Download Chapter 2

Chapter 18
Protocols for QoS
Support
1
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
2
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
3
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
– 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
5
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
6
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
Flow Descriptor



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)
Chapter 18: Protocols for QoS Support
7
Example: Treatment of
Packets at Router
1.
Packet is
checked to see
if it is in a
defined flow
2.
Chapter 18: Protocols for QoS Support
Packet in flow is
granted the
appropriate QoS
for that flow
3.
Packets are
handled (queued
and serviced)
per QoS
parameters
8
RSVP Operation
Chapter 18: Protocols for QoS Support
R1, R2, R3, R4: forwarding routers
G1, G2, G3: multicast receivers
S1, S2: multicast senders
9
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

– 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
11
RSVP Styles - Reservation
Attributes and Sender Selection
per sender
per session
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})
Chapter 18: Protocols for QoS Support
Wildcard-Filter:
• Specifies that a single
resource reservation is
to be shared by all
senders to this address
• Symbolic representation:
WF(*{Q})
12
Reservation Styles: Example
Multicast
Group
Sources
S1
S2
S3
Chapter 18: Protocols for QoS Support
Router
with
RSVP
capability
Multicast
Group
Receivers
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
Chapter 18: Protocols for QoS Support

Significant new
capabilities are
introduced in
MPLS:
1. support for
connectionoriented QoS
2. Traffic
engineering
3. VPN support
4. multiprotocol
support

RFC 3031 issued
in January 2001
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
Chapter 18: Protocols for QoS Support
18
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

supports network scalability
– 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 IP–ATM networks.
Chapter 18: Protocols for QoS Support
19
MPLS in Practice

integrates IP and ATM in the network

builds interoperable networks
– MPLS provides a bridge between access IP and core
ATM.
– MPLS can reuse existing router/ATM switch hardware,
effectively joining the two disparate 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 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.

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

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
– 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
24
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
25
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
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
29
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


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
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
– 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
43
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
44
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
Chapter 18: Protocols for QoS Support
49
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