Activating networks: a progress report

Cover Feature

.

Activating Networks: A Progress Report Research in active networking has moved beyond ad hoc approaches. Several working systems address a range of problems, including congestion control and auctions.

Jonathan M. Smith University of Pennsylvania

Kenneth L. Calvert University of Kentucky

Sandra L. Murphy TIS Labs at Newark Associates Inc.

Hilarie K. Orman US Defense Advanced Research Projects Agency

Larry L. Peterson Princeton University

32

ctive networks—networks you can add programs to or customize to particular applications—are probably most familiar as Web proxy caches and firewalls. In their more sophisticated form, however, they have become customized infrastructures that let designers program control planes—the control software and network hardware used to manipulate the transport system’s behavior. Programming mechanisms such as open signaling are becoming more widespread, for example. But research in active networks has taken a step beyond even these sophisticated infrastructures. Working systems now let designers modify packetswitching infrastructures on the fly using either a switch-like model, which mixes active packets with other packets, or in a capsule model, which regards all packets as programs.1 From this work, researchers are defining a general architecture for active network elements that contains multiple execution environments (EEs). Each EE accepts valid programs and packets, either executing them or modifying their state, and emits one or more new packets or programs. The EE is essentially the active network’s programming environment and is often centered on a particular language or model. The major challenge to implementing this general architecture is how to trade off among usability, flexibility, security, and performance concerns. The chief obstacles to usability are unfamiliar programming models and constraints. Flexibility means that the network subsystem can be adapted to a wide variety of tasks. Security challenges include being able to define, identify, and authenticate principals. The principals must also have associated rights, enforced remotely through cryptographically protected credentials. Rights must be to real network resources such as buffers and bandwidth. Finally, performance targets dictate where active networking can be deployed without creating new bottlenecks.

A

Computer

In surveying working systems and experimental results, we have found that first-generation systems have opted to use modern programming language technologies such as Caml (a language developed at INRIA) and Java to provide usability and safety, and cryptographic techniques to provide security. The systems differ in the degree of flexibility and performance they offer. Many differences stem from the use of a particular security model. Their degree of usability differs, depending on the application.

TOWARD A GENERAL ARCHITECTURE Figure 1 shows the envisioned general architecture for a node in an active network. One or more applications feed into an EE, which feeds into a node operating system. A single, monolithic EE might manage hardware resources within the runtime system, but this would not work well when EEs must share node resources. The research community has developed a framework that describes an active network’s functional components and component interfaces.2 The framework assumes the traditional network—one that comprises nodes connected by various kinds of transmission channels, or links. It also specifies a packet-switched network, which means communication takes place when packets of data move from node to node. The network also communicates among end systems, as opposed to providing general computing services. The active network differs from traditional architectures primarily in what it does not specify. Instead of defining how the nodes work together to provide the network service (for example, through best-effort datagram delivery), the active network describes functional slots that must be instantiated to provide a particular network service. These slots create a new degree of freedom in network architectures, which in turn opens up the opportunity to speed up network evolution and thus accommodate new network types, algorithms, and applications. 0018-9162/99/$10.00 © 1999 IEEE

.

Figure 1. A proposed general architecture for active networking. At each network node, execution environments (EEs) act as programming mechanisms and can be tailored to a particular application or set of applications. The EEs could be any of the environments currently offered: Alien, ANTS, Switchware, and so on. The node operating system (Nemesis, Scout, Linux, or NT, for example) enforces resource sharing and eliminates the need to repeat core services.

Application 4 Application 1 Application 2

Execution environment A

Application 3

Execution environment B

Node operating system

Application 1

Execution environment A

Application 3

Execution environment B

Node operating system

Transmission facilities

Obtaining services As the figure shows, a network user (application) gets a service by interacting with an EE, an instance of which is running in each shared node as well as in the communicating end systems. The EE is responsible for all aspects of the user-to-network interface, including the syntax and semantics of the packets the user submits, the nature of the programming model and the abstractions supported, and addressing and naming facilities. Each EE exports some API to the user—for example, an extended Java Virtual Machine, an enhanced sockets interface, or a secured module-loading interface for adding extensions. Because multiple EEs may run on a single active node, as in Figure 1, the node’s operating system (NodeOS) must manage available resources and control resource contention. To ensure this control, all EEs access node resources only through the NodeOS, which mediates all access to node resources, including transmission, storage, and computational bandwidth. The NodeOS also implements a security policy database and an enforcement engine, which carries out node policies that govern resource use. Finally, the NodeOS may also support generic abstractions that could be useful to all EEs, such as forwarding tables. Thus, the end user’s packets see the services built up in three layers. At the bottom level, the NodeOS’s API—which is consistent throughout the active network—defines the basic building blocks available to EEs. An individual EE implements a set of abstractions using these building blocks and presents them to the end user. To obtain a desired service, the end user manipulates these abstractions according to the API the EE defines. The basic operation model is the same for all active nodes: Packets arrive on some physical link, and the

