Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 565 (1994)

(USC DC Other)

USC Computer Science Technical Reports, no. 565 (1994)

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content An Arc hitecture for WideArea Multicast Routing
Stephen Deering Xero x Deb orah Estrin USC Dino F arinacci cisco V an Jacobson LBL
ChingGung Liu USC Liming W ei USC
Abstract
Existing m ulticast routing mec hanisms w ere in tended for use
within regions where a group is widely represen ted or band
width is univ ersally plen tiful When group mem b ers and
senders to those group mem b ers are distributed sp arsely
across a wide area these sc hemes are not ecien t data pac k
ets or mem b ership rep ort information are o ccasionally sen t
o v er man y links that do not lead to receiv ers or senders re
sp ectiv elyW eha v e dev elop ed a m ulticast routing arc hitec
ture that ecien tly establishes distribution trees across wide
area in ternets where man y groups will b e sparsely repre
sen ted Eciency is measured in terms of the state con trol
message pro cessing and data pac k et pro cessing required
across the en tire net w ork in order to deliv er data pac k ets to
the mem b ers of the group
Our Proto col Indep enden t Multicast PIM arc hitecture
a main tains the traditional IP m ulticast service mo del
of receiv erinitia ted mem b ership b can b e congured to
adapt to dieren tm ulticast group and net w ork c haracteris
tics c is not dep enden t on a sp ecic unicast routing pro
to col and d uses softstate mec hanisms to adapt to under
lying net w ork conditions and group dynamics The robust
ness exibili t y and scaling prop erties of this arc hitecture
makeit w ell suited to large heterogeneous in ternet w orks
Intro duction
This pap er describ es an arc hitecture for ecien tly routing
to m ulticast groups that span widearea and in terdomain
in ternets W e refer to the approac h as Proto col Indep en
den t Multicast PIM b ecause it is not dep enden ton an y
particular unicast routing proto col
Giv en the length of this author list it seems appropriate to iden
tify the roles pla y ed b y eac h of the authors who are listed in alpha
b etical order Jacobson prop osed the original idea of sending join
messages to w ard disco v ered sources as a mean of supp orting sparse
m ulticast groups The detailed arc hitecture and supp orting proto cols
w ere dev elop ed as a collab orativ e eort of Deering Estrin F arinacci
and Jacobson More recen tly Liu iden tied and xed sev eral critical
proto col bugs as part of his implemen tation eort and W ei pro vided
data to supp ort the need for shortest path distribution trees SPT
and con tributed to proto col dev elopmen t as part of his sim ulation ef
fort Estrin Liu and W ei w ere supp orted b y gran ts from the National
Science F oundation and Sun Microsystems
The arc hitecture prop osed here complemen ts existing
m ulticast routing mec hanisms suc h as those prop osed b y
Deering in and implemen ted in MOSPF and D VMRP
These traditional m ulticast sc hemes w ere in tended
for use within regions where a group is widely represen ted
or bandwidth is univ ersall y plen tiful Ho w ev er when group
mem b ers and senders to those group mem b ers are dis
tributed sp arsely across a wide area these sc hemes are not
ecien t data pac k ets in the case of D VMRP or mem ber ship rep ort information in the case of MOSPF are o cca
sionally sento v er man y links that do not lead to receiv ers
or senders resp ectiv ely The purp ose of this w ork is to de
v elop a m ulticast routing arc hitecture that ecien tly estab
lishes distribution trees ev en when some or all mem b ers are
sparsely distributed Eciency is measured in terms of the
state con trol message pro cessing and data pac k et pro cess
ing required across the en tire net w ork in order to deliv er
data pac k ets to the mem b ers of the group
Background
In the traditional IP m ulticast mo del established b y Deer
ing a multic ast addr ess is assigned to the collection of
receiv ers for a m ulticast group Senders simply use that
address as the destination address of a pac k et to reachall
mem b ers of the group The separation of senders and re
ceiv ers allo ws an y hostmem b er or nonmem b erto send
to a group A group mem b ership proto col is used for
routers to learn the existence of mem b ers on their directly
attac hed subnet w orks This receiv erinitiated join pro cedure
has v ery go o d scaling prop erties as the group gro ws it b e
comes more lik ely that a new receiv er will b e able to splice
on to a nearb y branc h of the distribution tree A m ulticast
routing proto col in the form of an extension to existing
unicast proto cols eg D VMRP an extension to a RIP
lik e distancev ector unicast proto col or MOSPF an exten
sion to the linkstate unicast proto col OSPF is executed
on routers to construct m ulticast pac k et deliv ery paths and
to accomplish m ulticast data pac k et forw arding
In the case of linkstate proto cols c hanges of group mem
b ership on a subnet w ork are detected b y one of the routers
directly attac hed to that subnet w ork and that router broad
casts the information to all other routers in the same routing
domain Eac h router main tains an uptodate image of
the domains top ology through the unicast linkstate rout
ing proto col Up on receiving a m ulticast data pac k et the
router uses the top ology information and the group mem ber ship information to determine the shortestpath tree SPT
from the pac k ets source subnet w ork to its destination group
Figure Example of Multicast T rees
mem b ers Broadcasting of mem b ership information is one
ma jor factor prev en ting linkstate m ulticast from scaling to
larger widearea net w orksev eryrouterm ust receiv e and
store mem b ership information for ev ery group in the do
main The other ma jor factor is the pro cessing cost of the
Dijkstra shortestpathtree calculations p erformed to com
pute the deliv ery trees for all activem ulticast sources th us limiting its applicabi li ty onanin ternet wide basis
Distancev ector m ulticast routing proto cols construct
m ulticast distribution trees using v arian ts of Rev erse P ath
F orw arding When the rst data pac k et is sen t to a group
from a particular source subnet w ork and a router receiving
this pac k et has no kno wledge ab out the group the router
forw ards the incoming pac k et out all in terfaces except the
incoming in terface
A sp ecial mec hanism is used to a v oid
forw arding of data pac k ets to leaf subnet w orks with no mem
b ers in that group ak a truncated broadcasting Also if the
arriving data pac k et do es not come through the in terface
that the router uses to send pac k ets to the source of the
data pac k et the data pac k et is silen tly dropp ed th us the
term Rev erseP ath F orw arding RPF When a router
attac hed to a leaf subnet w ork receiv es a data pac k et ad
dressed to a new group if it nds no mem b ers presenton
its attac hed subnet w orks it will send a prune message up
stream to w ard the source of the data pac k et The prune mes
sages prune the tree branc hes not leading to group mem bers th us resulting in a sourcesp ecic shortestpath tree with all
lea v es ha ving mem b ers Pruned branc hes will gro wbac k
after a timeout p erio d these branc hes will again b e pruned
if there are still no m ulticast mem b ers and data pac k ets are
still b eing sen t to the group
Compared with the total n um b er of destinations within
the greater In ternet the n um b er of destinations ha ving
group mem b ers of an y particular widear e a group is lik ely to
b e small In the case of distancev ector m ulticast sc hemes
routers that are not on the m ulticast deliv ery tree still ha v e
to carry the p erio dic truncatedbroadcast of pac k ets and
pro cess the subsequen t pruning of branc hes for all activ e
groups One particular distancev ector m ulticast proto col
D VMRP has b een deplo y ed in h undreds of regions con
nected b y the MBONE Ho w ev er its o ccasional broad
Some sc hemes reduce the n um b er of outgoing in terfaces further
b y using unicast routing proto col information to k eep trackof c hild
paren t information casting b eha vior sev erely limits its capabilityto scale to
larger net w orks supp orting m uc h larger n um b ers of groups
man y of whic h are sparse
Extending multicast to the wide a rea scaling issues
The scalabilityof a m ulticast proto col can b e ev aluated in
terms of its o v erhead gro wth with the size of the in ternet
size of groups n um b er of groups size of sender sets and
distribution of group mem bers Ov erhead is measured in
terms of resources consumed in routers and links ie state
pro cessing and bandwidth
Existing linkstate and distancev ector m ulticast rout
ing sc hemes ha v e go o d scaling prop erties only when m ulti
cast groups densely p opulate the net w ork of in terest When
most of the subnet w orks or links in the in ternet w ork ha v e
group mem b ers then the bandwidth storage and pro cessing
o v erhead of broadcasting mem b ership rep orts linkstate
or data pac k ets distancev ector is w arran ted since the in
formation or data pac k ets are needed in most parts of the
net w ork an yw a y The emphasis of our prop osed w ork is to
dev elop m ulticast proto cols that will also ecien tly supp ort
the sparsely distributed groups that are lik ely to b e most
prev alen t in widearea in ternet w orks
Overhead and tree t yp es
The examples in gure illustrate the inadequacies of the
existing mec hanisms There are three domains that com
m unicate via an in ternet There is a mem b er of a particular
group G lo cated in eac h of the domains There are no other
mem b ers of this group curren tly activ e in the in ternet If a
traditional IP m ulticast routing mec hanism suchas D VMRP
is used then when a source in domain A starts to send to
the group its data pac k ets will b e broadcast throughout
the en tire in ternet Subsequen tly all those sites that do not
ha v e lo cal mem b ers will send prune messages and the distri
bution tree will stabilize to that illustrated with b old lines
in gure b Ho w ev er p erio dicall y the sources pac k ets
will b e broadcast throughout the en tire in ternet when the
prunedo branc hes time out
Th us far weha vemotiv ated our design b y con trasting it
to the traditional denselydistrib utedmem b ers hi p IP m ulti
cast routing proto cols More recen tly the Core Based T ree
CBT proto col w as prop osed to address similar scaling
1234 5 678
Network Node Degree
0.8
1.0
1.2
1.4
1.6
Ratio of Maximum Delay (CBT/SPT)
In 50-node networks
23456 7 8 9
Network Node Degree
5000
6000
7000
8000
9000
Max Number of Flows/link
300 Groups in each network
SPT
Center-Based Tree
a b
Figure Comparison of shortestpath trees and cen terbased tree
problems CBT uses a single deliv ery tree for eac h group
ro oted at a core router and shared b y all senders to the
group As desired for sparse groups CBT do es not exhibit
the o ccasional broadcasting or o o ding b eha vior of earlier
proto cols Ho w ev er CBT do es so at the cost of imp osing a
single shared tree for eachm ulticast group
If CBT w ere used to supp ort the example group then
a core migh t b e dened in domain A and the distribution
tree illustrated in gure c w ould b e established This
distribution tree w ould also b e used b y sources sending from
domains B and C This w ould result in concen tration of all
the sources trac on the path indicated with b old lines W e
refer to this as tr ac c onc entr atio n This is a p oten tially
signican t issue with CBT or an y proto col that imp oses
a single shared tree p er group In addition the pac k ets
tra v eling from Y to Z will not tra v el via the shortest path
used b y unicast pac k ets b et w een Y and Z
W e need to kno w the kind of degradations a corebased
tree can incur in a v erage net w orks Da vid W all pro v ed
that the b ound on maxim um dela y of an optimal corebased
tree whic h he called a c enterb ase d tree is times the
shortestpath dela yT o get a b etter understanding of ho w
w ell optimal corebased trees p erform in a v erage cases w e
sim ulated an optimal corebased tree algorithm o v er large
n um b er of dieren t random graphs W e measured the max
im um dela y within eac h group and exp erimen ted with
graphs of dieren t no de degrees W esho w the ratio of the
CBT maxim um delayv ersus shortestpath tree maxim um
dela y in gure a F or eac h no de degree w e tried dif
feren t no de graphs with mem b er groups c hosen ran
domly It can b e seen that the maxim um dela ys of core
based trees with optimal core placemen t are up to times
of the shortestpath trees
F or in teractiv e applicatio ns where lo w latency is critical
it is desirable to use the shortestpath trees to a v oid the
longer dela ys of an optimal corebased tree
With resp ect to the p oten tial trac concen tration prob
Note that although some error bars in the dela y graph extend
b elo w there are no real data p oin ts b elo w the distribution is
not symmetric for more details see lem w e also conducted sim ulations in randomly generated
no de net w orks In eac hnet w ork there w ere activ e
groups all ha ving mem b ers of whic h mem bers w ere
also senders W e measured the n um b er of trac o ws on
eac h link of the net w ork then recorded the maxim um n um
b er within the net w ork F or eac h no de degree b et w een three
and eigh t random net w orks w ere generated and the
measured maxim um n um b er of trac o ws w ere a v eraged
gure b sho ws a plot of the measuremen ts in net w orks
with dieren t no de degrees It is clear from this exp erimen t
that CBT exhibits greater trac concen trations
It is eviden t to us that b oth tree t yp es ha v e their ad
v an tages and disadv an tages One t yp e of tree ma y p erform
v ery w ell under one class of conditions while the other t yp e
ma y b e b etter in other situations F or example shared trees
ma y p erform v ery w ell for large n um bers of lo w data rate
sources eg resource disco v ery applicati ons while SPTs
ma y b e b etter suited for high data rate sources eg real
time teleconferencing
It w ould b e ideal to exibly sup
p ort b oth t yp es of trees within one m ulticast arc hitecture
so that the selection of tree t yp es b ecomes a conguration
decision within a m ulticast proto col
PIM is designed to address the t w o issues describ ed
ab o v e to a v oid the o v erhead of broadcasting pac k ets when
group mem b ers sparsely p opulate the in ternet and to do so
in a w a y that supp orts go o dqualit y distribution trees for
heterogeneous applications In PIM a m ulticast group can c ho ose to use shortest
path trees or a groupshared tree The rsthop routers of
the receiv ers can mak e this decision indep enden tlyA re ceiv er could ev en c ho ose dieren tt yp es of trees for dieren t
sources B
The capabilit y to supp ort dieren ttree t yp es is the fun
damen tal dierence b et w een PIM and CBT There are other
signican t proto col engineering dierences as w ell
A more complete analysis of these tradeos can b e found in Twoob vious engineering tradeos are
Soft state v ersus explicit reliabilitymec hanism CBT
uses explicit hopb yhop mec hanisms to ac hiev e reliable deliv
ery of con trol messages As describ ed in the next section PIM
P ap er o rganization
In the remainder of this pap er ween umerate the sp ecic de
sign requiremen ts for widearea m ulticast routing section
describ e a sp ecic proto col for realizing these require
men ts sections and discuss op en issues section Requirements
W e had sev eral design ob jectiv es in mind when designing
this arc hitecture
Ecien t Sparse Group Supp ort
W e dene a sparse group as one in whic h a the n um
b er of net w orks domains with group mem b ers presen t
is signican tly smaller than the n um b er of net w orks domains in the In ternet b group mem b ers span an
area that is to o largewide to rely on scop e con trol and
c the in ternet w ork spanned b y the group is not su
cien tly resource ric h to ignore the o v erhead of curren t
sc hemes Sparse groups are not necessarily small
therefore wem ust supp ort dynamic groups with large
n um b ers of receiv ers
HighQualit y Data Distribution
W e wish to supp ort lo wdela y data distribution when
needed b y the applicati on In particular w ea v oid im
p osing a single shared tree in whic h data pac k ets are
forw arded to receiv ers along a common tree indep en
den t of their source Sourcesp ecic trees are sup erior
when a m ultiple sources send data sim ultaneously
and w ould exp erience p o or service when the trac is
all concen trated on a single shared tree or b the path
lengths b et w een sources and destinations in the short
est path tree SPTs are signican tly shorter than in
the shared tree
Routing Proto col Indep enden t
The proto col should rely on existing unicast routing
functionalit y to adapt to top ology c hanges but at the
same time b e indep enden t of the particular proto col
emplo y ed W e accomplish this b y letting the m ulti
cast proto col mak e use of the unicast routing tables
indep endentof ho w those tables are computed
In terop erabilit y
W e require in terop erabili t y with traditional RPF and
linkstate m ulticast routing b oth in tradomain and
in terdomain F or example the in tradomain p ortion
of a distribution tree ma y b e established b y some other
IP m ulticast proto col and the in terdomain p ortion b y
PIM In some cases it will b e necessary to imp ose some
additional proto col or conguration o v erhead in order
uses p erio dic refreshes as its primary means of reliabilit yThis
approac h reduces the complexit y of the proto col and co v ers a
wide range of proto col and net w ork failures in a single simple
mec hanism On the other hand it can in tro duce additional
message proto col o v erhead
Incoming in terface c hec k on all m ulticast data pac k ets
If m ulticast data pac k ets lo op the result can b e sev ere unlik e
unicast pac k ets m ulticast pac k ets can fan out eac h time they
lo op Therefore w e assert that all m ulticast data pac k ets should
b e sub ject to an incoming in terface c hec k comparable to the
one p erformed byD VMRP and MOSPF
to in terop erate with some in tradomain routing proto
cols
In supp ort of this in terop eration with existing IP m ul
ticast and in supp ort of groups with v ery large n um
b ers of receiv ers w e should main tain the logical sepa
ration of roles b et w een receiv ers and senders
Robustness
The proto col should b e able to gracefully adapt to
routing c hanges W eac hievethis b y a using soft state
refreshmen t mec hanisms b a v oiding a single p oin t
of failure and c adapting along with and based on
unicast routing c hanges to deliv er m ulticast service so
long as unicast pac k ets are b eing serviced
PIM Proto col
In this section w e start with an o v erview of the PIM proto col
and then giv e a more detailed description of eac h phase
As describ ed traditional m ulticast routing proto cols
whichw ere designed for densely p opulated groups rely on
data driv en actions in all the net w ork routers to establish
ecien t distributio n trees w e refer to suchsc hemes as dense
mo de m ulticast In con trast sp arse mo de m ulticast tries to
constrain the data distribution so that a minimal n um ber of
routers in the net w ork receiv e it PIM diers from existing
IP m ulticast sc hemes in t w o fundamen tal w a ys
routers with lo cal or do wnstream mem b ers join a
PIM sparse mo de distributio n tree b y sending explicit
join messages in dense mo de IP m ulticast suc has
D VMRP mem b ership is assumed and m ulticast data
pac k ets are sentun til routers without lo cal or do wn
stream mem b ers send explicit prune messages to re
mo v e themselv es from the distribution tree
whereas dense mo de IP m ulticast tree construction
is data driv en PIM m ust use p ergroup r endezvous
p oints RPs for receiv ers to meet new sources
RPs are used b y senders to announce their existence
and b y receiv ers to learn ab out new senders of a group
The shortest path tree state main tained in routers is
roughly the same as the forw arding information that is cur
ren tly main tained b y routers running existing IP m ulticast
proto cols suc h as MOSPF ie source S m ulticast address
G outgoing in terface set oif incoming in terface iif W e refer to this forw arding information as the m ulticast for
w arding en try for SG
An en try for a shared tree can matchpac k ets from an y
source for its asso ciated group if the pac k ets come through
the righ t incoming in terface W e denote suchanen try G
A G en try k eeps the same information an SG en try
k eeps except that it sa v es the RP address in place of the
source address There is a wildcard ag indicating that this
is a shared tree en try Figure sho ws a simple scenario of a receiv er and a
sender joining a m ulticast group via an RP When the re
ceiv er w an ts to join a PIM m ulticast group its rsthop
W e will discuss ho w RPs are selected in section The oif s and iif s of SG en tries in all routers together form a
shortest path tree ro oted at S
Figure Ho w senders rendezv ous with receiv ers
PIMsp eaking router A in gure sends a PIM join mes
sage to w ard one of the RPs adv ertised for the group Pro
cessing of this message byin termediate routers sets up the
m ulticast tree branc h from the RP to the receiv er When
sources start sending to the m ulticast group the rsthop
PIMsp eaking router D in gure sends a PIM register
message piggybac k ed on the data pac k et to the RPs for
that group The RP resp onds b y sending a join to w ard the
source Pro cessing of these messages b yin termediate routers
there are no in termediate routers b et w een the RP and the
source in gure sets up a pac k et deliv ery path from the
source to the RPs
If sourcesp ecic distributio n trees are desired the rst
hop PIM router for eachmem ber ev en tually joins the source
ro oted distribution tree for eac h source b y sending a PIM
join message to w ard the source After data pac k ets are re
ceiv ed on the new path router D to router B then to router
A router B in gure sends a PIM prune message to w ard
the RP
One or more rendezv ous p oin ts RPs are used initial ly
to propagate data pac k ets from sources to receiv ers An RP
can b e an y PIMsp eaking router in the net w ork A sparse
mo de group ie one that the receiv ers directly connected
PIM router will join using PIM is iden tied b y the pres
ence of RP addresses asso ciated with the group in ques
tion The mapping information ma y b e congured or ma y
b e learned through another proto col mec hanism eg a new
IGMP message used b y hosts distribute information ab out
RPs to their lo cal routers
PIM a v oids explicit en umeration of receiv ers but do es re
quire en umeration of sources If there are v ery large n um bers
of sources sending to a group but the sources a v erage data
rates are lo w then one p ossibil it y is to supp ort the group
with a shared tree instead whic h has less p ersource o v er
head If shortest path trees are desired then when the n um
b er of sources gro ws v ery large some form of aggregation or
pro xy mec hanism will b e needed see section W e selected
Bkno ws b yc hec king the incoming in terface in it routing table
that it is at a p oin t where the shortest path tree and the RP tree
branc hes div erge A ag called SPT bit is included in SG en tries
to indicate whether the transition from shared tree to shortest path
tree has nished This minimizes the c hance of losing data pac k ets
during the transition
this tradeo b ecause in man y existing and an ticipated ap
plications the n um b er of receiv ers is m uc h larger than the
n um b er of sources And when the n um b er of sources is v ery
large the a v erage data rate tends to b e lo w er eg resource
disco v ery
The remainder of this section describ es the proto col de
sign in more detail
Lo cal hosts joining a group
A host sends IGMP rep ort message iden tifying a particular
group G in resp onse to a directlyconnected routers IGMP
query message as sho wn in gure F rom this p ointon w e
refer to suc h a host as a receiv er R or mem b er of the
group G
When a designatedr outer DR
receiv es a rep ort
for a new group G it c hec ks to see if it has RP addresses
asso ciated with G
A DR will iden tify a new group ie
one for whic h it has no existing m ulticast en tries as needing
PIM sparse mo de supp ort byc hec king if there exists an RP
mapping If there is no RP mapping pro vided in IGMP
rep ort messages and there is no mapping pro vided in the
appropriate conguration le then the router will assume
that the group is not to b e supp orted with PIM sparse mo de
Ev en when a group has an asso ciated RPit ma y b e that
some outgoing and incoming in terfaces do not require PIM
sparse mo de but are handled using a dense mo de sc heme
suc h as MOSPF D VMRP or a dense mo de v ariantof PIM
In this case the router will ag individ ual in terfaces
as dense or sparse mo de to allo w dieren tial treatmentof
dieren tin terfaces F or the sakeof clarit yw e will ignore
these added complexities throughout most of the proto col
description See section for some further discussion of
A designated router is the one that tak es resp onsibilit y for serving
the mem b ers on a m ultiaccess LAN
The mec hanism for learning this mapping of G to RPs is some
what orthogonal to the sp ecication of this proto col ho w ev er w e
require some mec hanism in order for the proto col to w ork A t the
v ery least this information m ust b e man ually congurable W e pro
p ose the use of a new host message that w ould allo w hosts to inform
their directlyconnected PIMsp eaking routers of GRPs mappings
This is imp ortan t for dynamic groups where hosts participate in sp e
cial applications to adv ertise and learn of m ulticast addresses and
their asso ciated RPs
Figure Example ho wareceiv er joins and sets up shared tree
Actions are n um b ered in the order they o ccur
these v ery practical issues
F or the remainder of this description w e will also assume
a single RP just for the sak e of clarit y W e discuss the
direct extensibili t y to op eration with m ultiple RPs later in
the do cumen t in section The DR eg router A in gure creates a m ulticast
forw arding cac he for G The RP address is included in
a sp ecial record in the forw arding en trysothatitwill be
included in upstream join messages The outgoing in terface
is set to that o v er whic h the IGMP rep ort w as receiv ed from
the new mem b er The incoming in terface is set to the in
terface used to send unicast pac k ets to the RP A wildcard
W C bit asso ciated with this en try is set indicating that
this is a G en try The DR sets an RPtimer for this en try The timer is
reset eac h time an RP reac habilit y message is receiv ed for
G see section Establishing the RPro oted sha red tree
The DR router creates a PIM join message with the RP ad
dress in its join list with the RP and W C bits set nothing
is listed in its prune list The W C bit ags an address as
b eing the RP asso ciated with that shared tree The RP
bit indicates that the receiv er exp ects to receivepac k ets
from new sources via this shared tree path and there
fore upstream routers should create or add to G for
w arding en tries
The PIM join message pa yload con tains
MulticastaddressG PIMjoin fRP RPbitW CbitgPIM pruneNULL
A RP bit in a forw arding en try indicates that the incoming in ter
face c hec k for that en try should b e the RPF in terface to the RPnot
to the source PIM prune messages with the RP bit set cause this bit
to b e set in the asso ciated forw arding en try The RP bit in an SG
en try indicates that p erio dic PIM joinprune should b e sen tto w ard
the RP Eac h upstream router creates or up dates its m ulticast
forw arding en try for G when it receiv es a PIM join with
the W C and RP bits set The in terface on whichthe PIM
join message arriv ed is added to the list of outgoing in ter
faces for G Based on this en try eac h upstream router b e
t w een the receiv er and the RP sends a PIM join message in
whic h the join list includes the RP The pac k et pa yload con
tains MulticastaddressG PIMjoin fRP RPbitW Cbitg PIMpruneNULL
The RP recognizes its o wn address and do es not attempt
to send join messages for this en try upstream The incoming
in terface in the RPs G en try is set to n ull RP reac ha
bilit y messages are generated b y RPs p erio dicall y and dis
tributed do wn the G tree established for the group This
allo ws do wnstream routers to detect when their currentRP
has b ecome unreac hable and triggers joining to w ard an al
ternate RP Switching from sha red tree RP tree to sho rtest path
tree SPT
When a PIMsp eaking router on a shared tree whic hhas
directlyconnected mem b ers w an ts to join the group with
shortest paths the router notices data pac k ets for G that are
sourced b y an address Sn for whic h it do es not ha veam ulti
cast forw arding en try SnG As sho wn in gure router A
initiates a new m ulticast forw arding en try for SnG with
SPT bit cleared indicating that the shortest path tree branc h
from Sn has not b een completely setup and in the mean
time it still uses the shared tree to get pac k ets from Sn A
timer is set for the SnG en try A PIM join message will b e sen t upstream to the b est
next hop to w ard the new source Sn with Sn in the join list
MulticastaddressG PIMjoin fSng PIMpruneNULL
When a router whic h has a SnG en try with SPT bit
cleared starts to receiv epac k ets from the new source Sn on
the in terface used to reac h Sn it sets the SPT bit and sends
Figure Example Switc hing from shared tree to shortest path tree
Actions are n um b ered in the order they o ccur
a PIM prune to w ard RP if its shared tree incoming in terface
diers from its shortest path tree incoming in terface indi
cating that it no longer w an ts to receiv e pac k ets from Sn via
RP In the PIM message to w ard RP it includes Sn in the
prune list with RP bit set indicating that a negativ e cac he
should b e set up on the w aytoRP When the SnG en try is created the outgoing in terface
list is copied from G ie all lo cal shared tree branc hes
are replicated in the new shortest path tree In this w a y
when a data pac k et from Sn arriv es and matc hes on this
en try all receiv ers will con tin ue to receiv e source pac k ets
along this path unless and un til the receiv ers c ho ose to prune
themselv es
Note that a DR ma y adopt a p olicy of not setting up
an SG en try and therefore not sending a PIM join mes
sage to w ard the source un til it has receiv ed m data pac k ets
from the source within some in terv al of n seconds This
w ould eliminate the o v erhead of sending SG state up
stream when small n um b ers of pac k ets are sen t sp oradicall y Ho w ev er data pac k ets distributed in this manner maybe
deliv ered o v er the sub optimal paths of the shared RP tree
The DR ma y also c ho ose to remain on the RP
distribution tree indenitely instead of mo ving to the short
est path tree
Steady state maintenance of router state
In the steady state eac h router sends p erio dic refreshes of
PIM messages upstream to eac h of the next hop routers that
is en route to eac h source S for whic h ithas am ulticast
forw arding en try SG as w ell as for the RP listed in the
G en try These messages are sen t p erio dical ly to capture
A negativ e cac he en try is a SG en try on the RP tree The
RP bit is set indicating that the asso ciated prune messages should
b e sen t up the shared tree to w ard the RP In addition the outgoing
in terface from whic h it receiv es a PIM prune message with SG and
the RP bit in the prune list is deleted from the outgoing in terface
list Data pac k ets matc hing the negativecac he are not senttothat
in terface
state top ology and mem b ership c hanges A PIM message
is also sentonan ev en ttriggered basis eac htimea new
forw arding en try is established for some new SnG note
that some damping function ma y b e applied eg a merge
time Optionally the PIM message could con tain only the
incremen tal information ab out the new source The deliv ery
of PIM messages do es not dep end on p ositiveac kno wledge
men t lost pac k ets will b e reco v ered from at the next p erio dic
refresh time
Multicast data pack et p ro cessing
Data pac k ets are pro cessed in a manner similar to exist
ing m ulticast sc hemes An incoming in terface c heckis per formed and if it fails the pac k et is dropp ed otherwise the
pac k et is forw arded to all the in terfaces listed in the outgo
ing in terface list whose timers ha v e not expired There are
t w o exception actions that are in tro duced if pac k ets are to
b e deliv ered con tin uouslyev en during the transition from
a shared to shortest path tree First when a data pac k et
matc hes on an SG en try with a cleared SPT bit if the
pac k et do es not matc h the incoming in terface for that en try then the pac k et is forw arded according to the G en try
ie it is sen t to the outgoing in terfaces listed in G if the
incoming in terface matc hes that of the G In addition
when a data pac k et matc hes on an SG en try with a cleared
SPT bit and the incoming in terface of the pac k et matc hes
that of the SG en try then the pac k et is forw arded and
the SPT bit is set for that en try Data pac k ets nev er trigger prunes Data pac k ets ma y
trigger actions whic h in turn trigger prunes In particular
data pac k ets from a new source can trigger creation of a new
SG forw arding en try This causes S to b e included in the
prune list in a triggered PIM messages to w ard the RP just
as it causes S to b e included in the join list in a triggered
PIM message to w ard the source
Timers
A timer is main tained for eac h outgoing in terface listed in
eac h SG or G en try The timer is set when the in
terface is added The timer is reset eac htimeaPIM join
message is receiv ed on that in terface for that forw arding en
try ie SG or G
When a timer expires the corresp onding outgoing in ter
face is deleted from the outgoing in terface list When the
outgoing in terface list is n ull a prune message is sentup stream and the en try is deleted after times the refresh
p erio d
PIMsp eaking routers on multiaccess subnet w o rks
Certain m ultiaccess subnet w ork congurations require sp e
cial consideration When a LANconnected router receiv es
a prune from the LAN it m ust detect whether there remain
other do wnstream routers with activedo wnstream mem bers The follo wing proto col is used when a router whose incom
ing in terface is the LAN has all of its outgoing in terfaces
go to n ull the router m ulticasts a prune message for SG
on to the LAN All other routers hear this prune and if there
is an y router that has the LAN as its incoming in terface for
the same SG and has nonn ull outgoing in terface list then
the router sends a join message on to the LAN to o v erride
the prune The join and prune should go to single upstream
router that is the righ t previous hop to the source or RP
ho w ev er at the same time w ew an t others to hear the join
and prune so that they suppress their o wn joinsprunes or
o v erride the prune F or this reason the join is senttoaspe cial m ulticast address whic h all routers on the same LAN
and only those on the same LAN are mem b ers

