1 / 52

Chapter 18

Chapter 18. Protocols for QoS Support. 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)

caelan
Download Presentation

Chapter 18

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 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.) Chapter 18: Protocols for QoS Support

  4. RSVP Design Characteristics • Unicast and Multicast (design point) • Simplex • Receiver-initiated reservation • Maintains soft state • Different reservation styles • Transparent operation through non-RSVP routers • Support for IPv4 and IPv6 • Unicast and Multicast • Simplex • Receiver-initiated reservation • Maintains soft state • Different reservation styles • Transparent operation through non-RSVP routers • Support for IPv4 and IPv6 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 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 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) Flow Descriptor Chapter 18: Protocols for QoS Support

  8. Example: Treatment of Packets at Router • Packet is checked to see if it is in a defined flow 3. Packets are handled (queued and serviced) per QoS parameters 2. Packet in flow is granted the appropriate QoS for that flow Chapter 18: Protocols for QoS Support

  9. RSVP Operation R1, R2, R3, R4: forwarding routers G1, G2, G3: multicast receivers S1, S2: multicast senders Chapter 18: Protocols for QoS Support

  10. RSVP Reservation (RESV) Messages RSVP Reservation Operation Destination(s)/ Receiver(s) Source(s)/ Senders(s) Router • Reservation actions at router: • Admission control – verify requested resources are available • Policy control – verify permissions • Set up classifier and scheduler to provide requested Q0S • Forward request upstream (aggregate as required) 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… Chapter 18: Protocols for QoS Support

  12. RSVP Styles - Reservation Attributes and Sender Selection per session per sender • Wildcard-Filter: • Specifies that a single resource reservation is to be shared by all senders to this address • Symbolic representation: WF(*{Q}) • Shared-Explicit: • Specifies that a single resource reservation is to be shared by an explicit list of senders • Symbolic representation: SE(S1, S2, … {Q}) • Fixed-Filter: • Specifies a distinct reservation for each sender and an explicit list of senders • Symbolic representation: FF(S1{Q1}, S2{Q2}, …) Chapter 18: Protocols for QoS Support

  13. S1 S2 S3 Reservation Styles: Example Router with RSVP capability Multicast Group Receivers Multicast Group Sources 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 Chapter 18: Protocols for QoS Support

  15. QoS Protocols (cont.)

  16. Multiprotocol Label Switching “MPLS: The intelligence of routing with the performance of switching.” Chapter 18: Protocols for QoS Support

  17. 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 Multiprotocol Label Switching Chapter 18: Protocols for QoS Support

  18. 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 MPLS in Practice Chapter 18: Protocols for QoS Support

  19. 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. MPLS in Practice Chapter 18: Protocols for QoS Support

  20. 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. MPLS in Practice Chapter 18: Protocols for QoS Support

  21. MPLS Terminology Summary   Chapter 18: Protocols for QoS Support Per RFC 3031

  22. MPLS Operation  using an interior routing protocol (like OSPF), establish a path (LSP) in advance for a given FEC and establish the QoS parameters for the FEC. Labels are assigned for each FEC.  the egress LSR strips the label and forwards the packet to its final destination  packets entering at ingress LSR are assigned to an appropriate FEC and a label is attached  at each LSR along the LSP, the incoming label is removed and an outgoing label is attached Chapter 18: Protocols for QoS Support

  23. MPLS Operation 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 Chapter 18: Protocols for QoS Support

  25. 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 MPLS Advantages over Network Layer Forwarding Chapter 18: Protocols for QoS Support

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

  27. MPLS Label Format & Placement Data Link Frame IEEE 802 MAC Frame ATM Cell Frame Relay Frame Chapter 18: Protocols for QoS Support

  28. MPLS Path Selection Traffic Engineering Class of Service 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 Chapter 18: Protocols for QoS Support

  30. Recent focus of IETF efforts 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) Chapter 18: Protocols for QoS Support

  31. Real-Time Transport Protocol (RTP)

  32. Real-Time Traffic Flow • Real-Time • Distributed • Application: • Source generates data stream at a constant rate • One or more destinations must deliver that data to an application at the same constant rate Chapter 18: Protocols for QoS Support

  33. Time relationship of real-time traffic Real-time traffic requires preservation of the time relationship between packets of a session. From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support

  34. Jitter (variation in delay) Jitter is introduced due top the variable component of delay in packet switched networks. From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support

  35. Timestamp Timestamping packets can allow reconstruction of original time relationship at the receiver. From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support

  36. Playback Buffer threshold threshold A playback buffer at the receiver is used to sequence/time the release of data to the application. From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support

  37. 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 TCP/UDP for Real-Time? 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) Chapter 18: Protocols for QoS Support

  39. RTP Architecture Concepts From Data Communication and Networks, Forouzan, 4th Edition 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 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) 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. 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 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 Chapter 18: Protocols for QoS Support

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

  46. RTP Fixed Header Supplied by a mixer Chapter 18: Protocols for QoS Support

  47. Some Standard Payload Types (see RFC 3551) 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 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 Chapter 18: Protocols for QoS Support

  50. RTCP Bandwidth Scaling • RTCP attempts to limit its traffic to 5% of the session bandwidth. Example • Suppose one sender, sending video at a rate of 2 Mbps. Then RTCP attempts to limit its traffic to 100 Kbps (5% of 2 Mbps) • RTCP gives 75% of this rate to the receivers; remaining 25% to the sender • The 75 kbps is equally shared among receivers: • With R receivers, each receiver gets to send RTCP traffic at 75/R kbps. • Sender gets to send RTCP traffic at 25 kbps. • Participant determines RTCP packet transmission period by calculating avg RTCP packet size (across the entire session) and dividing by allocated rate. Chapter 18: Protocols for QoS Support

More Related