1

Smart Networks Project Overview

• Cisco:

– David Jaffe, Karl Auerbach, Anna Charny

• Berkeley:– Venkat Anantharam, David Tse, Pravin Varaiya, Jean Walrand

– Stavros Tripakis (Post-Doc)

– Linhai He, John Musacchio, Jeff Danley, Jun Shu, Gaurav Agarwal, Eric Chi, Rajarshi Gupta

2

Outline

• Project Description– Why Smart Networks?

– Smart Networks Vision

– Main Focus Areas

– DiffServ

– Traffic engineering with MPLS/RSVP

– Test-bed

• Synergies with other groups

3

Why Smart Networks?

• Only the most basic measurements are used today for Networks Operations.

• Using more advanced measurements could improve– Planning

– Provisioning

– Resource Allocation to Different Classes of Service

– Fault Detection

• Need suitable methodology

4

Smart Networks Project

• DiffServ – Network Planning

– CoS Provisioning

– Operations: e.g., bandwidth brokers, tuning

• MPLS– Route-selection algorithms

– Robustness to link/node failures: selection of back-up routes

• DiffServ / MPLS integration– Traffic mixing at router’s scheduler

• Test-bed set-up for implementation, proof-of-concept and small-scale experimentation

Main Focus Areas

5

Smart Networks Vision

• Model networks, using knowledge from – Stochastic Models

– Applied Statistics, Simulation Techniques

– Control Systems

• Measurements -> Model Fitting -> Analysis/Simulation -> Decision Making

DesignerOperator

Historical

RecordsModel Fitting and Validation

(Model Selection)

Model Evaluation and Optimization(Analysis & Simulation)

OAM Message Transport

Probes; MIB

Design, Planning, Operations

Network Devices

Tools

6

DiffServ• Goal:

– CoS without per-connection state

• Solution: – No route-pinning (routing protocol, e.g. OSPF, BGP, handles that)– Planning and operations based on aggregate statistics and worst-case

routing– Admission-control, policing/shaping, tagging at the edge– Peer-to-peer SLAs that specify total rate but not traffic destination

SLACloud 1 Cloud 2

Edge router Core router/switch

7

DiffServ Issues

• What is the right admission control policy:– Centralized/Distributed– Depends on client request model: pipe/hose

• Pipe model: client requests access to specific destination (i.e., ingress and egress routers are specified)

• Hose: client requests access to the network (destination of client unknown, only ingress router known)

– Worst-case / Statistics based (measuring temporal and spatial distribution of traffic)

8

DiffServ Issues (continued)

• How are SLAs updated (resizing) :– Peer-to-peer: bandwidth broker only talks to peer

clouds. Algorithms/protocols ?• Convergence of updates, stability• Performance w.r.t. centralized solution

– End-to-end: request travels end-to-end and updates SLAs along the path(s).

• Scalability ? (Hierarchical solutions ?)• Acceptance of hierarchical solutions by cloud administrators ?

9

DiffServ Issues (continued)

• Analysis to establish end-to-end guarantees:– What is the right model for a router ?

• Highly dependent on scheduling algorithm, but would like to abstract

• Per-hop-behavior (PHB) definitions not formal/strict enough

– What are the right assumptions for intra- and inter-domain traffic statistics ?

– How does best-effort (or AF) traffic affect EF traffic ?

• On-line monitoring and reaction to failures:– Is re-routing (handled by routing protocol) enough or is rescheduling at routers also necessary ?

10

Ingress 1

Ingress 2

Ingress 3

Typical Case(spatial distribution)

Ingress 1

Ingress 3

Worst Case

Bottleneck LinkIngress 2

DiffServ : Worst Case Admission Control

Admission control based on worst case is excessively wasteful!

11

DiffServ : Measurement-Based Admission Control

New

Capacity

Mean + 2.4

Admit if peak(new) < Gap at all times

Gap

12

