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

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
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
IP
Network
IP
Edge
But, how should we partition function vertically?
Today: Inside a Single Network
Shell scripts
Management Plane
• Figure out what is
Planning tools
Databases
happening in network
Configs SNMP
netflow modems • Decide how to change it
OSPF
Control Plane
Link
• Multiple routing processes
Routing
OSPF
metrics
on each router
policies
BGP
• Each router with different
configuration program
OSPF
OSPF
• Many control knobs: link
BGP
BGP
FIB
weights, access lists, policy
FIB
Traffic Engin.
Data Plane
FIB
• Packet handling by routers
Packet • Forwarding, filtering, queuing
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
From Karthik Lakshminarayanan’s slides
Multiple route providers
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
eBGP
Inter-AS
Protocol
–eBGP
Using
answers to the routers
RCPiBGP to “push”RCP
RCP
iBGP
– No need
RCPat all
RCPto change the legacy routers
iBGP
iBGP
– Keep
message
format
and
change
decision
AS
1
AS
2
AS 3 rules
Physical
peering
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 firstorder 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