Internet Routing (COS 598A) Today: Telling Routers What to Do

1. Internet Routing (COS 598A)Today: Telling Routers What to Do Jennifer Rexford http://www.cs.princeton.edu/~jrex/teaching/spring2005 Tuesdays/Thursdays 11:00am-12:20pm

2. Outline • Drivers for changing the routing architecture • Complexity • Inflexibility • Who wants what • Operators • End users • Researchers • Removing routing from routers • Routing As a Service • Routing Control Platform • Wafer-thin control plane

3. Drivers for Architectural Change • Big problems • Complexity for operators to manage the network • Difficulty for users to get what they want • Challenging for R&D to change the infrastructure • Architectural approaches • Change the division of functionality • Data, control, and management planes • Change the division of responsibility • End users, third parties, and service providers • Add new features in overlay services • Treat today’s network as an unfortunate artifact

4. Internet Architecture • Smart hosts, and a dumb network • Network provides best-effort packet delivery • All other services implemented on hosts • Keep most state at the edges Edge Network IP Edge IP But, how should we partition function vertically?

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

6. No State in the Network? Yeah, Right… • Dynamic state • Routing tables • Forwarding tables • Configuration state • Access control lists • Link weights • Routing policies • Hard-wired state • Default values of timers • Path-computation algorithms Lots of state, updated in a distributed, uncoordinated way

7. How Did We Get in This Mess? • Initial IP architecture • Bundled packet handling and control logic • Distributed the functions across routers • Didn’t fully anticipate the need for management • Rapid growth in features • Sudden popularity and growth of the Internet • Increasing demands for new functionality • Incremental extensions to protocols & routers • Challenges of distributed algorithms • Some tasks are hard to do in a distributed fashion

8. Who Wants What?

9. Network Operators • Network-wide views • Network topology (e.g., routers, links) • Mapping to lower-level equipment • Traffic matrix • Network-level objectives • Load balancing • Survivability • Reachability • Security • Direct control • Explicit configuration of data-plane mechanisms

10. End Users • Good, predictable end-to-end performance • Reachability • Low end-to-end delay • High end-to-end throughput • High reliability • Flexibility to balance trade-offs • Selecting the provider, or end-to-end path • Good performance given a financial constraint • Minimum cost given a performance constraint • Performance guarantees for subset of traffic

11. Researchers • Learn from today’s networks • Measuring and analyzing the Internet • Representative models of traffic, topology, etc. • Clean-slate designs • Move away from today’s artifacts • Propose new architectures, protocols, algorithms • Opportunities to experiment • Collect and analyze measurement data • Evaluate ideas in simulators and testbeds • Plausible deployment paths • Possibility of getting from here to there

12. Removing Routing from Routers

13. Proposals Ask: What Should Routers Do? • Forward packets: yes • Must be done at high speed • … in line-card hardware on fast routers • So, needs to be done on the routers • Compute routes: no • Hard to do in a distribution fashion • Difficult to make load-sensitive routing stable • Lacking complete information for good decisions • Not flexible enough for end users • Difficult to extend over time

14. Routing As a Service • Goal: third parties pick end-to-end paths for clients to satisfy diverse user objectives • Forwarding infrastructure • Basic routing (e.g., default routing) • Primitives for inserting routes • Route selector • Aggregates network information • Selects routes on behalf of clients • Competes with other selectors for customers • End host • Queries route selector to set up paths

15. Multiple route providers Analogy to Transportation Networks From Karthik Lakshminarayanan’s slides

17. Multiple route metrics

18. Time taken Distance

19. eBGP eBGP Inter-AS Protocol RCP RCP RCP iBGP RCP RCP iBGP iBGP AS 1 AS 2 AS 3 Physical peering Routing Control Platform • Goal: Move beyond today’s artifacts, while remaining compatible with the legacy routers • Incentive compatibility: phased evolution • Intelligent route reflector in a single AS • Learning eBGP routes directly from neighbor ASes • Interdomain routing between RCPs • Backwards compatibility: internal BGP • Using iBGP to “push” answers to the routers • No need to change the legacy routers at all • Keep message format and change decision rules

20. Wafer-Thin Control Plane • Goal: Refactor the data, control, and management planes from scratch • Management plane  Decision plane • Operates on network-wide view and objectives • Directly controls the data plane in real time • Control plane  Discovery plane • Responsible for providing the network-wide view • Topology discovery, traffic measurement, etc. • Data plane • Queues, filters, and forwards data packets • Accepts direct instruction from the decision plane Simple routers that have no control-plane configuration

21. How Does This Differ From Overlays • Overlays: circumventing the underlay • Host nodes throughout the network • Logical links between the host nodes • Active probes to observe the performance • Direct packets through good intermediate nodes • Routing services: controlling the underlay • Servers collect data directly from the routers • Servers compute forwarding tables for the routers • Data packets do not go through the servers • Like an overlay for managing the underlay Maybe some combination of the two makes sense?

22. Discussion

23. Feasibility • Fast reaction to failures • Routers are closer to the failures • Can a service react quickly enough? • Scalability with network size • State and computation grow with the topology • Can a service manage a large network? • Reliability? • Service is now a point of failure • Is simple replication enough? • Security? • Service is now a natural point of attack • Easier (or harder) to protect than the routers?

24. Collecting Measurement Data • All three proposals make measurement a first-order part of running the network • Routers have only two jobs • Forward packets • Collect measurement data • What measurements? • Topology discovery • Traffic demands • Performance statistics • …?

25. Algorithms for Computing Routes • Selecting routes should be easier • Complete view of network topology and traffic • Possibility of using centralized algorithms • Direct control over forwarding tables • …but what algorithms to use? • Still need a separation of timescale, but how? • Fast reaction to topological changes • Semi-offline optimization of routing • … and how to compute end-to-end paths? • Policy-based path vector protocol? • Publish/subscribe system? • Something else?

26. Solving Real Problems? • Customer load-balancing • Trading off load, performance, and cost • Controlling inbound and outbound traffic • Avoiding small subnets and BGP tweaks • Preventing overloading router resources • Minimum-sized forwarding table per router • Minimum stretch while obeying memory limits • Flexible end-to-end path selection • Satisfy the goals of end users and providers • Handle pricing/economics in the right way

27. Other Thoughts?

28. Next Time: Routing Software • No class next week • Work on course projects • Written report due May 10 • Class presentations on May 16 (?) • Two papers (NSDI’05) for April 19 class • “Designing Extensible IP Router Software” • “Design and Implementation of a Routing Control Platform” • Review just of the first paper • Optional: pointers to OpenBGPd and Quagga