Protocols for QoS Support

1. 1 Chapter 18 Protocols for QoS Support

2. Chapter 18: Protocols for QoS Support 2 Introduction Modern internet applications demand services not provided by a best-effort service model The TCP/IP infrastructure has been enhanced to address the need increased capacity and data rates efficient multicasting techniques (Chap. 15) QoS capabilities added (Chap. 17) Protocols are required to support the QoS enhancements to the infrastructure: RSVP for reservation and admission control MPLS for traffic engineering RTP for real-time application support

3. Chapter 18: Protocols for QoS Support 3 Resource Reservation (RSVP) Internet resource reservation characteristics (RFC 2205) similar, but fundamentally different from that used in connection-oriented networks such as ATM, frame relay soft state at routers: reserved resources expire unless refreshed there is no �connection� setup or teardown on which to base �hard� state maintenance end systems must periodically renew their requests (default: every 30 sec.)

4. Chapter 18: Protocols for QoS Support 4 RSVP Design Characteristics Unicast and Multicast Simplex Receiver-initiated reservation Maintains soft state Different reservation styles Transparent operation through non-RSVP routers Support for IPv4 and IPv6

5. Chapter 18: Protocols for QoS Support 5 Receiver-Initiated Reservation Source-initiated reservations are inadequate for multicasting different members of same group may have different resource requirements if transmission flow is divided into sub-flows, not all members need all sub-flows if multiple sources are transmitting for same group, receiver may want to select source In general, QoS needs of different receivers may differ due to equipment, link speed, processing speed/power or other differences Sender provides traffic characteristics, but receiver requests desired QoS

6. Chapter 18: Protocols for QoS Support 6 Soft State Values associated with a given flow is temporarily cached at the router based on end-system reservation Routing for that flow is subject to change End systems must periodically refresh the state information Routers discard states not refreshed within specified time limit If a new route becomes the preferred route for the flow, end systems provide the reservation information to the new routers on the route

7. Chapter 18: Protocols for QoS Support 7 RSVP Data Flow Concepts How are flows of data identified? Session � identifies a flow by its destination (unicast or multicast) Destination IP address IP protocol identifier (e.g., TCP or UDP) Destination port number Flowspec � describes the QoS parameters Service class Tspec: traffic characteristics of the flow (average rate, peak rate, maximum burst size) Rspec: QoS reservations specification of the flow (for Guaranteed Service) Filter specification � defines the packets in a flow Source IP address (minimal) UDP/TCP source port number (optional) other fields (based on application)

8. Chapter 18: Protocols for QoS Support 8 Example: Treatment of Packets at Router

9. Chapter 18: Protocols for QoS Support 9 RSVP Operation

10. Chapter 18: Protocols for QoS Support 10 RSVP Reservation Operation

11. Chapter 18: Protocols for QoS Support 11 Reservation Styles How resource reservations are aggregated/merged for multiple receivers in the same multicast group Two options, specified in the receivers� reservation requests Reservation attribute: reservation is shared over flows from multiple senders, or distinct for each sender Sender selection: explicit list or wildcard Three reservation styles are defined�

12. Chapter 18: Protocols for QoS Support 12 RSVP Styles - Reservation Attributes and Sender Selection

13. Chapter 18: Protocols for QoS Support 13 Reservation Styles: Example

14. Chapter 18: Protocols for QoS Support 14 RSVP Protocol Mechanisms Two basic message types: Resv: propagates upstream from receivers to establish router soft states (resource reservations) for a multicast group, merging as required. Message carries a merged flowspec. Path: issued by senders to establish reverse-hop (upstream) path back to a source from group members

15. 15 QoS Protocols (cont.)

16. Chapter 18: Protocols for QoS Support 16 Multiprotocol Label Switching

17. Chapter 18: Protocols for QoS Support 17 Multiprotocol Label Switching MPLS Goal: provide ATM-like traffic management and QoS within IP-based networks Reality: provides an approach which reduces per-packet processing required at routers, thereby enhancing IP routing performance Significant new capabilities are introduced in MPLS: support for connection-oriented QoS Traffic engineering VPN support multiprotocol support RFC 3031 issued in January 2001

