P3_rsvp

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.


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.


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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


need to be displayed

8/8/2019 P3_rsvp

32/86

Exam le:

( S1 ) ( R1 )(a) (c)

Router

( S2, S3 )( R2 )(b) (d)


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


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


8/8/2019 P3_rsvp

35/86

Exam le contd Fixed-Filter (FF) style


(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}


8/8/2019 P3_rsvp

36/86

Exam le contd Shared-Explicit (SE) style


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)


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 )


Router Configuration

8/8/2019 P3_rsvp

38/86

Exam le contd Wildcard-Filter (WF) style


WF( *{4B} )(a) (c)*{4B}

WF( *{4B} )

WF( *{3B} )WF( *{3B} )WF( *{2B} )* 3B


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


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


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


8/8/2019 P3_rsvp

42/86

Example

S1 S4

H4

H2

S3

H3


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


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


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


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


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


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


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


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


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


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


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


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


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)


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


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


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


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


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.


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


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


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'


= ,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


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


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


P3_rsvp

Documents

Transcript of P3_rsvp