Protocols for QoS Support

1. Protocols for QoS Support COMP5416 Chapter 18 Chapter 18 Protocols for QoS Support

2. Review/Preview Approaches to QoS support: • Fine-grained approach • provide QoS to individualapplications or flows • IntServ, RSVP(ATM too) • Coarse-grained approach • provide QoS to large classesof data or aggregated traffic • DiffServ Chapter 18 Protocols for QoS Support

3. Review/Preview: IntServ • 2 service classes, besides best-effort • guaranteed service: • for delay intolerant application, packets never arrive late maximum delay guaranteed • controlled load service: • for adaptive applications that run well if network is not heavily loaded • Mechanisms • Declaring service requirements and characterising the data(flowspec) • admission control (can we provide requested service to givendata) • resource reservation (networks exchange of information) • packet scheduling (actions of routers to meet the requirements) i.e. queuing discipline! Chapter 18 Protocols for QoS Support

4. Resource Reservation Problems on an Internet • Must interact with dynamic routing • Reservations must follow changes in route • Thus, keep soft state– a set of state information at a router that expires unless refreshed • End users periodically renew resource requests Chapter 18 Protocols for QoS Support

5. Resource ReSerVation Protocol (RSVP) Design Goals • Enable receivers to make reservations • Different reservations among members of same multicast group allowed • Deal gracefully with changes in group membership • Dynamic reservations, separate for each member of group • Receivers can select one of multiple sources (like channel selection) • Deal gracefully with changes in routes • Re-establish reservations • Need to control protocol overhead • Specified in RFC2205 Chapter 18 Protocols for QoS Support

6. RSVP Characteristics • Can be used for Unicast and Multicast • Simplex • I.e. unidirectional data flow • Separate reservations in two directions if two-way exchange • Receiver initiated • Receiver knows which subset of source transmissions it wants • Maintain soft state on internet • It’s the responsibility of receivers! • Transparent operation through non-RSVP routers Chapter 18 Protocols for QoS Support

7. Data Flows - Session • Data flow identified by destination • Resources allocated by router for duration of session • Defined by (used for packet filtering) • Destination IP address • Unicast or multicast • IP protocol field (rep. next higher level) • TCP, UDP etc. • Destination port • May not be used in multicast Chapter 18 Protocols for QoS Support

8. Flow Descriptor • Reservation Request includes a flow descriptor containing a flowspec and a filter spec • Flowspec: • Specifies the service class • TSpec: a flow’s traffic characteristics, such as data rate • RSpec: service requested from network (its desired QoS) • Filter spec • Set of packets for this reservation • Uses source address & source port Chapter 18 Protocols for QoS Support

9. Treatment of Packets of One Session at One Router Chapter 18 Protocols for QoS Support

10. RSVP Protocol Mechanisms Two message types: • Path • Provide upstream routing information • Used by receivers to make reservation • Issued by sending hosts • Transmitted through distribution tree to all destinations • Resv (i.e. reserve) • Originate at multicast group receivers • Propagate upstream • Merged and packed as appropriate • Create & store soft states Chapter 18 Protocols for QoS Support

11. Path reservation • Receiver-oriented approach - receiver needs to know sender’s TSpecand the path • sender sends a message with TSpec to receiver, get reverse path as abonus • source transmits PATH, receiver responds with RESV Chapter 18 Protocols for QoS Support

12. MPLS: Background • Efforts to marry IP and ATM as ATM switching (was) much faster than IP routers • IETF working group formed in 1997, proposed standard 2001 • However, routers developed to be as fast as ATM switches now! • Remove the need to provide both technologies in same network • MPLS does provide new capabilities: • QoS support • Traffic engineering • Virtual private networks (VPNs) • Multiprotocol support Chapter 18 Protocols for QoS Support

13. Connection Oriented QoS Support (1) • Guarantee fixed capacity for specific applications • Control latency/jitter • E.g., ensures capacity for voice • MPLS imposes connection oriented framework on IP based internets • Contrary to RSVP’s approach Chapter 18 Protocols for QoS Support