NodeOS immediately classifies them according to their headers and places them in the appropriate logical channels. Each channel has some associated protocol processing, which may include security checks. A channel delivers a packet either to an EE for interpretation and processing or to an output physical link. EEs may also originate packets and place them in output channels, which provide processing and, ultimately, transmission, on a physical link. Unlike traditional networks, however, in which a single packet traverses network nodes, the relationship between incoming and outgoing packets at an active node is arbitrary—giving designers a new degree of freedom. This means that the EEs must implement any global mechanisms to enhance or maintain network stability; the NodeOS can only ensure that instability in one EE does not affect the resources available to others. Many EEs have implemented mechanisms to ensure the stability of the services they provide. To simplify porting EEs to multiple underlying operating systems, the proposed active network architecture specifies an EE-to-NodeOS interface, or NodeOS interface.

Design objectives The architecture meets five main objectives: • Minimize the standardized protocols required to develop and implement end-to-end services. By reducing the amount of global agreement needed, this objective serves both research and commercial interests. Designers can experiment with a “live” network because the network is flexible enough to accommodate their needs during its operation. On the standard foundation, a variety of communication services can be established within each EE. April 1999

33

.

Current Work on Execution Environments Alien: D.S. Alexander et al., “Active Bridging,” Proc. SIGCOMM 97, ACM Press, New York, 1997, pp. 101-111.

ANTS: http://www.sds.lcs.mit.edu/activeware Liane: S. Bhattacharjee, K.L. Calvert, and E.W. Zegura, “Reasoning about Active Network Protocols,” Proc. Int’l Conf. Network Protocols, 1998, pp. 31-41. Liquid Software: ftp://ftp.cs.arizona.edu/xkernel/ Papers/tr96-11.ps.

Internet Protocol (IP), as instances. In the general architecture, an IP stack can be viewed as an EE, albeit with a very simple API and role.

EXECUTION ENVIRONMENTS Active networks rely on the ability to add programs easily to the networking infrastructure, so the choice of the EE’s programming language and runtime environment is critical. The EEs we describe attempt to optimize different programming aspects. Their particular trade-offs depend on the expected mix between active and nonactive traffic, the amount of processing power in the infrastructure, and the longevity of the active networking mobile code.

Netscript: http://www.cs.columbia.edu/dcc/netscript.

Smartpackets PAN: E. Nygren, “The Design and Implementation of a High Performance Active Network Node,” master’s thesis, MIT, Cambridge, Mass., 1998. PLAN: M. Hicks et al., “PLAN: A Packet Language for Active Networks,” Proc. Int’l Conf. Functional Programming, 1998, pp. 86-93. Smartpackets: http://www.net-tech.bbn.com/smtpkts/smtpkts-index.html

SwitchWare: D.S. Alexander et al., “The SwitchWare Active Network Architecture,” IEEE Network Magazine, May/June 1998, pp. 29-36.

• Maximize flexibility in services supported. An element of this is to support different services simultaneously. The network-element resources the NodeOS controls are those universally needed by EEs; in this sense the architecture resembles a kernel architecture, in which EEs are multiprocessed. Because multiple EEs can run concurrently in each network node, research into different programming models can proceed in parallel. This is important for two reasons. First, although the programming community is gaining more insight into various models, they have yet to select a winner. Second, designers can migrate to new versions of EEs while continuing to support the old ones. • Let networks operated by different administrations be interconnected. Part of this is recognizing that trust relationships vary across administrations. It also means that security must be a fundamental consideration. In the general architecture, the NodeOS provides security services to EEs. • Support scaling in both size and speed. This means considering fast-path processing, for packets that may not need active capabilities. • Encompass current protocols, particularly the 34

Computer

