Chapter 10 Advanced Network Architectures

1. Chapter 10 Advanced Network Architectures Integrated Services in the Internet RSVP Differentiated Services Network Interconnection Models MPLS Multimedia Networking Real-Time Transport Protocol Session Control Protocols

2. Chapter 10Advanced Network Architectures Integrated Services in the Internet

3. Integrated Services IP Model • Defines a flow as a stream of IP packets • Generated by a sender and destined to a destination • That require the same QoS • Provides QoS to individual flows in the Internet • “Better than Best Effort” for some applications • Support for real-time voice and video applications • Requires traffic management mechanisms to deliver appropriate QoS to each flow • Packet classification, scheduling, admission control • Explicit reservation of buffers and bandwidth resources for individual flows at every node • Resource Reservation Protocol (RSVP) provides means for making reservations

4. Network Service Models • Best effort service • No guarantees; suitable for elastic traffic • At low loading, suitable for many traffic classes • Guaranteed service • bound on maximum delay • guarantee on available bandwidth • Controlled load service • delay consistent with lightly loaded network

5. Routing agent Reservation agent Management agent Admission control Routing database Traffic control database Classifier Packet scheduler Input driver Internet forwarder Output driver IntServ Router Model Accept/reject a flow Identify a packet’s flow Buffering to control loss Transmission scheduling to control delay Traffic management mechanisms discussed in Chapter 7

6. End-to-End Performance • End-to-end performance for an individual flow is the result of per-switch performances • delay, jitter, loss, bandwidth • Per-switch performance depends on: • per-packet processing common to all packets • specific per-connection or per-class treatment • Resources must be allocated by RSVP at each node for each flow Router 1 Router 2 Router 3

7. Admission Control • Individual flow negotiates admission into the network • Flow Descriptor has two parts • Filter specification (filterspec) provides information required by classifier to identify the packets in the flow • Flow specification(flowspec) describes traffic properties of flow and QoS requirements • Traffic Specification (Tspec) describes traffic in terms of a token bucket • Request Specification (Rspec) describes QoS in terms of bandwidth, delay, loss • Each node along path must decide whether a flow can be accepted

8. Guaranteed Service • Intended for flows that require real-time packet delivery • Provides a firm delay bound • Each flow is shaped by (b,r) leaky bucket • b token bucket size • r token rate • Police the flow to ensure compliance • Reserve bit rate R>r at every node (weighted fair queueing) • Account for other network parameters From Chapter 7: m maximum packet size in flow M max packet size in network Rj bit rate of link j H number of hops in path

9. Controlled Load Service • Intended for flows that can tolerate some delay but are sensitive to traffic overload • Equivalent to “Best Effort under Light Traffic” • Low delay and low loss, but no quantitative guarantees • Less complex than guaranteed service • Each flow is shaped by (b,r) leaky bucket • Use admission control to limit volume of controlled load service • Reserve bit rate for the entire class to ensure light traffic mode • Police each flow to ensure compliance; Non-conforming packets accorded best effort service

10. Number of (application) flows can become extremely large Per-flow treatment involves high complexity Traffic Management Per-flow classifier Per-flow queueing Per-flow scheduling Hugh table sizes & high hardware complexity Admission Control Set up & maintenance of individual flows High processing load IntServ is not scalable Routing agent Reservation agent Management agent Admission control Routing database Traffic control database Classifier Packet scheduler Input driver Internet forwarder Output driver IntServ involves High Complexity

11. Chapter 10Advanced Network Architectures RSVP

12. ReSerVation Protocol (RSVP) • RSVP is an IP signaling protocol to setup and maintain flow-specific state in hosts and routers • Multicast-oriented • Performs resource reservations for multipoint-multipoint applications • Adapts changing group membership & routes • Unicast, a special case • Simplex • Requests resources from sender to receiver • Bidirectional flows require separate reservations • Receiver-oriented • Receivers initiate and maintain resource reservations • Soft-state at intermediate routers • Reservation valid for specified duration • Released after timeout, unless first refreshed