with
the IP address of the previous hop in the IGMP header
Unicast routing changes
When unicast routing c hanges an RPF c hec k is done and all
aected m ulticast forw arding en tries are up dated In partic
ular if the new incoming in terface app ears in the outgoing
in terface list it is deleted from the outgoing list
The PIMsp eaking router sends a PIM join message out
its new in terface to inform upstream routers that it exp ects
m ulticast datagrams o v er the in terface It sends a PIM
prune message out the old in terface if the link is op erational
to inform upstream routers that this part of the distribution
tree is going a w a y Multiple rendezvous p oints and RP failure scena rios
If there is one RP then there is no concern ab out sources
and receiv ers actually b eing able to rendezv ous but there is
a reliabili t y issue
When a timer is reset for an outgoing in terface listed in G
en tryw e should also reset the in terface timers for all SG en tries
whic h con tain that in terface in their outgoing in terface list Because
some of the outgoing in terfaces in SG en try are copied from G
outgoing in terface list they ma y not ha v e explicit join messages from
the do wnstream routers
Negativ e cac he en tries on the RP tree m ust b e k ept aliveb y re
ceipt of Prunes W e do not w an t to delete suchen tries if G en try
exists otherwise data pac k ets will tra v el do wn b oth RP tree and
SPT It ma y not result in p erio dic duplicates b ecause of the RPF
c hec k but it do es w aste a lot of net w ork bandwidth
see this address is also used b y routers to send
PIM query pac k ets to neigh b or routers on the same LAN
Unreac hable RPs are detected using the RP reac habil
it y message When a G en try is established b y a router
with lo cal mem b ers a timer is set The timer is reset eac h
time an RP reac habilit y message is receiv ed If this timer
expires the router lo oks up an alternate RP for the group
sends a join to w ard the new RP A new G en try is estab
lished with the incoming in terface set to the in terface used
to reac h the new RP The outgoing in terface list includes
only those in terfaces on whic h IGMP Rep orts for the group
w ere receiv ed
When m ultiple RPs are used eac h source registers and
sends data pac k ets to w ard eac h of the RPs but receiv ers
only join to w ard a single RP If one of the RPs fails receiv ers
that joined that RP will stop receiving RP reac habilitymes sages and will start sending joins to one of the alternativ e
RPs Sources do not need to tak e sp ecial action
Summa ry
In summary once the PIM join messages ha v e propagated
upstream from the RP data pac k ets from the source will fol
lo w the SG distributio n path established The pac k ets will
tra v el to the receiv ers via the distribution paths established
b y the PIM join messages sen t upstream from receiv ers to
w ard the RP Multicast pac k ets will arriv e at some receiv ers
b efore reac hing the RP if the receiv ers and the source are
b oth upstream to the RP When the receiv ers initiate shortestpath distribution additional outgoing in terfaces will b e added to the SG
en try and the data pac k ets will b e deliv ered via the shortest
paths to receiv ers
Data pac k ets will con tin ue to tra v el from the source to
the RPs in order to reac h new receiv ers Similarlyre ceiv ers con tin ue to receiv e some data pac k ets via the RP
tree in order to pic k up new senders Ho w ev er when source
sp ecic distribution is used most data pac k ets will arriveat
receiv ers o v er a shortest path tree
Op en Issues
Before concluding w e discuss sev eral op en issues that require
further researc h engineering or exp erimen tal atten tion
In terop eration with dense mo de net w orks re
gions
Anet w ork or collection of net w orks should b e able to
c ho ose whether to use sparse mo de PIM as describ ed
here or dense mo de m ulticast to join a distribution
tree dep ending on the densit y of the group mem ber ships in that region or on the scarcit ya v ailab il i tyof
bandwidth