In BBN’s Smartpackets, mobile code is bound to and delivered with an IP data packet. The code’s lifetime at the node is only the time to completely execute it. Smartpackets designers use Sprocket, a source code language that can be easily compiled to a compact representation, and the Spanner executable language (similar to a generic assembly language). The runtime system for Spanner includes support for accessing network management variables from management information bases (MIBs) efficiently, but there is no access to system calls or memory outside the current packet and its declared dynamic variables. With the added support for packet authentication, Smartpackets is tailored for highly flexible but safe network device monitoring and control.

Active Network Transport System (ANTS) MIT’s ANTS uses Java as its programming language and the Java Virtual Machine for the runtime environment (see “ANTS: Network Services Without the Red Tape” on pp. 42-48). Java’s features make ANTS suitable for a variety of applications, which means it is gaining a programmer base. To transport mobile code, ANTS primes the packet delivery path with any necessary protocol code during the initial delivery. Subsequent packets can then use the code without the overhead of transporting it. At the lowest layer of its architecture, ANTS contains capsules, which carry both code and data. However, because the code is limited to referencing a protocol to apply to the packet, the code representation is compact. MIT’s Practical Active Network (PAN) modifies the ANTS architecture to be more closely tied to the NodeOS and to support coexisting mobile-code systems.

Liquid Software Relative to other elements of an active network, Java is slow. The University of Arizona’s Liquid Software contains a set of Java tools that offset the

.

speed problem in two ways (see “Joust: A Platform for Liquid Software” on pp. 50-56). First, it uses Javato-C translators in conjunction with C compilers, thus avoiding the need to interpret bytecode at runtime. Second, it uses compilers that themselves execute quickly and can be run at the point of execution. This approach maintains the usability and flexibility of Java while improving performance.

implementation is in C++, but relies on a reduced programming model that gives a predecided amount of flexibility to the dynamic environment. The advantage is that designers can limit the required security analysis. Efforts are under way to apply Liane to classes of multicast service and to provide verifiable safety assertions about the behavior of composed services.

SwitchWare The University of Pennsylvania’s SwitchWare uses a domain-specific functional scripting language, Programming Language for Active Networks (PLAN), as well as a general-purpose functional programming language, Caml, for its programming interfaces. Both PLAN and Caml are supported by Alien, a layered architecture for loading code. SwitchWare also provides a set of basic services for creating useful protocols. PLAN offers type safety, and any program is guaranteed to terminate. Both these characteristics solve some security and resource problems. In SwitchWare, the first use of an active packet injects the packet into the network, and the SwitchWare nodes execute the code in each packet along its delivery path. The mobile code controls the delivery path itself; language constructs support remote execution at arbitrary and neighbor nodes. SwitchWare also provides for extensions to the resident code base, which it loads explicitly onto each network processing element that will need it—all separate from data delivery. Extensions are subject to more thorough security checks3 than active packets, and thus may be more trustworthy.

Netscript Columbia University researchers are using the Netscript scripting language to compose basic services into more complex ones. Using Netscript interpreters as the runtime environment, programmers can create a dataflow mesh of processes on select network nodes with explicit input and output ports. The programming language is implemented in Java, and the dataflow abstractions are mapped to Java classes. The dataflow mesh becomes a network service that is applied to select data packets within the network. Within the runtime environment are primitives to control the instantiation of services on remote nodes. The Netscript toolkit and runtime environment are being used to demonstrate dynamic firewall creation and specialized routing functions.

Liane Georgia Tech’s Liane attempts to construct dynamic, trustworthy services from reliable base services. It is not tied to a particular language, although its prototype

NODE OPERATING SYSTEM

Active networks rely on the ability to add programs easily to the networking infrastructure, so the choice of the EE’s programming language and runtime environment is critical.

The NodeOS interface defines four primary abstractions: thread pools, memory pools, channels, and flows. The first three encapsulate a system’s three types of resources: computation, storage, and communication. The fourth is used to aggregate control and scheduling of the other three in a form that more closely resembles network application requirements. The NodeOS interface is currently being implemented in the Scout operating system4 and in the Amp, an exokernel library operating system.5 Other implementations are planned.

Threads and memory There is nothing unusual about the use of threads or memory in the NodeOS interface, except as related to flows. Each flow contains a single-thread pool that is initialized when the flow is created. To create a thread pool, implementers must specify • • • •

