Micro-Communication Element System

Transcription

1 Micro-Communication Element System Peng Zheng, Zeng Jiazhi, Zhang Ming, and Zhao Jidong School of Computer Science and Engineering, UESTC, Chengdu, , China Abstract. Based on the research on Service Unit based Network Architecture (SUNA), this paper presents a Micro-Communication Element System (MCES) which is a new interconnecting network system and is easy for applications and users from TCP/IP environment to be converted into. MCES is constructed of organized micro-communication elements, and the entire network system consists of many micro-communication systems. Beside interal flexibility, MCES is compact and easy to be implemented. 1 Introduction Since 1990s, research on high-performance network architecture has been conducted internationally. For instance, D. Clark, D. Tennenhouse et al proposed ALF (Application Level Frame) in 1990 [1] and Active Network Technique in 1996 [2]. Later, A. Lazar proposed a programmable network model [3]. These researches on optimizing network performance are based on layered architectures. So it is difficult for them to solve the problems that are inherent in layer-based networks. The Modular Communication System (MCS) [4][5][6][7], introduced by Stefan Boecking, is an object-oriented network architecture designed to satisfy diversified requirements of performance and Qos. In 2002, Braden and his fellows proposed a non-layered paradigm, called RBA (role-based architecture) [8], which can communicate between network layers and accommodate additional services in existing network. Function redundancy impairs the practicability of usage in the broadband network, as revealed in a number of studies [9][10][11]. To resolve existing defects in layerbased architecture, another non-layered network architecture, service unit based network architecture (SUNA) was introduced in 2003 [12], and its Micro- Communication Element System (MCES) is proposed in this paper. 2 Service Unit Based Network Architecture (SUNA) Service unit based network architecture is a modularized structure where modules are SUs (service units). A SU is a minimal entity (hardware or software) that provides services without any exposure of its inner details. Another feature distinguishing a SU from a layer is that the SU merely provide services while the other one not only offers K.-M. Liew et al. (Eds.): PDCAT 2004, LNCS 3320, pp , Springer-Verlag Berlin Heidelberg 2004

2 Micro-Communication Element System 423 services but also requests services. The services from SUs are implemented by service data units (SDUs), which are also titled packages. SU can be the sender (source), receiver (destination), forwarder or transformer. a loose set of applications Application Layer (Application Group) an orgnized set of service units Service Layer (Service Team) Fig. 1. Node model of SUNA In the new network architecture, end-to-end addresses are employed instead of layer addresses. End-to-end addresses are expected to be an ordered pair made up of node address and port number. End-to-End Address = (Node Address, Port Number) The node model of SUNA can be divided into two parts, as is shown in Fig. 1: an application group and a service group. An application group could only receive services, while service group accommodate applications with services. 3 Micro-Communication Element System Architecture A SU and network media constitute active communication channels. Since SUs are relatively small, a single node may contain many SUs. We therefore call them Micro-Communication Elements. Furthermore, a service team, which is made up of relevant nodes, organizes these micro-communication elements into a microcommunication system. A number of micro-communication systems then consolidate to form a network system. That is exactly why we call the first network system in SUNA as MCES (Micro Communication Element System). 3.1 A Reference Model for MCES Architecture A reference model for MCES architecture is shown in Fig. 2. Here, squares and triangles stand for SUs. As is mentioned in this [12], there are five general types of SUs in a network and there are several distinct SUs in each general type to perform different functions. They are denoted by i and j as suffixes respectively. Connectionless and connection-oriented SUs are of the first SU type. We could also confirm the SUs for segmentation, ICMP, IGMP and RTCP belong to the second type. Similarly, passive services fall into category three, routing-like SUs pertain to the fourth type, and SUs for encryption, NIC and so on should be of the fifth type. The sequence of SUs of the 5th type in the same node could be either the same or not the same. One host could thereupon communicate with distinct nodes simultaneously in different ways such as encrypted or common communication. In addition, the SU sequence structure could be decided during initiating period or after the negotiation between other nodes.

