ANTS: A toolkit for Building and Dynamically Deploying Protocols
A Critical Examination
By Chris McAnally & Manu Mittal
Due to the importance of services in providing Internet users with required performance, recent research activities have centered on providing more rapid deployment of protocols and services. Rather than enhance static routers with functionality in an ad hoc fashion, one thread of research has focused on replacing static routing with active nodes to facilitate dynamic deployment and intelligent routing. This paper deals with one such architecture the Active Network Transport System developed at MIT. In this paper we will take a critical view of the system examining its strengths and weaknesses.
The ANTS Protocol Architecture:
ANTS is an active network approach and thus rather than routing statically applications can place routines that are executed at the routers to forward messages as they arrive. The protocols pushed through the network can execute traditional routing protocols or more exotic routines. The designers of ANTS set three goals for the system:
· Support for a variety of protocols
· Support the construction of new protocols and
· Support the deployment of the protocols
To do this the designers replaced the concept of packets with capsules using part of the payload section of a normal IP Packet for a capsule header. They also replaced routers and end nodes with active nodes that can execute capsule protocols and maintain state information in soft-state storage. They also developed a system to dynamically transfer protocols.
Capsules contain a header with the following fields:
The version field contains the ANT system version # of the originating node. Thus outdated active nodes can forward the capsule as an IP router. The previous node field contains the address of the previous active node to process the capsule. This is used for the code distribution system. The type field of a data capsule is a hash value of the routing protocol the capsule requires (an MD5 digest). This allows protocols to be found rapidly and limits protocol spoofing.
This format does prevent protocol spoofing and allows more fields for the system and it’s protocols to use, but at the expense of payload space. Because payload space becomes larger to accommodate the capsule header, the chance of packet fragmentation increases, and fragmented capsules may not maintain their capsule headers losing the active quality of their routing. To reduce this occurrence more numerous and smaller capsules could be used, but this degrades performance. Further, except for the digest field, there is little to no protection of a capsule’s header from non-active routers, except for the type field. Thus incorrect routing can occur.
The problem with letting user-developed programs execute locally remains the most pressing difficulty with active networks and the designers of ANTS decided to solve the problem by limiting the protocol’s access to resources and capsule fields, and they provided a safe set of primitives for applications to use in their routines. These routines fall into three categories:
· Environmental calls for local state information such as addresses and forwarding statistics.
· Storage calls to change store and access items cached by the application.
· Control Operations to send capsules along links
other categories could be added (encryption, scheduling, etc.) but these have yet to be developed.
The goal of ANTS remains to provide quick deployment of new protocols where needed, but by restricting the protocols to a limited set of primitives we limit the protocols flexibility. For example suppose we have a protocol that compresses capsules going through links that lack the bandwidth to accommodate larger capsules. The new protocol cannot be deployed until new primitives for compression are installed, or the protocol incorporates the compression routine into a local routine, increasing the protocol size and transfer time. So again we are left with a situation of waiting for router upgrades to increase performance. Still this restricted environment in ANTS provides a great deal of security in that it prevents malicious routers from inserting dangerous protocols and yet provides the flexibility to develop most legitimate routines. However as we shall see later, the protocol distribution scheme contains security weaknesses.
The protocol distribution system retains both simplicity and robustness in the face of shifting network topologies. When an active node receives a capsule containing an unrecognized protocol it uses the previous node field to request the protocol on the basis that the previous hop should still retain the protocol in soft-state. Meanwhile the capsules with the unknown type field are put to sleep in cache. When a node receives such a request, it forwards the protocol to the requesting node. After the protocol has arrived any sleeping capsules belonging to the protocol are woken and processed.
While this remains a simple system and robust in the face of shifting topologies, the scheme remains open to a denial of service attack (DoS). Suppose a hostile router Manu decided to mount a DoS attack on the polite and respectable router Chris. Manu could do this by sending a string of capsules at Chris with different Type fields and ignore all requests for the protocols. Chris would begin storing all the capsules in soft-state and sending requests to Manu. Eventually Chris’ soft state would fill up and his performance would degrade to the point where he became useless as an active node. Such a weakness remains undressed in this paper. However the paper and prototype remain proof-of-concept systems and security currently takes a back seat to functionality. Still the later security is added to a system the more overhead and awkwardness it tends to lend to the final product.
There also remains a final open question to the future of ANTS and other active networks, “Can we do this in hardware?[1]” With current technology in programmable chips such a hardware system appears unlikely, but future developments could allow active networks to take place in hardware. Currently all active networks remain prototypes implemented in software as user-level applications and endure all the performance degradation that implies. If fast hardware systems emerge, active networks may become the wave of the future, and ANTS a pioneer in the field.
III. Programming with ANTS
The two simple protocols the authors introduce to demonstrate how they intend their architecture to be used are multicast and mobility services into an ANTS network that initially lacks them. The authors argue that in developing these protocols their intent was not to present new and better solution to these problems but to show that ANTS facilitates protocol construction and deployment.
A. Mobile Hosts
Mobility services involve two kinds of capsules. The first one is sent by the mobile host to register forwarding information while its roaming and the other one is used to other hosts (sources) to send messages to the mobile host while its roaming. The concept of Home Agent (Used to intercept messages at the base location of the mobile host) and Foreign Agent (Used as a “care of” address to reach the mobile host while its away from its base) from Mobile IP is still preserved here.
Mobile Host periodically sends “Register” capsules to their Home agent via the Foreign Agent and this capsule updates the forwarding address cached at the home and the foreign agent. At the Home Agent when it receives capsules marked for the mobile host it forwards them to the Foreign Agent. Foreign Agent maintains a pointer to the Mobile Host and when it receives a capsule intended for the host it simply forwards them.
The advantage with this approach is that, not only it is simple but it provides the essential feature of mobility: hosts may be reached as they move without introducing another layer of addressing. Also the fact that, it is not necessary to confine the forwarding information to the edges of the network, potentially any node can be programmed to act like a Home/Foreign Agent. Although ANTS approach provides essential features of mobility and some more flexibility it doesn’t really offer any added advantage over the existing Mobile IP mode.
B. Multicasting
Multicasting also involves two kinds of capsules: Subscriber capsules (sent by applications that wish to receive messages sent by a particular sender) and Multicast Data capsules (sender sends these to multicast to the group which simply route themselves along the distribution tree). The subscribe program looks up the forwarding record for the group in the node cache of the node or creates a new one if none is found. To distinguish between different multicast session in the cache, the record is stored in a key, which is a combination of the group and the sender’s address. Once a forwarding record is located, a “reverse” pointer in the direction of the subscriber is merged into the forwarding record. Leaf subscribers have empty forwarding lists. Multicast data program makes use of the forwarding records found at the node, sending copies along every indicated “reverse” path. At the end systems, where there is an empty forwarding record, the capsule is delivered to the application.
The advantage with ANTS multicasting is that special multicasting routers are not needed; this scheme is localized to the nodes using this protocol. Also intelligence might be built into the nodes such that for instance, if a high definition multimedia broadcast is taking place, then the network can detect a bottleneck in between the source and the destinations and can thus adjust the transmission speed to match the minimum speed link in the distribution tree.
IV. Prototype Implementation
The current implementation is written in JAVA because of its support for safety and mobility (through bytecode and verification) and the likely emergence of higher performance compilers and runtimes. Classes involved are:
Node Class: which represents the runtime of a single network node, including its code and soft storage caches and code distribution protocol. It provides a set of node primitives that can be invoked by capsule programs. These primitives allow access to the state at the node and enforce various security constraints.
Channel Class: provides the interface to the link layer, connecting nodes via point-to-point or shared medium channels. At present either Ethernet or UDP “tunnels” may be used to transfer capsules.
Capsule Class: is a virtual class that can be specialized to create the capsule types that comprise protocols.
Application class: is a container for the end system processing that provides a small API for registering protocols, injecting capsules into the network and receiving capsules from the network.
Measurement and Evaluation
The authors point out that though their prototype implementation was not built for performance, they did run some performance tests. All test reported were performed on a Sun Ultrasparc 1 (167Mhz) running Solaris 2.5 and connected with 100 Mbps Ethernet. Some of the assumptions/details were
· Minimum size capsules were used
· Assumed there were no non-active nodes in the network
· Assumed no security issues/polices in the network
From the above table the Latency and the throughput improved as new JAVA and JIT (Just-in-time) compilers were used. This performance was compared with C user lever relay (simple 100 lines of code that receives and forwards packets without processing them). According to the authors ANTS achieves most of the throughput of a JAVA relay, adding approximately 35 percent overhead for 512-byte capsules, of which only five percent is fundamental. They also add that absolute system performance is thus limited by both user-level and JAVA based operations, neither of which ANTS require. Thus, they could build much faster ANTS implementations without resorting to custom hardware and operating system support. The latency of capsule forwarding and code loading was also found to be reasonable by the authors, according to whom ANTS adds a constant overhead of approximately 400ms per capsule to the latency of the C relay. This means that there are no hidden data-dependent costs in implementing the forwarding model [1].
V. Conclusion
In conclusion, ANTS is an architecture that supports the construction and dynamic deployment of network protocols. In contrast to standardization based approach ANTS
· Allows new protocols to be automatically, dynamically and rapidly deployed to exact those nodes where needed.
· Required no advanced consensus about the kinds or definitions of the protocols.
· Can provide means for automatically upgrading network protocols; can thus remove barriers to innovation, stimulate experimentation, and hasten the arrival of new functionality.
1
[1] Suggested by Dr. Ravi Prakash