Return to active network (idea)

The current [network] infrastructure is essentially static. Although [active code] may be sent from [server|servers] to [client|clients] (such as web [applet|applets]) and from clients to servers (such as OO [database] queries), internal network nodes (such as [router|routers]) [Packet switching|passively switch packets]. This infrastructure is standardized using [monolithic] protocols such as [IP]. Adding functionality to these core network protocols is performed by adding complexity to the protocols through a lengthy process of [prototyping], [standardizing], [developing], and [deploying]. The result is that although the core protocols become [bloated], they are still incapable of incorporating all of the functionality within the network (such as [convergecast|convergecasts] or data [caching]) that applications may desire. Prior to [active networks], the only solution other than adapting [protocols] has been to place specialized servers within the network to perform tasks such as [multicast|multicast tunneling], [web caching], and [network monitoring].

By allowing computation to happen within the network as data passes through nodes, [active networks]1 provide a different solution to these problems. Rather than standardizing on a protocol that describes how [node]s should forward packets, an active network [standardizes] on an [execution environment] that is provided to the [capsules] that pass through network nodes. A [capsule] contains both data and a reference to code to execute at each node the capsule passes through. In a traditional network, routers look at [IP packet headers|packet headers] and decide where to forward the packets. In an active network, [router|routers] execute the code referred to by capsules, and this code tells the router where to forward the capsule.

This active networking approach would allow network protocols to evolve much more rapidly. In an active network, protocols can be written and immediately deployed without any need for an extensive standardization process. Because new protocols can be written (or existing protocols can be modified) to provide exactly the functionality that is needed by applications, the large [bloat] associated with monolithic protocols can be avoided. Active networks take the [end-to-end model|end-to-end argument]2 to the extreme by allowing applications and protocols to do exactly what they need to do exactly where they need to do it. Utilizing active networks may make it much easier to implement and deploy new protocols for tasks such as multicasting, convergecasting, data caching, network monitoring, and dynamic data distribution.

Two somewhat different approaches have been taken to active networking: the [capsule-based] (or [integrated]) approach, and the [programmable switch] (or [discrete]) approach. The [integrated approach] revolves around programming in the [messenger paradigm]3 --- capsules containing both [code] and [data] move around the network and are executed on the nodes they pass through. In the [discrete approach], functionality can be added to nodes [out-of-band] from the packets being processed by the node.


Adapted from: [nygren|Erik L. Nygren], [Stephen J. Garland], and [M. Frans Kaashoek], [PAN: A High-Performance Active Network Node Supporting Multiple Mobile Code Systems], In the proceedings of [IEEE] [OpenArch] 1999, New York, New York, pp. 78-89, March 1999.

1[David L. Tennenhouse] and [David J. Wetherall], "[Towards an Active Network Architecture]", Computer Communication Review, vol. 26, no. 2, pp. 5 18, April 1996.

2[Jerome H. Saltzer], [David P. Reed], and [David Clark|David D. Clark], [End-to-end Arguments in System Design], ACM Transactions on Computer Systems,vol. 2, no. 2, pp. 277 286, November 1984.

3Giovanna DiMarzo, Murhimanya Muhugusa, Christian Tschudin, and Jurgen Harms, "[The Messenger Paradigm and its Implications on Distributed Systems], in Proceedings of the ICC 95 Workshop on Intelligent Computer Communication, June 1995, pp. 79 94.

Existing:


Non-Existing: