Communication Protocol Decomposition and Component-based Protocol Submodule

Transcription

1 Communication Protocol Decomposition and Component-based Protocol Submodule Tianzhou Chen 1, Quan Gan 2, Zhaohui Wu 1 College of Computer Science, Zhejiang University, Hangzhou, P.R.CHINA, {tzchen, wzh}@zju.edu.cn 2 g_q_spring@hotmail.com Abstract. Due to evolving network technologies as well as increased and varying demands of modern applications on embedded systems, general-purpose protocol stacks are not always adequate. We examine the usefulness of component-based software engineering for the implementation of software communication systems. We present an architecture that allows dividing protocol software into fully de-coupled components. By plugging required components together, that is, loading proper protocol submodules for communication services, we rapidly prototype flexible, robust, and application-tailored communication protocols. The primary goal is the configurability of communication services, that is, the configurability of protocol submodules for each communication service according to application requirements and network capabilities. The achieved communication system supports efficiently and coordinately the multiple communication services customized by the coexisting applications. Keywords: component, network communication protocol, communication system modeling, customized submodule 1 Introduction Today's communication systems are typically structured into several layers, where each layer realizes a fixed set of protocol functions. These functions have been carefully chosen such that a wide range of applications can be supported and protocols work in a general environment of networks. Well-known architectures of this type are the OSI stack [1] or the Internet Protocol Suite [2]. However, due to evolving net-work technologies as well as increasing demands of modern applica- This work is supported by the national 863 high technology project and HP Embedded Laboratory of Zhejiang University. tions general-purpose protocol stacks are not always adequate. In particular, the applications on embedded devices often require various communication services for the sake of many different device types and the communication means introduced by the devices. Also, the communication services cannot respond dynamically to the flexible applications. The services will never be changed until they are reconfigured after the communication devices turn off. To improve this situation an alternative approach is to decompose the monolithic implementation of software communication system. The idea of replacing general-purpose protocols by application tailored protocols requires ease of implementation and rapid prototyping of

2 new protocols. Since protocol implementation from scratch is expensive and error-prone, it is important to structure protocols in a way that protocol elements can be reused in different contexts and adapted to the special needs of applications. Additionally, protocol implementations should be prepared for change and hence easy to extend and maintain. The recently emerged software-engineering paradigm called component-based development (CBD) promises a new dimension of re-usability and rapid prototyping of software. CBD fosters the division of software into components that can be easily configured and plugged together to create new applications. AVOCA is a component-based communication system [3]. It is a further stage of the x-kernel [4] and finer-grained protocol components are employed representing protocol mechanisms. These protocol components provide the same uniform protocol interface as the original x-kernel protocols. However, a communication system must provide communication services for multiple applications that coexist in the system. It is paramount to be able to configure communication services according to varying demands of applications and coordinate all the protocol functions. Developing a single heavyweight protocol that efficiently supports every class of application and network appears to be infeasible. One promising alternative is to devise multiple lightweight protocols that are customized for particular pairings of application requirements and network characteristics. Communication services are configured separately by lightweight protocols that are specially tailored to fulfill the requirements of particular applications (or classes of applications) that run in a particular network environment. In this paper we present a highly flexible and configurable architecture of network communication system especially for embedded devices. We devise multiple lightweight protocol components that are customized for particular pairings of application requirements and device characteristics. Communication services are configured dynamically by selecting proper protocol components, that is, loading proper protocol submodules for protocol functions. Then we demonstrate how to realize multiple communication services that support all the coexisting applications in one system efficiently and coordinately. 2 Architecture of Communication System The task of communication systems is to provide communication services for applications that exist in the system. We abstract the implementation of communication service customized by given application to a communication subsystem, as illustrated in Fig. 1. A communication subsystem upgrades a given basic communication service in order to provide a target service requested by the application. However, the design and analysis of its architecture will be the most untrivial task, since the properties of this communication scheme will severely impact the performance of the whole system. In order to handle this, we have concentrated on the communication mechanisms, primitives and abstractions. To allow reuse, selection and integration of different mod-

