Internet Protocols for QoS Support
Protocols and the TCP/IP Suite Internet Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 Resource Reservation (RSVP)
Protocols and the TCP/IP Suite 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 Chapter 2 RSVP Design Characteristics
Protocols and the TCP/IP Suite 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 Chapter 2 Receiver-Initiated Reservation
Protocols and the TCP/IP Suite 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 Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 RSVP Data Flow Concepts
Protocols and the TCP/IP Suite 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 Chapter 2 Example: Treatment of Packets at Router
Protocols and the TCP/IP Suite Example:Treatment of Packets at Router Packet is checked to see if it is in a defined flow 2.Packet in flow is granted the appropriate QoS for that flow 3.Packets are handled (queued and serviced) per QoS parameters Chapter 18:Protocols for QoS Support Chapter 2 RSVP Reservation Operation
Protocols and the TCP/IP Suite RSVP Reservation Operation Source(s)/ Senders(s) RSVP Reservation (RESV) Messages Destination(s)/ Receiver(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 Chapter 2 Protocols and the TCP/IP Suite
RSVP Operation R1, R2, R3, R4:forwarding routers G1, G2, G3:multicast receivers S1, S2: multicast senders Chapter 18:Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 RSVP Styles - Reservation Attributes and Sender Selection
Protocols and the TCP/IP Suite RSVP Styles - Reservation Attributes and Sender Selection per session per sender Fixed-Filter: Specifies a distinct reservation for each sender and an explicit list of senders Symbolic representation: FF(S1{Q1}, S2{Q2}, ) Shared-Explicit: Specifies that a single resource reservation is to be shared by an explicit list of senders Symbolic representation: SE(S1, S2, {Q}) Wildcard-Filter: Specifies that a single resource reservation is to be shared by all senders to this address Symbolic representation: WF(*{Q}) Chapter 18:Protocols for QoS Support Chapter 2 Reservation Styles: Example
Protocols and the TCP/IP Suite Reservation Styles: Example S1 S2 S3 Router with RSVP capability Multicast Group Sources Multicast Group Receivers Chapter 18:Protocols for QoS Support Chapter 2 RSVP Protocol Mechanisms
Protocols and the TCP/IP Suite 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 Chapter 2 Protocols and the TCP/IP Suite
QoS Protocols (cont.) Chapter 2 Multiprotocol Label Switching
Protocols and the TCP/IP Suite Multiprotocol Label Switching MPLS:The intelligence of routing with the performance of switching. Chapter 18:Protocols for QoS Support Chapter 2 Multiprotocol Label Switching
Protocols and the TCP/IP Suite 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 Chapter 18:Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 18:Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
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 IPATM networks. Chapter 18:Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
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 IPover-synchronous optical network (SONET) integration in optical switching. MPLS helps build scalable VPNs with traffic-engineering capability. Chapter 18:Protocols for QoS Support Chapter 2 MPLS Terminology Summary
Protocols and the TCP/IP Suite MPLS Terminology Summary Chapter 18:Protocols for QoS Support Per RFC 3031 Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 Protocols and the TCP/IP Suite
MPLS Operation Chapter 18:Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 MPLS Advantages over Network Layer Forwarding
Protocols and the TCP/IP Suite 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 Chapter 18:Protocols for QoS Support Chapter 2 MPLS Packet Forwarding
Protocols and the TCP/IP Suite MPLS Packet Forwarding Label stacking? Chapter 18:Protocols for QoS Support Chapter 2 MPLS Label Format & Placement
Protocols and the TCP/IP Suite MPLS Label Format & Placement Data Link Frame IEEE 802 MAC Frame ATM Cell Frame Relay Frame Chapter 18:Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
MPLS Path Selection Traffic Engineering Class of Service Chapter 18:Protocols for QoS Support Chapter 2 MPLS Path (Route) Selection
Protocols and the TCP/IP Suite 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 Chapter 2 MPLS Label Distribution
Protocols and the TCP/IP Suite 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) Recent focus of IETF efforts Chapter 18:Protocols for QoS Support Chapter 2 Real-Time Transport Protocol (RTP)
Protocols and the TCP/IP Suite Real-Time Transport Protocol (RTP) Chapter 2 Real-Time Traffic Flow
Protocols and the TCP/IP Suite 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 Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 18:Protocols for QoS Support Chapter 2 Real-Time Transport Protocol (RTP)
Protocols and the TCP/IP Suite 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 Chapter 2 RTP Architecture Concepts
Protocols and the TCP/IP Suite RTP Architecture Concepts From Data Communication and Networks, Forouzan, 4th Edition Chapter 18:Protocols for QoS Support Chapter 2 RTP Architecture Concepts
Protocols and the TCP/IP Suite 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 Chapter 2 RTP Architecture Concepts
Protocols and the TCP/IP Suite 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 Chapter 2 RTP Architecture Concepts
Protocols and the TCP/IP Suite 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 Chapter 2 RTP Data Transfer Protocol
Protocols and the TCP/IP Suite 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 Chapter 2 RTP Data Transfer Protocol
Protocols and the TCP/IP Suite 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 Chapter 2 RTP Mixers & Translators
Protocols and the TCP/IP Suite RTP Mixers & Translators Mixer Translator Chapter 18:Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
RTP Fixed Header Supplied by a mixer Chapter 18:Protocols for QoS Support Chapter 2 Some Standard Payload Types (see RFC 3551)
Protocols and the TCP/IP Suite Some Standard Payload Types (see RFC 3551) Chapter 18:Protocols for QoS Support Chapter 2 RTP Control Protocol (RTCP)
Protocols and the TCP/IP Suite 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 Chapter 2 Protocols and the TCP/IP Suite
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 Chapter 2 Protocols and the TCP/IP Suite
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% ofthis 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 byallocated rate. Chapter 18:Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
RTCP Formats Sender Report Receiver Report Application-defined Packet RTCP BYE Source Description Chapter 18:Protocols for QoS Support Chapter 2 Protocols and the TCP/IP Suite
SDES Types Chapter 18:Protocols for QoS Support Chapter 2