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) 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

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

end systems must periodically renew their requests (default: every 30 sec.)
Chapter 18: Protocols for QoS Support

there is no connection setup or teardown on which to base hard state maintenance

RSVP Design Characteristics

Unicast and Multicast (design point) Simplex Receiver-initiated reservation Maintains soft state Different reservation styles Transparent operation through nonRSVP routers Support for IPv4 and IPv6

Chapter 18: Protocols for QoS Support 4

Receiver-Initiated Reservation

Source-initiated reservations are inadequate for multicasting

Sender provides traffic characteristics, but receiver requests desired QoS

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

Chapter 18: Protocols for QoS Support

Soft State

Values associated with a given flow is temporarily cached at the router 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
6

based on end-system reservation

Chapter 18: Protocols for QoS Support

RSVP Data Flow Concepts

Session identifies a flow by its destination (unicast or multicast)

How are flows of data identified?

Destination IP address IP protocol identifier (e.g., TCP or UDP) Destination port number

Flowspec describes the QoS parameters

Flow Descriptor

Filter specification defines the packets in a flow

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)

Chapter 18: Protocols for QoS Support

Source IP address (minimal) UDP/TCP source port number (optional) other fields (based on application)

Example: Treatment of Packets at Router

1.

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

RSVP Operation

Chapter 18: Protocols for QoS Support

R1, R2, R3, R4: forwarding routers G1, G2, G3: multicast receivers S1, S2: multicast senders

RSVP Reservation Operation

Source(s)/ Senders(s)

RSVP Reservation (RESV) Messages

Destination(s)/ Receiver(s)

Router

Reservation actions at router: 1. Admission control verify requested resources are available 2. Policy control verify permissions 3. Set up classifier and scheduler to provide requested Q0S 4. Forward request upstream (aggregate as required)
Chapter 18: Protocols for QoS Support

10

Reservation Styles
How resource reservations are aggregated/merged for multiple receivers in the same multicast group Two options, specified in the receivers reservation requests

Three reservation styles are defined

11

Reservation attribute: reservation is shared over flows from multiple senders, or distinct for each sender Sender selection: explicit list or wildcard

Chapter 18: Protocols for QoS Support

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})
12

Chapter 18: Protocols for QoS Support

Reservation Styles: Example

Multicast Group Sources
S1

Router with RSVP capability Multicast Group Receivers

S2

S3

Chapter 18: Protocols for QoS Support

13

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

14

QoS Protocols (cont.)

15

Multiprotocol Label Switching

MPLS: The intelligence of routing with the performance of switching.

Chapter 18: Protocols for QoS Support

16

Multiprotocol Label Switching

MPLS Goal: provide ATM-like traffic management and QoS within IPbased networks Reality: provides an approach which reduces per-packet processing required at routers, thereby enhancing IP routing performance

1. support for connectionoriented QoS 2. Traffic engineering 3. VPN support 4. multiprotocol support

Significant new capabilities are introduced in MPLS:

RFC 3031 issued in January 2001

Chapter 18: Protocols for QoS Support

17

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
18

Chapter 18: Protocols for QoS Support

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.
MPLS can be used to avoid the overlay performance problem associated with meshed IPATM networks.
19

supports network scalability

Chapter 18: Protocols for QoS Support

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 trafficengineering capability.

Chapter 18: Protocols for QoS Support

20

MPLS Terminology Summary

Chapter 18: Protocols for QoS Support 21

Per RFC 3031

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.

packets entering at ingress LSR are assigned to an appropriate FEC and a label is attached

the egress LSR strips the label and forwards the packet to its final destination

Chapter 18: Protocols for QoS Support

at each LSR along the LSP, the incoming label is removed and an outgoing label is attached

22

MPLS Operation

Chapter 18: Protocols for QoS Support

23

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 A particular PHB can be assigned for a given FEC at each LSR
24

note: labels have local significance only

Chapter 18: Protocols for QoS Support

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
25

Chapter 18: Protocols for QoS Support

MPLS Packet Forwarding

Label stacking?
Chapter 18: Protocols for QoS Support 26

MPLS Label Format & Placement

Data Link Frame IEEE 802 MAC Frame ATM Cell

Frame Relay Frame

Chapter 18: Protocols for QoS Support 27

MPLS Path Selection

Traffic Engineering

Class of Service

Chapter 18: Protocols for QoS Support

28

MPLS Path (Route) Selection

Two options specified in RFC 3031:

hop-by-hop routing

explicit routing

makes use of ordinary routing protocols, like OSPF does not readily support traffic engineering or routing based on policy/priority 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
29

Chapter 18: Protocols for QoS Support

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
Recent focus of IETF efforts

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 30

Real-Time Transport Protocol (RTP)

31

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 32

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 33

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 34

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 35

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 36

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

37

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

38

RTP Architecture Concepts

From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support

39

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

flow is broken into ADUs (application data units), e.g. audio samples, video frames

may need to re-compute lost data before sending may be able to send new data that fixes the consequences of any lost data

lower layers must preserve ADU boundaries payload format is specific to the application

Chapter 18: Protocols for QoS Support

40

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

41

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 42

RTP Data Transfer Protocol

Supports transfer of real-time data among participants in a RTP session

Four primary functions are:

session is defined by: RTP port#, RTCP port#, participant IP address payload type identification timestamping data sequencing/synchronizing data mixing/translating data
43

Chapter 18: Protocols for QoS Support

RTP Data Transfer Protocol

Each RTP data unit must include:

RTP relays

source identifiers (who generated data) timestamp (when data was generated) sequence number (order of data in a flow) payload format (type of data)

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
44

Chapter 18: Protocols for QoS Support

RTP Mixers & Translators

Mixer

Translator

Chapter 18: Protocols for QoS Support

45

RTP Fixed Header

Supplied by a mixer

Chapter 18: Protocols for QoS Support

46

Some Standard Payload Types

(see RFC 3551)

Chapter 18: Protocols for QoS Support

47

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

48

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
49

Chapter 18: Protocols for QoS Support

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

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.
50

RTCP Formats

Source Description

Receiver Report RTCP BYE Sender Report Application-defined Packet

Chapter 18: Protocols for QoS Support 51

SDES Types

Chapter 18: Protocols for QoS Support

52