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. 644 (1997)
(USC DC Other)
USC Computer Science Technical Reports, no. 644 (1997)
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
A Dynamic Bo otstrap Mec hanism for Rendezv ousbased
Multicast Routing
Deb orah Estrin Mark Handley Ahmed Helm y P olly Huang Da vid Thaler
Abstract
Currentm ulticast routing proto cols can b e classied in to three t yp es according to ho w the
m ulticast tree is established broadcast and prune eg D VMRP PIMDM mem b ership ad
v ertisemen t eg MOSPF and rendezv ousbased eg CBT PIMSM Rendezv ousbased
proto cols asso ciate with eac h logical m ulticast group address a ph ysical unicast address re
ferred to as the core or rendezv ous p oin t RP Mem bers rst join a m ulticast tree ro oted
at this rendezv ous p oin t in order to receiv e data pac k ets sen t to the group Rendezv ous mec h
anisms are w ell suited to large widearea net w orks b ecause they distribute groupsp ecic data
and mem b ership information only to those routers that are on the m ulticast distribution tree
Ho w ev er rendezv ous proto cols require a b o otstr ap me chanism to map eac h logical m ulticast
address to its currentph ysical rendezv ousp oin t address The b o otstrap mec hanism m ust adapt
to net w ork and router failures but should minimize unnecessary c hanges in the grouptoRP
mapping In addition the b o otstrap mec hanism should b e transparen t to the hosts
This pap er describ es and analyzes the b o otstrap mec hanism dev elop ed for PIMSM The
mec hanism emplo ys an algorithmic mapping of m ulticast group to rendezv ous p oin t address
based on a set of a v ailable RPs distributed throughout a m ulticast domain The primary ev al
uation measures are con v ergence time message distribution o v erhead balanced assignmen tof
groups to RPs and host impact The mec hanism as a whole and the design lessons in particular
are applicable to other rendezv ousbased m ulticast routing proto cols as w ell
In tro duction
Multicast routing is a critical tec hnology for the ev olving In ternet Previous pap ers ha v e describ ed
tec hniques that use some form of broadcast to build a m ulticast distribution tree from activ e
sources to curren t group mem b ers D VMRP and PIMDM broadcast initial data pac k ets
whic h in turn trigger and store prune state in those parts of the net w ork that do not lead to group
mem bers MOSPF broadcasts mem b ership information so that in termediate no des can construct
source sp ecic distribution trees on the y These m ulticast routing proto cols are ecien t when
eac h group is widely represen ted or the bandwidth is univ ersally plen tiful
Authors listed in alphab etical order
In con trast Core Based T rees CBT and Proto col Indep enden t MulticastSparse Mo de
PIMSM or PIM for short do not use broadcast Rather they use explicit joining to a desig
nated core or rendezv ous p oin t whereb y new receiv ers hear from all group sources and new sources
reac h all group mem b ers Suc h rendezv ousbased m ulticast routing proto cols are b etter suited for
wide area m ulticast where group mem bers ma y b e sparsely distributed and where bandwidth is a
scarce resource The PIM arc hitecture describ ed the rationale and design details b y whic h
the m ulticast trees are built and main tained In this pap er w e describ e the b o otstrap mec hanisms
in particular the distribution of rendezv ousp oin t information and the use of that information to
map sp ecic groups to RPs in a consisten t distributed and robust manner W e fo cus on the
robustness and con trol message o v erhead of the b o otstrap mec hanisms b ecause these are the main
determinan ts of scalabilit y After a short o v erview of PIMSM w e motiv ate the design of its b o otstrap mec hanisms and
outline the remainder of the pap er
Proto col Indep enden t MulticastOv erview
In this section w e pro vide an o v erview of the arc hitectural comp onen ts of PIMSM referred to
hereafter as PIM The arc hitecture describ ed here op erates in eac h m ulticast domain
whic h in this con text is a con tiguous set of routers that all implemen t PIM and op erate within a
common b oundary dened b y PIM Multicast Border Routers As sho wn in Figure when a receiv ers lo cal router Adisco v ers it has lo cal receiv ers it starts
sending p erio dic joinmessages to w ard a groupsp ecic Rendezv ous P oin t RP Eac h router along
the path to w ard the RP builds a wildcard an ysource r oute entry for the group and sends the
joinmessages on to w ard the RPA r oute entry is the forw arding state held in a router to main tain
the distribution tree T ypically it includes the data source address the m ulticast group address
the incoming in terface from whic h pac k ets are accepted the list of outgoing in terfaces to whic h
pac k ets are sen t and v arious timers and ags In this case the wildcard route en trys data source
is an y source the incoming in terface p oin ts to w ard the RP and the outgoing in terfaces p ointto
the neigh b oring do wnstream routers that ha v e sen t join messages to w ard the RP This state forms
a shared RPro oted distribution tree that reac hes all group mem b ers
When a data source rst sends to a group its lo cal router D unicasts registermessages to
the RP with the sources data pac k ets encapsulated within If the data rate is high the RP can
send sourcesp ecic joinmessages bac k to w ards the source These will instan tiate source sp ecic
route en tries in the routers on the path and the sources data pac k ets will then follo w the resulting
forw arding state and tra v el unencapsulated to the RP Data pac k ets reac hing the RP are forw arded nativ ely do wn the RPro oted distribution tree
to w ard group mem bers If the data rate w arran ts it routers with lo cal receiv ers can join a source
sp ecic shortest path distribution tree and prune this sources pac k ets o of the shared RPro oted
tree Ho w ev er for lo w data rate sources PIM routers need not join a sourcesp ecic shortest path
tree and data pac k ets can b e deliv ered via the shared RPtree
If a sender or receiv er has more than one lo cal router one of them is elected the Designated
Router DR and only this router participates in this pro cess
Figure Ho w senders rendezv ous with receiv ers
Bo otstrap mec hanismsarc hitectural issues
Rendezv ousbased proto cols require that ev ery router consisten tly maps an activem ulticast group
address to the same RP There are man yw a ys to p erform this task
Application lev el adv ertisemen ts to distribute RP information along with the m ulticast group
to p oten tial participan t applications
A routing proto col to adv ertise grouptoRP mappings to routers
A distributed directory in whic h routers can lo okup grouptoRP mappings ondemand
An algorithmic mapping from m ulticast address to RP address
Applicationlev el adv ertisemen ts require c hanging the IP m ulticast service mo del and require
adding applicationlev el dep endencies on the c hoice of m ulticast routing proto col
Routingproto col based adv ertisemen ts scale badly b ecause eac h router needs to main tain the
mapping for all p oten tial m ulticast groups This ma y additionally add unpredictable dela ys b et w een
c ho osing a m ulticast address and b eing able to use it
Ondemand lo okup using a distributed directory suc h as DNS scales b etter but in tro duces
a startup dela y from when a source starts sending to when the directory resp onds with the group
toRP mapping This is a problem for sources wishing to use m ulticast for resource lo cation for
example where only a brief query ma y b e sen t and then the sender go es silen t again Suc h burst y
sources ma y send for less time than the time tak en to acquire the mapping If the in terburst
period is longer than the routers state timeout period then all the sources pac k ets ma y be lost
deterministically W e refer to this problem as the bursty sour c e pr oblem All three of these mec hanisms do not allo w applications to algorithmically generate and use
m ulticast addresses without announcing them to all p oten tial recipien ts a b o otstrapping problem
in some circumstances
Moreo v er all three of these mec hanisms in tro duce a dep endency on applicationlev el directory
assistance in some w a y if only to insert the mapping in to the database Ideally w e w ould lik e
m ulticast to be as lo w a lev el service as p ossible dep ending only on unicast routing and routers
themselv es
The use of an algorithmic mapping from group to RP address allo ws us to address these com
p eting design issues This approac h en tails p erio dic distribution of a set of reac hable RPs to all
routers in the domain and use of a common hash function to map an y m ulticast address to one
router from the set of RPs The algorithmic mapping approac h requires routers to store and main
tain liv eness information for a relativ ely small and stable set of RPs per m ulticast domain This
approac h scales w ell is purely a lo wlev el routing function and do es not require an y c hanges to
hosts
F or suc h an algorithmic mapping to w ork the set of RPs m ust b e distributed consisten tly to all
routers within a domain This m ust be done robustly and ecien tly If routers ha v e inconsisten t
sets of RPs groups ma y fail to rendezv ous
The distribution of the set of RPs within a domain cannot be supp orted b y rendezv ousbased
m ulticast without man ual conguration whic h is not robust to failures or misconguration The
set of RPs could be distributed using a separate broadcastandprune m ulticast routing proto col
but this w ould in tro duce an unnecessary dep endency A third alternativ e adopted here uses a
simple bridgelik e o o ding mec hanism to distribute the set of RPs ecien tly within eac h domain
see section Finally giv en the c hoice of an algorithmic mapping w em ust use one that will ac hiev e the goal
of mapping groups ev enly across RPs in the domains RP set th us reducing trac concen tration
at individual RPs W e also desire c haracteristics suc h as minimal group disruption when RP
reac habilityc hanges the abilit y to map related groups to the same RP and ecien t implemen tation
The remainder of this pap er pro vides a detailed ev aluation of the design robustness and p erfor
mance of the b o otstrap mec hanisms Section describ es these mec hanisms in detail and section ev aluates them in terms of robustness and eciency Section details the algorithmic mapping and
its ev aluation Section summarizes our results and prop osals for future researc h Supplemen tal
app endices pro vide elab orate details of proto col mo dels mathematical analyses and sim ulation
detail
Bo otstrap mec hanisms Design description and rationale
This section describ es ho w the set of RPs is distributed throughout a domain W e elab orate on
the design rationale of the b o otstrap mec hanisms The three critical elemen ts of the design are
the b o otstrap router the candidate RPs and the RPSet The follo wing subsections describ e ho w
these elemen ts t together to realize the b o otstrap mec hanisms
BSR election
A Bo otStrap Router BSR is a dynamicallyelected PIM router within a PIM domain It
collects the set of p oten tial RPs and distributes the resulting set of RPs RPSet to all the
PIM routers in the PIM domain Cen tralizing the RPSet distribution reduces the opp ortunities
for inconsistency while dynamic election pro vides robustness in the face of net w ork c hanges and
failures
A small set of routers within a PIM domain are congured as candidate b o otstrap routers
CandidateBSRs and eac h is giv en a not necessarily unique BSRpriorit y F rom these can
didates a single b o otstrap router BSRiselected for that domain Should the curren t BSR fail
or another CandidateBSR with higher priorit y be added to the net w ork a new BSR is elected
automatically The mec hanism is based up on a bridgelik e spanningtree election algorithm b o otstrap messages
originated b y the CandidateBSRs tra v el hopb yhop and the most preferred
candidate is elected
as the BSR for the domain This dense distribution mec hanism is ecien t since all PIM routers
in the domain require the messages whic h corresp onds to a densely p opulated group
The elected BSR originates p erio dic b o otstrap messages to capture net w ork dynamics If a
PIM domain partitions eac h area separated from the old BSR will elect its o wn BSR whic h will
distribute an RPSet con taining RPs that are reac hable within that partition When the partition
heals an election will o ccur with the next p erio dic b o otstrap message and only one of the BSRs will
con tin ue to send out b o otstrap messages As is exp ected at the time of a partition or healing some
disruption in pac k et deliv ery ma y o ccur This time will b e on the order of the regions endtoend
dela y and the b o otstrap router timeout v alues see section The BSR election mec hanism is in tegrated with the RPSet distribution mec hanism describ ed
in section Complete mec hanistic details are giv en in app endix A and RPSet construction using CandidateRPAdv ertisemen ts
A set of routers within a PIM domain are congured as c andidate RPs T ypically these are the
same routers that are congured as CandidateBSRs
Once a BSR for the domain is elected
candidate RPs p erio dically unicast CandidateRPAdv ertisemen t messages to the elected BSR
These messages include the address of the adv ertising candidate RP and pro vide a liv eness indication
to the BSR
The BSR c ho oses a subset
of or all the liv e candidate RPs to form the RPSet whic h is then
distributed in the b o otstrap messages
RPSet distribution
The b o otstrap messages originated b y the BSR carry the BSRs address and priorit y and the RP
Set A b o otstrap message is m ulticast out all in terfaces with a TTL of to all directly connected
PIM routers Before accepting a b o otstrap message a PIM router p erforms t w o c hec ks
Only those b o otstrap messages that arriv e from the Rev erse P ath F orw arding RPF neigh bor
to w ards the BSR are pro cessed others are discarded The RPF c hec k prev en ts lo oping of
b o otstrap messages P ersisten t lo oping w ould lead to usage of obsolete information
Unicast routing dynamics ma y cause transien t lo ops but these do not aect the ev en tual
correctness of the mec hanism
The preferred router is the one with highest congured priorit y or highest addressed if priorities are equal
An y PIM router can b e congured as a candidate RP or CandidateBSR Ho w ev er to maximize reac habilit y only w ellconnected stable routers should b e congured as candidates
The BSR attempts to c ho ose the same subset eac h time if p ossible
The RPF neigh b or for an IP address X is the the nexthop router used to forw ard pac k ets to w ard X
If the RPF c hec k passes a c hec k is p erformed against the previously stored activ e BSR
information priorit y and address Ev ery time a PIM router gets a message from the elected
BSR it restarts a b o otstraptimer So long as the timer has not expired the BSR is considered
activ e and only messages from a preferred CandidateBSR or from the activ e BSR are
accepted If the b o otstraptimer has expired this indicates that the stored BSR is no longer
activ e and the next b o otstrap message receiv ed will be accepted App endix A presen ts a
detailed state transition diagram for this mec hanism as w ell as the timer actions
When a b o otstrap message is accepted b y a PIM router the BSR and RPSet information
within that router are up dated and the b o otstraptimer restarted The b o otstrap message is then
forw arded out all in terfaces except the receiving in terface
Toac hiev e b etter con v ergence for newly started PIM routers a Designated Router ma y send a
b o otstrap message carrying RPSet information to new PIM neigh b ors In this case a newly started
PIM router ha ving no RPSet information accepts the rst b o otstrap message it gets In general
ho w ev er b o otstrap messages are only sen t p erio dically and are not triggered This minimizes the
o v erhead asso ciated with the mec hanism for detailed analysis of o v erhead see section When a BSR b ecomes unreac hable and b o otstrap messages stop routers con tin ue to use the
stored RPSet un til they get new information This w a ym ulticast data distribution is not disrupted
as long as the RP for the group is still reac hable F or further discussion of detailed failure scenarios
see section RPSet pro cessing
The b o otstrap message indicates liv eness of the RP in the RPSet If an RP is included then it is
tagged as up at the routers while RPs not included in the message are remo v ed from the set of
RPs o v er whic h the grouptoRP mapping algorithm functions
This mec hanism adapts ecien tly to net w ork dynamics including partitions The BSR main
tains a timer for eachRP called the RPtimer When an RP b ecomes unreac hable the BSR stops
receiving adv ertisemen ts from it Consequen tly the BSRs RPtimer for that RP expires and the
RP is remo v ed from the RPSet Routers receiving the new RPSet that do es not con tain the
failed RP remap the aected groups to other reac hable RPs from the new RPSet
Since the set of RPs are kno wn to be liv e prior to initiating a m ulticast group this sc heme
requires no start up phase and hence is suitable for applications with strict start up dela y b ounds
The burst y source problem is also eliminated
This RP liv eness mec hanism requires only a b o otstrap message CandidateRPAdv ertisemen t
message and an RPtimer at the BSR simplifying complex reac habilit y mec hanisms describ ed in
a previous PIM sp ecication and ob viating the need for RPreac habilit y RPlist and P oll
messages in addition to v arious ags and timers
GrouptoRP mapping
When a Designated Router DR receiv es an IGMP HostMem b ershipRep ort from a directly
connected receiv er for a group for whic h it has no state the DR uses an algorithmic mapping to
bind the group to one of the RPs in the RPSet The DR then sends a join message to w ards
that RP When the DR receiv es a data pac k et from a directly connected sender for suc h a group
it p erforms the same algorithmic mapping and sends the data pac k et encapsulated in a Register
message directly to the RP All PIM routers within a domain use the same mapping algorithm
whichw e presen t in section Ev aluation metrics of the Bo otstrap Mec hanisms
One of the ma jor design goals of the b o otstrap mec hanisms is sc alability In the next t w o subsec
tions w e sho w a detailed ev aluation of the b o otstrap mec hanism with emphasis on t w o critical
dimensions of scalabilit y r obustness and overhe ad F or robustness w e study resp onsiv eness of the proto col to router failures and top ology c hanges
In particular w e explain the transien t proto col b eha vior due to v arious net w ork ev en ts and ev aluate
the time tak en to con v erge on and join to a consisten t RPSet The study establishes an upp er
b ound on a v erage c onver genc e time F or o v erhead w eev aluate the domain resources state and bandwidth consumed b y the b o ot
strap mec hanisms The state consumed is the memory required to main tain the BSR and RPSet
information in eac h router and is simply prop ortional to the size of the RPSet The analysis of the
bandwidth o v erhead ho w ev er is more in v olv ed b ecause it is aected b y the underlying top ology Ev aluation of robustness
When an RP or BSR c hanges state ie b ecomes reac hable or unreac hable data loss ma y o ccur
The duration of time during whichloss mayoccur is a function of the con v ergence time m uchas
it is for unicast routing
Occasional RP failure or unreac habilit y is una v oidable When this happ ens receiv ers using
the shared RP tree ma y lose data for groups that map to the failed RP Mean while the RPtimer
asso ciated with this RP at the BSR times out and the RP is remo v ed from the RPSet Up to
this poin t the RPSet remains consisten t among all routers When distribution of the new RP
Set starts the groups that mapp ed to the failed RP ma y temp orarily use inconsisten t RPSets if
some routers receiv e the new RPSet b efore others After the distribution is completed all routers
con v erge on the new RPSet When aected groups rejoin to the new RP data will b e receiv ed
again
In this section w e en umerate the v arious net w ork ev en ts that can result in data loss F or eac h
ev entweform ulate an expression for the a v erage con v ergence time W e use the follo wing terms in
our analysis
Con v ergence time Conv The time tak en for all routers within a domain to con v erge
on and join to a consisten t RPSet of reac hable RPs after net w ork c hanges This represen ts
an upp er b ound on the time tak en for group participan ts DRs to rejoin to a single reac hable
RP This time is measured from the poin t when the RPSet b ecomes inconsistentor an RP
within the RPSet b ecomes unreac hable
CandidateRPAdv ertisementperiod RP A dvPerio d The p erio d at whic h Candidate
RPAdv ertisemen t messages are sen t eg seconds
All default v alues men tioned here are set as p er the PIMv sp ecication
RP timeout RPTime out The time in terv al after whic h the BSR times out an RP T ypically this timer is set to times the CandidateRPAdv ertisemen t p erio d eg
seconds
Bo otstrap p erio d Bo otstr apPerio d The p erio d at whic h the elected BSR originates
p erio dic b o otstrap messages eg seconds W e call the state in whic h the elected BSR
originates p erio dic messages the ste ady state Bo otstrap timeout Bo otstr apTime out The time after whic h a CandidateBSR originates
a b o otstrap message to elect a new BSR W e call the time during whic h the election is in
pro cess the tr ansient state eg seconds times the b o otstrap p erio d
RPSet distribution time SetDist The time to distribute an RPSet throughout the
domain or the time for all routers within the domain to con v erge on the distributed RPSet
Join latency JoinL at The time tak en to establish a new m ulticast branc h leading to a
receiv er b y pro cessing hopb yhop PIM join messages The join messages ma yin w orst case
tra v el all the w a y to the RP if no closer p oin t exists on the m ulticast tree
Join p erio d JoinPerio d The time in terv al at whic h p erio dic joinmessages are sen teg seconds
A t the end of this section w e presen t sample con v ergence times for v arious net w ork top ologies
and loss probabilities
Con v ergence time due to v arious net w ork ev en ts
When net w ork dynamics aect BSR and RP reac habilit y data loss ma y o ccur The b o otstrap mec h
anism describ ed here w as designed to adapt to these c hanges in a timely fashion The con v ergence
time v aries dep ending up on the particular net w ork ev en t
Changes in BSR A c hange in the BSR without a c hange in the RPSet do es not partition
groups
nor cause data loss RPs con tin ue to supp ort activ e groups without disruption to data
deliv ery so long as the RPs are reac hable during the BSR reelection
Addition of a new RP When a new candidate RP b ecomes reac hable it ma y immediately
obtain the BSR address from its neigh b ors or w ait for the p erio dic b o otstrap messages The new
candidate RP then sends a CandidateRPAdv ertisemen t to the BSR Pro vided that the Candidate
RPAdv ertisemen t message is not lost and the BSR includes it in a new RPSet the new RPSet
will be distributed during the next RPSet cycle After the RPSet distribution time SetDist the domain con v erges on the up dated RPSet The last con v erged router needs time JoinL at to
join to the new RP Group partition ma y o ccur during the distribution of the new RPSet as some routers get the
new information b efore others There is p oten tial data loss for some group mem b ers during the
time when group partition o ccurs
If no join messages are lost this v alue is on the order of the endtoend dela y of a domain
A group partitions when m utually reac hable receiv ers and senders map to dieren t RPs or map to an unreac hable
RP and hence fail to rendezv ous
Hence the con v ergence time b ecomes
R P AddC onv S etD ist J oinLat
Deletion of an RP In the follo wing analyses w e use the notation ab to denote a time in terv al
bet w een a and b If an RP b ecomes unreac hable from the BSR its asso ciated RPtimer at the
BSR expires within the in terv al RPTime out RP A dvPerio d RPTime out at b est the RP failure
happ ens righ t b efore the RP sends a CandidateRPAdv ertisemen t where the time in terv al b et w een
the p oin t of failure and RPtimer timeout is RPTime outRP A dvPerio d The BSR will send the new
RPSet at the next RPSet cycle Bo otstr apPerio d After SetDist the PIM domain con v erges
on the up dated RPSet The last con v erged router needs time JoinL at to join to the new RP W e note that p oten tial data loss starts from the p oin t of RP failure or unreac habilit y but only
aects groups that map to the unreac hable RP After all PIM routers con v erge on the up dated
RPSet and aected groups rejoin to their new RP the data loss for the aected groups stops
During the RPSet Distribution Time groups mapping to the unreac hable RP are partitioned
The con v ergence time b ecomes
R P D el C onv R P T imeout R P Adv P er iod R P T imeout
B ootstr apP er iod S etD ist J oinLat
Net w ork partitions In addition to single BSR c hange and RP c hange w e are in terested in
ev en ts suc h as net w ork partition and partition healing that ma y sometimes cause sim ultaneous
c hanges in b oth RP and BSR reac habilit y When a domain partitions it is divided in to t w o separate regions one of whic h will ha v e the
old BSR and some subset of the RPs in the RPSet and the other will ha v e the remainder of the
RPs in the RPSet Wewill look ateac h side of the partition in turn
F or the region con taining the original BSR an y groups using RPs in that region will b e unaf
fected and hence their con v ergence time is An y groups using RPs that are no wunreac hable
will see con v ergence times equiv alen t to those exp erienced when an RP is deleted
On the other side of the partition without the original BSR all groups using RPs whic h are
still reac hable on the same side will remain unaected and hence also ha v e a con v ergence time
of Groups using no wunreac hable RPs ho w ev er exp erience longer con v ergence times A new
BSR is elected after Bo otstr apTime out After RPTime out the new BSR times out the RPtimer
Then the new BSR up dates the RPSet and distributes the new RPSet within the in terv al Bo otstr apPerio d After SetDist the PIM domain con v erges on the up dated smaller RPSet
Thelastcon v erged router needs time JoinL at to join to the new RP In this case the con v ergence time is giv en b y
P ar titionC onv B ootstr apT imeout R P T imeout B ootstr apP er iod S etD ist J oinLat
When a partition heals the t w o previouslypartitioned regions merge Eac h region will originally
ha v e its o wn BSR and set of RPs Of the t w o BSRs one will be more preferred than the other
and b ecome the BSR of the com bined region A t the p oin t where the t w o regions b ecome m utually
reac hable groups are b y denition partitioned and hence the con v ergence time starts from this
p oin t
When the partition heals the more preferred BSR sends a b o otstrap message within the in terv al
Bo otstr apPerio d All routers in the other region receiv e this message after S etD ist It then
tak es JoinL at for them to join to a new RPTh us the initial con v ergence time is giv en b y
H eal C onv B ootstr apP er iod S etD ist J oinLat
Mean while the candidate RPs in the other region start sending their CandidateRPAdv ertisemen t
messages to the more preferred BSR Then one B ootstr apP er iod after the rst b o otstrap message
the more preferred BSR ma y issue an up dated RPSet with RPs from b oth previouslydisconnected
regions This can cause another temp orary group partition whic h is equiv alen t to that exp erienced
when a new RP is added
Ev aluation of RPSet distribution time and join latency
The expressions deriv ed ab o v e are all a function of RPSet distribution time and join latency both
of whic h dep end up on the c haracteristics of the domain top ology and the n um ber of successiv e
b o otstrap message losses
In the absence of pac k et loss the a v erage RPSet distribution time gro ws linearly with the end
toend dela y of the domain Therefore w e represen t the distribution time for a particular top ology
in the absence of pac k et loss as a constan t C
b
This constan t co v ers transmission pro cessing and
propagation dela ys
Next w e consider the eect of pac k et loss In App endix B w e sho w that the exp ected RPSet
distribution time is b ounded b y
E S etD ist C
b
B ootstr apP er iod P N where E S etD ist is the exp ected v alue of S etD ist N is the n um b er of no des in the domain and
P is the probabilityof pac k et loss on a link
PIM join messages are pro cessed hopb yhop and establish m ulticast state within in termediate
routers If the rst join message reac hes the RP successfully the v alue of JoinL at is simply the time
to establish the shared m ulticast tree within in termediate routers
Suc h time includes transmission
pro cessing times and propagation dela ys and is represen ted b y the constan t C
j
As with b o otstrap messages PIM join message loss con tributes to o v erall con v ergence time
Using similar terminology w e can lik ewise express the exp ected join latency JoinL at in the
presence of pac k et loss as b eing b ounded b y
E J oinLat C
j
J oinP er iod P N Giv en these form ulations for the exp ected RPSet distribution time and join latency Figure sho ws com bined dela ys as a function of net w ork top ology and pac k et loss p er link probabilities
W e presen t examples for the com bination of RPSet distribution time and join latency b ecause
together they are the common v ariables in most of the con v ergence form ulas These results w ere
based on sev eral simplications and assumptions The constan ts C
b
and C
j
w ere assumed to be
Note that this represen ts an upp er bound on the join latency JoinL at for all routers since in general join
messages only reac h the nearest p oin t of the established tree and need not reac h the RP p er se
100
200
300
400
500
0.00001
0.0001
0.001
0.00
10.00
20.00
30.00
40.00
50.00
60.00
70.00
80.00
Convergence Time (Second)
N (Number of Domain Nodes)
P (Probability of Packet
Loss Per Link)
Upper Bound of Average SetDist + JoinLat
Figure Com bined RPSet distribution time and join latency SetDist JoinL at negligible as compared to the other terms and default v alues from the PIMSM sp ecication w ere used for the JoinPerio d Bo otstr apPerio d RPTime out Bo otstr apTime out and RP A dvPerio d V alues used for the pac k et loss probabilit y p er link w ere restricted to those ranges considered t ypical
of currentnet w orks
Summary of con v ergence time
T o conclude our discussion of con v ergence time Figure sho ws the results of substituting n um bers
in Figure in to the con v ergence form ulas for the v arious net w ork ev en ts The results sho wn w ere
obtained using the follo wing simplied equations based on default timer v alues
E R P AddC onv U pper B ound E S etD ist J oinLat E R P D el C onv U pper B ound E R P AddC onv E P ar titionC onv U pper B ound E R P AddC onv E H eal C onv UpperBound E R P AddC onv Anet w ork administrator could use this analysis to determine the maxim um desired domain size
giv en a tolerable con v ergence time and observ ed probabilityof pac k et loss p er link
Ev aluation of con trol message o v erhead
T ypically state and bandwidth o v erheads are considered F or the b o otstrap mec hanisms state
o v erhead is simply prop ortional to the n um b er of RPs within the RPSet Bandwidth o v erhead is
Upper Bound on Avg RPAddConv(in sec) Upper Bound on Avg RPDelConv(in sec)
N\P 0.00001 0.0001 0.001 N\P 0.00001 0.0001 0.001
100 0.12 1.19 12.49 100 150.12 151.19 162.49
200 0.24 2.41 26.44 200 150.24 152.41 176.44
300 0.36 3.64 41.85 300 150.36 153.64 191.85
400 0.48 4.89 58.88 400 150.48 154.89 208.88
500 0.60 6.14 77.70 500 150.60 156.14 227.70
Upper Bound on Avg PartitionConv(in sec) Upper Bound on Avg HealConv(in sec)
N\P 0.00001 0.0001 0.001 N\P 0.00001 0.0001 0.001
100 330.12 331.19 342.49 100 30.12 31.19 42.49
200 330.24 332.41 356.44 200 30.24 32.41 56.44
300 330.36 333.64 371.85 300 30.36 33.64 71.85
400 330.48 334.89 388.88 400 30.48 34.89 88.88
500 330.60 336.14 407.70 500 30.60 36.14 107.70
N: Number of Nodes in Domain
P = Probability of Packet Loss Per Link
Figure Summary of con v ergence time
a function of CandidateRPAdv ertisemen t and b o otstrap messages CandidateRPAdv ertisemen t
o v erhead is prop ortional to the n um ber of candidate RPs and the unicast distances b et w een can
didate RPs and the BSR A more complex issue is the o v erhead due to distribution of b o otstrap
messages The n um ber of RPs in the domain included in the RPSet aects the size of b o otstrap
messages W e assume the n um b er of RPs is constan t for the remainder of the comparisons
Bo otstrap message o v erhead in steady state
In steady state when there is no BSR election b o otstrap messages will b e originated p erio dically
ev ery Bo otstr apPerio d b y the BSR Eac h router accepts only those bootstrap messages sen t b y
the Rev erse P ath F orw arding neigh bor to w ards the BSR The accepted b o otstrap message is then
forw arded to all in terfaces except the receiving in terface
This b eha vior has the follo wing prop ert y If the unic ast r outing is stable and the link layer do es
not c ause any duplic ate p acket tr ansmission e ach no de wil l forwar d b o otstr ap messages only onc e
over e ach interfac e exc ept the inc oming interfac e
By the ab o v e prop ert y it is easy to sho w that the total n um ber of b o otstrap messages sen t
within the domain equals
C
BS R
X
i C
BS R
C
i
X
C
i
N where C
i
is the degree of router i and N is total n um b er of routers in the PIM domain
Bootstrap Message Overhead: Total Amount of Bootstrap Messages on Links
0
50
100
150
200
250
300
350
400
450
500
10 15 20 25 30 35 40 45 50
Number of Domain Nodes
Number of Bootstrap Messages
Overhead in Transient w /o
Randomization
Overhead in Transient w
Randomization
Figure Distribution of b o otstrap o v erhead
Bo otstrap message o v erhead in transien t state
When the b o otstraptimer expires in all CandidateBSRs during transien t state after a net w ork
partition for example eac h CandidateBSR originates a b o otstrap message This b o otstrap message
is suppressed when it reac hes an y PIM router ha ving higher preference or whic h has receiv ed
b o otstrap messages from another CandidateBSR with higher preference
Since the b o otstraptimers are sync hronized b y the elected BSRs b o otstrap messages this
mec hanism ma y incur a lot of o v erhead as sho wn in Figure Yaxis v alues are the total n um
b er of b o otstrap messages generated or forw arded during a partition healing un til con v ergence
Ho w ev er adding randomization to b o otstrap message origination decreases the o v erhead of boot strap messages signican tly F urther if the random w ait v alue is a function of the priorit y and
address of the CandidateBSR the b eha vior of b o otstrap messages in transien t states tends to that
of the steady state In Figure the dotted line represen ts this case The R andomWait v alue is set
suc h that the highest addressed CandidateBSR is the rst to originate a b o otstrap message The
function used here is
R andomW ait log
E l ectedB S R Addr ess C andidateB S R Addr ess Sim ulations used random graphs generated using R TG As a w orst case scenario all routers w ere considered
CandidateBSRs
Sim ulations w ere p erformed using PIMSIM a discrete ev en tdriv en pac k etlev el sim ulator based on the Mary
land Routing Sim ulatorMaRS F uture sim ulations will use the Net w ork Sim ulator ns v ersion
This function could b e extended easily to accommo date v arious priorities as w ell
GrouptoRendezv ous P oin t Mapping Algorithm
Ha ving sho wn that all routers con v erge on a common RPSet under all kinds of conditions w e
no w consider the group to RP mapping using this RPSet
Ideally a go o d mapping of groups to RPs meets the follo wing requiremen ts
Group balancing under anym ulticast address allo cation sc heme By this w e mean that when
the n um b er of groups is large no single RP is serving signican tly man y more groups than an y
otherRPin the RPSet While this balances the numb er of groups as opp osed to balancing
the actual load the actual load will b e balanced roughly when the n um b er of groups is large
pro vided that the mapping is indep enden t of the load represen ted b y a group
Minimal disruption of groups when theres a c hange in the RPSet By this w e mean that
the n um ber of activ e m ulticast groups and hence the n um ber of shared RPtrees aected
bya c hange in the RPSet m ust b e as small as p ossible
A set of related groups can map to the same RP giving the same latency and fatesharing
c haracteristics and allo wing state aggregation This is useful when data is split across m ultiple
groups b ecause of dieren t media t yp es or for hierarc hical enco ding eg Ecien t implemen tation This means there m ust be a fast implemen tation requiring only
bit in teger arithmetic
W e emplo y hash function theory to realize the desired algorithm In the follo wing subsections
wepro vide bac kground information on theory and implemen tation of con v en tional hash functions
follo w ed b y an explanation of the selected Highest Random W eigh t HR W sc heme Then w e
ev aluate the scaling prop erties of the c hosen algorithm
Hash F unction Theory and Implemen tation
A con v en tional hash function maps a k ey k to one of n buc k ets b y computing a buc k et n um ber i
as a function of k ie i h k T ypically suc h functions are dened as f kmodulo nwhere f is
some function of k eg f k k when k is an in teger F or our purp oses a k ey k corresp onds to
am ulticast group address and a buc k et corresp onds to an RP from the RPSet The problem with
using a Mo dulo n function for GrouptoRP mapping ho w ev er comes when the RPSet c hanges
W e rst dene disruption as the fraction of k eys whic h map to a dieren t buc k et when the set of
buc k ets c hanges ie the n um ber of m ulticast groups whichget remapp ed to a dieren t RP when
the RPSet c hanges Since the RPSet ma y c hange whenev er a candidate RP go es up or do wn
the n um ber of buc k ets n o v er whic h the hash function will op erate can c hange o v er time F or
example when a single RP fails and the n um ber of RPs in the RPSet c hanges from n to n
all groups w ould b e remapp ed except those for whic h f kmod n f kmod n When f k is uniformly distributed the disruption will th us b e
n n
or almost all the groups Clearly this is
insucien t for our purp oses
Am uc h b etter sc heme whic hw e emplo y is the Highest Random W eigh t HR W algorithm
HR W denes the hash function so as to giv e the buc k et with the maxim um v alue of a function f ie
h i f k l i f k l j i j n
where the buc k et lab el l i is a function of the buc k et n um b er for our purp oses l i is the unicast
IP address of the i
th
RP in the RPSet and f is a function of both the k ey and the buc k et
lab el If f is sucien tly random with resp ect to k and l this has the desirable prop ert y that the
disruption caused b y m RPs c hanging is just mn This successfully ac hiev es the minim um b ound
on disruption as sho wn in Weno w need to nd an appropriate function for f that satises the ab o v e constrain t F or this
w e use the follo wing function
f k l i k X OR l i mo d whic h is deriv ed from the BSD rand function and is sho wn in to p erform w ell as a hash
function compared with other pseudorandom n um ber generators It also lends itself w ell to an
ecien t bit implemen tation
When a router detects that one or more m RPs ha v e failed b y their absence from a newly
receiv ed RPSet only those groups whic h previously mapp ed to those RPs m ust b e rehashed F or
eac h of these m
n
g groups h is recomputed in O n time for a total pro cessing requiremen t of
O mgw ork
On the other hand when a router detects that one or more m RPs ha v e been added to the
RPSet again only m
n
g groups will be aected but all groups m ust be rehashed to determine
whichof them are aected This can b e optimized b y storing the v alues of i and f k l i in p er
group state Then for eachgroup konly f k l j where l j is the address of a new RP need b e
calculated to determine whic h groups are aected This again can b e done in O mg time
Finallyto allo w state aggregation w eno w mo dify the denition of the k ey k to b e k group address mask
The mask determines howm uc h state aggregation will exist ie ho w man y groups will alw a ys map
to the same RP This mask is sp ecied b y the BSR and is included with the RPSet distributed to
all other routers in the domain F or example if this mask is hex FFFFFFF C the recommended
default then sets of four consecutiv e group addresses will map to the same RPAm ulticast address
allo cation sc heme maytak e adv an tage of this when allo cating m ultiple m ulticast addresses for the
same session b y allo cating a set of addresses whichha v e the longest p ossible prex in common
Ev aluation of the Hash F unction
T o determine ho w w ell our hash function scales with resp ect to group balancing w e use the c o ef
cient of variation dened as the ratio bet w een the standard deviation and the mean of
the n um ber of activ e groups mapp ed to eac h RP in the RPSet F or group balancing to scale w e
desire that
lim
g
where g is the n um ber of activ e groups W e emphasize that it is imp ortan t that this be true
r e gar dless of the distribution of k In other w ords it m ust be true under an y m ulticast address
allo cation sc heme When the n um b er of groups is small the co ecien tof v ariation is less imp ortan t
since the RPs will b e comparativ ely ligh tly loaded
W e ran sev eral sim ulations to v erify that do es indeed approac h in the limit Figure a
sho ws the results of v arying the n um ber of groups on among RPs In this sim ulation
both m ulticast group addresses and addresses of RPs w ere randomly c hosen from the a v ailable
0
0.05
0.1
0.15
0.2
0.25
100 1000 10000 100000
Coefficient of Variation
# Groups
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
0 50 100 150 200 250 300 350 400
Coefficient of Variation
# RPs in the Domain
a b
Figure Group balancing eectiv eness
address spaces Eac h poin t represen ts an a v erage o v er trials As can be seen the groups are
indeed balanced as g Other sim ulations using sequen tial m ulticast group addresses and RP
addresses pro duced similar results This is not surprising since the randomness inheren t in the
function f results in a mapping whic h is relativ ely indep enden t of the distribution of its inputs
Figure b sho ws the results of v arying the n um ber of RPs in the RPSet with the total
n um ber of groups remaining constan t at Again eac h poin t represen ts an a v erage o v er
trials F rom this w e see that gro ws with the n um b er of RPs Ho w ev er since the load on eac h
RP decreases as the n um b er of RPs gro ws this im balance b ecomes less imp ortan t
Summary and F uture W ork
Rendezv ousbased m ulticast routing proto cols are lik ely to b e an imp ortan t infrastructure tec hnol
ogy for the ev olving In ternet and therefore it is imp ortan t to carefully ev aluate their robustness
and eciency While previous studies describ ed and justied PIMs use of explicit join mec hanism
and the manner in whic h it builds and main tains distribution trees this is the rst treatmen t of
the other critical comp onen t of the arc hitecture the b o otstr ap me chanisms In this pap er w e ha v e presen ted arc hitectural and mec hanistic details of the b o otstrap mec h
anisms as w ell as systematic analysis and ev aluation of the robustness and p erformance of these
mec hanisms Moreo v er these b o otstrap mec hanisms could b e readily used with other rendezv ous
based m ulticast proto cols suc has CBT Curren tly under study are the extensions of the b o otstrap mec hanisms to a global in terdomain
con text and questions of m ulticast group address allo cation and state aggregation
References
D W aitzman S Deering C P artridge Distance V ector Multicast Routing Proto col No v em ber RF C
D Estrin D F arinacci A Helm y V Jacobson and L W ei Proto col Indep enden t MulticastDense
Mo de PIMDM Proto col Sp ecication Pr op ose d Exp erimental RF C Septem ber A J Ballardie P FF rancis and J Cro w croft Core Based T rees In Pr o c e e dings of the A CM SIG
COMM San F rancisco S Deering D Estrin D F arinacci M Handley AHelm y V Jacobson C Liu P Sharma D Thaler
and L W ei Proto col Indep enden t Multicast Sparse Mo de PIMSM Motiv ation and Arc hitecture
Exp erimental RF C Octob er S Deering D Estrin D F arrinacci V Jacobson C Liu and L W ei An Arc hitecture for Widearea
Multicast Routing In Pr o c e e dings of the A CM SIGCOMM London S Deering D Estrin D F arinacci V Jacobson C Liu and L W ei The PIM Arc hitecture for
WideArea Multicast Routing A CM T r ansactions on Networks April D Estrin D F arinacci A Helm y D Thaler S Deering M Handley V Jacobson C Liu P Sharma
andLW ei Proto col Indep enden t Multicast Sparse Mo de PIMSM Proto col Sp ecication Exp eri
mental RF C Decem b er S Deering D Estrin D F arinacci V Jacobson C Liu L W ei P Sharma and A Helm y Proto col
Indep enden t MulticastSparse Mo de PIMSM Proto col Sp ecication Internet Dr aft Decem ber W F enner In ternet Group Managemen t Proto col V ersion Internet Dr aftJan uary Liming W ei Thesis Dissertation Scalable Multicast Routing T ree T yp es And Proto col Dynamics
Decem b er Liming W ei The design of the USC PIM SIMulator PIMSIM T ec hnical Rep ort USC TR
Computer Science Departmen t Univ ersit y of Southern California F eburary Cengiz Alaettinoglu A Uda y a Shank er Klaudia DussaZieger and Ibrahim Matta Mars Maryland
Routing Sim ulator v ersion users man ual T ec hnical Rep ort CSTR Computer Science
Departmen t Univ ersit y of Mariland June Cengiz Alaettinoglu A Uda y a Shank er Klaudia DussaZieger and Ibrahim Matta Design and imple
men tation of mars A routing testb ed T ec hnical Rep ort CSTR Computer Science Departmen t
Univ ersit y of Mariland Septem ber Stev en McCanne The UCBLBNL Net w ork Sim ulatorns No v em b er
N Shac ham Multip oin t comm unication b y hierarc hically enco ded data In Pr o c e e dings of the IEEE
INF OCOM pages D T aubman and A Zakhor Multirate D subband co ding of video IEEE T r ansactions on Image
Pr o c essing Septem b er
Stev en McCanne V an Jacobson and Martin V etterli Receiv erdriv en La y ered Multicast In Pr o c e e dings
of the A CM SIGCOMM August
Da vid Thaler and Chin yaV Ra vishank ar A NameBased Mapping Sc heme for Rendezv ous T ec hnical
Rep ort CSETR Univ ersit y of Mic higan No v em ber
App endices
A BSR Election and RPSet Distribution
F or simplicit y the b o otstrap message is used in b oth the BSR election and the RPSet distribution
mec hanisms These mec hanisms are describ ed b y the follo wing state mac hine illustrated in gure The proto col transitions for a CandidateBSR are giv en in state diagram a F or routers not
congured as CandidateBSRs the proto col transitions are giv en in state diagram b
Incoming events
Name
-----------------------------------------------------------------------------------------------------
PrefBSMRxd
BSMRxd
TExp
Interface
RPF nbr toward included BSR
Meaning
Bootstrap msg rcvd satisfying P
RPF nbr toward included BSR Bootstrap message received
States
Name
------------------------------------------------------------------------------------------------------
AxptPref
Meaning
Accept only Bootstrap messages from preferred or equal BSR
AxptAny
Accept any RP-Set messages coming thru the right interface
Outgoing events
Name
-----------------------------------------------------------------------------------------------------
FwdBSM
Interface
All interfaces except receiving interface
Meaning
Forward Bootstrap message
Predicates
Name
------------------------------------------------------------------------------------------------------
P
Meaning
Timer provider machinery Bootstrap timer expired
RxdBSR LclBSR ≥
Specific actions
[1] = Restart Bootstrap timer at Bootstrap-Timeout
[2] = (LclBSR = RxdBSR)
[3] = (LclRP-Set = RxdRP-Set)
State variables
LclBSR = Local concatenated BSR priority and BSR IP address
LclRP-Set = Local RP-Set
RxdBSR = Received concatenated BSR priority and BSR IP address
RxdRP-Set = Received RP-Set
CandBSR
ElectedBSR
Candidate bootstrap router
Elected bootstrap router
All interfaces Originate Bootstrap message
[4] = Restart Bootstrap timer at Bootstrap-Period
OrigBSM
Bootstrap-Period = 60 seconds
Bootstrap-Timeout = 2.5 x Bootstrap-Period = 150 seconds
PrefBSMRxd; FwdBSM, [1][2][3]
TExp
BSMRxd; FwdBSM, [1][2][3]
PrefBSMRxd; FwdBSM, [1][2][3]
PrefBSMRxd; FwdBSM, [1][2][3]
AxptPref AxptAny
State transition diagram for a router not configured as C-BSR
CandBSR Elected BSR
TExp; OrigBSM,[4]
TExp; OrigBSM,[4]
State transition diagram for a Candidate BSR
Initial state: AxptAny; LclBSR = 0, LclRP-Set = empty
Initial state: CandBSR; LclBSR = Local address, LclRP-Set = empty
(b)
(a)
Figure State Diagram for the BSR election and RPSet distribution mec hanisms
Eac h PIM router k eeps a b o otstraptimer initialized to Bo otstrapTimeout in addition to a
lo cal BSR eld L clBSR initialized to a lo cal address if CandidateBSR or to otherwise and a
lo cal RPSet L clRPSet initially empt y The main stim uli to the state mac hine are timer ev en ts
and arriv al of b o otstrap messages
Initial states and timer ev en ts
If the router is a CandidateBSR
a The router op erates initially in the CandBSR state where it do es not originate an y
b o otstrap messages
b If the b o otstraptimer expires and the curren t state is CandBSR the router originates
a b o otstrap message carrying the lo cal RPSet and its o wn BSR priorit y and address
restarts the b o otstraptimer at Bo otstrapP erio d seconds and transits in to the Elect
edBSR state Note that the actual sending of the b o otstrap message ma y be dela y ed
b y a random v alue to reduce transientcon trol o v erhead
c If the b o otstraptimer expires and the curren t state is ElectedBSR the router orig
inates a b o otstrap message and restarts the RPSet timer at Bo otstrapP erio d No
state transition is incurred
This w a y the elected BSR originates p erio dic b o otstrap messages ev ery Bo otstrap
P erio d
If a router is not a CandidateBSR
a The router op erates initially in the AxptAn y state In suc h state a router accepts the
rst b o otstrap message from the The Rev erse P ath F orw arding RPF neigh bor to w ard
the included BSR The RPF neigh b or in this case is the next hop router en route to the
included BSR
b If the b o otstraptimer expires and the curren t state is AxptPref where the router
accepts only preferred b o otstrap messages those that carry BSRpriorit y and address
higher than or equal to L clBSR from the RPF neigh bor to w ard the included BSR
the router transits in to the AxptAn y state
In this case if an elected BSR b ecomes unreac hable the routers start accepting boot strap messages from another CandidateBSR after the b o otstraptimer expires All PIM
routers within a domain con v erge on the preferred reac hable CandidateBSR
Receiving b o otstrap message T o a v oid lo ops an RPF c hec k is p erformed on the included
BSR address Up on receiving a b o otstrap message from the RPF neigh bor to w ard the included
BSR the follo wing actions are tak en
If the router is not a CandidateBSR
a If the curren t state is AxptAn y the router accepts the b o otstrap message and transits
in to the AxptPref state
b If the curren t state is AxptPref and the b o otstrap message is preferred the message
is accepted No state transition is incurred
If the router is a CandidateBSR and the b o otstrap message is preferred the message is
accepted F urther if this happ ens when the curren t state is Elected BSR the router transits
in to the CandBSR state
When a b o otstrap message is accepted the router restarts the b o otstraptimer at Bo otstrap
Timeout stores the receiv ed BSR priorit y and address in L clBSR and the receiv ed RPSet in
L clRPSet and forw ards the b o otstrap message out all in terfaces except the receiving in terface
If a b o otstrap message is rejected no state transitions are triggered
B Analysis of RPSet distribution time and join latency
W e rst dene the follo wing terms
N n um b er of routers in the PIM domain
C
b
a v erage RPSet distribution time without loss of b o otstrap messages
P
i
the probabilit y that a giv en b o otstrap message crossing router is RPF link to w ards the
BSR is lost
Pr no b o otstrap loss the probabilit y that a giv en b o otstrap message reac hes all other
routers in the PIM domain
Pr no b o otstrap loss N Y
i
P
i
If no messages are dropp ed the a v erage RPSet distribution time SetDist should b e no greater
than the endtoend dela y and equal to C
b
If the rst b o otstrap message is lost an ywhere in
the domain con v ergence tak es at least another B ootstr apP er iod The second message will then
complete the con v ergence if there is no loss b et w een the BSR and an y routers whic h did not receiv e
the rst message The n um ber of times the b o otstrap message m ust be sen t un til it reac hes all
routers is then b ounded ab o v e b y a geometric distribution function The upp er b ound on the
exp ected n um b er of trials un til success is th us giv en b y
Exp ected trials un til success Pr no b o otstrap loss Note that this is simply an upp er b ound since in fact eac h no de need only get the message
once Th us once an en tire subtree has receiv ed the message later retransmissions dropp ed within
the subtree are irrelev an t
If w e assume for the sak e of simplicit y that P
i
is the same for all links then w eget Exp ected trials un til success P N E S etD ist C
b
B ootstr apP er iod P N W e can apply the same pro cess to nding the a v erage join latency Let C
j
be the a v erage
transmission pro cessing and propagation dela y exp erienced from the DR to the RP In the w orst
case a linear top ology the join message again crosses N links giving us upp er b ounds of
Exp ected trials un til success P N E J oinLat C
j
J oinP er iod P N
Abstract (if available)
Linked assets
Computer Science Technical Report Archive
Conceptually similar
PDF
USC Computer Science Technical Reports, no. 657 (1997)
PDF
USC Computer Science Technical Reports, no. 673 (1998)
PDF
USC Computer Science Technical Reports, no. 678 (1998)
PDF
USC Computer Science Technical Reports, no. 690 (1998)
PDF
USC Computer Science Technical Reports, no. 702 (1999)
PDF
USC Computer Science Technical Reports, no. 727 (2000)
PDF
USC Computer Science Technical Reports, no. 674 (1998)
PDF
USC Computer Science Technical Reports, no. 667 (1998)
PDF
USC Computer Science Technical Reports, no. 655 (1997)
PDF
USC Computer Science Technical Reports, no. 726 (2000)
PDF
USC Computer Science Technical Reports, no. 679 (1998)
PDF
USC Computer Science Technical Reports, no. 693 (1999)
PDF
USC Computer Science Technical Reports, no. 747 (2001)
PDF
USC Computer Science Technical Reports, no. 613 (1995)
PDF
USC Computer Science Technical Reports, no. 753 (2002)
PDF
USC Computer Science Technical Reports, no. 696 (1999)
PDF
USC Computer Science Technical Reports, no. 709 (1999)
PDF
USC Computer Science Technical Reports, no. 700 (1999)
PDF
USC Computer Science Technical Reports, no. 649 (1997)
PDF
USC Computer Science Technical Reports, no. 734 (2000)
Description
Deborah Estrin, Mark Handley, Ahmed Helmy, Polly Huang, David Thaler. "A dynamic bootstrap mechanism for rendezvous-based multicast routing." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 644 (1997).
Asset Metadata
Creator
Estrin, Deborah
(author),
Handley, Mark
(author),
Helmy, Ahmed
(author),
Huang, Polly
(author),
Thaler, David
(author)
Core Title
USC Computer Science Technical Reports, no. 644 (1997)
Alternative Title
A dynamic bootstrap mechanism for rendezvous-based multicast routing (
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
21 pages
(extent),
technical reports
(aat)
Language
English
Unique identifier
UC16271041
Identifier
97-644 A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Routing (filename)
Legacy Identifier
usc-cstr-97-644
Format
21 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/