internet routing (cos 598a) today: telling routers what to do jennifer rexford...
Post on 21-Dec-2015
216 views
TRANSCRIPT
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
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
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
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?
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
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