18. Chapter 18: Protocols for QoS Support 18 MPLS in Practice High-speed IP backbones Legacy ATM networks MPLS-capable ATM networks Optical networks Frame relay networks Most prevalent usage is for transporting IP data over these networks with low overhead/latency, often to implement a VPN for IP traffic

19. Chapter 18: Protocols for QoS Support 19 MPLS in Practice improves packet-forwarding performance in the network MPLS enhances and simplifies packet forwarding through routers using Layer-2 switching paradigms. MPLS is simple, which allows for easy implementation. MPLS increases network performance because it enables routing by switching at wireline speeds. supports QoS and CoS for service differentiation MPLS uses traffic-engineered path setup and helps achieve service-level guarantees. MPLS incorporates provisions for constraint-based and explicit path setup. supports network scalability MPLS can be used to avoid the overlay performance problem associated with meshed IP�ATM networks.

20. Chapter 18: Protocols for QoS Support 20 MPLS in Practice integrates IP and ATM in the network MPLS provides a bridge between access IP and core ATM. MPLS can reuse existing router/ATM switch hardware, effectively joining the two disparate networks. builds interoperable networks MPLS is a standards-based solution that achieves synergy between IP and ATM networks. MPLS facilitates IP�over-synchronous optical network (SONET) integration in optical switching. MPLS helps build scalable VPNs with traffic-engineering capability.

21. Chapter 18: Protocols for QoS Support 21 MPLS Terminology Summary

22. Chapter 18: Protocols for QoS Support 22 MPLS Operation

23. Chapter 18: Protocols for QoS Support 23 MPLS Operation

24. Chapter 18: Protocols for QoS Support 24 MPLS Operation MPLS FEC can be determined by a number of parameters: source/destination IP addresses port numbers IP protocol ID DS codepoint IPv6 flow label Forwarding between LSRs requires only simple mapping between label values and next hop addresses note: labels have local significance only A particular PHB can be assigned for a given FEC at each LSR

25. Chapter 18: Protocols for QoS Support 25 MPLS Advantages over Network Layer Forwarding MPLS forwarding can be done by high-speed switches that may not be capable of IP packet analysis/handling Forwarding behavior (the LSP) can be based on information other than that in the IP header Forwarding behavior can be based on network ingress point FEC determination can be arbitrarily complex since it is done only once � at ingress Paths for traffic can be �engineered� in advance to balance load traffic or provide different levels of serviced for different FECs

26. Chapter 18: Protocols for QoS Support 26 MPLS Packet Forwarding

27. Chapter 18: Protocols for QoS Support 27 MPLS Label Format & Placement

28. Chapter 18: Protocols for QoS Support 28 MPLS Path Selection

29. Chapter 18: Protocols for QoS Support 29 MPLS Path (Route) Selection Two options specified in RFC 3031: hop-by-hop routing makes use of ordinary routing protocols, like OSPF does not readily support traffic engineering or routing based on policy/priority explicit routing single designated LSR, usually an ingress or egress LSR, specifies all LSRs in a route for a given FEC with �loose explicit routing� only some of the LSRs are specified

30. Chapter 18: Protocols for QoS Support 30 MPLS Label Distribution RFC 3031 does not define or depend on a specific label distribution protocol � several are defined MPLS-LDP (RFC 3036) RSVP-TE (RFC 3209) MPLS-BGP MPLS-RSVP-TUNNELS Labels are distributed (bound) in a downstream path of LSRs in an LSP Labels must be unique on each hop between pairs of LSRs )local significance)

31. 31 Real-Time Transport Protocol (RTP)

32. Chapter 18: Protocols for QoS Support 32 Real-Time Traffic Flow

33. Chapter 18: Protocols for QoS Support 33

34. Chapter 18: Protocols for QoS Support 34

35. Chapter 18: Protocols for QoS Support 35

36. Chapter 18: Protocols for QoS Support 36

37. Chapter 18: Protocols for QoS Support 37 TCP/UDP for Real-Time? TCP point-to-point, connection-oriented, so not suitable for multicast includes retransmission mechanisms for lost segments, which often conflicts with real-time application requirement no segment timing information available UDP no segment timing information available or other general purpose real time tools

