As per Relevance of the word multicast, we have this rfc below:
Network Working Group D.
Request for Comments: 2362
Obsoletes: 2117 D.
Category: Experimental
A.
D.
S.
M.
V.
C.
P.
L.
June 1998
Protocol Independent Multicast-Sparse Mode (PIM-SM):
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
Estrin, et. al. Experimental [Page 1]
RFC 2362 PIM-SM June 1998
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 2362 PIM-SM June 1998
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
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
Estrin, et. al. Experimental [Page 3]
RFC 2362 PIM-SM June 1998
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
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
Estrin, et. al. Experimental [Page 4]
RFC 2362 PIM-SM June 1998
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
(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
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
Estrin, et. al. Experimental [Page 5]
RFC 2362 PIM-SM June 1998
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.
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
Estrin, et. al. Experimental [Page 6]
RFC 2362 PIM-SM June 1998
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
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) distributed
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
Estrin, et. al. Experimental [Page 7]
RFC 2362 PIM-SM June 1998
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
2.7 Interoperation with dense mode protocols such as
In order to interoperate with networks that run dense-mode,
and prune, protocols, such as DVMRP, all packets generated within
PIM-SM region must be pulled out to that region's PIM
Border Routers (PMBRs) and injected (i.e., broadcast) into the
network. A PMBR is a router that sits at the boundary of a PIM-
domain and interoperates with other types of multicast routers
as those that run DVMRP. Generally a PMBR would speak both
and implement interoperability functions not required by regular
Estrin, et. al. Experimental [Page 8]
RFC 2362 PIM-SM June 1998
routers. To support interoperability, a special entry type,
to as (*,*,RP), must be supported by all PIM routers. For
reason we include details about (*,*,RP) entry handling in
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
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
Estrin, et. al. Experimental [Page 9]
RFC 2362 PIM-SM June 1998
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 entry
the incoming interface differs from the incoming
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 the same
one of those, the packet is forwarded to the oif-list
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
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
Estrin, et. al. Experimental [Page 10]
RFC 2362 PIM-SM June 1998
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 election
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
layer address assumes the role of DR. Each router connected to
multi-access LAN sends the Hellos periodically in order to adapt
changes in router status
Parallel paths to a source or the RP--Assert process
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
packet. The router with the smallest numerical metric (with
broken by highest address) will become the forwarder. All
Estrin, et. al. Experimental [Page 11]
RFC 2362 PIM-SM June 1998
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 suppression
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 network layer address),
timer (the Join/Prune-Suppression-timer) in the recipient's
entry may be started to suppress further Join/Prune messages.
this timer expires, the recipient triggers a Join/Prune message,
Estrin, et. al. Experimental [Page 12]
RFC 2362 PIM-SM June 1998
resumes sending periodic Join/Prunes, for this entry.
Join/Prune-Suppression-timer should be restarted each time
Join/Prune message 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 2362 PIM-SM June 1998
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.
are sent on all types of communication links
3.1.2 Receiving
When a router receives a Hello message, it stores the network
address for that neighbor, sets its Neighbor-timer for the
sender to the Holdtime included in the Hello, and determines
Designated Router (DR) for that interface. The highest
system is elected DR. Each Hello received causes the DR's address
be updated
When a router that is the active DR receives a Hello from a
neighbor (i.e., from an address that is not yet in the DRs
table), the DR unicasts its most recent RP-set information to the
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 network layer address. If an interface has
down, the router may optionally time out all PIM neighbors
with the 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
Estrin, et. al. Experimental [Page 14]
RFC 2362 PIM-SM June 1998
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
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
Periodic Join/Prune Messages
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 and
bits set) is included in the join list of a periodic Join/
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
Estrin, et. al. Experimental [Page 15]
RFC 2362 PIM-SM June 1998
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,
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) entry
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) entry with
RPT-bit flag cleared and SPT-bit set, and the
interface toward S is different than the incoming
toward the RP,
3 The Join/Prune message is being sent to the
neighbor toward the RP, and there exists a (*,G) entry
(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) entry
a null oif list (see Section 3.5.2).
Triggered Join/Prune Messages
In addition to periodic messages, the following events
trigger Join/Prune messages if as a result, a) a new entry
created, or b) the oif list changes from null to non-null or non
null to null. The contents of triggered messages are the same
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
Estrin, et. al. Experimental [Page 16]
RFC 2362 PIM-SM June 1998
left), for a group G, may cause the last-hop router to build
modify corresponding (*,G) state. When IGMP indicates
there are no longer directly connected members, the oif
removed from the oif list if the oif-timer is not running.
Join/Prune message is triggered if and only if a) a new entry
created, or b) the oif list changes from null to non-null
non-null to null, as follows
1 If the receiving router does not have a route
for G the router creates a (*,G) entry, copies the oif
from the corresponding (*,*,RP) entry (if it exists),
includes the interface included in the IGMP
indication in the oif list; as always, the router
includes the entry's iif in the oif list. The router
a Join/Prune message towards the RP with the RP address
RPT-bit 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 indication
added to the oif list (if it was not included already).
2 Receipt of a Join/Prune message for (S,G), (*,G)
(*,*,RP) will cause building or modifying corresponding state
and subsequent triggering of upstream Join/Prune messages,
the following cases
1 When there is no current route entry, the RP
included in the Join/Prune message is checked against
local RP-Set information. If it matches, an entry will
created and the new entry will in turn trigger an
Join/Prune message. If the router has no RP-Set
it may discard the message, or optionally use the
address included in the message
2 When the outgoing interface list of an (S,G)RPT-
entry becomes null, the triggered Join/Prune message
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, the
interface is added to the oif list and a (*,G) Join/
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
Estrin, et. al. Experimental [Page 17]
RFC 2362 PIM-SM June 1998
3 Receipt of a packet that matches on a (S,G) entry
SPT-bit is cleared triggers the following if the packet
on the correct incoming interface and there is a (*,G)
(*,*,RP) entry with a different incoming interface: a)
router sets the SPT-bit on the (S,G) entry, and b) the
sends a Join/Prune message towards the RP with S in the
list and the RPT-bit set
4 Receipt of a packet at the DR from a directly
source S, on the subnet containing the address S, triggers
Join/Prune message towards the RP with S in the prune list
the RPT-bit set under the following conditions: a) there is
matching (S,G) state, and b) there exists a (*,G) or (*,*,RP
for which the DR is not the RP
5 When a Join/Prune message is received for a group G,
prune list is checked. If the prune list contains a source or
for which the receiving router has a corresponding active (S,G),
(*,G) or (*,*,RP) entry, and whose iif is that on which
Join/Prune was received, then a join for (S,G), (*,G)
(*,*,RP) is triggered to override the prune, respectively. (
is necessary in the case of parallel downstream
connected to a multi-access network.)
6 When the RP fails, the RP will not be included in
Bootstrap messages sent to all routers in that domain.
triggers the DRs to send (*,G) Join/Prune messages towards
new RP for the group, as determined by the RP-Set and the
function. As described earlier, PMBRs trigger (*,*,RP)
towards each RP in the RP-Set
7 When an entry's Join/Prune-Suppression timer expires,
Join/Prune message is triggered upstream corresponding to
entry, even if the outgoing interface has not
between null and non-null states
8 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 entry
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
Estrin, et. al. Experimental [Page 18]
RFC 2362 PIM-SM June 1998
aragraphFragmentation 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
3.2.2 Receiving Join/Prune Messages When a router
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.
the router does not have any RP-Set information, it may
the address Sj included in the Join/Prune message as the
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 is
(*,G) entry, the router creates one first) and sets
Oif-timer for that interface to the Holdtime specified
the Join/Prune message. In addition, the Oif-Deletion-
for that interface is set to 1/3rd the Holdtime
Estrin, et. al. Experimental [Page 19]
RFC 2362 PIM-SM June 1998
in the Join/Prune message. If a (*,*,RP) entry exists,
the RP associated with G, then the oif list of the
created (*,G) entry is copied from that (*,*,RP) entry
3 For each (Si,G) entry associated with group G: i)
Si is not included in the prune list, ii) if I is not
the same subnet as the address Si, and iii) if I is not
iif, then interface I is added to the oif list and
Oif-timer for that interface in each affected entry
increased (never decreased) to the Holdtime included in
Join/Prune message. In addition, if the Oif-timer for
interface is increased, the Oif-Deletion-Delay for
interface is set to 1/3rd the Holdtime specified in
Join/Prune message
If the group address in the Join/Prune message is `*'
every (*,G) and (S,G) entry, whose group address hashes
the RP indicated in the (*,*,RP) Join/Prune message,
updated accordingly. A `*' in the group field of
Join/Prune is represented by a group address 224.0.0.0
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, then
(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) route 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 is
(*,G) entry, the oif list is copied from the (*,*,RP) entry,
it exists. In all cases, the iif of the (S,G) entry is
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 interface
to send unicast packets to Sj (i.e., the RPF neighbor).
2 If the interface used to reach Sj, is the same as I
this represents an error (or a unicast routing change)
the Join/Prune must not be processed
Estrin, et. al. Experimental [Page 20]
RFC 2362 PIM-SM June 1998
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-bit
on the (Sj,G) entry, sets the incoming interface to
towards Sj for that (Sj,G) entry, and sends a Join/
message corresponding to that entry through the
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)
the Holdtime included in the Join/Prune message.
addition, if the Oif-timer for that interface is increased
the Oif-Deletion-Delay for that interface is set to 1/3
the Holdtime specified in the 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,
associated prune list is processed as follows. We refer to
address in the prune list as Sp; Sp refers to the RP if the RPT
bit and WC-bit are both set. For each Sp in the prune list of
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 entry's 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-
flag set to 1, then this (Sp,G)RPT-bit entry is
(not deleted) even if its outgoing interface list is null
2 For each address, Sp, in the prune list whose RPT-bit
set and whose WC-bit cleared
Estrin, et. al. Experimental [Page 21]
RFC 2362 PIM-SM June 1998
1 If there is an existing (Sp,G) route entry, the
lowers the entry's 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-
flag set to 1, then this (Sp,G)RPT-bit entry is
deleted, and the Entry-timer is restarted, even if
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 is
. The outgoing interface list is copied from the (*,G),
(*,*,RP), entry, with the interface, I, on which the
was received, is deleted. Packets from the pruned source
Sp, match on this state and are not forwarded toward
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 I to
Oif-Deletion-Delay, allowing for other downstream
on a multi-access LAN to override the prune. However,
point-to-point links, the oif-timer is expired immediately
2 If the corresponding (*,*,RP) state exists, but
is no (*,G) entry, a (*,G) entry is created. The
interface list is copied from (*,*,RP) entry, with
interface, I, on which the prune was 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.)
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
Estrin, et. al. Experimental [Page 22]
RFC 2362 PIM-SM June 1998
prune list `completely-matches' a route entry only if both
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 network layer address. When
Join/Prune timer expires, the router triggers a Join/Prune
for the 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, S, on the subnet containing the address S
1 If there is no corresponding (S,G) entry, and
router has RP-Set information, and the DR is not the RP
G, the DR creates an (S,G) entry with the Register
Suppression-timer turned off and the RP address
according to the hash function mapping for
corresponding group. The oif list is copied from
(*,G) or (*,*,RP) entries, if they exist. The iif of
(S,G) entry is always excluded from the oif list. If
exists a (*,G) or (*,*,RP) entry, the DR sends a Join/
message towards the RP with S in the prune list and
RPT-bit set
2 If there is a (S,G) entry in existence, the DR
restarts the corresponding Entry-timer
When a PMBR (e.g., a router that connects the PIM-SM
to a dense mode region running DVMRP or PIM-DM) receives
packet from a source in the dense mode region, the
Estrin, et. al. Experimental [Page 23]
RFC 2362 PIM-SM June 1998
treats the packet as if it were from a directly
source. A 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 RP
that group. The data packet is also forwarded according to (S,G
state in the DR if the oif list is not null; since a
may join the SP-tree while the DR is still registering to
RP
3 If the (S,G) entry's Register-Suppression-timer is running
the data packet is not sent in a Register message, it is
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 packet) to the RP, [Probe
Time] seconds before the Register-Suppression-timer expires, to
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-
set to 1, the packet is forwarded; and the SPT bit is
cleared (0). If the SPT bit is 1, the packet is dropped
and Register-Stop messages are triggered. Register-
should be rate-limited (in an implementation-
manner) so that no more than a few are sent per round
time. This prevents a high datarate stream of packets
triggering a large number of Register-Stop messages
the time that the first packet is received and the
when the source receives the first Register-Stop
2 If there is no (S,G) entry, but there is a (*,G
entry, and the received Register does not have the Null
Register-Bit set to 1, the packet is forwarded according
the (*,G) entry
Estrin, et. al. Experimental [Page 24]
RFC 2362 PIM-SM June 1998
3 If there is a (*,*,RP) entry but no (*,G) entry,
the Register received does not have the Null-Register-
set to 1, a (*,G) or (S,G) entry is created and the
list is copied from the (*,*,RP) entry to the new entry
The packet is forwarded 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 is triggered
5 A "Border bit" bit is added to the Register message
to facilitate interoperability mechanisms. PMBRs set
bit when registering for external sources (see
2.7). If the "Border bit" is set in the Register
the RP does the following
1 If there is no matching (S,G) state, but
exists (*,G) or (*,*,RP) entry, the RP creates a (S,G
entry, with a `PMBR' field. This field holds
source of the Register (i.e. the outer network
address of the register packet). The RP triggers
(S,G) join towards the source of the data packet,
clears the SPT bit for the (S,G) entry. If
received Register is not a `null Register' the
is forwarded according to the created state. Else
2 If the `PMBR' field for the corresponding (S,G
entry matches the source of the Register packet,
the received Register is not a `null Register',
decapsulated packet is forwarded to the oif list
that entry. Else
3 If the `PMBR' field for the corresponding (S,G
entry matches the source of the Register packet,
decapsulated packet is forwarded to the oif list
that entry,
4 The packet is dropped, and a Register-stop
triggered towards the source of the Register
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 source
the Register message; in the latter case, the source-
field, within the Register-Stop message, is set to the
Estrin, et. al. Experimental [Page 25]
RFC 2362 PIM-SM June 1998
value (all 0's). This message is not processed by
routers, hence no (S,G) state is constructed between the RP
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) route
with the outgoing interface list, excluding iif(S,G),
from the (*,G) outgoing interface list, its SPT-bit
initialized to 0. If a (*,G) entry does not exist, but
exists a (*,*,RP) entry with the RP corresponding to G , the
list for (S,G) is copied - excluding the iif - from
(*,*,RP) entry
A timer (Entry-timer) is set for the (S,G) entry and this
is restarted by receipt of data packets for (S,G). The (S,G
entry causes the RP to send a Join/Prune message for
indicated group towards the source of the register message
If the (S,G) oif list becomes null, Join/Prune messages will
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 in
data packet. If neither S, nor G, find a longest match entry
and the RP for the packet's destination group address has
corresponding (*,*,RP) entry, then the longest match does
require an exact match on the destination group address.
summary, the longest match is performed in the following order
(1) (S,G), (2) (*,G). If neither is matched, then a lookup
performed on (*,*,RP) entries
2 If the packet arrived on the interface found in
matching-entry's iif field, and the oif list is not null
1 Forward the packet to the oif list for that entry
excluding the subnet containing S, and restart the Entry
timer if the matching entry is (S,G). Optionally,
(S,G) Entry-timer may be restarted by periodic checking
the matching packet count
Estrin, et. al. Experimental [Page 26]
RFC 2362 PIM-SM June 1998
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),
the SPT-bit for the (S,G) entry and trigger an (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 receiving interface
check the Register-Suppression-timer associated with
(S,G) entry. If it is not running, then the
encapsulates the data packet in a register message
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 the SPT-
of the entry. If the SPT-bit is set, drop the packet.
the SPT-bit is cleared, then lookup the (*,G), or (*,*,RP),
entry for G. If the packet arrived on the iif found
(*,G), or the corresponding (*,*,RP), forward the packet
the oif list of the matching entry. This covers the
when a data packet matches on a (S,G) entry for which
SP-tree has not yet been 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
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
Estrin, et. al. Experimental [Page 27]
RFC 2362 PIM-SM June 1998
One proposed example is to do so based on data rate. For example
when a (*,G), or corresponding (*,*,RP), entry is created, a
rate counter may be initiated at the last-hop routers. The
is 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 routers
to a multi-access LAN is responsible for forwarding packets onto
LAN
3.5.1 Sending
The following Assert rules are provided when a multicast packet
received on an outgoing multi-access interface "I" of an
active (S,G), (*,G) or (*,*,RP) entry
1 Do unicast routing table lookup on source address from
packet, and send assert on interface "I" for source address
data packet; include metric preference of routing protocol
metric from routing table lookup
2 If route is not found, use metric preference of 0x7
and metric 0xffffffff
When an assert is sent for a (*,G) entry, the first bit in the
preference (the RPT-bit) is set to 1, indicating the data packet
routed down the RP-tree
Asserts should be rate-limited in an implementation-specific manner
Estrin, et. al. Experimental [Page 28]
RFC 2362 PIM-SM June 1998
3.5.2 Receiving
When an Assert is received the router performs a longest match on
source and group address in the Assert message, only active
-- that have packet forwarding state -- are matched. The
checks the first bit of the metric preference (RPT-bit).
1 If the RPT-bit is set, the router first does a match
(*,G), or (*,*,RP), entries; if no matching entry is found,
ignores the Assert
2 If the RPT-bit is not set in the Assert, the router
does a match on (S,G) entries; if no matching entry is found
the router matches (*,G) or (*,*,RP) entries
Receiving Asserts on an entry's outgoing interface
If the interface that received the Assert message is in the
list of the matched entry, then this Assert is processed by
router as follows
1 If the Assert's RPT-bit is set and the matching entry
(*,*,RP), the router creates a (*,G) entry. If the Assert'
RPT-bit is cleared and the matching entry is (*,G), or (*,*,RP),
the router creates a (S,G)RPT-bit entry. Otherwise, no
entry is created in response to the Assert
2 The router then compares the metric values received in
Assert with the metric values associated with the matched entry
The RPT-bit and metric preference (in that order) are treated
the high-order part of an Assert metric comparison. If the
in the Assert is less than the router's value (with ties
by the IP address, where higher network layer address wins),
delete the interface from the entry. When the deletion
for a (*,G) or (*,*,RP) entry , the interface is also
from any associated (S,G)RPT-bit or (*,G) entries, respectively
The Entry-timer for the affected entries is restarted
3 If the router has won the election the router keeps
interface in its outgoing interface list. It acts as
forwarder for the LAN
The winning router sends an Assert message containing its own
to that outgoing interface. This will cause other routers on the
to prune that interface from their route entries. The winning
sets the RPT-bit in the Assert message if a (*,G) or (S,G)RPT-
entry was matched
Estrin, et. al. Experimental [Page 29]
RFC 2362 PIM-SM June 1998
Receiving Asserts on an entry's incoming
If the Assert arrived on the incoming interface of an existing (S,G),
(*,G), or (*,*,RP) entry, the Assert is processed as follows. If
Assert message does not match the entry, exactly, it is ignored; i.e
longest-match is not used in this case. If the Assert message
match exactly, then
1 Downstream routers will select the upstream router with
smallest metric preference and metric as their RPF neighbor.
two metrics are the same, the highest network layer address
chosen to break the tie. This is important so that
routers send subsequent Joins/Prunes (in SM) to the
neighbor. An Assert-timer is initiated when changing the
neighbor to the Assert winner. When the timer expires,
router resets its RPF neighbor according to its unicast
tables to capture network dynamics and router failures
2 If the downstream routers have downstream members, and
the Assert caused the RPF neighbor to change, the
routers must trigger a Join/Prune message to inform the
router that packets are to be forwarded on the multi-
network
3.6 Candidate-RP-Advertisements and Bootstrap
Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM
unicast to the BSR by those routers that are configured
Candidate-RPs (C-RPs).
Bootstrap messages are periodic PIM messages originated by
Bootstrap router (BSR) within a domain, and forwarded hop-by-hop
distribute the current RP-set to all routers in that domain
The Bootstrap messages also support a simple mechanism by which
Candidate BSR (C-BSR) with the highest BSR-priority and
(referred to as the preferred BSR) is elected as the BSR for
domain. We recommend that each router configured as a C-RP also
configured as a C-BSR. Sections 3.6.2 and 3.6.3 describe the
function of Bootstrap messages as the vehicle for BSR election
RP-Set distribution
A Finite State Machine description of the BSR election and RP-
distribution mechanisms is included in Appendix II
Estrin, et. al. Experimental [Page 30]
RFC 2362 PIM-SM June 1998
3.6.1 Sending Candidate-RP-
C-RPs periodically unicast C-RP-Advs to the BSR for that domain.
interval for sending these messages is subject to local
at the C-RP
Candidate-RP-Advertisements carry group address and group
fields. This enables the advertising router to limit
advertisement to certain prefixes or scopes of groups.
advertising router may enforce this scope acceptance when
Registers or Join/Prune messages. C-RPs should send C-RP-
messages with the `Priority' field set to `0'.
3.6.2 Receiving C-RP-Advs and Originating
Upon receiving a C-RP-Adv, a router does the following
1 If the router is not the elected BSR, it ignores
message,
2 The BSR adds the RP address to its local pool of
RPs, according to the associated group prefix(es) in the C-RP
Adv message. The Holdtime in the C-RP-Adv message is also
with the corresponding RP, to be included later in the
message. The BSR may apply a local policy to limit the number
Candidate RPs included in the Bootstrap message. The BSR
override the prefix indicated in a C-RP-Adv unless
`Priority' field is not zero
The BSR keeps an RP-timer per RP in its local RP-set. The RP-timer
initialized to the Holdtime in the RP's C-RP-Adv. When the
expires, the corresponding RP is removed from the RP-set. The RP
timer is restarted by the C-RP-Advs from the corresponding RP
The BSR also uses its Bootstrap-timer to periodically send
messages. In particular, when the Bootstrap-timer expires, the
originates a Bootstrap message on each of its PIM interfaces.
reduce the bootstrap message overhead during partition healing,
BSR should set a random time (as a function of the priority
address) after which the Bootstrap message is originated only if
other preferred Bootstrap message is received. For details
appendix 6.2. The message is sent with a TTL of 1 to the `ALL-PIM
ROUTERS' group. In steady state, the BSR originates
messages periodically. At startup, the Bootstrap-timer
initialized to [Bootstrap-Timeout], causing the first
message to be originated only when and if the timer expires.
Estrin, et. al. Experimental [Page 31]
RFC 2362 PIM-SM June 1998
timer details, see Section 3.6.3. A DR unicasts a Bootstrap
to each new PIM neighbor, i.e., after the DR receives the neighbor'
Hello message (it does so even if the new neighbor becomes the DR).
The Bootstrap message is subdivided into sets of group-prefix,RP
Count,RP-addresses. For each RP-address, the corresponding
is included in the "RP-Holdtime" field. The format of the
message allows `semantic fragmentation', if the length of
original Bootstrap message exceeds the packet maximum boundaries (
Section 4). However, we recommend against configuring a large
of routers as C-RPs, to reduce the semantic fragmentation required
3.6.3 Receiving and Forwarding
Each router keeps a Bootstrap-timer, initialized to [Bootstrap
Timeout] at startup
When a router receives Bootstrap message sent to `ALL-PIM-ROUTERS
group, it performs the following
1 If the message was not sent by the RPF neighbor towards
BSR address included, the message is dropped.
2 If the included BSR is not preferred over, and not
to, the currently active BSR
1 If the Bootstrap-timer has not yet expired, or if
receiving router is a C-BSR, then the Bootstrap message
dropped.
2 If the Bootstrap-timer has expired and the
router is not a C-BSR, the receiving router stores the RP
Set and BSR address and priority found in the message,
restarts the timer by setting it to [Bootstrap-Timeout].
The Bootstrap message is then forwarded out all
interfaces, excluding the one over which the
arrived, to `ALL-PIM-ROUTERS' group, with a TTL of 1.
3 If the Bootstrap message includes a BSR address that
preferred over, or equal to, the currently active BSR,
router restarts its Bootstrap-timer at [Bootstrap-Timeout
seconds. and stores the BSR address and RP-Set information
The Bootstrap message is then forwarded out all PIM interfaces
excluding the one over which the message arrived, to `ALL-PIM
ROUTERS' group, with a TTL of 1.
Estrin, et. al. Experimental [Page 32]
RFC 2362 PIM-SM June 1998
4 If the receiving router has no current RP set
and the Bootstrap was unicast to it from a directly
neighbor, the router stores the information as its new RP-set
This covers the startup condition when a newly booted
obtains the RP-Set and BSR address from its DR
When a router receives a new RP-Set, it checks if each of the
referred to by existing state (i.e., by (*,G), (*,*,RP),
(S,G)RPT-bit entries) is in the new RP-Set. If an RP is not in
new RP-set, that RP is considered unreachable and the hash
(see below) is re-performed for each group with locally active
that previously hashed to that RP. This will cause those groups to
distributed among the remaining RPs. When the new RP-Set contains
new RP, the value of the new RP is calculated for each group
by that C-RP's Group-prefix. Any group for which the new RP's
is greater than the previously active RP's value is switched over
the new RP
3.7 Hash
The hash function is used by all routers within a domain, to map
group to one of the C-RPs from the RP-Set. For a particular group, G
the hash function uses only those C-RPs whose Group-prefix covers G
The algorithm takes as input the group address, and the addresses
the Candidate RPs, and gives as output one RP address to be used
The protocol requires that all routers hash to the same RP within
domain (except for transients). The following hash function must
used in each router
1 For RP addresses in the RP-Set, whose Group-prefix
G, select the RPs with the highest priority (i.e.
`Priority' value), and compute a value
Value(G,M,C(i))=
(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31
where C_i is the RP address and M is a hash-mask included
Bootstrap messages. The hash-mask allows a small number
consecutive groups (e.g., 4) to always hash to the same RP.
instance, hierarchically-encoded data can be sent on
group addresses to get the same delay and fate-
characteristics
For address families other than IPv4, a 32-bit digest to be
as C_i must first be derived from the actual RP address. Such
digest method must be used consistently throughout the
Estrin, et. al. Experimental [Page 33]
RFC 2362 PIM-SM June 1998
domain. For IPv6 addresses, we recommend using the
IPv4 address for an IPv4-compatible address, and the CRC-32
checksum [7] of all other IPv6 addresses
2 From the RPs with the highest priority (i.e.
`Priority' value), the candidate with the highest
value is then chosen as the RP for that group, and its
and hash value are stored with the entry created
Ties between RPs having the same hash value and priority,
broken in advantage of the highest address
The hash function algorithm is invoked by a DR, upon reception of
packet, or IGMP membership indication, for a group, for which the
has no entry. It is invoked by any router that has (*,*,RP)
when a packet is received for which there is no corresponding (S,G
or (*,G) entry. Furthermore, the hash function is invoked by
routers upon receiving a (*,G) or (*,*,RP) Join/Prune message
3.8 Processing Timer
In this subsection, we enumerate all timers that have been
or implied. Since some critical timer events are not associated
the receipt or sending of messages, they are not fully covered
earlier subsections
Timers are implemented in an implementation-specific manner.
example, a timer may count up or down, or may simply expire at
specific time. Setting a timer to a value T means that it will
after T seconds
3.8.1 Timers related to tree
Each (S,G), (*,G), and (*,*,RP) route entry has multiple
associated with it: one for each interface in the outgoing
list, one for the multicast routing entry itself, and one
Join/Prune-Suppression-Timer. Each (S,G) and (*,G) entry also has
Assert-timer and a Random-Delay-Join-Timer for use with Asserts.
addition, DR's have a Register-Suppression-timer for each (S,G)
and every router has a single Join/Prune-timer. (A router
optionally keep separate Join/Prune-timers for different
or route entries if different Join/Prune periods are desired.)
* [Join/Prune-Timer] This timer is used for
sending aggregate Join/Prune messages. To
synchronization among routers booting simultaneously, it
initially set to a random value between 1 and [Join/Prune
Period]. When it expires, the timer is immediately
Estrin, et. al. Experimental [Page 34]
RFC 2362 PIM-SM June 1998
to [Join/Prune-Period]. A Join/Prune message is then sent
each interface. This timer should not be restarted by
events
* [Join/Prune-Suppression-Timer (kept per route entry)]
route entry's (optional) Join/Prune-Suppression-Timer may
used to suppress duplicate joins from multiple
routers on the same LAN. When a Join message is received
a neighbor on the entry's incoming interface in which
included Holdtime is higher than the router's
[Join/Prune-Holdtime] (with ties broken by higher
layer address), the timer is set to [Join/Prune-Suppression
Timeout], with some random jitter introduced to
synchronization of triggered Join/Prune messages
expiration. (The random timeout value must be < 1.5 *
[Join/Prune-Period] to prevent losing data after 2
Join/Prunes.) The timer is restarted every time a
Join/Prune message (with higher Holdtime/IP address) for
entry is received on its incoming interface. While the
is running, Join/Prune messages for the entry are not sent
This timer is idle (not running) for point-to-point links
* [Oif-Timer (kept per oif for each route entry)] A timer
each oif of a route entry is used to time out that oif
Because some of the outgoing interfaces in an (S,G) entry
copied from the (*,G) outgoing interface list, they may
have explicit (S,G) join messages from some of the
routers (i.e., where members are joining to the (*,G)
only). Thus, when an Oif-timer is restarted in a (*,G) entry
the Oif-timer is restarted for that interface in each
(S,G) entry whose oif list contains that interface. The
rule applies to (*,G) and (S,G) entries when restarting
Oif-timer on a (*,*,RP) entry
The following table shows its usage when first adding the
to the entry's oiflist, when it should be restarted (unless
is already higher), and when it should be decreased (unless
is already lower).
Set to | When | Applies
included Holdtime | adding oif off Join/Prune | (S,G) (*,G
| | (*,*,RP
Increased (only) to | When | Applies
included Holdtime | received Join/Prune | (S,G) (*,G
| | (*,*,RP
(*,*,RP) oif-timer value | (*,*,RP) oif-timer restarted | (S,G) (*,G
(*,G) oif-timer value | (*,G) oif-timer restarted | (S,G
Estrin, et. al. Experimental [Page 35]
RFC 2362 PIM-SM June 1998
When the timer expires, the oif is removed from the oiflist
there are no directly-connected members. When deleted, the
is also removed in any associated (S,G) or (*,G) entries
* [Entry-Timer (kept per route entry)] A timer for each
entry is used to time out that entry. The following
summarizes its usage when first adding the oif to the entry'
oiflist, and when it should be restarted (unless it is
higher).
Set to | When | Applies
[Data-Timeout] | created off data packet | (S,G
included Holdtime | created off Join/Prune | (S,G) (*,G) (*,*,RP
Increased (only) to | When | Applies
[Data-Timeout] | receiving data packets | (S,G)no RPT-
oif-timer value | any oif-timer restarted | (S,G)RPT-bit (*,G
| | (*,*,RP
[Assert-Timeout] | assert received | (S,G)RPT-bit (*,G
| | w/null
When the timer expires, the route entry is deleted; if
entry is a (*,G) or (*,*,RP) entry, all associated (S,G)RPT
bit entries are also deleted
* [Register-Suppression-Timer (kept per (S,G) route entry)]
An (S,G) route entry's Register-Suppression-Timer is used
suppress registers when the RP is receiving data
natively. When a Register-Stop message for the entry
received from the RP, the timer is set to a random value
the range 0.5 * [Register-Suppression-Timeout] to 1.5 *
[Register-Suppression-Timeout]. While the timer is running
Registers for that entry will be suppressed. If
registers are used, a null register is sent [Probe-Time
seconds before the timer expires
* [Assert-Timer (per (S,G) or (*,G) route entry)]
Assert-Timer for an (S,G) or (*,G) route entry is used
timing out Asserts received. When an Assert is received
the RPF neighbor is changed to the Assert winner, the Assert
Timer is set to [Assert-Timeout], and is restarted to
value every time a subsequent Assert for the entry is
on its incoming interface. When the timer expires, the
resets its RPF neighbor according to its unicast
table
Estrin, et. al. Experimental [Page 36]
RFC 2362 PIM-SM June 1998
* [Random-Delay-Join-Timer (per (S,G) or (*,G) route entry)]
The Random-Delay-Join-Timer for an (S,G) or (*,G) route
is used to prevent synchronization among downstream routers
a LAN when their RPF neighbor changes. When the RPF
changes, this timer is set to a random value between 0
[Random-Delay-Join-Timeout] seconds. When the timer expires,
triggered Join/Prune message is sent for the entry unless
Join/Prune-Suppression-Timer is running
3.8.2 Timers relating to neighbor
* [Hello-Timer] This timer is used to periodically send
messages. To avoid synchronization among routers
simultaneously, it is initially set to a random value
1 and [Hello-Period]. When it expires, the timer
immediately restarted to [Hello-Period]. A Hello message
then sent out each interface. This timer should not
restarted by other events
* [Neighbor-Timer (kept per neighbor)] A Neighbor-Timer
each neighbor is used to time out the neighbor state. When
Hello message is received from a new neighbor, the timer
initially set to the Holdtime included in the Hello
(which is equal to the neighbor's value of [Hello-Holdtime]).
Every time a subsequent Hello is received from that neighbor
the timer is restarted to the Holdtime in the Hello. When
timer expires, the neighbor state is removed
3.8.3 Timers relating to RP
* [C-RP-Adv-Timer (C-RP's only)] Routers configured
candidate RP's use this timer to periodically send C-RP-
messages. To avoid synchronization among routers
simultaneously, the timer is initially set to a random
between 1 and [C-RP-Adv-Period]. When it expires, the timer
immediately restarted to [C-RP-Adv-Period]. A C-RP-Adv
is then sent to the elected BSR. This timer should not
restarted by other events
* [RP-Timer (BSR only, kept per RP in RP-Set)] The BSR uses
timer per RP in the RP-Set to monitor liveness. When a C-RP
added to the RP-Set, its timer is set to the Holdtime
in the C-RP-Adv message from that C-RP (which is equal to
C-RP's value of [RP-Holdtime]). Every time a subsequent C-RP
Adv is received from that RP, its timer is restarted to
Holdtime in the C-RP-Adv. When the timer expires, the RP
removed from the RP-Set included in Bootstrap messages
Estrin, et. al. Experimental [Page 37]
RFC 2362 PIM-SM June 1998
* [Bootstrap-Timer] This timer is used by the BSR
periodically originate Bootstrap messages, and by
routers to time out the BSR (see 3.6.3). This timer
initially set to [Bootstrap-Timeout]. A C-BSR restarts
timer to [Bootstrap-Timeout] upon receiving a
message from a preferred router, and originates a
message and restarts the timer to [Bootstrap-Period] when
expires. Routers not configured as C-BSR's restart this
to [Bootstrap-Timeout] upon receiving a Bootstrap message
the elected or a more preferred BSR, and ignore
messages from non-preferred C-BSRs while it is running
3.8.4 Default timer
Most of the default timeout values for state information are 3.5
times the refresh period. For example, Hellos refresh Neighbor
and the default Hello-timer period is 30 seconds, so a
Neighbor-timer duration of 105 seconds is included in the
field of the Hellos. In order to improve convergence, however,
default timeout value for information related to RP liveness
Bootstrap messages is 2.5 times the refresh period
In this version of the spec, we suggest particular numerical
settings. A future version of the specification will specify
mechanism for timer values to be scaled based upon observed
parameters
* [Join/Prune-Period] This is the interval
sending Join/Prune messages. Default: 60 seconds. This
may be set to take into account such things as the
bandwidth and expected average number of multicast
entries for the attached network or link (e.g., the
would be longer for lower-speed links, or for routers in
center of the network that expect to have a larger number
entries). In addition, a router could modify this value (
corresponding Join/Prune-Holdtime value) if the number
route entries changes significantly (e.g., by an order
magnitude). For example, given a default minimum Join/Prune
Period value, if the number of route entries with a
iif increases from N to N*100, the router could increase
Join/Prune-Period (and Join/Prune-Holdtime), for
interface, by a factor of 10; and if/when the number
entries decreases back to N, the Join/Prune-Period (
Join/Prune-Holdtime) could be decreased to its previous value
If the Join/Prune-Period is modified, these changes should
made relatively infrequently and the router should continue
refresh at its previous Join/Prune-Period for at
Join/Prune-Holdtime, in order to allow the upstream router
Estrin, et. al. Experimental [Page 38]
RFC 2362 PIM-SM June 1998
adapt
* [Join-Prune Holdtime] This is the Holdtime specified
Join/Prune messages, and is used to time out oifs. This
be set to 3.5 * [Join/Prune-Period]. Default: 210 seconds
* [Join/Prune-Suppression-Timeout] This is the
interval between receiving a Join/Prune with a higher
(with ties broken by higher network layer address)
allowing duplicate Join/Prunes to be sent again. This
be set to approximately 1.25 * [Join/Prune-Period]. Default
75 seconds
* [Data-Timeout] This is the time after which (S,G)
for a silent source will be deleted. Default: 210 seconds
* [Register-Suppression-Timeout] This is the
interval between receiving a Register-Stop and
Registers to be sent again. A lower value means more
register bursts at RP, while a higher value means longer
latency for new receivers. Default: 60 seconds. (Note
if null Registers are sent [Probe-Time] seconds before
timeout, register bursts are prevents, and [Register
Suppression-Timeout] may be lowered to decrease join latency.)
* [Probe-Time] When null Registers are used, this is
time between sending a null Register and the Register
Suppression-Timer expiring unless it is restarted by
a Register-Stop. Thus, a null Register would be sent when
Register-Suppression-Timer reaches this value. Default: 5
seconds
* [Assert-Timeout] This is the interval between the
time an Assert is received, and the time at which the
is timed out. Default: 180 seconds
* [Random-Delay-Join-Timeout] This is the
interval between the time when the RPF neighbor changes,
the time at which a triggered Join/Prune message is sent
Default: 4.5 seconds
* [Hello-Period] This is the interval between
Hello messages. Default: 30 seconds
* [Hello-Holdtime] This is the Holdtime specified
Hello messages, after which neighbors will time out
neighbor entries for the router. This should be set to 3.5 *
[Hello-Period]. Default: 105 seconds
Estrin, et. al. Experimental [Page 39]
RFC 2362 PIM-SM June 1998
* [C-RP-Adv-Period] For C-RPs, this is the
between sending C-RP-Adv messages. Default: 60 seconds
* [RP-Holdtime] For C-RPs, this is the Holdtime
in C-RP-Adv messages, and is used by the BSR to time out RPs
This should be set to 2.5 * [C-RP-Adv-Period]. Default: 150
seconds
* [Bootstrap-Period] At the elected BSR, this is
interval between originating Bootstrap messages, and should
equal to 60 seconds
* [Bootstrap-Timeout] This is the time after which
elected BSR will be assumed unreachable when
messages are not received from it. This should be set to `2 *
[Bootstrap-Period] + 10'. Default: 130 seconds
3.9 Summary of flags
Following is a summary of all the flags used in our scheme
Bit | Used in |
Border | Register | Register for external sources is
from PIM multicast border
Null | Register | Register sent as Probe of RP,
encapsulated IP data packet should
be
RPT | Route entry | Entry represents state on the RP-
RPT | Join/Prune | Join is associated with the shared tree
therefore the Join/Prune message
propagated along the RP-tree (
encoded is an RP address
RPT | Assert | The data packet was routed down the
tree; thus, the path indicated
to the RP
SPT | (S,G) entry | Packets have arrived on the iif
S, and the iif is different from
(*,G)
WC |Join | The receiver expects to receive
from all sources via this (shared tree
path. Thus, the Join/Prune applies to
(*,G)
WC | Route entry | Wildcard entry; if there is no
specific match for a particular source
packets will be forwarded according
this
Estrin, et. al. Experimental [Page 40]
RFC 2362 PIM-SM June 1998
3.10
All PIM control messages may use IPsec [6] to address
concerns
4 Packet
This section describes the details of the packet formats for
control messages
All PIM control messages have protocol number 103.
Basically, PIM messages are either unicast (e.g. Registers
Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS'
`224.0.0.13' (e.g. Join/Prune, Asserts, etc.).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM
PIM Version number is 2.
Type Types for specific PIM messages. PIM Types are
0 =
1 =
2 = Register-
3 = Join/
4 =
5 =
6 = Graft (used in PIM-DM only
7 = Graft-Ack (used in PIM-DM only
8 = Candidate-RP-
set to zero. Ignored upon receipt
The checksum is the 16-bit one's complement of the one'
complement sum of the entire PIM message, (excluding
data portion in the Register message). For computing
checksum, the checksum field is zeroed
Estrin, et. al. Experimental [Page 41]
RFC 2362 PIM-SM June 1998
4.1 Encoded Source and Group Address
1 Encoded-Unicast-address: Takes the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++
Addr
The address family of the `Unicast Address' field
this address
Here is the address family numbers assigned by IANA
Number
-------- ---------------------------------------------------------
0
1 IP (IP version 4)
2 IP6 (IP version 6)
3
4 HDLC (8-bit multidrop
5 BBN 1822
6 802 (includes all 802 media plus Ethernet "canonical format")
7 E.163
8 E.164 (SMDS, Frame Relay, ATM
9 F.69 (Telex
10 X.121 (X.25, Frame Relay
11
12
13 Decnet
14 Banyan
15 E.164 with NSAP format
Encoding
The type of encoding used within a specific
Family. The value `0' is reserved for this field
and represents the native encoding of the
Family
Unicast
The unicast address as represented by the
Address Family and Encoding Type
Estrin, et. al. Experimental [Page 42]
RFC 2362 PIM-SM June 1998
2 Encoded-Group-Address: Takes the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Reserved | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addr
described above
Encoding
described above
Transmitted as zero. Ignored upon receipt
Mask
The Mask length is 8 bits. The value is the number
contiguous bits left justified used as a mask
describes the address. It is less than or equal to
address length in bits for the given Address
and Encoding Type. If the message is sent for a
group then the Mask length must equal the
length in bits for the given Address Family
Encoding Type. (e.g. 32 for IPv4 native encoding
128 for IPv6 native encoding).
Group multicast
contains the group address
3 Encoded-Source-Address: Takes the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addr
described above
Encoding
described above
Estrin, et. al. Experimental [Page 43]
RFC 2362 PIM-SM June 1998
Transmitted as zero, ignored on receipt
S,W,R See Section 4.5 for details
Mask
Mask length is 8 bits. The value is the number
contiguous bits left justified used as a mask
describes the address. The mask length must be
than or equal to the address length in bits for
given Address Family and Encoding Type. If the
is sent for a single group then the Mask length
equal the address length in bits for the given
Family and Encoding Type. In version 2 of PIM, it
strongly recommended that this field be set to 32
IPv4 native encoding
Source
The source address
4.2 Hello
It is sent periodically by routers on all interfaces
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
PIM Version, Type, Reserved,
Described above
Estrin, et. al. Experimental [Page 44]
RFC 2362 PIM-SM June 1998
The type of the option given in the following
field
The length of the OptionValue field in bytes
A variable length field, carrying the value of the option
The Option fields may contain the following values
* OptionType = 1; OptionLength = 2; OptionValue = Holdtime
where Holdtime is the amount of time a receiver must keep
neighbor reachable, in seconds. If the Holdtime is set
`0xffff', the receiver of this message never times out
neighbor. This may be used with ISDN lines, to avoid
the link up with periodic Hello messages. Furthermore, if
Holdtime is set to `0', the information is timed
immediately
* OptionType 2 to 16:
* The rest of the OptionTypes are defined in
document
In general, options may be ignored; but a router must not ignore
4.3 Register
A Register message is sent by the DR or a PMBR to the RP when
multicast packet needs to be transmitted on the RP-tree.
address is set to the address of the DR, destination address is
the RP's address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|N| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Multicast data
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estrin, et. al. Experimental [Page 45]
RFC 2362 PIM-SM June 1998
PIM Version, Type, Reserved,
Described above. Note that the checksum for
is done only on the PIM header, excluding the data
portion
B The Border bit. If the router is a DR for a source that
is directly connected to, it sets the B bit to 0. If
router is a PMBR for a source in a directly
cloud, it sets the B bit to 1.
N The Null-Register bit. Set to 1 by a DR that is
the RP before expiring its local Register-
timer. Set to 0 otherwise
Multicast data
The original packet sent by the source
For (S,G) null Registers, the Multicast data packet
contains only a dummy header with S as the source address, G
the destination address, and a data length of zero
4.4 Register-Stop
A Register-Stop is unicast from the RP to the sender of the
message. Source address is the address to which the register
addressed. Destination address is the source address of the
message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved,
Described above
Encoded-Group
Format described above. Note that for Register-Stops
Mask Len field contains full address length * 8 (e.g. 32
for IPv4 native encoding), if the message is sent for
single group
Estrin, et. al. Experimental [Page 46]
RFC 2362 PIM-SM June 1998
Encoded-Unicast-Source
host address of source from multicast data packet
register. The format for this address is given in
Encoded-Unicast-Address in 4.1. A special wild card
(0's), can be used to indicate any source
4.5 Join/Prune
A Join/Prune message is sent by routers towards upstream sources
RPs. Joins are sent to build shared trees (RP trees) or source
(SPT). Prunes are sent to prune source trees when members
groups as well as sources that do not use the shared tree
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-Upstream Neighbor Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Multicast Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Multicast Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estrin, et. al. Experimental [Page 47]
RFC 2362 PIM-SM June 1998
| Encoded-Joined Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved,
Described above
Encoded-Unicast Upstream Neighbor
The address of the RPF or upstream neighbor. The
for this address is given in the Encoded-Unicast-Address
4.1. .IP "Reserved
Transmitted as zero, ignored on receipt
The amount of time a receiver must keep the Join/
state alive, in seconds. If the Holdtime is set
`0xffff', the receiver of this message never times out
oif. This may be used with ISDN lines, to avoid keeping
link up with periodical Join/Prune messages. Furthermore
if the Holdtime is set to `0', the information is timed
immediately
Number of
The number of multicast group sets contained in
message
Encoded-Multicast group
For format description see
4.1. A wild card group in the (*,*,RP) join is
by a 224.0.0.0 in the group address field and `4' in
mask length field. A (*,*,RP) join also has the WC-bit
the RPT-bit set
Number of Joined
Number of join source addresses listed for a given group
Estrin, et. al. Experimental [Page 48]
RFC 2362 PIM-SM June 1998
Join Source Address-1 ..
This list contains the sources that the sending
will forward multicast datagrams for if received on
interface this message is sent on
See format section 4.1. The fields explanation for
Encoded-Source-Address format follows
Described above
S The Sparse bit is a 1 bit value, set to 1 for PIM-SM
It is used for PIM v.1 compatibility
W The WC bit is a 1 bit value. If 1, the join or
applies to the (*,G) or (*,*,RP) entry. If 0, the
or prune applies to the (S,G) entry where S is
Address. Joins and prunes sent towards the RP
have this bit set
R The RPT-bit is a 1 bit value. If 1, the
about (S,G) is sent towards the RP. If 0,
information must be sent toward S, where S is
Source Address
Mask Length, Source
Described above
Represented in the form
< WC-bit >< RPT-bit >< Source address>:
A source address could be a host IPv4 native
address :
< 0 >< 0 >< 32 >< 192.1.1.17 >
A source address could be the RP's IP address :
< 1 >< 1 >< 32 >< 131.108.13.111 >
A source address could be a subnet address to prune
the RP-tree :
< 0 >< 1 >< 28 >< 192.1.1.16 >
A source address could be a general aggregate :
< 0 >< 0 >< 16 >< 192.1.0.0 >
Estrin, et. al. Experimental [Page 49]
RFC 2362 PIM-SM June 1998
Number of Pruned
Number of prune source addresses listed for a group
Prune Source Address-1 ..
This list contains the sources that the sending
does not want to forward multicast datagrams for
received on the interface this message is sent on. If
Join/Prune message boundary exceeds the maximum
size, then the join and prune lists for the same group
be included in the same packet
4.6 Bootstrap
The Bootstrap messages are multicast to `ALL-PIM-ROUTERS' group,
all interfaces having PIM neighbors (excluding the one over which
message was received). Bootstrap messages are sent with TTL value
1. Bootstrap messages originate at the BSR, and are forwarded
intermediate routers
Bootstrap message is divided up into `semantic fragments', if
original message exceeds the maximum packet size boundaries
The semantics of a single `fragment' is given below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask len | BSR-priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-BSR-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP-Count-1 | Frag RP-Cnt-1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1-Holdtime | RP1-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2-Holdtime | RP2-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estrin, et. al. Experimental [Page 50]
RFC 2362 PIM-SM June 1998
| Encoded-Unicast-RP-Address-m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm-Holdtime | RPm-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP-Count-n | Frag RP-Cnt-n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1-Holdtime | RP1-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2-Holdtime | RP2-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm-Holdtime | RPm-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved,
Described above
Fragment
A randomly generated number, acts to distinguish
fragments belonging to different Bootstrap messages
fragments belonging to same Bootstrap message carry
same `Fragment Tag'.
Hash Mask
The length (in bits) of the mask to use in the
function. For IPv4 we recommend a value of 30. For IPv6
recommend a value of 126.
BSR-
Contains the BSR priority value of the included BSR.
field is considered as a high order byte when comparing
addresses
Estrin, et. al. Experimental [Page 51]
RFC 2362 PIM-SM June 1998
Encoded-Unicast-BSR-
The address of the bootstrap router for the domain.
format for this address is given in the Encoded-Unicast
Address in 4.1. .IP "Encoded-Group Address-1..n
The group prefix (address and mask) with which
Candidate RPs are associated. Format previously described
RP-Count-1..
The number of Candidate RP addresses included in the
Bootstrap message for the corresponding group prefix.
router does not replace its old RP-Set for a given
prefix until/unless it receives `RP-Count' addresses
that prefix; the addresses could be carried over
fragments. If only part of the RP-Set for a given
prefix was received, the router discards it,
updating that specific group prefix's RP-Set
Frag RP-Cnt-1..
The number of Candidate RP addresses included in
fragment of the Bootstrap message, for the
group prefix. The `Frag RP-Cnt' field facilitates
of the RP-Set for a given group prefix, when carried
more than one fragment
Encoded-Unicast-RP-address-1..
The address of the Candidate RPs, for the
group prefix. The format for this address is given in
Encoded-Unicast-Address in 4.1. .IP "RP1..m-Holdtime
The Holdtime for the corresponding RP. This field
copied from the `Holdtime' field of the associated
stored at the BSR
RP1..m-
The `Priority' of the corresponding RP and Encoded-
Address. This field is copied from the `Priority'
stored at the BSR when receiving a Candidate-RP
Advertisement. The highest priority is `0' (i.e. the
the value of the `Priority' field, the higher). Note
the priority is per RP per Encoded-Group Address
4.7 Assert
The Assert message is sent when a multicast data packet is
on an outgoing interface corresponding to the (S,G) or (*,G
associated with the source
Estrin, et. al. Experimental [Page 52]
RFC 2362 PIM-SM June 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved,
Described above
Encoded-Group
The group address to which the data packet was addressed
and which triggered the Assert. Format
described
Encoded-Unicast-Source
Source address from multicast datagram that triggered
Assert packet to be sent. The format for this address
given in the Encoded-Unicast-Address in 4.1. .IP "R
RPT-bit is a 1 bit value. If the multicast datagram
triggered the Assert packet is routed down the RP tree
then the RPT-bit is 1; if the multicast datagram is
down the SPT, it is 0.
Metric
Preference value assigned to the unicast routing
that provided the route to Host address
Metric The unicast routing table metric. The metric is in
applicable to the unicast routing protocol used
4.8 Graft
Used in dense-mode. Refer to PIM dense mode specification
4.9 Graft-Ack
Used in dense-mode. Refer to PIM dense mode specification
Estrin, et. al. Experimental [Page 53]
RFC 2362 PIM-SM June 1998
4.10 Candidate-RP-
Candidate-RP-Advertisements are periodically unicast from the C-
to the BSR
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Cnt | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved,
Described above
Prefix-
The number of encoded group addresses included in
message; indicating the group prefixes for which the C-
is advertising. A Prefix-Cnt of `0' implies a prefix
224.0.0.0 with mask length of 4; i.e. all multicast groups
If the C-RP is not configured with Group-
information, the C-RP puts a default value of `0' in
field
The `Priority' of the included RP, for the
Encoded-Group Address (if any). highest priority is `0'
(i.e. the lower the value of the `Priority' field,
higher the priority). This field is stored at the BSR
receipt along with the RP address and
Encoded-Group Address
The amount of time the advertisement is valid. This
allows advertisements to be aged out
Estrin, et. al. Experimental [Page 54]
RFC 2362 PIM-SM June 1998
Encoded-Unicast-RP-
The address of the interface to advertise as a
RP. The format for this address is given in the Encoded
Unicast-Address in 4.1. .IP "Encoded-Group Address-1..n
The group prefixes for which the C-RP is advertising
Format previously described
5
Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul Francis
Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski,
Zhang and Girish Chandranmenon provided detailed comments on
drafts. The authors of CBT [8] and membership of the IDMR WG
many of the motivating ideas for this work and useful feedback
design details
This work was supported by the National Science Foundation, ARPA
cisco Systems and Sun Microsystems
Estrin, et. al. Experimental [Page 55]
RFC 2362 PIM-SM June 1998
6
6.1 Appendix I: Major Changes and Updates to the
This appendix populates the major changes in the
document as compared to `draft-ietf-idmr-pim-spec-01.ps,txt'.
bsubsection*Major
List of changes since March '96 IETF
1. (*,*,RP) Joins state and data forwarding check; replaces (*,G
Prefix) Joins state for interoperability. (*,G) negative
introduced for the (*,*,RP) state supporting mechanisms
2. Semantic fragmentation for the Bootstrap message
3. Refinement of Assert details
4. Addition and refinement of Join/Prune suppression and
suppression (introduction of null Registers).
5. Editorial changes and clarifications to the timers section
6. Addition of Appendix II (BSR Election and RP-Set Distribution),
and Appendix III (Glossary of Terms).
7. Addition of table of contents
List of changes incurred since version 1 of the spec.:
1. Proposal and refinement of bootstrap router (BSR)
2. Introduction of hash functions for Group to RP
3. New RP-liveness indication mechanisms based upon the
Bootstrap Router (BSR) and the Bootstrap messages
4. Removal of reachability messages, RP reports and multiple
per group
*Packet Format
Packet Format incurred updates to accommodate different
lengths, and address aggregation
Estrin, et. al. Experimental [Page 56]
RFC 2362 PIM-SM June 1998
1 The `Addr Family' and `Encoding Type' fields were added to
packet formats
2 The Encoded source and group address formats were introduced
with the use of a `Mask length' field to allow aggregation,
4.1.
3 Packet formats are no longer IGMP messages; rather PIM messages
PIM message types and formats were also modified
[Note: most changes were made to the May 95 version,
otherwise specified].
1 Obsolete messages
Register-Ack [Feb. 96]
Poll and Poll Response [Feb. 96]
RP-Reachability [Feb. 96]
RPlist-Mapping [Feb. 96]
2 New messages
Candidate-RP-Advertisement [change made in October 95]
RP-Set [Feb. 96]
3 Modified messages
Join/Prune [Feb. 96]
Register [Feb. 96]
Register-Stop [Feb. 96]
Hello (addition of OptionTypes) [Aug 96]
4 Renamed messages
Query messages are renamed as Hello messages [Aug. 96]
RP-Set messages are renamed as Bootstrap messages [Aug. 96]
Estrin, et. al. Experimental [Page 57]
RFC 2362 PIM-SM June 1998
6.2 Appendix II: BSR Election and RP-Set
For simplicity, the bootstrap message is used in both the
election and the RP-Set distribution mechanisms. These
are described by the following state machine, illustrated in
4. The protocol transitions for a Candidate-BSR are given in
diagram (a). For routers not configured as Candidate-BSRs,
protocol transitions are given in state diagram (b).
[Figures are present only in the postscript version] Fig. 4
Diagram for the BSR election and RP-Set
Each PIM router keeps a bootstrap-timer, initialized to [Bootstrap
Timeout], in addition to a local BSR field `LclBSR' (initialized to
local address if Candidate-BSR, or to 0 otherwise), and a local RP
Set `LclRP-Set' (initially empty). The main stimuli to the
machine are timer events and arrival of bootstrap messages
bsubsection*Initial States and Timer
1
2 If the router is a Candidate-BSR
1
2 The router operates initially in the `CandBSR' state
where it does not originate any bootstrap messages
3 If the bootstrap-timer expires, and the current
is `CandBSR', the router originates a
message carrying the local RP-Set and its own
priority and address, restarts the bootstrap-timer
[Bootstrap-Period] seconds, and transits into
`ElectedBSR' state. Note that the actual sending
the bootstrap message may be delayed by a random
to reduce transient control overhead. To obtain
results, the random value is set such that
preferred BSR is the first to originate a
message. We propose the following as an
implementation of the random value delay (in seconds):
Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) +
where myPriority is the Candidate-BSR'
configured priority, and bestPriority equals
bestPriority = Max(storedPriority, myPriority) ]
Estrin, et. al. Experimental [Page 58]
RFC 2362 PIM-SM June 1998
and AddrDelay is given by the following
1 if ( bestPriority equals myPriority)
[AddrDelay = log_2(bestAddr - myAddr) / 16, ]
2 else [AddrDelay = 2 - (myAddr / 2^31) ]
where myAddr is the Candidate-BSR's address,
bestAddr is the stored BSR's address
4 If the bootstrap-timer expires, and the current
is `ElectedBSR', the router originates a
message, and restarts the RP-Set timer at [Bootstrap
Period]. No state transition is incurred
This way, the elected BSR originates
bootstrap messages every [Bootstrap-Period].
3 If a router is not a Candidate-BSR
1
2 The router operates initially in the `AxptAny' state
In such state, a router accepts the first
message from the The Reverse Path Forwarding (RPF
neighbor toward the included BSR. The RPF neighbor
this case is the next hop router en route to
included BSR
3 If the bootstrap-timer expires, and the current
is `AxptPref'-- where the router accepts
preferred bootstrap messages (those that carry BSR
priority and address higher than, or equal to
`LclBSR') from the RPF neighbor toward the
BSR-- the router transits into the `AxptAny' state
In this case, if an elected BSR becomes unreachable
the routers start accepting bootstrap messages
another Candidate-BSR after the bootstrap-
expires. All PIM routers within a domain converge
the preferred reachable Candidate-BSR
Estrin, et. al. Experimental [Page 59]
RFC 2362 PIM-SM June 1998
Receiving Bootstrap Message
To avoid loops, an RPF check is performed on the included
address. Upon receiving a bootstrap message from the
neighbor toward the included BSR, the following actions
taken
1 If the router is not a Candidate-BSR
1 If the current state is `AxptAny', the router
the bootstrap message, and transits into
`AxptPref' state
2 If the current state is `AxptPref', and the
message is preferred, the message is accepted.
state transition is incurred
2 If the router is a Candidate-BSR, and the bootstrap
is preferred, the message is accepted. Further, if
happens when the current state is `Elected BSR', the
transits into the `CandBSR' state
When a bootstrap message is accepted, the router restarts
bootstrap-timer at [Bootstrap-Timeout], stores the received
priority and address in `LclBSR', and the received RP-Set
`LclRP-Set', and forwards the bootstrap message out
interfaces except the receiving interface
If a bootstrap message is rejected, no state transitions
triggered
Estrin, et. al. Experimental [Page 60]
RFC 2362 PIM-SM June 1998
6.3 Appendix III: Glossary of
Following is an alphabetized list of terms and definitions
throughout this specification
* { Bootstrap router (BSR)}. A BSR is a dynamically
router within a PIM domain. It is responsible for
the RP-Set and originating Bootstrap messages
* { Candidate-BSR (C-BSR)}. A C-BSR is a router configured
participate in the BSR election and act as BSRs if elected
* { Candidate RP (C-RP)}. A C-RP is a router configured
send periodic Candidate-RP-Advertisement messages to the BSR
and act as an RP when it receives Join/Prune or
messages for the advertised group prefix
* { Designated Router (DR)}. The DR sets up multicast
entries and sends corresponding Join/Prune and
messages on behalf of directly-connected receivers
sources, respectively. The DR may or may not be the
router as the IGMP Querier. The DR may or may not be
long-term, last-hop router for the group; a router on the
that has a lower metric route to the data source, or to
group's RP, may take over the role of sending Join/
messages
* { Incoming interface (iif)}. The iif of a multicast
entry indicates the interface from which multicast
packets are accepted for forwarding. The iif is
when the entry is created
* Join list. The Join list is one of two lists of
that is included in a Join/Prune message; each address
to a source or RP. It indicates those sources or RPs to
downstream receiver(s) wish to join
* { Last-hop router}. The last-hop router is the last
to receive multicast data packets before they are delivered
directly-connected member hosts. In general the last-
router is the DR for the LAN. However, under
conditions described in this document a parallel
connected to the same LAN may take over as the last-hop
in place of the DR
* { Outgoing interface (oif) list}. Each multicast
entry has an oif list containing the outgoing interfaces
which multicast packets should be forwarded
Estrin, et. al. Experimental [Page 61]
RFC 2362 PIM-SM June 1998
* Prune List. The Prune list is the second list of
that is included in a Join/Prune message. It indicates
sources or RPs from which downstream receiver(s) wish
prune
* { PIM Multicast Border Router (PMBR)}. A PMBR connects
PIM domain to other multicast routing domain(s).
* { Rendezvous Point (RP)}. Each multicast group has
shared-tree via which receivers hear of new sources and
receivers hear of all sources. The RP is the root of
per-group shared tree, called the RP-Tree
* { RP-Set}. The RP-Set is a set of RP addresses
by the BSR based on Candidate-RP advertisements received.
RP-Set information is distributed to all PIM routers in
BSR's PIM domain
* { Reverse Path Forwarding (RPF)}. RPF is used to select
appropriate incoming interface for a multicast route entry .
The RPF neighbor for an address X is the the next-hop
used to forward packets toward X. The RPF interface is
interface to that RPF neighbor. In the common case this is
next hop used by the unicast routing protocol for
unicast packets toward X. For example, in cases where
and multicast routes are not congruent, it can be different
* { Route entry.} A multicast route entry is state
in a router along the distribution tree and is created,
updated based on incoming control messages. The route
may be different from the forwarding entry; the latter is
to forward data packets in real time. Typically a
entry is not created until data packets arrive, the
entry's iif and oif list are copied from the route entry,
the forwarding entry may be flushed and recreated at will
* { Shortest path tree (SPT)}. The SPT is the
distribution tree created by the merger of all of the
paths that connect receivers to the source (as determined
unicast routing).
* { Sparse Mode (SM)}. SM is one mode of operation of
multicast protocol. PIM SM uses explicit Join/Prune
and Rendezvous points in place of Dense Mode PIM's and DVMRP'
broadcast and prune mechanism
Estrin, et. al. Experimental [Page 62]
RFC 2362 PIM-SM June 1998
* { Wildcard (WC) multicast route entry}. Wildcard
route entries are those entries that may be used to
packets for any source sending to the specified group
Wildcard bots in the join list of a Join/Prune
represent either a (*,G) or (*,*,RP) join; in the prune
they represent a (*,G) prune
* { (S,G) route entry}. (S,G) is a source-specific
entry. It may be created in response to data packets
Join/Prune messages, or Asserts. The (S,G) state in
creates a source-rooted, shortest path (or reverse
path) distribution tree. (S,G)RPT bit entries are source
specific entries on the shared RP-Tree; these entries are
to prune particular sources off of the shared tree
* { (*,G) route entry}. Group members join the shared RP-
for a particular group. This tree is represented by (*,G
multicast route entries along the shortest path
between the RP and the group members
* { (*,*,RP) route entry}. (*,*,RP) refers to any source
any multicast group that maps to the RP included in the entry
The routers along the shortest path branches between
domain's RP(s) and its PMBRs keep (*,*,RP) state and use it
determine how to deliver packets toward the PMBRs if
packets arrive for which there is not a longer match.
wildcard group in the (*,*,RP) route entry is represented by
group address of 224.0.0.0 and a mask length of 4 bits
1. Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C.,
Wei, L., Sharma, P., and A. Helmy, "Protocol Independent
(pim): Motivation and Architecture", Work in Progress
2. S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L
Wei. The pim architecture for wide-area multicast routing.
Transactions on Networks, April 1996.
3. Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma
P., and A. Helmy, "Protocol Independent Multicast-dense Mode (pim
dm): Protocol Specification", Work in Progress
4. Deering, S., "Host Extensions for IP Multicasting", STD 5,
1112, August 1989.
5. Fenner, W., "Internet Group Management Protocol, Version 2",
2236, November 1997.
Estrin, et. al. Experimental [Page 63]
RFC 2362 PIM-SM June 1998
6. Atkinson, R., "Security Architecture for the Internet Protocol",
RFC 1825, August 1995.
7. Mark R. Nelson. File verification using CRC. Dr. Dobb'
Journal, May 1992.
8. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees
In Proceedings of the ACM SIGCOMM, San Francisco, 1993.
Authors'
NOTE: The author list has been reordered to reflect the
in 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
Deborah
Computer Science Dept/
University of Southern Calif
Los Angeles, CA 90089
EMail: estrin@usc.
Dino
Cisco Systems Inc
170 West Tasman Drive
San Jose, CA 95134
EMail: dino@cisco.
Ahmed
Computer Science Dept
University of Southern Calif
Los Angeles, CA 90089
EMail: ahelmy@catarina.usc.
David
EECS
University of
Ann Arbor, MI 48109
EMail: thalerd@eecs.umich.
Estrin, et. al. Experimental [Page 64]
RFC 2362 PIM-SM June 1998
Stephen
Xerox
3333 Coyote Hill
Palo Alto, CA 94304
EMail: deering@parc.xerox.
Mark
Department of Computer
University College
Gower
London, WC1E 6
EMail: m.handley@cs.ucl.ac.
Van
Lawrence Berkeley
1 Cyclotron
Berkeley, CA 94720
EMail: van@ee.lbl.
Ching-gung
Computer Science Dept
University of Southern Calif
Los Angeles, CA 90089
EMail: charley@catarina.usc.
Puneet
Computer Science Dept
University of Southern Calif
Los Angeles, CA 90089
EMail: puneet@catarina.usc.
Liming
Cisco Systems Inc
170 West Tasman Drive
San Jose, CA 95134
EMail: lwei@cisco.
Estrin, et. al. Experimental [Page 65]
RFC 2362 PIM-SM June 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Estrin, et. al. Experimental [Page 66]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
