1. PROTEAN: A Scalable Architecture for Active Networks
Scott Travis & Stan Komsky

2. Introduction What is an active network?
A network that allows users (ie. An application, ISP, or other organization) to change or program routers in a network to provide specialized functionality
Most researched approaches for active networks focus on router design and implementation rather than network-level design
The researched solution for these network-level problems is PROTEAN
PROgrammable TEchnology for Active Networks
Simulations and prototypes show that the PROTEAN solution manages scalability as well as providing many attractive features of active networks

3. Background
Traditional networks provide only best effort service as all the programmable functionality resides at the end hosts
Since active networks allows users to interact with the routers, per-user functionality can be achieved
Allows for things like specialized QoS routing, mobility support, scheduling, frame-based dropping, transcoding, compression and decompression, etc.
The PROTEAN solution allows for this functionality while still providing scalability, as the simulation results will show

4. Problem Several issues with implementation of active networks:
1. Where should the active routers be in the network?
Issue of scalability vs. flexibility
2. From 1, if not all the routers are active, how do you account for the state of the other routers?
Issue of active routers needing an idea of the state of links in the network
3. How do active routers discover and communicate with other active routers?
Issue of communication for services between active routers (ie. Compression at one router and decompression at another)
4. How do users discover the available active services?
Issue of users being able to use the available active network

5. Network Organization A) Provide UP at all routers in the network
User-programmability vs. Network-programmability
UP is allowing services for each user while NP allows for resource distribution between users
NP is generally implemented in routers by manufacturers
A) Provide UP at all routers in the network
Gives users complete flexibility over the network
Not practical due to security issues and extremely limited scalability
B) Provide UP only at edge routers (NP for core)
Edge routers already maintain some kind of state for users for things like QoS and traffic monitoring
More scalable than A, but UP services can only reside at the edges
Intelligent equivalent link state discovery could provide edge routers with the path characteristics between active routers
C) Do not provide UP in the network
Most scalable solution, but loses functionality
Some approaches provide for connected active servers to allow for some of the functionality of an active network, but this doesn’t really create an actual active network
PROTEAN chooses B as the most balanced option

6. Equivalent Link Abstraction
In order to detect and avoid bottlenecks in the flow path, edge routers must communicate some information to determine an “equivalent link” between the routers
Ex: With a video stream in a fully active network, the router directly upstream of the bottleneck would perform priority dropping to ensure service. With PROTEAN, the bottleneck is abstracted in the “equivalent link” and the priority dropping is then done at the edge routers
If an underlying network does not provide any equivalent link characteristics, they must be abstracted from available information

7. Equivalent Link Abstraction 2
Consider an active network with ingress and egress edge routers Ri and Re, respectively
Also, available rate estimate r(t), loss probability l(t), and delay estimate d(t) Ri Re
The path state is then abstracted every period of time (epoch) by:
Rate Adaptation:
r(t+1) = r(t) – B(t), where B(t) is the amount of congestion notification (indicated to Ri from either loss notification from Re or by explicit congestion notification)
r(t+1) = r(t) + A , where if there was no kind of congestion notification, the rate estimate is increased by an additive constant A
Loss Probability:
l(t+1) = k·l(t) + (1-k) ·max{0,1-a(t)/r(t)}, where k is a constant and a(t) is feedback from Re to Ri indicating the reception rate of packets
Delay Computation:
rtt = j·rtt + (1-j) ·rttcurrent , where rtt is the Round Trip Time and j is a constant
d(t) = rtt / 2 after the computation of rtt

8. Spine Network Interface
Spine structure is a “tree” which is made of nodes
The structure of the spine reflects the physical structure of the underlying layer
Each node has a name, and a leaf count
Each node knows the topology of all of its children, and its parent.

9. Spine Network Interface
The node contains 4 databases: router db, UNC db, service db, and service instance db
Three main operations:
Pull mode- client sends a query to a target server, and the server responds to the client with the results of the query processing
Push mode- client caches query response, server caches client’s query and sends update to client when there is an update that matches the client’s query
Server recognizes the location of the caches in order to optimize the push path

10. Spine Network Interface
It provides a framework for the discovery and dissemination of third party services
It provides a framework for the discovery, management, and communication of active routers
Query request and update state are based on soft state
The push path and pull path are optimized independently
The hierarchy of the spine is used to forward requests, nodes do not cache a superset of the cached information of their children.

11. Active Video Streaming Case Study
Compares Non-Active networks, End-Active Networks, Edge Active Networks, and Fully Active Networks when a video stream originates from the server
Frames are characterized as high priority, medium priority, and low priority
A CBR traffic Source is introduced between the 200 and 300ms points of the test that takes up half of the available capacity.

12. Active Video Streaming Case Study

13. Critique
The implementation of the PROTEAN active network may not address all of the security concerns network providers may have, but measures out of the scope of PROTEAN could be taken to address this

14. Summary/Conclusions
The PROTEAN approach to active networks strikes a good balance between scalability and flexibility
Only edge routers are User-programmable while all routers are Network-programmable
The equivalent link abstraction process allows edge routers to deal accordingly with issues within the core routers
The Spine implementation allows for discovery of and communication between active routers as well as discovery of active services available

15. Related Works
R. Sivakumar, N. Venkitaraman, V. Bharghavan, “The Protean Programmable Network Architecture: Design and Initial Experiences,” in Proceedings of the International Working Conference on Active Networks (IWAN), Berlin, Germany, 1999.
R. Sivakumar, S. Ha, S. Han, J. Li, V. Bharghavan, “The Protean Active Router Architecture,” TIMELY Group Research Report, 1999.
R. Sivakumar, B. Das, V. Bharghavan, “Spine Routing in Ad hoc Networks,” ACM/Baltzer Publications Cluster Computing Journal, Special Issue on Mobile Computing, 1998.