Transcript Internet QoS Protocols

Internet 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 to, but fundamentally different
from, the approach used in connectionoriented networks such as ATM
– 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 (uni-directional reservation)
Receiver-initiated
Maintains soft state
Different reservation styles
Transparent operation through nonRSVP routers
 Support for IPv4 and IPv6
 Intended for services associated with a
single flow (IntServ)







but can be extended (RFC 2430: PASTE) to
support aggregates of flows (DiffServ classes)
Chapter 18: Protocols for QoS Support
4
Multicasting Applications

Multimedia (live streaming)
QoS Attributes
– television, presentations, gaming, etc.

Teleconferencing
– voice and video

Database
– replication and updates

Distributed computing and real-time
workgroup
– exchange of results, files, graphics,
messages, etc.
Chapter 16b Multicasting
5
True Multicast

Source knows network location of
multicast group members
– identifies least cost path to reach each
member’s network
– establishes a partial spanning tree to
reach all group member networks
Source node sends single packet
along tree path
 Packet is replicated by routers at
each branch point in path

Chapter 16b Multicasting
6
Multicast Requirements





Unique multicast addressing scheme
– IPv4 “Class D” addresses: 1110, followed by
28-bit group identifier
– IPv6: 11111111, 3 flag bits, 4 scope bits, and
112-bit group identifier
Nodes must be able to translate between
multicast addresses and list of networks that
have members
Routers must translate between multicast
address and subnetwork addressing (e.g. MAC
multicast)
Must have mechanism for hosts to inform
routers of group membership/exclusion
Routers must have mechanism for determining
and applying multicast routing paths (multiple
outbound paths for the same received packet)
Chapter 16b Multicasting
7
Internet Multicast Service
Model
128.59.16.12 (m/c group member)
128.119.40.186
(source)
multicast
group
226.17.30.197
128.34.108.63
(m/c group member)
128.34.108.60
(m/c group member)
multicast group concept: use of indirection
– hosts addresses IP datagram to multicast
group
– routers forward multicast datagrams to
hosts that have “joined” that multicast group
Chapter 16b Multicasting
8
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
9
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
10
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
Could also
use DSCP or
MPLS FEC
– 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
Could also
use DSCP or
MPLS FEC
11
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
12
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 QoS
4. Forward request upstream (aggregate as
required)
Chapter 18: Protocols for QoS Support
13
RSVP Filtering Operation
X
Chapter 18: Protocols for QoS Support
X
R1, R2, R3, R4: forwarding routers
G1, G2, G3: multicast receivers
S1, S2: multicast senders
14
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
15
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})
16
Reservation Styles: Example
Multicast
Group
Sources
S1
S2
S3
Chapter 18: Protocols for QoS Support
Router
with
RSVP
capability
Multicast
Group
Receivers
17
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
18
RSVP Protocol Mechanisms
1.
2.
3.
4.
5.
Receiver sends IGMP Join message to local router. Router
forwards path (routing) information toward sender(s)
Sender(s) send RSVP Path message to the multicast group
Receiver gets Path message(s) and identifies sender(s)
Receiver send RSVP Resv messages along reverse path to
sender(s)
Receiver get Resv messages and begins sending data
Chapter 18: Protocols for QoS Support
19
QoS Protocols (cont.)
20
Multiprotocol Label Switching
“MPLS: The intelligence of
routing with the performance of
switching.”
Chapter 18: Protocols for QoS Support
21
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
22
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
23
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 line speeds.

supports QoS 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 integrated IP–ATM networks.
Chapter 18: Protocols for QoS Support
24
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/SDH) integration in optical switching.
– MPLS helps build scalable VPNs with trafficengineering capability.
Chapter 18: Protocols for QoS Support
25
MPLS Terminology Summary


Chapter 18: Protocols for QoS Support
26
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
toward 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
27
MPLS Operation
LIB (Library Information Base): Binds IP forwarding table to MPLS label.
Chapter 18: Protocols for QoS Support
28
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
29
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
or dynamically to balance load or provide different
levels of service for different FECs
Chapter 18: Protocols for QoS Support
30
MPLS Packet Forwarding
Label stacking?
LFIB (Label Forwarding Information Base): Binds MPLS label forwarding behavior.
Chapter 18: Protocols for QoS Support
31
MPLS Label Format &
Placement
Data Link
Frame
IEEE 802
MAC Frame
ATM
Cell
Frame Relay
Frame
Chapter 18: Protocols for QoS Support
32
MPLS Path Selection
Traffic Engineering
Class of Service
Chapter 18: Protocols for QoS Support
33
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
34
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
35
DiffServ with MPLS


