The Darwin Router Control Interface

1. The Darwin Router Control Interface Peter Steenkiste, Jun Gao, Prashant Chandra, Eduardo Takahashi Computer Science Department Department of Electical and Computer Engineering Carnegie Mellon University OPENSIG ‘99 Carnegie Mellon University, October 1999

2. Outline • Motivation • Router Control Interface • Security and safety • Conclusion

3. Motivation • Open up the network: have a larger community develop services and applications for networks • Not just vendor sofware • Imagine a PC on which you can only run vendor software • Advanced services and applications need customized, runtime resource management support • Quality of execution depends on how resources are managed • Example: Corba + QoS (QuO) at BBN • Network management and control applications. • Support flexible QoS policies, monitoring tools, etc. • Convenient and fast software deployment and upgrading • Example: virtual private network service

4. E Example: A Virtual Private Network Service Delegates support customized control protocols F PARCPC MIT LBLPC UCL A B ISIPC ISIEPC DARPA2 UCLAPC VPN team: Keng Lim Jun Gao Eugene Ng Hui Zhang Peter Steenkiste CMU C D Hierarchical scheduler manages VPN resources G

5. Virtual Mesh: Resources + Control

6. Client Beagle Routing Beagle Control Delegates Applications Other Delegates Other Routing Entities Router Control Interface Local Resource Manager Route Lookup Classifier + Scheduler Darwin Node Architecture Classifier + Action

7. Router Control Interface (RCI) • RCI operates on a flow-based network model • Flows are the basic data type: RCI is an instruction set that operates on flows • Flow is defined using IP and transport layer header fields • Four categories of functions • Collecting information • Bandwidth usage, Monitor queue length, etc. • Local resource management actions • Set QoS parameters, selectively drop packets, etc. • Flow redirection • Tunneling, flow redirecting to delegate, route changes, etc. • Inter-delegate communication • Allow delegates to interact with peers and endpoints

8. Darwin Delegate Implementation • Implemented as Java code segments • Also more restricted support for C delegates • Delegate runtime environment based on a Java Virtual Machine • RCI is implemented as a set of C native methods • Use Java sandboxing for basic safety support • Delegates can be dynamically installed by the Beagle signaling protocol • Client specifies the delegates as part of the mesh • Beagle carries delegate bytecode to routers • Verifies, instantiates and initializes delegates

9. Control Delegates Link Org 1 Org 2 App 1 Flow 1 Hierarchical Resource Tree A Hierarchical Network Model • Hierarchical resource management in support of service hierarchies • Translates into a hierarchy of meshes • Representation on a router is a resource tree • Realized using the Hierarchical Fair Service Curve Scheduler (HFSC) • Delegates are associated with nodes in the resource tree • Scheduler provides isolation of network resource (data plane) • Delegates provide isolation of resource management and control (control plane)

10. Delegate Examples • Selective packet dropping for MPEG video streams • Monitoring, selective dropping • Dynamic control of MJPEG video encoding • Monitoring, control/data delegates coordination • Selective dropping of non-adaptive flows • Monitoring, selective dropping, inter-delegate communication • Load-sensitive flow redirecting • Monitoring, inter-delegate communication • On-going projects • QoS virtual private networks, active monitoring, etc.

11. Comparisonwith Related Projects • Active Nets node architecture (Peterson) • The delegate runtime environment can be viewed as an execution environment that handles “control” packets • “Data” packets follow the “cut through” path • What path that a packet takes through the router is controlled through a general classifier on the input port • Pronto (Hjalmtysson) • It has a similar architecture but has a stronger coupling between data/control plane • Darwin hierarchy provides more structure • Active signaling (Braden) • Also control and data plane separation but single network wide control • Focus on controlling versions instead of customization

12. Security and Safety: Where is the Problem? • Everywhere! • Harm the base router or other users (crash, corrupt, ..) • Allocate or use other user’s resources • Affect the treatment of other user’s traffic • We focus is on traffic management related threats • Other groups are addressing some of the other issues. • E.g., allocation of CPU time, efficient safety mechanisms, .. • Address the problem piece-wise by looking at an increasingly more powerful delegate • Delegates perform only local actions • Delegates can also perform global actions • Delegates can create peers and delegate responsibility.

13. Routing Beagle Control Delegates Router Control Interface Local Resource Manager Classifier + Action Classifier + Scheduler Local Actions Only • Beagle creates all delegates and sets up all permissions • Delegates can modify flow definitions and resource allocations • Modify flow weights, .. • Control over an output port (roughly) • Probably useful to have different levels of permission: • monitor traffic only • modify weights • change structure of the tree • peek at contents of packets

14. Control Delegates Link Org 1 Org 2 App 1 Flow 1 Hierarchical Resource Tree Local Actions Only: Possible Solutions • Leverage the hierarchical resource management abstraction • Beagle must verify that client can add a node and associated delegate • Check with owner of the parent • Runtime checking for every delegate RCI call • Is the call allowed on this resource? • Does the flow filter only match traffic that is controlled by this delegate • Usual runtime versus install time verification tradeoff • Fewer runtime checks for trusted code

15. Routing Beagle Control Delegates Router Control Interface Local Resource Manager Classifier + Action Classifier + Scheduler Global Actions • Beagle creates all delegates and sets up all permissions • Delegates can redirect flows • Example: routing delegates in a VPN service application • Affects what parts of the network are used: RCI is used for distributed programming • Changes input port functions • How to implement? • Tunneling seems manageable • Routing is more difficult! • How many routing tables? • How do you control and verify changes to a shared routing table? • What is the right model?

16. Global Actions: Possible Solutions • Restricted delegate actions to stay inside the mesh • Only affect traffic and only use links that are part of the mesh • Delegate has choice of outgoing link and path • Demonstrated this capability for the VPN services application • Use multiple routing daemons and forwarding tables • view of each routing daemon is restricted to its mesh

17. Delegation Control Delegates • Beagle is no longer the only manager of delegates or delegate permissions • It is “only” the signaling protocol for the root node • Delegates for interior nodes can also manage delegates and their permissions • Delegate authority, create peers or delegates for children,.. • Example: A VPN-specific signaling protocol creates delegates • Solution will have to combine local protection with “space” or mesh aspect. Link Org 1 Org 2 App 1 Flow 1 Hierarchical Resource Tree

18. Conclusion • Darwin delegates support the development of customized network control protocols • Use the RCI to affect the data forwarding path • Key question: what router functions do you want to be able to “delegate” (securely) • Resource management and QoS? • Routing? • Signaling and delegate management? • Desired degree of customization depends on user • Security becomes harder as you expand the scope • Version 1.0 of Darwin is available • http://www.cs.cmu.edu/~darwin • includes the HFSC scheduler, Beagle, and the delegate runtime environment