the maximum number of threads in the pool, the rate at which cycles can be consumed, the total cycles that can be consumed, and a scheduler object that specifies how the threads are scheduled for execution.

From the interface’s view, the thread pool exists primarily for accounting. Whether or not a NodeOS preallocates the specified number of threads is an implementation issue. Any thread running on behalf of the thread pool, no matter how it is implemented, will be charged to the pool. Each flow also contains a single memory pool that is initialized to contain pages shared by its parent when the flow was created. A thread running in the flow can then map virtual memory regions into the pool, unmap regions out of the pool, and control various attributes of these virtual memory regions. Because many EEs will not want to manage virtual memory directly, the NodeOS should eventually define a library that provides portable facilities for manipulating virtual memory. This would be useful to buffer packets, for example, or reduce the cost of protection boundary crossings among the NodeOS, EEs, and applications. April 1999

35

.

Channels

Like users of traditional networks, active network users are concerned with the authenticity, integrity, and confidentiality of the data going through the network.

Flows create channels to send, receive, and forward packets. Some channels are anchored in an EE, in that they send packets only between the EE and the underlying communication substrate. Anchored channels are further characterized as being either incoming or outgoing. Other channels are cut-through, meaning that they forward packets through the active node— from an input device to an output device—without an EE intercepting them. When creating an input channel, the flow must specify which arriving packets are to be delivered on this channel and create a buffer pool to queue packets waiting to be processed by that channel. When creating an output channel, the flow must specify how much link bandwidth (bits per second) the channel is guaranteed. Cut-through channels both receive and transmit packets, so they must specify a demultiplexing key, a buffer pool, and the link bandwidth. It is helpful, but not mandatory, to define channels as a series of protocol modules, which implement some well-defined primitive communication service. Protocol modules are advantageous because designers can stack them to build more complex communication services, essentially extending the channel services. The EEs must be able to name the protocol stack that implements a channel. For incoming and outgoing channels, this means the EE must provide enough information for the NodeOS to classify incoming packets and demultiplex them to the appropriate channel. Much of this demultiplexing information will be implied by the path name and the addresses passed as attributes when the channel is created. There are two complications to providing information, however. The first is that the EE may want to segregate different data streams onto different channels. The second is that cut-through channels sometimes want to capture packets with a far richer demultiplexing key than is implied by the protocol stack that implements the channel. Fortunately, cut-through channels can be created as new channels or as replacements for a pair of incoming and outgoing channels.

Flows The flow is the primary abstraction for accounting, admission control, and aggregate scheduling in the system. System resources, such as CPU cycles, memory, and network bandwidth are allocated to particular flows. A flow typically contains an incoming and an outgoing channel, a memory pool, and a thread pool. Active packets arrive on the incoming channel, are processed by the EE using threads and memory allocated to the flow, and then transmitted on the outgoing channel. Channels consume not only network bandwidth, 36

Computer

but also CPU cycles and memory buffers. The threads that shepherd messages across the flow’s channels come from the flow’s thread pool, and the cycles they consume are charged to that pool. Similarly, the I/O buffers used to queue messages on a flow’s channels are allocated from (and charged to) the flow’s memory pool. A flow might also include a cut-through channel. In such a scenario, control packets could be received on the incoming channel, processed by the EE, and sent on the outgoing channel, while the cut-through channel forwards data packets. Cycles and memory used by the cut-through channel would be charged to the flow’s thread and memory pool. Flows can also contain subflows, resulting in a flow hierarchy: The root flow corresponds to the NodeOS, the flows at the first level correspond to the EEs, and the flows at the lower levels correspond to channels within each EE. This hierarchy provides a flexible model for resource accountability, which can support active network applications that are arbitrarily complex.

SECURITY ISSUES Like users of traditional networks, active network users are concerned with the authenticity, integrity, and confidentiality of the data going through the network. However, traditional networks are concerned only with possible damage to user data and end nodes. Active networks share these concerns but must also consider possible damage as the active packet moves into each node and EE. Active nodes could be harmed by active code, either because the code modifies the node’s state or because it drains resources (essentially launching a denial-of-service attack). Thus, enforcing protections at end nodes is not sufficient for active networks. Securing an active network means that protection mechanisms must move into each node and each EE. Protecting the network as a whole is only possible by building a common protection mechanism into the design of individual nodes and EEs. For example, some EEs, like PLAN, have defined a network resource that is consumed as a packet traverses the node. The resource is designed to keep a packet from placing an infinite demand on the network. An active node or EE, on the other hand, can enforce its own individual security; no common protection mechanism is mandated. Active nodes protect themselves by ensuring that activity within the node is safe and properly authorized. A variety of techniques are available to ensure safe execution of active code, such as type-safe languages, proof-carrying code, or software fault isolation. However, authorization for activities will vary with the principal and the security policy. Therefore, ensuring that activities are properly authorized is not amenable to such all-or-nothing techniques. Authorization is an overriding issue in active networks.

