Internet Routing (COS 598A) Today: Telling Routers What to Do Jennifer Rexford Tuesdays/Thursdays 11:00am-12:20pm

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

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

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 But, how should we partition function vertically?

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 Each router with different configuration program Many control knobs: link weights, access lists, policy FIB Routing policies Packet filters

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

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

Who Wants What?

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

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

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

Removing Routing from Routers

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

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

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

Multiple route metrics

Time taken Distance

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 iBGP eBGP RCP iBGP eBGP RCP AS 3 AS 2 AS 1 iBGP Physical peering Inter-AS Protocol RCP

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

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?

Discussion

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?

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 –…?

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?

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

Other Thoughts?

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