13. R1 S1 Multicast distribution by Internet R2 S2 R3 RSVP Sessions • Session: a data flow identified by destination address (unicast/multicast), transport layer protocol, & destination port # (optional) • Packets flow from multiple senders to multiple receivers

14. Policy control determines if application allowed to make request Admission control determines if resources available; sets up classifier & packet scheduler Application requests QoS from RSVP process RSVP prepares & sends request messages to router Host Router Appli- RSVP RSVP RSVP cation RSVP process process Routing process Policy Policy control control Data Admission Admission control control Classi- Classi- Packet Packet fier fier scheduler scheduler Data Data RSVP Architecture

15. RSVP Reservations Request RSVP Reservation Requests include: • Flowspec: specifies traffic and performance requirements of a flow • RSVP carries flowspecs and installs them in switches • Flowspec invokes admission control & sets scheduler • Filterspec describes packets that can use resources • Wildcard filter: single reservation for all senders in a session • Fixed filter: distinct reservation for each sender • Dynamic filter: single reservation for a specified set of senders • RSVP does not interpret the flowspecs and filter specs, it only carries them

16. PATH PATH PATH PATH RESV RESV RESV RESV Rx R3 S R1 ?  ?  R2  ? • Sender multicasts PATH message that describes traffic flow • Uses an existing routing protocol • Each router stores address of previous RSVP router (PHOP) and inserts its address in last hop field and forwards message, establishing the path in the reverse direction • Receiver unicasts RESV message to reserve resources (Can request confirmation from sender) • Each router performs admission & policy control (Send PathErr message if rejected) • Reservations may be modified or merged as RESV proceeds back to sender

17. Path Rx1 Resv Path R3 Path S Path R1 Path Rx2 Resv Resv Resv Resv R2 Path Path Resv Rx3 R4 Resv Reservation Merging • Resources are shared among receivers up to point where paths to different receivers diverge • RSVP process at nodes will merge requests at node where sufficient resources are already reserved • Request is not forwarded beyond merge point

18. S1 R1 Router S2,S3 R1, R3 Reservation Styles • S1, S2, S3, R1, R2, R3 belong to the same session • Can S2 & S3 share the bandwidth reserved by S1? • Yes if application has one sender transmit at a time • No if multiple senders transmit • How does router know which senders can access a reserved resource? • Explicit List • Wildcard (Any sender in session) Fixed Filter • Separate reservations • Explicit list Wildcard Filter • Shared reservations • Wildcard (all senders) Shared Explicit Filter • Shared reservations • Explicit list

19. a S1 c R1 Router R2 S2, S3 b d R3 Example

20. Wildcard request for 4B from R1 Wildcard request for 3B & 2B from R2 and R3; Merged into 3B request Inputs merge requests to 4B before upstream Example: audioconferencing with different bitrates Wildcard Filter Send Reserve Receive WF( *{4B} ) WF( *{4B} ) *{4B} (a) (c) WF( *{3B} ) WF( *{4B} ) WF( *{2B} ) *{3B} (d) (b)

21. Fixed Filter Send Reserve Receive FF( S1{4B} ) FF( S1{4B}, S2{5B} ) S1{4B} (a) (c) S2{5B} FF( S1{3B}, S3{B} ) FF( S2{5B}, S3{B}) S1{3B} FF( S1{B} ) (d) S3{B} (b) • FF request from R1 for 4B from S1, 5B from S2 • FF request from R2 for 3B from S1, B from S3 • FF request from R3 for B from S1 • Merge request to S1 for 3B • Merge request to S1 for 4B • Example: all-to-all videoconference