14. Traffic Engineering (2) • Ability to dynamically define routes, plan resource commitments based on known demands and optimise network utilisation • Basic IP allows primitive traffic engineering • E.g. dynamic routing • MPLS makes network resource commitment easy • Able to balance load in face of demand • Able to commit to different levels of support to meet user traffic requirements • Aware of traffic flows with QoS requirements and predicted demand • Intelligent re-routing when congested Chapter 18 Protocols for QoS Support

15. Virtual Private Network (VPN) Support (3) • Traffic from a given enterprise or group passes transparently through an internet • Dedicated resources for VPNs • Segregated from other traffic on internet • VPN feature allows: • Performance guarantees • Security Chapter 18 Protocols for QoS Support

16. Multiprotocol support (4) Chapter 18 Protocols for QoS Support

17. MPLS Operation • Label switched routers (LSRs) capable of switching and routing packets based on label appended to a packet • Labels define a flow of packets between end points or multicast destinations • Each flow has specific path through LSRs • Connection oriented • Assigned to a FEC (forward equivalence class) • Each FEC declares QoS requirements • IP header not examined in LSRs • Forward only based on label value Chapter 18 Protocols for QoS Support

18. MPLS Operation II • MPLS domain is contiguous set of MPLS enabled routers (i.e LSRs) • A FEC (i.e. a flow) determined by: • Source/destination IP address or network IP address • Port numbers • IP protocol value • DiffServ codepoint or IPv6 flow label • Forwarding is simple lookup in predefined table • Map label to next hop • Packets between same end points may belong to different FECs Chapter 18 Protocols for QoS Support

19. FECs, LSPs, and Labels • A FEC’s path is known as Labelled Switched Path (LSP) • Packets identified by locally significant label • At each LSR, labelled packets forwarded on basis of label • LSR replaces incoming label with outgoing label • Routing protocol must determine topology and current conditions so LSP can be assigned to FEC • Must be able to gather and use information to support QoS • LSRs must be aware of LSP for given FEC, assign label to FEC and communicate label to other LSRs Chapter 18 Protocols for QoS Support

20. MPLS Operation Diagram Chapter 18 Protocols for QoS Support

21. Explanation – Connection Setup • LSP established prior to routing and delivery of packets • QoS parameters established along LSP • Resource commitment • Queuing and AQM policies at LSR • Labels assigned • Has local significance only • Manually or using a distribution protocol Chapter 18 Protocols for QoS Support

22. Explanation – Packet Handling • Packet enters domain through edge LSR • Processed to determine QoS (thru DS codepoint) • Ingress LSR assigns packet to FEC and hence LSP • May need co-operation to set up new LSP • LSR appends label and forwards packet • Other LSR in LSP receives packet • Remove incoming label, attach outgoing label and forward • Egress LSR strips label, reads IP header and forwards Chapter 18 Protocols for QoS Support

23. MPLS Packet Forwarding Chapter 18 Protocols for QoS Support

24. Label Format Diagram • Label value: Locally significant 20 bit • Exp: 3 bit reserved for experimental use • S: 1 for oldest entry in stack, zero otherwise • Time to live (TTL): hop count or TTL value Chapter 18 Protocols for QoS Support

25. Time to Live Processing • Needed to support TTL since IP header not read • Otherwise faulty LSR may result in endless looping • First label TTL set to IP header TTL on entry to MPLS domain • TTL decremented at internal LSR • If zero, packet dropped or passed to ordinary error processing (e.g. ICMP) • If positive, value placed in TTL of label and packet forwarded • At exit from domain, TTL decremented • If zero, as above • If positive, placed in TTL field of IP header and forwarded Chapter 18 Protocols for QoS Support

26. Summary • RSVP and MPLS protocols used to provide QoS support • There are other protocols used for specific type of applications • RTP and SCTP for streaming applications requiring soft real-time communication • Choice of a suitable protocol and architecture depends upon user requirements • To substantiate a choice, performance studies are required through tools like queuing theory and simulators! Chapter 18 Protocols for QoS Support

27. Final Exam Tips • 2 questions from Performance part • Simulation (no coding!) • Queuing analysis • 4 questions from Traffic Control part • TCP traffic control • ATM traffic control • IntServ framework • RSVP • Main focus on above, but understanding of all required • You are allowed to bring in one A4 annotated (double-sided) page • Bring along a calculator (non-programmable) Chapter 18 Protocols for QoS Support