Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
Computer Science Technical Report Archive
/
USC Computer Science Technical Reports, no. 606 (1995)
(USC DC Other)
USC Computer Science Technical Reports, no. 606 (1995)
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
RSVP A New Resource ReSerV ation Proto col
Lixia Zhang
Stev e Deering
Deb orah Estrin
Scott Shenk er
Daniel Zappala
flixia deering shenk ergparcxero xcom festrin zappala guscedu
A CCEPTED BY IEEE NETW ORK MA GAZINE
XeroxP AR C Co y ote Hill Road P alo Alto CA Information Sciences Institute and Computer Science Departmen t Univ ersit y of Southern California
Computer Science Departmen t Univ ersit y of Southern California Los Angeles CA
In tro duction
The currentIn ternet arc hitecture as em b o died in the IP net w ork proto col oers a v ery simple
service mo del p oin ttop oin t b esteort service In recen ty ears sev eral new classes of distributed
applications ha v e b een dev elop ed suc h as remote video m ultimedia conferencing data fusion
visualization and virtual realit y It is b ecoming increasingly clear that the In ternets primitiv e
service mo del is inadequate for these new applications this inadequacy stems from the failure of
the p oin ttop oin t b esteort service mo del to address t w o application requiremen ts First man yof
these applications are v ery sensitiv e to the qualit y of service their pac k ets receiv e F or a net w ork to
deliv er the appropriate qualit y of service it m ust go b ey ond the b esteort service mo del and allo w
o ws whic h is the generic term w e will use to iden tify data trac streams in the net w ork to reserv e
net w ork resources Second these new applications are not solely p oin ttop oin t with a single sender
and a single receiv er of data instead these applications can often b e m ultip oin ttom ultip ointwith
sev eral senders and sev eral receiv ers of data Multip oin ttom ultip ointcomm unication o ccurs
for example in m ultipart y conferencing where eac h participan t is b oth a sender and a receiv er of
data and also in remote learning applications although in this case there are t ypically manymore
receiv ers than senders
In recenty ears there has b een a urry of researc hactivitydev oted to the dev elopmen t of new
net w ork arc hitectures and service mo dels to accommo date these new application requiremen ts
Ev en though there are rather fundamen tal dierences b et w een the v arious prop osed arc hitectures
there is widespread agreemen t that an y new arc hitecture capable of accommo dating m ulticast and
av ariet y of qualities of service can b e divided in to v e distinct comp onen ts whic hw e iden tify and
describ e b elo w
Flo w Sp ecication The net w ork and the v arious data o ws need a common language so that a
source can tell the net w ork ab out the trac c haracteristics of its o w and the net w ork can in
turn sp ecify the qualit y of service to b e deliv ered to that o w Th us the rst comp onen tof
this new arc hitecture is a o w sp ecication or owsp e c whic h describ es the c haracteristics of
b oth the trac stream sen tb y the source and also the service requiremen ts of the application
In some sense the o wsp ec is the cen tral comp onen t of the arc hitecture since it em b o dies the
service in terface that applications will in teract with the details of all of the other comp onen ts
of the arc hitecture are hidden from applications Tw o prop osals for a o wsp ec are describ ed
in References Routing The net w ork m ust decide ho w to transp ort pac k ets from the source to the receiv er or in
the case of m ulticast receiv ers of the o w Th us the second comp onen t of the arc hitecture
is a routing proto col that can pro vide qualit y unicast and m ulticast paths There are man y
approac hes to unicast routing References describ e dieren t approachestom ulticast
routing None of the curren t prop osals ha vey et dealt sucien tly with the in teraction b et w een
routing and qualit y of service constrain ts that is the sub ject of future researc h
Resource Reserv ation In order for the net w ork to deliv er to a particular o w a quan titativ ely
sp ecied qualit y of service lik e a b ound on dela y it is usually necessary for the net w ork to
set aside certain resources suc h as a share of bandwidth or a n um b er of buers for that o w
This abilityto create andmain tain resource reserv ations on eac h link along the transp ort
path is the third comp onen t of the arc hitecture References describ e t w o approac hes
to resource reserv ation in this article w e describ e another
Admission Con trol Because a net w orks resources are nite it cannot gran t all resource reser
v ation requests In order to main tain the net w ork load at a lev el where all qualit y of service
commitmen ts can b e met the net w ork arc hitecture m ust con tain an admission con trol algo
rithm this algorithm determines whic h reserv ation requests to gran t and whic h to den yand
thereb y main tains the net w ork load at an appropriate lev el References and describ e
t w o admission con trol algorithms
P ac k et Sc heduling After ev ery pac k et transmission a net w ork switchm ust decide whether and
whichpac k et to transmit next It is the pac k et sc heduling algorithm whichcon trols this
decision The pac k et sc heduling algorithm lies at the heart of an y net w ork arc hitecture
b ecause it determines whic h qualities of service the net w ork to can pro vide There are man y
prop osed pac k et sc heduling algorithms see References for a few examples
In this article wepresen t our prop osal for the third comp onen t of the arc hitecture a new resource
ReSerV ation Proto col RSVP Similar to previous w ork on resource reserv ation proto cols eg ST
I I RSVP is a simplex proto col ie it reserv es resources in one direction Ho w ev er sev eral
no v el features in the RSVP design lead to the unique exibilit y and scalabilit y of the proto col
RSVP is receiv erorien ted in that the receiv er of the data o w is resp onsible for the initiation
of the resource reserv ation This design decision enables RSVP to accommo date heterogeneous
receiv ers in a m ulticast group sp ecically eac h receiv er ma y reserv e a dieren t amoun t of resources
ma y receiv e dieren t data streams sen t to the same m ulticast group and ma y switc hc hannels
from time to time that is c hange whic h data streams it wishes to receiv e without c hanging its
reserv ation RSVP also pro vides sev eral reserv ation st yles that allo w applications to sp ecify ho w
reserv ations for the same m ulticast group should b e aggregated at the in termediate switc hes this
feature results in more ecien t utilization of net w ork resources Finallyb y using softstate in
the switc hes RSVP supp orts dynamic mem b ership c hanges and automatically adapts to routing
c hanges These features enable RSVP to deal gracefully and ecien tly with large m ulticast groups
While the motiv ation for RSVP arose within the In ternet con text our design is in tended to b e fully
general
This article has sections W e rst list our design goals Section and then discuss the basic design
principles used to meet these goals Section Section con tains a more detailed description of
the proto col op eration and Section describ es ho w the proto col w ould w ork in a simple example
Section describ es the curren t state of our RSVP implemen tation Wedela y consideration of
related w ork un til Section and follo w that with a discussion of unresolv ed issues in Section Finally in Section w e conclude with a brief summary RSVP Design Goals
In the traditional p oin ttop oin t case one ob vious reserv ation paradigm w ould ha v e the sender
transmit a reserv ation request to w ards the receiv er with the switc hes along the path either admit
ting or rejecting the o w F or the p oin ttom ultip oin t case one ma y trivially extend this paradigm
to ha v e the sender transmit the reserv ation request along a m ulticast routing tree to eac h of the
receiv ers When w eha vem ultip oin ttom ultip oin t data transmissions the straigh tforw ard exten
sion of this paradigm w ould b e to ha veeac h sender transmit a reserv ation request along its o wn
m ulticast tree to eac h receiv er Ho w ev er the sp ecial prop erties of ha ving m ultiple heterogeneous
receiv ers andor m ultiple senders p ose serious c hallenges that are not addressed b y this simple
extension of the basic reserv ation paradigm W e outline these v arious c hallenges b elo w and detail
ho w these c hallenges are not met b y the stra wman prop osal of straigh tforw ardly extending the
basic paradigm In the pro cess w e iden tify the sev en goals whic h guided the design of RSVP In a wide area in ternet w ork suchasthe In ternet receiv ers as w ell as the paths used to reac h the
receiv ers can ha vev ery dieren t prop erties from one another In particular one m ust not assume
that all the receiv ers of a m ulticast group p ossess the same capacit y for pro cessing incoming data
nor ev en necessarily desire or require the same qualit y of service from the net w ork F or instance
a source ma y b e sending a la y ered enco ding of a video signal it is p ossible that certain receiv ers
whic h are doing the deco ding in soft w are w ould only ha v e sucien t pro cessing p o w er to deco de
the lo wresolution signal while those receiv ers with hardw are deco ding or more pro cessing p o w er
could deco de the en tire signal F urthermore the paths used to reac h all the receiv ers ma y not
ha v e the same capacit y in the la y ered enco ding example ab o v e certain receiv ers migh t only ha v e
lo wbandwidth paths b et w een them and the source and so could only receiv e the lo wresolution
signal The stra wman prop osal ab o v e is incapable of dealing with the receiv ers individuall y and so
cannot address these heterogeneous needs Therefore our rst design goal for RSVP is to pro vide
the abilit y for heterogeneous receiv ers to makereserv ations sp ecically tailored to their o wn needs
The presence of m ultiple receiv ers raises another issue the mem b ership in a m ulticast group can
b e dynamic The stra wman prop osal w ould ha v e to reinitiate the reserv ation proto col ev ery time a
new mem b er joined or an existing mem b er left the m ulticast group Reinitiation of the reserv ation
proto col is particularly burdensome for large groups b ecause the larger the group size the more
frequen t are c hanges in group mem b ership So our second design goal for RSVP is to deal gracefully
with c hanges in the m ulticast group mem b ership
The stra wman prop osal deals with m ultiple senders byha ving eac h sender mak e an indep enden t
resource reserv ation along its o wn m ulticast routing tree This approac h results in resources b eing
reserv ed along m ultiple indep enden t trees ev en though the branc hes of dieren t trees often share
common links This ma y b e appropriate for some applications but in other cases this duplication
can lead to a signican tw asting of resources F or example in an audio conference with sev eral
p eople there is usually only one p erson or at most a few p eople talking at an y one time b ecause
of the normal dynamics of h uman con v ersation Th us instead of reserving enough bandwidth for
ev ery p oten tial sp eak er to sp eak sim ultaneouslyin man y circumstances it w ould b e adequate to
reserv e only enough net w ork resources to handle a few sim ultaneous audio c hannels Our third
design goal is for RSVP to allo w end users to sp ecify their application needs so that the aggregate
resources reserv ed for a m ulticast group can more accurately reect the resources actually needed
b y that group
F urthermore in a m ultipart y conference a receiv er ma y only wish to or ma y only b e able to w atc h
one or a few other participan ts at a time but w ould lik e the p ossibilit y of switc hing among v arious
participan ts The simple approac hof deliv ering the data streams from all the sources and then
dropping the undesired ones at the receiv er do es not address net w ork resource usage considerations
eg ecien t use of limited bandwidth or reducing the c harges incurred for bandwidth usage A
receiv er should b e able to con trol whichpac k ets are carried on its reserv ed resources not only what
gets displa y ed on its lo cal screen Moreo v er a receiv er should b e able to switc h among sources
without the risk of ha ving the c hange request denied as could o ccur if a new reserv ation request
had to b e submitted in order to switc hc hannels Our fourth design goal for RSVP is to enable
this c hannel c hanging feature
RSVP is not a routing proto col and should a v oid replicating an y routing functions RSVPs task
is to establish and main tain resource reserv ations o v er a path or a distribution tree indep enden t
of ho w the path or tree w as created In a large in ternet w ork with a v olatile top ology and load
these routes mayc hange from time to time Adapting to suc hc hanges in top ology and load is the
explicit job of the routing proto col and it w ould b e exp ensiv e and complicating to replicate the
function in RSVPA t the same time ho w ev er RSVP should b e able to cop e with the resulting
routing c hanges Our fth design goal is that RSVP should deal gracefully with suc hc hanges
in routes automatically reestablishing the resource reserv ations along the new paths as long as
adequate resources are a v ailable
The stra wman prop osal do es not deal gracefully with c hanges in routes b ecause there is no mec h
anism to disco v er the c hange and trigger a new resource reserv ation request One could in tro duce
suc h a mec hanism byha ving eac h source p erio dicall y r efr esh its reserv ation o v er the m ulticast rout
ing tree Ho w ev er in large m ulticast groups suc h refreshing w ould lead to S messages arriving at
ev ery receiv er during ev ery refresh p erio d where S is the n um b er of sources Our sixth design goal
is to con trol proto col o v erhead b y this wemeanboth a v oiding the explosion in proto col o v erhead
when group size gets large and also incorp orating tunable parameters so that that the amoun tof
proto col o v erhead can b e adjusted
Our last design goal is not sp ecic to the problem at hand but rather is a general matter of
mo dular design w e hop e to mak e the general design of RSVP relativ ely indep enden t of the other
arc hitectural comp onen ts listed in Section Clearly a particular implemen tation of RSVP will
b e tied quite closely to the o wsp ec and in terfaces used b y the routing and admission con trol
algorithms Ho w ev er the general proto col design should b e indep enden t of these In particular
our proto col should b e capable of establishing reserv ations across net w orks that implemen t dieren t
routing algorithms suc h as IP unicast routing IP m ulticast routing the recen tly prop osed CBT
CoreBased T ree m ulticast routing or some future routing proto cols This design goal mak es
RSVP deplo y able in manycon texts Ho w ev er for optimally ecien t routing decisions routing
selection and resource reserv ation should b e in tegrated so that the c hoice of route can dep end on
the qualit y of service requested and so that the stabilit y of the route can b e main tained o v er the
duration of the reserv ation Suchan in tegration w ould lead to more co ordination b et w een the
c hoice of whic h resources to reserv e and the mec hanics of establishing the reserv ation whic his
RSVPs main fo cus This in tegration is something that requires further researc h
Th us in summary w eha v e iden tied sev en imp ortan t design goals whic hw e list in Figure RSVP
is primarily a v ehicle used b y applications to comm unicate their requiremen ts to the net w ork in a
robust and ecien tw a y indep enden t of what the sp ecic requiremen ts are RSVP deliv ers resource
reserv ation requests to the relev an t switc hes but pla ys no other role in pro viding net w ork services
Th us RSVP can comm unicate the requiremen ts for but do es not directly pro vide for a wide
range of net w ork services F or instance the sync hronization requiremen ts of o ws or the need for
reliable m ulticast deliv ery could b e expressed in the o wsp ec that is distributed b y RSVP and then
realized b y the switc hes Similarly the o wsp ec could also carry around information ab out adv ance
reserv ations reserv ations made for a future time and preemptable reserv ations reserv ations that
a receiv er is willing to ha v e preempted RSVP is capable for supp orting the deliv ery of these
and other services whenev er these net w ork services rely only on state b eing established at the
individual switc hes along the paths determined b y the routing algorithm Th us while w eha v e
describ ed RSVP as a resource reserv ation proto col it can b e seen more generally as a switch state
establishment proto col
Basic Design Principles
Toac hiev e the sev en design goals listed in Figure w e used six basic design principles whichw e
no w describ e These design principles are listed in Figure Receiv erIniti ated Reserv ation
The stra wman prop osal discussed in the previous section and all existing resource reserv ation
proto cols are designed around the principle that the data source initiates the reserv ation request
In con trast RSVP adopts a no v el r e c eiverinitiate d design principle receiv ers c ho ose the lev el of
resources reserv ed and are resp onsible for initiating and k eeping the reserv ation activ e as long as
they w anttoreceiv e the data W e describ e the motiv ation for this receiv erinitiated approac h
b elo w
A source can alw a ys transmit data whether or not adequate resources exist in the net w ork to deliv er
the data It is the receiv er who kno ws its o wn capacit y limitations furthermore the receiv er is
the only one who exp eriences and th us who is directly concerned with the qualit y of service
exp erienced b y the incoming pac k ets Additionallyif net w ork c harging is deplo y ed in the future
the receiv er w ould lik ely b e the partypa ying for the requested qualit y of service Th us it should
b e the receiv er who decides what resources should b e reserv ed
One could imagine ha ving the receiv ers send this information to the source and then ha ving the
source use this information in sending out the reserv ation request T o handle heterogeneous re
quests ho w ev er this approac hw ould require that the sender bundle all requests together to pass
to the net w ork so that the net w ork can gure out according to the lo cation of individual receiv ers
howm uc h resource needs to b e reserv ed on whichlinks F or large m ulticast groups this will lik ely
cause a m ulticast implosion at the sender This implosion problem b ecomes more serious when
the m ulticast group mem b ership c hanges dynamically and the reserv ation has to b e p erio dically
renew ed Consider as an extreme example a cable TV rm with broadcasting sev eral c hannels
of programs while there are relativ ely few sources there are p erhaps h undreds of thousands of
receiv ers eac h of whichcan w atc h only one or a few c hannels at a time In the stra wman pro
p osal whenev er an y individual receiv er w an ts to switchbet w een c hannels it sends a message to
the source In this case where there are man y receiv ers and frequen t switc hing b et w een c hannels
eac h source has to accommo date an deluge of c hange requests Ho w ev er this o v erhead is clearly
sup eruous since w e exp ect the resulting broadcast pattern to c hange relativ ely slo wly b ecause
the resulting m ulticast trees will lik ely b e relativ ely stable except near the leaf no des In Section w e showho w our receiv erinitiated design accommo dates heterogeneit y among group mem bers y et
a v oids suchm ulticast implosion
The idea of the receiv erinitiated approac hw as rst inspired b y Deerings w ork onIPm ulticast
routing The IP m ulticast routing proto col treats senders and receiv ers separately A sender
sends to a m ulticast group in exactly the same w a y as it sends to a single receiv er it merely puts in
eac h pac k et a m ulticast group address in place of a host address The m ulticast group mem b ership
is dened as the group of receiv ers Deerings m ulticast routing design can b e considered a receiv er
initiated approac h in the sense that eac h receiv er individuall y decides to join or lea v e the group
without aecting other receiv ers in the group or aecting sources that send to the group It is
the routing proto col that tak es the resp onsibilit y of forw arding all m ulticast data pac k ets to all the
curren t mem b ers in the group Analogous to our argumen t that a sender do es not care whether
adequate resources are a v ailable a sender to a m ulticast group do es not necessarily kno w who is
curren tly a mem b er of the m ulticast group ie receiving the data in particular it ma y not b e a
mem b er of the m ulticast group itself
Separating Reserv ation from P ac k et Filtering
A resource reserv ation at a switc h assigns certain resources buers bandwidth etc to the en tit y
making the reserv ation A distinction that is rarely made whic h will b e crucial to our abilityto
meet our design goals is that the resource reserv ation do es not determine whichpac k ets can use
the resources but merely sp ecies what amount of resources is reserv ed for whom Notice that
the whom refers not to whichpac k ets can use the reserv ed resources but rather sp ecies whic h
en tit y c ontr ols the resources There is a separate function called a pac k et lter whic h selects those
pac k ets that can use the resources this lter is set b y the reserving en tit y Moreo v er the lter can
be c hanged without c hanging the amountof reserv ed resources Th us one of the imp ortan t design
principles in RSVP is that weallo w this lter to b e dynamic that is the receiv er can c hange it
during the course of the reserv ation This distinction b et w een the reserv ation and the lter will
enable us to oer sev eral dieren t reserv ation st yles whic hweno w describ e
Pro viding Dieren t Reserv ation St yles
As w e discussed briey in Section ab o v e the service requiremen ts of m ulticast applications dictate
ho w the reserv ation requests from individual receiv ers should b e aggregated inside the net w ork F or
example as w e discussed in Section the t ypical dynamics of h uman v erbal in teraction results in
only one or a few p eople talking at an y one time th us in man y conferencing situations it w ould b e
feasible to ha v e all senders of audio signals to a conference share the same set of reserv ed resources
where these resources w ere sucien t for a small n um b er of sim ultaneous audio streams In con trast
there are no analogous limitations on video signals Therefore if the conferencing application also
includes video then enough resources m ust b e reserv ed for the n um b er of video streams one desires
to w atchsim ultaneously As in the usual m ulticast paradigm if t w o receiv ers do wnstream of a
particular link are w atc hing the same video stream for the lifetime of the application eg when
attending a remote lecture only a single reserv ation need b e made on this link to accommo date
their needs Ho w ev er if these t w o receiv ers wish to o ccasionally switc h among the senders during
the application lifetime eg when participating in a distributed group meeting then separate
reserv ations mustbemain tained T o supp ort dieren t needs of v arious applications while making
the most ecien t use of net w ork resources RSVP denes dieren t r eservation styles whic h indicate
howin termediate switc hes should aggregate reserv ation requests from receiv ers in the same m ulti
cast group Curren tly there are three reserv ation st yles nolter xe dlter and dynamiclter Weno w describ e these lter st yles for the sak e of brevityw e will iden tify applications only b y
their m ulticast address although in the curren tIn ternet con text a m ulticast application maybe
iden tied b y the IP m ulticast address plus destination p ort n um ber When a receiv er mak es a resource reserv ation for a m ulticast application it can sp ecify whether
or not a data source lter is to b e used If there is no lter then an y pac k ets destined for that
m ulticast group ma y use the reserv ed resources although some enforcemen tmec hanism is needed
to mak e sure that the aggregate stream do es not use more than the reserv ed amoun t w e will not
discuss enforcemen t mec hanisms here F or example the audio conference describ ed ab o vew ould
use a nolter reserv ation so that a single reserv ed pip e can b e used b y whomev er is sp eaking
at the momen t If source ltering is needed the lter is sp ecied b y a list of sources again
in the In ternet con text a data source can b e sp ecied b y the source host address plus source p ort
n um b er but w e will only refer to the source host address in this exp osition Only the pac k ets from
the sp ecied sources can use the reserv ed resources Filtered reserv ations will b e used to forw ard
individual images in video conferencing enabling participan ts to reserv e resources for particular
video streams
A ltered reserv ation can b e either xed or dynamic A xe dlter reserv ation means that for the
duration of the reserv ation the receiv er will receiv e data only from the sources listed in the original
reserv ation request A dynamiclter reserv ation allo ws a receiv er to c hange its lter to dieren t
sources o v er time
In order to illustrate howin termediate no des use these reserv ation st yles to aggregate reserv ation
requests consider the case where sev eral receiv ers in the same m ulticast group mak e xe dlter
reserv ations o v er a common link These reserv ations ma y b e shared if the source lists o v erlap
b ecause the reserv ation will nev er b e c hanged Th us only a single pip e with the largest amoun t
of resources from all the requests will b e reserv ed for eachsourceev en when there are m ultiple
requests Suc h aggregation can o ccur when mem bers of a m ulticast application all listen or w atc h
the same audio or video signals as in the case of a m ulticast lecture Reserv ations using the nolter
st yle can also b e aggregated in this manner b ecause if a receiv er do es not discriminate b et w een
individual sources it cannot switc h among the sources either
If a receiv er exp ects to switc h among dieren t sources from time to time it m ust makea dynamic
lter reservationtoa v oid aecting the reception of other receiv ers in the same m ulticast application
Because the receiv er can c hange the list of sources in the lter at an y time during the course of
the reserv ation the in termediate no des cannot aggregate reserv ations of this st yle In fact this
separation b et w een the resource reserv ation and the lter is one of the k ey facets of RSVP the
resource reserv ation con trols howm uc h bandwidth is reserv ed while the lter con trols whichpac k ets
can utilize that bandwidth In the dynamiclter reserv ation case eac h receiv er requests enough
bandwidth for the maxim um n um b er of incoming streams it can handle at once and the net w ork
m ust reserv e enough resources to handle the w orst case when all the receiv ers that requested
dynamic lter reserv ations tak e input from dieren t sources ev en though sev eral receiv ers ma y
actually tune to the same sources from time to time Ho w ev er note that the total amoun tof
dynamic lter reserv ations made o v er an y link should b e limited to the amoun t of bandwidth needed
to forw ard data from all the upstream sources
In summaryha ving sev eral dieren t reserv ation st yles allo ws in termediate switc hes to decide ho w
individual reserv ation requests for the same m ulticast group can b e ecien tly merged The dynamic
lter reserv ation st yle allo ws receiv ers to c hange c hannels Th us w eha v e met design goals and So far RSVP has dened three reserv ation st yles other st yles ma y b e iden tied as new m ulticast
applications with dieren t needs are dev elop ed
Main taining SoftState in the Net w ork
The t ypical m ultip oin ttom ultip oin t applications weha v e considered are rather longliv ed Ov er
the lifetime of suc h an application it is quite p ossible that new mem b ers ma y join and existing
mem b ers maylea v e and routes ma yalso c hange due to dynamic status c hanges at in termediate
switc hes and links T o b e able to adjust resource reserv ations accordinglyand in a w a y transparen t
to end applications RSVP k eeps softstate at in termediate switc hes and lea v es the resp onsibilityof
main taining the reserv ation to end users The term softstate w as rst used b y Clark in and in
our con text refers to state main tained at net w ork switc hes whic h when lost will b e automatically
reinstated b y RSVP so on thereafter Th us softstate is appropriate in our con text where frequen t
routing c hanges and o ccasional service outages w ould render a more brittle ie less selfstabilizin g
state to b ecome and p erhaps remain obsolete or incorrect
More sp ecically RSVP distinguishes t w o kinds of state information at eachin termediate switc h
p ath state and r eservation state Eac h data source p erio dically sends a Path message that estab
lishes or up dates the path state and eac hreceiv er p erio dically sends a R eservation message that
establishes or up dates the reserv ation state whic hisattac hed to the path state
P ath messages are forw arded using the switc hes existing routing table in other w ords the routing
decision is made b y the net w orks routing proto col not b yRSVPEac h path message carries a
o wsp ec giv en b y the data source as w ell as an Fag indicating if the application wishes to
allo w ltered reserv ations In pro cessing eac h path message the switc h up dates its path state that
con tains information ab out the incoming link upstream to the source and the outgoing links
do wnstream from that source to the receiv ers in the group as indicated b y the m ulticast routing
table In addition if the Fag in the path message is on the switc halso k eeps the information
ab out the source and the previous hop upstream to reac h the source this information allo ws the
switc h to accommo date anyst yle of reserv ation If the Fag is o the switc h will not main tain an y
information ab out the sp ecic source of the path message except adding its incoming link to the
path state th us minimizing the state that m ust b e k ept at the switc h Consequen tly only nolter
st yle reserv ations can b e made for data streams from suc h sources As w e will sho w later in an
example not main taining p er source information can in some top ologies result in o v erreserving
resources o v er certain links
Eac h reserv ation message carries a o wsp ec a reserv ation st yle and a pac k et lter if the reserv ation
uses a ltered st yle either xed or dynamic In pro cessing eac h reserv ation message the switc h
up dates its reserv ation state that con tains information for the outgoing link the message came from
b y recording the amoun t of resources reserv ed the source lter for the reserv ed resource the reserv ation st yle and if the st yle is dynamiclter the reserv er the sender of this reserv ation
message whic h is one of the receiv ers of this m ulticast group W e see that the only time w e need
to k eep p er receiv er information in the reserv ation table is when the reserv ations in v olv e dynamic
lters when all reserv ations are either nolter or xedlter w e can assign the reserv ation to
the m ulticast group as a whole and then only k eep trac k of the total resources reserv ed on eac h
do wnstream link
Reserv ation messages are forw arded backto w ards the sources b y rev ersing the paths of path mes
sages In fact the path information is main tained solely to do this rev erse path forw arding of the
reserv ation messages More sp ecically reserv ation messages of the nolter st yle are forw arded to
all incoming links to the m ulticast group and those of ltered st yles are forw arded to the previous
hops of the sources that are listed in the lters
Both path messages and reserv ation messages carry a timeout v alue that is used byin termediate
switc hes to set corresp onding timers the timers get reset whenev er new messages are receiv ed
Whenev er a timer expires the corresp onding state will b e deleted This timeoutdriv en deletion
prev en ts resources from b eing orphaned when a receiv er fails to send an explicit teardo wn message
or the underlying route c hanges It is also the only w a y to release the resources of nolter or
xedlter reserv ations in these cases the switc h cannot determine if the reserv ation is b eing
shared bym ultiple receiv ers and so can only delete the reserv ation when it times out It is the
resp onsibilit y of b oth senders and receiv ers to main tain the prop er reserv ation state inside the
net w ork b y p erio dically refreshing the path and reserv ation state
When a route or mem b ership c hanges the routing proto col running underneath RSVP will forw ard
future path messages along the new routes and reac hnew mem b ers As a result the path state
at switc hes will b e up dated causing future reserv ation messages to tra v erse the new routes or new
route segmen ts Reserv ations along old routes or along routes to inactiv e senders or receiv ers will
time out automatically Because path and reserv ation messages are sen t p erio dically the proto col
will tolerate o ccasional corruption or loss of a few messages This softstate approac h adds b oth
adaptivit y and robustness to RSVP The adv an tages of the softstate approac h ho w ev er do not come for free the p erio dic refreshing
messages add o v erhead to the proto col op eration W e next discuss ho w RSVP con trols proto col
o v erhead
Proto col Ov erhead Con trol
The RSVP o v erhead is determined b y three factors the n um b er of RSVP messages sen t the size
of these RSVP messages and the refresh frequencies of b oth path and reserv ation messages As w e
describ e in more detail in Section RSVP merges path and reserv ation messages as they tra v erse
the net w ork The merging of path messages means that in general eac h link carries no more than
a single path message in eac h direction during eac h path refresh p erio d Similarly the merging
of reserv ation messages means that eac h link carries no more than a single reserv ation message in
eac h direction during eac h reserv ation refresh p erio d The maxim um size of b oth the path and
reserv ation messages on a particular link is prop ortional to the n um b er of data sources upstream
RSVP con trols the third o v erhead factor the refresh frequencies b y tuning the timeout v alues
carried in path and reserv ation messages The larger the timeout v alue the less frequen t the refresh
messages ha veto be sen t There exists ho w ev er a tradeo b et w een the o v erhead one is willing
to tolerate and RSVPs resp onsiv eness in adapting to dynamic c hanges F or instance reserv ation
messages are forw arded according to the path state main tained at in termediate switc hes whic h
in turn gets sync hronized with the routing proto col state ev ery time a path message is pro cessed
When a route c hanges reserv ations along the new route or new route segmen ts will not b e
established un til a new path message has b een sen t causing the path state to b e up dated and a
new reserv ation message has b een sen t along the new route
Our curren t RSVP implemen tation uses static timer v alues whic h are c hosen on the basis of engi
neering judgmen t in the future w e will in v estigate adaptiv e timeout algorithms to optimally adjust
the timer v alues according to observ ed dynamics in route and mem b ership c hanges as w ell as the
loss probabilit y of RSVP messages
Mo dularit y
In the con text of a realtime m ulticast application RSVP in terfaces to three other comp onen ts in
the arc hitecture the o wsp ec whic hishandedto RSVPb y an application or some session
con trol proto col on b ehalf of the application when in v oking RSVP the net w ork routing proto col
whic h forw ards path messages to w ards all the receiv ers causing RSVP path state to b e established
at in termediate switc h no des and the net w ork admission con trol whic hmak es an acceptance
decision based on the o wsp ec carried in the reserv ation messages
W e list mo dularit y as one of RSVPs design goals b ecause w ew ould lik e to mak e RSVP as indep en
den t from the other comp onen ts as p ossible W eha v e attempted to mak e few assumptions ab out
these other comp onen ts and those assumptions that w eha v e made are describ ed explicitly Wemak e no assumptions ab out the o wsp ec to b e carried b y RSVP RSVP treats the o wsp ec as
an um b er of unin terpreted b ytes of data that need to b e exc hanged among only the applications
and the net w ork admission con trol algorithm W e assume that the admission con trol algorithm
op erates byha ving an RSVP reserv ation pac k et con taining a o wsp ec pass through the switc hes
along the deliv ery path for that o w but ob viously in the rev erse direction with eac hswitc h
returning an admit or r eje ct signal the resource reserv ation is established only if all switc hes along
the path admit the o w W e also assume that the pac k et sc heduling algorithm can c hange pac k et
lters without needing to establish a new reserv ation
The only assumptions that w e mak e ab out the underlying routing proto cols are that it pro vides
b oth unicast and m ulticast routing and that a sender to a m ulticast group can reac h all group
mem b ers under normal net w ork conditions ob viously in the case of a net w ork partition no routing
proto col can guaran tee this reac habilit yW e do not assume that a sender to a m ulticast group is
necessarily a mem b er of the group nor do w e assume that the route from a sender to a receiv er is
the same as the route from the receiv er to the sender
RSVP Op eration Ov erview
RSVP and indeed an y reserv ation proto col is a v ehicle for establishing and main taining state in
switc hes along the paths that eacho ws data pac k ets will tra v el Because reserv ation messages
are initiated b y eac h receiv er RSVP m ust mak e sure that the reserv ation messages from a receiv er
follo w exactly the rev erse routes of the data streams from all the sources that the receiv er is
in terested in In other w ords RSVP m ust establish a sink tr e e from eachreceiv er to all the sources
to forw ard reserv ation messages
The sink tree for eac h receiv er is formed b y tracing in the rev erse direction the paths as dened b y
the m ulticast routing proto col from the receiv er to eac h of the sources see Figure P erio dic path
messages are forw arded along the routing trees pro vided b y the routing proto col and reserv ation
refresh messages are forw arded along the sink trees to main tain curren t reserv ation state Ho w ev er
a reserv ation message propagates only as far as the closest p oin t on the sink tree where a reserv ation
lev el greater than or equal to the reserv ation lev el b eing requested has already b een made
Eac h switc h uses the path states to main tain for eac hm ulticast group a table of incoming and
outgoing in terfaces Eac h incoming in terface k eeps the information ab out the o wsp ecs it has
forw arded upstream whic h is needed in merging reserv ation requests from m ultiple do wnstream
links F or eac h outgoing link there is a list of senders asso ciated with eac h sender in this list is
the previous hop address from whic h data from that sender arriv es at the currentswitc h There is
also a set of reserv ations Generally sp eaking eac h reserv ation consists of a reserv er a lter and
the amoun t of resources reserv ed F or nolter reserv ations the rst t w o elds are not needed and
for xedlter reserv ations the rst eld is not needed
Weno w review the pro cess of creating and main taining reserv ations in more detail Before or when
eac h data source starts transmitting it sends a path message whic hcon tains the o wsp ec pro vided
b y the data source When a switc h receiv es a path message it rst c hec ks to see if it already has
the path state for the named target whic h can b e either a single host or a m ulticast group plus the
destination p ort n um b er if not it creates path state for that target The switc h then obtains the
outgoing in terfaces of the path message from the routing proto col in use and up dates its table
of incoming and outgoing links accordingly the source address and p ort n um b er in the In ternet
con text carried in the path message will also b e recorded if the path message indicates that the
application ma y require a ltered reserv ation This path message is forw arded immediately only if
it is from a new source or indicates a c hange in routes The switc h can detect a c hange in routes
byc hec king to see if the outgoing in terfaces indicated b y the routing proto cols routing table are
dieren t than the outgoing links main tained in the path state Otherwise the switc h discards the
incoming path message and instead p erio dically sends its o wn path messages whic h con tain the
path information carried in all the path messages that it has receiv ed so far
When a receiv er receiv es a path message from a source for whose data it w ould lik e to create a
reserv ation the receiv er sends a reserv ation message using the p ossibly mo died o wsp ec that
came in the incoming path message As describ ed earlier the reserv ation message will b e guided
along the rev erse route of the path messages to reac h the data sources Along the w ayif an y
switc h rejects the reserv ation an RSVP reject message will b e sen t bac k to the receiv er and the
reserv ation message discarded otherwise if the reserv ation message requires a new reserv ation to b e
made it will propagate as far as the closest p oin t along the w a y to the senders where a reserv ation
lev el equal or greater than that b eing requested has b een made
Once the reserv ation is established the receiv er p erio dicall y sends reserv ation refresh messages
whic h are iden tical in format to the original request As the reserv ation requests are forw arded
along the sink trees the switc hes merge the requests for the same m ulticast group b y pruning those
that carry a request for reserving a smaller or equal amoun t of resources than some previous
request As an example let us assume that H in Figure is a video source and that H has
reserv ed enough bandwidth to receiv e the full video data stream while H w an ts to receiv e only
lo w resolution video data In this case when the reserv ation request from H reac hes S S will
mak e the requested reserv ation o v er the link from S to H and then S will drop the request ie
not forw ard it upstream b ecause sucien t resources ha v e b een reserv ed already b y Hs request
When a sender receiv er wishes to terminate the connection the sender receiv er sends out a
path reserv ation teardo wn message to release the path state or reserv ed resources There is no
retransmission timer for this teardo wn message In cases where the teardo wn message is lost the
in termediate no des will ev en tually time out the corresp onding state As w e noted ab o v e nolter
or xedlter reserv ations cannot b e explicitly torn do wn b ecause the switc hes do not main tain
sucien t state
Example
T o illustrate in more detail ho w RSVP w orks w e consider a simple net w ork conguration There are
hosts connected b ypoin ttop oin t links and switc hes w e assume that for the links connecting
them directly to a switc h the hosts act as switc hes in terms of reserving resources T o simplify the
description in the follo wing examples w e assume adequate net w ork resources exist for all reserv ation
requests F urthermore the example in v olv es only a single m ulticast group so w e do not discuss the
addressing used to distinguish reserv ations made for one m ulticast group from reserv ations made
for other m ulticast groups
W e describ e the cases of nolter and ltered reserv ations separately w e start with the simpler
case nolter reserv ations and then discuss the case of ltered reserv ations
Nolter Reserv ations
Let us consider an audio conference to b e held among participan ts one at eac h of the hosts
depicted in Figure therefore eac h host b eha v es b oth as a source and a receiv er at the same time
W e assume that the routing proto col has built a m ulticast routing tree so that eac h sender can
reac h all the receiv ers eac h switc h has receiv ed RSVP path messages with the Fag o from
all the sources therefore the switc hes do not record source information and stored complete path
state as b elo w although in a real application sources ma y start at dieren t times hence the path
state w ould b e built up o v er time and no reserv ations ha v e b een made y et
S S S
Incominglinks L L L L L L L L L
Outgoinglinks L L L L L L L L L
Weno w describ e ho w reserv ations are created H w an ts to receiv e data from all other senders to
the m ulticast group but only w an ts enough bandwidth reserv ed to carry one audio stream th us it
sends a reserv ation message RB nofilter to S where B is the amoun t of bandwidth needed
to forw ard one audio stream When S receiv es RB nofilter it rst reserv es resources o v er
L in the direction from S to w ards H then attac hes the follo wing reserv ation state to the path
state to indicate the amoun t of the reserv ation made o v er L
S
Incominglinks L L L
Outgoinglinks LB L L
Finally S forw ards RB nofilter o v er all incominglinks in this case L and L Note that
the switchnev er forw ards an y RSVP message o v er the link the message came from
The copyof RB nofilter that w as sen t along L reac hes S whic h reserv es B o v er L and
forw ards the message to links and When the cop yof RB nofilter that w as sen t along
L reac hes S that switc h reserv es B o v er L and then forw ards RB nofilter o v er links and When H w an ts to create a reserv ation it sends a reserv ation message RB nofilter to S Up on receipt of RB nofilter S rst reserv esBo v er L so the path state then b ecomes
S
Incominglinks L L L
Outgoinglinks LB LB L
S then forw ards RB nofilter o v er L only b ecause it has forw ard an iden tical request o v er
L previously After all the receiving hosts ha v e sen t RSVP reserv ation messages an amoun t B of resources ha v e
b een reserv ed o v er eac h of the links in eac h of the t w o directions
Before lea ving this example of nolter reserv ation let us consider the tradeo b et w een k eeping
extra state information and the p ossibilityof o v erreserving resources on certain links as w emen tioned earlier In the ab o v e example w e had assumed that all the path messages had the Fag
o therefore there is no p er source information k ept at the switc hes As a result if eac h of the
receiv ers had requested an amoun t B of bandwidth ie an amoun t enough to carry t w o full audio
streams then an amoun tBw ould b e reserv ed on ev ery link ev en though on link L and similarly
on links L L L and L in the direction a w ayfromH w e need only reserveanamoun t B since
there is only a single source upstream on the link In general a nolter reserv ation should indicate
howm uc h should b e reserv ed as a function of the n um b er of sources upstream in this example
it w ould b e B units p er upstream source Unfortunately one cannot kno w the n um b er of sources
upstream without k eeping a list of the sources Had the Fag b een set in all the path messages
the switc hes w ould ha vek ept trac k of individual sources and bypa ying this extra cost in increased
state only the required amoun t of resources w ould ha v e b een reserv ed along all the links
Although not main taining p er source information can lead to an o v erreserving of resources o v er
some of the net w ork links as the ab o v e example sho w ed in those applications where there are man y
data sources but few resources are needed for eac h source suc h as in a datagathering application
with man y sensors one ma y still c ho ose to reduce the switc h state at the p ossible exp ense of
o v erreserving resources o v er some links
Filtered Reserv ations
No w consider the case where H H H and H are receiv ers ie mem b ers of the m ulticast
group and H H and H are sources All path message ha v e the Fag set so eac h switc h needs
to k eep a list of sources asso ciated with their previous hops Assume that S has receiv ed path
messages from all of the sources but that no reserv ations ha vey et b een made Th us Ss path
state con tains the follo wing en try
S
Outgoinglinks LsrcHH HS HS LsrcHH
The notation LsrcHH HS HS indicates that data from sources H H and H are sen t out along outgoing link L for eac h source H S and S are the previous hop addresses
from whic h data from that source arriv es resp ectiv ely H is not a receiv er so L is not among
the outgoing links of S
No w assume that H sends the follo wing reserv ation message denoted RB H That is H
w an ts to receivepac k ets only from source H and is reserving an amoun t B that is sucien t for
one source The reserv ation message RB H reac hes S via the L in terface S nds that H
is indeed one of the sources it has heard and that the pac k ets from H come from S S reserv es
bandwidth B o v er L and forw ards RB H o v er L to S
Ss path state con tains the follo wing en tries
S
Outgoinglinks LsrcHS HS LsrcHS HH LsrcHS HH
When S receiv es RB H it reserv es B o v er L and then forw ards the message RB H to
S whic h is the previous hop to w ards H
Ss path state con tains the follo wing en tries
S
Outgoinglinks LsrcHS HH HS LsrcHS HS LsrcHH
Up on receiving RB H S reserv esBo v er L and forw ards the message to H When the
message reac hes H a pip e of B has b een reserv ed from H to H This describ es the reserv ation
ev en ts surrounding the reserv ation request RB H Supp ose that sometime afterw ards H sends the reserv ation message RB where indicates
a request for dynamiclter reserv ation When S receiv es this reserv ation message RB it
reserv es B o v er L at least sources can go that direction for H and forw ards the reserv ation
message RB o v er L and L
When S receiv es RB it nds out that there is only one source going out L It therefore
reserv es an amountB o v er L for R and then passes the reserv ation request on to H
When S receiv es RB it nds out that there is only one source going out L and has
a xedlter reserv ation already S do es not reserv ean y more nor do es it further forw ard the
request to L
Supp ose no w that at some p oin t H decides to terminate b oth receiving and sending and do es not
transmit an y teardo wn messages Since H will no longer b e sending path or reserv ation refreshes
all H related state will time out resulting in the follo wing outgoinglink en tries in the v arious
switc hes
S LsrcHH HS LsrcHH
S LsrcHS LsrcHH LsrcHS HH
S LsrcHS HS
S stops forw arding RB H from H and returns an RSVP error message to H S forw ards
future RB reserv ation refreshes to the L direction only since there are no more sources in
L direction
F or the sak e of simplicit y in the ab o v e example weha v e assumed that eac h of the data streams
requires the same amoun t of bandwidth to forw ard RSVP is designed to handle the case where
eac h source ma y demand dieren t amoun t of resources and eac h receiv er ma y receiv e only a subset
of the data from eac h source In xedlter reserv ations this requires that eac h source lter m ust
b e asso ciated with a sp ecic amoun t of resources In dynamiclter reserv ations the receiv er m ust
either receiv e the same amoun t of data when switc hing c hannels or it m ust sp ecify a sp ecic
amoun t of resources for eac h of the sources in its curren t lter and the sum of its total incoming
data v olume do es not c hange o v er the lifetime of the reserv ation
Implemen tati on Status
This article is in tended to illustrate at a general lev el ho w RSVP w orks There are man y details
that for the sak eofbrevit y and clarit yw eha v e not presen ted In particular w eha v e not describ ed
with an y sp ecicit y the merging algorithm Ho w ev er w eha vev eried this design in a pac k etlev el
in teractiv e sim ulator where all suc h details ha v e b een tested
The sim ulator used is written b y one of us LZ and has b een used in sev eral previous sim ulation
studies The sim ulator pro vides mo dules that imitate the actual b eha vior of common
net w ork comp onen ts suc h as hosts links IP routers and proto cols suc hasIP TCP and UDP Wev eried RSVP design b y implemen ting the proto col in the sim ulator and then observing step
b y step ho w the proto col handles v arious dynamic ev en ts suc h as new sendersreceiv ers joining a
m ulticast group or existing mem b ers lea ving Indeed the design of most proto col details emerged
from an iterativ e pro cess of sim ulation and redesign
Using the sim ulator co de as a starting p oin t the proto col has b een implemen ted b y Sugih Jamin
USC for exp erimen tation on Dartnet whic h is a crosscoun tryTnet w ork testb ed sp onsored b y
ARP A linking roughly a dozen academic and industrial researc h institutions Preliminary tests
ha v e b een p erformed on this implemen tation but no systematic p erformance studies ha v e b een
done as y et
Related W ork
In the course of exploring net w ork algorithms that deliv er qualit y of service guaran tees there ha v e
b een sev eral prop osals and protot yp e implemen tations of net w ork resource reserv ation algorithms
o v er the last few y ears see for example Ho w ev er almost all of these protot yp es deal
exclusiv ely with unicast reserv ations
The Stream Proto col ST w as a pioneering w ork in m ulticast reserv ation proto col design ST
w as designed sp ecically to supp ort v oice conferencing and w as capable of making b oth unicast and
m ulticast resource reserv ations A t the time ST w as prop osed there w as no w ork on sophisticated
m ulticast routing so ST w ould mak e resource reserv ations o v er a single duplex distribution tree
whichw as created b y blending the paths from unicast routing this w as done with the assumptions
that the routes w ere rev ersible and the application data trac w ould tra v el in b oth directions
Ho w ev er ST requires a cen tralized Access Con troller to co ordinate among all the participan ts and
to manage the tree establishmen t
The successor to ST STI I con tin ues to create its o wn m ulticast trees b y blending the paths
from unicast routing ho w ev er STI I establishes m ultiple simplex reserv ations to eliminate the
Access Con troller Eac h data source mak es a resource reserv ation along a m ulticast tree that is
ro oted at the source and reac hes out to all the receiv ers the reserv ation made along the tree uses
a single o wsp ec therefore STI I cannot accommo date heterogeneous receiv ers Because eac h data
source mak es its reserv ation indep enden tly a single pip e is reserv ed from ev ery source to ev ery
receiv er in the same m ulticast application group An analysis of STI I implemen tation and design
issues is pro vided in
Th us neither ST nor STI I pro vides a robust and ecien t solution to the m ultip oin ttom ultip oin t
resource reserv ation problem they share sev eral of the limitations of the stra wman prop osal de
scrib ed earlier The RSVP design eort w as initiated to ll this v acuum Recen tlyho w ev er there
ha v e b een other prop osals to ll this need P asquale et al ha v e prop osed a disseminationorien ted
approac h in their w ork on m ultimedia m ulticast c hannels They share with us the viewp oin t
that in order to ecien tly supp ort heterogeneous receiv ers eac h receiv er m ust b e able to sp ecify a
stream lter for the subset of the data it is in terested in receiving and furthermore that in order
to not w aste net w ork resources the lters from all the receiv ers should b e propagated to w ards the
sender so that the subset of the data that no one is in terested w ould b e stopp ed at the earliest
poin t along the source propagation tree Ho w ev er they only considered single source applications
suc h as cable TV as opp osed to RSVPs functionalit y of supp orting m ultip oin ttom ultip oin t ap
plications and they ha v e mainly fo cused on the programming in terface to applications as opp osed
to our in terest in designing a proto col that reserv es resources inside the net w ork and adjusts the
reserv ation to dynamic en vironmen tal c hanges
Unresolv ed Issues
While RSVP has b een sim ulated and tested to some exten t w e fully exp ect that further incremen tal
design c hanges will b e made as w e gain exp erience with RSVP b oth on D AR Tnet and also through
further sim ulation Besides these incremen tal c hanges ho w ev er there are sev eral larger design
issues that remain unresolv ed These issues are
RSVP w as designed with minimal exp ections of routing P ath messages are used to essen tially
in v ert the routing tables a function that routing could easily pro vide if it w ere so designed If
wew ere to design new routing algorithms what routing supp ort w ould w e include to supp ort
resource reserv ation algorithms
In this design weha v e asso ciated lters with resource reserv ations In fact lters could b e
applied to o ws ev en without reserv ed resources F urthermore there are lter st yles b esides
the ones describ ed here that migh t b e useful F or instance as has b een prop osed b y Jacobson
for remote lectures with sev eral sp eak ers at separate sites one mightw an t a dynamic
ltered reserv ation where the lter is the same for eac h receiv er this feature w ould allo w the
audience to switc h in unison to dieren tspeak ers with only one set of resources reserv ed
Th us one unresolv ed issue is dening the general service mo del and in terfaces for suchlters where these denitions are not sp ecically tied to the presence of resource reserv ations
Our currentsim ulations and tests deal only with reasonably small net w orks and small m ul
ticast groups W edonot y et understand ho w RSVP p erforms when the size of the m ulticast
groups gets v ery large Can one use cac hing strategies to a v oid the router state explosion
when S the n um b er of senders andor R the n um ber of receiv ers gets v ery large This
issue is particularly relev an t to the case of cable TV where ev ery home w ould w an t a dynamic
reserv ation but the switc hes ob viously w ould not w antto k eep individual reserv ation state
for eac h home
Summary
RSVPs arc hitecture is unique in that it pro vides receiv erinitiated reserv ations to accommo
date heterogeneit y among receiv ers as w ell as dynamic mem b ership c hanges it separates the
lter from the reserv ation th us allo wing c hannel c hanging b eha vior it supp orts a dynamic and
robust m ultip oin ttom ultip oin t comm unication mo del b y taking a softstate approachinmain tain
ing resource reserv ations and it decouples the reserv ation and routing functions and th us can
run on top of and tak e adv an tage of an ym ulticast routing proto cols
Weha vev eried the rst RSVP design as describ ed ab o v e b y detailed sim ulation and a preliminary
implemen tation Muc h testing remains to b e done in the con text of larger scale sim ulations as w ell
as in real protot yp e net w orks suchasD AR Tnet
Ac kno wledgmen ts
Wew ould lik e to gratefully ac kno wledge useful con v ersations with Bob Braden Da vid Clark Ron
F rederic k Shai Herzog Sugih Jamin and Dann y Mitzel
References
Ballardie A Tsuc hiy a P and Cro w croft J Cor e BasedT r e es CBT In ternet Draft
No v em b er Cidon I Segall A F ast Conne ction Establishment in High Sp e e d Networks in the Pro ceed
ings of A CM SIGCOMM Septem b er Clark D D The Design Philosophy of the D ARP A Internet Pr oto c ols in the Pro ceedings
of A CM SIGCOMM August Clark D D Shenk er S and Zhang L Supp orting R e alTime Applic ations in an Inte gr ate d
Servic es Packet Network A r chite ctureand Me chanism in the Pro ceedings of A CM SIG
COMM August Deering S Multic ast R outing in a Datagr am Internetwork T ec h Rep ort No ST ANCS
Stanford Univ ersit y Decem b er F errari D Banerjea A and Zhang H Network Supp ort for Multime dia A Discussion of
the T enet Appr o achT ec hnical Rep ort TR Computer Science Division Univ ersityof
California at Berk eleyNo v em b er
F orgie J ST A Pr op ose d Internet Str e am Pr oto c olIn ternet Exp erimen tal Notes IEN
Septem ber Golestani S J Dur ationLimite d Statistic al Multiplexing of Delay Sensitive T r ac in Packet
NetworksIn Pro ceedings of INF OCOM
Jacobson V priv ate comm unication
Jamin S Shenk er S Zhang L and Clark D A dmission Contr ol A lgorithm for Pr e dictive
R e alTime Servic e Pro ceedings of rd In ternation al W orkshop on Net w ork and Op erating
System Supp ort for Digital Audio and VideoNo v em b er Kalmanek C Kanakia H and Kesha v S R ate Contr ol le d Servers for V ery HighSp e e d
NetworksIn Pro ceedings of Glob eCom pp J Hyman A Lazar and G P acici R e alTime Sche duling with Quality of Servic e Constr aints In IEEE JSA CV ol No pp Septem ber Hyman J M Lazar A A P acici G Join tSc heduling and Admission Con trol for A TS
based Switc hing No des Pro c A CM SIGCOMM August P artridge C APr op ose d Flow Sp e cic ation In ternet RF C July C P artridge and S Pink A n Implementation of the R evise d Internet Str e am Pr oto c ol ST In In ternet w orki ng Researc h and Exp erienceV ol No pp Marc h P asquale J P olyzos G Anderson E and Komp ella V The Multime dia Multic ast Channel Pro ceedings of rd In ternation al W orkshop on Net w ork and Op erating System Supp ort
for Digital Audio and VideoNo v em b er
T op olcic C Exp erimental Internet Str e am Pr oto c ol V ersion STII In ternet RFC Octob er Zhang L A New A r chite ctur e for Packet Switching Network Pr oto c olsIn T ec hnical Rep ort
TR Lab oratory for Computer Science Massac h usetts Institute of T ec hnology
Accommo date heterogeneous receiv ers
Adapt to c hanging m ulticast group mem b ership
Exploit the resource needs of dieren t applications in order to use net w ork resources ecien tly
Allo w receiv ers to switch channels
Adapt to c hanges in the underlying unicast and m ulticast routes
Con trol proto col o v erhead so that it do es not gro w linearly or w orse with the n um ber of
participan ts
Mak e the design mo dular to accommo date heterogeneous underlying tec hnologies
Figure The Sev en Design Goals of RSVP Receiv erInitiated Reserv ation
Separating Reserv ation from P ac k et Filtering
Pro viding Dieren t Reserv ation St yles
Main taining SoftState in the Net w ork
Proto col Ov erhead Con trol
Mo dularit y
Figure The Six Design Principles of RSVP H3
H4
H5
S1
S2
S3
H1
H2
S4
Figure A simple net w ork top ology with the m ulticast routing trees depicted H and H are
data sources and H H and H are receiv ers The solid lines depict the routing tree of H and
the dotted lines the routing tree of H In general the set of sources and the set of receiv ers ma y
o v erlap partially or completely here for the sak e of clarit yw e consider the case where they are
disjoin t
H3
H4
H5
S1
S2
S3
H1
H2
S4
Figure A simple net w ork top ology with the sink trees depicted H and H are data sources
and H H and H are receiv ers sinks The dotted lines depict the sink tree of H and the solid
lines the sink tree of H F or clarit y the sink tree of H is omitted
H1
H2 H3
H4 H5
S1
S2
S3
L1
L2
L3
L4
L5
L6
L7
Figure Net w ork T op ology
Abstract (if available)
Linked assets
Computer Science Technical Report Archive
Conceptually similar
PDF
USC Computer Science Technical Reports, no. 585 (1994)
PDF
USC Computer Science Technical Reports, no. 607 (1995)
PDF
USC Computer Science Technical Reports, no. 648 (1997)
PDF
USC Computer Science Technical Reports, no. 656 (1997)
PDF
USC Computer Science Technical Reports, no. 655 (1997)
PDF
USC Computer Science Technical Reports, no. 599 (1995)
PDF
USC Computer Science Technical Reports, no. 614 (1995)
PDF
USC Computer Science Technical Reports, no. 731 (2000)
PDF
USC Computer Science Technical Reports, no. 608 (1995)
PDF
USC Computer Science Technical Reports, no. 670 (1998)
PDF
USC Computer Science Technical Reports, no. 605 (1995)
PDF
USC Computer Science Technical Reports, no. 678 (1998)
PDF
USC Computer Science Technical Reports, no. 657 (1997)
PDF
USC Computer Science Technical Reports, no. 586 (1994)
PDF
USC Computer Science Technical Reports, no. 565 (1994)
PDF
USC Computer Science Technical Reports, no. 640 (1996)
PDF
USC Computer Science Technical Reports, no. 690 (1998)
PDF
USC Computer Science Technical Reports, no. 730 (2000)
PDF
USC Computer Science Technical Reports, no. 696 (1999)
PDF
USC Computer Science Technical Reports, no. 667 (1998)
Description
Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker and Daniel Zappala. "RSVP: A new resource reservation protocol." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 606 (1995).
Asset Metadata
Creator
Deering, Steve
(author),
Estrin, Deborah
(author),
Shenker Scott
(author),
Zappala, Daniel
(author),
Zhang, Lixia
(author)
Core Title
USC Computer Science Technical Reports, no. 606 (1995)
Alternative Title
RSVP: A new resource reservation protocol (
title
)
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Tag
OAI-PMH Harvest
Format
22 pages
(extent),
technical reports
(aat)
Language
English
Unique identifier
UC16270872
Identifier
95-606 RSVP A New Resource ReSerVation Protocol (filename)
Legacy Identifier
usc-cstr-95-606
Format
22 pages (extent),technical reports (aat)
Rights
Department of Computer Science (University of Southern California) and the author(s).
Internet Media Type
application/pdf
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/
Source
20180426-rozan-cstechreports-shoaf
(batch),
Computer Science Technical Report Archive
(collection),
University of Southern California. Department of Computer Science. Technical Reports
(series)
Access Conditions
The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Repository Email
csdept@usc.edu
Inherited Values
Title
Computer Science Technical Report Archive
Coverage Temporal
1991/2017
Repository Email
csdept@usc.edu
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/