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

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

  • Uploaded on
  • Presentation posted in: General

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 Presentationdownload

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

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

Who wants what

Who Wants What?

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

Removing routing from routers

Removing Routing from Routers

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

Internet routing cos 598a today telling routers what to do

Multiple route metrics

Internet routing cos 598a today telling routers what to do

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

Other thoughts

Other Thoughts?

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

  • Login