RFC 3270: allows the MPLS network
administrator to map DiffServ Behavior
Aggregates (BAs) onto Label Switched Paths
(LSPs) in order to best match the DiffServ,
Traffic Engineering and protection objectives
within a particular network.
RFC 2430: A Provider architecture for
Differentiated Services Traffic Engineering
(PASTE)
– Merges Differentiated Services flow
aggregation with MPLS
– Uses RSVP for reserving capacity for
collections of flows with similar QoS
requirements
Chapter 18: Protocols for QoS Support
36
Real-Time Transport
Protocol (RTP)
37
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
38
Why Do We Need a Real Time
Protocol?


Ubiquity of real-time network applications:
–
–
–
–
–
–
audio and video conferencing, VoIP
live video distribution
remote medical diagnosis
command and control systems
distributed interactive simulations
real-time monitoring, security systems
Real-time applications require a closer coupling
between application functionality and the
network layer than is provided by TCP and UDP
alone. RTP provides:
– timing information
– data synchronization and sequencing
– mixing and translation of data streams
Chapter 18: Protocols for QoS Support
39
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
40
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
41
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
42
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
43
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 realtime application requirement
– no segment timing information available

UDP
– no segment timing or sequencing information
is available (or other general purpose real
time tools)
Chapter 18: Protocols for QoS Support
44
Real-Time Transport Protocol
(RTP)

Defined in RFC 3550 (STD 64) to provide mechanisms
needed to support real-time traffic in IP-based
networks,
– designed 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
45
RTP Architecture Concepts
From Data Communication and Networks, Forouzan, 4th Edition
Chapter 18: Protocols for QoS Support
46
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
47
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) of the
protocol stack to be tightly
coupled
– therefore, RTP is not
complete by itself… requires
application-layer information,
and includes some transport
layer capabilities itself (with
appropriate information in its
header)
Chapter 18: Protocols for QoS Support
48
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:
defines how a particular payload,
such as an audio or video encoding,
is to be carried in RTP.
Chapter 18: Protocols for QoS Support
49
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 of RTP are:
–
–
–
–
payload type identification
timestamping data
sequencing/synchronizing data
mixing/translating data
Chapter 18: Protocols for QoS Support
50
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: synchronizes and combines data from
multiple sources and forwards the new RTP
packet stream (e.g., multipoint conference)
– translator: converts input and resends in a
new format, or replicates for unicast
destinations (e.g., video or audio format)
51
Chapter 18: Protocols for QoS Support
RTP Mixers & Translators
speaker 1
speaker 2
Mixer
combined
audio
speaker 3
DV14-8 kHz
PCMA
audio
Translator
DV14-16 kHz
L16 Stereo
Chapter 18: Protocols for QoS Support
52
RTP Fixed Header
Supplied
by
a mixer
Chapter 18: Protocols for QoS Support
53
Some Standard Payload Types
(see RFC 3551)
Chapter 18: Protocols for QoS Support
54
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 3550)
–
–
–
–
QoS and congestion control
Source identification
Session size estimation and scaling
Session control
Chapter 18: Protocols for QoS Support
55
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 of RTCP “packets” (reports) are
defined
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
56
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(s)
Chapter 18: Protocols for QoS Support



The 75 kbps is equally
shared among receivers:
– With N receivers,
each receiver gets to
send RTCP traffic at
75/N kbps.
Sender(s) gets to send
RTCP traffic at 25 kbps.
Participant determines
RTCP packet transmission
period by calculating
average RTCP packet size
(across the entire
session) and dividing by
allocated rate.
57
RTCP Control Information

A typical RTCP transmission consists
of a number of RTCP “packets”
bundled into a single UDP datagram:
–
–
–
–
–

Sender Report (SR)
Receiver Report (RR)
Source Description (SDES)
Goodbye (BYE)
Application specific
Each has a fixed header followed by
report-specific data
Chapter 18: Protocols for QoS Support
58
RTCP Formats
Source Description
Receiver Report
RTCP BYE
Sender Report
Application-defined Packet
Chapter 18: Protocols for QoS Support
59
SDES Types
Chapter 18: Protocols for QoS Support
60