22. Shared Explicit Send Reserve Receive SE(S1{3B}) SE((S1,S2){B}) (S1,S2){B} (a) (c) SE((S1,S3){3B}) SE((S2, S3){3B}) (S1,S2,S3) SE(S2{2B}) (d) (b) {3B} • SE request for B for S1 & S2 from R1 • SE request for 3B for S1 & S3 from R2 • SE request for 2B for S2 from R2 • Merge to union of list (S1, S2, S3) & max request, 3B • Example: layered video

23. RSVP Soft State • Reservations are valid for a timeout period • Need to “refresh” reservation state by resending PATH & RESV messages before expiry time • Reservation removed if not refreshed by timeout • RSVP runs directly over IP with type=46 • message delivery is not reliable • Assume 1 in 3 consecutive messages gets through • Nominal refresh rate specified by R (usually 30 sec) • Refresh period for a receiver randomized from (0.5R, 1.5R) to avoid simultaneous refresh attempts • PathTear & ResvTear messages explicitly delete reservations

24. Version: 1 Flags: undefined Internet Checksum Send_TTL: TTL of originating IP packet Detects non-RSVP routers Length: total RSVP message Message Types Path Resv PathErr PathTear ResvTear ResvConf 0 4 8 16 31 Version Flags Msg Type RSVP Checksum Send_TTL Reserved RSVP Length RSVP Message Header

25. RSVP Message Objects SESSION: IP destination address, IP protocol number, and destination port # RSVP_HOP: IP address of RSVP-capable router that sent this message TIME_VALUES: refresh period R. STYLE: reservation style information not in flowspec or filterspec objects FLOWSPEC: desired QoS in a Resv message. FILTER-SPEC: set of packets that receive desired QoS in a Resv message. SENDER_TEMPLATE: IP address of the sender in Path message. SENDER_TSPEC: sender’s traffic characteristics in Path message. ADSPEC: carries end-to-end path information in Path message. ERROR_SPEC: specifies errors in PathErr and ResvErr; confirmation in ResvConf. POLICY_DATA: enables policy modules to determine whether request is allowed INTEGRITY: cryptographic and authentication information to verify RSVP message SCOPE: explicit list of senders that are to receive this message. RESV_CONFIRM: receiver IP address that is to receive the confirmation.

26. Chapter 10Advanced Network Architectures Differentiated Services

27. Differentiated Services • Differentiated Services (DiffServ) model is designed to be scalable and to provide QoS • Traffic is aggregated into a limited number of classes • Service is on aggregate-flow basis, not per individual flow • Each class receives a well-defined service treatment at each DiffServ router • No per-flow signaling

28. C =Core Router A =Access Router SLA H =Host Notwithstanding … Forwarding Path Architecture TCA … Complexity at the Edge • User negotiates Service Level Agreement (SLA) with service provider • SLA includes a Traffic Conditioning Agreement (TCA) stipulating • service level, traffic profile, marking, shaping • Access Router • classifies user packets and marks them in DS field of IP header as belonging to a specific class • conditions packet stream so it conforms to profile H H DiffServ Domain A C A H C A C A H A A H

29. C =Core Router A =Access Router H =Host Forwarding Path Architecture Simplicity in the Core • Aggregate-flow or class identified by a particular value in the DS field • Core routers provide a limited number packet forwarding options called Per-Hop Behaviors (PHBs) • Value in DS field identifies class and PHB • Router resources reserved on aggregate-flow basis, not per-flow H H DiffServ Domain A C A H C A C A H A A H

30. 0 6 7 DSCP CU Differentiated Services Field • Differentiated Services Codepoint (DSCP) • Six bits in the IPv4 TOS field • DSCP value specifies PHB in core router • Router uses DSCP as index that determines buffering & scheduling treatment for a packet • A recommended set of DSCP-to-PHB mappings • But service providers free to choose their own mapping • TOS Backwards Compatibility: • 000000→Default (Best Effort), 11x000→Network Control “Currently Unused”

