In computer networks, switching elements are categorized based on their functionality and position within a network. Switches are found at the link, network and application layer of the OSI protocol stack. Currently deployed switches sometimes provide capabilities for non-switching functionality [2], but in most current implementations, this capability is fixed and limited. By contrast, active networks are networks with dynamic user-programmable switches called active nodes. Active nodes enable the user to create required functionality ``on the fly''. This functionality can range from advanced switching functions such as content specific redirection of data [4] to non-switching functions such as data transformation [2] and error correction.
While active networks hold promise to make the network infrastructure more flexible, there is considerable debate as to whether active network technologies are deployable in practice. In addition to security concerns, there are a variety of forces that will cause changes in the deployability of services at various locations in the network architecture. These forces include, but are not limited to (a) changes in router hardware, (b) changes in Internet protocols (e.g. deployment of IPv6, MPLS, IPsec, mobile IP), (c) changes in Internet traffic volume and distribution, (d) increased diversity of endpoint computation, storage, and (e) last-hop bitrate (e.g. mobile vs. hard-wired, supercomputer vs. portable battery-limited devices).
When considering router services above and beyond simple packet-forwarding, we suggest that three metrics have the most impact on deployability, namely: computational requirements, storage and network bandwidth consumption. These metrics are measures of resource requirements.
Our work involves the development of a framework that is aimed at allowing incremental deployment of non-switching functions in routers. Our framework provides:
By basing our deployment framework on resource requirements, we seek to bridge the gap between the practical view that ``routers should just route'',and the active networks view that ``each router is a Turing machine''. Our goal is to provide a roadmap for the rapid introduction of innovative network services into common practice.
There are atleast two approaches one can take to arrive at a classification of services. The bottom-up approach involves first enumerating services that a router can provide, based on a list of known applications. These services are then grouped according to their similarity in resource requirements.
By contrast, the top-down approach starts with the identification of applications that can use router services. We start with a single application and determine what kind of router services would be beneficial to that application. We then create a class of services that includes services that can completely satisfy the requirements of that application and label this class, say,C0. We then consider another application and see if its requirements can be satisfied by the services whose resource requirements are similar to those in class C0. If they are then we add the services to C0, else we create another class, C1 containing the services that satisfy the requirements of the application under consideration. Next, we repeat the process with another application this time comparing its services to C0 and C1 and creating additional classes as necessary. We finish when we have exhausted our list of applications.
Below is the result of an application of the top-down approach to a few applications. The results in five classes of router assist services with a higher level number indicating greater resource requirement for that level of service.
| Level | Application | Service |
| 0 | Telnet | Unicast forwarding |
| 1 | Audio Broadcast, FTP Client | Multicast forwarding, Anycast forwarding |
| 2 | Shared Whiteboard, RMFT, Security,Network management | Feedback redirection, Feedback aggregation, NAT, MIB agents |
| 3 | Firewalls, Multimedia | Forwarding after rule matching, Priority scheduling (QoS), Rule matching |
| 4 | Web browser | URL redirection |
There are also other metrics of classification which might or might not have a direct relation to the resource metrics (computation, storage and network). These metrics could be based on packet state or on the frequency of invocation of service (per session or per packet).
We also propose to investigate the theoretical basis of the classes we identify. An analytic model of the classification will help in extracting crucial features of each class and will aid in the development of a more robust and effective implementation framework. We envision a scheme by which we might characterize router services along the same lines that the Chomsky Hierarchy [3] is used to characterize classes of formal languages.
In addition to the development of a formal classification for router services, we propose to develop an implementation framework and open-source toolkit for the incremental deployment of router assist services in various classes.
Our initial approach has similarities to the Generic Router Assist (GRA) [1] work being undertaken by the Reliable Multicast Working Group of Internet Engineering Task Force. For example, both our work and that being developed as part of the GRA proposal create a signalling protocol for router assist services.
However, our work goes beyond that of the GRA approach in several respects. The GRA work of the IETF is based on a very conservative approach to providing only the most limited router-assist functions, since there is concern about whether such services are deployable on the scale of the ``big-I Internet.'' Our framework takes the approach that the conservative restrictions imposed by GRA represent only one class of potential router services; hence, our signalling protocol provides for other classes that relax the restrictive assumptions made by GRA.