Computer Science Technical Report Archive

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

(USC DC Other)

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

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content Proto col Indep enden t Multicast PIM Motiv ation and Arc hitecture
Stephen Deering
XeroxP AR C
Co y ot y Hill Road
P alo Alto CA deeringparcxero xcom
Deb orah Estrin
Computer Science Departmen tISI
Univ ersit y of Southern California
Los Angeles CA estrinuscedu
Dino F arinacci
Cisco Systems Inc
W est T asman Driv e
San Jose CA dinociscocom
V an Jacobson
La wrence Berk eley Lab oratory
Cyclotron Road
Berk eley CA v aneelblgo v
Chinggung Liu
Computer Science Departmen t
Univ ersit y of Southern California
Los Angeles CA c harleycatarinauscedu
Liming W ei
Computer Science Departmen t
Univ ersit y of Southern California
Los Angeles CA lw eicatarinauscedu
draftietfidmrpimarc hps
Jan uary Status of This Memo
This do cumentis anIn ternet Draft In ternet Drafts are w orking do cumen ts of the In ternet Engineering T ask
F orce IETF its Areas and its W orking Groups Note that other groups ma y also distribute w orking do cumen ts
as In ternet Drafts
In ternet Drafts are draft do cumen ts v alid for a maxim um of six mon ths In ternet Drafts ma y b e up dated
replaced or obsoleted b y other do cumen ts at an y time It is not appropriate to use In ternet Drafts as reference
material or to cite them other than as a w orking draft or w ork in progress
Please c hec k the ID abstract listing con tained in eachIn ternet Draft directory to learn the curren t status of
this or an y other In ternet Draft
Editors Note
This do cumen t has b een mo died signican tly since the Marc h v ersion In particular w e
In tegrated Dense Mo de PIM description and explanation of SMDM PIM in teraction
Extended discussion of PIMnonPIM in teraction
Revised and extended discussion of scaling in terms of state and con trol trac
Giv en the length of this author list it seems appropriate to iden tify the roles pla y ed byeac h of the authors who are
listed in alphab etical order Jacobson prop osed the original idea of sending join messages to w ards disco v ered sources as
a means 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 Liu iden tied and xed man y critical proto col bugs as part
of his implemen tation eort and W ei pro vided data to supp ort the need for shortestpath distribution trees SPT and
con tributed to proto col dev elopmen t as part of his sim ulation eort Estrin Liu and W ei w ere supp orted b y gran ts from
the National Science F oundation and Sun Microsystems
draftietfidmrpimarc hps Abstract
Existing m ulticast routing mec hanisms w ere in tended for use within regions where a group is
widely represen ted or bandwidth 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 p erio dically sento v er man y links that do not lead to
receiv ers or senders resp ectiv elyThis c haracteristic lead us to dev elop a m ulticast routing arc hitecture
that ecien tly establishes distribution trees across widearea in ternets where man y groups will b e
sparsely represen ted and where bandwidth is not uniformly plen tiful due to the distances and m ultiple
administrations tra v ersed Eciency is ev aluated 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 The arc hitecture also includes a more traditional dense mo de of op eration for
use within campus net w orks or other regions c haracterized b y plen tiful bandwidth
The Proto col Indep enden t Multicast PIM arc hitecture
a main tains the traditional IP m ulticast service mo del of receiv erinitiated mem b ership
b can b e congured to adapt to dieren tm ulticast group and net w ork c haracteristics
c is not dep enden t on a sp ecic unicast routing proto col and
d uses softstate mec hanisms to adapt to underlying net w ork conditions and group dynamics
The robustness exibilit y and scaling prop erties of this arc hitecture makeit w ell suited to large
heterogeneous in ternet w orks
This do cumentmotiv ates and describ es the PIM arc hitecture A companion do cumen t describ es
the proto col mec hanisms for b oth sparse and dense mo des PIM
draftietfidmrpimarc hps In tro duction
This do cumen t describ es an arc hitecture for ecien tly routing to m ulticast groups that ma y span wide
area and in terdomain in ternets W e refer to the approac h as Proto col Indep enden t Multicast PIM
b ecause it is not dep endenton an y particular unicast routing proto col
The most signican t inno v ation in this arc hitecture is the ecien t supp ort of sparse wide area groups
This sp arse mo de SM of op eration complemen ts the traditional densemo de approachto m ulticast
routing for campus net w orks as dev elop ed b y Deering and implemen ted previously in MOSPF and
D VMRP These traditional dense mo de m ulticast sc hemes w ere in tended for use within regions
where a group is widely represen ted or bandwidth is univ ersally plen tiful Ho w ev er when group mem bers 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 in the case of D VMRP or mem b ership rep ort information in the case of MOSPF
are o ccasionally 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 dev elop a m ulticast routing arc hitecture that ecien tly establishes distribution trees
ev en when some or all mem b ers are sparsely distributed Eciency is ev aluated in terms of the state
con trol message and data pac k et o v erhead 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
Denition of terms
Asserts The pro cess of c ho osing whichrouterwill forw ard a m ulticast pac k et from a particular source
on to a LAN segmen t when there are m ultiple routers on that LAN segmen t with routes to the
source
Dense Groups Group mem b ership that is plen tiful within a region of an in ternet
Densemo de DM A generic term referring to a m ulticast routing proto col that is optimized for dense
groups Densemo de PIM is an example of suc h a proto col
Designated Router DR The highest IP addressed router on a m ultiaccess net w ork b ecomes the
DR It is resp onsible for sending IGMP Query pac k ets to the LAN and for sending PIM Register
pac k ets and PIM Join pac k ets to w ards the RP DRs need to kno w the list of RP addresses for
a sparsemo de group
Grafts Grafts are used b y new mem b ers to add themselv es on to an existing distribution tree when a
system b ecomes a mem b er of a group Grafts are used to undo pruned tree branc hes and are sen t
to w ards kno wn sources for densemo de groups They are ac kno wledged hopb yhop with GraftAc k
pac k ets
Joins Joins are sentto ward theRPor to w ard a source to create or refresh a branc h ofam ulticast
distribution tree Joins are transmitted p erio dically Lasthop Routers A lasthop router is one that is directly connected to mem b ers of a group Lasthop
routers need to kno w the list of RP addresses for a sparsemo de group
Mem ber A system that desires to receivem ulticast datagrams for a group This system need not b e a
sender to the group A Mem ber is synon ymously called a R e c eiver Prunes Prunes are sentto w ard a source b y a router when it wishes to lea v e the distribution tree In
sparsemo de prunes are also sen tto w ard the RP when a router switc hes from the RP tree to the
sourcero oted shortest path tree
draftietfidmrpimarc hps Rendezv ous P oin t RP An RP is used for groups that op erate in sparsemo de It is a router that
rendezv ous receiv ers and senders for a group There ma y b e more than one RP p er group A
router ma y b e the RP for m ultiple groups
Registers A metho d for new sources to b e kno wn to the RP and for existing sources to learn ab out
new receiv ers Registers start the pro cess to create m ulticast routing state in routers b et w een the
source and RP Rev erse P ath F orw arding RPF The algorithm used to pro vide lo opfree deliv ery of m ulticast data
grams on a distribution tree The RPF in terface is the exp ected in terface to receivem ulticast pac k ets
from a source The RPF in terface is also the in terface used to send unicast pac k ets to the source
Source A system that sends m ulticast datagrams to a group A Source is not required to b e a mem ber A Source is synon ymously called a Sender
SG state Pronounced S comma G it is the m ulticast routing table state a router has for a shortest
path tree ro oted at the source The incoming in terface for this en try is the RPF in terface to S
There is a SG for eac h source sending to eac h group
S state Pronounced S comma star it is a m ulticast routing table state a router has for eac h source
sending to an y group The incoming in terface for this en try is the RPF in terface to S
Shared T ree RP tree The set of paths connecting all receiv ers of a group to its RP is the RP tree
A receiv er on the RP tree receiv es pac k ets from all sources of the group except those sources that
w ere pruned o the RP tree
ShortestP ath T ree SPT A shortestpath tree ro oted from the source is kno w as the SPT Eac h
source sending to a group has a distinct tree
Sparse Groups Group mem b ership that is spread out across regions of an in ternet This do es not imply
that the group has a few n um ber of mem bers Sparsemo de SM A generic term referring to a m ulticast proto col that is optimized for sparse groups
Sparsemo de PIM and CBT are examples of suc h proto cols
G state Pronounced star comma G it is the m ulticast routing table state a router has for the RP
tree The incoming in terface for this en try is the RPF in terface to the RP for sparsemo de groups
There is one G for eac h group
Bac kground
In the traditional densemo de IP m ulticast mo del established b y Deering 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 reac h all mem b ers of the group The separation of senders and
receiv ers allo ws an y host mem b er or nonmem b er to 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 ecomes more
lik ely that a new receiv er will b e able to splice on to a nearbybranc 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 RIPlik e distancev ector unicast proto col or MOSPF an extension 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
draftietfidmrpimarc hps In the case of linkstate proto cols c hanges of group mem b ership on a subnet w ork are detected byone
of the routers directly attac hed to that subnet w ork and that router broadcasts 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 routing proto col Up on receiving a m ulticast data pac k et the
router uses the top ology information and the group mem b ership information to determine the shortest
path tree SPT from the pac k ets source subnet w ork to its destination group 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 orks ev ery router m ust receiv e and store mem b ership information for ev ery group in
the domain The other ma jor factor is the pro cessing cost of the Dijkstra shortestpathtree calculations
p erformed to compute the deliv ery trees for all activem ulticast sources for all groups th us limiting
its applicabilityon an in ternetwide 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 RPF 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 also kno wn
as 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 erse P ath F orw arding When a router attac hed to a leaf subnet w ork receiv es a data pac k et
addressed to a new group if it nds no mem b ers presen t on its attac hed subnet w orks it will send a prune
message upstream to w ards the source of the data pac k et The prune messages prune the tree branc hes
not leading to group mem b ers th us resulting in a sourcesp ecic shortestpath tree with all lea v es ha ving
mem b ers Pruned branc hes will gro w bac 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 destina
tions ha ving group mem b ers of an y particular widear e a group is lik ely to b e small More imp ortan tly bandwidth limitations and therefore data and con trol message o v erhead should not b e ignored in a wide
area con text 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 connected b y the MBONE Ho w ev er its o ccasional broad
casting b eha vior sev erely limits its capabilit y to scale to larger net w orks supp orting m uchlarger n um bers
of groups man y of whic h are sparse
Extending m ulticast to the wide area 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 ev aluated in terms of resources consumed in routers and links ie state pro cessing and
bandwidth
Existing densemo de linkstate and distancev ector m ulticast routing sc hemes ha v e go o d scaling prop
erties only when m ulticast groups densely p opulate the net w ork of in terest or when the o v erhead of dense
mo de op eration is negligible relativ e to the net w ork resources When most of the subnets 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 broadcast
ing mem b ership rep orts linkstate or data pac k ets distancev ector is w arran ted since the information
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
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
trackofc hildparen t information
Figure Example of Multicast T rees
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 m ultiadministratio n in ternet w orks where resources m ust b e
used more conserv ativ ely Ov erhead and tree t yp es
The examples in Figure illustrate the inadequacies of densemo de mec hanisms when supp orting sparse
wide area groups There are three domains that comm unicate via an in ternet There is a mem ber 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 distribution tree will stabilize to that illustrated with b old lines in Figure b Ho w ev er p erio dically the sources pac k ets will b e broadcast throughout the en tire in ternet when the prunedo branc hes times
out
Th us far weha v e motiv ated our design bycon trasting it to the traditional densemo de IP m ulticast
routing proto cols More recen tly the Core Based T ree CBT proto col w as prop osed to address
similar scaling problems in supp ort of sparsemo de m ulticast 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 Figure 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 sources trac on the
path indicated with b old lines W e refer to this as tr ac c onc entr ation 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 hhe called a c enterb ase d
tree is times the shortestpath dela yT o get a b etter understanding of howw 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 ber of
dieren t random graphs W e measured the maxim um dela y within eac h group and exp erimen ted with
graphs of dieren t no de degrees W e sho w the ratio of the CBT maxim um delayv ersus shortestpath
draftietfidmrpimarc hps 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
tree maxim um dela y in Figure a F or eac h no de degree w e tried dieren t no de graphs with
mem b er groups c hosen randomly It can b e seen that the maxim um dela ys of corebased trees with
optimal core placemen t are around to that of the shortestpath trees
F or in teractiv e applications 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 problem 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
whichmem b ers 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
Figure 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 adv 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 sit
uations F or example shared tress ma y p erform v ery w ell for large n um bers of lo w data rate sources
eg resource disco v ery applications 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 supp ort b oth t yp es of trees within one m ulti
cast 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 addressed 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 d qualit y distribution trees for heterogeneous applications
In PIM a m ulticast group can c ho ose to use shortestpath trees or a groupshared tree The lasthop
routers of the receiv ers can mak e this decision indep enden tly A receiv er could ev en c ho ose dieren tt yp es
of trees for dieren t sources
The capabilit y to supp ort dieren t tree t yp es is the fundamen tal dierence b et w een PIM and CBT
Note that although some error bars in the dela y graph extend b elo w there are no real data p oin ts b elow the
distribution is not symmetric for more details see A more complete analysis of these tradeos can b e found in
draftietfidmrpimarc hps There are other signican t proto col engineering dierences as w ell the most signican t of whic h is PIMs
use of soft state reliabilitymec hanisms 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 uses p erio dic refreshes as its primary
means of reliabilit y This approac h reduces the complexit y of the proto col and co versawiderange
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
In tegrated densemo de and sparsemo de proto col
While this new arc hitecture w as motiv ated primarily b y the need for sparsemo de functionalit y it also
sp ecies a new densemo de proto col instead of relying on existing densemo de proto cols suc hasD VMRP
and MOSPF PIMDense Mo de PIMDM is similar in b eha vior to D VMRP in that it relies on a form
of Rev erse P ath F orw arding Ho w ev er PIMDM has t w o imp ortan t dierences
PIMDM mak es use of unicast routing tables indep enden t of the proto col that created them
D VMRP carries around its o wn unicast routing information and mak es use of a RIPlik e proto col to compute needed unicast routing information as a result it has the scaling limitations of
RIP and do es not takeadv an tage of information and computation already b eing carried out bythe
net w orks unicast routing proto col MOSPF do es tak eadv an tage of the unicast routing proto col
but it is sp ecic to that one proto col OSPF PIMDM con trol message pro cessing and data pac k et forw arding is in tegrated with PIMSM op er
ations so that a single router can run dieren t mo des for dieren t groups
Note that while weha vedev elop ed a new densemo de proto col to accompan y PIMSM w e also
recognize and address the need for in terop erabilit y with existing densemo de proto cols
Do cumen t organization
In the remainder of this do cumentween umerate the sp ecic design requiremen ts for widearea m ulti
cast routing section summarize the arc hitectural comp onen ts and functions section en umerate
sev eral proto col engineering c hoices made in the design of PIM proto cols section consider the use of
aggregation to address the scalabilit y problem section and discuss op en issues section Proto col
details can b e found in
Requiremen ts
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 ber of net w orksdomains with group mem b ers presen t is signican tly smaller than
n um ber of net w orksdomains 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 sucien tly resource ric h to ignore the o v erhead
of currentsc hemes
Sparse groups are not necessarily small therefore w em ust supp ort dynamic groups with large
n um b ers of receiv ers
draftietfidmrpimarc hps HighQualit y Data Distribution
W e wish to supp ort lo wdela y data distribution when needed b y the application In particular
wea v oid imp osing a single shared tree in whic h data pac k ets are forw arded to receiv ers along a
common tree indep enden 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 shortestpath tree SPTs are signif
ican 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 This indep endence has
another adv an tage that the m ulticast domain b oundaries do not ha v e to map directly to unicast
domain b oundaries This allo ws net w ork designers to takein to consideration the m ulticast require
men ts and not to b e burdened with unicast top ology restrictions W e accomplish this b y letting
the m ulticast proto col mak e use of the unicast routing tables indep enden tof ho w those tables are
computed
Accommo date Dense Mo de Beha vior
F or those groups whose mem b ers and sources reside completeley within a con tained campus net w ork
or region w e wish to op erate in a mo de that is more similar to traditional IP m ulticast ie data
driv en state creation with implicit joining and explicit pruning default to send
In terop erabilit y
W e require in terop erabilit y with traditional RPF and linkstate m ulticast routing b oth in tra
domain and in terdomain F or example the in tradomain p ortion of a distribution tree ma ybe
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 to
in terop erate with some in tradomain routing proto cols
In supp ort of this in terop eration with existing IP m ulticast and in supp ort of groups with v ery
large n um b ers of receiv ers w e should main tain the logical separation 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 hievethisb y
a using soft state refreshmentmec 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
Scalabilit y
W e pro vide mec hanisms for scaling with group and net w ork size These mec hanisms address the
forms of o v erhead con trol messages and state Bandwidth consumed b y data pac k ets is already
minimized through the use of explicitjoin sparse mo de Con trol message o v erhead is limited to a
draftietfidmrpimarc hps xed p ercen tage of the link bandwidth b y adjusting the frequency of p erio dic messages on a link
b y link basis
State o v erhead is managed in sucha w a y that eac h router can unilaterally c ho ose its o wn tradeo
pointbet w een the amoun t of state main tained and the amoun t of bandwidth consumed b y unneeded
o o ding of m ulticast pac k ets
PIM Comp onen ts and F unctions Ov erview
In this section w e describ e the arc hitectural comp onen ts of PIM F or clarit yw e describ e the general
b eha vior of PIMDense Mo de and PIMSparse Mo de separately Ho w ev er the detailed proto col mec ha
nisms dev elop ed to realize sparse and dense mo de functionalit y are describ ed in an in tegrated manner in
PIMDense Mo de PIMDM
Densemo de PIM uses Rev erse P ath Multicasting RPM RPM is a tec hnique in whicham ulticast
datagram is forw arded if the receiving in terface is one used to forw ard unicast datagrams to the source
of the datagram The m ulticast datagram is then forw arded out all other in terfaces Densemo de PIM
builds sourcebased acyclic trees
Densemo de PIM is data driv en a no de creates a m ulticast forw arding en try for a particular source
ro oted distribution tree when a data pac k et from that source to the group rst arriv es In creating
this en try it is assumed that all do wnstream systems w an t to receivem ulticast datagrams F or densely
p opulated groups or in net w orks where the bandwidth is plen tiful this default to send b eha vior is
optimal If some areas of the net w ork do not ha v e group mem b ers densemo de PIM will prune branc hes
of the sourcebased tree When group mem b ers lea v e the group branc hes will also b e pruned
UnlikeD VMRP pac k ets are forw arded on all outgoing in terfaces except the incoming un til
pruning and truncation o ccurs D VMRP mak es use of paren tc hild data to reduce the n um b er of outgoing
in terfaces used b efore pruning In b oth proto cols once truncation o ccurs pruning state is main tained
and pac k ets are only forw arded on to outgoing in terfaces that in fact reachdo wnstream mem b ers W e
c hose to accept additional o v erhead in fa v or of reduced dep endency on the unicast routing proto col and
reduced o v erall proto col complexit y Densemo de PIM diers from sparsemo de PIM in t woessen tial p oin ts
a there are no p erio dic joins transmitted only explicit triggered graftsprunes and
b there is no Rendezv ous P oin t RP
Comparison to other densemo de sc hemes
Rev erse P ath Broadcasting RPB is dieren t from RPF b ecause duplicate pac k ets are a v oided in the
RPB that are sen t in RPF In general the n um b er of duplicates sen t on a link can b e as high as the
n um b er of routers directly connected to that link
Rev erse P ath Multicasting RPM is dieren t from RPF or RPB b ecause pruning information is
propagated upstream Leaf routers m ust kno w that they are leaf routers so that in resp onse to no IGMP
rep orts for a group those leaf routers kno w to initiate the prune pro cess
In D VMRP there are routing proto col dep endencies for
a building a paren tc hild database so that duplicate pac k ets can b e eliminated
This metho d of con trolling o v erhead w as prop osed byV an Jacobson
draftietfidmrpimarc hps
b eliminating duplicate pac k ets on m ultiaccess LANs and
c sending split horizon with p oison rev erse information to detect that a router is not a leaf router
if a router do es not receiv ean y p oison rev erse messages from other routers on a m ultiaccess LAN
then that router acts as a leaf router for that LAN and kno ws to prune if there are not IGMP
rep orts on that LAN for a group G
Densemo de PIM will accept some duplicate pac k ets in order to a v oid b eing routing proto col dep en
den t and a v oid building a paren tc hild database
Wein tro duce a simple prune mec hanism for reducing duplicates on m ultiaccess LANs W ein tro duce
a simple graft mec hanism to reduce join latency on previously pruned branc hes of a sourcebased m ulticast
tree W ein tro duce an alternativ e leafrouter detection mec hanism that do es not rely on a sp ecic unicast
routing proto col mec hanism suc h as split horizon with p oison rev erse These mec hanisms are describ ed
in detail in the proto col sp ecication do cumen t
PIMSparse Mo de PIMSM
As describ ed traditional m ulticast routing proto cols as w ell as PIMDM w ere designed for densely
p opulated groups and rely on data driv en actions in all net w ork routers to establish ecien t distribution
trees In con trast sparsemo de m ulticast tries to constrain the data distribution so that a minimal
n um b er of routers in the net w ork receiv e it PIMSM 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 sparsemo de PIM distribution tree b y sending
explicit join messages in densemo de IP m ulticast mem b ership is assumed and m ulticast data
pac k ets are sentun til routers without lo cal or do wnstream mem b ers send explicit prune messages
to remo v e themselv es from the distribution tree
Whereas densemo de IP m ulticast tree construction is data driv en sparsemo de PIM m ust use p er
group R endezvous Points for receiv ers to meet new sources Rendezv ous P oin ts RP are used
b y senders to announce their existence and b y receiv ers to learn ab out new senders of a group In
SM some join state is stored in an ticipation of data pac k ets whereas DM do es not create state
un til a data pac k et arriv es
The shortestpathtree state main tained in routers is roughly the same as the forw arding information
that is curren 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 forw arding en try for SG
An en try for a shared tree can matc h pac 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 suchan en try G An G en try k eeps the
same information a 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 W Cbit 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 receiv er w an ts to join a PIM m ulticast group its lasthop PIM router A in g sends a PIMJoin
message to w ards one of the RPs adv ertised for the group
Pro cessing of this message b yin 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 designated router D in g sends a PIMRegister message encapsulating the data
pac k et to the RPs for that group The RP resp onds b y sending a join to w ards the source Pro cessing
F or all routers con taining a SG en try their oif s and iif together form a shortestpath tree ro oted at S If the lasthop router do es not ha v e RP information then the group is treated in dense mo de
Figure Ho w senders rendezv ous with receiv ers
of these messages byin termediate routers there are no in termediate routers b et w een the RP and the
source in g sets up a pac k et deliv ery path from the source to the RPs
If sourcesp ecic distribution trees are desired the lasthop PIM router for eac hmem ber ev en tually
joins the sourcero oted distribution tree for eac h source b y sending a PIMJoin message to w ards the
source After data pac k ets are receiv ed on the new path router B in g sends a PIMprune message
to w ards 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 ma ybe an y PIMsp eaking router that is close to one of the mem b ers of the group
or it ma y b e some other PIMsp eaking router in the net w ork A sparsemo de group ie one that
the receiv ers directly connected PIM router will join using PIM is iden tied b y the presence of RP
addresses asso ciated with the group in question 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 to distribute
information ab out RPs to their lo cal routers PIM a v oids explicit en umeration of receiv ers but do es require en umeration of sources If there are
v ery large n um b ers of sources sending to a group but the sources a v erage data rates are lo w then
it ma y b e more ecien t to supp ort the group with a shared tree instead whic h has less p ersource
o v erhead If shortestpath trees are desired then when the n um b er of sources gro ws v ery large some form
of aggregation can b e emplo y ed see section W e selected this tradeo b ecause in man y existing and
an ticipated applications the n umberofreceiv 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
In summary once the PIMJoin messages ha v e propagated upstream from the RP data pac k ets from
the source will follo w the SG distribution path state established The pac k ets will tra v el to the receiv ers
via the distribution paths established b y the PIMJoin messages sen t upstream from receiv ers to w ards
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 of 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 Similarly receiv ers con tin ue to receiv e some data pac k ets via the RP tree in order to pic k
B kno ws b yc hec king the incoming in terface in it routing table that it is at a p oin t where the shortestpath tree and
the RP tree branc hes div erge A ag called SPTbit is included in SG en tries to indicate whether the transition from
shared tree to shortestpath tree has nished This minimizes the c hance of losing data pac k ets during the transition
draftietfidmrpimarc hps
up new senders Ho w ev er when sourcesp ecic tree distribution is used most data pac k ets will arriveat
receiv ers o v er a shortestpath distribution tree
Sparse mo dedense mo de in teraction
There are t w o imp ortan t p oin ts regarding the in teraction of SM and DM
If a m ulticast data pac k et arriv es for whic h there is no m ulticast forw arding state and no RP
information the data pac k et will b e o o ded as describ ed in the Dense Mo de proto col
If a m ulticast group is widearea ie it has RPs asso ciated with it then b oth tree managemen t
joining pruning and registering and data pac k et forw arding will b e handled in a Sparse Mo de
manner
T o summarize SM links are nev er treated in DM but DM links are alw a ys treated in SM when the group
itself is SM
Proto col Engineering Design F eatures
In this section w e describ e engineering features em b o died in the PIM proto cols robustness sparse
mo dedensemo de in teraction PIMnonPIM in teraction and m ulticast service in terfaces
Robustness features
There are sev eral areas in whic h PIM is designed for robustness
Lost PIM messages
The proto col is fairly robust to lost con trol messages If a PIMRegister message gets lost then data
pac k ets will con tin ue to b e encapsulated in subsequen t PIMRegister messages un til the RP initializes
an SG en try sends a PIMJoin message to the source and un til the asso ciated PIMRegisterStop
messages propagate up to the source
If a PIMJoin message is lost then for the remainder of the refresh p erio d pac k ets will not b e forw arded
on the new path or will con tin ue to b e forw arded un til the refresh is sen t
F or example PIM messages ma y b e transmitted at a rate of seconds outgoingin terface state that
is cac hed should b e timed out after times the transmission p erio d if no PIM message for the en tries ha v e
b een receiv ed When a forw arding en try has no more outgoing in terfaces it is sc heduled to b e deleted
some time later and a prune can b e sen t upstream or the router can w ait un til the next p erio d when
the PIM list will no longer include the source for the deleted en try and the state will ev en tually b e timed
out upstream
Multiple Rendezv ous P oin ts and RP failure scenarios
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 reliabilit y issue If there are more than one RPs then eac h receiv er still joins to a single RP but eac h source m ust register to e ach and every RP In other w ords there are m ultiple RP distribution
trees and so long as eac h source sends its pac k ets to all of them receiv ers need only join to one
When the RP fails or b ecomes unreac hable b y receiv ers mem b ers who ha v e already joined will
con tin ue to receiv e pac k ets from sources that had previously sen t to the group and for whic h the receiv ers
had already switc hed to the SPT assuming the SPT is not aected b y the same failure as mak es the
draftietfidmrpimarc hps
RP unreac hable Ho w ev er new mem b ers will send joins to w ards the unreac hable RP and will not be
successfully joined to the group unless their join pac k ets reac h existing SPTs of the sources b efore they
reac h the RP New sources will attempt to register and send to the failed RP As a result their pac k ets
will not b e deliv ered to an y receiv ers and the SPT from the source to receiv ers will nev er b e set up ev en
if the paths that mak e up the SPT are a v ailable This leads to the motiv ation for emplo ying m ultiple
RPs
Unreac hable RPs are detected bydo wnstream routers using the RPReac habilit 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
RPReac 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 ards the new RP A new G en try is established 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 IGMPRep 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 ards eac h of the RPs
but receiv ers only join to w ards a single RP If one of the RPs fails receiv ers that joined to that RP
will stop receiving RPReac habilit y messages and will start sending joins to one of the alternativeRPs Sources tak e dieren t actions When an RP is unreac hable it will not receiv e the sources register messages
and therefore will not resp ond with joins and so the outgoing in terfaces in SG p oin ting to w ards the
unreac hable RP will time out without an y explicit action on the part of the source Ho w ev er when
the RP comes bac k up the rsthop routers need to inform the RP ab out sources it had previously
sen t Registers for This allo ws the RP to join to those sources so data can tra v el nativ ely rather than
encapsulated
Because eac h receiv ers directlyconnected router selects an RP indep enden tly it is p ossible for routers
on the same part of the distribution tree to sp ecify dieren t RPs while b oth are still a v ailable This can
lead to lo oping in some top ologies T oa v oid lo oping RP address information carried in PIMJoin and
RPreac habilit y messages is examined to con v erge to a common RP the larger n um b ered RP dominates
Unicast routing c hanges
When unicast routing c hanges an RPF c hec k is done and all aected exp ected incoming in terfaces are
up dated If the new incoming in terface app ears in the outgoing in terface list it is deleted from the
outgoing list The previous incoming in terface ma y b e added to the outgoing in terface list b y a subsequen t
join from do wnstream Joins receiv ed on the curren t incoming in terface are ignored Joins receiv ed on
new in terfaces or existing outgoing in terfaces are not ignored Other outgoing in terfaces are left as is
un til they are explicitly pruned bydo wnstream routers or are timed out due to lac k of appropriate join
messages
Dense mo de and sparse mo de in teraction
The basic dierence b et w een PIMDM and PIMSM is that the former is data driv en F our imp ortan t
b eha vioral dierences result
Dense mo de sends and stores explicit prune state in resp onse to un w an ted data pac k ets Sparse
mo de requires explicit joining the default action is to not send data pac k ets where they ha venot
b een requested
Sparse mo de stores join state in an ticipation of data pac k ets Densemo de routers only store state
in resp onse to arriving data pac k ets ie for activ e data sources
Sparse mo de relies on the concept of an RP for data to b e deliv ered to receiv ers who request to join
the group Densemo de groups do not require an RP
draftietfidmrpimarc hps
Sparse mo de relies on p erio dic refreshing of explicit join messages Dense mo de do es not need to
send prune messages p erio dically b ecause of its data driv en nature
In simplied terms the cost of dense mo de is the default o o ding b eha vior whereas the cost of sparse
mo de is the need for RPs RPtree state for idle groups and p erio dic refreshes
If all mem b ers of a group are lo cated within a region the group ma y b e supp orted in a strictly dense
mo de These groups require no RP to b e congured or used and shortestpath trees are built in a data
driv en manner
Groups that do not mak e use of RPs will not b e able to include an y receiv ers that are b ey ond the
scop e of the m ulticast address PIMSM is designed to address the more general problem of groups that
are not a priori limited to in tradomain mem b ership and m ust therefore span sparsemo de in terfaces and
b oundaries An y suc h group that is not strictly lo cal to a densemo de congured domain m ust ha veat
least one RP dened All receiv ers join suchin terdomain groups using p erio dic explicit join messages
dened in the Sparse Mo de proto col
In other w ords if a group is wide area and has RPs asso ciated with it then all mem b ers in PIM
regions will Join the group using the PIMSM proto col
One implication of this approachis thatall in terfaces in PIM routers m ust b e able to run PIMSM
In the case of m ultiaccess LANs some in teresting issues arise b ecause of p ossibilit y of parallel routers
forw arding duplicate pac k ets on to the LAN In SM w em ust b e particularly careful with the op eration
of the RPtree b ecause the RPF c hec k that prev en ts routing lo ops is dep enden t on information stored in
the router and not based on the source address found in the pac k et header As a result it is conceiv able
that a pac k et could b e routed in elab orate lo ops b ecause dieren t routers are using dieren t criteria for
accepting the pac k et T osolv e this problem eac h router on a m ultiaccess LAN sends Assert messages
when a data pac k et from a source arriv es on the outgoing in terface for the asso ciated SG or the G
en try All routers listen to Assert messages compare the metrics included therein and only one router
remains the forw arder for that source to that LAN
In terop eration with nonPIM net w orks
W e wish to in terop erate with net w orks that do not ha v e hosts and routers mo died to generate and
in terpret PIMJoin messages W eha v e to address t w o functions pulling data do wn to the nonPIM DM
cloud and propagating data pac k ets through the cloud ev en when they arriv e on the RP tree
In PIMSM receiv ers are not passiv e they m ust tak e explicit join action to receiv e data pac k ets
This creates problems when a nonPIM densemo de region wishes to in terop erate with PIMSM
In particular when a receiv er decides to join a group inside of a nonPIM cloud in whic h there
are no other mem b ers then the PIMnonPIM b order routers PIMBRs of that cloud m ust b e
notied in order to trigger sending of a PIMJoin message to w ards the RP Similarly if join comes
upstream from a SM region and the RP or source is on the other side of the nonPIM region
then the PIMBRs m ust b e notied in order to ha v e the join message propagate upstream of the
nonPIM region
Data pac k ets will not b e o o ded through the nonPIM region if they arriv e via the wrong incoming
b order router Therefore w e need to in tro duce some additional mec hanism to cause RPtree pac k ets
to b e forw arded through the nonPIM region In order for the nonPIM cloud to propagate a data
pac k et from the RP tree through to an yin ternal mem b ers and to other PIMBRs whic h migh t
ha vedo wnstream mem b ers the pac k et m ust b e injected via the PIMBRs that are the shortest
path tree en try p oin ts from the pac k et source S to the routers inside the nonPIM region
The details of these mec hanisms are describ ed in
draftietfidmrpimarc hps
When a source inside of a nonPIM region is sending to a nonlo cal group all the PIMBRs that ha v e
external shortest paths to the RP m ust send register messages The RPs will resolv e the problem b y
sending a join to only one of them and an indication to stop to all of them The RP need not c ho ose an
optimal BR an y one will do
Multicast service in terface
In the general case sparsemo de PIM requires that receiv ers obtain the addresses of an RP along with
the address of the m ulticast group Receiv ers then need to comm unicate these v alues to their DR just as
receiv ers ha v e to comm unicate m ulticast addresses curren tly In PIM sources will also ha vetopro vide
the m ulticast and RP address information to their DR
F or sp ecial cases routers can use congured w ellkno wnv alue or default RP information to a v oid the
necessit y for this additional information from hosts ho w ev er these solutions are not general enough
Although it is alw a ys b etter to a v oid c hanges in the service mo del if p ossible in this case the c hange is
quite minor in that it is not implicating an additional information distribution mec hanism In other w ords
the host do es not need to in teract with some new directory service or n um b er distributionadv ertisemen t
mec hanism Rather the host just needs to obtain more than one n um b er from whomev er the m ulticast
address is curren tly obtained
W e prop ose to dev elop an IGMP RPRep ort message that is also sen t in resp onse to an IGMPQuery The RPRep ort lists all the RPs for a particular group
RPRep ort messages will b e sen t to the group This will cause receiv ers to participate in suppression
This seems acceptable giv en the other tradeos
Note that strictly lo cal eg in tradomain groups do not require RPs ev en for PIMDM Deering
has suggested dening a separate part of the address space for m ulticast groups that do require RP
SM joining to a v oid the am biguit y that migh t o ccur if the binding b et w een RP and m ulticast address
information is lost
Scaling and Aggregation
There are sev eral motiv ations for aggregating source information the most imp ortan t are PIM message
size and the amoun t of memory used for m ulticast 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 forw 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 messages will tra v el to w ards all mem b ers of the aggregate whichw ould b e inecien tin
mostman ycases PIMDM do es not ha v e this problem since prune messages can carry most ne grain information
whic h are triggered based on data pac k ets If the prune messages are lost subsequen t data triggers the
prune On the other hand graft messages ma y b e sub ject to the fannout problem In this case they are
sen t as far as the message information tak es it The p enalt y is increased join latency 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 ossibilit y is to use the domain lev el aggregate for a source in PIM messages
Autonomous System AS n um b ers or Routing Domain Iden tiers RDIs Then the PIM message
will tra v el to the PIMBRs of the domain and the PIMBRs can use the in ternal m ulticast proto cols
mec hanism for propagating the join within the domain eg send appropriate linkstate adv ertisemen t
F or more information on RPRep ort messages see up coming In ternetDraft on new IGMP messages b y S Deering
draftietfidmrpimarc hps
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 domain address when pro cessing data
pac k ets as w ell as con trol pac k ets
W e address the issues of con trol trac and state scaling separately b elo w The detailed mec hanisms
ha v e not y et b een incorp orated in to the proto col sp ecication as they are still b eing designed
Con taining con trol trac o v erhead
T o con trol the bandwidth consumed b y p erio dic con trol messages w e adopt a tec hnique prop osed byone
of the authors Jacobson called sc alable timers The timers con trolling p erio dic refreshing of con trol
messages are set suc h that the total o v erhead is a small xed p ercen tage of the link bandwidth
The timeout mec hanism is determined b y the sender of the information Therefore a router tells its
neigh b ors ho w long to keepitreac hable byadv ertising the holdtime in PIMQuery messages Lik ewise
joinprune messages and RPReac hable messages indicate ho w long state should b e k ept This allo ws the
sender to c hange its frequency without the receiv ers requiring an y sp ecial conguration information
Note that across regions that drop state see b elo w the timer is no longer across a link but is across
the cloud as a whole Routers within the cloud do not con trol the frequency hopb yhop but just pass
thru con trol messages generated at the edges of the cloud So the b order routers ha v e to set their timers
so as to constrain proto col o v erhead across the cloud
Con taining state o v erhead
If the state in an y particular router gro ws to o big that router can drop the state and reconstruct state
for activ e data sources only This tec hnique has the imp ortan t prop ert y that they do not require an y
co ordinated action across routers routers act unilaterally according to their aggregation needs
When a router is o v erloaded with state w e prop ose that it drop state in an LR U fashion and rebuild
needed state in a datadriv en fashion as needed Conceptually this approac hem ulates densemo de data
driv en b eha vior but builds SM state in order to reduce the amoun t of prune state stored in the SM
region
In other w ords a router in this state builds SG en tries in a datadriv en manner Ho w ev er to
reac h all do wnstream mem b ers it p opulates the outgoing in terface list with all in terfaces other than the
incoming The state is SM state b ecause eac h outgoing in terface is timed out after some p erio d if an
explicit SM join is not receiv ed
Although state is built in a data driv en manner SM joins that arriv e from do wnstream are still
propagated upstream through the aggregating region The Joins from do wnstream that matc h on lo cal
en tries reset the timers ho w ev er joins that do not matc h are just passed through state is NOT created
in resp onse to a join State is not created b ecause the whole p oin t of the sc heme is to not create state in
adv ance of data The Joins m ust still b e propagated upstream so that upstream regions can k eep regular
SM state and are not forced to time out their explicit join state and cause blac kholes as a result of an
in termediate router dropping state In summary sparsemo de join information gets propagated up to
the data source the data pac k ets thereb y arriv e at the aggregating regions BRs and are automatically
propagated through the aggregating region using the datadriv en mec hanisms
Ho w ev er as with PIMnonPIM in teraction sp ecial actions m ust b e tak en to propagate RPtree
pac k ets through an aggregating region T o do so the BRs at the b order b et w een the aggregating and
nonaggregating region m ust encapsulate and decapsulate RPtree pac k ets as they en ter and exit the
region resp ectiv ely
draftietfidmrpimarc hps
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
RPs There are sev eral op en issues with resp ect to supp orting RPs this is not surprising since the
concept do es not exist in currentIP m ulticast routing
Distinguishing b et w een DM and SM groups
It w ould b e useful to kno w explicitly if a particular group had RPs asso ciated with it and
if therefore the SM proto col should b e used to participate T o this end w e are considering
dening a p ortion of the m ulticast address space for use b y widearea in terdomain groups
that use RPs
Selecting RPs
An RP for a particular m ulticast group can b e an y IPaddressable en tit y in the in ternet
Ho w ev er it is ecien t and con v enien t for the RP to b e the directlyconnected PIM router
of one of the mem b ers of the group If an RP has lo cal mem b ers 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 a y for deliv ery to those mem bers Nev ertheless w e
need not b e o v erly concerned with placemen t of the RPs when shortestpath trees are used
b ecause the RP will not remain on the distribution path for most receiv ers unless it happ ens
to also b e on the SPT
As describ ed earlier the RP address can b e congured or can b e dynamically disco v ered b y
mapping from the m ulticast address query of a directory service or from information obtained
via some new IGMP RPRep ort messages The mapping of G to RP addresses should b e
cac hed
IGMP RPRep orts
Hosts m ust notify their DRs of the RPs asso ciated with a particular group W e are dev eloping
an IGMPRPRep ort message to b e used for just this purp ose
In teraction with p olicybased and QOS routing
PIM messages and data pac k ets maytra v el o v er p olicyconstrained routes to the same exten t that
unicast routing do es so long as the p olicy do es not prohibit this trac explicitly T o obtain p olicysensitiv e distribution of m ulticast pac k ets w e need to consider the paths c hosen
for forw arding PIMJoin messages
If the path to reac h the RP or some source is indicated as b eing the appropriate QOS and indicated
as b eing symmetric then PIM routers can determine 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 byhopb 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 sen t with
an em b edded SDRP route This option needs to b e added to PIM join messages Its absence
will indicate forw arding according to the routers unicast routing tables 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 distribution tree
branc h
draftietfidmrpimarc hps
In teraction with receiv erinitiated reserv ation setup suchasRSVP Once the shortestpath distribution tree has b een established RSVP reserv ation messages followthe
rev 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 initially receiv e all pac k ets via the RP distribution tree and after some dela y it could send
PIM messages to establish the shortestpath tree and then establish reserv 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 setting up a reserv ation on
the RP path the receiv er w ould send its IGMP message b efor 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 routing is w ell suited to receiv er initiated reser
v ations since if a reserv ation is blo c k ed the previous router or the receiv er can select an alternativ e
rev 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 ulticast pac k ets in large widearea in ternets
Our approac h
a uses constrained receiv erinitiated mem b ership adv ertisemen t for sparsely distributed m ulticast
groups
b supp orts b oth shared and shortest path tree t yp es in one proto col
c do es not dep end on the underlying unicast proto cols and
d 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 ulticast groups
and to dieren tnet w ork conditions
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 resolv ed Solutions to some of the issues require co ordination with eorts in other areas
suchasin terdomain routing and resource reserv ation proto cols
Ac kno wledgmen ts
T on y Ballardie Scott Brim Jon Cro w croft P aul F rancis Puneet Sharma Lixia Zhang and John Zwieb el
pro vided detailed commen ts on previous drafts The authors of CBT and mem b ership of the IDMR W G
pro vided man y of the motiv ating ideas for this w ork and useful feedbac k on design details
References
S Deering D Estrin D F arinacci V Jacobson C Liu and L W ei Proto col indep enden tm ulticast
pim Sp ecication Working Dr aftNo v em b er
S Deering and D Cheriton Multicast routing in datagram in ternet w orks and extended lans A CM
T r ansactions on Computer Systems pages ! Ma y The in teraction of PIM SDRP and RSVP is curren tly b eing in v estigated b y D Zappala S Shenk er and D Estrin
draftietfidmrpimarc hps
S Deering Multic ast R outing in a Datagr am Internetwork PhD thesis Stanford Univ ersit y J Mo y Multicast extension to ospf Internet Dr aft Septem ber D W aitzman S Deering C P artridge Distance v ector m ulticast routing proto col no v
RF C
S Deering Host extensions for ip m ulticasting aug RF C
J Mo yOspf v ersion o ct 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 arding of broadcast pac k ets Communic ations of
the A CM ! Ron F rederic k Ietf audio " video cast Internet So ciety News A J Ballardie P F F rancis and J Cro w croft Core based trees In Pr o c e e dings of the A CM
SIGCOMMSan 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 The tradeos of m ulticast trees and algorithms In Pr o c e e dings of the international c onfer enceon c omputer c ommunic ations and networksSan F rancisco Septem b er
G Malkin Rip v ersion carrying additional information jun RF C
S Deering Igmp No v em b er Y Rekh ter and T Li editors A b order gatew a y proto col bgp Internet Dr aft Jan uary S Hares and John Scudder Idrp for ip Internet Dr aftSeptem ber D Estrin T Li Y Rekh ter and D Zappala Source demand routing proto col P ac k et format and
forw arding sp ecication InternetDr aftMarc h L Zhang R Braden D Estrin S Herzog and S Jamin Resource reserv ation proto col rsvp !
v ersion functional sp ecication InternetDr aft Octob er

Abstract (if available)

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

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

PDF

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

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. 530 (1992)

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

Description

Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ching-gung Liu, and Liming Wei. "Protocol independent multicast (PIM): motivation and architecture." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 608 (1995).

Asset Metadata

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

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

Alternative Title Protocol independent multicast (PIM): motivation and architecture (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 20 pages (extent), technical reports (aat)

Language English

Unique identifier UC16270531

Identifier 95-608 Protocol Independent Multicast (PIM) Motivation and Architecture (filename)

Legacy Identifier usc-cstr-95-608

Format 20 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

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)