Internet Routing (COS Internet Routing (COS 598A)598A)

Today: Telling Routers What to DoToday: Telling Routers What to Do

Jennifer RexfordJennifer Rexford

http://www.cs.princeton.edu/~jrex/teaching/http://www.cs.princeton.edu/~jrex/teaching/spring2005spring2005

Tuesdays/Thursdays 11:00am-12:20pmTuesdays/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 EdgeNetworkIP 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.

DatabasesPlanning tools

OSPFSNMP netflow modemsConfigs

OSPFBGP

Link metrics

OSPFBGP

OSPFBGP

Control Plane• Multiple routing processes

on each router• Each router with different

configuration program• Many control knobs: link

weights, access lists, policy

FIB

FIB

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

RCPiBGP

eBGP

RCP

AS 3AS 2AS 1

iBGP

Physicalpeering

Inter-AS ProtocolRCP RCP 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

planeSimple 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 underlayMaybe 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