.

A significant challenge in protecting active networks is to create enough uniformity of security requirements and features among diverse networks, nodes, and EEs that application developers can comply with the requirements and effectively use the security features of the active network, while still maintaining the flexibility to customize security services.

Authorization Authorization is the fundamental security service used to protect either the active node or the EE. Authorization is expressed as permission to access parts of the node’s or EE’s state—to protect either its confidentiality or its content. Authorization is also expressed as bounds on the use of resources and services. The fundamental motivation for such bounds is to prevent denial-of-service attacks against the node, and thereby indirectly against the network The scale of active networks creates difficulties in providing the authorization mechanism. The mechanism must be suitable for anything from an enterprise network governed by a single administration with a homogeneous model and policy to a wide area network that comprises a multitude of authorization models and policies. Thus, authorization cannot always be expressed in terms of unique principals and single services or resources. Instead, those specifying a security policy define aggregates of principals and identify them by some security attributes. The policy relates the security attributes to access authorizations. Aggregates could be roles, groups, labels, domains, types, and so on. The security policy could further abstract authorization by aggregating services and resources in the same way. Thus, authorization would be decided using the requesting principal’s security attribute along with the service’s or resource’s security attributes. Clearly, validating the source authenticity and integrity of the active code is crucial in ensuring proper authorization. If the source can be spoofed, then the node or EE can be deceived into taking harmful actions. If the active code can be changed, it can be made to perform actions other than those intended, possibly inducing harm.

Policy enforcement The NodeOS enforces a policy for authorization to the NodeOS services and resources (flows, memory pools, thread pools, and channels). Because the flows request memory, threads, and channels in this architecture, the NodeOS must associate a principal with each flow as it is created. The authorization of that principal will then decide the accesses and use limits of a particular flow. There need not be a separate principal for each flow; one principal may authorize many flows and subflows.

It must be possible for properly authorized Securing an active principals to modify the policy dynamically. network means This requires separating the policy storage and enforcement. In the proposed general architecthat protection ture, policy is stored in a database, and policy mechanisms must enforcement is a separate engine within the move into each node NodeOS. and each EE. This in The enforcement engine refers to the policy database to decide each controlled access. Thus, turn means building when the policy database changes, the correprotection into sponding policy enforcement changes at the same the design. time. Each EE has its own protection policy. For example, if an EE offers specialized routing services and a routing table, its policy governs who can use or update the table and who can use the routing services. This is straightforward enough, but a complication arises because each EE service or resource is composed from services and resources the NodeOS provides. The access to those NodeOS-level objects must be decided in accordance with NodeOS policy. The EE and NodeOS policies may conflict. For example, there is no guarantee that the NodeOS policy for accessing the memory pool that underlies the routing table meets the EE’s policy. The EE policy is allowed to be stronger than the NodeOS policy; it may not circumvent the NodeOS policy. The responsibility for policy enforcement can be divided between the EE and the NodeOS in several ways. One is to have the EE choose to defer all authorization decisions to the NodeOS. The EE would then have to communicate its access policy to the NodeOS, and the NodeOS would have to be able to partition the resources it has associated with the EE according to the EE’s policy. Another approach is to have the EE enforce its own policy, with its own policy database and its own enforcement engine. Indeed, it would be hard for the NodeOS to keep the EE from performing its own authorization checks for its own service or resource. When the EE grants access to a service or resource, it will attempt to access the NodeOS services and resources underlying its own services and resources. The NodeOS can then enforce its access policy. When using NodeOS services and resources, the EE may or may not indicate the principal associated with the active code. If it doesn’t, the NodeOS will decide authorization on the basis of the principal associated with the EE. The EE would then be accountable for that use of NodeOS resources. Again, the NodeOS must trust that the EE will manage the resources in accordance with the NodeOS policy, so the NodeOS must communicate its policy to the EE as an initial policy database. The active network research efforts have not exhibited a consensus as to the proper division of responApril 1999

