CDS: a code distribution scheme for active networks☆
Introduction
The design of today's IP networks is based on internal network elements concentrating on the simple forwarding function, leaving the network control and management to the end points while achieving a great success nowadays [1]. On the other hand, with the rapid development of the Internet and increasing demands on new network services and applications, the traditional network cannot get itself well fitted for. In order to alleviate these problems, some researchers have suggested active networks (ANs) in which the network elements can perform customized computation on a message flow, instead of just simple forwarding [2].
The concept of ANs opens up a new and challenging field to both academy and industry. After years of concept study, some advancement has been achieved. For example, an architectural framework for ANs and specifications on the node operating system (Node OS) are suggested [3], [4]. According to the architectural framework for AN presented by AN Working Group, the functionality of an AN node are divided into four parts: underlying hardware, Node OS, execution environments (EEs), and active applications (AAs). Each active node runs a Node OS and one or more EE. The Node OS is responsible for allocating and scheduling the node resources. Each EE implements a virtual machine (VM) that interprets some kinds of active packets arriving at the node. An AA is an active program which, when executed by the VM of a particular EE, implements an end-to-end service. Likewise, a testbed for AN, known as Abone, is available for testing new services and all newly emerging features of ANs [5]. However, this area is still in its infancy. In Ref. [6], some important issues and concerns regarding ANs, such as EE, interfaces, security and code distribution protocol (CDP) are put forward, providing a good intuition towards a comprehensive study of the field.
In this paper, we will further investigate the design issues of the CDP and present a new code distribution scheme (CDS) that is better applicable in practice. Specifically, we note that the basic function of ANs is to get an active program injected into network nodes to perform a customized computation for end-user applications. With reference to the architecture in Ref. [3], as an active packet arrives at one node, it will be directed to an EE which claims the receipt of certain type of packets based on the information in the packet (e.g. headers, see ANEP [7]). EEs will then determine to fetch, compose, load and execute an active program as an AA to evaluate contents of the received packets.
There are two methods to deliver program codes into elements of ANs. One is to carry code fragments with an active packet itself through a data path [8]. This type of active packets is termed as capsules [2], while the method is called as in-band method [3]. The other method is classified as out-band method [9], of which loading may happen during a separate signaling phase or on-demand upon packet arrival.
In practice, most likely it is required to transport an active code via out-band. For one reason, the code size to implement a practical network control is typically very large for an individual capsule [9]. Moreover, it is expected that most end users will not program network nodes. Rather, applications in end systems may need to access AN by invoking an off-the-shelf AA code, which is provided by an AA developer. If the EE needs to fetch a program code on demand or in advance, a code distribution mechanism should be essentially available. Unfortunately, such a mechanism does not exist yet.
Nowadays, most researchers are in favor of the framework of ANs, but the CDP involved is likely coarse and inflexible. The ANTS [23] toolkit and PAN [19] have provided one promising CDP with in-band transfer and incremental data path distribution. On the other hand, this in-band method cannot meet the normal practical requirements as discussed above. In addition, it is very restricted to describe an active application only based on MD5. Likewise, ASP [9] provides a method, named as AASpec object, to describe AAs. But it leaves alone the problems with the store and distribution of active codes, as well as, security, etc. Nevertheless, we note that these previous contributions have established a good base for future researches.
There are two contributions in this paper. First, we provide a comprehensive study on the design issues regarding implementing a common and flexible CDP for ANs. Second, a new CDS is proposed accordingly. The rest of the paper is organized as follows. In Section 2, design issues on CDP and CDS are introduced. Section 3 describes a naming mechanism for AA. This is followed by a discussion on the distribution and store of AA description and active code in Section 4. In Section 5, we discuss the transport protocol for AA codes in CDS, which is a revision of trivial file transfer protocol (TFTP). A verification method for secure active codes based on public key infrastructure is presented in Section 6. Section 7 gives an implementation of CDS with a performance assessment to verify its effectiveness. Finally, conclusions are drawn in Section 8.
Section snippets
Issues on CDP
With reference to the CDP, we deem that the design of a common, practical code distribution mechanism should consider the following properties.
Naming and name resolution method of AA. This is a basic function of a CDP. When active packets arrive at an EE, the EE should determine which program to load and execute, where to get the program as needed. The name of an AA should universally identify the AA. In other words, it is essential to develop a universal naming mechanism to uniquely identify
Structure of AAI
AAI is a naming mechanism for AAs. Its task is to universally and uniquely identify an AA. The AAI must be concise enough to be encapsulated in active packets to indicate which AA to be executed. In addition, AAI may be used to name an application for other purposes, such as store and transport of AAs. In order to provide an AA identifier that is persistent, location-independent, unique and global, AAI is designed as a universal resource names (URN [12]).
As an example, AAI may be defined with
Distribution and store of AAD and AA codes in CDS
As we have known, there is a two-level mapping mechanism in CDS from AAI to AA code. Specifically, AAIPH first maps the AAI to an AAD XML document, and then maps the AAD to a collective of code components. After getting all necessary components, AAIPH composes, verifies the AA, and returns it to EE. Accordingly, there are two stores in CDS. One is for AAD XML documents; the other is for AA components or AA codes. Furthermore, CDS employs the existing technology of WWW to store and retrieve AAD
Transport protocol for AA codes
In CDS, we employ a revised TFTP to transport AA codes. There are mainly two revisions in CDS. The first is changing fixed payload size of 512K into a variable size. If network condition allows, a larger size will achieve a better throughput.
The other is to improve the security of TFTP. The client can only read from a server, but cannot write to the server. This is because TFTP has weak security. If the client can write to a server, a vicious client can write some useless or malicious code to
Security issues
Security is of a great concern to commercial community. In CDS, the security issues come out of three aspects, namely, store server, transport action and active codes. The server security concerns problems with denial of service attacks, misappropriation of service or data. The transport security should prevent active codes from substitution and insertion. Likewise, the correctness of active code itself should be checked after transferred or before executed.
Security based on PKI in CDS
Different level of security may be
Effectiveness verification of CDS
As described above, we can see that CDS is more flexible and secure than existing CDPs. However, it may incur a little delay compared with existing CDPs, but we believe the performance of CDS should be acceptable for use in practice. To verify the effectiveness of CDS, we have implemented a prototype of CDS based on Anetd [5], which is an experimental daemon specifically designed to support the deployment, operation and control of ANs with ABone. Specifically, we have modified or replaced some
Conclusions
In this paper, we propose a new common and flexible code distribution mechanism for ANs, named as CDS. In order to achieve flexibility, CDS provides a universal, flexible and scalable mechanism for using an XML document to describe related information with AAs. A two level mapping method also enables a flexible and distributed store of AAD XML documents and active code components. Moreover, a digital signature is embedded to protect active codes from tampering.
Experiments with an implemented
References (23)
The design philosophy of the DARPA Internet protocols
Computer Communication Review
(1988)- et al.
A survey of active network research
IEEE Communications Magazine
(1997) - K.L. Calvert (Ed.), Architectural Framework for Active Network, version 1.0, DARPA AN Working Group Draft, July 27,...
- L. Peterson (Ed.), NodeOS Interface Specification, DARPA AN Working Group Draft, January 10,...
- et al.
Evolution of an Active Network Testbed
(2002) - et al.
Current directions in active programmable networks
IEEE International Conference on Networks (ICON), Bangkok Thailand
(2001) - Alexander, D.S., Braclen, B., Gunter, C.A., Jackson, A.W., Keromytis, A.D., Minder, G.J., Wetherall, D. Active network...
- et al.
PLANet: an active internetwork
IEEE INFOCOM’99, New York
(1999) - et al.
The ASP EE: An Active Network Execution Environment
(2002) - et al.
Chord: a scalable peer-to-peer lookup service for Internet applications
ACM SIGCOMM 2001, San Deigo, CA
(2001)
Internet Security Glossary, RFC 2828, May
Cited by (0)
- ☆
This paper is supported by the National High Technology Development 863 Program of China Grant No. 2001AA112020.