Download Multimedia Communication and Internet QoS

Multimedia Communication
and
Internet QoS
Hermann Hellwagner
Research Group Multimedia Communication (MMC)
Institute of Information Technology (ITEC)
Klagenfurt University,
University Austria
[email protected]
g
http://www.itec.uni-klu.ac.at/~hellwagn
G ö 29 April
Györ,
A il 2010
Hellwagner
Multimedia Communication and Internet QoS
1
Who am I?
ƒ Professor of Information Technology
Head of RG Multimedia Communication (MMC)
ƒ Research interests:
• Distributed multimedia systems
• Multimedia communication, quality of service (QoS)
ƒ Teaching:
• Computer organization, operating systems, computer networks
• Internet QoS,
QoS servers/clusters,
servers/clusters advanced topics in multimedia
communication
ƒ Professional services:
• Member of the Scientific Board of the Austrian Science Fund (FWF)
• Deputy Head of Austrian Delegation to ISO/IEC JTC1/SC29 WG11
(Moving Picture Experts Group - MPEG)
Hellwagner
Multimedia Communication and Internet QoS
2
Where do I come from?
Klagenfurt
g
Hellwagner
Multimedia Communication and Internet QoS
3
Where do I come from?
Hellwagner
Multimedia Communication and Internet QoS
4
Outline
1
Introduction: Motivation, QoS Requirements, Terminology,
Pi i l
Principles
2
Integrated Services (IntServ) and the Resource Reservation
P t
Protocol
l (RSVP)
3
Differentiated Services (DiffServ)
4
Multiprotocol Label Switching (MPLS)
5
Real-Time
Real
Time Multimedia Data Transport: Basic Protocols
6
Conclusions
Hellwagner
Multimedia Communication and Internet QoS
5
Literature: Books
ƒ Ina Minei, Julian Lucek
MPLS-Enabled Applications: Emerging Developments and New Technologies
Wiley 2008 (Second Edition)
ƒ Mihaela van der Schaar, Philip A. Chou
Multimedia over IP and Wireless Networks. Compression, Networks, and
Systems
Elsevier / Academic Press 2007
ƒ John Evans, Clarence Filsfils
Deploying IP and MPLS QoS for Multiservice Networks. Theory and Practice
Elsevier / Morgan Kaufmann 2007
ƒ Jitae Shin, Daniel C. Lee, C.-C. Jay Kuo
Quality of Service for Internet Multimedia
Prentice Hall 2004
ƒ Sanjay Jha, Mahbub Hassan
Engineering Internet QoS
Artech House 2002
ƒ F
Fred
d Halsall
H l ll
Multimedia Communications
Addison Wesley 2001
ƒ Ralf Steinmetz
Multimedia-Technologie. Grundlagen, Komponenten und Systeme
Springer 1998
Hellwagner
Multimedia Communication and Internet QoS
6
Literature: Journals and Conferences
ƒ IEEE Network
ƒ IEEE Communications Magazine
ƒ IEEE Communications Surveys & Tutorials:
http://www.comsoc.org/livepubs/surveys/index.html
ƒ IEEE Multimedia
ƒ IEEE Internet Computing: http://computer.org/internet/ (IC Online)
ƒ IEEE Transactions on Communications
ƒ IEEE Journal on Selected Areas in Communications
ƒ IEEE Transactions on Multimedia
ƒ IEEE/ACM Transactions on Networking
ƒ ACM Multimedia Systems
ƒ Numerous Conferences on Networking Topics
Hellwagner
Multimedia Communication and Internet QoS
7
Literature: Some WWW Resources
ƒ Internet Engineering Task Force (IETF): http://www.ietf.org
(incl many Working Groups defining QoS mechanisms)
(incl.
ƒ IEEE Communications Society: http://www.comsoc.org
ƒ Qbone Internet2 Initiative: http://qbone.internet2.edu/
http://qbone internet2 edu/
ƒ Survey on Internet QoS: http://user.chollian.net/~son6971/qos/qos.htm
ƒ Prof. Raj Jain‘s Web page: http://www.cs.wustl.edu/~jain/
ƒ Prof. Henning Schulzrinne‘s Web page:
http://www.cs.columbia.edu/~hgs/
ƒ “Classical“
Classical Networking Reading Lists (incl.
(incl QoS):
http://www.cs.columbia.edu/~hgs/netbib/standard.html
ƒ Prof. Klara Nahrstedt‘s Web page:
htt // i
http://cairo.cs.uiuc.edu/~klara/home.html
i
d / kl
/h
ht l
Hellwagner
Multimedia Communication and Internet QoS
8
1
Introduction
Motivation, QoS Requirements,
Terminology, Principles
Hellwagner
Multimedia Communication and Internet QoS
9
The Challenge: Multimedia
ƒ Multimedia
• Handling
H dli off a variety
i t off presentation
t ti media
di
• Acquisition, storage, retrieval, transmission, presentation, and
perception of different data types:
• Text, graphics, voice, audio, video, animation, VR/AR, .....
• Movie: video + audio + script + descriptive (meta-) data + .....
ƒ New applications
• Multimedia has become pervasive in applications
• Technology push and end user pull
ƒ Challenges
g
• Storage: many GBs per video
• Timely, continuous (real-time) and correct (synchronized) delivery
• Indexing, searching, retrieval: 1000s of videos?
Hellwagner
Multimedia Communication and Internet QoS
10
A Movie as a Set of Elementary Streams
Hellwagner
Multimedia Communication and Internet QoS
11
The Real Challenge: Multimedia over IP Networks
Gaming
VoIP
I t
Internet
t
Wireless
Browsing
Video
Conference
Video Clip
Attachment
E-mail
Music
g
Streaming
Hellwagner
Information
Digital Photos
Movie
Search
Finance,
Streaming
St
i
Brokerage
Multimedia Communication and Internet QoS
12
Some Applications: Broad-/Multicast and (N)VoD
ƒ Broadcast or Multicast Video
• Store-and-playback or live content
• Enhanced services, reliability,
availability and maintenance
availability,
Internet
ISP
Content
provider
ƒ Video-on-Demand (VoD)
Clients
• Users can select from a list of choices (EPG), maybe preview
• Interaction via set-top box + remote control or via PC
ƒ Near Video-on-Demand (NVoD)
• Popular videos are broadcasted periodically (“carousel”)
• VCR control is more difficult
Hellwagner
Multimedia Communication and Internet QoS
13
Some Applications: Collaborative Work
ƒ Videoconferencing
• Geographically distributed virtual meetings (presenters + audience)
• Diverse audio/visual (A/V) input and output devices
• Presenters can broadcast speech and graphics
graphics,
maybe also real-time video
• Hard requirements on the infrastructure, e.g., logging facility
ƒ CSCW System
Distributed content providers
• All of the above plus, e.g.,
joint work on a document
Internet
ƒ Teleteaching / Telelearning
• Potentially many participants
ƒ Gaming
Control
Hellwagner
Multimedia Communication and Internet QoS
14
Some Data Rates and Technology Data
Multimedia Source
Mb/s
GB/h
Telephone (PCM)
0.064
0.003
MP3 music
0 14
0.14
0 06
0.06
Fast Ethernet
100
Audio CD
1.4
0.62
EIDE disk
133
MPEG-1 movie
1 - 1.5
0.66
ATM OC
OC-3
3
156
MPEG-2 movie
4
1.76
320
Digital camcorder (720 x 480)
25
11
SCSI Ultra Wide
disk
IEEE 1394
(FireWire)
400
Gigabit Ethernet
1000
SCSI Ultra-160
1280
Uncompressed TV (640 x 480)
Uncompressed HDTV
(1280 x 720)
Hellwagner
221
648
97
288
Device
Mb/s
WiFi LAN (802.11b)
11
Multimedia Communication and Internet QoS
15
How Much Does Compression Help?
Multimedia Source
Resolution
[cols x lines x fps]
Raw bit rate
[Mb/s]
Compressed
bit rate [Mb/s]
480 x 480 x 24
133
3-6
480 x 480 x 29
29.97
97
168
4-8
576 x 576 x 25
199
4-9
HDTV video
1920 x 1080 x 30
1493
10 - 30
ISDN videophone (CIF)
352 x 288 x 29.97
73
0.064 - 1.92
PSTN videophone
p
(QCIF)
(Q
)
176 x 144 x 29.97
18
0.01 - 0.03
Film (USA and Japan)
NTSC video
PAL video
Hellwagner
Multimedia Communication and Internet QoS
16
Is Raw Bandwidth the “Silver Bullet“?
ƒ Bandwidth (throughput): important, but not sufficient
• Example: telephone over satellite:
-
Enough bandwidth, but:
-
R
Response
nott iimmediate
di t
ƒ Equally important: delay (latency) and jitter (delay variance):
• Critical for timely, continuous delivery and (soft) real-time playback
Sender
Receiver
Delay
Jitter
Time
ƒ Additional criteria: stream synchronization, reliability, cost, .....
Hellwagner
Multimedia Communication and Internet QoS
17
Example Audio Application
E g Voice over IP (VoIP)
E.g.,
Microphone
Routers and switches with
queues of variable lengths
Sampler
p ,
A D
converter
Buffer,
D A
Speaker
ƒ Voice sample once every 125µs
ƒ Each sample has a playback time
ƒ Packets experience variable delay in network
ƒ Add constant “insurance” factor to playback time: playback point
ƒ For voice, data arrival within ~300
300 ms is tolerable
Hellwagner
Multimedia Communication and Internet QoS
18
Example Audio Application: Delay and Jitter
Audio application (e.g., VoIP) will most probably use:
ƒ Asynchronous transmission
ƒ Statistical multiplexing
→ Optimized use
off b
bandwidth
d id h
→ Increases delay
→ Introduces jitter
Hellwagner
Multimedia Communication and Internet QoS
19
Se
equence number
Example Audio Application: Playback
Packet
arrival
Packet
generation
Buffer drained,
drained late
packets are discarded
Network
delay
Buffer
Playback
Time
Hellwagner
Multimedia Communication and Internet QoS
20
Distribution of Delays on the Internet
90% 97% 98%
99%
Packets [%]
97% of the packets has
100 ms delay or less
1% of the packets has
more than 150 ms delay
50
100
150
200
Delay
e ay [[ms]
s]
Hellwagner
Multimedia Communication and Internet QoS
21
Example MPEG-4 Video Stream
ƒ Frame size varies considerably over time:
• Due to frame
patterns (I, P, B)
Frame Sizes
15000
I−Frame
P−Frame
B−Frame
• Due to different
scenes
Æ Burstiness
10000
Frame
eS
Size in Bytes
Æ Variable bit rate
t ffi
traffic
5000
0
Hellwagner
0
200
400
600
800
1000
Frame Numbers
Multimedia Communication and Internet QoS
1200
1400
1600
1800
22
QoS Definition
Quality of Service :=
“Well-defined and controllable behavior of a system according
to quantitatively measurable parameters.“ [ISO]
Layer model, due to variety off possible views:
Use
(Perception QoS)
Application
pp
(Application QoS)
System
(Device QoS)
MM Devices
Hellwagner
(System QoS)
(Communication QoS)
Local Processing
Network
Multimedia Communication and Internet QoS
23
QoS Parameters: Examples
Services can be described both qualitatively and quantitatively:
QoS Layer
Application QoS
System
y
Q
QoS
Comm. QoS
Device QoS
Hellwagner
QoS Parameters (Examples)
Media quality
Media characteristics
Media transmission characteristics
Th
Throughput
h t
Latency
Response time
Error detection and correction characteristics
Memory and buffer specification
Inter-stream synchronization
Sequencing requirements
Error handling mechanisms
Scheduling mechanisms
Packet size
Average/maximum packet rate (throughput)
Burstiness
Processing time for packet in network node
Jitter - “ Average/maximum disk access time
Data transfer rate of disk
Description
Parameters cover application-related
requirements
Parameters cover requirements on
OS and communication services:
- Quantitative parameters
- Qualitative parameters
Parameters cover low-level requirements on
network services
Parameters cover time-related and
performance requirements on individual
devices
Multimedia Communication and Internet QoS
24
QoS Parameters: Example Transport System
Common parameters concerning the transport system:
ƒ Throughput
• Maximum long-term rate [b/s]
• Maximum burst size
• Maximum packet size
Delay
Throughput
ƒ Delay / latency
• Maximum end-to-end delay for transmission of one packet
• Jitter := maximum variance of transmission times
Loss
ƒ Loss / reliability
• Loss rate := maximum number of losses per time interval
• Loss size := maximum number of consecutively lost packets
• Sensitivity class: ignore / indicate / correct losses
ƒ But also: security, costs, stability (resilience)
Hellwagner
Multimedia Communication and Internet QoS
25
Typical QoS Requirements
QoS
Max latency
Max.
[s]
Max. jitter
Max
[ms]
Throughput
[Mb/s]
Bit error
rate
Packet error
rate
Voice
0.25
10
0.054
< 10-3
< 10-4
Video (TV)
0.25
100
100
< 10-2
< 10-3
Compressed
video
0 25
0.25
100
2 - 10
< 10-66
< 10-99
Image
1
-
2 - 10
< 10-4
< 10-9
Data
(file transfer)
1
-
2 - 100
0
0
0.001 – 1
-
< 10
0
0
Real-time data
(control)
Hellwagner
Multimedia Communication and Internet QoS
26
How to Provide End-to-End QoS in a Complex System?
In the processing nodes and ...
... across the network (protocol zoo)
Hellwagner
Multimedia Communication and Internet QoS
27
By Managing Resources in an Appropriate Way!
Services (and Qos) are provided by resources:
• Active resources: CPU
CPU, I/O subsystem
subsystem, network adapter
adapter, router
router, ...
• Passive resources: provide “space“; file system, buffer, link b/w, ...
C
Common
parameter:
t
capacity
it Æ allows
ll
quantitative
tit ti description
d
i ti
Compute resources
Application
(source)
Hybrid resources
(e.g., gateway)
System SW
CPU
QoS before
transmission
Hellwagner
System SW
Memory
Data in
CPU
Networks
System SW
Memory
Network
Net
o k
resources
Application
(sink)
Networks
Multimedia Communication and Internet QoS
CPU
Memory
Data out
QoS after
transmission
28
Resource Management: Goal
Starting point: scarce, but sufficient resources
R
Requirements
i
t
“Window of Scarcity“
Interactive
video
Insufficient resources
Audio
(CD quality)
Scarce
resources
Data
transfer
Sufficient resources
Remote
login
1980
1990
2000
2010
Hardware
resources
in year ....
Goal: provide best service at lowest possible resource
consumption / costs
Hellwagner
Multimedia Communication and Internet QoS
29
Resource Management: Approaches
Approaches (in other words: relationship QoS – resources):
1. Resource reservation
Phase 1: Setup
User‘s QoS
requirements
Rejection
j
Calculation
Admission control
QoS negotiation
Resource
reservation
Q S guarantees
QoS
t
to user
Phase 2: Processing
g / Transmission
Data arrival
(in streams)
QoS enforcement by resource scheduling,
traffic monitoring, policing, shaping, renegotiation, ...
2. Adaptation: data streams (and QoS) are adapted according to status
of resources; e
e.g.,
g CPU/network load
load, link bandwidth
bandwidth, congestion,
congestion ...
Hellwagner
Multimedia Communication and Internet QoS
30
Resource Management: Architecture
“Generic“ node architecture:
Control /
Signaling
Resource
manager
Resource
monitor
Data
Hellwagner
Reservation
R
ti
database
Resource
specific
information
Resource
scheduler
Multimedia Communication and Internet QoS
31
Static Resource/QoS Management Functions
ƒ QoS specification
• Qualitatively and quantitatively,
quantitatively on various layers
• E.g., deterministic ranges for delay, throughput, and reliability
parameters
ƒ Negotiation
• Goal: contract b/w user‘s app. and system
y
((service/QoS provider))
• Application may accept lower QoS level for lower cost
ƒ Admission control
• Are requested resources available and can QoS be provided?
• If test is passed, the system has to guarantee the promised QoS
ƒ Resource reservation
• May
y be necessary
y to p
provide g
guaranteed QoS
• Dominating approach today (conceptually, not in implementations)
Hellwagner
Multimedia Communication and Internet QoS
32
Dynamic Resource/QoS Management Functions
ƒ Monitoring
• Notices deviation from QoS level
• At a certain level of granularity (e.g. every 100 ms)
ƒ Policing
• Detects participants not adhering to the contract
• E.g. source sends faster than negotiated (e.g. 30 fps)
ƒ Maintenance
• Attempt to sustain the negotiated QoS
• E.g. the system acquires more resources
ƒ Renegotiation / adaptation
• User may be able to accept lower QoS and renegotiate with system
• Or/and tries to adapt data stream(s)
Hellwagner
Multimedia Communication and Internet QoS
33
Setup Phase: QoS Specification
Example: sample ATM QoS parameters (for IP, “cell“ ≅ “packet“)
ƒ Traffic descriptor: provided by user to describe traffic (via QoS API)
PCR
Peak Cell Rate
Max. cell rate input into network
SCR
Sustained Cell Rate
Avg cell rate
Avg.
MCR
Minimum Cell Rate
Min. cell rate (expected by user)
MBS
Maximum Burst Size
Max. number of back-to-back cells
ƒ Service descriptor: user‘s QoS requ‘s, negotiated b/w user & network
CTD
Cell Transfer Delay
Min. and max. cell delay
CDVT
Cell Delay Var. Tolerance
Max. acceptable jitter (for PCR, SCR)
CLR
Cell Loss Ratio
Max. ratio of cells lost
ƒ Service parameters: QoS delivered, non-negotiatable, measured
CDV
Cell Delay Variation
Actual variance in cell delays
CER
Cell Error Ratio
(Max.) Ratio of erroneous cells
CMR
Cell Misinsertion Ratio
(Max.) Ratio of mis-delivered cells
Hellwagner
Multimedia Communication and Internet QoS
34
Setup Phase: QoS Negotiation
Example: Trilateral peer-to-peer QoS negotiation
ƒ QoS requirement: QoSminreq and upper bound QoSbound>QoSminreq
ƒ Goal: agreement of all participants on value QoScontract
Caller
Callee
QoSbound
QoScontract
QoSminreq
4
Connect
Confirm
1
Connect
Request
QoSavail
2
Connect
Indication
QoScontract
3
Connect
Response
Service
Provider
Hellwagner
Multimedia Communication and Internet QoS
35
Setup Phase: Admission Control
Check whether requested resources are and will be available
Especially important for shared resources, like:
• CPU
• Network
N t
k paths
th
• Buffer space
Example: ATM connection admission control (CAC)
Simple rule: admit new connection
k with
i h bandwidth
b d id h requ. B(k) iff
B(k) + Σi B(i) ≤ Btotal
Available
n/w resources
Traffic descr.
CAC
Service descr.
descr
Admitted
Network
connections
[B(k) may pertain to PCR or SCR]
Must be strongly related/coupled to
costs, otherwise “over provisioning“
Hellwagner
Rejected
j
connections
Multimedia Communication and Internet QoS
36
Setup Phase: Resource Reservation
Fundamental concept for reliable enforcement of QoS guarantees
Variants:
Time
ƒ Pessimistic reservation:
Needs of
appl. 1
• Relies on worst-case assumptions
• Results in g
guaranteed QoS
Unused
b/w Needs of
appl 2
appl.
• E.g., bandwidth reservation using PCR
ƒ Optimistic reservation:
• Relies on statistical multiplexing
• Results in statistical QoS
Conflict!
• Can lead to QoS violations and congestion
• E.g.,
E g bandwidth reservation using SCR
Hellwagner
Multimedia Communication and Internet QoS
37
Setup Phase: Reservation Protocols
Reservation protocols in general referred to, and combined with,
signaling protocols (e.g., for connection establishment)
Two phases:
1. Reservation is requested and checked (admission control)
2. Reservation is actually performed, if checks were successful
Sender
User
Q & conn.
QoS
requested
Receiver
Host s resource
Host‘s
manager
Host s resource
Host‘s
manager
Reservation
accepted
Reservation
requested
User
QoS & conn.
accepted
Network
QoS & conn.
established
Hellwagner
Reservation
done
Reservation to
be performed
Multimedia Communication and Internet QoS
QoS & conn.
acknowledged
38
Processing Phase
Enforce QoS by:
ƒ Resource scheduling
ƒ QoS / traffic monitoring
ƒ Maintenance of resource reservations
ƒ Potential acquisition of new resources
ƒ Traffic shaping
g
ƒ Traffic policing
ƒ QoS
Q S feedback
f db k and
d traffic
t ffi adaptation
d t ti
ƒ Potential QoS renegotiation
Hellwagner
Multimedia Communication and Internet QoS
39
Traffic Shaping and Policing (1)
ƒ Mechanisms to ensure that traffic conforms to QoS contract,
d
does
nott overload
l d network,
t
k etc.
t
ƒ Traffic shaping:
ƒ Traffic policing:
• Usually done in hosts
• Usually done in switches/routers
• Change shape of traffic
by e.g. postponing packets
• Cut off traffic to conform to contract
by e.g. discarding packets
Switch /
router
Host
PCR
Traffic
T
ffi
shaping
Traffic
T
ffi
policing
t
Original traffic
Hellwagner
t
Shaped traffic
Multimedia Communication and Internet QoS
40
Traffic Shaping and Policing (2)
ƒ Major goal: protect
• network resources and
• other traffic
against congestion and conflicts, caused by ill-behaving
ill behaving traffic sources
ƒ Mechanisms:
• M
Marking
ki packets/cells
k t / ll as candidates
did t for
f later
l t discarding
di
di
• Immediate discarding of packets/cells (traffic policing)
• Buffering
g of packets/cells in host ((traffic shaping)
g)
ƒ How traffic can be shaped (ATM examples):
• Reduction of PCR ((Peak Cell Rate))
• Reduction of CDV (Cell Delay Variation)
• Reduction of MBS (Maximum Burst Size), i.e., limitation of bursts
Hellwagner
Multimedia Communication and Internet QoS
41
Traffic Shaping / Policing: Leaky Bucket Algorithm (1)
Single algorithm for both traffic shaping and policing:
L k B
Leaky
Bucket
k t Al
Alg. or (i
(in ATM tterms)) G
Generic
i Cell
C ll Rate
R t Alg.
Al (GCRA):
(GCRA)
Each arriving packet/cell is classified as
• conforming (arriving within valid time interval)
or
• non-conforming (arriving too early)
Two parameters:
p
• Increment T: packet/cell interarrival time;
e.g., T = 1 / PCR
• Limit L: tolerated variance thereof;
e.g., L = CDVT
Æ GCRA (T, L)
Hellwagner
Multimedia Communication and Internet QoS
42
Traffic Shaping / Policing: Leaky Bucket Algorithm (2)
Notation:
• ta(k): arrival time of packet/cell k
• TAT: theoretical arrival time of next packet/cell
GCRA (T,
(T L):
Arrival of cell k at time ta(k)
Cell non-conforming
Y
ta(k) < TAT – L ?
N
Initially: TAT := ta(1)
Hellwagner
TAT := max(t
( a((k),TAT)
),
)+T
Cell conforming
Multimedia Communication and Internet QoS
43
Traffic Shaping / Policing: Leaky Bucket Algorithm (3)
Time
T
Illustration:
L
Cell
(a)
1
Maximal case.
Cell 2 arrives T sec after Cell 1
cell 3 expected
at t2 + T
T
2
t2
t1
1
(b)
2
t2
t1
(c)
Slow sender.
Cell 2 arrives > T sec after cell 1
T
1
t1
2
Fast sender.
Cell 2 arrives up to L sec early
t2
T
(d)
1
2
Cell 3 expected
at t2 + T
Cell 3 expected
at t1 + 2T
Very fast sender.
Cell 2 arrives prior to t1 + T – L.
Cell is nonconforming.
t1
Hellwagner
Cell 3 expected
at t1 + T
Multimedia Communication and Internet QoS
44
Traffic Shaping / Policing: Leaky Bucket Algorithm (4)
“Leaky bucket“ metaphor and interpretation:
Time
0
T
2T
3T
4T
5T
T-ε
1
T-ε
T-ε
2
T-ε
T-ε
3
4
5
Nonconforming
cell
6
ε
2ε
3ε
4ε
5ε
(a)
Fluid
luid level
Bucket limit
T
0
Hellwagner
(b) and Internet QoS
Multimedia Communication
45
Traffic Shaping / Policing: Leaky Bucket Algorithm (5)
Use of GCRA(T,L):
1. Formal definition and policing of CBR and VBR traffic
(Constant / Variable Bit Rate) re. PCR and CDVT:
GCRA (1/PCR, CDVT)
2 Formal definition and optional policing of VBR traffic
2.
re. SCR and burstiness:
GCRA (1/SCR, BT)
where BT = (MBS – 1) (1/SCR – 1/PCR)
(BT ... Burst Tolerance
MBS ... Maximum Burst Size)
3. Traffic shaping re. these parameters
Hellwagner
Multimedia Communication and Internet QoS
46
Traffic Shaping / Policing: Leaky Bucket Algorithm (6)
Characteristics and alternative notation / illustration:
ƒ Simple isochronous algorithm
ƒ β ... bucket size
R ... constant output
(data rate)
Data
D
t tto be
b ttransmitted
itt d
(variable input)
ƒ Problems with bursts:
Æ packet losses
β
Control
(regulation)
Hellwagner
R
Multimedia Communication and Internet QoS
Leaky Bucket
Data transmitted
(constant drain)
47
Traffic Shaping / Policing: Token Bucket Algorithm
Token Bucket Algorithm:
ƒ Improvement
I
t over Leaky
L k Bucket
B k t tto tolerate
t l
t limited
li it d burstiness
b
ti
ƒ Data transmission consumes tokens
ƒ Bursts are limited in interval T by: β + T · R
(R ... token placement rate = average packet rate)
ƒ Reduction of data loss rate:
separate data buffer
R
β
D
Data
b
buffer
ff
Hellwagner
Multimedia Communication and Internet QoS
Token Bucket
Average
g data rate R
48
Traffic Shaping / Policing: Token Bucket Example
Bandwid
dth [Mbit//s]
Example: two traffic flows with equal average data rate,
b t different
but
diff
t Token
T k Bucket
B k t descriptions
d
i ti
2
Flow B
1
Flow A
1
2
3
Time [s]
4
Flow A: CBR traffic with R = 1 Mbit/s, β = 1 byte
Fl
Flow
B:
B VBR traffic
t ffi with
ith R = 1 Mbit/
Mbit/s, β = 1 Mbit
Hellwagner
Multimedia Communication and Internet QoS
49
Traffic Shaping / Policing: Token + Leaky Bucket
Token Bucket with Leaky Bucket rate control:
ƒ Smoothing of bursts of Token Bucket by Leaky Bucket at output
ƒ C ... maximum data rate
R ... average data rate
ƒC>R
R
β
Token Bucket
Leaky Bucket
Data buffer
Hellwagner
β
Multimedia Communication and Internet QoS
C
50
2
Integrated Services (IntServ)
and the
(
)
Resource Reservation Protocol (RSVP)
Hellwagner
Multimedia Communication and Internet QoS
51
IntServ and RSVP
ƒ Early
y ((mid 90‘s)) IETF standard for end-to-end QoS p
provisioning:
g
• Extension to Internet architecture
• For forthcoming real-time applications
• E.g., packet voice, packet video, distributed simulation
ƒ QoS
Q S for
f particular
ti l data
d t / traffic
t ffi flows
fl
ƒ Flows categorized into service classes
ƒ Generally
y requires
q
reservation of network resources in routers
along the path(s) of the flows as well as in the end hosts
Hellwagner
Multimedia Communication and Internet QoS
52
IntServ Services Classes
•
Fixed delay bound
•
For A/V, no packet arrives after its play back time
•
Early packets must be buffered
•
For “hard“ real-time applications
2. Controlled load service
•
Probabilistic delay bound
•
Gives the illusion of reserved channels,
under reasonable load
•
Based on routers’ queuing alg. + admission control
•
For delay-adaptive applications
R
Resource
e consum
mption
1. Guaranteed service
3. Best effort service
Hellwagner
•
Available per default
•
For “elastic“ (adaptive) applications
Multimedia Communication and Internet QoS
53
Components / Mechanisms (1)
Setup, routing, background control (on end systems, impl. on user-level)
Traffic control (on end systems, impl. in the OS kernel)
Hellwagner
Multimedia Communication and Internet QoS
54
Components / Mechanisms (2)
1. Reservation setup (→ RSVP)
Passes the QoS request from originating end system to each router
along the data path or, in case of multicasting, along the branches of
the delivery tree
C
Consists
i t of:
f
•
•
FlowSpec: defines the desired QoS
FilterSpec: defines the subset of flows to receive this QoS
2. Admission control
All
Allocates
t the
th necessary node
d and
d link
li k resources to
t satisfy
ti f requ. QoS
Q S
Establishes state for flow, if accepted
3. Policy control
Ensures that QoS request and reservation is administratively possible
(Routing is separate, not part of IntServ concept.)
Hellwagner
Multimedia Communication and Internet QoS
55
Components / Mechanisms (3)
4. Packet classifier
Sorts incoming data packets forming flows into appropriate
scheduling classes, based on FilterSpec
St t (i
State
(i.e., filt
filter)) established
t bli h d by
b RSVP
5. Packet scheduler
Link-layer QoS mechanism to provide requested QoS
(queuing mechanisms in routers, not covered here)
Multiplexes packets from different reserved flows onto the outgoing
links, based on FlowSpec
State established by RSVP
Hellwagner
Multimedia Communication and Internet QoS
56
FlowSpec
ƒ RSpec: characteristics requested from network, e.g.,
•
Guaranteed service: delay bound as parameter
•
Controlled load: no additional parameters
ƒ TSpec: traffic characteristics of the flow, e.g.,
•
Average bandwidth and burstiness
•
U
Usually
ll specified
ifi d by
b a token
t k b
bucket,
k t e.g.,
M
Mbit/s
R = 1 Mbit/s, β = 1 Mbit
Same avg. rates,
diff. token buckets
3
R = 1 Mbit/s, β=1 byte
Flow B
2
1
Flow A
1
Hellwagner
Multimedia Communication and Internet QoS
2
3
s
4
57
RSVP: Features (1)
RSVP ...
ƒ ... is a control (signaling) protocol, not a routing protocol
ƒ ... is
i used
d by
b hosts
h t to
t requestt specific
ifi QoS
Q S from
f
the
th network
t
k
ƒ ... is used by routers to deliver QoS requests and to establish
and maintain states to provide the requested services
ƒ ... supports
pp
heterogeneous
g
hosts, QoS requests,
q
links, etc.
ƒ ... supports unicast and multicast (in fact, multipoint-to-multipoint communication), i.e., uses IP multicast for data distribution
ƒ ... does not deliver messages reliably
Hellwagner
Multimedia Communication and Internet QoS
58
RSVP: Features (2)
RSVP ...
ƒ ... uses receiver-initiated reservations
• PATH and RESV messages
• Receivers
R
i
explicitly
li itl request/start
t/ t t reservation
ti
• No need for senders to keep track of many receivers (for multicast)
• Merging of reservation requests possible
ƒ ... uses soft state in the routers and connectionless model
• States
St t time
ti
outt automatically
t
ti ll (e.g.,
(
after
ft 1 minute)
i t )
• Can be (and need to be) refreshed periodically
• Responsibility of reservation maintenance is in the end hosts
• Modifications of reservations possible
ƒ is therefore robust and adaptive against route and multicast
group membership changes
Hellwagner
Multimedia Communication and Internet QoS
59
Multipoint-to-Multipoint Communication Model
ƒ Basic communication model: simplex distribution of data
from m sources to n receivers (same destination)
ƒ Such an m-to-n flow is called RSVP session
ƒ Examples: video conference: m = n; broadcast: m = 1, n >(>) 1
ƒ Logical definition of an RSVP session:
(Destination IP address, IP protocol ID, destination port)
ƒ To select a subset of the traffic in a session,
e.g., particular sender(s) (=: FilterSpec):
(Source IP address, source port)
Hellwagner
Multimedia Communication and Internet QoS
60
Reservations: Basic Protocol (1)
PATH and RESV messages:
PATH
Hellwagner
RESV
Multimedia Communication and Internet QoS
61
Reservations: Basic Protocol (2)
ƒ Source transmits PATH message:
• Conveys TSpec of the source
• Routers figure out the reverse path
• Sent e.g.
e g every 30 seconds
ƒ Destination responds with RESV message:
• Conveys TSpec and RSpec (FlowSpec) of the receiver
• Routers on the path try to make appropriate reservations
ƒ In case of router or link failure:
• New route will be automatically established by repeated PATHs
• Reservation will be also automatically renewed on the new path
• Soft state on old path will time-out
Hellwagner
Multimedia Communication and Internet QoS
62
Reservations: Merging Reservations
ƒ In case of multicast, reservation requests can merge
as they travel up the delivery tree
ƒ Example:
1 Mbps
1 Mbps
ƒ “Largest“ FlowSpec will arrive
at sender(s): Least-Upper-Bound (LUB)
0.5 Mbps
1 Mbps
0 5 Mbps
0.5
ƒ Service-specific
S
i
ifi routines
ti
required
i d to
t perform
f
FlowSpec
Fl S
merging
i
Hellwagner
Multimedia Communication and Internet QoS
63
RSVP Drawback: Poor Scalability
State is required for each individual flow!
Example:
• Optical link @ 2.5 Gbps
• We can multiplex
(2.5 * 109) / (64 * 103) = 39000
ISDN flows (64 kbps,
kbps e.g.,
e g voice) onto this link
Per-flow management requires huge memory and CPU resources!
So revert to best-effort service model again?
S
g
• Requires (almost) no state about individual flows
• Scales well,, since “only“
y bandwidth and routing
g tables
have to grow
Hellwagner
Multimedia Communication and Internet QoS
64
3
Differentiated Services (DiffServ)
Hellwagner
Multimedia Communication and Internet QoS
65
IntServ/RSVP Review: Major Characteristics
ƒ Per-flow signaling and reservation
ƒ Per-flow
Per flow service state at every hop (router)
ƒ Strict, end-to-end QoS guarantees
ƒ Focus on multicast
ƒ Virtually connection oriented
Hellwagner
Multimedia Communication and Internet QoS
66
IntServ/RSVP Review: Problems and Drawbacks
ƒ Complexity:
• Reservation p
protocols and structure complicated
p
- Lot of message passing; coordination problems
• Heavy-weight state at every router
- Processing
P
i and
d memory resources required
i d
ƒ Scalability problem:
• Lots
L t off flows
fl
traverse
t
core (backbone)
(b kb
) routers
t
ƒ Interoperability problems:
• End-to-end
End to end mechanisms
ƒ Deployment?
Lots of flows
Backbone
Hellwagner
Multimedia Communication and Internet QoS
67
Basic Ideas Toward a More Light-Weight Model
ƒ Support QoS end-to-end
ƒ But keep per-flow state and packet forwarding overhead
out of the core
→ Keep the architecture simple within the backbone,
permit
it hi
higher
h complexity
l it att edge
d routers
t
ƒ Some data is more important than other data
ƒ Specify relative priorities of packets
ƒ Charged differently for high and low priority classes
→ Just provide for service differences,
no explicit guarantees
ƒ Get rid of complexity of per-flow signaling & state maintenance
→ Deal with flow aggregates rather than individual flows
Hellwagner
Multimedia Communication and Internet QoS
68
DiffServ Goals
ƒ Simpler than IntServ
ƒ Lightweight, scalable service discrimination
suitable for network backbones
• No
N per-flow
fl
signaling
i
li
and
d resource allocation
ll
ti
• No per-flow state
• Separation
p
of service from signaling
g
g
ƒ Aggregation of traffic into priority classes
• Focus on aggregates,
aggregates not flows
• Customer agreements are relatively static
• Ability to charge differently for different services
ƒ Simple system at first, expand if needed in future
• Allow for incremental deployment
• Chosen for Internet2 QoS
Hellwagner
Multimedia Communication and Internet QoS
69
DiffServ Overview (1)
ƒ Exploit edge/core router distinction for scalability
• Policing at edge to get services (complex)
• Forwarding in core to realize services (simple, fast)
ƒ Relative-priority scheme
• Packets are marked with “behavior” (essentially, priority) ...
• ... and treated according to small set of packet-forwarding schemes
ƒ Abstract/manage each network’s resources → bandwidth brokers (BBs)
BB
Hellwagner
BB
Multimedia Communication and Internet QoS
70
DiffServ Overview (2)
ƒ Applications contract for specific QoS traffic profiles
• Traffic is policed at network periphery (leaf routers) ...
• ... and assigned to different service classes (packets marked) ...
• ... according
g to Service Level Agreements
g
(SLAs)
(
)
between customer and ISP
ƒ Networks (“clouds”) contract for aggregate QoS traffic profiles
• Aggregates are policed at network-network boundaries
(edge routers) ...
• ... according
di to
t simple,
i l bilateral
bil t
l business
b i
agreements
t
ƒ Core routers apply few, simple per-hop fwd. behaviors (PHBs)
• Indicated in packet header
• Applied to PHB traffic aggregates (service classes)
ƒ Policing rules + PHBs = range of services
Hellwagner
Multimedia Communication and Internet QoS
71
DiffServ Network Model
Bandwidth Brokers
(perform admission control,
manage network resources,
configure leaf and edge devices)
Source
BB
Destination
BB
Core
routers
Leaf Router
(police, mark flows)
Egress
Edge Router
(shape aggregates)
DiffServ (DS) Domain
(separate admin. unit)
Ingress Edge Router
(classify, police, mark aggregates)
Hellwagner
Multimedia Communication and Internet QoS
72
DiffServ Domain
DS Domain
(e.g., ISP’s network)
IInterior
t i
Router
Individual
flows
Ingress
Router
Traffic conditioning,
MF classification
Hellwagner
Egress
Router
Traffic
aggregates
BA classification,
PHB-based forwarding
PHB-based forwarding,
traffic shaping, pre-marking
Multimedia Communication and Internet QoS
73
Service Level Agreements (SLAs)
Agreement customer/ISP — ISP about traffic and services:
• Economic and technical specifications (SLSs)
• Static vs. dynamic
• Quantitative vs. qualitative (relative priorities)
Service Level Specifications (SLSs):
• Detailed technical specifications of QoS parameters
• Contain Traffic Conditioning Agreements/Specs. (TCAs/TCSs):
- Detailed service parameters, e.g., throughput, max. delay,
max. jitter, packet loss rate
- Traffic profile, spec‘d e.g. by token bucket
- Scope of service: ingress - egress routers
- What happens to non-conforming packets?
- Where is traffic marking and shaping being performed?
- ....
Hellwagner
Multimedia Communication and Internet QoS
74
Example Service Levels
Initial proposal, not standardized:
ƒ Premium Service: low delay,
delay low jitter
ƒ Assured Service: better reliability than best-effort service
→ Initial two-bit DiffServ model ((P-bit and A-bit))
In addition, only given as example:
ƒ Olympic Service: three tiers with
ith decreasing q
quality
alit
• Gold
• Silver
• Bronze
DiffServ defines only DS field and PHBs:
• Expedited Forwarding PHB
• Assured Forwarding PHB
Support/mapping of these services levels to PHBs required
Hellwagner
Multimedia Communication and Internet QoS
75
Premium Service
Defines a virtual leased line: fixed maximum bandwidth,
available when needed:
• Conservative allocation of resources:
-
Provisioned according to peak capacity profiles
• Shaped at network boundaries to remove bursts
• Out-of-profile packets are dropped
• Qualitative
Drop always
Fixed Bandwidth
Hellwagner
Multimedia Communication and Internet QoS
76
Assured Service
Defines a “better” best-effort line:
• Resources statistically provisioned:
- Provisioned according to expected capacity usage profiles
• In-profile traffic is “unlikely” to be dropped
• Out-of-profile packets get best-effort delivery
• Qualitative
Drop if congested
Uncongested
Congested
Assured Service
Hellwagner
Multimedia Communication and Internet QoS
77
Two-Bit DiffServ Border (Leaf) Router Functionality
Premium Service:
Token
Bucket
Wait
for
token
Packet Input
Set
P-bit
Packet Output
Data Queue
Assured Service:
Packet Input
Token
Bucket
No token
Test if Token Set
token
A-bit
Packet Output
Data Queue
Hellwagner
Multimedia Communication and Internet QoS
78
Two-Bit DiffServ Interior Router Functionality
High Priority Queue
Packets In
P bit
P-bit
set?
Yes
No
Low Priority Queue
Packets Out
If A-bit set,
a_cnt++
If A-bit set,
a_cnt--
RED In/Out
Queue Management
Hellwagner
Multimedia Communication and Internet QoS
79
Logical View of DiffServ-Capable Router
Meter
Packets Packet
In
classifier
Packet
Classification
Packet
marker
Shaper/
Dropper
Traffic Conditioning
PHB
Packets
mechaOut
nism
PHB-based
PHB
based
Forwarding
Routers differ by functionality actually needed/provided !
Hellwagner
Multimedia Communication and Internet QoS
80
Packet Classification
Done in ingress routers, functionality based on position of router:
ƒ Leaf router: multi-field (MF) classification
• Process of classifying packets based on the content of multiple
fields in the IP header,
header such as
- Source and destination IP addresses
- Source and destination port numbers
- Protocol ID
- TOS byte
• Operates on individual flows
flows, builds traffic aggregates
ƒ Other ingress routers: behavior aggregate (BA) classification
• P
Process off sorting
ti packets
k t b
based
d only
l on the
th contents
t t off the
th
DS field in the IP header
• Operates
p
on traffic aggregates
gg g
Hellwagner
Multimedia Communication and Internet QoS
81
Traffic Conditioning
Done in ingress routers, partially in egress routers;
consisting of (a subset of):
ƒ Metering: measurement of actual characteristics of a flow
ƒ Marking: setting Differentiated Services field (DS field) in the IP header
(Pre-marking: egress router sets DS field before packet leaves DS
domain)
ƒ Shaper:
• Traffic shaping according to TCA
• Packets buffered or dropped, if buffer full
ƒ Dropper: special form of traffic shaper
shaper, without buffer
Hellwagner
Multimedia Communication and Internet QoS
82
DS Field
DS field in IP header:
• Information which service class (behavior aggregate) a packet
belongs to
• Signaled by Differentiated Services Codepoint (DSCP)
DS Codepoint
(6 bits)
Unused
(2 bits)
DS field
DSCP:
• Set
S tb
by leaf
l f / ingress
i
routers
t
• Must be interpreted and used by DS-capable core / egress routers
• Is ignored by DS-unaware routers → best-effort service
• Predefined class selector codepoints (CSCs): xxx000, where x∈{0,1}
• Bits 0-2 define class, bits 3-5 relative p
priority
y within class
• Backward compatibility to IPv4 TOS field required
Hellwagner
Multimedia Communication and Internet QoS
83
DS Field in IP Header
IPv4 header: TOS field → DS field
0
4
8
Version HLen
TOS 16
31
Length
DS
g
Flags
Ident
TTL
19
Protocol
Offset
Checksum
SourceAddr
DestinationAddr
Options (variable)
Pad
(variable)
Data
IPv6 header: Traffic class octet → DS field
Hellwagner
Multimedia Communication and Internet QoS
84
Per-Hop Forwarding Behavior (PHB)
Specifies a router‘s (hop‘s) externally observable behavior
when forwarding (packets from) BAs
PHB based on DSCP; defined locally only!
Defined by:
• QoS parameters like delay, jitter, loss rate, ....
• Absolute
Ab l t or relative
l ti (to
(t other
th PHB) values
l
• Rules how queues are shared among service classes
• ....
Realized by:
• Queue management and packet scheduling techniques
• But not specified as their parameters
→ Allow for implementation flexibility
Hellwagner
Multimedia Communication and Internet QoS
85
DSCP – PHB Mapping
Simple table lookup, e.g.:
DSCP
PHB #
PHB Semantics
000000
PHB 1
Best Effort
001000
PHB 2
Premium Traffic
001111
PHB 3
Management
111000
111001
111101
Some rules:
• DSCP = 000000 → best-effort service class!
• ≤ 8 service classes (CSCs) → ≥ 2 PHBs
• Numerically larger DSCP → better service
Caveat:
Packets from single
g source with different CSCs may
y arrive out of order,
due to different PHBs encountered in routers!
Hellwagner
Multimedia Communication and Internet QoS
86
End-to-End Service Architecture: Example
Delivery of Premium Service with Dynamic SLA:
Example scenario:
ƒ Host S in Corporate Network 1 (CN1) wants to send data using
Premium Service to Host D in CN 2.
ƒ Host S has a dynamic SLA with ISP 1.
Th following
The
f ll i shows
h
potential
t ti l behavior;
b h i
nothing
thi
settled
ttl d yet.
t
Hellwagner
Multimedia Communication and Internet QoS
87
Phase 1: Signaling
Step 1: Host S sends an RSVP PATH Message to local Bandwidth Broker CN1-BB.
Step 2: CN1-BB makes an admission control decision.
Iff request is denied, an error message is sent back to S;
S signaling process ends.
Step 3: Request is accepted by CN1-BB. It sends the PATH Message to ISP1-BB.
Step 4: ISP1-BB
ISP1 BB makes
k an admission
d i i
control
t l decision.
d i i
- If request is denied, an error message is sent back to CN1-BB; S will be notified.
- If request is accepted, ISP1-BB sends the PATH Message to CN2-BB.
St 5:
Step
5 CN2-BB makes an admission control decision.
- If request is denied, an error message is sent back to ISP1-BB; S will be notified.
- If request is accepted, CN2-BB will set classification and policing rules on router
ER2 (using LDAP or RSVP).
RSVP) CN2-BB will then send RSVP RESV Msg.
Msg to ISP1-BB.
ISP1-BB
Step 6: When ISP1-BB receives the RESV Message, it will configure classification
and policing rules on router BR1, and policing and reshaping rules on router BR2.
It will then send the RESV Message to CN1-BB.
CN1 BB
Step 7: When CN1-BB receives the RESV Message, it will set classification and
policing rules on router LR1, and policing and reshaping rules on router ER1.
CN1-BB will then send the RESV Message to S.
Step 8: When S receives the RESV Message, it can start transmitting data.
Hellwagner
Multimedia Communication and Internet QoS
88
Notes on Signaling Process
ƒ Significant differences from IntServ/RSVP signaling process:
• Sender requests for resources, not receiver.
• Request can be rejected when a BB receives PATH Msg. from S.
(In IntServ/RSVP,
IntServ/RSVP rejection only on RESV Message from receiver.)
receiver )
• A BB can aggregate multiple requests and make a single request
to the next BB.
• Each domain behaves like a single node, represented by its BB.
ISP core routers are not involved in this process.
ƒ St
State
t information
i f
ti installed
i t ll d by
b the
th BB on a BR is
i soft
ft state.
t t It
must be regularly refreshed, or it will time out.
ƒ Steps
St
4 and
d 6 repeated
t d once for
f each
h intermediate
i t
di t ISP.
ISP
ƒ If SLA between CN1 and ISP1 is static, Steps 3–6 are skipped.
Hellwagner
Multimedia Communication and Internet QoS
89
Phase 2: Data Transmission
Step 9: Host S sends packets to leaf router LR1.
Step 10: Leaf router LR1 performs an MF classification.
classification
If the traffic is non-conforming, LR1 will shape it.
LR1 will also set the P-bits of the packets. All packets enter the P-queue.
St 11:
Step
11 Each intermediate router between LR1 and ER1 performs BA
classification, puts the packets into the P-queue, and sends them out.
Step
p 12: ER1 pperforms a BA classification and reshapes
p the traffic to make sure
that the negotiated peak rate is not exceeded. Reshaping is done for the
aggregation of all flows heading toward BR1, not for each individual flow.
Step 13: BR1 classifies & policies the traffic.
traffic Excess premium packets are
dropped.
Step 14: Intermediate routers between BR1 and BR2 (inclusive) perform BA
classification.
l
ifi ti
BR2 also
l reshapes
h
th premium
the
i
t ffi
traffic.
Step 15: ER2 classifies & policies the traffic. Excess premium packets are
dropped.
Step 16: The premium packets are delivered to host D.
Hellwagner
Multimedia Communication and Internet QoS
90
DiffServ Advantages
ƒ Limited number of service classes
ƒ Aggregation
A
ti
off flows
fl
into
i t traffic
t ffi aggregates
t
→ Better scalability
ƒ Thorough classification and policing in edge routers only
→ Easier implementation and deployment (than IntServ/RSVP)
ƒ Leaf routers connected to slow links to customers
→ Room for per-flow classification (MF), policing, and shaping
ƒ Core routers perform standard classification (BA) only,
→ Simple, fast packet forwarding
ƒ Local rules and behavior only (PHBs; policies in DS domain)
ƒ DS field ignored by DS-unaware routers (best-effort service)
→ Incremental
I
t l deployment
d l
t in
i the
th Internet
I t
t
Hellwagner
Multimedia Communication and Internet QoS
91
Comparison of IntServ and DiffServ (1)
Hellwagner
Criteria
IntServ
DiffServ
Granularity of
service
differentiation
State in routers
(e.g., scheduling,
buffer management)
T ffi classification
Traffic
l
ifi i
basis
Type of service
differentiation
Individual flow
Aggregate of
flows
Per flow
Per aggregate
DS fi
field
ld
Admission control
Severall h
S
header
d
fields
Deterministic or
statistical
guarantees
Required
Signaling protocol
Required (RSVP)
Multimedia Communication and Internet QoS
Absolute or
relative
assurance
Required for
absolute
differentiation
Not required
for relative
schemes
92
Comparison of IntServ and DiffServ (2)
Criteria
IntServ
Coordination for service End-to-end
differentiation
Scope of service
A unicast or multicast
differentiation
path
Scalability
Network accounting
g
Network management
Inter-domain
deployment
Hellwagner
DiffServ
Local (per-hop)
Anywhere in a
network or in
specific paths
Limited by the number
Limited by the
of flows
number of classes
of service
Based on flow
Based on class
characteristics and QoS usage
requirements
Similar to circuit
Similar to existing
switching networks
IP networks
Multilateral agreements Bilateral
agreements
Multimedia Communication and Internet QoS
93
4
Multiprotocol Label Switching (MPLS)
Hellwagner
Multimedia Communication and Internet QoS
94
Internet’s Status Today
ƒ Traffic growth
ƒ Complex,
C
l
time-consuming
ti
i
IP datagram
d t
forwarding
f
di
• Find IP address prefix matching with forwarding table entry
ƒ Best-effort
B t ff t service
i model
d l
• No native QoS or multi-service capability in IP networks
ƒ Scalability (of routing protocols and tables)?
Backbone
T ffi growth,
Traffic
th IP forwarding,
f
di
etc.
t
Hellwagner
Multimedia Communication and Internet QoS
95
Classical IP Datagram Forwarding
ƒ Forwarding: find longest matching prefix in fwd. table and fwd. packet
ƒ Hop-by-hop
p y
p behavior: no overall traffic cntl.
D est
4 7 .1
4 7 .2
4 7 .3
O ut
1
2
3
1
D est
4 7 .1
4 7 .2
4 7 .3
D est
4 7 .1
4 7 .2
4 7 .3
IP 47.1.1.1
O ut
1
2
3
1
47.1
2
IP 47.1.1.1
3
O ut
1
2
3
2
IP 47.1.1.1
1
47.3
47 2
47.2
3
2
IP 47.1.1.1
Hellwagner
Multimedia Communication and Internet QoS
96
Major Motivation and Goals behind MPLS
ƒ Simplify and speed up IP forwarding significantly (10x ?)
ƒ Support multiple service classes and QoS
ƒ Support traffic engineering (TE)
• TE := direct traffic to where the network capacity is
ƒ Promote p
partitioning
g of functionality
y within the network
• Detailed processing of packets at edge routers
• Simple packet forwarding in core routers
ƒ Thus, improve scalability of IP protocols (particularly, routing)
ƒ Facilitate the integration of ATM switches and IP routers
Hellwagner
Multimedia Communication and Internet QoS
97
Basic Idea: Route at Edge – Switch in Core
ƒ MPLS combines best of two worlds:
• Flexible IP packet routing / forwarding
• Fast ATM circuit switching
IP
IP
IP Forwarding
Hellwagner
#L1
IP
#L2
IP
#L3
IP
IP Forwarding
MP Label Switching:
packets are switched on labels,
p
rather than destination IP address
Multimedia Communication and Internet QoS
98
Label Switching Devices
ƒ Label Edge Routers (LERs): LSRs at edge of MPLS network
• Ingress LERs are responsible for classifying unlabelled IP packets
and
d appending
di
the
th appropriate
i t label.
l b l
• Egress LERs are responsible for removing the label and forwarding
the unlabelled IP packet towards its destination.
ƒ Label Switching Routers (LSRs):
• Forward labelled packets based on the information carried by labels
Label Switching Routers
(IP Router or ATM Switch)
L b l Edge
Label
Ed Routers
R t
Hellwagner
Multimedia Communication and Internet QoS
99
Forwarding Equivalence Classes (FEC)
LSR
LER
LSR
LER
LSP
IP1
IP1
IP1
#L1
IP1
#L2
IP1
#L3
IP2
#L1
IP2
#L2
IP2
#L3
IP2
IP2
Packets are destined for different address prefixes,
but can be mapped to common path.
ƒ FEC := subset of packets all treated the same way by a router
ƒ Concept
C
t off FEC
FECs provides
id for
f flexibility
fl ibilit and
d scalability
l bilit
ƒ In conventional routing, a packet is assigned to a FEC at each
hop (i.e.,
(i e L3 look-up),
look-up) in MPLS it is only done once at the
network ingress
Hellwagner
Multimedia Communication and Internet QoS
100
Label Switched Path (LSP)
Label Swapping (Substituion)
Intf Label Dest Intf Label
In In
Out Out
3
50
47.1 1
40
Intf Dest Intf Label
In
Out Out
3
47.1 1
50
47.3
Label Dest Intf
In
Out
40
47.1 1
IP 47.1.1.1
1 47.1
3
3
1
1
Intf
In
3
LSR
LER
2
2
47.2
3
2
IP 47.1.1.1
47 1 1 1
LER
MPLS adds a connection-oriented
connection oriented paradigm to IP networks!
Hellwagner
Multimedia Communication and Internet QoS
101
Components in Routers
ƒ Forwarding component:
• Uses label information carried in a packet and label binding
information maintained by a LSR to forward the packet
ƒ Label Forwarding Information Base (LFIB):
• Each entry consists of:
-
Incoming label
Outgoing label
Outgoing interface
• LFIB is
i indexed
i d
d by
b incoming
i
i
label
l b l (→
( fast
f
forwarding,
f
di
cf.
f ATM)
• LFIB could be either per LSR or per interface
ƒ Control component:
• Responsible for maintaining correct label binding information
among LSRs
Hellwagner
Multimedia Communication and Internet QoS
102
Label Distribution
Label Binding
Intf Label Dest Intf Label
Out Out
In In
3
50
47.1 1
40
Intf
In
3
Label Dest Intf
In
Out
40
47.1 1
1
3
Intf Dest Intf Label
In
Out Out
3
47.1 1
50
47 1
47.1
3
2
1
1
47.3
Request: 47.1
M
Mapping:
i
40
2
47.2
3
2
Various Label Distribution Protocols (LDPs) under development/standard.
Hellwagner
Multimedia Communication and Internet QoS
103
Example for LSP Setup: Explicitly Routed (ER) LSP
Intf
I
In
3
3
Dest
47.1.1
47.1
Intf
O t
Out
2
1
Intf Label Dest Intf Label
In In
Out Out
3
50
47.1 1
40
Label
O t
Out
33
50
Label Dest Intf
In
Out
40
47.1 1
IP 47.1.1.1
1 47.1
3
3
Route = A,B,C,D
ABCD
2
1
1
47.3
Intf
In
3
D
2
47.2
3
2
C
IP 47.1.1.1
B
A
ER-LSP:
ER
LSP route
t chosen
h
by
b source (source
(
routing),
ti ) via
i control
t l messages:
• Can use routes other than shortest path
• Routing
g flexibility
y for network operator
p
(policy-based,
(p
y
, QoS-based))
Other routing protocols in use as well, e.g., constraint-based routing (CR)
Hellwagner
Multimedia Communication and Internet QoS
104
MPLS Label Encapsulation
ƒ MPLS label encapsulation := way to carry label information
ƒ Defined over multiple link layers: Multiprotocol LS
ƒ Specifications for the following link layers currently exist:
• PPP/LAN: uses ”shim” header inserted between L2 and L3 headers
→ “Layer
Layer 2
2.5
5” technology
• ATM: label contained in VCI/VPI field of ATM header
• Frame Relay
ƒ Translation between link layer types must be supported
Hellwagner
Multimedia Communication and Internet QoS
105
MPLS Encapsulation – PPP Links & LANs
MPLS ‘Shim’ Headers (1-n)
n
•••
Layer 2 Header
(e.g., PPP, 802.3)
1
Network Layer Header
and Packet (e.g., IP)
4 Bytes
Label Stack
Entry Format
Label
Label:
Exp.:
S:
TTL
TTL:
Exp.
S
TTL
Label Value, 20 bits (0-16 reserved)
Experimental, 3 bits (was Class of Service)
Bottom of Stack, 1 bit (1 = last entry in label stack)
Ti
Time
tto Live,
Li
8 bit
bits
• Multiple labels from multiple networks form label stack
• Network layer must be inferable from value of bottom label of the stack
• TTL must be set to the value of the IP TTL field when packet is first labelled
• When
Wh last
l t label
l b l is
i popped
d off
ff stack,
t k MPLS TTL to
t be
b copied
i d to
t IP TTL field
fi ld
Hellwagner
Multimedia Communication and Internet QoS
106
Hierarchy via Label Stack
Layer 2 Header
Label 3
Label 2
Label 1
IP Packet
MPLS Domain 1
MPLS D
Domain
i 2
MPLS Domain 3
S
Supports
t network
t
k scalability
l bilit
Hellwagner
Multimedia Communication and Internet QoS
107
Summary: (Remaining) Key Elements of MPLS
ƒ MPLS header stack
• Contains the MPLS label on which LSRs forward the packets.
Headers can be stacked.
ƒ Differentiated behavior of routers
• Packet labelling at edge, based on routing information
• Packet forwarding in core
core, based on labels
(much alike ATM cell switching)
ƒ Enhanced IP routing
g protocols
p
• Which distribute topology and constraint-based data
ƒ Label distribution protocols
• Standardized (or, yet to be) connection establishment protocols
through which LSRs set up a complete path (LSP) from ingress
LSR tto egress LSR
LSR.
Hellwagner
Multimedia Communication and Internet QoS
108
MPLS – The Big Picture
1. Existing routing protocols (e.g. OSPF, IGRP) establish routes.
2b. Label Distribution
Protocol (e.g., LDP)
creates LFIB entries
on LSRs
2a. Label Distribution Protocol (e.g.,
LDP) establishes label to routes
mappings
3. Ingress edge LSR receives packet,
performs Layer 3 value-added
services and “label”
services,
label packets
Hellwagner
5. Edge LSR at
egress
removes label
and delivers
packet
4. LSRs forward labelled packets
using label swapping
Multimedia Communication and Internet QoS
109
MPLS Traffic Engineering: Motivation
Current interior gateway routing protocols (IGPs) can lead to
unfavorable traffic distribution:
• Over-utilized and under-utilized links
• Due to shortest path routing
Avoid in backbone!
Traffic for D,
shortest path routed
9 under-ultilized links
4 over-utilized links
D
S
Congestion
Hellwagner
Multimedia Communication and Internet QoS
Massive
M
i
congestion
110
MPLS Traffic Engineering: Objectives
ƒ Map/distribute actual traffic efficiently to available resources
ƒ Use resources in a controlled way
ƒ Redistribute traffic rapidly and effectively in response to
changes in network topology (e.g., link or router failure)
Use of MPLS LSPs
D
S
This helps real-time traffic requiring QoS
Hellwagner
Multimedia Communication and Internet QoS
111
MPLS Traffic Engineering: Some Methods
• MPLS can use source routing capability to steer traffic on desired path
• Operator may manually configure these in LSRs along the desired path
• Analogous to setting up PVCs in ATM switches
• IIngress LSR may be
b configured
fi
d with
ith the
th path,
th RSVP used
d to
t sett up LSP
• Some vendors have extended RSVP for MPLS path set-up
• Ingress LSR may be configured with the path,
path LDP used to set up LSP
• Many vendors believe RSVP not suited
• Ingress LSR may be configured with one or more LSRs along desired
path, hop-by-hop routing may be used to set up the rest of the path
• A.k.a loose source routing, less configuration required
• If desired for control, route discov’d by hop-by-hop routing can be frozen
• In the future, constraint-based routing will offload traffic engineering
tasks from the operator to the network itself
Hellwagner
Multimedia Communication and Internet QoS
112
MPLS and DiffServ: Possible Combination
ƒ Both MPLS and DiffServ have same scalability goals/approach:
• Aggregation of traffic on edge
• Fast processing/forwarding of aggregates in core
ƒ DiffServ can augment
g
MPLS signaling
g
g and forwarding:
g
• Signaling: augment LSP setup and distribution protocols (e.g., LDP,
CR-LDP, RSVP-TE) with explicit CoS indication (e.g., EF, AF)
• Forwarding: DiffServ Code Points (DSCP) can be mapped to the EXP
(former CoS) bits in the MPLS label, to indicate packets’ priorities
ƒ PHB enforcement in MPLS DiffServ:
• Exact same PHB mechanisms as in IP DiffServ
DiffServ queues with DiffServ drop profiles; EF, AF i, default PHBs
• Only difference is packet classification
-
For IP DiffServ, packets classified by DSCP
-
For
o MPLS
S DiffServ,
Se , packets
pac ets c
classified
ass ed by label
abe / EXP b
bits
ts
ƒ MPLS DiffServ can be thought of undistinguishable from IP DiffServ
Hellwagner
Multimedia Communication and Internet QoS
113
Example: MPLS End-to-End CoS and QoS
DiffServ mapping to
LSPs
MPLS switching
g
in the core
Packets are DiffServ
classified at router
DiffServ CoS used
on egress to router
B
B
A
A
Vid
T l t FTP TCP Video
Telnet
Hellwagner
Per-connection/flow QoS
for Premium Services
Multimedia Communication and Internet QoS
Telnet FTP TCP Video
114
5
Real-Time Multimedia Data Transport
Basic Protocols
Hellwagner
Multimedia Communication and Internet QoS
115
Requirements (1)
ƒ Interoperability between different applications
• E.g., two different audio conference systems
ƒ Negotiation about coding issues
• Agree on media type, compression method, etc.
ƒ Timing for proper playback (in a single stream)
ƒ Synchronization (among multiple streams)
• E.g.,
g , between video and corresponding
p
g audio
ƒ Indication of packet loss, thus also congestion
• RTP runs typically over non-reliable
non reliable transport (UDP)
• This enables applications to do something,
e.g., adapt to congestion situation
Hellwagner
Multimedia Communication and Internet QoS
116
Requirements (2)
ƒ Framing
• Enable applications to mark start and end of frames
• E.g., mark the beginning of a “talkspurt” — the application may
shorten or lengthen
g
silences
ƒ Sender identification
• IP address is not extremely user-friendly
user friendly
ƒ Efficiency
• No long headers are acceptable
• E.g., audio data packets are typically short, a great overhead is
undesirable
Hellwagner
Multimedia Communication and Internet QoS
117
Real-Time Transport Protocol (RTP) [RFC 3550] (1)
ƒ Origins in the vat audio conferencing tool’s application protocol
ƒ RTP is a “transport” protocol on application level,
running over the usual transport protocols, typically UDP
ƒ Protocol stack for multimedia application using RTP:
Application
RTP ((Real-time
ea t e Transport
a spo t Protocol)
otoco )
UDP (User Datagram Protocol)
IP (Internet Protocol)
Network
Hellwagner
Multimedia Communication and Internet QoS
118
RTP (2)
ƒ Twin-standard by IETF (with RTCP)
• RTP: exchange of multimedia data
• RTCP: exchange of periodic control information
even–odd
odd port numbers
• They use consecutive even
ƒ Application Level Framing (ALF)
• Applications understand their needs best
• Profile
-
Defines the meaning of certain fields in the header
• Payload formats
-
Hellwagner
Interpretation of data following the header,
e g as simple stream of bytes or some more complex structure
e.g.,
(MPEG)
Multimedia Communication and Internet QoS
119
RTP Header Format (1)
Number of bits
V2 P1 X1 CC4 M1
PT7
Sequence number16
Timestamp32
Synchronization source (SSRC) identifier
Contributing source (CSRC) identifier
…
Extension header
ƒ V: version no. – 2 bits might be few, later extensions possible (subversion)
ƒ P: Padding is used
ƒ X: Extension header exists
ƒ CC: Contributing sources – needed only if the RTP streams are “mixed”
ƒ M: Marks the packet, e.g., as start of frame – the app. uses it at wish
ƒ PT: Payload type
Hellwagner
Multimedia Communication and Internet QoS
120
RTP Header Format (2)
ƒ Payload type
• Generally not used as demultiplexing key
• Transport mechanisms are used for multiplexing,
e g different UDP ports for each stream
e.g.,
ƒ Sequence number
• The
Th sender
d just
j t increments
i
t it – handling
h dli
by
b application
li ti
• E.g., replay the last frame for a lost video frame
ƒ Time stamp
• Tick is defined by the application, e.g., 125 µs for audio
ƒ Synchronization source (SSRC)
• Random number uniquely identifying single sources
Hellwagner
Multimedia Communication and Internet QoS
121
RTP Packet Format
Pad count bytes
UDP hdr.
RTP hdr.
RTP payload
Pad Pad cnt
Length
g carried in the UDP header
ƒ The length of the RTP data is coded in the UDP header
ƒ If the RTP payload is less than this length, then padding is
used
ƒ Advantage
• The RTP header remains short: 1 bit suffices
• The Pad count byte is used only if this place is unused by the
payload anyway
Hellwagner
Multimedia Communication and Internet QoS
122
RTP Packet Example
Example: single frame (24 bytes) of G.723.1 encoded voice
Hellwagner
Multimedia Communication and Internet QoS
123
Real-Time Control Protocol (RTCP) [RFC 3550]
RTCP provides a control stream associated with the data stream,
with
i h the
h functions:
f
i
• Performance feedback
- E.g.,
E
for
f adaptive
d ti applications
li ti
• Correlate and synchronize media streams of the same sender
- The same sender may have several SSRC values
- Canonical name (CNAME) assigned to a sender
- Different clocks must be synchronized
• Convey the identity of the sender
Hellwagner
Multimedia Communication and Internet QoS
124
RTCP Packet Types
ƒ
Sender and receiver reports
• SSRC ((synchronization
y
source)) identifier
• Statistics of lost data packets from this source
• Highest sequence number from this source
• Estimated interarrival jitter for this source
• Last actual timestamp received via RTP for this sender
• Delay since last sender report received via RTP for this sender
ƒ
Extra sender information, enabling synchronization
• Timestamp of the actual date time of report generation
• RTP timestamp of report generation
• Cumulative packet and byte counts of this sender
ƒ
Source descriptions
• CNAME and other sender description information
ƒ
Application-specific control packets
Hellwagner
Multimedia Communication and Internet QoS
125
RTCP Operation
ƒ
RTCP traffic is limited to ~ 5% of RTP traffic
• The report generation slows down if necessary
ƒ
Recipients
p
and sender may
y react on the reports
p
• Recipient may require resource reservation noticing that other
recipients have better QoS
• Sender may reduce rate if too many packets are lost
• RTP timestamp + time of day enable synchronization of streams,
even with different clock granularity
• CNAME enables the identification of the media stream with
different SSRC values
Hellwagner
Multimedia Communication and Internet QoS
126
Real-Time Streaming Protocol (RTSP) [RFC 2326]
ƒ
User-level protocol
ƒ
No assumption about the transport level
ƒ
No explicit QoS mechanisms
ƒ
Delivers only control data, no payload
ƒ
Syntax similar to HTTP, but the server does have state
ƒ
Extensible by
y new methods and/or parameters
ƒ
Supported operations
• Download of media data from a media server
• Invitation of a media server into a conference
• Adding of media to an existing presentation
Hellwagner
Multimedia Communication and Internet QoS
127
Control and User Data
Port 2n for RTP Port
2n+1 for RTCP
TCP connection
(Server def. port: 554)
RTSP Control connection
User data
RTP data +
RTCP reports
Case 1: Control and data pyhsically separated TCP connection
(Server def. port: 554)
RTSP Control connection
U
User
d
data
t
Case 2: Control and data only logically separated
Hellwagner
Multimedia Communication and Internet QoS
128
RTSP State Diagram
SETUP
Init
TEARDOWN
TEARDOWN
Ready
PAUSE
PAUSE
RECORD
PLAY
Recording
Playing
TEARDOWN
Hellwagner
Multimedia Communication and Internet QoS
129
RTSP Session Protocol
Client
Ident. actual
version
Offered types
of delivery
HTTP GET
Media description
Web
server
OPTIONS
Transport options
Media server
SETUP
OK
Selected type
of delivery
PLAY
OK
Media data (usually via RTP)
Stream control data (usually via RTCP)
PAUSE
OK
TEARDOWN
OK
Hellwagner
Multimedia Communication and Internet QoS
130
RTSP Methods
Method
Direction
Object
Availability
DESCRIBE
ANNOUNCE
GET_PARAMETER
OPTIONS
C→S
C↔S
C↔S
C↔S
P, S
P, S
P, S
P, S
PAUSE
PLAY
RECORD
REDIRECT
SETUP
SET_PARAMETER
TEARDOWN
C→S
C→S
C→S
S→C
C→S
C↔S
C→S
P, S
P, S
P, S
P, S
S
P, S
P, S
suggested
optional
optional
mandatory
((S → C: optional)
p
)
suggested
mandatory
optional
p
optional
mandatory
optional
mandatory
Hellwagner
Multimedia Communication and Internet QoS
131
RTSP: OPTIONS and SETUP
C -> S:
OPTIONS * RTSP/1.0
C
Cseq:
1
Require: implicit-play
Proxy-Require: gzipped-messages
S -> C:
RTSP/1.0 200 OK
Cseq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
C -> S:
SETUP rtsp://server.com/media RTSP/1.0
Cseq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
/
i
li
4588 4589
S -> C:
RTSP/1.0 200 OK
q 302
Cseq:
Date: 11 Jan 2001 10:30:06 GMT
Session: 447745
Transport: RTP/AVP;unicast;client_port=4588-4589;
server_port=6256-6257
Hellwagner
Multimedia Communication and Internet QoS
132
RTSP: PLAY and PAUSE
C ->
> S:
PLAY rtsp://server
rtsp://server.com/media
com/media RTSP/1.0
RTSP/1 0
Cseq: 825
Session: 447745
Range: npt
npt=10-15
10 15 (normal play time, 10.-15.
10. 15. sec)
S -> C:
RTSP/1.0 200 OK
Cseq: 825
D t
Date:
11 J
Jan 2001 10
10:30:06
30 06 GMT
C ->
> S:
PAUSE rtsp://server
rtsp://server.com/media
com/media RTSP/1.0
RTSP/1 0
Cseq: 834
Session: 447745
S -> C:
RTSP/1.0 200 OK
Cseq: 834
Date: 11 Jan 2001 10:30:06 GMT
Hellwagner
Multimedia Communication and Internet QoS
133
RTSP and TCP Interleaved
C -> S:
SETUP rtsp://server.com/media RTSP/1.0
Cseq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
RTP/AVP/TCP;interleaved=0 1
S -> C:
RTSP/1.0 200 OK
Cseq: 2
Date: 11 Jan 2001 10:36:30 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 123456
C -> S:
PLAY rtsp://server.com/media
rtsp://server com/media RTSP/1
RTSP/1.0
0
Cseq: 3
Session: 123456
S -> C:
RTSP/1.0
RTSP/1
0 200 OK
Cseq: 3
Session: 123456
Date: 11 Jan 2001 10:31:24 GMT
RTP-Info: url=rtsp://server.com/media;
seq=232433; rtptime=972948234
S -> C: $\000(2 byte length)(“length“ bytes data, w/RTP header)
S -> C: $\001(2 byte length)(“length“ bytes RTCP packet
Hellwagner
Multimedia Communication and Internet QoS
134
Session Initiation Protocol (SIP) [RFC 3261]: Features
ƒ An application level, end-to-end, client-server session signaling
(control) protocol for creating, modifying, and terminating
sessions with one or more participants
ƒ Can be used for voice, video, instant messaging, gaming, etc.
ƒ Follows on HTTP:
• Text-based messaging
• URIs,
URIs e.g.
e g sip:[email protected]
sip:dbaron@mit edu
ƒ Supports user location, call setup, call transfers
ƒ Supports mobility by proxying and redirection
ƒ Works together with other IP protocols:
• SAP (S.
(S Advertisement
Ad ertisement P.)
P ) for advertising
ad ertising multimedia
m ltimedia sessions
• SDP (S. Description P.) for describing multimedia sessions
network-resource
resource reservation
• RSVP for network
• RTP, RTCP, RTSP for real time data transport
Hellwagner
Multimedia Communication and Internet QoS
135
SIP Components
SIP End Devices:
• User Agent Clients (originating calls)
• User Agent Servers (listening for incoming calls)
SIP Registrar:
• Accepts registration requests from users
• Maintains
M i t i user‘s
‘ whereabouts
h
b t att a Location
L
ti Server
S
SIP Proxy Server:
• Relays call signaling (acting as client and server)
• Keeps no session state
SIP Redirect Server:
• Redirects callers to other servers
SIP Gateways
Hellwagner
Multimedia Communication and Internet QoS
136
SIP Trapezoid
Location
S
Server
DNS
S
Server
DNS
Registrar
SIP
Outgoing
Proxy
Incoming
Proxy
SIP
Originating
User Agent
SIP
SIP
SIP
RTP
Terminating
User Agent
C simplify
Can
i lif to
t triangle
ti
l or P2P signaling
i
li
Hellwagner
Multimedia Communication and Internet QoS
137
SIP Addresses
SIP uses globally reachable addresses (URIs):
• Callees bind to this address using the
SIP REGISTER method
• Callers use this address to establish real-time communication with
callees
E
Examples:
l
• sip:[email protected]
• sip:[email protected]?subject=callme
i
i
il@i t l
? bj t
ll
• Non-SIP URLs/URIs can be used as well (mailto:, http:, ...)
Hellwagner
Multimedia Communication and Internet QoS
138
Important SIP Methods
INVITE
Requests a session
ACK
Final response to INVITE
OPTIONS
Asks for server capabilities
CANCEL
Cancels a pending request
BYE
Terminates a session
REGISTER
Sends user’s address to server
Hellwagner
Multimedia Communication and Internet QoS
139
SIP Responses
1XX
Provisional
100 Trying
2XX
Success
200 OK
3XX
Redirection
302 Moved Temporarily
4XX
Client Error
404 Not Found
5XX
Server Error
504 Server Time-out
6XX
Global Failure
603 Decline
Hellwagner
Multimedia Communication and Internet QoS
140
SIP Flows - Basic
User
A
User
B
“Calls”
18.18.2.4
INVITE: sip:18.18.2.4
180 - Ringing
200 - OK
Rings
Answers
ACK
RTP
Talking
Hangs up
Talking
BYE
200 - OK
Hellwagner
Multimedia Communication and Internet QoS
141
SIP INVITE
INVITE sip:e9-airport.mit.edu SIP/2.0
From: "Dennis Baron"<sip:[email protected]>;tag=1c41
To: sip:e9-airport.mit.edu
Call-Id: [email protected]
Cseq: 1 INVITE
Contact: "Dennis Baron"<sip:[email protected]>
Content-Type: application/sdp
Content-Length: 304
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY,
REGISTER, SUBSCRIBE
Supported: sip-cc
sip-cc, sip-cc-01,
sip-cc-01 timer,
timer replaces
User-Agent: Pingtel/2.1.11 (WinNT)
Date: Thu, 30 Sep 2004 00:28:42 GMT
Via: SIP/2.0/UDP 18.10.0.79
Hellwagner
Multimedia Communication and Internet QoS
142
Session Description Protocol (SDP) [RFC 2327]
ƒ Intended for describing multimedia sessions for the purposes of
session
i
announcement,
t session
i
invitation,
i it ti
and
d other
th forms
f
off
multimedia session initiation
ƒ Included:
I l d d
• Type of media (video, audio, etc.)
• Transport protocol (RTP/UDP/IP,
(RTP/UDP/IP H.320,
H 320 etc
etc.))
• Format of the media (H.261 video, MPEG video, etc.)
• Information to receive those media ((addresses,, ports,
p
, formats and
so on)
Hellwagner
Multimedia Communication and Internet QoS
143
SDP
v=0
o=Pingtel
o
gte 5 5 IN IP4 18.10.0.79
8 00 9
s=phone-call
c=IN IP4 18.10.0.79
t=0 0
m=audio 8766 RTP/AVP 96 97 0 8 18 98
a=rtpmap:96 eg711u/8000/1
a=rtpmap:97 eg711a/8000/1
a=rtpmap:0 pcmu/8000/1
a=rtpmap:8 pcma/8000/1
a=rtpmap:18 g729/8000/1
a=fmtp:18 annexb=no
a=rtpmap:98 telephone-event/8000/1
Hellwagner
Multimedia Communication and Internet QoS
144
6
Conclusions
Hellwagner
Multimedia Communication and Internet QoS
145
Concluding Remarks
ƒ Challenging QoS requirements,
b i ll emerging
basically
i
f
from
multimedia
lti di communication
i ti
ƒM
Many Internet
I t
t QoS
Q S approaches/mechanisms
h /
h i
proposed
d and
d tested,
t t d
many not adopted, not feasible in practice, refused
ƒ Currently most successful: MPLS
(although not a “native“ QoS approach)
ƒ Still a relevant topic in academia, industry, and standardization
ƒ Important component in “Future Internet“ initiatives
ƒ Still ongoing dispute: raw bandwidth vs. QoS mechanisms?
Hellwagner
Multimedia Communication and Internet QoS
146