37

.

Figure 2. Using protocol boosters to enhance a subnet. Here, a booster/ debooster pair on routers augment a network—for example, with an error-correcting code. The augmenting is transparent to the end-toend protocol.

Host A

Host B

Application

Application

Router R

Booster

Debooster

Boosted link or subnet

sibility for policy enforcement between the NodeOS and the EE.

Identifying principals’ authorizations Once authorization and policy enforcement are decided, the problem becomes how to distribute the representation of principals and their authorizations. An enterprise network in a trusted environment may be able to store identifiers and security attributes directly in the packet. The meaning of these identifiers and the policy governing them would be known everywhere and the source and integrity of the packets would be trusted. For example, NFS packets carry the Unix user ID and user’s group ID used in checking file access between the file server and the client. The user IDs and group IDs are trusted to have the same semantics (represent the same principal and authorization), throughout the NFS network. In more widespread and heterogeneous environments, however, users cannot presume that the identification of principals and their authorizations can be trusted. Instead, an authority must attest to the authorizations granted to a principal and that attestation must be bound to the packet. Authorities and authorizations. The most popular way to bind the principal and authorizations to the packet is through cryptography. Normally, the principal is associated with a key that is used to provide it some cryptographic service. An authority cryptographically binds the principal’s keying material and some designation of its authorization into a certificate or credential. The cryptographic binding, which could be the authority’s digital signature of the contents, is itself carried in the credential. Authorities also use credentials to attest to the binding of digital signature keys to other authorities. Packet/credential association. The next step in 38

Computer

binding the principal and authorization to the packet is to bind the credential to the packet. This keeps other principals from using that credential. The cryptographic binding typically also provides assurance of the packet’s integrity and source. When all active nodes can be trusted, the cryptographic binding can use low-cost symmetric algorithms employing shared keys. This places a great deal of trust in all the active nodes. Another approach is to digitally sign the packet and credential with the key represented in the credential. This approach protects the packet source and integrity even when it is not safe to implicitly trust every active node. One active packet can contain the credentials of multiple principals. The authorizations associated with the source of the packet are fundamental to most security policies, so the source’s credentials are commonly included in the packet. The authorization of the active code’s author or the relevant attributes of the code, such as the proof for proof-carrying code, might be part of some policies. In those cases, the packet must carry author and code credentials as well.

APPLICATIONS Applications of active networks continue to grow with examples ranging from reliable multicast to Internet management and congestion control.

Active Reliable Multicast MIT’s Active Reliable Multicast (ARM),6 developed by Li wei Lehman and colleagues, embeds active routers in a multicast tree. The routers in ARM handle loss recovery much more efficiently than conventional routers. The improved loss recovery comes from three sources:

.

• Duplicate NACK suppression, which inhibits NACK implosion. • Best-effort caching of multicast data in case of retransmission, which is required for recovery. • Local multicasts in retransmission, which reduces the bandwidth required to retransmit the data. In ARM, all nodes need not be active, and no particular routers are required to recover losses. The result is a robust, scalable system for reliable multicast that shows significant benefits, including recovery latency, scalability, and reduced bandwidth for recovery. These benefits are particularly dramatic when ARM is compared with Scalable Reliable Multicast (SRM).7

IP

IP router/ forwarder

LAN IP

Active Congestion Control Because of its flexibility, active networking offers considerable promise for improving congestion control. This goal was an objective of Ted Faber of USC/ISI’s Active Congestion Control (ACC) project.9 ACC exploits state and programmability to reduce the delay when congestion is signaled to sending systems. ACC packets contain 4- to 8-byte characterizations of the state of the endpoint’s congestion feedback, perhaps a congestion window that the sender adjusts. When congestion occurs at a router—in particular, when a packet is dropped—the router • determines the congestion window size, • deletes packets that would not be sent with this new window size, and • informs the sender of the new window size. Nodes beyond the congestion point see traffic that looks as if the sender had reacted instantly. Thus, ACC is particularly powerful in network contexts that have large (bandwidth × delay) products. Faber evaluated it by applying the basic model to TCP/IP congestion control, assuming that ACC was embedded in IP routers. Simulations showed up to an 18 percent improvement in throughput when traffic is bursty.

