As per Relevance of the word multicast, we have this rfc below:
Network Working Group D.
Request for Comments: 2117
Category: Experimental D.
A.
D.
S.
M.
V.
C.
P.
L.
June 1997
Protocol Independent Multicast-Sparse Mode (PIM-SM):
Status of This
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
The author list has been reordered to reflect the involvement
detailed editorial work on this specification document. The
four authors are the primary editors and are listed alphabetically
The rest of the authors, also listed alphabetically, participated
all aspects of the architectural and detailed design but managed
get away without hacking the latex
Estrin, et. al. Experimental [Page 1]
RFC 2117 PIM-SM June 1997
1
This document describes a protocol for efficiently routing
multicast groups that may span wide-area (and inter-domain
internets. We refer to the approach as Protocol
Multicast--Sparse Mode (PIM-SM) because it is not dependent on
particular unicast routing protocol, and because it is designed
support sparse groups as defined in [1][2]. This document
the protocol details. For the motivation behind the design and
description of the architecture, see [1][2]. Section 2
PIM-SM operation. It describes the protocol from a
perspective, in particular, how the participating routers interact
create and maintain the multicast distribution tree. Section 3
describes PIM-SM operations from the perspective of a single
implementing the protocol; this section constitutes the main body
the protocol specification. It is organized according to PIM-
message type; for each message type we describe its contents,
generation, and its processing
Sections 3.8 and 3.9 summarize the timers and flags referred
throughout this document. Section 4 provides packet format details
The most significant functional changes since the January '95
involve the Rendezvous Point-related mechanisms, several
simplifications to the protocol, and removal of the PIM-DM
details to a separate document [3] (for clarity).
2 PIM-SM Protocol
In this section we provide an overview of the
components of PIM-SM
A router receives explicit Join/Prune messages from those
routers that have downstream group members. The router then
data packets addressed to a multicast group, G, only onto
interfaces on which explicit joins have been received. Note that
routers mentioned in this document are assumed to be PIM-SM capable
unless otherwise specified
A Designated Router (DR) sends periodic Join/Prune messages toward
group-specific Rendezvous Point (RP) for each group for which it
active members. Each router along the path toward the RP builds
wildcard (any-source) state for the group and sends Join/
messages on toward the RP. We use the term route entry to refer
the state maintained in a router to represent the distribution tree
A route entry may include such fields as the source address,
group address, the incoming interface from which packets
accepted, the list of outgoing interfaces to which packets are sent
Estrin, et. al. Experimental [Page 2]
RFC 2117 PIM-SM June 1997
timers, flag bits, etc. The wildcard route entry's incoming
points toward the RP; the outgoing interfaces point to
neighboring downstream routers that have sent Join/Prune
toward the RP. This state creates a shared, RP-centered,
tree that reaches all group members. When a data source first
to a group, its DR unicasts Register messages to the RP with
source's data packets encapsulated within. If the data rate is high
the RP can send source-specific Join/Prune messages back towards
source and the source's data packets will follow the
forwarding state and travel unencapsulated to the RP. Whether
arrive encapsulated or natively, the RP forwards the source'
decapsulated data packets down the RP-centered distribution
toward group members. If the data rate warrants it, routers
local receivers can join a source-specific, shortest path
distribution tree, and prune this source's packets off of the
RP-centered tree. For low data rate sources, neither the RP,
last-hop routers need join a source-specific shortest path tree
data packets can be delivered via the shared, RP-tree
The following subsections describe SM operation in more detail,
particular, the control messages, and the actions they trigger
2.1 Local hosts joining a
In order to join a multicast group, G, a host conveys its
information through the Internet Group Management Protocol (IGMP),
specified in [4][5], (see figure 1). From this point on we refer
such a host as a receiver, R, (or member) of the group G
Note that all figures used in this section are for illustration
are not intended to be complete. For complete and detailed
action see Section 3.
[Figures are present only in the postscript version
Fig. 1 Example: how a receiver joins, and sets up shared
When a DR (e.g., router A in figure 1) gets a membership
from IGMP for a new group, G, the DR looks up the associated RP.
DR creates a wildcard multicast route entry for the group,
to here as a (*,G) entry; if there is no more specific match for
particular source, the packet will be forwarded according to
entry
Estrin, et. al. Experimental [Page 3]
RFC 2117 PIM-SM June 1997
The RP address is included in a special field in the route entry
is included in periodic upstream Join/Prune messages. The
interface is set to that included in the IGMP membership
for the new member. The incoming interface is set to the
used to send unicast packets to the RP
When there are no longer directly connected members for the group
IGMP notifies the DR. If the DR has neither local members
downstream receivers, the (*,G) state is deleted
2.2 Establishing the RP-rooted shared
Triggered by the (*,G) state, the DR creates a Join/Prune
with the RP address in its join list and the the wildcard bit (WC
bit) and RP-tree bit (RPT-bit) set to 1. The WC-bit indicates
any source may match and be forwarded according to this entry
there is no longer match; the RPT-bit indicates that this join
being sent up the shared, RP-tree. The prune list is left empty.
the RPT-bit is set to 1 it indicates that the join is associated
the shared RP-tree and therefore the Join/Prune message is
along the RP-tree. When the WC-bit is set to 1 it indicates that
address is an RP and the downstream receivers expect to
packets from all sources via this (shared tree) path. The term RPT
bit is used to refer to both the RPT-bit flags associated with
entries, and the RPT-bit included in each encoded address in
Join/Prune message
Each upstream router creates or updates its multicast route entry
(*,G) when it receives a Join/Prune with the RPT-bit and WC-bit set
The interface on which the Join/Prune message arrived is added to
list of outgoing interfaces (oifs) for (*,G). Based on this
each upstream router between the receiver and the RP sends
Join/Prune message in which the join list includes the RP. The
payload contains Multicast-Address=G, Join=RP,WC-bit,RPT-bit
Prune=NULL
2.3 Hosts sending to a
When a host starts sending multicast data packets to a group
initially its DR must deliver each packet to the RP for
down the RP-tree (see figure 2). The sender's DR
encapsulates each data packet in a Register message and unicasts
to the RP for that group. The RP decapsulates each Register
and forwards the enclosed data packet natively to downstream
on the shared RP-tree
[Figures are present only in the postscript version
Fig. 2 Example: a host sending to a
Estrin, et. al. Experimental [Page 4]
RFC 2117 PIM-SM June 1997
If the data rate of the source warrants the use of a source-
shortest path tree (SPT), the RP may construct a new multicast
entry that is specific to the source, hereafter referred to as (S,G
state, and send periodic Join/Prune messages toward the source.
that over time, the rules for when to switch can be modified
global coordination. When and if the RP does switch to the SPT,
routers between the source and the RP build and maintain (S,G)
in response to these messages and send (S,G) messages upstream
the source
The source's DR must stop encapsulating data packets in
when (and so long as) it receives Register-Stop messages from the RP
The RP triggers Register-Stop messages in response to Registers,
the RP has no downstream receivers for the group (or for
particular source), or if the RP has already joined the (S,G)
and is receiving the data packets natively. Each source's
maintains, per (S,G), a Register-Suppression-timer. The Register
Suppression-timer is started by the Register-Stop message;
expiration, the source's DR resumes sending data packets to the RP
encapsulated in Register messages
2.4 Switching from shared tree (RP-tree) to shortest path tree (SP
tree
A router with directly-connected members first joins the shared RP
tree. The router can switch to a source's shortest path tree (SP
tree) after receiving packets from that source over the shared RP
tree. The recommended policy is to initiate the switch to the SP-
after receiving a significant number of data packets during
specified time interval from a particular source. To realize
policy the router can monitor data packets from sources for which
has no source-specific multicast route entry and initiate such
entry when the data rate exceeds the configured threshold. As
in figure 3, router `A' initiates a (S,G) state
[Figures are present only in the postscript version
Fig. 3 Example: Switching from shared tree to shortest path
When a (S,G) entry is activated (and periodically so long as
state exists), a Join/Prune message is sent upstream towards
source, S, with S in the join list. The payload contains Multicast
Address=G, Join=S, Prune=NULL. When the (S,G) entry is created,
outgoing interface list is copied from (*,G), i.e., all local
tree branches are replicated in the new shortest path tree. In
way when a data packet from S arrives and matches on this entry,
receivers will continue to receive the source's packets along
path. (In more complicated scenarios, other entries in the
have to be considered, as described in Section 3). Note that (S,G
Estrin, et. al. Experimental [Page 5]
RFC 2117 PIM-SM June 1997
state must be maintained in each last-hop router that is
for initiating and maintaining an SP-tree. Even when (*,G) and (S,G
overlap, both states are needed to trigger the source-
Join/Prune messages. (S,G) state is kept alive by data
arriving from that source. A timer, Entry-timer, is set for the (S,G
entry and this timer is restarted whenever data packets for (S,G)
forwarded out at least one oif, or Registers are sent. When
Entry-timer expires, the state is deleted. The last-hop router is
router that delivers the packets to their ultimate end-
destination. This is the router that monitors if there is
membership and joins or prunes the appropriate distribution trees
response. In general the last-hop router is the Designated
(DR) for the LAN. However, under various conditions described later
a parallel router connected to the same LAN may take over as
last-hop router in place of the DR
Only the RP and routers with local members can initiate switching
the SP-tree; intermediate routers do not. Consequently, last-
routers create (S,G) state in response to data packets from
source, S; whereas intermediate routers only create (S,G) state
response to Join/Prune messages from downstream that have S in
Join list
The (S,G) entry is initialized with the SPT-bit cleared,
that the shortest path tree branch from S has not yet been
completely, and the router can still accept packets from S
arrive on the (*,G) entry's indicated incoming interface (iif).
PIM multicast entry has an associated incoming interface on
packets are expected to arrive
When a router with a (S,G) entry and a cleared SPT-bit starts
receive packets from the new source S on the iif for the (S,G) entry
and that iif differs from the (*,G) entry's iif, the router sets
SPT-bit, and sends a Join/Prune message towards the RP,
that the router no longer wants to receive packets from S via
shared RP-tree. The Join/Prune message sent towards the RP includes
in the prune list, with the RPT-bit set indicating that S's
must not be forwarded down this branch of the shared tree. If
router receiving the Join/Prune message has (S,G) state (with
without the route entry's RPT-bit flag set), it deletes the
interface from the (S,G) oif list. If the router has only (*,G
state, it creates an entry with the RPT-bit flag set to 1.
Estrin, et. al. Experimental [Page 6]
RFC 2117 PIM-SM June 1997
brevity we refer to an (S,G) entry that has the RPT-bit flag set to 1
as an (S,G)RPT-bit entry. This notational distinction is useful
point out the different actions taken for (S,G) entries depending
the setting of the RPT-bit flag. Note that a router can have no
than one active (S,G) entry for any particular S and G, at
particular time; whether the RPT-bit flag is set or not. In
words, a router never has both an (S,G) and an (S,G)RPT-bit entry
the same S and G at the same time. The Join/Prune message
contains Multicast-Address=G, Join=NULL, Prune=S,RPT-bit
A new receiver may join an existing RP-tree on which source-
prune state has been established (e.g., because downstream
have switched to SP-trees). In this case the prune state must
eradicated upstream of the new receiver to bring all sources'
packets down to the new receiver. Therefore, when a (*,G)
arrives at a router that has any (Si,G)RPT-bit entries (i.e.,
that cause the router to send source-specific prunes toward the RP),
these entries must be updated upstream of the router so as to
all sources' packets down to the new member. To accomplish this,
router that receives a (*,G) Join/Prune message updates all
(S,G)RPT-bit entries. The router may also trigger a (*,G) Join/
message upstream to cause the same updating of RPT-bit
upstream and pull down all active sources' packets. If the
(*,G) join has some sources included in its prune list, then
corresponding (S,G)RPT-bit entries are left unchanged (i.e.,
RPT-bit remains set and no oif is added).
2.5 Steady state maintenance of distribution tree (i.e., router state
In the steady state each router sends periodic Join/Prune
for each active PIM route entry; the Join/Prune messages are sent
the neighbor indicated in the corresponding entry. These messages
sent periodically to capture state, topology, and membership changes
A Join/Prune message is also sent on an event-triggered basis
time a new route entry is established for some new source (note
some damping function may be applied, e.g., a short delay to
for merging of new Join information). Join/Prune messages do
elicit any form of explicit acknowledgment; routers recover from
packets using the periodic refresh mechanism
2.6 Obtaining RP
To obtain the RP information, all routers within a PIM domain
Bootstrap messages. Bootstrap messages are sent hop-by-hop within
domain; the domain's bootstrap router (BSR) is responsible
originating the Bootstrap messages. Bootstrap messages are used
carry out a dynamic BSR election when needed and to distribute
information in steady state
Estrin, et. al. Experimental [Page 7]
RFC 2117 PIM-SM June 1997
A domain in this context is a contiguous set of routers that
implement PIM and are configured to operate within a common
defined by PIM Multicast Border Routers (PMBRs). PMBRs connect
PIM domain to the rest of the internet
Routers use a set of available RPs (called the {RP-Set})
in Bootstrap messages to get the proper Group to RP mapping.
following paragraphs summarize the mechanism; details of
mechanism may be found in Sections 3.6 and Appendix 6.2. A (small
set of routers, within a domain, are configured as candidate
and, through a simple election mechanism, a single BSR is
for that domain. A set of routers within a domain are also
as candidate RPs (C-RPs); typically these will be the same
that are configured as C-BSRs. Candidate RPs periodically
Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of
domain. C-RP-Advs include the address of the advertising C-RP,
well as an optional group address and a mask length field,
the group prefix(es) for which the candidacy is advertised. The
then includes a set of these Candidate-RPs (the RP-Set), along
the corresponding group prefixes, in Bootstrap messages
periodically originates. Bootstrap messages are distributed hop-by
hop throughout the domain
Routers receive and store Bootstrap messages originated by the BSR
When a DR gets a membership indication from IGMP for (or a
packet from) a directly connected host, for a group for which it
no entry, the DR uses a hash function to map the group address to
of the C-RPs whose Group-prefix includes the group (see Section 3.7).
The DR then sends a Join/Prune message towards (or unicasts
to) that RP
The Bootstrap message indicates liveness of the RPs included therein
If an RP is included in the message, then it is tagged as `up' at
routers; while RPs not included in the message are removed from
list of RPs over which the hash algorithm acts. Each router
to use the contents of the most recently received Bootstrap
until it receives a new Bootstrap message
If a PIM domain partitions, each area separated from the old BSR
elect its own BSR, which will distribute an RP-Set containing
that are reachable within that partition. When the partition heals
another election will occur automatically and only one of the
will continue to send out Bootstrap messages. As is expected at
time of a partition or healing, some disruption in packet
may occur. This time will be on the order of the region's round-
time and the bootstrap router timeout value
Estrin, et. al. Experimental [Page 8]
RFC 2117 PIM-SM June 1997
2.7 Interoperation with dense mode protocols such as
In order to interoperate with networks that run dense-mode
{broadcast and prune}, protocols, such as DVMRP, all
generated within a PIM-SM region must be pulled out to that region'
PIM Multicast Border Routers (PMBRs) and injected (i.e., broadcast
into the DVMRP network. A PMBR is a router that sits at the
of a PIM-SM domain and interoperates with other types of
routers such as those that run DVMRP. Generally a PMBR would
both protocols and implement interoperability functions not
by regular PIM routers. To support interoperability, a special
type, referred to as (*,*,RP), must be supported by all PIM routers
For this reason we include details about (*,*,RP) entry handling
this general PIM specification
A data packet will match on a (*,*,RP) entry if there is no
specific entry (such as (S,G) or (*,G)) and the destination
address in the packet maps to the RP listed in the (*,*,RP) entry.
this sense, a (*,*,RP) entry represents an aggregation of all
groups that hash to that RP. PMBRs initialize (*,*,RP) state for
RP in the domain's RPset. The (*,*,RP) state causes the PMBRs to
(*,*,RP) Join/Prune messages toward each of the active RPs in
domain. As a result distribution trees are built that carry all
packets originated within the PIM domain (and sent to the RPs)
to the PMBRs
PMBRs are also responsible for delivering externally-
packets to routers within the PIM domain. To do so, PMBRs
encapsulate externally-originated packets (i.e., received on
interfaces) in Register messages and unicast them to
corresponding RP within the PIM domain. The Register message has
bit indicating that it was originated by a border router and the
caches the originating PMBR's address in the route entry so
duplicate Registers from other PMBRs can be declined with
Register-Stop message
All PIM routers must be capable of supporting (*,*,RP) state
interpreting associated Join/Prune messages. We describe the
of (*,*,RP) entries and messages throughout this document; however
detailed PIM Multicast Border Router (PMBR) functions will
specified in a separate interoperability document (see directory
http://catarina.usc.edu/pim/interop/).
2.8 Multicast data packet
Data packets are processed in a manner similar to other
schemes. A router first performs a longest match on the source
group address in the data packet. A (S,G) entry is matched first
Estrin, et. al. Experimental [Page 9]
RFC 2117 PIM-SM June 1997
one exists; a (*,G) entry is matched otherwise. If neither
exists, then a (*,*,RP) entry match is attempted as follows:
router hashes on G to identify the RP for group G, and looks for
(*,*,RP) entry that has this RP address associated with it. If
of the above exists, then the packet is dropped. If a state
matched, the router compares the interface on which the
arrived to the incoming interface field in the matched route entry
If the iif check fails the packet is dropped, otherwise the packet
forwarded to all interfaces listed in the outgoing interface list
Some special actions are needed to deliver packets continuously
switching from the shared to shortest-path tree. In particular,
a (S,G) entry is matched, incoming packets are forwarded as follows
1 If the SPT-bit is set, then
1 if the incoming interface is the same as a
(S,G) iif, the packet is forwarded to the oif-list
(S,G).
2 if the incoming interface is different than a
(S,G) iif , the packet is discarded
2 If the SPT-bit is cleared, then
1 if the incoming interface is the same as a
(S,G) iif, the packet is forwarded to the oif-list
(S,G). In addition, the SPT bit is set for that
if the incoming interface differs from the
interface of the (*,G) or (*,*,RP) entry
2 if the incoming interface is different than a
(S,G) iif, the incoming interface is tested against
matching (*,G) or (*,*,RP) entry. If the iif is
same as one of those, the packet is forwarded to
oif-list of the matching entry
3 Otherwise the iif does not match any entry for G
the packet is discarded
Data packets never trigger prunes. However, data packets may
actions that in turn trigger prunes. For example, when router B
figure 3 decides to switch to SP-tree at step 3, it creates a (S,G
entry with SPT-bit set to 0. When data packets from S arrive
Estrin, et. al. Experimental [Page 10]
RFC 2117 PIM-SM June 1997
interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G)
different than that for (S,G). This triggers the sending of
towards the RP
2.9 Operation over Multi-access
This section describes a few additional protocol mechanisms needed
operate PIM over multi-access networks: Designated Router election
Assert messages to resolve parallel paths, and the Join/Prune
Suppression-Timer to suppress redundant Joins on multi-
networks
* Designated router
When there are multiple routers connected to a multi-access network
one of them must be chosen to operate as the designated router (DR
at any point in time. The DR is responsible for sending
Join/Prune and Register messages toward the RP
A simple designated router (DR) election mechanism is used for
SM and traditional IP multicast routing. Neighboring routers
Hello messages to each other. The sender with the largest IP
assumes the role of DR. Each router connected to the multi-access
sends the Hellos periodically in order to adapt to changes in
status
* Parallel paths to a source or the RP--Assert
If a router receives a multicast datagram on a multi-access LAN
a source whose corresponding (S,G) outgoing interface list
the interface to that LAN, the packet must be a duplicate. In
case a single forwarder must be elected. Using Assert
addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN
upstream routers can resolve which one will act as the forwarder
Downstream routers listen to the Asserts so they know which one
elected, and therefore where to send subsequent Joins. Typically
is the same as the downstream router's RPF (Reverse Path Forwarding
neighbor; but there are circumstances where this might not be
case, e.g., when using multiple unicast routing protocols on
LAN. The RPF neighbor for a particular source (or RP) is the next-
router to which packets are forwarded en route to that source (
RP); and therefore is considered a good path via which to
packets from that source
The upstream router elected is the one that has the shortest
to the source. Therefore, when a packet is received on an
interface a router sends an Assert message on the multi-access
indicating what metric it uses to reach the source of the
Estrin, et. al. Experimental [Page 11]
RFC 2117 PIM-SM June 1997
packet. The router with the smallest numerical metric (with
broken by highest address) will become the forwarder. All
upstream routers will delete the interface from their
interface list. The downstream routers also do the comparison in
the forwarder is different than the RPF neighbor
Associated with the metric is a metric preference value. This
provided to deal with the case where the upstream routers may
different unicast routing protocols. The numerically smaller
preference is always preferred. The metric preference is treated
the high-order part of an assert metric comparison. Therefore,
metric value can be compared with another metric value provided
metric preferences are the same. A metric preference can be
per unicast routing protocol and needs to be consistent for
routers on the multi-access network
Asserts are also needed for (*,G) entries since an RP-Tree and
SP-Tree for the same group may both cross the same multi-
network. When an assert is sent for a (*,G) entry, the first bit
the metric preference (RPT-bit) is always set to 1 to indicate
this path corresponds to the RP tree, and that the match must be
on (*,G) if it exists. Furthermore, the RPT-bit is always cleared
metric preferences that refer to SP-tree entries; this causes an SP
tree path to always look better than an RP-tree path. When the SP
tree and RPtree cross the same LAN, this mechanism eliminates
duplicates that would otherwise be carried over the LAN
In case the packet, or the Assert message, matches on oif
(*,*,RP) entry, a (*,G) entry is created, and asserts take place
if the matching state were (*,G).
The DR may lose the (*,G) Assert process to another router on the
if there are multiple paths to the RP through the LAN. From then on
the DR is no longer the last-hop router for local receivers
removes the LAN from its (*,G) oif list. The winning router
the last-hop router and is responsible for sending (*,G)
messages to the RP
* Join/Prune
Join/Prune suppression may be used on multi-access LANs to
duplicate control message overhead; it is not required for
performance of the protocol. If a Join/Prune message arrives
matches on the incoming interface for an existing (S,G), (*,G),
(*,*,RP) route entry, and the Holdtime included in the Join/
message is greater than the recipient's own [Join/Prune-Holdtime
(with ties resolved in favor of the higher IP address), a timer (
Join/Prune-Suppression-timer) in the recipient's route entry may
Estrin, et. al. Experimental [Page 12]
RFC 2117 PIM-SM June 1997
started to suppress further Join/Prune messages. After this
expires, the recipient triggers a Join/Prune message, and
sending periodic Join/Prunes, for this entry. The Join/Prune
Suppression-timer should be restarted each time a Join/Prune
is received with a higher Holdtime
2.10 Unicast Routing
When unicast routing changes, an RPF check is done on all
(S,G), (*,G) and (*,*,RP) entries, and all affected expected
interfaces are updated. In particular, if the new incoming
appears in the outgoing interface list, it is deleted from
outgoing interface list. The previous incoming interface may be
to the outgoing interface list by a subsequent Join/Prune
downstream. Join/Prune messages received on the current
interface are ignored. Join/Prune messages received on
interfaces or existing outgoing interfaces are not ignored.
outgoing interfaces are left as is until they are explicitly
by downstream routers or are timed out due to lack of
Join/Prune messages. If the router has a (S,G) entry with the SPT-
set, and the updated iif(S,G) does not differ from iif(*,G)
iif(*,*,RP), then the router resets the SPT-bit
The router must send a Join/Prune message with S in the Join list
any new incoming interfaces to inform upstream routers that
expects multicast datagrams over the interface. It may also send
Join/Prune message with S in the Prune list out the old
interface, if the link is operational, to inform upstream
that this part of the distribution tree is going away
2.11 PIM-SM for Inter-Domain
Future documents will address the use of PIM-SM as a backbone inter
domain multicast routing protocol. Design choices center
around the distribution and usage of RP information for wide area
inter-domain groups
2.12
All PIM control messages may use IPsec [6] to address
concerns. Security mechanisms are likely to be enhanced in the
future
3 Detailed Protocol
This section describes the protocol operations from the
of an individual router implementation. In particular, for
message type we describe how it is generated and processed
Estrin, et. al. Experimental [Page 13]
RFC 2117 PIM-SM June 1997
3.1
Hello messages are sent so neighboring routers can discover
other
3.1.1 Sending
Hello messages are sent periodically between PIM neighbors,
[Hello-Period] seconds. This informs routers what interfaces
PIM neighbors. Hello messages are multicast using address 224.0.0.13
(ALL-PIM-ROUTERS group). The packet includes a Holdtime, set
[Hello-Holdtime], for neighbors to keep the information valid
Hellos are sent on all types of communication links
3.1.2 Receiving
When a router receives a Hello message, it stores the IP address
that neighbor, sets its Neighbor-timer for the Hello sender to
Holdtime included in the Hello, and determines the Designated
(DR) for that interface. The highest IP addressed system is
DR. Each Hello received causes the DR's address to be updated
When a router that is the active DR receives a Hello from a
neighbor (i.e., from an IP address that is not yet in the
neighbor table), the DR unicasts its most recent RP-set
to the new neighbor
3.1.3 Timing out neighbor
A periodic process is run to time out PIM neighbors that have
sent Hellos. If the DR has gone down, a new DR is chosen by
all neighbors on the interface and selecting the new DR to be the
with the highest IP address. If an interface has gone down,
router may optionally time out all PIM neighbors associated with
interface
3.2 Join/
Join/Prune messages are sent to join or prune a branch off of
multicast distribution tree. A single message contains both a
and prune list, either one of which may be null. Each list
a set of source addresses, indicating the source- specific trees
shared tree that the router wants to join or prune
3.2.1 Sending Join/Prune
Join/Prune messages are merged such that a message sent to
particular upstream neighbor, N, includes all of the current
Estrin, et. al. Experimental [Page 14]
RFC 2117 PIM-SM June 1997
and pruned sources that are reached via N; according to
routing Join/Prune messages are multicast to all routers on multi
access networks with the target address set to the next hop
towards S or RP. Join/Prune messages are sent every [Join/Prune
Period] seconds. In the future we will introduce mechanisms to rate
limit this control traffic on a hop by hop basis, in order to
excessive overhead on small links. In addition, certain events
triggered Join/Prune messages to be sent
3.2.1.1 Periodic Join/Prune
A router sends a periodic Join/Prune message to each distinct
neighbor associated with each (S,G), (*,G) and (*,*,RP) entry
Join/Prune messages are only sent if the RPF neighbor is a
neighbor. A periodic Join/Prune message sent to a particular
neighbor is constructed as follows
1 Each router determines the RP for a (*,G) entry by
the hash function described. The RP address (with RPT
WC bits set) is included in the join list of a
Join/Prune message under the following conditions
1 The Join/Prune message is being sent to the
neighbor toward the RP for an active (*,G) or (*,*,RP
entry,
2 The outgoing interface list in the (*,G) or (*,*,RP
entry is non-NULL, or the router is the DR on the
interface as the RPF neighbor
2 A particular source address, S, is included in the
list with the RPT and WC bits cleared under the
conditions
1 The Join/Prune message is being sent to the
neighbor toward S,
2 There exists an active (S,G) entry with the RPT-
flag cleared,
3 The oif list in the (S,G) entry is not null
3 A particular source address, S, is included in the
list with the RPT and WC bits cleared under the
conditions
1 The Join/Prune message is being sent to the
neighbor toward S,
Estrin, et. al. Experimental [Page 15]
RFC 2117 PIM-SM June 1997
2 There exists an active (S,G) entry with the RPT-
flag cleared,
3 The oif list in the (S,G) entry is null
4 A particular source address, S, is included in the
list with the RPT-bit set and the WC bit cleared under
following conditions
1 The Join/Prune message is being sent to the
neighbor toward the RP and there exists a (S,G)
with the RPT-bit flag set and null oif list,
2 The Join/Prune message is being sent to the
neighbor toward the RP, there exists a (S,G)
with the RPT-bit flag cleared and SPT-bit set, and
incoming interface toward S is different than
incoming interface toward the RP,
3 The Join/Prune message is being sent to the
neighbor toward the RP, and there exists a (*,G)
and (S,G) entry for a directly connected source
5 The RP address (with RPT and WC bits set) is included
the prune list if
1 The Join/Prune message is being sent to the
neighbor toward the RP and there exists a (*,G)
with a null oif list (see Section 3.5.2).
3.2.1.2 Triggered Join/Prune
In addition to periodic messages, the following events will
Join/Prune messages if as a result, a) a new entry is created, or b
the oif list changes from null to non-null or non-null to null.
contents of triggered messages are the same as the periodic
described above
1 Receipt of an indication from IGMP that the state
directly-connected- membership has changed (i.e., new
have just joined `membership indication' or all members
left), for a group G, may cause the last-hop router to
or modify corresponding (*,G) state. When IGMP
that there are no longer directly connected members, the
is removed from the oif list if the oif- timer is
running. A Join/Prune message is triggered if and only
a) a new entry is created, or b) the oif list changes
null to non-null or non-null to null, as follows :
Estrin, et. al. Experimental [Page 16]
RFC 2117 PIM-SM June 1997
1 If the receiving router does not have a route
for G the router creates a (*,G) entry, copies
oif list from the corresponding (*,*,RP)
(if it exists), and includes the interface
in the IGMP membership indication in the oif list
as always, the router never includes the entry's
in the oif list. The router sends a Join/
message towards the RP with the RP address and RPT-
and WC-bits set in the join list. Or
2 If a (S,G)RPT-bit or (*,G) entry already exists,
interface included in the IGMP membership
is added to the oif list (if it was not included already).
2 Receipt of a Join/Prune message for (S,G), (*,G) or (*,*,RP
will cause building or modifying corresponding state,
subsequent triggering of upstream Join/Prune messages, in
following cases
1 When there is no current route entry, the RP
included in the Join/Prune message is checked
the local RP-Set information. If it matches, an
will be created and the new entry will in turn
an upstream Join/Prune message. If the router has
RP-Set information it may discard the message,
optionally use the RP address included in the message
2 When the outgoing interface list of an (S,G)RPT-
entry becomes null, the triggered Join/Prune
will contain S in the prune list
3 When there exists a (S,G)RPT-bit with null oif list
and an (*,G) Join/Prune message is received,
arriving interface is added to the oif list and a (*,G
Join/Prune message is triggered upstream
4 When there exists a (*,G) with null oif list, and
(*,*,RP) Join/Prune message is received, the
interface is added to the oif list and a (*,*,RP
Join/Prune message is triggered upstream
3 Receipt of a packet that matches on a (S,G) entry
SPT-bit is cleared triggers the following if the
arrived on the correct incoming interface and there is
(*,G) or (*,*,RP) entry with a different
interface: a) the router sets the SPT-bit on the (S,G
entry, and b) the router sends a Join/Prune
towards the RP with S and a set RPT-bit in the prune list
Estrin, et. al. Experimental [Page 17]
RFC 2117 PIM-SM June 1997
4 When a Join/Prune message is received for a group G,
prune list is checked. If the prune list contains a
or RP for which the receiving router has a
active (S,G), (*,G) or (*,*,RP) entry, and whose iif
that on which the Join/Prune was received, then a join
(S,G), (*,G) or (*,*,RP) is triggered to override the prune
respectively. (This is necessary in the case of
downstream routers connected to a multi-access network.)
5 When the RP fails, the RP will not be included in
Bootstrap messages sent to all routers in that domain
This triggers the DRs to send (*,G) Join/Prune
towards new RP for the group, as determined by the RP-
and the hash function. As described earlier, PMBRs
(*,*,RP) joins towards each RP in the RP-Set
6 When an entry's Join/Prune-Suppression timer expires,
Join/Prune message is triggered upstream corresponding
that entry, even if the outgoing interface has
transitioned between null and non-null states
7 When the RPF neighbor changes (whether due to an Assert
changes in unicast routing), the router sets a random
timer (the Random-Delay-Join-Timer) whose expiration
sending of a Join/Prune message for the asserted route
to the Assert winner (if the Join/Prune Suppression timer
expired.)
We do not trigger prunes onto interfaces based on data packets.
packets that arrive on the wrong incoming interface are
dropped. However, on point-to-point interfaces triggered prunes
be sent as an optimization
3.2.1.3 Fragmentation: It is possible that a Join/Prune
constructed according to the preceding rules could exceed the MTU
a network. In this case, the message can undergo
fragmentation whereby information corresponding to different
can be sent in different messages. However, if a Join/Prune
must be fragmented the complete prune list corresponding to a group
must be included in the same Join/Prune message as the
RP-tree Join for G. If such semantic fragmentation is not possible
IP fragmentation should be used between the two neighboring hops
Estrin, et. al. Experimental [Page 18]
RFC 2117 PIM-SM June 1997
3.2.2 Receiving Join/Prune Messages When a router receives
Join/Prune message, it processes it as follows
The receiver of the Join/Prune notes the interface on which the
message arrived, call it I. The receiver then checks to see if
Join/Prune message was addressed to the receiving router
(i.e., the router's address appears in the Unicast Upstream
Router field of the Join/Prune message). (If the router is
to a multiaccess LAN, the message could be intended for a
router.) If the Join/Prune is for this router the following
are taken
For each group address G, in the Join/Prune message, the
join list is processed as follows. We refer to each address in
join list as Sj; Sj refers to the RP if the RPT- bit and WC-bit
both set. For each Sj in the join list of the Join/Prune message
1 If an address, Sj, in the join list of the Join/
message has the RPT-bit and WC-bit set, then Sj is the
address used by the downstream router(s) and the
actions are taken
1 If Sj is not the same as the receiving router's
mapping for G, the receiving router may ignore
Join/Prune message with respect to that group entry
If the router does not have any RP-Set information,
may use the address Sj included in the Join/
message as the RP for the group
2 If Sj is the same as the receiving router's RP
for G, the receiving router adds I to the
interface list of the (*,G) route entry (if there
no (*,G) entry, the router creates one first) and
the Oif-timer for that interface to the
specified in the Join/Prune message. In addition,
Oif-Deletion-Delay for that interface is set to 1/3
the Holdtime specified in the Join/Prune message
If a (*,*,RP) entry exists, for the RP associated
G, then the oif list of the newly created (*,G)
is copied from that (*,*,RP) entry
3 For each (Si,G) entry associated with group G, if
is not included in the prune list, and if I is not
iif then interface I is added to the oif list and
Oif-timer for that interface in each affected
is increased (never decreased) to the Holdtime
in the Join/Prune message. In addition, if
Estrin, et. al. Experimental [Page 19]
RFC 2117 PIM-SM June 1997
Oif-timer for that interface is increased,
Oif-Deletion-Delay for that interface is set to 1/3
the Holdtime specified in the Join/Prune message
If the group address in the Join/Prune message is `*'
then every (*,G) and (S,G) entry, whose group
hashes to the RP indicated in the (*,*,RP) Join/
message, is updated accordingly. A `*' in the
field of the Join/Prune is represented by a
address 224.0.0.0 and a group mask length of 4,
indicating a (*,*,RP) Join
4 If the (Si,G) entry has its RPT-bit flag set to 1,
its oif list is the same as the (*,G) oif list,
the (Si,G)RPT-bit entry is deleted
5 The incoming interface is set to the interface used
send unicast packets to the RP in the (*,G)
entry, i.e., RPF interface toward the RP
2 For each address, Sj, in the join list whose RPT-bit
WC-bit are not set, and for which there is no existing (Sj,G
route entry, the router initiates one. The router creates
(S,G) entry and copies all outgoing interfaces from
(S,G)RPT-bit entry, if it exists. If there is no (S,G) entry
the oif list is copied from the (*,G) entry; and if there
no (*,G) entry, the oif list is copied from the (*,*,RP
entry, if it exists. In all cases, the iif of the (S,G
entry is always excluded from the oif list
1 The outgoing interface for (Sj,G) is set to I.
incoming interface for (Sj,G) is set to the
used to send unicast packets to Sj (i.e., the
neighbor).
2 If the interface used to reach Sj, is the same as I
this represents an error (or a unicast routing change
and the Join/Prune must not be processed
Estrin, et. al. Experimental [Page 20]
RFC 2117 PIM-SM June 1997
3 For each address, Sj, in the join list of the Join/
message, for which there is an existing (Sj,G) route entry
1 If the RPT-bit is not set for Sj listed in
Join/Prune message, but the RPT-bit flag is set on
existing (Sj,G) entry, the router clears the RPT-
flag on the (Sj,G) entry, sets the incoming
to point towards Sj for that (Sj,G) entry, and sends
Join/Prune message corresponding to that entry
the new incoming interface;
2 If I is not the same as the existing
interface, the router adds I to the list of
interfaces
3 The Oif-timer for I is increased (never decreased
to the Holdtime included in the Join/Prune message
In addition, if the Oif-timer for that interface
increased, the Oif-Deletion-Delay for that
is set to 1/3rd the Holdtime specified in
Join/Prune message
4 The (Sj,G) entry's SPT bit is cleared until data
down the shortest path tree
For each group address G, in the Join/Prune message, the
prune list is processed as follows. We refer to each address in
prune list as Sp; Sp refers to the RP if the RPT-bit and WC-bit
both set. For each Sp in the prune list of the Join/Prune message
1 For each address, Sp, in the prune list whose RPT-bit
WC-bit are cleared
1 If there is an existing (Sp,G) route entry, the
lowers the Oif-timer for I to its Oif-Deletion-Delay
allowing for other downstream routers on a multi
access LAN to override the prune. However, on point
to-point links, the oif-timer is expired immediately
2 If the router has a current (*,G), or (*,*,RP),
entry, and if the existing (Sp,G) entry has its RPT
bit flag set to 1, then this (Sp,G)RPT-bit entry
maintained (not deleted) even if its
interface list is null
Estrin, et. al. Experimental [Page 21]
RFC 2117 PIM-SM June 1997
2 For each address, Sp, in the prune list whose RPT-bit
set and whose WC-bit cleared
1 If there is an existing (Sp,G) route entry, the
lowers the entry's Oif-timer for I to
Oif-Deletion-Delay, allowing for other
routers on a multi- access LAN to override the prune
However, on point-to-point links, the oif-timer
expired immediately
2 If the router has a current (*,G), or (*,*,RP),
entry, and if the existing (Sp,G) entry has
RPT- bit flag set to 1, then this (Sp,G)RPT-bit
is not deleted, and the Entry-timer is restarted,
if its outgoing interface list is null
3 If (*,G), or corresponding (*,*,RP), state exists,
there is no (Sp,G) entry, an (Sp,G)RPT-bit entry
created. The outgoing interface list is copied from
(*,G), or (*,*,RP), entry, with the interface, I,
which the prune was received, is deleted. Packets
the pruned source, Sp, match on this state and are
forwarded toward the pruned receivers
4 If there exists a (Sp,G) entry, with or without
RPT-bit set, the oif-timer for I is expired, and
Entry-timer is restarted
3 For each address, Sp, in the prune list whose RPT-bit
WC-bit are both set
1 If there is an existing (*,G) entry, with Sp as the
for G, the router lowers the entry's Oif-timer for
to its Oif-Deletion-Delay, allowing for
downstream routers on a multi-access LAN to override
prune. However, on point-to-point links, the oif-
is expired immediately
2 If the corresponding (*,*,RP) state exists, but
is no (*,G) entry, a (*,G) entry is created.
outgoing interface list is copied from (*,*,RP) entry
with the interface, I, on which the prune
received, deleted
For any new (S,G), (*,G) or (*,*,RP) entry created by
incoming Join/Prune message, the SPT-bit is cleared (and if
Join/Prune-Suppression timer is used, it is left off.)
Estrin, et. al. Experimental [Page 22]
RFC 2117 PIM-SM June 1997
If the entry has a Join/Prune-Suppression timer associated with it
and if the received Join/Prune does not indicate the router as
target, then the receiving router examines the join and prune
to see if any addresses in the list `completely- match'
(S,G), (*,G), or (*,*,RP) state for which the receiving
currently schedules Join/Prune messages. An element on the join
prune list `completely-matches' a route entry only if both the
addresses and RPT-bit flag are the same. If the incoming Join/
message completely matches an existing (S,G), (*,G), or (*,*,RP
entry and the Join/Prune arrived on the iif for that entry, then
router compares the Holdtime included in the Join/Prune message,
its own [Join/Prune-Holdtime]. If its own [Join/Prune-Holdtime]
lower, the Join/Prune-Suppression-timer is started at
[Join/Prune-Suppression-Timeout]. If the [Join/Prune-Holdtime]
equal, the tie is resolved in favor of the Join/Prune
originator that has the higher IP address. When the Join/Prune
expires, the router triggers a Join/Prune message for
corresponding entry(ies).
3.3 Register and Register-
When a source first starts sending to a group its packets
encapsulated in Register messages and sent to the RP. If the
rate warrants source-specific paths, the RP sets up source
state and starts sending (S,G) Join/Prune messages toward the source
with S in the join list
3.3.1 Sending Registers and Receiving Register-
Register messages are sent as follows
1 When a DR receives a packet from a directly
source,
1 If there is no corresponding (S,G) entry, and
router has RP-Set information, the DR creates one
the Register-Suppression-timer turned off and the
address set according to the hash function mapping
the corresponding group. The oif list is copied
existing (*,G) or (*,*,RP) entries, if they exist.
iif of the (S,G) entry is always excluded from the
list
2 If there is a (S,G) entry in existence, the DR
restarts the corresponding Entry-timer
Estrin, et. al. Experimental [Page 23]
RFC 2117 PIM-SM June 1997
When a PMBR (e.g., a router that connects the PIM-SM region
a dense mode region running DVMRP or PIM-DM) receives a
from a source in the dense mode region, the router treats
packet as if it were from a directly connected source.
separate document will describe the details
interoperability
2 If the new or previously-existing (S,G) entry's Register
Suppression-timer is not running, the data packet
encapsulated in a Register message and unicast to the
for that group. The data packet is also forwarded
to (S,G) state in the DR if the oif list is not null;
a receiver may join the SP-tree while the DR is
registering to the RP
3 If the (S,G) entry's Register-Suppression-timer is running
the data packet is not sent in a Register message, it
just forwarded according to the (S,G) oif list
When the DR receives a Register-Stop message, it restarts
Register-Suppression-timer in the corresponding (S,G) entry(ies)
[Register-Suppression-Timeout] seconds. If there is data to
registered, the DR may send a null Register (a Register message
a zero-length data portion in the inner IP packet) to the RP
[Probe-Time] seconds before the Register- Suppression-timer expires
to avoid sending occasional bursts of traffic to an RP unnecessarily
3.3.2 Receiving Register Messages and Sending Register-
When a router (i.e., the RP) receives a Register message, the
does the following
1 Decapsulates the data packet, and checks for
corresponding (S,G) entry
1 If a (S,G) entry with cleared (0) SPT bit exists,
the received Register does not have the Null
Register-Bit set to 1, the packet is forwarded;
the SPT bit is left cleared (0). If the SPT bit is 1,
the packet is dropped, and Register-Stop messages
triggered. Register-Stops should be rate-limited (
an implementation-specific manner) so that no
than a few are sent per round trip time. This
a high datarate stream of packets from triggering
large number of Register-Stop messages between
time that the first packet is received and the
when the source receives the first Register-Stop
Estrin, et. al. Experimental [Page 24]
RFC 2117 PIM-SM June 1997
2 If there is no (S,G) entry, but there is a (*,G
entry, and the received Register does not have
Null-Register-Bit set to 1, the packet is
according to the (*,G) entry
3 If there is a (*,*,RP) entry but no (*,G) entry,
the Register received does not have the Null
Register-Bit set to 1, a (*,G) or (S,G) entry
created and the oif list is copied from the (*,*,RP
entry to the new entry. The packet is
according to the created entry
4 If there is no G or (*,*,RP) entry corresponding to G
the packet is dropped, and a Register-Stop
triggered
5 A "Border bit" bit is added to the Register message
to facilitate interoperability mechanisms. PMBRs
this bit when registering for external sources (
Section 2.7). If the "Border bit" is set in
Register, the RP does the following
1 If there is no matching (S,G) state, but
exists (*,G) or (*,*,RP) entry, the RP creates
(S,G) entry, with a `PMBR' field. This
holds the source of the Register (i.e. the
IP address of the register packet). The
triggers a (S,G) join towards the source of
data packet, and clears the SPT bit for the (S,G
entry. If the received Register is not a `
Register' the packet is forwarded according
the created state. Else
2 If the `PMBR' field for the corresponding (S,G
entry matches the source of the Register packet
and the received Register is not a `
Register', the decapsulated packet is
to the oif list of that entry. Else
3 If the `PMBR' field for the corresponding (S,G
entry matches the source of the Register packet
the decapsulated packet is forwarded to the
list of that entry,
4 The packet is dropped, and a Register-stop
triggered towards the source of the Register
Estrin, et. al. Experimental [Page 25]
RFC 2117 PIM-SM June 1997
The (S,G) Entry-timer is restarted by Registers arriving
that source to that group
2 If the matching (S,G) or (*,G) state contains a null
list, the RP unicasts a Register-Stop message to the
of the Register message; in the latter case, the source
address field, within the Register-Stop message, is set
the wildcard value (all 0's). This message is not
by intermediate routers, hence no (S,G) state
constructed between the RP and the source
3 If the Register message arrival rate warrants it and
is no existing (S,G) entry, the RP sets up a (S,G)
entry with the outgoing interface list, excluding iif(S,G),
copied from the (*,G) outgoing interface list, its SPT-
is initialized to 0. If a (*,G) entry does not exist,
there exists a (*,*,RP) entry with the RP corresponding
G , the oif list for (S,G) is copied -excluding the iif
from that (*,*,RP) entry
A timer (Entry-timer) is set for the (S,G) entry and
timer is restarted by receipt of data packets for (S,G).
The (S,G) entry causes the RP to send a Join/Prune
for the indicated group towards the source of the
message
If the (S,G) oif list becomes null, Join/Prune
will not be sent towards the source, S
3.4 Multicast Data Packet
Processing a multicast data packet involves the following steps
1 Lookup route state based on a longest match of the
address, and an exact match of the destination address
the data packet. If neither S, nor G, find a longest
entry, and the RP for the packet's destination
address has a corresponding (*,*,RP) entry, then
longest match does not require an exact match on
destination group address. In summary, the longest match
performed in the following order: (1) (S,G), (2) (*,G).
neither is matched, then a lookup is performed on (*,*,RP
entries
2 If the packet arrived on the interface found in
matching-entry's iif field, and the oif list is
null
Estrin, et. al. Experimental [Page 26]
RFC 2117 PIM-SM June 1997
1 Forward the packet to the oif list for that
and restart the Entry-timer if the matching entry
(S,G). Optionally, the (S,G) Entry-timer may
restarted by periodic checking of the matching
count
2 If the entry is a (S,G) entry with a cleared SPT-bit
and a (*,G) or associated (*,*,RP) also exists
incoming interface is different than that for (S,G),
set the SPT-bit for the (S,G) entry and trigger
(S,G) RPT-bit prune towards the RP
3 If the source of the packet is a directly-
host and the router is the DR on the
interface, check the Register-Suppression-
associated with the (S,G) entry. If it is not running
then the router encapsulates the data packet in
register message and sends it to the RP
This covers the common case of a packet arriving on the
interface to the source or RP and being forwarded to
joined branches. It also detects when packets arrive on
SP-tree, and triggers their pruning from the RP-tree. If
is the DR for the source, it sends data
encapsulated in Registers to the RPs
3 If the packet matches to an entry but did not arrive on
interface found in the entry's iif field, check
SPT-bit of the entry. If the SPT-bit is set, drop
packet. If the SPT-bit is cleared, then lookup the (*,G),
or (*,*,RP), entry for G. If the packet arrived on
iif found in (*,G), or the corresponding (*,*,RP),
forward the packet to the oif list of the
entry. This covers the case when a data packet matches on
(S,G) entry for which the SP-tree has not yet
completely established upstream
4 If the packet does not match any entry, but the source
the data packet is a local, directly-connected host,
the router is the DR on a multi-access LAN and has RP-
information, the DR uses the hash function to determine
RP associated with the destination group, G. The DR
a (S,G) entry, with the Register-Suppression-timer
running, encapsulates the data packet in a Register
and unicasts it to the RP
5 If the packet does not match to any entry, and it is not
local host or the router is not the DR, drop the packet
Estrin, et. al. Experimental [Page 27]
RFC 2117 PIM-SM June 1997
3.4.1 Data triggered switch to shortest path tree (SP-tree
Different criteria can be applied to trigger switching over from
RP-based shared tree to source-specific, shortest path trees
One proposed example is to do so based on data rate. For example
when a (*,G), or corresponding (*,*,RP), entry is created, a data
counter may be initiated at the last-hop routers. The counter
incremented with every data packet received for directly
members of an SM group, if the longest match is (*,G) or (*,*,RP).
and when the data rate for the group exceeds a certain
threshold (t1), the router initiates `source-specific' data
counters for the following data packets. Then, each counter for
source, is incremented when packets matching on (*,G), or (*,*,RP),
are received from that source. If the data rate from the
source exceeds a configured threshold (t2), a (S,G) entry is
and a Join/Prune message is sent towards the source. If the
interface for (S,G) is not the same as that for (*,G) -or (*,*,RP),
then the SPT-bit is cleared in the (S,G) entry
Other configured rules may be enforced to cause or
establishment of (S,G) state
3.5
Asserts are used to resolve which of the parallel route