Internet routing cos 598a today telling routers what to do
1 / 28

Internet Routing (COS 598A) Today: Telling Routers What to Do - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Internet Routing (COS 598A) Today: Telling Routers What to Do' - arion

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Internet routing cos 598a today telling routers what to do

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

Jennifer Rexford

Tuesdays/Thursdays 11:00am-12:20pm


  • 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
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
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






But, how should we partition function vertically?

Today inside a single network

Data Plane

Packet handling by routers

Forwarding, filtering, queuing

Shell scripts

  • Management Plane

  • Figure out what is happening in network

  • Decide how to change it

Traffic Engin.

Planning tools






  • Control Plane

  • Multiple routing processes on each router

  • Each router with different configuration program

  • Many control knobs: link weights, access lists, policy


Link metrics

Routing policies










Today: Inside a Single Network

Packet filters

No state in the network yeah right
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
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 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
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


  • 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
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
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

Analogy to Transportation Networks

From Karthik Lakshminarayanan’s slides

Time taken


Routing control platform



Inter-AS Protocol









AS 1

AS 2

AS 3



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

Wafer thin control plane
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
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?


  • 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
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
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
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
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