31. Per-Hop Behaviors • Several PHBs defined by IETF • DE (Default) PHB: Best effort • Expedited Forwarding (EF) PHB: “Premium” • Low loss, low latency, low jitter, assured-bandwidth end-to-end transfer • Assured Forwarding (AF) PHB: “Better than Best Effort” • High assurance of delivery if traffic profile kept • Four independent AF classes • Provide four levels of assurance • Three values of packet drop precedence within each level • Router must preserve sequence of packets within same microflow (same application flow, same AF level)

32. PHB and Traffic Management • PHB definition do not specify mechanism to implement behavior • EF PHB • HOL priority queueing, Weighted Fair Queueing, or combination • AF PHB: Different levels of drop-precedence • RED with IN/OUT (RIO) • Maintain running averages • QIN: avg # conforming packets in buffer • QT: avg # total packets in buffer • IN packets dropped according to RED algorithm using QIN • OUT packets dropped according to RED using QT • OUT packets dropped more aggressively than IN packets

33. Possible Core Router Design • Define two basic priority classes serviced • Use RIO mechanism on the lower priority queue(s) High Priority Y EF? Scheduler Input Packet Output Packet N Low Priority Could define several classes Each with separate queue RIO Queue Management

34. H H Local DS domain A Transit network C A H B A C C B A H A A Contracted aggregate rate H DiffServ across Domains B = Border DS router • SLA must be in place between domains • Egress border router must condition traffic to contracted profile • Ingress border router classifies & conditions traffic • DSCP values may need to be mapped if domains use different DSCP-PHB mappings

35. Meter Shaper/ Marker dropper Classified Conditioned packets packets Traffic Conditioner • Meter measures traffic and checks for conformance to traffic profile • Token bucket to check peak rate, sustained rate, maximum burst size • Marker sets DSCP • Remark to lower class if non-conforming • Shaper/Dropper: Shape to profile; drop non-conforming packets

36. Bandwidth Broker • Bandwidth Broker responsible for allocating and controlling bandwidth within a DS domain • Users contact BB to negotiate SLA • BB uses policy database to determine whether a user can request certain services • BB determines whether resources are available to handle a request • BB translates flow database into TCAs to setup packet classifiers & meters in edge routers • BB allocates traffic to classes within domain • BB negotiates agreements with other DS domains

37. Chapter 10Advanced Network Architectures Network Interconnection Models

38. Host 2 Host 1 A G B F C E D Network 3 Network 1 Network 2 Network Interconnection ATM Network • Server network (Network 2) provides transport service to Client networks (Network 1 & Network 3) • Control Plane Issues: • Server network & client networks may use different technologies • What signaling is used and how are paths determined? SONET Network Optical Network IP Network IP Network

39. Host 1 Host 2 Application Application A B F G TCP TCP C D E IP IP IP IP IP IP AAL ATM AAL ATM Data Link Data Link Data Link Data Link ATM ATM ATM PHY PHY PHY PHY PHY PHY PHY PHY PHY Network 1 Network 2 Network 3 End-to-End Protocol Stacks • Example: IP over ATM • Hosts run TCP/IP • Client networks are IP networks • Server network is ATM

40. Overlay Model Independent control planes Client interacts with server network through User-Network Interface (UNI) Signal across UNI to request or release connections No network state information passes from server network to client network Secure & appropriate when networks run by different administrations Addressing method in client & server networks different Need ARP Client & server networks can evolve independently Peer-to-Peer Model Same control plane spans client & server network Client network knows state of server network e.g. OSPF information shared among networks RSVP implemented in all networks Client network can make routing decisions involving server network Higher efficiency Same addressing scheme in client and server networks No need for address resolution protocol Interdependence makes evolution more difficult Approaches to Interconnection

41. MPS2 MPS3 MPS1 IP router Host2 Host1 Default path Edge device Client network Client network ED ED MPC1 MPC2 ATM switch Overlay Example: IP over ATM • Multiprotocol over ATM (MPOA) uses overlay approach • Edge Device (ED) interposed between IP net & ATM net • ED contains MPOA client (MPC) to set up & release VCs • ATM has MPOA servers (MPS) for IP-ATM address resolution & IP packet forwarding

