Bowman: a Node OS for Active Networks

Bowman: A Node OS for Active Networks ¡ ¢ S. Merugu S. Bhattacharjee E. Zegura K. Calvert ¡ ¢ College of Computing, Dept. of Computer Science, Dept. of Computer Science, Georgia Tech., Univ. of Maryland, Univ. of Kentucky, Atlanta, GA. College Park, MD. Lexington, KY. £ merugu, ewz ¤ @cc.gatech.edu [email protected] [email protected] AbstractÐBowman is an extensible platform for active networking: it ef®cient and ¯exible packet classi®cation algorithm. Com- layers active-networking functionality in user-space software over variants putation on behalf of a ¯ow occurs in its own set of compute of the System V UNIX operating system. The packet processing path implemented in Bowman incorporates an ef®cient and ¯exible packet classi®- threads. Thus, the internal packet forwarding path of Bow- cation algorithm, supports multi-threaded per-¯ow processing, and utilizes man is inherently multi-threaded. real-time processor schedulingto achieve deterministicperformance inuser- ¥ Provide a fast-path. For packets that do not require per- space. In this paper we describe the design and implementation of Bowman; ¯ow processing, Bowman provides cut-through channels, discuss the support that Bowman provides for implementing execution environments for active networking; discuss the network-level architecture i.e., paths through the Bowman packet processing cycle that of Bowman that can be used to implement virtual networks; and present do not incur the overheads of multi-threaded processing. performance data. Bowman is able to sustain 100 Mbps throughput while ¥ Enable a network-wide architecture. Globally, Bowman forwarding IP packets over fast Ethernets. implements a network-wide architecture by providing system support for multiple simultaneous abstract topologies, I. INTRODUCTION i.e., overlay network abstractions that can be used to imple- Active networks provide a programmable user-network inter- ment virtual networks. face that supports dynamic modi®cation of the network's be- ¥ Maintain reasonable performance. Bowman is multi- havior. Such dynamic control is potentially useful on multiple processor capable and provides deterministic performance levels: in user-space by utilizing POSIX real-time extensions for ¥ For a network provider, active networks have the potential processor scheduling [2]. Even though Bowman is imple- to reduce the time required to deploy new protocols and mented entirely in user space, it delivers high performance. network services. IP forwarding through Bowman saturates 100 Mbps Ether- ¥ At a ®ner level of granularity, active networks might en- net, and the Bowman classi®er is able to classify packets at able users or third parties to create and tailor services to gigabit rates while matching on multiple ®elds. particular applications and current network conditions. ¥ For researchers, a dynamically-programmable network of- fers a platform for experimenting with new network services The Bowman software architecture is highly modular and exten- and features on a realistic scale without disrupting regular sible. All the major parts of a Bowman node Ðcommunication network service. protocol implementations, routing protocols and associated data The programming interface supported by the active network structures, code-fetch mechanisms, per-¯ow processing and out- de®nesthe ªvirtual machineºpresent at each node of the network. put queuing mechanismsÐ are loaded dynamically at run-time. Depending on its design, such a virtual machine can provide a The Bowman implementation can be ported to UNIX systems generic mechanism such as a language interpreter at each node or that support the POSIX system call interface [2]. it may just allow the user of the network to choose a service from a set of services provided at each node. Particular programming In the next section, we provide an overview of Bowman. We interfaces for active networks are implemented by node-resident start with the architectural context for the development; we then programs called Execution Environments (EEs). discuss the abstractions supported by Bowman and provide an This paper describes the design and implementation of the overview of the network architecture. In Section III, we present Bowman node operating system, a software platform for im- selected details of the Bowman implementation, with a focus on plementing execution environments within active nodes. Bow- the packet processing path and the packet classi®er. We present man was speci®cally implemented as a platform for the CANEs a set of performance results for Bowman in Section IV including EE [1]; however, it provides a general platform over which other details of the forwarding performance and individual overheads EEs may also be implemented. in the packet processing path. We also provide a performance The design goals for Bowman are the following: analysis of the Bowman packet classi®cation algorithm and the ¥ Support per-¯ow processing. Bowman provides system effect of real-time processor scheduling. In Section V, we de- support for long-lived ¯ows. Flows are classi®ed using an scribe how the CANEs EE is implemented over Bowman. We present a survey of related work in Section VI, and conclude in Work supported by DARPA under contract N66001-97-C-8512. Section VII. II. OVERVIEW basic services (again, the real users of the EE API are the In this section we provide an overview of the design and programmers who create the active applications). ¥ implementation of Bowman. The active applications provide an interface by which end- users invoke (by sending packets to an EE with appropriate instructions) and possibly customize (via in-band or out-of- Active Network User Network Interfaces band signaling) their services. The ability of EEs to provide interesting and novel services de- ANTS CANEs . IP v4 pends greatly on the degree to which the NodeOS exposes lower- level mechanisms. For example, providing active applications execution environments with ®ne-grained control over scheduling requires a greater degree of access to output and processor scheduling decisions than Common Objects is traditionally provided in general-purpose operating systems. (Routing Tables) In designing Bowman we have attempted to provide this kind of access without re-implementing available components. Thus Bowman makes use of an underlying Host OS, and attempts to P P . hide the differences between low-level capabilities (e.g., network IO interfaces Processors State Store interfaces) across different platforms by providing a consistent node resources interface. Node Operating System While the NodeOS/EE interface generally marks the separa- tion of local and global concerns, the NodeOS cannot totally Fig. 1. DARPA active networking architecture ignore end-to-end considerations. For example, the NodeOS is responsible for seeing that packets transmitted by end users Ðincluding both data and signaling packetsÐ reach the proper A. Architectural Context nodes and the proper EE at a node. Bowman provides a packet- Figure 1 shows the architecture for active network nodes de- matching mechanism enabling EEs to describe packets they want veloped within the DARPA active network research commu- to receive. In addition, Bowman makes it possible to group and nity [3]. The primary functional components in the architecture identify channels consistently across multiple nodes, so that EEs are the Node Operating System (NodeOS) and the Execution can de®ne and use virtual topologies. In addition, the role of the Environments (EEs). Generally speaking, the NodeOS is re- NodeOS (and Bowman) includes support for common objects sponsible for managing the local resources at a node, while each such as routing tables that are likely to be useful to all EEs. EE is responsible for implementing a User-Network interface, Bowman implements a subset of the emerging DARPA Node i.e., a service exported to users of the active network. In par- OS interface [5]. The interface exported by Bowman is intended ticular, each EE de®nes a ªvirtual machineº that interprets the to be used primarily by EE-implementors, although it can be packets delivered to it at each node. Thus an Internet Protocol used for other purposes as well, such as experimentation with implementation might be considered a very simple EE, whose different network architectures. virtual machine is ªprogrammableº only to the extent of control- B. Bowman Abstractions ling where packets are delivered. On the other hand, the ANTS execution environment [4] uses a virtual machine that interprets Bowman is built around three key abstractions: channels, a- Java bytecodes. ¯ows, and state store. To understand how Bowman ®ts into the picture, it may be ¥ Channels. Channels in Bowman are communication end- useful to consider the purpose of the programming interface points that support sending and receiving packets via an exported by each component, along with its intended ªusersº: extensible set of protocols. Bowman exports a set of func- ¥ The NodeOS exports an API that provides access to node tions enabling EEs to create, destroy, query and commu- resources including computing, storage, and transmission nicate over channels that implement traditional protocols bandwidth; its ªusersº are the Execution Environments, or (e.g., TCP, UDP, IP) in various con®gurations. In addition, more precisely the programmers who implement them. A Bowman channels allow other forms of processing such as functional speci®cation of this API is currently in draft [5]. compression and forward error correction to

Load more