38. Chapter 18: Protocols for QoS Support 38 Real-Time Transport Protocol (RTP) Defined in RFC 3550 to provide mechanisms needed to support real-time traffic in IP-based networks, primarily to satisfy the needs of multi- participant multimedia conferences Best suited for soft real-time communication Lacks mechanisms to support hard real-time traffic (i.e., traffic with no loss tolerance, minimal jitter) Closely coupled with the application layer in the Internet protocol stack (typically, above UDP) Two protocols make up RTP: RTP, a data transfer protocol (carries the data) RTCP, a control protocol (carries session/QoS info)

39. Chapter 18: Protocols for QoS Support 39 RTP Architecture Concepts

40. Chapter 18: Protocols for QoS Support 40 RTP Architecture Concepts Application-Level Framing recovery from lost data and framing can be handled at the application layer retransmission may not be appropriate may be more useful for destination(s) to inform source about the quality of transmission application often provides data for retransmission may need to re-compute lost data before sending may be able to send new data that fixes the consequences of any lost data flow is broken into ADUs (application data units), e.g. audio samples, video frames lower layers must preserve ADU boundaries payload format is specific to the application

41. Chapter 18: Protocols for QoS Support 41 RTP Architecture Concepts Integrated Layer Processing typical layered protocols call for data units to be sequentially processed by each layer integrated layer processing allows adjacent layers (application, RTP, transport) of the protocol stack to be tightly coupled therefore, RTP is not complete by itself� requires application-layer and transport layer capabilities (and appropriate information in its header)

42. Chapter 18: Protocols for QoS Support 42 RTP Architecture Concepts Profile Specification Document: defines a set of payload type codes and their mapping to payload formats (e.g., media encodings). May also define extensions or modifications to RTP that are specific to a particular class of applications. Typically, an application will operate under only one profile. E.g. profile for AV application data may be found in RFC 3551. Payload Format Specification Documents: define how a particular payload, such as an audio or video encoding, is to be carried in RTP.

43. Chapter 18: Protocols for QoS Support 43 RTP Data Transfer Protocol Supports transfer of real-time data among participants in a RTP session session is defined by: RTP port#, RTCP port#, participant IP address Four primary functions are: payload type identification timestamping data sequencing/synchronizing data mixing/translating data

44. Chapter 18: Protocols for QoS Support 44 RTP Data Transfer Protocol Each RTP data unit must include: source identifiers (who generated data) timestamp (when data was generated) sequence number (order of data in a flow) payload format (type of data) RTP relays mixer: combines data from multiple sources and creates new single data signal translator: converts input and resends in new format, or replicates for unicast destinations

45. Chapter 18: Protocols for QoS Support 45 RTP Mixers & Translators

46. Chapter 18: Protocols for QoS Support 46 RTP Fixed Header

47. Chapter 18: Protocols for QoS Support 47 Some Standard Payload Types  (see RFC 3551)

48. Chapter 18: Protocols for QoS Support 48 RTP Control Protocol (RTCP) Provides control information and feedback between session participants Each participant in an RTP session periodically issues an RTCP packet Uses same underlying transport as RTP (usually UDP) RTCP port # = RTP session port # +1 Provides four key functions for real-time traffic management (per RFC 1889) QoS and congestion control Source identification Session size estimation and scaling Session control

49. Chapter 18: Protocols for QoS Support 49 RTCP Operation Protocol specifies report packets exchanged between sources and destinations in real-time flows (max. one every 5 secs, limit to 5% session traffic) Five report types are defined: Sender (SR), Receiver(RR), Goodbye (BYE), Source Description (SDES) and Application specific SR and RR reports contain statistics such as the number of packets sent, number of packets lost, inter-arrival jitter, etc. Used to modify sender(s) transmissions and for diagnostics purposes

50. Chapter 18: Protocols for QoS Support 50

51. Chapter 18: Protocols for QoS Support 51 RTCP Formats

52. Chapter 18: Protocols for QoS Support 52 SDES Types