Links should b e congurable to op erate
in dense mo de or in sparse mo de If the group mem
b ership densit y is high or bandwidth is plen tiful then it
is ecien ttouse rev erse path m ulticasting RPM or
o o d mem b ership rep orts since in general most links
will b e on a path from some source to some destination
F or example an exp ensiv eW AN link or in terdomain
link may b e congured as default sparsemo de Most
in tradomain or in tracampus links will probably b e
congured as default densemo de

F or this reason weha v e also dev elop ed a dense mo de m ulticast
sc heme that uses D VMRPlik e RPF but that is unicast routing pro
to col indep enden t
The primary issue in splicing dense mo de regions on to
a distributio n tree comprised in whole or part of
sparse mo de regions is the incompatabil i tybet w een
the data driv en nature of dense mo de and the explicit
join nature of sparse mo de In other w ords the rst
group mem b er in a dense mo de region needs to ha v e
some w a y of initial ly pulling do wn the data pac k ets
from or through an upstream sparse mo de region
Normally data pac k ets emanating from or tra v eling
through a sparse mo de region w ould not b e sentto
the dense mo de region without explicit joins W eare
w orking on a mec hanism to address this problem that
relies on getting the group mem b er existence informa
tion to the b order routers and ha ving b order routers
send explicit joins
A second issue in splicing these IP clouds on to PIM
trees is iden tifying whic h b order router for the IP cloud
should b e the en try p oin t for data pac k ets from a par
ticular source and therefore whic h sources individu al
b order routers should put in their join and prune lists
This is analogous to the LAN case when there is more
than one router serving it The designated router is
the one that tak es resp onsibili t y for serving the mem
b ers on the LAN
Aggregation of information in PIM
There are sev eral motiv ations for aggregating source
information b ey ond the subnet lev el supp orted in the
curren t sp ecication the most imp ortan t issues are
PIM message size and the amoun t of memory used for
routing forw arding en tries
One migh t consider using the highest lev el aggregate
a v ailable for an address when setting up the m ulticast
forw arding en try This is optimal with resp ect to for
w arding en try space It is also optimal with resp ect to
PIM message size Ho w ev er PIM messages will carry
v ery coarse information and when the messages arriv e
at routers closer to the sources where more sp ecic
routes exist there will b e a large fanout and PIM mes
sages will tra v el to w ard all mem b ers of the aggregate
whichw ould b e inecien t in mostman y cases
If PIM is b eing used for in terdomain routing and
routers are able to map from IP address to domain
iden tier then one p ossibil it y is to use the domain
lev el aggregate for a source in PIM messages au
tonomous system AS n um b ers or routing domain
iden tiers RDIs Then the PIM message will tra v el
to the b or der r outers BR of the domain and the
BRs can use the in ternal m ulticast proto cols mec ha
nism for propagating the join within the domain eg
send appropriate linkstate adv ertisemen t in MOSPF
or register a lo cal mem b er and do not prune in the
case of RPF Ho w ev er this approac h requires that it
is b oth p ossible and ecien t to map from IP to do
main address when pro cessing data pac k ets as w ell as
con trol pac k ets
Another p ossibil ity istouse pro xies as suggested b y
V Jacobson In this case within PIM clouds PIM
messages need only refer to pro xies for sources outside
the cloud In this sc heme BRs w ould join a PIM tree
externally and inject themselv es as sources in ternally When data pac k ets arriv ed the data pac k et w ould b e
forw arded in to the cloud and routers w ould see a new
source They w ould then need to determine whichis
the en try BR for the particular source and forw ard the
pac k et on the m ulticast tree asso ciated with that BR
The router could cac he a forw arding en try for the new
source in order to a v oid rep eating this step on eac h
data pac k et This tec hnique is curren tly b eing dev el
op ed and w ould b e deplo y able as an addition to the
curren t proto col without aecting the proto col sp eci
cation
In the absence of aggregation or pro xy tec hniques
when the n um b er of sources get to some threshold
v alue to b e determined receiv ers could compromise
the qualit y of the distribution tree in exc hange for
accommo dating large n um bers of unaggregatable
sources
As the n um b er of groups gro ws verylargeitma ybe
necessary to allo w aggregation of state across groups
whereas th us far weha v e only addressed aggregation
across sources Tw o of the authors Deering and Ja
cobson ha v e prop osed creating default S en tries to
address this problem
Selecting and iden tifyin g RPs
An RP for a particular m ulticast group can b e an y
IPaddressable en tityinthe in ternet Ho w ev er it is
most ecien t and con v enien t for the RP to b e the
directlyconnected PIMsp eaking router of one of the
mem b ers of the group If an RP has lo cal mem bers of
the group then there is no w asted o v erhead asso ciated
with sources con tin ually sending their data pac k ets to
the RP since it needed to b e deliv ered there an yw ayfor
deliv ery to those mem b ers Nev ertheless w e need not
be o v erly concerned with placemen t of the RPs when
shortest path trees are used b ecause the RP will not
remain on the distribution path for most receiv ers un
less it also happ ens to b e on the SPT The RP address
can b e congured or can b e dynamicall y disco v ered b y
mapping from the m ulticast address query of a direc
tory service or from information obtained via some
new PIM RPrep ort messages The mapping of G to
RP addresses should b e cac hed
In teraction with p olicybased and QOS routing
PIM messages and data pac k ets ma y tra v el o v er p olicy
constrained routes to the same exten t that unicast
routing do es so long as the p olicy do es not prohibit
this trac explicitl y T o obtain p olicysensi ti v e distributio n of m ulticast
pac k ets w e need to consider the paths c hosen for for
w arding PIM join and register messages
If the path to reac h the RP or some source is indi
cated as b eing the appropriate QOS and indicated as
b eing symmetric then PIMsp eaking routers can de
termine that if they forw ard joins upstream that the
data pac k ets will allo w ed to tra v el do wnstream This
implies that BGPIDRP should carry t w o QOS
ags symmetry ag and m ulticast willing ag
If the generic route computed b y hopb yhop routing
do es not ha v e the symmetry and m ulticast bits set
but there is an SDRP route that do es then the
PIM message should b e sentwith an em b edded SDRP
route This option needs to b e added to PIM join
messages Its absence will indicate forw arding accord
ing to the routers unicast routing table Its presence
will indicate forw arding according to the SDRP route
This implies that SDRP should also carry symmetry
and m ulticast QOS bits and that PIM should carry
an optional SDRP route inside of it to cause the PIM
message and the m ulticast forw arding state to o ccur
on an alternativ e distributio n tree branc h
In teraction with receiv er initiated reserv ation
setup suc h as RSVP Once the shortest path distributi on tree has b een es
tablished RSVP reserv ation messages followthe re v erse of senders path messages and the senders path
messages will tra v el according to the state that PIM
installs Ho w ev er one w an ts to a v oid switc hing
reserv ationorien ted routes so the receiv er could ini
tially receiv e all pac k ets via the RP distribution tree
and after some dela y it could send PIM messages to es
tablish the shortest path tree and then establish reser
v ations o v er that tree The sources path message
w ould tra v el rst via the RP path then to a v oid set
ting up a reserv ation on the RP path the receiv er
w ould send its PIM join messages to w ard source b e
for e it sends out its reserv ation message and w ait for
another path message to tra v el o v er the new shortest
path
In summary w e exp ect that this receiv er initiated rout
ing is w ell suited to receiv er initiated reserv ations since
if a reserv ation is blo c k ed the previous router or the
receiv er can select an alternativerev erse path to the
particular sources This is also a sub ject for future
w ork that will aect the use of the proto col and not
the proto col itself
Conclusions
Weha v e presen ted a solution to the problem of routing m ul
ticast pac k ets in large wide area in ternets Our approac h uses constrained receiv erinitia ted mem b ership adv ertise
men t for sparsely distributed m ulticast groups supp orts
b oth shared and shortest path tree t yp es in one proto col do es not dep end on the underlying unicast proto cols and
uses soft state mec hanisms to reliably and resp onsiv ely
main tain m ulticast trees The arc hitecture accommo dates
graceful and ecien t adaptation to v arying t yp es of m ulti
cast groups and to dieren tnet w ork conditions
A proto col implemen tation of PIM using extensions to
existing IGMP message t yp es is in progress Sim ulation and
implemen tation eorts are underw aytoc haracterize cong
uration criteria and deplo ymen t issues
Due to the complexit y of the en vironmen ts PIM exp ects
to op erate in there are still sev eral issues not completely re
solv ed Solutions to some of the issues require co ordination
with eorts in other areas suc has in terdomain routing and
resource reserv ation proto cols
References
S Deering and D Cheriton Multicast routing in data
gram in ternet w orks and extended LANs A CM T r ans
actions on Computer Systems pages Ma y S Deering Multic ast R outing in a Datagr am Internet
work PhD thesis Stanford Univ ersit y J Mo y Multicast extension to OSPF Internet Dr aft Septem b er D W aitzman C P artridge and S Deering Distance
v ector m ulticast routing proto col No v em b er RF C
S Deering Host extensions for IP m ulticasting August
RF C
J Mo yOSPF v ersion Octob er RF C
J Mo y MOSPF Analysis and exp erience Internet
Dr aft July Y K Dalal and R M Metcalfe Rev erse path forw ard
ing of broadcast pac k ets Communic ations of the A CM R F rederic k IETF audio ! video cast Internet So ciety
News A J Ballardie P FF rancis and J Cro w croft Core
based trees In Pr o c e e dings of the A CM SIGCOMM San F rancisco Da vid W all Me chanisms for Br o adc ast and Sele ctive
Br o adc ast PhD thesis Stanford Univ ersit y June T ec hnical Rep ort N L W ei and D Estrin A comparison of m ulticast trees
and algorithms T ec hnical Rep ort USCCS
Computer Science Departmen t Univ ersit y of Southern
California Septem b er S Deering D Estrin D F arinacci and V Jacobson
IGMP router extensions for routing to dense m ulticast
groups Internet Dr aft Octob er S Deering D Estrin D F arinacci and V Jacobson
IGMP router extensions for routing to sparse m ulticast
groups Internet Dr aft Octob er Y Rekh ter and T Li editors A b order gatew a y
proto col BGP Internet Dr aftJan uary S Hares and John Scudder IDRP for IP Internet
Dr aft Septem b er D Estrin T Li Y Rekh ter and D Zappala Source
demand routing proto col P ac k et format and forw ard
ing sp ecication InternetDr aft Marc h
L Zhang R Braden D Estrin S Herzog and
S Jamin Resource reserv ation protocol RSVP v er
sion functional sp ecication InternetDr aftOctober

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 608 (1995)

