Internet routing cos 598a today telling routers what to do
This presentation is the property of its rightful owner.
Sponsored Links
1 / 28

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


  • 127 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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

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

Network

IP

Edge

IP

But, how should we partition function vertically?


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

Databases

Configs

SNMP

netflow

modems

  • Control Plane

  • Multiple routing processes on each router

  • Each router with different configuration program

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

OSPF

Link metrics

Routing policies

OSPF

OSPF

OSPF

BGP

BGP

BGP

FIB

FIB

FIB

Today: Inside a Single Network

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


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


Multiple route providers

Analogy to Transportation Networks

From Karthik Lakshminarayanan’s slides


Multiple route metrics


Time taken

Distance


eBGP

eBGP

Inter-AS Protocol

RCP

RCP

RCP

iBGP

RCP

RCP

iBGP

iBGP

AS 1

AS 2

AS 3

Physical

peering

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

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


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


  • Login