updat e

Active router controller

Active packets IP

IP IP router/ forwarder

Protocol boosters Protocol boosters8 are protocol elements that can be inserted into and removed from existing protocols. The idea is to build protocols dynamically, which can aid both protocol performance and the rate at which the network technology evolves (because specialized protocols can be developed rapidly). Figure 2 shows how protocol boosters enhance a subnet. Protocol boosters have been developed for error and congestion control, and active networks clearly provide the ideal infrastructure for implementing them.

Route

IP

IP router/ forwarder

IP

IP

IP

Auctions Online auction servers collect bids from clients for items and provide the item’s current price on request. Given the short time within which servers can operate and the possible long delays in packet arrival time, prices lower than the current bid can arrive. Depending on the scale of the auction, these irrelevant bids can generate a considerable server load. The active protocol suggested by Ulana Legedza and colleagues of MIT10 deletes low bids with active elements embedded in the network that connects the client and server. When the server becomes busy, it enables these elements and periodically updates their notion of the current price. In dropping low bids, they thus serve as proxies for the server in its attempts to focus on relevant bids.

Figure 3. An active router controller (ARC) managing a set of router/ forwarders. Active elements adjust forwarding tables, including directions to forward active packets to active elements.

Internet enhancement One way to rapidly deploy active networking is to enhance the existing Internet. At the University of Pennsylvania, enhancements take the form of active router control, or ARC (http:// www.cis.upenn.edu/~switchware). In this approach, active elements serve as an enhanced programmable management and measurement system for the Internet. Figure 3 shows ARC applied to a set of routers configured as a logical “router in a room” (a set of interconnected routers that appear to be a single logical router). Designers can replicate the basic active blob (large oval in the center of the figure) throughout an Internet network, with the active elements using the managed Internet routes as link layers. A set of active nodes can be grafted into a larger collection of routers and forwarders to create an active Internet. April 1999

39

.

Active Network Encapsulation Protocol 0

8 Version

16

24

Flags

Type ID

ANEP header length

ANEP packet length Options Payload

Figure 4. Format of the Active Network Encapsulation Protocol (ANEP) header. The header allows execution environments (EEs) to be selected arbitrarily and provides a way to pass parameters that aid EEs in interpreting packets.

The near-term interoperability solution is to use an encapsulation protocol for active packets. In ANEP terminology, a packet consists of an ANEP header and a payload. An active node is a network element that can evaluate active packets. Figure 4 shows the ANEP packet header format. Much of the information is organized as triples of , or TLVs. The basic header is the first two words of the ANEP header. Figure 5 illustrates how the active packets would be demultiplexed to the appropriate EE. The active network community devised ANEP as a way to bootstrap itself with existing infrastructure. As such, we do not see it as an end product, but rather as a stepping-stone to building prototypes that will allow practical interoperability.

ABONE PLAN

Netscript Active packets

ANTS

Demultiplex encapsulated active packets

ANEP port UDP protocol

IP over subnets

Packet Frame

Figure 5. How packets are demultiplexed to execution environments (EEs) through ANEP using the PLAN scripting language. Packets arrive on a network interface, are demultiplexed to the IP, UDP, and ANEP stacks, and are finally forwarded to the correct EE for processing.

INTEROPERABILITY Two efforts are ongoing to support the interoperation of EEs. The Active Network Encapsulation Protocol, or ANEP (http://www.cis.upenn.edu/ ~switchware/ANEP), aims to accelerate interoperability experiments and to use existing infrastructures in various applications. The Active Network Backbone (ABONE)11 is being used to test EEs and implement applications that use them. 40

Computer

ABONE is one such prototype. Its goal is to have a 1,000+ node network. At present, its 100 nodes are Unix machines operating the anetd program, which manages active network nodes, including initiating EEs. At present, the ABONE is flat, although its developers have proposed a hierarchy, with locally administered hosts at the edges of the network and intermediate routers moving toward the root. The hierarchy may accelerate progress toward the goal of a 1,000+ node goal. The ABONE supports ANTS, Netscript, and PLAN/Alien. Over the next several years, active networking research as a whole will be deploying many other applications over the ABONE to develop an understanding of robustness and scalability, evaluate security and usability, and demonstrate high performance. During this time, we can expect to winnow EEs down to a very few and begin to develop new features and services for those remaining. ctive networks are a major shift in paradigm for the networking world. This new paradigm permits packets to carry their own network service and to compute that service within the infrastructure. Research in this area has been energetic and has begun to produce exciting results. We believe the active-node architecture we have proposed will productively channel development of interoperable components. The issues in building a secure network have been analyzed, and solutions are being explored. Both interesting applications and execution environments of sufficient power to support interesting applications have been implemented and are in use in the ABONE. The field is maturing quickly and promises soon to bring the benefits of the unique features of active networks to the networking world. ❖

A

.

Acknowledgments Work at the University of Pennsylvania was supported by the US Defense Advanced Research Projects Agency under contract N66001-96-C-852. Work at TIS Labs was supported by the US Defense Advanced Research Projects Agency under contract N66001-97C-8514.

References 1. D.L. Tennenhouse et al., “A Survey of Active Network Research,” IEEE Communications, Jan. 1997, pp. 80-86. 2. Active Networks Working Group, Architectural Framework for Active Networks, July 1998, http://www.cc. gatech.edu/projects/canes. 3. D.S. Alexander et al., “A Secure Active Network Environment Architecture: Realization in SwitchWare,” IEEE Network, May/June 1998, pp. 37-45. 4. D. Mosberger and L. Peterson, “Making Paths Explicit in the Scout Operating System,” Proc. Second Symp. Operating System Design and Implementation, 1996, pp. 153-167. 5. F. Kaashoek et al., “Application Performance and Flexibility on Exokernel Systems,” Proc. 16th Symp. Operating Systems Principles, ACM Press, New York, 1997, pp. 52-65. 6. L. Lehman, S.J. Garland, and D.L. Tennenhouse, “Active Reliable Multicast,” Proc. INFOCOM 98, IEEE CS Press, Los Alamitos, Calif., 1998, pp. 581-589. 7. S. Floyd et al., “A Reliable Multicast Framework for Light-Weight Sessions and Application-Level Framing,” Proc. SIGCOMM 95, ACM Press, New York, 1995, pp. 342-356. 8. D.C. Feldmeier et al., “Protocol Boosters,” IEEE J. Selected Areas in Comm., Apr. 1998, pp. 437-444. 9. T. Faber, “ACC: Using Active Networking to Enhance Feedback Congestion Control Mechanisms,” IEEE Network, May/June 1998, pp. 61-65. 10. U. Legedza, D.J. Wetherall, and J. Guttag, “Improving the Performance of Distributed Applications Using Active Networks,” Proc. INFOCOM 98, IEEE CS Press, Los Alamitos, Calif., 1998, pp. 590-599.

Jonathan M. Smith is an associate professor of computer science at the University of Pennsylvania. His research interests include design, implementation, and experimental evaluation of advanced computer communications systems and security in the context of these systems. He has a PhD in computer science from Columbia University and is a member of the ACM and a senior member of the IEEE.

Kenneth L. Calvert is an associate professor of computer science at the University of Kentucky, where his research deals with the design and implementation of high-performance communication protocols and services, with an emphasis on architectures that reduce the cost of deploying services to support new applications. His current research interests include active networks, development of a compositional framework for end-to-end protocol functions, and network security. Calvert received a PhD from the University of Texas at Austin.

Sandra L. Murphy is a principal computer scientist for TIS Labs at Network Associates. Her research interests include the design and analysis of security in distributed systems and network protocols. She received an MS in computer science and applications from Virginia Tech and a PhD in computer science from the University of Maryland.

Hilarie K. Orman is a program manager in the Information Technology Office at DARPA, where she is responsible for active networking. She has worked in computer security, networking, and operating systems for the past 20 years. Her current research interests center on architectures for combining major system features into large systems with high performance and ways to use logic to provide increased program correctness assurance and combinatorics. She received a BS in mathematics from MIT and is doing graduate computer science coursework at the University of Southern California, Los Angeles.

Larry L. Peterson is a professor of computer science at Princeton University, where his primary research interests are in end-to-end issues related to computer networks. He has been part of designing and implementing the X-kernel and Scout operating systems and is a coauthor of Computer Networks: A Systems Approach (Morgan Kaufmann, 1997). Peterson is the editor-in-chief of ACM Transactions on Computer Systems and a member of the Internet’s End-to-End research group.

Contact Smith at [email protected]. April 1999

41