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 Records Model 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

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 Link Ingress 2 DiffServ : Worst Case Admission Control Admission control based on worst case is excessively wasteful!

11 DiffServ : Measurement-Based Admission Control New Capacity Mean  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 R1 R5 R9 Setup: Path (R1->R2->R6->R7->R4->R9) Reply: Resv communicates labels and reserves bandwidth on each link Pop

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 Engineering Co-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 ?

19 DiffServ and Traffic Engineering Co-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: –Scheduling: –4 types of traffic flow in the network: Best effort (non-MPLS, non-DiffServ) DiffSerf, non-MPLS : marked with a PHB tag MPLS, non-DiffServ : marked with MPLS label MPLS, DiffServ : marked with MPLS label and a PHB tag : MPLS packets are encapsulated IP packets, so they can also be marked by a DiffServ PHB tag, which would differentiate their treatment by the router w.r.t. scheduling. –Need analytical techniques to establish end-to-end guarantees for MPLS traffic as well : path establishment does not imply resource guarantees. –Policing (e.g., at the edge, using leaky buckets) will probably be necessary for both DiffServ and MPLS.

20 Smart Nets Test Bed - San Jose Legend 10Mbps Ethernet

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

25 Static vs. Dynamic Resource Reservations Example Problem: Distributed allocation of resources Issues: –Information available –Fairness –Efficiency –Robustness –Scalability Calls arrive at nodes 1 2 N