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/spring2
  005
• Tuesdays/Thursdays 1100am-1220pm

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 RD 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 todays 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
Edge
Network
IP
IP
But, how should we partition function vertically?
5
Today Inside a Single Network

• Data Plane
• Packet handling by routers
• Forwarding, filtering, queuing

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
• Didnt 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 todays networks
• Measuring and analyzing the Internet
• Representative models of traffic, topology, etc.
• Clean-slate designs
• Move away from todays 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
Analogy to Transportation Networks
From Karthik Lakshminarayanans slides
16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
Routing Control Platform

• Goal Move beyond todays 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 (NSDI05) 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