3 application subsystem target service basic service application subsystem network(e.g.,ethernet or ATM) Fig. 1. Communication subsystem ules, the communication and the computation will be separated and encapsulated. The communication subsystem is modeled as an ensemble of communicating modules. Each module is defined by its interface and its content where the interface is composed of a set of ports on which external or internal operations can be performed. This abstraction is reached when the module is represented by the protocol component and the communication is seen as the combination of requests and services. The protocol components serve as basic communication functions. They encapsulate the implementations of the protocol mechanisms, and provide the services externally by interfaces of them. The communication model is meant to manifest a unique interpretation of associations between components as a set of fundamental communication primitives. Moreover, these components may request other ones for services by interfaces, or their contents can be composed of other component instances. Hence the communication subsystem is a stacking of all the required components, which are plugged together to realize a given communication service. Due to various communication devices and application requirements the configurations of customized communication subsystems may be distinct. Therefore it is important to structure communication systems in a way that different subsystems can be supported and coordinated efficiently. We can employ different protocol components to serve the communication request that exists in different subsystems accordingly. Moreover, we support run-time reconfiguration of the communication subsystem. We examine the efficiency of the subsystem at run-time. When it does not adapt to the request of the application, more suitable component will be loaded to replace the one that does not match. This enables communication subsystems to adapt dynamically to changes in application requirements (e.g., switching from unreliable to reliable data delivery), communication system resources (e.g., buffer space and CPU load), and network characteristics (e.g., network congestion and routing). The replacement of protocol component is transparent to applications or the other components that refer to it as long as the interface remains the same. Proper communication components are dynamically loaded, that is, they are loaded into communication subsystem without rebooting the device. Communication subsystem adaptivity is important since applications and networks are dynamic entities that are not necessarily served most effectively by statically configured mechanisms. 3 Protocol Component The protocol component serves as the element of the communication system. It implements the basic communication service. These components are captured elegantly through the decomposition of the

4 protocols. We may employ modularized architecture based on protocol hierarchy to decompose the protocol. For example, the connection-oriented transport subsystem of the Internet Protocol Suite consists of three components of TCP, IP and Ethernet [5]. Likewise, we may also employ modularized architecture based on protocol functions to break down the protocol. The protocol functions serve as basic architectural components. For example, the sender part of Transport Control Protocol (TCP) located between application and network interface is totally composed of five components, which are connection management, data emit, data reemit, flow control and congestion control [6]. Protocol functions can often be provided by different algorithms (called mechanisms). Flow control, for instance, could be realized by a window-based or rate-based mechanism. Examples for protocol functions and corresponding mechanisms are listed in Table I. Different mechanisms of one protocol function are implemented by the corresponding components while the interface remains the same. We give the name submodules for these correlative components. The novel approach to protocol component presented herein is that we can implement application- and device-customized submodules for the same communication function. New execution properties extending an existing service can be added by writing additional submodules and including them in the existing component suite. The component of Internet Control Message Protocol (ICMP), for example, is used by Internet nodes and routes to signal networking conditions, as well as for network diag- Table 1. Protocol functions and corresponding mechanisms Protocol function Flow control Corruption control Connection management Acknowledgement Mechanism Stop-and-wait Window-based Rate-based Checksum Parity Implicit 2-way-handshake 3-way-handshake No connection (datagram) Cumulative Selective nostics. However, we give more suitable submodules under the different circumstances. When the network s bandwidth is low, the proper one is that numerical value of Time To Live (TTL) is adjusted according to network status. Also, we give the one that Timestamp Reply is forbidden so as to decrease the overload. Moreover, we are able to modify original properties of the components and add customized communication services in the submodules. The attack of Denial of Service (DoS), as we known, is often caused by the mechanism of sending large numbers of useless packages. It will be helpful to design a submodule resolving the problem by means of checking the source/destination address and the type of the package, including the package frequency. Thus, the component of ICMP will have ability to filter and check the package, just trying to guarantee the security of the network. With all these submodules, customized communication services can be constructed, which provide execution guarantees targeted to the specific requirements of the applications on different devices.

5 4 Implementation This work is deployed on the platform of Linux, hence the protocol components are just implemented by Linux modules [7], which can be loaded into the kernel or removed dynamically without rebuilding the kernel. Our novel approach is to remove the original TCP/IP protocol stack from the Linux kernel. However, we load the corresponding modules that implement the communication components into the kernel after it starts up. These components will now provide the services that are provided originally by the TCP/IP functions. The major steps are as follows. The primary process of TCP/IP protocol stack, such as allocating memory buffers in the kernel, registering structures of protocol chains and initializing the protocols are removed from the kernel. Instead, these entire works mentioned above are shifted into the corresponding implementation modules of the components. The work of allocation and registration are handled in the entrance function of the module, and should be undone in the exit function. The component's interface is then inserted into the files that originally implement the function. It is exported in the symbol table of the kernel, that is, we register an interface to the kernel. When the module that realizes the protocol component is compiled and installed, the interface is set to the concrete service implemented by component, which is handled in the entrance function of the module. Similarly, the interface is cleared in the exit function. The following are the example of entrance function and exit functions in certain implementations of ICMP component. int init_module(void) { /*set the interface*/ ICMP_SEND=icmp_send; XRLIM_ALLOW=xrlim_allow; /*load ICMP protocol component module into the kernel*/ inet_add_protocol(&icmp_protocol, IPPROTO_ICMP); /*initializing icmp protocol*/ icmp_init(&inet_family_ops); return 0; } void cleanup_module(void) { /*sock_create(icmp_socket) has been involved in icmp_init(&inet_family_ops), it should be released here*/ sock_release(icmp_socket); /*remove the ICMP component module from the kernel*/ inet_del_protocol(&icmp_protocol, IPPROTO_ICMP); /*reset the interface*/ ICMP_SEND=my_icmp_send; XRLIM_ALLOW=my_xrlim_allow; } We demonstrate the preferable example of communication system in Fig. 2. The given communication system provides communication services for three different applications that coexist in the system. As mentioned above we can employ different implementation submodules for the same protocol function that exists in different subsystems. For the same protocol function A, we load two different submodules of A1 for application 1 and 2, while A2 for application 3. Also, compo

