p3_rsvp
TRANSCRIPT
-
8/8/2019 P3_rsvp
1/86
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 1
-
8/8/2019 P3_rsvp
2/86
e :
1. L. Zhang, S. Deering, D. Estrin, S. Shenker and D.,
protocol, IEEE Network, Vol. 7, pp. 8-18, Sept 1993.2. B. Braden, L. Zhan , S. Berson, S. Herzo and S.
Jamin, Resource ReSerVation protocol (RSVP)
version 1 functional specification, RFC 2205, Internet, .
3. P. Pan and H. Schulzrinne, YESSIR: A SimpleReservation Mechanism for the Internet ACM
SIGCOMM Computer Communication Review, vol.29, no. 2, pp. 89-101, Apr 99.
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 2
-
8/8/2019 P3_rsvp
3/86
u me a on e n erne
ec ve:
To su ort new distributed a lications such as
remote video, multimedia conferencing, data
diffusion and virtual realit etc.
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 3
-
8/8/2019 P3_rsvp
4/86
Characteristics of these applications:
A lic tions re er sensiti e to the lit of
Service their packets receive -
Should allow flows, i.e. data traffic streams, toreserve network resources
These applications are often multipoint-to-multi oint with several senders and receivers
e.g. multiparty conferencing where each participantis both a sender and a receiver of data
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 4
-
8/8/2019 P3_rsvp
5/86
QoS, the network architecture requires the
Flow Specification
escr e o e c arac er s cs o e ra c s ream sen
by the source and the service requirements of the
application
Ref.: RFC 1363, RC 1190
Routing
Routing protocols that support QoS and multicast
ST 2+ (RFC 1819), Core Based Tree (CBT), Mrouted
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 5
-
8/8/2019 P3_rsvp
6/86
To provide guarantee QoS for a particular data flow, it is
necessary to set aside certain resources, such as buffer,
bandwidth, etc. i.e. need to create and maintain resource reservation
RSVP (RFC 2205)
For supporting real-time applications
RTP RFC 1889 XTP
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 6
-
8/8/2019 P3_rsvp
7/86
As network resources are limited, the network cannot
satisfy all reservation requests
An admission control mechanism is needed to determinewhich reservation requests are to be accepted and whichto be denied
Packet Scheduling
When a network switch receives the packets from a,
packet to be transmitted
The packet scheduler will actually determine the quality
of service t at t e networ can provi e E.g. Weighted Fair Queuing, Worst-case Weighted Fair
ueuin , Real-time Virtual Clock
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 7
-
8/8/2019 P3_rsvp
8/86
esource e er at on rotoco
Protocol for resource reservation on top of IP for real-time traffic
RSVP is NOT a routing protocol
A simplex protocol, i.e. reserves resources in only one
direction from source to receiver
Bidirectional resource reservation requires both end systems
to initiate separate reservations
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 8
-
8/8/2019 P3_rsvp
9/86
Receiver initiates and maintains the resource reservations Enables RSVP to accommodate heterogeneous receivers in a
multicast group
ac rece ver may reserve a eren amoun o
resources Not all receivers have the same processing capacity for
incoming data
Different receivers may require different quality ofservice
E.g. if layered encoding is used for video signal
some receivers will have enough processing power to
eco e ow-reso u on s gna on y some paths may have enough bandwidth for low
resolution signal only
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 9
-
8/8/2019 P3_rsvp
10/86
Reservation must hence be dynamic such that separate
dynamic reservations are needed for each member
Allow end-users to specify their application needs E.g. In audio conferencing, usually only one person, or at
mos a ew persons, w a a e same me. ence,
is adequate to reserve only resources from a few
simultaneously audio channels.
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 10
-
8/8/2019 P3_rsvp
11/86
Receiver should be able to switch between channels
E.g. In multiparty conference, a receiver may want to watch
among various participants. Hence, receiver should be able to
control which data stream is carried on the reserved
resources sw tc among c anne s
Reservations from different receivers, i.e. downstream
,be merged as reservations travel upstream
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 11
-
8/8/2019 P3_rsvp
12/86
RSVP ArchitectureHost Router
RSVP
process
Appli-
cationRSVP
processRoutingRSVP
Policy
control
Policy
control
process
Data
Admission
control
Admission
control
Packet
scheduler
Classi-
fier
Packet
scheduler
Classi-
fier
Data Data
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 12
-
8/8/2019 P3_rsvp
13/86
RSVP O eration - Overview Receivers use RSVP to deliver its request to the routers
a ong t e ata streams pat s towar s t e sources
RSVP is used to negotiate connection parameters with the
If a reservation is setup, RSVP is also responsible for
maintaining the router and host states to provide therequested service
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 13
-
8/8/2019 P3_rsvp
14/86
The RSVP process in each node performs local
procedures for reservation setup and enforcement
o cy con ro : e erm nes e app ca on s a owe o
make the reservation
In future authentication access control and accountin
for reservation may also be implemented by the policy
control m ss on con ro : eeps rac o e sys em resources an
determines whether the node has sufficient resources to
supply the requested QoS
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 14
-
8/8/2019 P3_rsvp
15/86
The RSVP daemon checks both the policy control and
admission control procedures
e t er c ec a s, an error s returne to t e
application that originate the request
o c ec s succee , e aemon se s
parameters in packet classifier and packet scheduler to
Packet classifier determines the QoS class for each packet
Packet scheduler orders acket transmission to achieve the
promised QoS for each stream
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 15
-
8/8/2019 P3_rsvp
16/86
uses two as c messages: at an esv
Path messages are sent periodically from the sender to
Path message is sent from source to receivers via the pathsdecided by the routing protocol
Path state is stored in each node along the way
Contains at least the unicast IP address of the previousho node which is used to route theResv messa es ho -by-hop in the reserve direction from the receivers
Contains the description of the traffic characteristics, Tspec,
Info. is used by the receivers to find reserve path to thesender and to determine the amount of resources need to be
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 16
reserve
-
8/8/2019 P3_rsvp
17/86
Resv messages are used by the receivers for setting up
reservations
on a ns reserva on parame ers
Resv messages travel toward the senders by following
exactl the reverse of the routes which data ackets will use
Resv messages are delivered to the sender hosts so that the
hosts can set up appropriate traffic control parameters for thers op
Path Path
R1S Path Path
ResvResv
Resv
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 17
-
8/8/2019 P3_rsvp
18/86
Reservation mer in When there are multiple receivers, the resource is
not reserved for each receiver
The resource is shared up to the point where thepaths to different receivers diverge
R3
Rx1Path
Path
ResvR1 Path
Resv ResvRx2
Path
Resv
Rx3
Path
Resv
Path
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 18
Resv
-
8/8/2019 P3_rsvp
19/86
different receivers at the point where multiple
re uests conver e
A reservation moving upstream will stop at thepoint where there is already an existing
reservation that is equal or greater than that being
requested This helps to reduce the RSVP traffic when there
are many receivers in the multicast tree
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 19
-
8/8/2019 P3_rsvp
20/86
Source
The source provide the Sender Tspec to RSVP Flows towards the receivers
Sender Tspec
data source, i.e. describe the traffic the application
ex ects to enerate
Token bucket rate
Token bucket size
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 20
-
8/8/2019 P3_rsvp
21/86
Peak data rate
Minimum packet size
This includes the application data and protocol
ea ers a or a ove eve
Used by the network node to compute the bandwidth
overhead needed to carr the flow over a articular
link-level technology and hence to compute the
amount of bandwidth to be allocated to the flow ax mum pac et s ze
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 21
-
8/8/2019 P3_rsvp
22/86
Source/Intermediate Network Elements
Adspec is generated at either the source or the
intermediate network elements
Adspec
Info. carried in the Adspec may be changed by
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 22
-
8/8/2019 P3_rsvp
23/86
Describe the properties of the data path, i.e. contains
.requirements of the sending application
Global Break bit
this bit is set if a router not supporting RSVP isencountered
is aware of the gap in integrated services coverage
use to inform the receiver that the Adspec may be invalid op count
estimate bandwidth available (min. of individual linkbandwidths along the path)
min. path latency (summation of individual link latencies)
Path Max. Transmission Unit (MTU): min. of MTUs of
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 23
-
8/8/2019 P3_rsvp
24/86
Reservation and Filtering
ece ver
Initiates the RSVP reservation and the request is sent towards tosource
A RSVP reservation request consists of aflowspec and afilter spec
Flowspec contains aReceiver_Tspec andRspec
_
Describe the level of traffic for which resources should be reserved
Specify the bucket rate, bucket size, peak data rate, min. and max.acket size
Rspec
Describe the level of QoS service desired
S ecif the desired bandwidth and dela uarantees
Used by packet scheduler
Specify the amount of resources to be reserved but NOT which datastream can use the resources
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 24
-
8/8/2019 P3_rsvp
25/86
Reservation and Filtering (contd)
Filter spec defines the data stream, i.e. the flow,
Used by packet classifier
e a a s ream us ng e resources can y c ange
by the receiver without changing the amount of
This is used to support switching between different
channels
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 25
-
8/8/2019 P3_rsvp
26/86
Reservation St lesReservation style is a set of options that specifies how the
reserved resources can be used by different datastreams
One option specifies the reservation class
Distinct reservations: a reservation is for each sender in eachsession
Shared reservations: a reservation is used b a set of sendersthat are known not to interfere with each other
Another option controls the selection of senders
xp c t: spec y a st o se ecte sen ers Wildcard: the reserved resources are for all senders to the
session
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 26
-
8/8/2019 P3_rsvp
27/86
3 reservation styles have been defined:
ReservationsSender
Selection Distinct Shared
Explicit Fixed-Filter (FF)
st le
Shared-Explicit
SE St le
Wildcard (None defined) Wildcard-Filter
y e
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 27
-
8/8/2019 P3_rsvp
28/86
Wildcard-filter (WF) Style
s ng e reserva on s crea e an s s are y ows rom aupstream senders
i.e. an ackets destined to the multicast rou can use the
reserved resources A shared pipe whose size is the largest of the resource requests
or t at n rom a rece vers, n epen ent o t e num er o
senders using it
Suitable for a lications in which there are multi le data sources
but they are unlikely to transmit simultaneously
Symbolic representation:
WF ( * {Q}) where * represents wildcard sender selection and Q is the
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 28
-
8/8/2019 P3_rsvp
29/86
Fixed-filter (FF) Style
st nct reservat on request s create or ata pac etsfrom each sender
total of the FF reservations for all requested senders FF reservations re uested b different receivers, but the
same sender, must be merged to share a singlereservation in a given node
ym o c representat on:
FF ( S{Q})
For multiple FF reservation: FF(S1{Q1}, S2{Q2}, )
The total reservation is the sum of Q1, Q2, for all
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 29
requested senders
-
8/8/2019 P3_rsvp
30/86
Shared-explicit (SE) Style
s ng e reservat on s create an s s are y a set oexplicit senders
the reservation The receiver can switch between senders b informin
the intermediate nodes
The packet classifier of the intermediate will filter offt ose ows t at are not se ecte y t e rece ver
Symbolic representation:
, ,
where S1, S2, are senders and Q is the flowspec
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 30
-
8/8/2019 P3_rsvp
31/86
Note:
WF and SE are appropriate for multicast applications in
which application-specific constraints make it unlikely
that multiple data sources will transmit simultaneously
e.g. In audio conferencing, a limited number of people talk at the
same t me
Each receiver might issue a WF or SE reservation request for a
cou le of audio channels
different senders
More appropriate for video signals if video from all participants
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 31
need to be displayed
-
8/8/2019 P3_rsvp
32/86
Exam le:
( S1 ) ( R1 )(a) (c)
Router
( S2, S3 )( R2 )(b) (d)
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 32
-
8/8/2019 P3_rsvp
33/86
Exam le contd
A router has two incoming interfaces (a) and (b),and two out oin interfaces (c) and (d)
Three upstream senders: S1, S2 and S3
Assume that (d) is connected to a broadcast LAN,
. .R3 are reached via different next hop routers (notshown)
Data packets from each Si are routed to bothout oin interfaces
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 33
-
8/8/2019 P3_rsvp
34/86
Exam le contd Wildcard-Filter (WF) style
Send Reserve Receive
WF( *{4B} )(a) (c)*{4B}
WF( *{4B} )
WF( *{4B} )WF( *{3B} )WF( *{2B} )* 3B
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 34
-
8/8/2019 P3_rsvp
35/86
Exam le contd Fixed-Filter (FF) style
Send Reserve Receive
(a) (c)FF( S1{4B} )
S1{4B}
S2{5B}
FF( S1{4B}, S2{5B} )
FF( S1{3B}, S3{B} )FF( S1{B} )
d
FF(S2{5B}, S3{B}) S1{3B}
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 35
-
8/8/2019 P3_rsvp
36/86
Exam le contd Shared-Explicit (SE) style
Send Reserve Receive
SE((S1,S2){B})(a) (c)
SE(S1{3B})(S1,S2){B}
SE((S1,S3){3B})
SE(S2{2B})SE((S2, S3){3B}) (S1,S2,S3)
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 36
-
8/8/2019 P3_rsvp
37/86
Exam le:
In the previous example, data packets from S1, S2 and S3
are forwarded to both outgoing interfaces
Here, packets from S2 and S3 are forwarded only tooutgoing interface (d)
There may be a shorter path to R1 via some other router
Router
( S1 ) ( R1 )
( R2 )
(a)
(b)
(c)
(d)2, 3
( R3 )
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 37
Router Configuration
-
8/8/2019 P3_rsvp
38/86
Exam le contd Wildcard-Filter (WF) style
Send Reserve Receive
WF( *{4B} )(a) (c)*{4B}
WF( *{4B} )
WF( *{3B} )WF( *{3B} )WF( *{2B} )* 3B
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 38
-
8/8/2019 P3_rsvp
39/86
Scalabilit Reservation merging leads to the primary advantages of RSVP
scalability
increasing the data traffic significantly A single physical interface may receive multiple reservation
requests from different next hops for the same session and with thesame filter spec
RSVP should install onl one reservation on that interface The installed reservation should have an effective flowspec that
is the "largest of the flowspecs requested by the different next
Similarly, a Resv message forwarded to a previous hop should carrya flowspec that is the "largest" of the flowspecs requested by the
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 39
-
8/8/2019 P3_rsvp
40/86
RSVP Operation1. A source joining a multicast group will consult its routing
protocol to obtain the routes.
. ,
theAdspec, from the source will be sent downstream.3. The Path message is used to update thePath state of each
sw c a ong e pa . e a s a e nc u es:
The incoming link upstream to the source
The out oin link downstream from the source to thereceivers in the group
The Path state is used to route the reservation in the
Note: the Tspec will not be modified by the switch on itsway from the source to the receivers; however, the break
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 40
n e spec may e mo e y e sw c anetwork element not supporting RSVP is encountered
-
8/8/2019 P3_rsvp
41/86
4. When a path message arrives a switch, the switch will
Checks to see if it already has the path state for the namedgroup; if not, a path state will be created
routing protocol Update its table of incoming and outgoing links
Record the source address if the path message indicates that the
application may require a filtered reservation
e pa message s orwar e s rom a new source or
there is a change in routes
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 41
-
8/8/2019 P3_rsvp
42/86
Example
S1 S4
H4
H2
S3
H3
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 42
-
8/8/2019 P3_rsvp
43/86
-
8/8/2019 P3_rsvp
44/86
6. When a switch receives the reservation message
If resources cannot be allocated to the request, a RSVPResvError messages are sent back to all the receiver and thereservation messa e is discarded
Note: a reservation request may embody a number ofrequests merged together
e reserva on s es a s e , e n o. n e reserva onmessage is used to maintain thereservation state at the switch
The switch will also try to merge the requests for the samemulticast group by pruning those carry a request for reservinga smaller, or equal, amount of resources than the previousrequest
The reservation message is forwarded to the next switchupstream if new (extra) resources are needed
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 44
-
8/8/2019 P3_rsvp
45/86
Exam les:
1. Reservation with wildcard filtering
Audio conferencing among 5 participants
Each host behaves as a source and receiver Audio rate: b
H2H3
H4R1 R2 R3
H5
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 45
-
8/8/2019 P3_rsvp
46/86
Assumed that the routing protocol has built a multicast routing
tree from each source
Note: With wildcard filtering, the switches will not record the
H1, , H5 all send path messages to address m1 Su ose H1 sends the first ath messa e
inout
inout
in L6
L1
L2 L6 L3L7
L4m1:m1:
out
H2 H3
L3
L5 L7
H4
H1
R1 R2 R3L1
L4
L5
L6 L7
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 46
H5
-
8/8/2019 P3_rsvp
47/86
Next, H5 sends path message, creating more state in routers
in
out
in
outin L6
L1
L2 L6 L3
L7
L4L5
L6
L1
m1:
m1:
m1:
H2 H3
L2L3
H4
H1
R1 R2 R3L1
L4
L5
L6 L7
H5
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 47
-
8/8/2019 P3_rsvp
48/86
H2, H3, H4 send path messages, completing the path state tables
inoutinoutL1
L2 L6 L3L7L4L6L1
L4L3 L7L2m1: m1:
out
H2 H3
L5 L7L6m :
H4
H1
R1 R2 R3L1
L4
L5
L6 L7
H5
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 48
-
8/8/2019 P3_rsvp
49/86
H1 wants to receive data from all senders but onl wants
enough bandwidth for ONE audio stream
H1 sends the reservation message(b, wildcard filter)
upstream to all sources
With wildcard filter, any sender can use the reserved
bandwidth
H2 H3
L2 L3
L6 L7
H5
H1 L1 L5
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 49
-
8/8/2019 P3_rsvp
50/86
When a router receives the reservation messa e
it reserves bandwidth b on the downstream link towards H1
When a host receives the reservation message
it sets up appropriate traffic control parameters for the first
hop
inout
L1L2 L6
L6
L1(b)
in L5 L7L6
inout
L3L4 L7
L7L3 (b)
L4L2m1:
m1:
m1:
H2 H3
L2 L3b
b b
b
H4
H1
R1 R2 R3L1
L4L5
L6 L7b b
b
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 50
H5
-
8/8/2019 P3_rsvp
51/86
When H2 wants to create a reservation
sen s a reservat on message , w car ter to R1 will forward the message to H1 ONLY, as it has forwarded
an identical re uest over R2 reviousl
After all receivers have sent RSVP reservation messages, an amountb of resources have been reserved over each of the seven links
inout
L1L2 L6
L6
L1(b)
inL5
L7L6
inout
L3L4 L7
L7L3 (b)
L4L2(b)
m1:
m1:
m1:
H2 H3
L2 L3b
b b
bb
H4
H1
R1 R2 R3L1
L4L5
L6 L7b b
b
b
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 51
H5
-
8/8/2019 P3_rsvp
52/86
What if multiple senders (e.g. H3, H4 and H5) send dataover the same link (e.g. link 6) simultaneously?
r rary n er eav ng o pac e s
L6 flow policed by leaky bucket: if H3+H4+H5 sending rateexceeds b acket loss will occur
inout
L1L2 L6
L6
L1(b)
inout
L3L4 L7
L7L3 (b)
L4L2(b)
m1: m1:
H2 H3
out L6 L7L5 (b)
b bb
m :
H4
H1
R1 R2 R3L1
L4
L5
L6 L7b
b
b
b
b
b
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 52
H5
-
8/8/2019 P3_rsvp
53/86
Consider the situation where each receiver requested 2bof bandwidth
wou e reserve on every n even t oug
those links directly from the hosts, i.e. L1, L2, L3, L4,
single source from the host
,sources from upstream; hence, they do not have the
information on the number of sources upstream
problem: over-reserving of resources on somenetwork links
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 53
-
8/8/2019 P3_rsvp
54/86
2. Reservation with ixed- ilterin or shared ex licit
filtering
H2H3
L2 L3
S1 S3S2L6 L7
H5 H4H1
L1 L5L4
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 54
-
8/8/2019 P3_rsvp
55/86
H2, H3, H4 and H5 are receivers and H1, H4 and H5 are
sources
With fixed/shared explicit filtering, each switch will keepa list of sources associated with their revious ho s
Assumed that S1, S2 and S3 have received path messages
from all sources but no reservations have yet been made
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 55
-
8/8/2019 P3_rsvp
56/86
S1s path state H2S1 S3S2
L1
L2
L6
L5
L7
L3
L4In L1, L6
H5 H4H1
Out L2(H1 via H1; H4 via S2; H5 via S2)
L6(H1 via H1)
s pa s a e
In L5, L6, L7
Out L5(H1 via S1; H4 via S3)
S3s ath state
L6(H4 via S3; H5 via H5)
L7(H1 via S1; H5 via H5)
In L4, L7Out L3(H1 via S2; H4 via H4; H5 via S2)
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 56
L7(H4 via H4)
-
8/8/2019 P3_rsvp
57/86
H2 wants to receive ackets from H4, i.e. fixed-filterin ,
and would like to reserve bandwidth of B
H2 sends a reservation message R2(B, H4) to S1
When S1 receives R2
Check that H4 is one of the source
ent y t at pac ets rom come rom
S1 reserves bandwidth B over L2
,
When S2 receives R2(B,H4)
S2 reserves B over L6 H3
S2 forwards the message toS3
2
S1 S3S2
L1
L2
L6
L5
L7
L4
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 57
H5 H4
-
8/8/2019 P3_rsvp
58/86
When S3 receives R2 B H4
S3 reserves B over L7
S3 forwards the message to H4
When R2 reaches H4, a pipe from H4 to H2 is reserved
H2H3
L2
L6 L7
L3
H1
S1 S3S2
L1 L5L4
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 58
H5 now sends a reservation message R5((H1,H4){2B})
-
8/8/2019 P3_rsvp
59/86
a shared-ex licit filterin
When S2 receives R5((H1,H4){2B})
H2H3
S1 S3S2
L2
L6 L7
L3
S2 reserves 2B over L5
S2 forwards R5 over L6 and L7H5 H4
H1L1
en rece ves ,
S1 finds that there is only one source going out L6; hence
only B is reserved over L6 S1 passes the R5 message to H1
When S3 receives R5 ((H1,H4){2B})
fixed-filter reservation has been established S3 does not reserve any more resources
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 59
S3 also does not forward the request to L4
-
8/8/2019 P3_rsvp
60/86
Dynamic Networks and Maintaining the
-
8/8/2019 P3_rsvp
61/86
Dynamic Networks and Maintaining the
eservat onProblems:
What if network topology changes?
How to cater for dynamic membership changes?
The reservation states RSVP builds at the routers areo s a e
The RSVP daemons at the source and receivers need to sendPath andResv messa es eriodicall to maintain the
reservation states If the state is not refreshed after certain timeout period, the
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 61
This mechanism prevents resources from being
-
8/8/2019 P3_rsvp
62/86
This mechanism prevents resources from being
orphaned when a receiver fails to send an explicit tear-down message or the underlying route changes
When a route or membership changes, the routing
protocol running underneath RSVP forwards future
new members
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 62
As IP is used to carry the RSVP messages occasional
-
8/8/2019 P3_rsvp
63/86
As IP is used to carry the RSVP messages, occasional
osses can e to erate at east one o t econsecutive messages get through (default:K=3)
(default:R=30) To avoid eriodic messa e s nchronisation, the actual
refresh period for each message is randomised in therange of [0.5R, 1.5R]
ac at an esv message carr es t e va ue o
Hence, a local node can determine its state lifetimeL, whichisL 1.5RK
Note: RSVP also has two teardown messages,PathTear andResvTear, to speed up state removals
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 63
Problems with RSVP
-
8/8/2019 P3_rsvp
64/86
Problems with RSVP
RSVP was perceived as a light-weighted
reser tion rotocol
However, the implementations are weighing in atbetween 10 000 and 30 000 lines of code
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 64
Features that contribute to its complexity:
-
8/8/2019 P3_rsvp
65/86
Features that contribute to its complexity:
Receiver orientation/diversity:
Individual receivers within a multicast group are allowed to
request different levels of service guarantees
Separation between reservation and path-finding messages
Implementation complexity:
As reservation requests are generated from downstream,
intensive
As RSVP is an out-of-band protocol, applications need to be
modified, either to take advantage of kernel-level support forRSVP or to convey their resource requirements to some
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 65
-
8/8/2019 P3_rsvp
66/86
YESSIR (YEt another Sender Session Interneteservat on
A proposal for resource reservation protocol serva ons:
Many multimedia applications that require guaranteed QoS
will use RTP The reservation protocol can hence make use of the
RTCP as in-band signaling for resource reservation
that is indicated by the sender instead of specifying adifferent bandwidth requirement
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 66
Design objectives
-
8/8/2019 P3_rsvp
67/86
Design objectives
Sender-initiated reservation
Many applications will not make full use of the benefits of
receiver-initiated reservations
Sender-initiated reservation fits better with policy and billing
or nstance, t e v eo-on- eman serv ce, t e cost o
resource reservation will probably be bundled with the cost
of content, simplifying billing It is easier for the relatively small number of large-scale
content providers to arrange for payment with the backbone
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 67
Robustness and soft-state
-
8/8/2019 P3_rsvp
68/86
m ar o , rou ers ma n a n reserva on s a es as so s a e
Rather than defining another signaling protocol, YESSIRmessa es are trans orted b RTCP
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 68
-
8/8/2019 P3_rsvp
69/86
For a particular flow, it is allowed to have reservation made on
some links while on some other links, the reservation request is
not successful
On link without reservation, traffic is carried out on a best-
downstream towards the receivers
As soft-state protocol is used, a flow can acquire a reservation
on a link when other flow terminates, without having to retry
at the application layer
,
successful reservation and hope that more links will be addedas the session continues
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 69
Provide different reservation styles
-
8/8/2019 P3_rsvp
70/86
y
SupportsIndividualand Sharedreservations Individual reservation
Use in situation where all senders are active simultaneously
E.g. distribution of participant video
Shared reservation
The allocated resources are used by all senders in a RTP
Use in situation where several senders alternate
E.g. audio conference
Note: YESSIR handles the shared reservation style from thesenders direction, while RSVP supports shared reservationfrom the receivers direction
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 70
Using of RTP in YESSIR
-
8/8/2019 P3_rsvp
71/86
Although RTP was not intended as a resource reservation protocol,resource reservation can benefit from the following RTP features:
In-band si nalin : RTCP has been defined for carr in controlmessages
Periodic sender/receiver notification:
ase on e en er epor s s an ece ver epor s(RRs), routers can deduce the resource requirements of asession
RTCP session control overhead is limited to no more than 5%of the data bandwidth
Embedded in a lication: As RTP is t icall im lemented as art
of the application, no modifications to the kernel, beyond thesupport of IP router alert options*, are needed* IP router alert option (RFC 2113) alerts transit routers to examine the contents of an IP packet closely.
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 71
YESSIR uses it to mark RTCP sender report for YESSIR processing
-
8/8/2019 P3_rsvp
72/86
-
8/8/2019 P3_rsvp
73/86
IP Header with Router-Alert Option
-
8/8/2019 P3_rsvp
74/86
UDP Header
RTCP message:
Sender Report:
- sender info.-
YESSIR message:
-
- reservation style- reservation flow spec.- link resource collection- reservation failure report
Profile-specific extensions
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 74
YESSIR Operation
-
8/8/2019 P3_rsvp
75/86
YESSIR inserts reservation info. into SR which sendersmulticast to all members of a multicast group periodically
When a router receives the SR, it will attempt to make a
resource reservation according to the info. specified
If the reservation cannot be granted
The SR packet will continue to be forwarded to the next hop
The router has the option of inserting the reservation failure info.
into the SR
, .
to the senders Based on the RRs received, senders can either drop the session or
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 75
lower the reservation request
If the reservation is successful
-
8/8/2019 P3_rsvp
76/86
The RTP data stream info. is added into the packet classifier ofthe router
e rou er s sc e u er s a so up a e o suppor e new s ream
Reservation states are maintained assoft-state .
received with several consecutive refresh intervals
RTP senders periodically generate RTCP SRs with IP router-alert option to refresh reservations
RTCP BYE message, sent when a sender leaves, releases the
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 76
Resource reservation
-
8/8/2019 P3_rsvp
77/86
In YESSIR, resources can be reserved based on flowspecor in measurement mode
Measurement mode
RTCP SRs contain a byte count and a timestamp
If the first RTCP packet for a session does not contain a
flowspec, the router simply records the timestamp and byte
count but does not make a reservation If a second packet for the same session comes along, the router
computes the difference in time stamps and byte counts and
computes an est mate rate
It establishes bandwidth reservation based on the estimated rate
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 77
Flow specification
-
8/8/2019 P3_rsvp
78/86
3 types have been considered: IntServ, RTP PT (payload-type),and TOS (type-of-service)
n erv:
Based on the specifications for controlled-load service anduaranteed service
The requested bandwidth, the burst size and the service class
need to be specified explicitly
RTP PT:
The payload type indicates the media encoding
,
with a fixed rate (e.g. 64kbps for G.711-encoded voice), therouter can hence make reservation based on this info.
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 78
TOS:
-
8/8/2019 P3_rsvp
79/86
routers can use the IP TOS value to map the data packets toappropriate scheduler queue
allocated bandwidth
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 79
-
8/8/2019 P3_rsvp
80/86
Shared
-
8/8/2019 P3_rsvp
81/86
All senders in a session share a single resource reservation in thenetwork
e amoun o resources reserve on a n s e eas upper
bound (LUB) of the individual flow requests
E. . if S1 and S2 re uest 10 kb s and 15 kb s res ectivel
the shared bandwidth to be reserved is 15 kbps
If there is a reservation failure, the reservation rejection info. and
e merge ow spec. w e p ggy ac e n e sen erreport
Receivers will feed back the failure reservation and re ected
reservation request to all participating members and the senders Senders can then adjust their requests
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 81
-
8/8/2019 P3_rsvp
82/86
Shared (contd)
-
8/8/2019 P3_rsvp
83/86
In YESSIR, besides using the LUB for flow merging, it alsoproposes a best-effort approach for flow merging
en ere s a rea y a reserva on n p ace, s reserva on
remains if a larger reservation request from another sender
cannot be granted
Example S3
Q3
RR to S3
S1
RRt3Rt2Rt1
Q1
Q'' Q''
S2 Q2
Q' Q'Q'
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 83
= ,Q'' = LUB (Q', Q3)
Example (contd)
-
8/8/2019 P3_rsvp
84/86
an are t e n t a sen ers o a s are -reservat onRTP session
The merged flowspec Q = LUB(Q1, Q2)
A new sender S3 joins in and requests Q3 worth of
resources
Q=LUB(Q, Q3)
The reservation is successful at Rt2 and the request Q is
orwar e to t
If Rt3 cannot reserve Q, it should continue to use theprevious reservation Q
Sender S3 will be informed about the last workablereservation Q from receiver R via RTCP
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 84
whether it can lower its sending rate
Dynamic Reservation
-
8/8/2019 P3_rsvp
85/86
YESSIR supports the reserve-when-needed mode
An RTP session ma not re uire a reservation for its
whole session and the application may decide to reserve
network resources only if best effort service is
unsatisfactory
As RTCP will keep monitoring the traffic statistics, senders can
when a sufficiently large fraction of the receivers indicate
reception problems
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 85
Network Resource Advertising
-
8/8/2019 P3_rsvp
86/86
The YESSIR reservation message carries a networkmonitoring fragment
Consists of hop counts, propagation delay, aggregated bandwidth
and delay bounds
s SR messages traverse routers, t s ragment s up ate
at every hop
e rece ver w co ec e pa resource n orma on ansend it back to the senders using the receiver report
sending new requests
Ver 2.3 E6703 Multimedia Networking Resource Reservation/Page 86