3 424 P. Zheng et al. S1,i Multiple Service Units of general type 1, 2, 3 and 4 S4,i S5,1 S5,1 NIC Service Unit Fig. 2. A reference model for MCES architecture Moreover, user-defined SUs are also available to extend network functions. For instance, users could define their own routing SUs to implement voluntary network function in a custom way. 3.2 The Package Format of MCES Architecture As is shown in Fig. 3, a package is composed of headers and bodies (data plus check) in which the data can be transmitted on behalf of applications. The basic header is indispensable, and is public to every SU in a service team. A bit map is employed in a header to denote the existence of each special field. Every special field includes several columns. For example, the special field for connection is divided into four columns: serial number, confirm number, window size and emergency pointer. Furthermore, every special field could be shared by multiple SUs. Returning to the previous example, special fields for connections are shared by SUs of connection establishing, data sending, data receiving, connection releasing and so on. Protocols, such as OSPF, RIP, EGP, and BGP, make use of data fields instead of headers. There should be different type flags to identify the existence of these different protocols. Routing and forwarding SUs merely forward packages to the 5th SUs in corresponding ports. All these SUs may change data, headers, or the entire pack-

4 Micro-Communication Element System 425 ages. For example, compression and decompression SUs only alter the data, while NIC SUs transform whole packages. Header Data Field CRC Check Basic Header Special Field (Maybe exist) Extendable Header (May be used in futher) Destination Node Address (4/16 Bytes) Destination Port Address (4/16 Bytes) Source Node Address (2 Bytes) Source Port Address (2 Bytes) Time to Live (8 bits) Priority and Data Type (5 bits) Bit Map for Special Fields (11 bits) Routing Connection ESP AH User Defined Service Unit ICMP Multicast Preserved Fig. 3. Package Format of MCES 4 Transition to the SUNA The original network adapter can be still employed after minor changes. As mentioned before, the interfaces of most system calls would remain to guarantee the tremendous amount of TCP/IP applications and software based on TCP or UDP are used as usual. Besides, additional SUs could be incorporated to extend system calls so that the real time transmission of voice and video can be supported directly. In SUNA, without frame processing, hardware structure, package forwarding rate and price of routers would be close to current layer 2 switches. With a package converter, our lowcost network can communicate with Internet. 5 Conclusion The MCES adopts many successful experiences and productions of TCP/IP, including state transition diagram which make it possible to adopt the modeling result immediately. With the avoidance of redundant functions and service transfer overheads, performance of MCES would be improved. And it is easy for MCES reference model to be implemented using modular or object-oriented programming methods. Consequently, MCES can be improved continually to suit broadband network for the next generation applications.

5 426 P. Zheng et al. References 1. D. Clark, D. Tennenhouse. Architectural Considerations for a New Generation of Protocols [A]. In Proc ACM Sigcomm 90[C]. Philadelphia, USA: ACM Sigcomm 90, D. Tennenhouse, D. Wetherall. Towards an Active Network Architecture [J]. Computer Communication Review, , Vol. 26, No A. Lazar. Programming Telecommunication Networks [A]. In Proc IWQOS 97[C]. New York, USA: Proc. 5th International Workshop on Quality of Service 1997, IWQOS 97, Stefan Boecking, Object Oriented Network Protocol [M], Beijing, Machinery Industrial Press (ISBN /TP), Stefan Boecking, et al. A Run-Time System for Multimedia Protocols [A]. In Proc ICCCN 95[C]. Las Vegas, USA: 4th International Conference on Computer Communications and Networks ICCCN 95, , Siemens AG. Performance and Software Evaluation of the Modular TIP Communication System[C]. USA: 5th International Conference on Computer Communications and Networks, Ch. Jin, Y. Du and J.Zh.Zeng, Dynamic Protocol Configuration upon Object [J], Computer Application, June B. Braden, T. Faber, M. Handley. From Protocol Stack to Protocol Heap - Role-Based Architecture[R]. First Workshop on Hot Topics in Networking, J. Kay, J. Pasqucde. Profiling and Reducing Processing Overheads in TCP/IP [J]. IEEE/ACM Trans.Net, , Vol.4, No.6: R. Stewart, C. Metz. SCTP: New Transport Protocol for TCP/IP [J]. IEEE Internet Computing, to , Vol.5, No.6: R. Engel, D. Kandlur, A. Mehra, D. Saha. Exploring the Performance Impact of QoS Support in TCP/IP Protocol Stacks[C]. Proceedings of IEEE INFOCOM98, , Zeng Jiazhi, et al, Service Unit based Network Architecture[C], International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT), 2003