6 Application 1 Application 2 Application 3 Component A1 Component A2 Component B1 Component B2 Component B Component C Communication Subsystem Network Fig. 2. Communication system nent B serves for application 3, while it is decomposed to B1 and B2 to serve application 1 and 2 as a whole. Moreover, this communication system does not necessarily remain the same, that is, the submodules can be replaced by others that match better as time goes on. For example, the submodule of C can be replaced dynamically by one of C1, C2 and etc, which provide the same communication service specifically for the various device types and application requirements. 5 Applying the Model and Measurements An experiment has been done for the protocol components of ICMP and UDP. The Linux kernel used in the experiment is The network part is removed from the kernel while only Unix Domain Sockets and TCP/IP options remain. After the kernel starts up, we test the component and the results are as follows. When the module of ICMP component is not loaded, it results in timeout when pinging this host from others. It is because that the interface cannot find the corresponding service answering for the ICMP package. So it just does nothing and cannot echo the reply. After the component of ICMP is properly loaded, the ping command works correctly. So we can say that the component serves very well. Another experiment is done to tell the performance difference precisely between the protocols implemented in the monolithic kernel and that encapsulated by modules. So we test the protocol of UDP by the software of netperf [8] that is the benchmark used to measure the performance of Linux network. We use the default value of Socket Size Message Size Elapsed Time Request Size and Response Size, which are 64k Bytes 1k Bytes 10s 1 Byte and 1 Byte respectively. The result is shown as Table II. There is approximately 1% performance lost compared to the monolithic implementation after the component-based mechanism is introduced, yet it is for the expense of encapsulation. However, the communication mechanisms can be tailored according to

7 Table 2. Performance of UDP by different mechanism UDP Compiled in the monolithic kernel UDP Compiled as module and loaded in the kernel Compare of performance Bulk Data Transfer Performance 10 6 bits/sec Request/Response Performance Trans. Rate per sec ( )/ *100%=1.11% ( )/ *100%=1.46% the device types and the applications running on them, which result in various protocol components that feature quite different performance characters. Thus we devise customized communication system with quite an increase in performance compared to the monolithic implementations. 6 Conclusion The component-based communication architecture enables the configuration of customized communication subsystem by composing a proper set of reusable protocol components. We can employ different protocol components to serve the communication request that exists in different subsystems accordingly. Moreover, we support run-time reconfiguration of the communication subsystem. The replacement of protocol component is transparent as long as the interface remains the same. Proper communication components are dynamically loaded, that is, they are loaded into communication subsystem without rebooting the device. Thus we devise the communication services demanded by the coexisting applications on the given devices to construct flexible, robust, and application-tailored communication systems. References 1. ISO 7498, Information technology -- Open Systems Interconnection -- Basic Reference Model. 2. J. Postel (Ed.), Internet Official Protocol Standards, RFC 1720, Network Working Group, March Don Batory and Sean O'malley, The Design and Implementation of Hier-archical Software Systems with Reusable Components, ACM Transactions on Software Engineering and Methodology, Vol 1, No 4, Pages , October 1992.s 4. N. Hutchinson and L. Peterson. The x-kernel: an architecture for implementing network protocols. IEEE Transactions on Software Engineering, 17(1): 64-76, Jan

8 5. B. Geppert and F. Rößler, Automatic Configuration of Communication Subsystems, SFB 501 Report 17/ D.C. Schmidt, D.F. Box, and T. Suda, ADAPTIVE: A Dynamically Assembled Protocol Transformation, Integration, and evaluation Environment, Concurrency Practice and Experience, Vol. 5, No. 4, June Bryan Henderson, Linux Loadable Kernel Module HOWTO[EB/OL], HOWTO/Module-HOWTO/,