Multimedia Communication and Internet QoS - Győr) · PDF fileMultimedia Communications...
Transcript of Multimedia Communication and Internet QoS - Győr) · PDF fileMultimedia Communications...
Multimedia Communication andand
Internet QoSHermann Hellwagner
Research Group Multimedia Communication (MMC)Institute of Information Technology (ITEC)
Klagenfurt University AustriaKlagenfurt University, Austria
[email protected]://www.itec.uni-klu.ac.at/~hellwagn
G ö 29 A il 2010
Hellwagner Multimedia Communication and Internet QoS 1
Györ, 29 April 2010
Who am I?
Professor of Information TechnologyHead of RG Multimedia Communication (MMC)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 servers/clusters advanced topics in multimedia• Internet QoS, servers/clusters, advanced topics in multimedia communication
Professional services:Professional services:• Member of the Scientific Board of the Austrian Science Fund (FWF)• Deputy Head of Austrian Delegation to ISO/IEC JTC1/SC29 WG11
Hellwagner Multimedia Communication and Internet QoS 2
(Moving Picture Experts Group - MPEG)
Where do I come from?
Klagenfurtg
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, P i i lPrinciples
2 Integrated Services (IntServ) and the Resource Reservation P t l (RSVP)Protocol (RSVP)
3 Differentiated Services (DiffServ)
4 Multiprotocol Label Switching (MPLS)
5 Real-Time Multimedia Data Transport: Basic Protocols5 Real Time Multimedia Data Transport: Basic Protocols
6 Conclusions
Hellwagner Multimedia Communication and Internet QoS 5
Literature: Books
Ina Minei, Julian LucekMPLS-Enabled Applications: Emerging Developments and New TechnologiesWiley 2008 (Second Edition)Wiley 2008 (Second Edition)Mihaela van der Schaar, Philip A. ChouMultimedia over IP and Wireless Networks. Compression, Networks, andSystems
/Elsevier / Academic Press 2007John Evans, Clarence FilsfilsDeploying IP and MPLS QoS for Multiservice Networks. Theory and PracticeElsevier / Morgan Kaufmann 2007Elsevier / Morgan Kaufmann 2007Jitae Shin, Daniel C. Lee, C.-C. Jay KuoQuality of Service for Internet MultimediaPrentice Hall 2004Sanjay Jha, Mahbub HassanEngineering Internet QoSArtech House 2002F d H l llFred HalsallMultimedia CommunicationsAddison Wesley 2001Ralf Steinmetz
Hellwagner Multimedia Communication and Internet QoS 6
Ralf SteinmetzMultimedia-Technologie. Grundlagen, Komponenten und SystemeSpringer 1998
Literature: Journals and Conferences
IEEE NetworkIEEE Communications MagazineIEEE Communications Surveys & Tutorials: http://www.comsoc.org/livepubs/surveys/index.htmlhttp://www.comsoc.org/livepubs/surveys/index.htmlIEEE MultimediaIEEE Internet Computing: http://computer.org/internet/ (IC Online)IEEE Transactions on CommunicationsIEEE Journal on Selected Areas in CommunicationsIEEE Transactions on Multimedia IEEE/ACM Transactions on NetworkingACM 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. many Working Groups defining QoS mechanisms)
IEEE Communications Society: http://www.comsoc.org
Qbone Internet2 Initiative: http://qbone internet2 edu/Qbone Internet2 Initiative: 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“ Networking Reading Lists (incl QoS):Classical Networking Reading Lists (incl. QoS): http://www.cs.columbia.edu/~hgs/netbib/standard.html
Prof. Klara Nahrstedt‘s Web page: htt // i i d / kl /h ht l
Hellwagner Multimedia Communication and Internet QoS 8
http://cairo.cs.uiuc.edu/~klara/home.html
11
IntroductionIntroduction
Motivation, QoS Requirements, Terminology, Principles
Hellwagner Multimedia Communication and Internet QoS 9
The Challenge: Multimedia
MultimediaH dli f i t f t ti di• Handling of a variety of presentation media
• 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
Challengesg• Storage: many GBs per video• Timely, continuous (real-time) and correct (synchronized) delivery
Hellwagner Multimedia Communication and Internet QoS 10
• Indexing, searching, retrieval: 1000s of videos?
A Movie as a Set of Elementary Streams
Hellwagner Multimedia Communication and Internet QoS 11
The Real Challenge: Multimedia over IP Networks
VoIP
Gaming
I t tVideoConference
VoIP
Internet Conference
Video ClipAttachment
Wireless Browsing
Music Streaming
Information SearchMovie
St iFinance,
Digital Photos
Hellwagner Multimedia Communication and Internet QoS 12
gStreaming Brokerage
Some Applications: Broad-/Multicast and (N)VoD
Broadcast or Multicast Video• Store-and-playback or live content• Enhanced services, reliability,
availability and maintenanceInternet
ISPavailability, and maintenance
Video-on-Demand (VoD)
Contentprovider 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”)
Hellwagner Multimedia Communication and Internet QoS 13
• VCR control is more difficult
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• Presenters can broadcast speech and graphics,
maybe also real-time video• Hard requirements on the infrastructure, e.g., logging facility
CSCW System• All of the above plus, e.g., Internet
Distributed content providers
joint work on a document
Teleteaching / Telelearning
Internet
• Potentially many participants
Gaming
Hellwagner Multimedia Communication and Internet QoS 14Control
Some Data Rates and Technology Data
GB/hMb/sMultimedia Source Mb/sDevice
0.0030.064Telephone (PCM)
0 060 14MP3 music 100Fast Ethernet
11WiFi LAN (802.11b)
0.060.14MP3 music
0.621.4Audio CD
0.661 - 1.5MPEG-1 movie
133EIDE disk
156ATM OC-31.764MPEG-2 movie
1125Digital camcorder (720 x 480)
156ATM OC 3
320SCSI Ultra Wide disk1125Digital camcorder (720 x 480)
97221Uncompressed TV (640 x 480)400IEEE 1394
(FireWire)
288648Uncompressed HDTV (1280 x 720)
1000Gigabit Ethernet
1280SCSI Ultra-160
Hellwagner Multimedia Communication and Internet QoS 15
How Much Does Compression Help?
Resolution[cols x lines x fps]
Multimedia Source Raw bit rate[Mb/s]
Compressedbit rate [Mb/s]
480 x 480 x 24Film (USA and Japan)
NTSC video
[cols x lines x fps]
480 x 480 x 29 97
[Mb/s]133
168
bit rate [Mb/s]3 - 6
4 - 8NTSC video
PAL video
HDTV video
480 x 480 x 29.97576 x 576 x 25
1920 x 1080 x 30
168199
1493
4 - 84 - 9
10 - 30
ISDN videophone (CIF)
PSTN videophone (QCIF)
352 x 288 x 29.97
176 x 144 x 29.97
73
18
0.064 - 1.92
0.01 - 0.03p (Q ) 18 0.01 0.03
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 t i di t- Response not immediate
Equally important: delay (latency) and jitter (delay variance):• Critical for timely, continuous delivery and (soft) real-time playback
Sender Receiver
Delay
TimeJitter
Hellwagner Multimedia Communication and Internet QoS 17
Additional criteria: stream synchronization, reliability, cost, .....
Example Audio Application
Routers and switches with queues of variable lengthsE g Voice over IP (VoIP)
Microphone Sampler, Buffer
queues of variable lengthsE.g., Voice over IP (VoIP)
Microphone
Speaker
p ,A D
converterBuffer,D A
Voice sample once every 125µs
Each sample has a playback timeEach 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 ms is tolerable
Hellwagner Multimedia Communication and Internet QoS 18
For voice, data arrival within 300 ms is tolerable
Example Audio Application: Delay and Jitter
Audio application (e.g., VoIP) will most probably use:Asynchronous transmissionAsynchronous transmissionStatistical multiplexing
→ Optimized usef b d id hof bandwidth
→ Increases delay→ Introduces jitter
Hellwagner Multimedia Communication and Internet QoS 19
→ Introduces jitter
Example Audio Application: Playback
Packetarrival
num
ber
Packet
arrival
Buffer drained late
eque
nce generation
Network Buffer
Buffer drained, late packets are discarded
Se Network
delayBuffer
Playback
Time
Hellwagner Multimedia Communication and Internet QoS 20
Time
Distribution of Delays on the Internet
90% 97% 98% 99%
97% of the packets has
ts [%
]
100 ms delay or less
Pac
ke 1% of the packets has more than 150 ms delay
150 20010050
Delay [ms]
Hellwagner Multimedia Communication and Internet QoS 21
e ay [ s]
Example MPEG-4 Video Stream
Frame size varies considerably over time:Due to frame Frame Sizes• Due to frame patterns (I, P, B)
• Due to different
15000Frame Sizes
I−FrameP−FrameB−Framescenes
Variable bit ratet ffi 10000
B−Frame
traffic
Burstiness
10000e
Siz
e in
Byt
es
5000
Fra
me
S
Hellwagner Multimedia Communication and Internet QoS 22
0 200 400 600 800 1000 1200 1400 1600 18000
Frame Numbers
QoS Definition
Quality of Service :=“Well-defined and controllable behavior of a system according
to quantitatively measurable parameters.“ [ISO]
fLayer model, due to variety of possible views:
Use
Application
(Perception QoS)
pp
(Application QoS)
System
(Device QoS) (Communication QoS)(System QoS)
Hellwagner Multimedia Communication and Internet QoS 23
MM Devices NetworkLocal Processing
QoS Parameters: Examples
Services can be described both qualitatively and quantitatively:
QoS Layer QoS Parameters (Examples) Description Media quality Media characteristics
Application QoS
Media transmission characteristics
Parameters cover application-related requirements
Th h tThroughputLatency Response time Error detection and correction characteristics Memory and buffer specification
Parameters cover requirements on OS and communication services: - Quantitative parameters
System QoS Memory and buffer specification
Inter-stream synchronization Sequencing requirements Error handling mechanisms
y Q
Scheduling mechanisms
- Qualitative parameters
Packet sizeAverage/maximum packet rate (throughput) Burstiness Processing time for packet in network node
Comm. QoS
Jitter - “ -
Parameters cover low-level requirements on network services
Jitter - -Average/maximum disk access time
Device QoS Data transfer rate of disk
Parameters cover time-related and performance requirements on individual devices
Hellwagner 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
DelayMaximum burst size
• Maximum packet size
Delay / latencyThroughput
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
Hellwagner Multimedia Communication and Internet QoS 25
But also: security, costs, stability (resilience)
Typical QoS Requirements
QoS Max latency Max jitter Throughput Bit error Packet errorQoS Max. latency [s]
Max. jitter [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 0 25 100 2 10 < 10-6 < 10-9Compressed video
0.25 100 2 - 10 < 10 6 < 10 9
Image 1 - 2 - 10 < 10-4 < 10-9
Data (file transfer)
1 - 2 - 100 0 0
Real-time data(control)
0.001 – 1 - < 10 0 0
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)... 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 I/O subsystem network adapter router• Active resources: CPU, I/O subsystem, network adapter, router, ...• Passive resources: provide “space“; file system, buffer, link b/w, ...
C t it ll tit ti d i tiCommon parameter: capacity allows quantitative description
Compute resources
Application(source)
Application (sink)
Hybrid resources(e.g., gateway)
CPU Memory
System SW
CPU Memory
System SW
CPU Memory
System SW
Net o kNetworks NetworksQoS before QoS after
Hellwagner Multimedia Communication and Internet QoS 28
Networkresources
Data in Data outQoS beforetransmission
QoS aftertransmission
Resource Management: Goal
Starting point: scarce, but sufficient resourcesR i tRequirements
Interactivevideo Scarce
“Window of Scarcity“
Audio (CD quality)
Insufficient resources resources
Datatransfer
Sufficient resourcesRemotelogin Hardware
resourcesin year1980 1990 2000 2010
Goal: provide best service at lowest possible resource consumption / costs
in year ....1980 1990 2000 2010
Hellwagner Multimedia Communication and Internet QoS 29
consumption / costs
Resource Management: Approaches
Approaches (in other words: relationship QoS – resources):
1. Resource reservation
Phase 1: Setup RejectionPhase 1: Setup
User‘s QoSrequirements
CalculationAdmission control
Q S t
Resourcereservation
j
Phase 2: Processing / Transmission
requirementsQoS negotiation QoS guarantees
to user
g
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 g CPU/network load link bandwidth congestion
Hellwagner Multimedia Communication and Internet QoS 30
of resources; e.g., CPU/network load, link bandwidth, congestion, ...
Resource Management: Architecture
“Generic“ node architecture:
R tiControl /
Resourcemanager
Reservationdatabase
Resource
Control /
Signaling
Resource specific
informationResourcemonitor
Resourcescheduler
Data
Hellwagner Multimedia Communication and Internet QoS 31
Static Resource/QoS Management Functions
QoS specification• Qualitatively and quantitatively on various layers• Qualitatively and quantitatively, on various layers• E.g., deterministic ranges for delay, throughput, and reliability
parameters
Negotiation• Goal: contract b/w user‘s app. and system (service/QoS provider)y ( )• Application may accept lower QoS level for lower cost
Admission controlAdmission 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 be necessary to provide guaranteed QoS
Hellwagner Multimedia Communication and Internet QoS 32
y y p g• Dominating approach today (conceptually, not in implementations)
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
Hellwagner Multimedia Communication and Internet QoS 33
• Or/and tries to adapt data stream(s)
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 networkSCR Sustained Cell Rate Avg cell rateSCR Sustained Cell Rate Avg. cell rateMCR 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 & networkCTD Cell Transfer Delay Min. and max. cell delayCDVT 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, measuredCDV Cell Delay Variation Actual variance in cell delaysCER Cell Error Ratio (Max.) Ratio of erroneous cells
Hellwagner Multimedia Communication and Internet QoS 34
CER Cell Error Ratio (Max.) Ratio of erroneous cellsCMR Cell Misinsertion Ratio (Max.) Ratio of mis-delivered cells
Setup Phase: QoS Negotiation
Example: Trilateral peer-to-peer QoS negotiation
QoS requirement: QoS req and upper bound QoS >QoS reqQoS requirement: QoSminreq and upper bound QoSbound>QoSmin
req
Goal: agreement of all participants on value QoScontract
Caller Callee
QoScontract
QoSbound
QoScontract
QoSminreq QoSavail
1 2 34
ConnectRequest
ConnectConfirm
ConnectIndication
ConnectResponse
1
Hellwagner Multimedia Communication and Internet QoS 35
ServiceProvider
Setup Phase: Admission Control
Check whether requested resources are and will be available
Especially important for shared resources, like:• CPU
N t k th• Network paths• Buffer space
Example: ATM connection admission control (CAC)
Simple rule: admit new connection k i h b d id h B(k) iff
Availablen/w resources
k with bandwidth requ. B(k) iff
B(k) + Σi B(i) ≤ BtotalCAC
Traffic descr.
Service descrNetwork
Admittedconnections
[B(k) may pertain to PCR or SCR]
Must be strongly related/coupled to
Service descr.
Rejected
Hellwagner Multimedia Communication and Internet QoS 36
Must be strongly related/coupled to costs, otherwise “over provisioning“
jconnections
Setup Phase: Resource Reservation
Fundamental concept for reliable enforcement of QoS guarantees
Variants:
Pessimistic reservation: Needs of
Time
Pessimistic reservation: • Relies on worst-case assumptions• Results in guaranteed QoS
Unusedb/w
appl. 1
Needs of appl 2g
• E.g., bandwidth reservation using PCRappl. 2
Optimistic reservation:• Relies on statistical multiplexing
Conflict!• Results in statistical QoS• Can lead to QoS violations and congestion• E g bandwidth reservation using SCR
Hellwagner Multimedia Communication and Internet QoS 37
• E.g., bandwidth reservation using SCR
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 ReceiverHost‘s resource Host‘s resourceUser Host s resourcemanager User
Host s resourcemanager
QoS & conn. ReservationQrequested
Network
Reservationrequested
Reservationaccepted QoS & conn.
accepted
NetworkQoS & conn.acknowledged
Reservation to be performed
ReservationdoneQoS & conn.
established
Hellwagner Multimedia Communication and Internet QoS 38
be performedestablished
Processing Phase
Enforce QoS by:
Resource scheduling
QoS / traffic monitoringQoS / traffic monitoring
Maintenance of resource reservations
Potential acquisition of new resources
Traffic shapingg
Traffic policing
Q S f db k d t ffi d t tiQoS feedback and traffic adaptation
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 t l d t k tdoes not overload network, etc.
Traffic shaping: Traffic policing:• Usually done in hosts• Change shape of traffic
by e.g. postponing packets
• Usually done in switches/routers• Cut off traffic to conform to contract
by e.g. discarding packetsby e.g. postponing packets by e.g. discarding packets
Switch /routerHost
T ffi T ffiPCR Trafficshaping
Trafficpolicing
t t
PCR
Hellwagner Multimedia Communication and Internet QoS 40
Original traffict
Shaped traffict
Traffic Shaping and Policing (2)
Major goal: protect • network resources and • other traffic
against congestion and conflicts, caused by ill-behaving traffic sourcesagainst congestion and conflicts, caused by ill behaving traffic sources
Mechanisms:M ki k t / ll did t f l t di di• Marking packets/cells as candidates for later discarding
• Immediate discarding of packets/cells (traffic policing)• Buffering of packets/cells in host (traffic shaping)g ( 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 k t Al (i ATM t ) G i C ll R t Al (GCRA)Leaky Bucket Alg. or (in ATM terms) Generic Cell Rate Alg. (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 kta(k): arrival time of packet/cell k• TAT: theoretical arrival time of next packet/cell
GCRA (T L):GCRA (T, L):Arrival of cell k at time ta(k)
Yta(k) < TAT – L ?Cell non-conforming
Y
TAT := max(ta(k),TAT) + T
N
Hellwagner Multimedia Communication and Internet QoS 43
( a( ), )Cell conformingInitially: TAT := ta(1)
Traffic Shaping / Policing: Leaky Bucket Algorithm (3)
Illustration: L
Time
T
t1
t2T
Maximal case.Cell 2 arrives T sec after Cell 1
cell 3 expected at t2 + T
Cell
1 2(a)
(b) 1 2Slow sender.Cell 2 arrives > T sec after cell 1
t1t2
T
Cell 3 expected at t2 + T
t1 t2
(c) 1 2 Fast sender.Cell 2 arrives up to L sec early
Cell 3 expected at t + 2TT
(d) 1 2
at t1 + 2T
Very fast sender.Cell 2 arrives prior to t1 + T – L.Cell is nonconforming.
Hellwagner Multimedia Communication and Internet QoS 44
t1
Cell 3 expected at t1 + T
Traffic Shaping / Policing: Leaky Bucket Algorithm (4)
“Leaky bucket“ metaphor and interpretation:
Time
T-ε
T-ε
0 T 2T 3T 4T 5T
1
Time
T-ε
T-εT-ε
T-ε
1
2
3
4
5
Non-conformingcell
6
ε 2ε 3ε(a)
4ε 5ε
T
luid
leve
l
Bucket limit
Hellwagner Multimedia Communication and Internet QoS 45(b)0
Flu
id
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 traffic2. Formal definition and optional policing of VBR trafficre. SCR and burstiness:
GCRA (1/SCR, BT)GCRA (1/SCR, BT)
where BT = (MBS – 1) (1/SCR – 1/PCR)(BT ... Burst ToleranceMBS ... 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 sizeD t t b t itt dR ... constant output
(data rate)
Problems with bursts:
Data to be transmitted (variable input)
Problems with bursts:packet losses
Leaky Bucketββ
Data transmitted(constant drain)Control
(regulation) R
Hellwagner Multimedia Communication and Internet QoS 47
Traffic Shaping / Policing: Token Bucket Algorithm
Token Bucket Algorithm:
I t L k B k t t t l t li it d b tiImprovement over Leaky Bucket to tolerate limited burstiness
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: RReduction of data loss rate: separate data buffer
R
Token Bucketβ
D b ffAverage data rate R
Hellwagner Multimedia Communication and Internet QoS 48
Data bufferg
Traffic Shaping / Policing: Token Bucket Example
Example: two traffic flows with equal average data rate,b t diff t T k B k t d i tibut different Token Bucket descriptions
/s] 2
Flow A
dth
[Mbi
t/ Flow B
1
Ban
dwid 1
Time [s]1 2 3 4
Flow A: CBR traffic with R = 1 Mbit/s, β = 1 byte
Fl B VBR t ffi ith R 1 Mbit/ β 1 Mbit
Time [s]
Hellwagner Multimedia Communication and Internet QoS 49
Flow B: VBR traffic with R = 1 Mbit/s, β = 1 Mbit
Traffic Shaping / Policing: Token + Leaky Bucket
Token Bucket with Leaky Bucket rate control:
Smoothing of bursts of Token Bucket by Leaky Bucket at outputC ... maximum data rate R ... average data rate C > R R
Token BucketToken Bucketβ
Data buffer β C
Leaky Bucket
Hellwagner Multimedia Communication and Internet QoS 50
β C
22
Integrated Services (IntServ)Integrated Services (IntServ) and the
Resource Reservation Protocol (RSVP)( )
Hellwagner Multimedia Communication and Internet QoS 51
IntServ and RSVP
Early (mid 90‘s) IETF standard for end-to-end QoS provisioning:y ( ) p g• Extension to Internet architecture• For forthcoming real-time applications• E.g., packet voice, packet video, distributed simulation
Q S f ti l d t / t ffi flQoS for particular data / traffic flows
Flows categorized into service classesFlows categorized into service classes
Generally requires reservation of network resources in routersy qalong the path(s) of the flows as well as in the end hosts
Hellwagner Multimedia Communication and Internet QoS 52
IntServ Services Classes
1. Guaranteed service• Fixed delay bound• 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 mpt
ion
• Probabilistic delay bound• Gives the illusion of reserved channels,
under reasonable load e co
nsum
under reasonable load • Based on routers’ queuing alg. + admission control• For delay-adaptive applications R
esou
rce
3. Best effort service• Available per default
R
Hellwagner Multimedia Communication and Internet QoS 53
• For “elastic“ (adaptive) applications
Components / Mechanisms (1)
Setup, routing, background control (on end systems, impl. on user-level)
Hellwagner Multimedia Communication and Internet QoS 54
Traffic control (on end systems, impl. in the OS kernel)
Components / Mechanisms (2)
1. Reservation setup (→ RSVP)
Passes the QoS request from originating end system to each routerPasses 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 treeC i t fConsists of:
• FlowSpec: defines the desired QoS• FilterSpec: defines the subset of flows to receive this QoSFilterSpec: defines the subset of flows to receive this QoS
2. Admission controlAll t th d d li k t ti f Q SAllocates the necessary node and link resources to satisfy requ. QoSEstablishes state for flow, if accepted
3. Policy controlEnsures that QoS request and reservation is administratively possible
Hellwagner Multimedia Communication and Internet QoS 55
(Routing is separate, not part of IntServ concept.)
Components / Mechanisms (3)
4. Packet classifier
Sorts incoming data packets forming flows into appropriatescheduling classes, based on FilterSpec
St t (i filt ) t bli h d b RSVPState (i.e., filter) established by 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 outgoinglinks, based on FlowSpec
State established by RSVPState established by RSVP
Hellwagner Multimedia Communication and Internet QoS 56
FlowSpec
RSpec: characteristics requested from network, e.g.,• Guaranteed service: delay bound as parameter• Guaranteed service: delay bound as parameter• Controlled load: no additional parameters
TSpec: traffic characteristics of the flow, e.g.,• Average bandwidth and burstiness
U ll ifi d b t k b k t• Usually specified by a token bucket, e.g.,
R = 1 Mbit/s, β = 1 Mbit
2
3Flow B
R = 1 Mbit/s, β=1 byte
Mbi
t/s1
Flow ASame avg. rates, diff. token buckets
M
Hellwagner Multimedia Communication and Internet QoS 57
1 2 3 4 s
RSVP: Features (1)
RSVP ...
... is a control (signaling) protocol, not a routing protocol
i d b h t t t ifi Q S f th t k... is used by hosts to request specific QoS from the network
... is used by routers to deliver QoS requests and to establish and maintain states to provide the requested services
... supports heterogeneous hosts, QoS requests, links, etc.pp g q
... supports unicast and multicast (in fact, multipoint-to-multi-point communication), i.e., uses IP multicast for data distributionpoint 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
R i li itl t/ t t ti• Receivers explicitly request/start reservation• No need for senders to keep track of many receivers (for multicast)• Merging of reservation requests possible• Merging of reservation requests possible
... uses soft state in the routers and connectionless modelSt t ti t t ti ll ( ft 1 i t )• States time out automatically (e.g., after 1 minute)
• Can be (and need to be) refreshed periodically• Responsibility of reservation maintenance is in the end hostsResponsibility of reservation maintenance is in the end hosts• Modifications of reservations possible
is therefore robust and adaptive against route and multicast
Hellwagner Multimedia Communication and Internet QoS 59
is therefore robust and adaptive against route and multicast group membership changes
Multipoint-to-Multipoint Communication Model
Basic communication model: simplex distribution of data from m sources to n receivers (same destination)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 RESV
Hellwagner 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 every 30 seconds• Sent 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 mergeas they travel up the delivery treeas they travel up the delivery tree
Example:
1 Mbps
0.5 Mbps1 Mbps
1 Mbps 0 5 Mbps“Largest“ FlowSpec will arrive at sender(s): Least-Upper-Bound (LUB)
S i ifi ti i d t f Fl S i
1 Mbps 0.5 Mbps
Hellwagner Multimedia Communication and Internet QoS 63
Service-specific routines required to perform FlowSpec merging
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 e g voice) onto this linkISDN flows (64 kbps, 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“ bandwidth and routing tables
Hellwagner Multimedia Communication and Internet QoS 64
, y ghave to grow
33
Differentiated Services (DiffServ)Differentiated Services (DiffServ)
Hellwagner Multimedia Communication and Internet QoS 65
IntServ/RSVP Review: Major Characteristics
Per-flow signaling and reservationPer flow service state at every hop (router)Per-flow service state at every hop (router)Strict, end-to-end QoS guarantees Focus on multicastFocus on multicastVirtually connection oriented
Hellwagner Multimedia Communication and Internet QoS 66
IntServ/RSVP Review: Problems and Drawbacks
Complexity:• Reservation protocols and structure complicatedp p
- Lot of message passing; coordination problems• Heavy-weight state at every router
P i d i d- Processing and memory resources required
Scalability problem:L t f fl t (b kb ) t• Lots of flows traverse core (backbone) routers
Interoperability problems:End to end mechanisms• 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-endBut keep per-flow state and packet forwarding overheadBut keep per-flow state and packet forwarding overhead out of the core
→ Keep the architecture simple within the backbone,it hi h l it t d tpermit higher complexity at edge routers
Some data is more important than other dataSome data is more important than other dataSpecify relative priorities of packetsCharged differently for high and low priority classesCharged 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
Hellwagner Multimedia Communication and Internet QoS 68
→ Deal with flow aggregates rather than individual flows
DiffServ Goals
Simpler than IntServ
Lightweight, scalable service discrimination suitable for network backbones
N fl i li d ll ti• No per-flow signaling and resource allocation• No per-flow state• Separation of service from signalingp g g
Aggregation of traffic into priority classes• Focus on aggregates not flowsFocus on 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
Hellwagner Multimedia Communication and Internet QoS 69
• Chosen for Internet2 QoS
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 BB
Hellwagner Multimedia Communication and Internet QoS 70
DiffServ Overview (2)
Applications contract for specific QoS traffic profiles • Traffic is policed at network periphery (leaf routers)• Traffic is policed at network periphery (leaf routers) ...• ... and assigned to different service classes (packets marked) ...• ... according to Service Level Agreements (SLAs)g g ( )
between customer and ISP
Networks (“clouds”) contract for aggregate QoS traffic profiles• Aggregates are policed at network-network boundaries
(edge routers) ...di t i l bil t l b i t• ... according to simple, bilateral business agreements
Core routers apply few, simple per-hop fwd. behaviors (PHBs)• Indicated in packet header• Applied to PHB traffic aggregates (service classes)
Hellwagner Multimedia Communication and Internet QoS 71
Policing rules + PHBs = range of services
DiffServ Network Model
Bandwidth Brokers(perform admission control, manage network resources,
configure leaf and edge devices)Source Destination
BB BB
Core
Leaf Router Egress
Corerouters
Leaf Router(police, mark flows)
Ingress Edge Router
Edge Router(shape aggregates)
DiffServ (DS) Domain(separate admin. unit)
Hellwagner Multimedia Communication and Internet QoS 72
Ingress Edge Router(classify, police, mark aggregates)
DiffServ Domain
DS DomainDS Domain(e.g., ISP’s network)
I t i
Individual IngressRouter
EgressRouter
InteriorRouter
flows RouterTraffic
aggregates
Traffic conditioning,MF classification
BA classification,PHB-based forwarding
PHB-based forwarding,traffic shaping, pre-marking
Hellwagner Multimedia Communication and Internet QoS 73
Service Level Agreements (SLAs)
Agreement customer/ISP — ISP about traffic and services: Economic and technical specifications (SLSs)• Economic and technical specifications (SLSs)
• Static vs. dynamic• Quantitative vs. qualitative (relative priorities)
Service Level Specifications (SLSs):Detailed technical specifications of QoS parameters• Detailed technical specifications of QoS parameters
• Contain Traffic Conditioning Agreements/Specs. (TCAs/TCSs):- Detailed service parameters, e.g., throughput, max. delay,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- 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 low jitterPremium Service: low delay, low jitterAssured 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 ith decreasing q alitOlympic Service: three tiers with decreasing quality
• Gold• Silver• Bronze
DiffServ defines only DS field and PHBs:DiffServ defines only DS field and PHBs:• Expedited Forwarding PHB• Assured Forwarding PHB
Hellwagner Multimedia Communication and Internet QoS 75
Support/mapping of these services levels to PHBs required
Premium Service
Defines a virtual leased line: fixed maximum bandwidth, available when needed: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 alwaysDrop always
Fixed Bandwidth
Hellwagner Multimedia Communication and Internet QoS 76
Fixed Bandwidth
Assured Service
Defines a “better” best-effort line:Resources statistically provisioned:• 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
Assured ServiceCongested
Hellwagner Multimedia Communication and Internet QoS 77
Two-Bit DiffServ Border (Leaf) Router Functionality
Premium Service: Token
Packet InputWait for Packet OutputSet
Bucket
Packet Input for token
Data Queue
Packet OutputP-bit
No tokenAssured Service: Token
Bucket
Packet Input Test if token Packet OutputSet
A-bitData Queue
Token
Hellwagner Multimedia Communication and Internet QoS 78
Data Queue
Two-Bit DiffServ Interior Router Functionality
P-bitPackets InHigh Priority Queue
YesP bit set?
No
Yes
Packets OutLow Priority Queue
If A-bit set,a_cnt++
No Packets Out
RED In/Out
If A-bit set,a_cnt--
RED In/OutQueue Management
Hellwagner Multimedia Communication and Internet QoS 79
Logical View of DiffServ-Capable Router
Meter
Packetclassifier
Packetmarker
Shaper/ Dropper
PacketsIn
PHBmecha-
nism
PacketsOut
nism
PHB basedPacket Traffic Conditioning PHB-basedForwarding
PacketClassification
Hellwagner Multimedia Communication and Internet QoS 80
Routers differ by functionality actually needed/provided !
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 such asfields in the IP header, such as- Source and destination IP addresses- Source and destination port numbers- Protocol ID- TOS byte
• Operates on individual flows builds traffic aggregates• Operates on individual flows, builds traffic aggregates
Other ingress routers: behavior aggregate (BA) classificationP f ti k t b d l th t t f th• Process of sorting packets based only on the contents of the DS field in the IP header
• Operates on traffic aggregates
Hellwagner Multimedia Communication and Internet QoS 81
p gg g
Traffic Conditioning
Done in ingress routers, partially in egress routers;consisting of (a subset of):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)domain)
Shaper:• Traffic shaping according to TCA• Traffic shaping according to TCA• Packets buffered or dropped, if buffer full
Dropper: special form of traffic shaper without bufferDropper: special form of traffic 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• 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:S t b l f / i t
(6 bits) (2 bits)
• Set by leaf / ingress routers• Must be interpreted and used by DS-capable core / egress routers• Is ignored by DS-unaware routers → best-effort serviceIs 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 priority within class
Hellwagner Multimedia Communication and Internet QoS 83
p y• Backward compatibility to IPv4 TOS field required
DS Field in IP Header
TOS0 4 8 16 19 31
IPv4 header: TOS field → DS field
Version HLen
TOSLength
Ident Flags Offset
0 4 8 16 19 31
DS
g
TTL Protocol Checksum
SourceAddrSourceAddr
DestinationAddr
Options (variable) PadOptions (variable) (variable)Data
Hellwagner Multimedia Communication and Internet QoS 84
IPv6 header: Traffic class octet → DS field
Per-Hop Forwarding Behavior (PHB)
Specifies a router‘s (hop‘s) externally observable behaviorwhen forwarding (packets from) BAswhen forwarding (packets from) BAs
PHB based on DSCP; defined locally only!
Defined by:• QoS parameters like delay, jitter, loss rate, ....
Ab l t l ti (t th PHB) l• Absolute or relative (to other PHB) values• Rules how queues are shared among service classes• ....
Realized by:• Queue management and packet scheduling techniques• Queue management and packet scheduling techniques• But not specified as their parameters
→ Allow for implementation flexibility
Hellwagner Multimedia Communication and Internet QoS 85
→ Allow for implementation flexibility
DSCP – PHB Mapping
Simple table lookup, e.g.:
000000DSCP
PHB 1PHB # PHB Semantics
Best Effort001000001111
PHB 2PHB 3
Premium TrafficManagement
111000111001111101
Some rules:111101
• DSCP = 000000 → best-effort service class!• ≤ 8 service classes (CSCs) → ≥ 2 PHBs• Numerically larger DSCP → better service
Caveat: Packets from single source with different CSCs may arrive out of order,
• Numerically larger DSCP → better service
Hellwagner Multimedia Communication and Internet QoS 86
g ydue to different PHBs encountered in routers!
End-to-End Service Architecture: Example
Delivery of Premium Service with Dynamic SLA:
Example scenario: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 f ll i h t ti l b h i thi ttl d t
Hellwagner Multimedia Communication and Internet QoS 87
The following shows potential behavior; nothing settled yet.
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.f SIf request is denied, an error message is sent back to S; signaling process ends.
Step 3: Request is accepted by CN1-BB. It sends the PATH Message to ISP1-BB.
Step 4: ISP1 BB k d i i t l d i iStep 4: ISP1-BB makes an admission control decision.- 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 5Step 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 routerER2 (using LDAP or RSVP) CN2-BB will then send RSVP RESV Msg to ISP1-BBER2 (using LDAP or RSVP). CN2-BB will then send RSVP RESV Msg. to ISP1-BB.
Step 6: When ISP1-BB receives the RESV Message, it will configure classificationand policing rules on router BR1, and policing and reshaping rules on router BR2. It will then send the RESV Message to CN1 BBIt will then send the RESV Message to CN1-BB.
Step 7: When CN1-BB receives the RESV Message, it will set classification andpolicing rules on router LR1, and policing and reshaping rules on router ER1.
Hellwagner Multimedia Communication and Internet QoS 88
CN1-BB will then send the RESV Message to S.
Step 8: When S receives the RESV Message, it can start transmitting data.
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 rejection only on RESV Message from receiver )(In IntServ/RSVP, rejection only on RESV Message from 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 t i f ti i t ll d b th BB BR i ft t t ItState information installed by the BB on a BR is soft state. Itmust be regularly refreshed, or it will time out.
St 4 d 6 t d f h i t di t ISPSteps 4 and 6 repeated once for each intermediate 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 classificationStep 10: Leaf router LR1 performs an MF 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 11Step 11: Each intermediate router between LR1 and ER1 performs BA classification, puts the packets into the P-queue, and sends them out.
Step 12: ER1 performs a BA classification and reshapes the traffic to make surep p pthat the negotiated peak rate is not exceeded. Reshaping is done for theaggregation of all flows heading toward BR1, not for each individual flow.
Step 13: BR1 classifies & policies the traffic Excess premium packets areStep 13: BR1 classifies & policies the traffic. Excess premium packets aredropped.
Step 14: Intermediate routers between BR1 and BR2 (inclusive) perform BA l ifi ti BR2 l h th i t fficlassification. BR2 also reshapes the premium traffic.
Step 15: ER2 classifies & policies the traffic. Excess premium packets aredropped.
Hellwagner Multimedia Communication and Internet QoS 90
Step 16: The premium packets are delivered to host D.
DiffServ Advantages
Limited number of service classesA ti f fl i t t ffi tAggregation of flows into traffic aggregates → 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)
I t l d l t i th I t t
Hellwagner Multimedia Communication and Internet QoS 91
→ Incremental deployment in the Internet
Comparison of IntServ and DiffServ (1)
Criteria IntServ DiffServ
Granularity ofservicedifferentiation
Individual flow Aggregate offlows
State in routers(e.g., scheduling,buffer management)
Per flow Per aggregate
T ffi l ifi i S l h d DS fi ldTraffic classificationbasis
Several headerfields
DS field
Type of servicedifferentiation
Deterministic orstatistical
Absolute orrelativedifferentiation statistical
guaranteesrelativeassurance
Admission control Required Required forabsoluteabsolutedifferentiation
Signaling protocol Required (RSVP) Not requiredfor relative
Hellwagner Multimedia Communication and Internet QoS 92
schemes
Comparison of IntServ and DiffServ (2)
Criteria IntServ DiffServ
Coordination for servicedifferentiation
End-to-end Local (per-hop)
Scope of service A unicast or multicast Anywhere in aScope of servicedifferentiation
A unicast or multicastpath
Anywhere in anetwork or inspecific paths
Scalability Limited by the number Limited by theScalability Limited by the numberof flows
Limited by thenumber of classesof service
Network accounting Based on flow Based on classgcharacteristics and QoSrequirements
usage
Network management Similar to circuit Similar to existingswitching networks IP networks
Inter-domaindeployment
Multilateral agreements Bilateralagreements
Hellwagner Multimedia Communication and Internet QoS 93
44
Multiprotocol Label Switching (MPLS)Multiprotocol Label Switching (MPLS)
Hellwagner Multimedia Communication and Internet QoS 94
Internet’s Status Today
Traffic growth
C l ti i IP d t f diComplex, time-consuming IP datagram forwarding• Find IP address prefix matching with forwarding table entry
B t ff t i d lBest-effort service model• No native QoS or multi-service capability in IP networks
Scalability (of routing protocols and tables)?Scalability (of routing protocols and tables)?
Backbone
T ffi th IP f di t
Hellwagner Multimedia Communication and Internet QoS 95
Traffic growth, IP forwarding, etc.
Classical IP Datagram Forwarding
D t O t
Forwarding: find longest matching prefix in fwd. table and fwd. packet
Hop-by-hop behavior: no overall traffic cntl.
D e s t O u t4 7 .1 14 7 .2 2
D e s t O u t4 7 . 1 14 7 . 2 24 7 . 3 3
p y p
47.14 7 .3 3
13
1
2IP 47.1.1.1
IP 47.1.1.1D e s t O u t
47 2
2
1IP 47.1.1.1
D e s t O u t4 7 . 1 14 7 . 2 24 7 . 3 3
47.247.3
IP 47.1.1.12
3
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 partitioning of functionality within the networkp g y• 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 routersFacilitate 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• Flexible IP packet routing / forwarding
• Fast ATM circuit switching
IP IP #L1 IP #L2 IP #L3 IP
IP ForwardingMP Label Switching:packets are switched on labels,
IP Forwarding
Hellwagner Multimedia Communication and Internet QoS 98
prather than destination IP address
Label Switching Devices
Label Edge Routers (LERs): LSRs at edge of MPLS network• Ingress LERs are responsible for classifying unlabelled IP packets
d di th i t l b land appending the appropriate label.• 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 Ed R t
Hellwagner Multimedia Communication and Internet QoS 99
Label Edge Routers
Forwarding Equivalence Classes (FEC)
LSRLSRLER LERLSP
IP1 IP1IP1 #L1 IP1 #L2 IP1 #L3
IP2 IP2
IP1 #L1
IP2 #L1
IP1 #L2
IP2 #L2
IP1 #L3
IP2 #L3
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
C t f FEC id f fl ibilit d l bilitConcept of FECs provides for flexibility and scalability
In conventional routing, a packet is assigned to a FEC at each hop (i e L3 look-up) in MPLS it is only done once at the
Hellwagner Multimedia Communication and Internet QoS 100
hop (i.e., L3 look-up), in MPLS it is only done once at the network ingress
Label Switched Path (LSP)
Intf In
Label In
Dest Intf Out
IntfIn
Label In
Dest Intf Out
Label Out
Label Swapping (Substituion)
In In Out3 40 47.1 1
In In Out Out 3 50 47.1 1 40
47.13
1Intf Dest Intf Label
IP 47.1.1.1
1
3
2
1
3Intf In
Dest Intf Out
Label Out
3 47.1 1 50
LERLSR
47.247.321
23
IP 47 1 1 1IP 47.1.1.1 LER
MPLS adds a connection oriented paradigm to IP networks!
Hellwagner Multimedia Communication and Internet QoS 101
MPLS adds a connection-oriented paradigm to IP networks!
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 labelIncoming label- Outgoing label- Outgoing interface
LFIB i i d d b i i l b l ( f f di f ATM)• LFIB is indexed by incoming label (→ fast forwarding, cf. 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
among LSRs
Label Distribution
Intf Label Dest Intf Intf Label Dest Intf Label
Label Binding
In In Out 3 40 47.1 1
IntfIn
Label In
Dest Intf Out
Label Out
3 50 47.1 1 40
47 11 47.1
1
31
2
3Intf In
Dest Intf Out
Label Out
3 47.1 1 50 M i 40
Request: 47.1
47.247.321
23
Mapping: 40
Hellwagner Multimedia Communication and Internet QoS 103
Various Label Distribution Protocols (LDPs) under development/standard.
Example for LSP Setup: Explicitly Routed (ER) LSPIntfIn
Label In
Dest Intf Out
3 40 47.1 1
IntfIn
Label In
Dest Intf Out
Label Out
3 50 47.1 1 40 Intf I
Dest Intf O t
Label O t
47.1
1
31
2
3
In Out Out3 47.1.1 2 33 3 47.1 1 50
IP 47.1.1.1
DRoute = A B C D
47.247.3
1
2
2
1
23
DRoute = A,B,C,D
2IP 47.1.1.1
BC
A
ER LSP t h b ( ti ) i t lER-LSP: route chosen by source (source routing), via control messages:• Can use routes other than shortest path• Routing flexibility for network operator (policy-based, QoS-based)
Hellwagner Multimedia Communication and Internet QoS 104
g y p (p y , )
Other routing protocols in use as well, e.g., constraint-based routing (CR)
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 2 5” technology→ Layer 2.5 technology
• ATM: label contained in VCI/VPI field of ATM header
• Frame RelayFrame 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)
1nLayer 2 Header
(e.g., PPP, 802.3)
••• 1nNetwork Layer Headerand Packet (e.g., IP)
Label Exp. S TTL
4 BytesLabel Stack
Entry Format
Label: Label Value, 20 bits (0-16 reserved)Exp.: Experimental, 3 bits (was Class of Service)S: Bottom of Stack, 1 bit (1 = last entry in label stack)TTL Ti t Li 8 bitTTL: Time to Live, 8 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
Wh l t l b l i d ff t k MPLS TTL t b i d t IP TTL fi ld
Hellwagner Multimedia Communication and Internet QoS 106
• When last label is popped off stack, MPLS TTL to be copied to IP TTL field
Hierarchy via Label Stack
Layer 2 Header Label 3 IP PacketLabel 2 Label 1
MPLS Domain 1
MPLS D i 2MPLS Domain 2
MPLS Domain 3
S t t k l bilit
Hellwagner Multimedia Communication and Internet QoS 107
Supports network scalability
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 routersDifferentiated behavior of routers• Packet labelling at edge, based on routing information• Packet forwarding in core based on labelsPacket forwarding in core, based on labels
(much alike ATM cell switching)
Enhanced IP routing protocolsg p• Which distribute topology and constraint-based data
Label distribution protocolsLabel distribution protocols• Standardized (or, yet to be) connection establishment protocols
through which LSRs set up a complete path (LSP) from ingress LSR t LSR
Hellwagner Multimedia Communication and Internet QoS 108
LSR to egress LSR.
MPLS – The Big Picture
1. Existing routing protocols (e.g. OSPF, IGRP) establish routes.
2a. Label Distribution Protocol (e.g., LDP) establishes label to routes mappings
2b. Label Distribution Protocol (e.g., LDP) creates LFIB entries on LSRson LSRs
5. Edge LSR at egress removes label and delivers packet
4. LSRs forward labelled packets using label swapping
3. Ingress edge LSR receives packet, performs Layer 3 value-added services and “label” packets
Hellwagner Multimedia Communication and Internet QoS 109
using label swappingservices, and label packets
MPLS Traffic Engineering: Motivation
Current interior gateway routing protocols (IGPs) can lead tounfavorable traffic distribution:
• Over-utilized and under-utilized links• Due to shortest path routing
Traffic for D,shortest path routed
Avoid in backbone!9 under-ultilized links 4 over-utilized links
D
S
M i
Hellwagner Multimedia Communication and Internet QoS 110
CongestionMassive
congestion
MPLS Traffic Engineering: Objectives
Map/distribute actual traffic efficiently to available resources
Use resources in a controlled wayUse resources in a controlled way
Redistribute traffic rapidly and effectively in response to changes in network topology (e.g., link or router failure)changes in network topology (e.g., link or router failure)
DUse of MPLS LSPs
S
Hellwagner Multimedia Communication and Internet QoS 111
This helps real-time traffic requiring QoS
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
I LSR b fi d ith th th RSVP d t t LSP• Ingress LSR may be configured with the path, RSVP used to set up LSP• Some vendors have extended RSVP for MPLS path set-up
• Ingress LSR may be configured with the path LDP used to set up LSP• Ingress LSR may be configured with the 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• 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
Hellwagner Multimedia Communication and Internet QoS 112
tasks from the operator to the network itself
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 MPLS signaling and forwarding:g g g 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• 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: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 MPLS DiffServ, packets classified by label / EXP bits
Hellwagner Multimedia Communication and Internet QoS 113
o S Se , pac ets c ass ed by abe / b ts
MPLS DiffServ can be thought of undistinguishable from IP DiffServ
Example: MPLS End-to-End CoS and QoS
DiffServ mapping to MPLS switching
Packets are DiffServ DiffServ CoS used
DiffServ mapping to LSPs
gin the core
Packets are DiffServ classified at router
DiffServ CoS used on egress to router
BB
A A
Telnet FTP TCP VideoPer-connection/flow QoS for Premium Services
T l t FTP TCP Vid
Hellwagner Multimedia Communication and Internet QoS 114
Telnet FTP TCP Video
55
Real-Time Multimedia Data TransportReal-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., between video and corresponding audiog , p g
Indication of packet loss, thus also congestion• RTP runs typically over non-reliable transport (UDP)RTP runs typically over 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 silencesg
Sender identification• IP address is not extremely user-friendlyIP address is not extremely user friendly
Efficiency• No long headers are acceptable• 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:
RTP (Real-time Transport Protocol)
Application
IP (Internet Protocol)
UDP (User Datagram Protocol)
( ea t e a spo t otoco )
Network
IP (Internet Protocol)
Hellwagner Multimedia Communication and Internet QoS 118
RTP (2)
Twin-standard by IETF (with RTCP)• RTP: exchange of multimedia data• RTP: exchange of multimedia data• RTCP: exchange of periodic control information• They use consecutive even–odd port numbersThey use consecutive even odd port numbers
Application Level Framing (ALF)• Applications understand their needs best• Applications understand their needs best• Profile
- Defines the meaning of certain fields in the header
• Payload formats- Interpretation of data following the header,
e g as simple stream of bytes or some more complex structuree.g., as simple stream of bytes or some more complex structure (MPEG)
Hellwagner Multimedia Communication and Internet QoS 119
RTP Header Format (1)
V2 P1 X1 CC4 M1 PT7 Sequence number16
Number of bits
Timestamp32
Synchronization source (SSRC) identifier
V2 P1 X1 CC4 M1 PT7 Sequence number16
Contributing source (CSRC) identifier…
Extension header
V: version no. – 2 bits might be few, later extensions possible (subversion)P: Padding is usedX: Extension header existsX: Extension header existsCC: 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
Hellwagner Multimedia Communication and Internet QoS 120
M: Marks the packet, e.g., as start of frame the app. uses it at wishPT: Payload type
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 streame.g., different UDP ports for each stream
Sequence numberTh d j t i t it h dli b li ti• The sender just increments it – handling by application
• 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 carried in the UDP header
The length of the RTP data is coded in the UDP header
g
If the RTP payload is less than this length, then padding is used
AdvantageAdvantage• The RTP header remains short: 1 bit suffices• The Pad count byte is used only if this place is unused by theThe 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,i h h f iwith the functions:
• Performance feedbackE f d ti li ti- E.g., for adaptive applications
• Correlate and synchronize media streams of the same sender- The same sender may have several SSRC valuesThe 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 source) identifier( y )• 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 senderDelay since last sender report received via RTP for this sender
Extra sender information, enabling synchronization• Timestamp of the actual date time of report generationTimestamp 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
Hellwagner Multimedia Communication and Internet QoS 125
Application-specific control packets
RTCP Operation
RTCP traffic is limited to ~ 5% of RTP traffic• The report generation slows down if necessary
Recipients and sender may react on the reportsp y 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 granularityeven 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 mechanismsNo explicit QoS mechanisms
Delivers only control data, no payload
Syntax similar to HTTP, but the server does have state
Extensible by new methods and/or parametersy
Supported operations• Download of media data from a media serverDownload 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
Adding of media to an existing presentation
Control and User Data
TCP connection(Server def. port: 554)
Port 2n for RTP Port 2n+1 for RTCP
RTSP Control connection
User data
Case 1: Control and data pyhsically separatedRTP data + RTCP reports
TCP connection(Server def. port: 554)
U d t
RTSP Control connection
User data
Case 2: Control and data only logically separated
Hellwagner Multimedia Communication and Internet QoS 128
Case 2: Control and data only logically separated
RTSP State Diagram
ReadyInit
SETUP
TEARDOWNTEARDOWN
PLAY
RECORDPAUSETEARDOWN PAUSE
Playing Recording
PLAY
Playing Recording
TEARDOWN
Hellwagner Multimedia Communication and Internet QoS 129
RTSP Session Protocol
Client Web HTTP GETMedia description
Media server
serverMedia description
OPTIONSTransport options
Ident. actual version
SETUPOK
Offered types of delivery Selected type
of delivery
PLAYOK
Media data (usually via RTP)Media data (usually via RTP)
Stream control data (usually via RTCP)
PAUSE
TEARDOWNOK
PAUSEOK
Hellwagner Multimedia Communication and Internet QoS 130
OK
RTSP Methods
Method Direction Object Availability
DESCRIBE C → S P, S suggestedANNOUNCE C ↔ S P, S optionalANNOUNCE C ↔ S P, S optionalGET_PARAMETER C ↔ S P, S optionalOPTIONS C ↔ S P, S mandatory
(S → C: optional)( p )PAUSE C → S P, S suggested PLAY C → S P, S mandatory RECORD C → S P, S optionalpREDIRECT S → C P, S optionalSETUP C → S S mandatory SET_PARAMETER C ↔ S P, S optionalTEARDOWN C → S P, S mandatory
Hellwagner Multimedia Communication and Internet QoS 131
RTSP: OPTIONS and SETUP
C -> S: OPTIONS * RTSP/1.0C 1Cseq: 1Require: implicit-playProxy-Require: gzipped-messages
S -> C: RTSP/1.0 200 OKCseq: 1Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
C -> S: SETUP rtsp://server.com/media RTSP/1.0Cseq: 302
/ i li 4588 4589Transport: RTP/AVP;unicast;client_port=4588-4589
S -> C: RTSP/1.0 200 OKCseq: 302qDate: 11 Jan 2001 10:30:06 GMTSession: 447745Transport: RTP/AVP;unicast;client_port=4588-4589;
Hellwagner Multimedia Communication and Internet QoS 132
server_port=6256-6257
RTSP: PLAY and PAUSE
C -> S: PLAY rtsp://server com/media RTSP/1 0C > S: PLAY rtsp://server.com/media RTSP/1.0Cseq: 825Session: 447745Range: npt=10-15 (normal play time, 10.-15. sec)Range: npt 10 15 (normal play time, 10. 15. sec)
S -> C: RTSP/1.0 200 OKCseq: 825D t 11 J 2001 10 30 06 GMTDate: 11 Jan 2001 10:30:06 GMT
C > S: PAUSE rtsp://server com/media RTSP/1 0C -> S: PAUSE rtsp://server.com/media RTSP/1.0Cseq: 834Session: 447745
S -> C: RTSP/1.0 200 OKCseq: 834Date: 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.0Cseq: 2Transport: RTP/AVP/TCP;interleaved=0 1Transport: RTP/AVP/TCP;interleaved=0-1
S -> C: RTSP/1.0 200 OKCseq: 2Date: 11 Jan 2001 10:36:30 GMTDate: 11 Jan 2001 10:36:30 GMTTransport: RTP/AVP/TCP;interleaved=0-1Session: 123456
C -> S: PLAY rtsp://server com/media RTSP/1 0C -> S: PLAY rtsp://server.com/media RTSP/1.0Cseq: 3Session: 123456
S -> C: RTSP/1 0 200 OKS -> C: RTSP/1.0 200 OKCseq: 3Session: 123456Date: 11 Jan 2001 10:31:24 GMTRTP-Info: url=rtsp://server.com/media;seq=232433; rtptime=972948234
S -> C: $\000(2 byte length)(“length“ bytes data, w/RTP header)
Hellwagner Multimedia Communication and Internet QoS 134
S -> C: $\001(2 byte length)(“length“ bytes RTCP packet
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 e g sip:dbaron@mit edu• URIs, e.g. sip:[email protected]
Supports user location, call setup, call transfers
Supports mobility by proxying and redirectionSupports mobility by proxying and redirection
Works together with other IP protocols:SAP (S Ad ertisement P ) for ad ertising m ltimedia sessions• SAP (S. Advertisement P.) for advertising multimedia sessions
• SDP (S. Description P.) for describing multimedia sessions• RSVP for network-resource reservation
Hellwagner Multimedia Communication and Internet QoS 135
RSVP for network resource reservation• RTP, RTCP, RTSP for real time data transport
SIP Components
SIP End Devices:• User Agent Clients (originating calls)• User Agent Clients (originating calls)
• User Agent Servers (listening for incoming calls)
SSIP Registrar:• Accepts registration requests from users
M i t i ‘ h b t t L ti S• Maintains user‘s whereabouts at a Location Server
SIP Proxy Server:• Relays call signaling (acting as client and server)
• Keeps no session state
SIP Redirect Server:• Redirects callers to other servers
Hellwagner Multimedia Communication and Internet QoS 136
SIP Gateways
SIP Trapezoid
DNS S
Location SServer Server
DNSRegistrar
Outgoing Proxy
SIP
Incoming Proxy
SIP SIP SIP
TerminatingOriginating SIP
C i lif t t i l P2P i li
Terminating User AgentUser Agent RTP
Hellwagner Multimedia Communication and Internet QoS 137
Can simplify to triangle or P2P signaling
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 withcallees
E lExamples:• sip:[email protected]
i i il@i t l ? bj t ll• sip:[email protected]?subject=callme
• 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 requestCANCEL 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 Found4XX 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
INVITE: sip:18.18.2.4“Calls” 18.18.2.4
180 - Ringing Rings
ACK
200 - OK Answers
RTPTalking Talking
200 - OK
BYEHangs up
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/sdpContent-Type: application/sdp
Content-Length: 304
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE
Supported: sip-cc sip-cc-01 timer replacesSupported: sip-cc, sip-cc-01, timer, replaces
User-Agent: Pingtel/2.1.11 (WinNT)
Date: Thu, 30 Sep 2004 00:28:42 GMT
Hellwagner Multimedia Communication and Internet QoS 142
Via: SIP/2.0/UDP 18.10.0.79
Session Description Protocol (SDP) [RFC 2327]
Intended for describing multimedia sessions for the purposes of i t i i it ti d th f fsession announcement, session invitation, and other forms of
multimedia session initiation
I l d dIncluded:• Type of media (video, audio, etc.)• Transport protocol (RTP/UDP/IP H 320 etc )• Transport protocol (RTP/UDP/IP, H.320, etc.)• Format of the media (H.261 video, MPEG video, etc.)• Information to receive those media (addresses, ports, formats and ( , p ,
so on)
Hellwagner Multimedia Communication and Internet QoS 143
SDP
v=0
o=Pingtel 5 5 IN IP4 18.10.0.79o gte 5 5 8 0 0 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
Hellwagner Multimedia Communication and Internet QoS 144
a=rtpmap:98 telephone-event/8000/1
66
ConclusionsConclusions
Hellwagner Multimedia Communication and Internet QoS 145
Concluding Remarks
Challenging QoS requirements,b i ll i f lti di i tibasically emerging from multimedia communication
M I t t Q S h / h i d d t t dMany Internet QoS approaches/mechanisms proposed and tested,many not adopted, not feasible in practice, refused
Currently most successful: MPLSCurrently 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