1. A Routing Control Platform for Managing IP Networks Jennifer Rexford Computer Science Department Princeton University http://www.cs.princeton.edu/~jrex

2. Background and Interests Professional background –Joined Princeton faculty in February 2005 –After 8.5 years at AT&T Labs—Research Work with AT&T’s backbone & large enterprises Tools in daily use in AT&T’s backbone Research interests: data networking –Networks easier to design and operate –IP routing and network measurement –Division between routers and management

3. Today: Inside a Single Network Data Plane Packet handling by routers Forwarding, filtering, queuing Management Plane Figure out what is happening in network Decide how to change it Shell scripts Traffic Engin. Databases Planning tools OSPF SNMPnetflowmodems Configs OSPF BGP Link metrics OSPF BGP OSPF BGP Control Plane Multiple routing processes on each router Configuration on each router Many control knobs: link weights, access lists, policy FIB Routing policies Packet filters

4. How Did We Get in This Mess? Initial IP architecture –Bundled packet handling and control –Functionality distributed across routers –Didn’t anticipate need for management Rapid growth in features –Internet’s sudden popularity and growth –Demands for new features –Built as incremental extensions Challenges of distributed algorithms –Some tasks are hard in a distributed fashion

5. Solution: Wafer-Thin Control Plane Decision plane: outside the routers –All decision logic and state –Network-wide view and objectives –Direct control over the data plane Discovery plane: in the routers –Monitors the topology –Measures the traffic Data plane: in the routers –Queues, filters, and forwards data packets –Accepts instruction from decision plane

6. Achieving the New Architecture Today Deployability: getting from here to there –Compatible with existing routers –Incentives for deployment Speed: running fast enough –Respond quickly to network events Reliability: avoiding single point of failure –Replicate to tolerate failure –Replicas must behave consistently Can we do it? The short answer is… yes!

7. Deployability: Backwards Compatibility using BGP Border Gateway Protocol (BGP) –Protocol: messages sent between routers –Decision logic: route-selection process –Policy: configurable rules The key point is –Complex decision logic and policies –Yet simple protocol and message format Idea: Use BGP messages to tell the routers what to do

8. Deployability: Inside a Single Autonomous System (AS) iBGP eBGP Before: conventional use of BGP in backbone network iBGP eBGP After: RCP learns routes and sends answers to routers Only one AS has to change its architecture! RCP

9. Deployability: Across Multiple ASes Represents the AS to others –Has complete view of all candidate routes –Computes answers for the AS’s routers Communicates with other ASes –Using BGP or a brand new protocol –… while using BGP to talk to the routers AS 3 AS 2 AS 1 iBGP Physical peering Inter-AS Protocol RCP

10. Routing Control Platform (RCP) Route Control Server (RCS) BGP Engine OSPF Viewer Routing Control Platform (RCP) Answers BGP updates … Options Topology BGP updates … OSPF link-state advertisements … Network

11. Scalability: Standard Computing Platform Prototype on a high-end PC –3.2 GHz Pentium-4 with 8 GB of RAM –Running the Linux 2.6.5 kernel Workload from the AT&T backbone –Replay the BGP and OSPF messages Good RCP performance –Memory usage: less than 2GB –Speed, BGP changes: less than 40 msec –Speed, topology changes: 0.1-0.8 seconds Short answer: the system can keep up

12. Reliability: Replication and Consistency Replication: avoid single point of failure –Multiple RCPs in a network –Connected at different places Consistency: no explicit coordination –Replica has full view of each partition –Replicas perform the same algorithm on the same data, and get the same answer RCP ARCP B A A, B B

13. Example Applications Customer-driven route selection –Customized load-balancing policies –Geographic rules for route selection Blocking denial-of-service attacks –“Blackhole” routes that drop traffic –Only for routers carrying attack traffic Hitless maintenance –Move traffic away from certain routers –Before the operators bring down the routers

14. Project With Department of Homeland Security Border Gateway Protocol is important –BGP is the glue that holds the Internet together BGP is extremely vulnerable –Easy to inject false information –Easy to trigger routing instability Vulnerabilities are being exploited –Configuration errors and malicious attacks –Route hijacking, blackholes, denial-of-service, … Changing to a secure protocol is hard –Can’t have a flag day to reboot the Internet

15. Example: Route Hijacking 1 2 3 4 5 6 7 12.34.0.0/16 Consequences for the data traffic –Discarded: denial of service –Snooped: violating the user’s privacy –Redirected: identity theft, propagating false info, etc.

16. Solution: Incremental Deployability Backwards compatibility –Work with existing routers and protocols Incentive compatibility –Offer significant benefits, even to the first adopter AS 3 AS 2 AS 1 BGP Inter-AS Protocol RCP Routing Control Platform tells routers how to forward traffic Use BGP to communicate with the legacy routers Use RCP to simplify management and enable new servicesUse RCP to detect (and avoid) suspicious routes Other ASes can deploy an RCP independently ASes with RCPs can cooperate to detect suspicious routes ASes can upgrade to secure interdomain routing protocol … all while still using BGP to control the legacy routers Distributed detection

17. Conclusion Network operations is too hard –IP was not designed for management –Complex, distributed operation of routers Must reduce complexity –Network-wide views and objectives –Direct control over the data plane New architecture is feasible –RCP is deployable, scalable, and reliable –RCP solves real, important problems New opportunity to impact the future of IP networks.