DiffServ : Measurement-Based SLA resizing

Use same idea for SLA resizing

• Keep statistics of traffic flowing to peer clouds• Request SLA update using:

• damping: update only when capacity of SLA exceeded• over-provisioning: update to more than actually needed

• Problem: what happens if peer broker rejects update request ?

13

Traffic Engineering with MPLS/RSVP

• Goal : guarantee QOS by explicitly controlling the routes

• How ?– MPLS (multi-protocol label switching) :

• Like ATM virtual-circuit switching• Packets encapsulated with a label (tag)• Router forwards based on label/input port, and assigns new label• Allows to bypass the IP routing protocol

– RSVP (resource reservation protocol) :• Signaling protocol, to establish the MPLS path initially• Also does resource book-keeping: how many paths are using a link

and how much of the capacity of that link is available• Soft state: reservations are periodically refreshed, to account for

failures, etc

Path Setup - Example

R8

R2

R6

R3

R4

R7

R1R5

R9

Setup: Path (R1->R2->R6->R7->R4->R9)Setup: Path (R1->R2->R6->R7->R4->R9)

Reply: Resv communicates labels andReply: Resv communicates labels andreserves bandwidth on each linkreserves bandwidth on each link

Pop

22

4917

32

15

Traffic Engineering Issues

• Off-line:– Plan routes for all possible source/destination pairs and

network states ahead of time (“optimal” solution).– Need knowledge of traffic statistics (arrival rates, holding

times, requested bandwidth) but these requests are not just voice calls ! (Might be aggregates coming from another cloud.)

• On-line:– Route requests as they arrive– Not using history/prediction of traffic => “greedy” approach

What is the right policy for path selection?

16

Traffic Engineering Issues

• Centralized/Distributed ?– Centralized assumes all requests arrive at the same route-selection

module.– Distributed may result in inconsistencies (e.g., over-booking).

• Many alternatives, even for on-line, centralized : – Any min-hop path with available resources– “Widest” path– Widest min-hop path– Minimum-interference path– Some weighted combination of some of the above ?

17

Traffic Engineering Issues (continued)

• How to make it robust to failures (e.g., single link/node failure) :– Reserve two (disjoint) paths for each request : active and back-up– Difficult choice of pairs of active / back-up paths

• How to periodically re-optimize by re-routing :– Example:might need to re-route a number of small-size calls to

accommodate / balance a large-size call.

• How to choose paths w.r.t. multiple-criteria :– Example: find a path that does not traverse a particular type of router

more than k times.

• End-to-end issues :– “Optimal” routes per cloud might not form an end-to-end optimal route.

18

DiffServ and Traffic EngineeringCo-existence

• Technologies are essentially complementary• Use DiffServ for aggregation into few traffic classes• Use traffic engineering to by-pass IP routing

• Issues for MPLS and DiffServ integration:– Path establishment in MPLS does not imply resource allocation

guarantees : need analytical techniques to establish end-to-end delay bounds.

– Scheduling mixed traffic:• Tag MPLS packets with DiffServ PHB (per-hop-behavior) tags ?• Hierarchical scheduling ?

20

Smart Nets Test Bed - San Jose

Legend

10MbpsEthernet

21

Management and Control Network

Legend

Serial(connected to

router’s console)

22

UNIX Box

• Receives Measurements from Routers (local or end-to-end measurements) :– Available Bandwidth

– Loss Rate

– Delay

– Jitter

23

UNIX Box

• Uses Measurements to Control Router– Adjusts Router’s Scheduling configuration, e.g.:

• Priority or Weighted Fair Queuing

• Adjust priorities or weights

– Currently building API using Expect (Tcl similar):

Jeff Danley, UCB student.

– Automated Process

24

Synergies

• Models / data for wide-area traffic

• Simulation tools (e.g., SSFNET, NIMI, for WAN)

• Test-bed:– Traffic generation software

– Measurement software