PDF

USC Computer Science Technical Reports, no. 599 (1995)

PDF

USC Computer Science Technical Reports, no. 656 (1997)

PDF

USC Computer Science Technical Reports, no. 530 (1992)

PDF

USC Computer Science Technical Reports, no. 613 (1995)

PDF

USC Computer Science Technical Reports, no. 560 (1993)

PDF

USC Computer Science Technical Reports, no. 648 (1997)

PDF

USC Computer Science Technical Reports, no. 657 (1997)

PDF

USC Computer Science Technical Reports, no. 655 (1997)

PDF

USC Computer Science Technical Reports, no. 673 (1998)

PDF

USC Computer Science Technical Reports, no. 674 (1998)

PDF

USC Computer Science Technical Reports, no. 690 (1998)

PDF

USC Computer Science Technical Reports, no. 644 (1997)

PDF

USC Computer Science Technical Reports, no. 727 (2000)

PDF

USC Computer Science Technical Reports, no. 603 (1995)

PDF

USC Computer Science Technical Reports, no. 640 (1996)

PDF

USC Computer Science Technical Reports, no. 631 (1996)

PDF

USC Computer Science Technical Reports, no. 606 (1995)

PDF

USC Computer Science Technical Reports, no. 667 (1998)

PDF

USC Computer Science Technical Reports, no. 697 (1999)

Description

Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ching-gung Liu, and Liming Wei. "An architecture for wide-area multicast routing." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 565 (1994).

Asset Metadata

Creator Deering, Stephen (author), Estrin, Deborah (author), Farinacci, Dino (author), Jacobson, Van (author), Liu, Ching-Gung (author), Wei, Liming (author)

Core Title USC Computer Science Technical Reports, no. 565 (1994)

Alternative Title An architecture for wide-area 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 10 pages (extent), technical reports (aat)

Language English

Unique identifier UC16269928

Identifier 94-565 An Architecture for Wide-Area Multicast Routing (filename)

Legacy Identifier usc-cstr-94-565

Format 10 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

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

Description Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.

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)