42. Overlay Example: IP over ATM MPS2 MPS3 MPS1 • First packets from Host 1 to Host 2 are routed using MPSs • Ingress ED monitors packet flows • When “long-lived” flow detected, MPD decides to set up VC • Sends ARP request, which is routed along routed path • Reply informs ingress ED of egress ED’s ATM address • VC set up & subsequent packet use ATM shortcut IP router Host2 Host1 Default path Edge device Client network Client network ED ED MPC1 MPC2 Short-cut path ATM switch

43. Routers are interconnected with ATM VCs in full mesh Many router adjacencies N2 for full mesh Routing algorithm becomes unnecessarily complex Many message exchanges when topology changes Routing could be simplified if ATM nodes used IP routing MPLS addresses this problem Routing Scalability in Overlay Model ATM network

44. y3 y4 y5 y2 y1 Peer-to-Peer Example: IP + ATM • Nodes combine ATM switching & IP routing • Initially packets are routed, hop by hop • Packets flow along default VCs “x” • When long-lived flow detected, node sets up shortcut • Client establishes VC shortcut y1 • Node A establishes VC shortcut y2 • And so on A B C D IP Client IP ATM Client IP PHY x x x x x Server network

45. Chapter 10Advanced Network Architectures MPLS

46. IP L1 IP L3 IP L2 What is MPLS? • Multiprotocol Label Switching (MPLS) • A set of protocols that enable MPLS networks • Packets are assigned labels by edge routers (which perform longest-prefix match) • Packets are forwarded along a Label-Switched Path (LSP) in the MPLS network using label switching • LSPs can be created over multiple layer-2 links • ATM, Ethernet, PPP, frame relay • LSPs can support multiple layer-3 protocols • IPv4, IPv6, and in others LER LSR LSR IP LER IP

47. Why MPLS? • Labels enable fast forwarding • But longest-prefix match is also fast • Circuits are good (sometimes) • Conventional IP routing selects one path, does not provide choice of route • Label switching enables routing flexibility • Traffic engineering: establish separate paths to meet different performance requirements of aggregated traffic flows • Virtual Private Networks: establish tunnels between user nodes

48. Proposals Leading to MPLS • IP Switching: IP+ATM proposed by IPSILON • Traffic-driven label assignment: create & teardown shortcut paths according to flow activity • Cell-Switch Router: proposed by Toshiba • Traffic-driven label assignment • Topology-driven label assignment: when node changes entries in IP routing table new ATM shortcuts are created & torn down • Request-driven label assignment: signaling can request setting up of new labels to set up explicit paths • Tag Switching: proposed by Cisco • Multiprotocol tag or label: over multiple layer-2 technologies • Label stacking: generalizes ATM 2-level hierarchy • Topology-driven & request-driven label assignment • ARIS (Aggregate Route-Based IP Switching): proposed by IBM • Label merging: optimization of label usage

49. Before MPLS: forwarding & control intertwined Transition to CIDR (control) meant forwarding had to change to longest-prefix match With MPLS: forwarding & control are separate All forwarding done with label switching Different control schemes dictate creation of labels & label-switched paths Control & forwarding can evolve independently Control component Routing and signaling Routing and signaling Routing and signaling Routing tables Forwarding tables Labeled packets Labeled packets Switch fabric Forwarding component Separation of Forwardng & Control All proposals leading to MPLS separate forwarding and control

50. Ingress LSR Ingress LSR Ingress LSR Egress LSR Ingress LSR Ingress LSR MPLS domain Ingress LSR Labels and Paths • Label-switched paths (LSPs) are unidirectional • LSPs can be: • point-to-point • tree rooted in egress node corresponds to shortest paths leading to a destination egress router