draft-ietf-pim-sm-v2-new-11.txt   draft-ietf-pim-sm-v2-new-12.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Bill Fenner/AT&T INTERNET-DRAFT Bill Fenner/AT&T
draft-ietf-pim-sm-v2-new-11.txt Mark Handley/UCL draft-ietf-pim-sm-v2-new-12.txt Mark Handley/UCL
Hugh Holbrook/Cisco Hugh Holbrook/Arastra
Isidor Kouvelas/Cisco Obsoletes (if approved): RFC2362 Isidor Kouvelas/Cisco
25 October 2004 20 March 2006
Expires: April 2005 Expires: September 2006
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised) Protocol Specification (Revised)
Status of this Document Status of this Document
By submitting this Internet-Draft, I certify that any applicable patent By submitting this Internet-Draft, each author represents that any
or other IPR claims of which I am aware have been disclosed, or will be applicable patent or other IPR claims of which he or she is aware have
disclosed, and any of which I become aware will be disclosed, in been or will be disclosed, and any of which he or she becomes aware will
accordance with RFC 3668. be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
skipping to change at page 3, line 5 skipping to change at page 2, line 15
Abstract Abstract
This document specifies Protocol Independent Multicast - This document specifies Protocol Independent Multicast -
Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol
that can use the underlying unicast routing information base that can use the underlying unicast routing information base
or a separate multicast-capable routing information base. It or a separate multicast-capable routing information base. It
builds unidirectional shared trees rooted at a Rendezvous builds unidirectional shared trees rooted at a Rendezvous
Point (RP) per group, and optionally creates shortest-path Point (RP) per group, and optionally creates shortest-path
trees per source. trees per source.
This document obsoletes RFC 2362, an Experimental version of
PIM-SM.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . 6 2.1. Definitions. . . . . . . . . . . . . . . . . . . . . 6
2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . 7 2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . 7
3. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . 8 3. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . 8
4. Protocol Specification. . . . . . . . . . . . . . . . . 13 4. Protocol Specification. . . . . . . . . . . . . . . . . 13
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . 13 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . 14
4.1.1. General Purpose State . . . . . . . . . . . . . . 14 4.1.1. General Purpose State . . . . . . . . . . . . . . 15
4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . 15 4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . 15
4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . 16 4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . 16
4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . 18 4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . 18
4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . 20 4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . 20
4.1.6. State Summarization Macros. . . . . . . . . . . . 21 4.1.6. State Summarization Macros. . . . . . . . . . . . 21
4.2. Data Packet Forwarding Rules . . . . . . . . . . . . 26 4.2. Data Packet Forwarding Rules . . . . . . . . . . . . 26
4.2.1. Last-hop Switchover to the SPT. . . . . . . . . . 28 4.2.1. Last-hop Switchover to the SPT. . . . . . . . . . 28
4.2.2. Setting and Clearing the (S,G) SPTbit . . . . . . 29 4.2.2. Setting and Clearing the (S,G) SPTbit . . . . . . 29
4.3. Designated Routers (DR) and Hello Messages . . . . . 30 4.3. Designated Routers (DR) and Hello Messages . . . . . 30
4.3.1. Sending Hello Messages. . . . . . . . . . . . . . 30 4.3.1. Sending Hello Messages. . . . . . . . . . . . . . 30
skipping to change at page 6, line 15 skipping to change at page 6, line 15
1. Introduction 1. Introduction
This document specifies a protocol for efficiently routing multicast This document specifies a protocol for efficiently routing multicast
groups that may span wide-area (and inter-domain) internets. This groups that may span wide-area (and inter-domain) internets. This
protocol is called Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol is called Protocol Independent Multicast - Sparse Mode (PIM-SM)
because, although it may use the underlying unicast routing to provide because, although it may use the underlying unicast routing to provide
reverse-path information for multicast tree building, it is not reverse-path information for multicast tree building, it is not
dependent on any particular unicast routing protocol. dependent on any particular unicast routing protocol.
PIM-SM version 2 was originally specified in RFC 2117, and revised in PIM-SM version 2 was originally specified in RFC 2117, and revised in
RFC 2362. This document is intended to obsolete RFC 2362, and to RFC 2362, both Experimental RFCs. This document is intended to obsolete
correct a number of deficiencies that have been identified with the way RFC 2362, to correct a number of deficiencies that have been identified
PIM-SM was previously specified. As far as possible, this document with the way PIM-SM was previously specified, and to bring PIM-SM onto
specifies the same protocol as RFC 2362, and only diverges from the the IETF Standards Track. As far as possible, this document specifies
behavior intended by RFC 2362 when the previously specified behavior was the same protocol as RFC 2362, and only diverges from the behavior
clearly incorrect. Routers implemented according to the specification intended by RFC 2362 when the previously specified behavior was clearly
in this document will be able to successfully interoperate with routers incorrect. Routers implemented according to the specification in this
document will be able to successfully interoperate with routers
implemented according to RFC 2362. implemented according to RFC 2362.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in RFC 2119 and indicate "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
requirement levels for compliant PIM-SM implementations. indicate requirement levels for compliant PIM-SM implementations.
2.1. Definitions 2.1. Definitions
This specification uses a number of terms to refer to the roles of The following terms have special significance for PIM-SM:
routers participating in PIM-SM. The following terms have special
significance for PIM-SM:
Rendezvous Point (RP): Rendezvous Point (RP):
An RP is a router that has been configured to be used as the root An RP is a router that has been configured to be used as the root
of the non-source-specific distribution tree for a multicast of the non-source-specific distribution tree for a multicast
group. Join messages from receivers for a group are sent towards group. Join messages from receivers for a group are sent towards
the RP, and data from senders is sent to the RP so that receivers the RP, and data from senders is sent to the RP so that receivers
can discover who the senders are, and start to receive traffic can discover who the senders are, and start to receive traffic
destined for the group. destined for the group.
Designated Router (DR): Designated Router (DR):
skipping to change at page 7, line 11 skipping to change at page 7, line 8
on behalf of directly connected hosts with respect to the PIM-SM on behalf of directly connected hosts with respect to the PIM-SM
protocol. A single DR is elected per interface (LAN or otherwise) protocol. A single DR is elected per interface (LAN or otherwise)
using a simple election process. using a simple election process.
MRIB Multicast Routing Information Base. This is the multicast MRIB Multicast Routing Information Base. This is the multicast
topology table, which is typically derived from the unicast topology table, which is typically derived from the unicast
routing table, or routing protocols such as MBGP that carry routing table, or routing protocols such as MBGP that carry
multicast-specific topology information. In PIM-SM, the MRIB is multicast-specific topology information. In PIM-SM, the MRIB is
used to decide where to send Join/Prune messages. A secondary used to decide where to send Join/Prune messages. A secondary
function of the MRIB is to provide routing metrics for destination function of the MRIB is to provide routing metrics for destination
addresses, these metrics are used when sending and processing addresses; these metrics are used when sending and processing
Assert messages. Assert messages.
RPF Neighbor RPF Neighbor
RPF stands for "Reverse Path Forwarding". The RPF Neighbor of a RPF stands for "Reverse Path Forwarding". The RPF Neighbor of a
router with respect to an address is the neighbor that the MRIB router with respect to an address is the neighbor that the MRIB
indicates should be used to forward packets to that address. In indicates should be used to forward packets to that address. In
the case of a PIM-SM multicast group, the RPF neighbor is the the case of a PIM-SM multicast group, the RPF neighbor is the
router that a Join message for that group would be directed to, in router that a Join message for that group would be directed to, in
the absence of modifying Assert state. the absence of modifying Assert state.
skipping to change at page 7, line 44 skipping to change at page 7, line 41
How this is done is implementation-specific, and is not discussed How this is done is implementation-specific, and is not discussed
in this document. in this document.
Upstream Upstream
Towards the root of the tree. The root of tree may either be the Towards the root of the tree. The root of tree may either be the
source or the RP depending on the context. source or the RP depending on the context.
Downstream Downstream
Away from the root of the tree. Away from the root of the tree.
GenID Generation Identifier, used to detect reboots.
PMBR PIM Multicast Border Router, joining a PIM domain with another
multicast domain.
2.2. Pseudocode Notation 2.2. Pseudocode Notation
We use set notation in several places in this specification. We use set notation in several places in this specification.
A (+) B A (+) B
is the union of two sets A and B. is the union of two sets A and B.
A (-) B A (-) B
is the elements of set A that are not in set B. is the elements of set A that are not in set B.
skipping to change at page 8, line 28 skipping to change at page 8, line 31
3. PIM-SM Protocol Overview 3. PIM-SM Protocol Overview
This section provides an overview of PIM-SM behavior. It is intended as This section provides an overview of PIM-SM behavior. It is intended as
an introduction to how PIM-SM works, and is NOT definitive. For the an introduction to how PIM-SM works, and is NOT definitive. For the
definitive specification, see Section 4. definitive specification, see Section 4.
PIM relies on an underlying topology-gathering protocol to populate a PIM relies on an underlying topology-gathering protocol to populate a
routing table with routes. This routing table is called the MRIB or routing table with routes. This routing table is called the MRIB or
Multicast Routing Information Base. The routes in this table may be Multicast Routing Information Base. The routes in this table may be
taken directly from the unicast routing table, or it may be different taken directly from the unicast routing table, or it may be different
and provided by a separate routing protocol such as MBGP [9]. Regardless and provided by a separate routing protocol such as MBGP [10].
of how it is created, the primary role of the MRIB in the PIM protocol Regardless of how it is created, the primary role of the MRIB in the PIM
is to provide the next hop router along a multicast-capable path to each protocol is to provide the next hop router along a multicast-capable
destination subnet. The MRIB is used to determine the next hop neighbor path to each destination subnet. The MRIB is used to determine the next
to which any PIM Join/Prune message is sent. Data flows along the hop neighbor to which any PIM Join/Prune message is sent. Data flows
reverse path of the Join messages. Thus, in contrast to the unicast RIB along the reverse path of the Join messages. Thus, in contrast to the
which specifies the next hop that a data packet would take to get to unicast RIB which specifies the next hop that a data packet would take
some subnet, the MRIB gives reverse-path information, and indicates the to get to some subnet, the MRIB gives reverse-path information, and
path that a multicast data packet would take from its origin subnet to indicates the path that a multicast data packet would take from its
the router that has the MRIB. origin subnet to the router that has the MRIB.
Like all multicast routing protocols that implement the service model Like all multicast routing protocols that implement the service model
from RFC 1112 [2], PIM-SM must be able to route data packets from from RFC 1112 [3], PIM-SM must be able to route data packets from
sources to receivers without either the sources or receivers knowing a- sources to receivers without either the sources or receivers knowing a-
priori of the existence of the others. This is essentially done in priori of the existence of the others. This is essentially done in
three phases, although as senders and receivers may come and go at any three phases, although as senders and receivers may come and go at any
time, all three phases may be occur simultaneously. time, all three phases may occur simultaneously.
Phase One: RP Tree Phase One: RP Tree
In phase one, a multicast receiver expresses its interest in receiving In phase one, a multicast receiver expresses its interest in receiving
traffic destined for a multicast group. Typically it does this using traffic destined for a multicast group. Typically it does this using
IGMP [1] or MLD [3], but other mechanisms might also serve this purpose. IGMP [2] or MLD [4], but other mechanisms might also serve this purpose.
One of the receiver's local routers is elected as the Designated Router One of the receiver's local routers is elected as the Designated Router
(DR) for that subnet. On receiving the receiver's expression of (DR) for that subnet. On receiving the receiver's expression of
interest, the DR then sends a PIM Join message towards the RP for that interest, the DR then sends a PIM Join message towards the RP for that
multicast group. This Join message is known as a (*,G) Join because it multicast group. This Join message is known as a (*,G) Join because it
joins group G for all sources to that group. The (*,G) Join travels joins group G for all sources to that group. The (*,G) Join travels
hop-by-hop towards the RP for the group, and in each router it passes hop-by-hop towards the RP for the group, and in each router it passes
through, multicast tree state for group G is instantiated. Eventually through, multicast tree state for group G is instantiated. Eventually
the (*,G) Join either reaches the RP, or reaches a router that already the (*,G) Join either reaches the RP, or reaches a router that already
has (*,G) Join state for that group. When many receivers join the has (*,G) Join state for that group. When many receivers join the
group, their Join messages converge on the RP, and form a distribution group, their Join messages converge on the RP, and form a distribution
tree for group G that is rooted at the RP. This is known as the RP Tree tree for group G that is rooted at the RP. This is known as the RP Tree
skipping to change at page 10, line 42 skipping to change at page 10, line 47
shared tree to the receiver is built. shared tree to the receiver is built.
Phase 3: Shortest-Path Tree Phase 3: Shortest-Path Tree
Although having the RP join back towards the source removes the Although having the RP join back towards the source removes the
encapsulation overhead, it does not completely optimize the forwarding encapsulation overhead, it does not completely optimize the forwarding
paths. For many receivers the route via the RP may involve a paths. For many receivers the route via the RP may involve a
significant detour when compared with the shortest path from the source significant detour when compared with the shortest path from the source
to the receiver. to the receiver.
To obtain lower latencies or more efficient bandwidth utilization, a | To obtain lower latencies or more efficient bandwidth utilization, a
router on the receiver's LAN, typically the DR, may optionally initiate router on the receiver's LAN, typically the DR, may optionally initiate
a transfer from the shared tree to a source-specific shortest-path tree a transfer from the shared tree to a source-specific shortest-path tree
(SPT). To do this, it issues an (S,G) Join towards S. This instantiates (SPT). To do this, it issues an (S,G) Join towards S. This instantiates
state in the routers along the path to S. Eventually this join either state in the routers along the path to S. Eventually this join either
reaches S's subnet, or reaches a router that already has (S,G) state. reaches S's subnet, or reaches a router that already has (S,G) state.
When this happens, data packets from S start to flow following the (S,G) When this happens, data packets from S start to flow following the (S,G)
state until they reach the receiver. state until they reach the receiver.
At this point the receiver (or a router upstream of the receiver) will At this point the receiver (or a router upstream of the receiver) will
be receiving two copies of the data - one from the SPT and one from the be receiving two copies of the data - one from the SPT and one from the
RPT. When the first traffic starts to arrive from the SPT, the DR or RPT. When the first traffic starts to arrive from the SPT, the DR or
upstream router starts to drop the packets for G from S that arrive via upstream router starts to drop the packets for G from S that arrive via
the RP tree. In addition, it sends an (S,G) Prune message towards the the RP tree. In addition, it sends an (S,G) Prune message towards the
skipping to change at page 14, line 49 skipping to change at page 15, line 11
forwarding operations - for example, the "NoInfo" state might be assumed forwarding operations - for example, the "NoInfo" state might be assumed
from the lack of other state information, rather than being held from the lack of other state information, rather than being held
explicitly. explicitly.
4.1.1. General Purpose State 4.1.1. General Purpose State
A router holds the following non-group-specific state: A router holds the following non-group-specific state:
For each interface: For each interface:
o Override Interval o Effective Override Interval
o Effective Propagation Delay
o Propagation Delay
o Suppression state: One of {"Enable", "Disable"} o Suppression state: One of {"Enable", "Disable"}
Neighbor State: Neighbor State:
For each neighbor: For each neighbor:
o Information from neighbor's Hello o Information from neighbor's Hello
o Neighbor's GenID. o Neighbor's GenID.
o Neighbor Liveness Timer (NLT) o Neighbor Liveness Timer (NLT)
Designated Router (DR) State: Designated Router (DR) State:
o Designated Router's IP Address o Designated Router's IP Address
o DR's DR Priority o DR's DR Priority
The Override Interval, the Propagation Delay and the Interface The Effective Override Interval, the Effective Propagation Delay and the
suppression state are described in Section 4.3.3. Designated Router Interface suppression state are described in Section 4.3.3. Designated
state is described in Section 4.3. Router state is described in Section 4.3.
4.1.2. (*,*,RP) State 4.1.2. (*,*,RP) State
For every RP a router keeps the following state: For every RP a router keeps the following state:
(*,*,RP) state: (*,*,RP) state:
For each interface: For each interface:
PIM (*,*,RP) Join/Prune State: PIM (*,*,RP) Join/Prune State:
skipping to change at page 22, line 34 skipping to change at page 22, line 39
joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G) joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)
immediate_olist(S,G) = immediate_olist(S,G) =
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G) joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
inherited_olist(S,G,rpt) = inherited_olist(S,G,rpt) =
( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G)) (+) ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) ) (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
inherited_olist(S,G) = | inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+) | inherited_olist(S,G,rpt) (+)
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G) joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces
to which traffic might be forwarded because of hosts that are local to which traffic might be forwarded because of hosts that are local
members on that interface. Note that normally only the DR cares about members on that interface. Note that normally only the DR cares about
local membership, but when an assert happens, the assert winner takes local membership, but when an assert happens, the assert winner takes
over responsibility for forwarding traffic to local members that have over responsibility for forwarding traffic to local members that have
requested traffic on a group or source/group pair. requested traffic on a group or source/group pair.
pim_include(*,G) = pim_include(*,G) =
skipping to change at page 23, line 10 skipping to change at page 23, line 14
OR AssertWinner(*,G,I) == me ) OR AssertWinner(*,G,I) == me )
AND local_receiver_include(*,G,I) } AND local_receiver_include(*,G,I) }
pim_include(S,G) = pim_include(S,G) =
{ all interfaces I such that: { all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE ) ( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE )
OR AssertWinner(S,G,I) == me ) OR AssertWinner(S,G,I) == me )
AND local_receiver_include(S,G,I) } AND local_receiver_include(S,G,I) }
pim_exclude(S,G) = pim_exclude(S,G) =
{ all interfaces I such that: | { all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE ) | ( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
OR AssertWinner(*,G,I) == me ) | OR AssertWinner(*,G,I) == me )
AND local_receiver_exclude(S,G,I) } AND local_receiver_exclude(S,G,I) }
The clause "local_receiver_include(S,G,I)" is true if the IGMP/MLD The clause "local_receiver_include(S,G,I)" is true if the IGMP/MLD
module or other local membership mechanism has determined that local | module or other local membership mechanism has determined that local
members on interface I desire to receive traffic sent specifically by S members on interface I desire to receive traffic sent specifically by S
to G. "local_receiver_include(*,G,I)" is true if the IGMP/MLD module or to G. "local_receiver_include(*,G,I)" is true if the IGMP/MLD module or
other local membership mechanism has determined that local members on | other local membership mechanism has determined that local members on
interface I desire to receive all traffic sent to G (possibly excluding | interface I desire to receive all traffic sent to G (possibly excluding
traffic from a specific set of sources). "local_receiver_exclude(S,G,I) | traffic from a specific set of sources). "local_receiver_exclude(S,G,I)
is true if "local_receiver_include(*,G,I)" is true but none of the local is true if "local_receiver_include(*,G,I)" is true but none of the local
members desire to receive traffic from S. members desire to receive traffic from S.
The set "joins(*,*,RP)" is the set of all interfaces on which the router The set "joins(*,*,RP)" is the set of all interfaces on which the router
has received (*,*,RP) Joins: has received (*,*,RP) Joins:
joins(*,*,RP) = joins(*,*,RP) =
{ all interfaces I such that { all interfaces I such that
DownstreamJPState(*,*,RP,I) is either Join or DownstreamJPState(*,*,RP,I) is either Join or
Prune-Pending } Prune-Pending }
skipping to change at page 27, line 13 skipping to change at page 27, line 15
empty, we forward the packet out of those interfaces. empty, we forward the packet out of those interfaces.
On receipt of data from S to G on interface iif: On receipt of data from S to G on interface iif:
if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) { if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) {
set KeepaliveTimer(S,G) to Keepalive_Period set KeepaliveTimer(S,G) to Keepalive_Period
# Note: a register state transition or UpstreamJPState(S,G) # Note: a register state transition or UpstreamJPState(S,G)
# transition may happen as a result of restarting # transition may happen as a result of restarting
# KeepaliveTimer, and must be dealt with here. # KeepaliveTimer, and must be dealt with here.
} }
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND | if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND
inherited_olist(S,G) != NULL ) { | inherited_olist(S,G) != NULL ) {
set KeepaliveTimer(S,G) to Keepalive_Period | set KeepaliveTimer(S,G) to Keepalive_Period
} | }
Update_SPTbit(S,G,iif) Update_SPTbit(S,G,iif)
oiflist = NULL oiflist = NULL
if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) { | if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) {
oiflist = inherited_olist(S,G) oiflist = inherited_olist(S,G)
} else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE) { } else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE) {
oiflist = inherited_olist(S,G,rpt) oiflist = inherited_olist(S,G,rpt)
CheckSwitchToSpt(S,G) CheckSwitchToSpt(S,G)
} else { } else {
# Note: RPF check failed # Note: RPF check failed
# A transition in an Assert FSM, may cause an Assert(S,G) | # A transition in an Assert FSM, may cause an Assert(S,G)
# or Assert(*,G) message to be sent out interface iif. | # or Assert(*,G) message to be sent out interface iif.
# See section 4.6 for details. | # See section 4.6 for details.
if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) { if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif send Assert(S,G) on iif
} else if ( SPTbit(S,G) == FALSE AND } else if ( SPTbit(S,G) == FALSE AND
iif is in inherited_olist(S,G,rpt) { iif is in inherited_olist(S,G,rpt) {
send Assert(*,G) on iif send Assert(*,G) on iif
} }
} }
oiflist = oiflist (-) iif oiflist = oiflist (-) iif
forward packet on all interfaces in oiflist forward packet on all interfaces in oiflist
skipping to change at page 28, line 9 skipping to change at page 28, line 9
directly connected to this router (or for packets originating on this directly connected to this router (or for packets originating on this
router). router).
inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section
4.1. 4.1.
Basically inherited_olist(S,G) is the outgoing interface list for Basically inherited_olist(S,G) is the outgoing interface list for
packets forwarded on (S,G) state taking into account (*,*,RP) state, packets forwarded on (S,G) state taking into account (*,*,RP) state,
(*,G) state, asserts, etc. (*,G) state, asserts, etc.
inherited_olist(S,G,rpt) is the outgoing interface for packets forwarded inherited_olist(S,G,rpt) is the outgoing interface list for packets
on (*,*,RP) or (*,G) state taking into account (S,G,rpt) prune state, forwarded on (*,*,RP) or (*,G) state taking into account (S,G,rpt) prune
and asserts, etc. state, and asserts, etc.
Update_SPTbit(S,G,iif) is defined in Section 4.2.2. Update_SPTbit(S,G,iif) is defined in Section 4.2.2.
CheckSwitchToSpt(S,G) is defined in Section 4.2.1. CheckSwitchToSpt(S,G) is defined in Section 4.2.1.
UpstreamJPState(S,G) is the state of the finite state machine in Section UpstreamJPState(S,G) is the state of the finite state machine in Section
4.5.7. 4.5.7.
Keepalive_Period is defined in Section 4.10. Keepalive_Period is defined in Section 4.10.
skipping to change at page 28, line 40 skipping to change at page 28, line 40
shortest path tree (SPT). shortest path tree (SPT).
The decision for a router to switch to the SPT is controlled as follows: The decision for a router to switch to the SPT is controlled as follows:
void void
CheckSwitchToSpt(S,G) { CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) pim_exclude(S,G) if ( ( pim_include(*,G) (-) pim_exclude(S,G)
(+) pim_include(S,G) != NULL ) (+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) { AND SwitchToSptDesired(S,G) ) {
# Note: Restarting the KAT will result in the SPT switch # Note: Restarting the KAT will result in the SPT switch
restart KeepaliveTimer(S,G); set KeepaliveTimer(S,G) to Keepalive_Period
} }
} }
SwitchToSptDesired(S,G) is a policy function that is implementation SwitchToSptDesired(S,G) is a policy function that is implementation
defined. An "infinite threshold" policy can be implemented making defined. An "infinite threshold" policy can be implemented making
SwitchToSptDesired(S,G) return false all the time. A "switch on first SwitchToSptDesired(S,G) return false all the time. A "switch on first
packet" policy can be implemented by making SwitchToSptDesired(S,G) packet" policy can be implemented by making SwitchToSptDesired(S,G)
return true once a single packet has been received for the source and return true once a single packet has been received for the source and
group. group.
skipping to change at page 31, line 46 skipping to change at page 31, line 46
information about that neighbor SHOULD be discarded and superseded by information about that neighbor SHOULD be discarded and superseded by
the information from the new Hello message. This may cause a new DR to the information from the new Hello message. This may cause a new DR to
be chosen on that interface. be chosen on that interface.
The LAN Prune Delay Option SHOULD be included in all Hello messages sent The LAN Prune Delay Option SHOULD be included in all Hello messages sent
on multi-access LANs. This option advertises a router's capability to on multi-access LANs. This option advertises a router's capability to
use values other than the default for the Propagation_Delay and use values other than the default for the Propagation_Delay and
Override_Interval which affect the setting of the Prune-Pending, Override_Interval which affect the setting of the Prune-Pending,
Upstream Join and Override Timers (defined in Section 4.10). Upstream Join and Override Timers (defined in Section 4.10).
The Interface_Address_List Option advertises all the secondary addresses The Address List Option advertises all the secondary addresses
associated with the source interface of the router originating the associated with the source interface of the router originating the
message. The option MUST be included in all Hello messages if there are message. The option MUST be included in all Hello messages if there are
secondary addresses associated with the source interface and MAY be secondary addresses associated with the source interface and MAY be
omitted if no secondary addresses exist. omitted if no secondary addresses exist.
To allow new or rebooting routers to learn of PIM neighbors quickly, To allow new or rebooting routers to learn of PIM neighbors quickly,
when a Hello message is received from a new neighbor, or a Hello message when a Hello message is received from a new neighbor, or a Hello message
with a new GenID is received from an existing neighbor, a new Hello with a new GenID is received from an existing neighbor, a new Hello
message should be sent on this interface after a randomized delay message should be sent on this interface after a randomized delay
between 0 and Triggered_Hello_Delay. This triggered message need not between 0 and Triggered_Hello_Delay. This triggered message need not
skipping to change at page 34, line 15 skipping to change at page 34, line 15
The DR Priority is a 32-bit unsigned number and the numerically larger The DR Priority is a 32-bit unsigned number and the numerically larger
priority is always preferred. A router's idea of the current DR on an priority is always preferred. A router's idea of the current DR on an
interface can change when a PIM Hello message is received, when a interface can change when a PIM Hello message is received, when a
neighbor times out, or when a router's own DR Priority changes. If the neighbor times out, or when a router's own DR Priority changes. If the
router becomes the DR or ceases to be the DR, this will normally cause router becomes the DR or ceases to be the DR, this will normally cause
the DR Register state machine to change state. Subsequent actions are the DR Register state machine to change state. Subsequent actions are
determined by that state machine. determined by that state machine.
We note that some PIM implementations do not send Hello We note that some PIM implementations do not send Hello
messages on point-to-point interfaces, and so cannot perform messages on point-to-point interfaces, and so cannot perform
DR election on such interfaces. This in non-compliant DR election on such interfaces. This is non-compliant
behavior. DR election MUST be performed on ALL active PIM-SM behavior. DR election MUST be performed on ALL active PIM-SM
interfaces. interfaces.
4.3.3. Reducing Prune Propagation Delay on LANs 4.3.3. Reducing Prune Propagation Delay on LANs
In addition to the information recorded for the DR Election, the In addition to the information recorded for the DR Election, the
following per neighbor information is obtained from the LAN Prune Delay following per neighbor information is obtained from the LAN Prune Delay
Hello option: Hello option:
neighbor.lan_prune_delay_present neighbor.lan_prune_delay_present
skipping to change at page 35, line 15 skipping to change at page 35, line 15
bool bool
lan_delay_enabled(I) { lan_delay_enabled(I) {
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.lan_prune_delay_present == false ) { if ( neighbor.lan_prune_delay_present == false ) {
return false return false
} }
} }
return true return true
} }
The Propagation Delay inserted by a router in the LAN Prune Delay option | The Propagation Delay inserted by a router in the LAN Prune Delay option
expresses the expected message propagation delay on the link and should expresses the expected message propagation delay on the link and should
be configurable by the system administrator. It is used by upstream be configurable by the system administrator. It is used by upstream
routers to figure out how long they should wait for a Join override routers to figure out how long they should wait for a Join override
message before pruning an interface. message before pruning an interface.
PIM implementors should enforce a lower bound on the permitted values PIM implementors should enforce a lower bound on the permitted values
for this delay to allow for scheduling and processing delays within for this delay to allow for scheduling and processing delays within
their router. Such delays may cause received messages to be processed their router. Such delays may cause received messages to be processed
later as well as triggered messages to be sent later than intended. later as well as triggered messages to be sent later than intended.
Setting this Propagation Delay to too low a value may result in Setting this Propagation Delay to too low a value may result in
skipping to change at page 39, line 34 skipping to change at page 39, line 34
| || | | | Stop | | | || | | | Stop | |
| || | | | Timer(*) | | | || | | | Timer(*) | |
+-----------++-----------+------------+------------+------------+------------+ +-----------++-----------+------------+------------+------------+------------+
| ||-> J state | - | -> NI | -> P state | -> J state | | ||-> J state | - | -> NI | -> P state | -> J state |
| || | | state | | | | || | | state | | |
|Join- ||add reg | | | set | add reg | |Join- ||add reg | | | set | add reg |
|Pending ||tunnel | | | Register- | tunnel; | |Pending ||tunnel | | | Register- | tunnel; |
|(JP) || | | | Stop | cancel | |(JP) || | | | Stop | cancel |
| || | | | Timer(*) | Register- | | || | | | Timer(*) | Register- |
| || | | | | Stop Timer | | || | | | | Stop Timer |
Tim+-----------++-----------+------------+------------+------------+------------+ +-----------++-----------+------------+------------+------------+------------+
| ||-> JP | - | -> NI | - | -> J state | | ||-> JP | - | -> NI | - | -> J state |
| ||state | | state | | | | ||state | | state | | |
| ||set | | | | add reg | | ||set | | | | add reg |
|Prune (P) ||Register- | | | | tunnel; | |Prune (P) ||Register- | | | | tunnel; |
| ||Stop | | | | cancel | | ||Stop | | | | cancel |
| ||Timer(**); | | | | Register- | | ||Timer(**); | | | | Register- |
| ||send Null- | | | | Stop Timer | | ||send Null- | | | | Stop Timer |
| ||Register | | | | | | ||Register | | | | |
+-----------++-----------+------------+------------+------------+------------+ +-----------++-----------+------------+------------+------------+------------+
skipping to change at page 40, line 15 skipping to change at page 40, line 15
(**) The Register-Stop Timer is set to Register_Probe_Time. (**) The Register-Stop Timer is set to Register_Probe_Time.
The following actions are defined: The following actions are defined:
Add Register Tunnel Add Register Tunnel
A Register-Tunnel virtual interface, VI, is created (if it doesn't A Register-Tunnel virtual interface, VI, is created (if it doesn't
already exist) with its encapsulation target being RP(G). already exist) with its encapsulation target being RP(G).
DownstreamJPState(S,G,VI) is set to Join state, causing the tunnel DownstreamJPState(S,G,VI) is set to Join state, causing the tunnel
interface to be added to immediate_olist(S,G). interface to be added to immediate_olist(S,G) and inherited_olist(S,G).
Remove Register Tunnel Remove Register Tunnel
VI is the Register-Tunnel virtual interface with encapsulation target of VI is the Register-Tunnel virtual interface with encapsulation target of
RP(G). DownstreamJPState(S,G,VI) is set to NoInfo state, causing the RP(G). DownstreamJPState(S,G,VI) is set to NoInfo state, causing the
tunnel interface to be removed from immediate_olist(S,G). If tunnel interface to be removed from immediate_olist(S,G) and
DownstreamJPState(S,G,VI) is NoInfo for all (S,G), then VI can be inherited_olist(S,G). If DownstreamJPState(S,G,VI) is NoInfo for all
deleted. (S,G), then VI can be deleted.
Update Register Tunnel Update Register Tunnel
This action occurs when RP(G) changes. This action occurs when RP(G) changes.
VI_old is the Register-Tunnel virtual interface with encapsulation VI_old is the Register-Tunnel virtual interface with encapsulation
target old_RP(G). A Register-Tunnel virtual interface, VI_new, is target old_RP(G). A Register-Tunnel virtual interface, VI_new, is
created (if it doesn't already exist) with its encapsulation target created (if it doesn't already exist) with its encapsulation target
being new_RP(G). DownstreamJPState(S,G,VI_old) is set to NoInfo state being new_RP(G). DownstreamJPState(S,G,VI_old) is set to NoInfo state
and DownstreamJPState(S,G,VI_new) is set to Join state. If and DownstreamJPState(S,G,VI_new) is set to Join state. If
skipping to change at page 41, line 43 skipping to change at page 41, line 43
normal TTL that the router would use for any locally-generated IP normal TTL that the router would use for any locally-generated IP
packet. packet.
The IP ECN bits should be copied from the original packet to the IP The IP ECN bits should be copied from the original packet to the IP
header of the encapsulating packet. They SHOULD NOT be set header of the encapsulating packet. They SHOULD NOT be set
independently by the encapsulating router. independently by the encapsulating router.
The Diffserv Code Point (DSCP) should be copied from the original packet The Diffserv Code Point (DSCP) should be copied from the original packet
to the IP header of the encapsulating packet. It MAY be set to the IP header of the encapsulating packet. It MAY be set
independently by the encapsulating router, based upon static independently by the encapsulating router, based upon static
configuration or traffic classification. See [10] for more discussion configuration or traffic classification. See [12] for more discussion
on setting the DSCP on tunnels. on setting the DSCP on tunnels.
Handling Register-Stop(*,G) Messages at the DR Handling Register-Stop(*,G) Messages at the DR
An old RP might send a Register-Stop message with the source address set An old RP might send a Register-Stop message with the source address set
to all-zeros. This was the normal course of action in RFC 2326 when the to all-zeros. This was the normal course of action in RFC 2362 when the
Register message matched against (*,G) state at the RP, and was defined Register message matched against (*,G) state at the RP, and was defined
as meaning "stop encapsulating all sources for this group". However, as meaning "stop encapsulating all sources for this group". However,
the behavior of such a Register-Stop(*,G) is ambiguous or incorrect in the behavior of such a Register-Stop(*,G) is ambiguous or incorrect in
some circumstances. some circumstances.
We specify that an RP should not send Register-Stop(*,G) messages, but We specify that an RP should not send Register-Stop(*,G) messages, but
for compatibility, a DR should be able to accept one if it is received. for compatibility, a DR should be able to accept one if it is received.
A Register-Stop(*,G) should be treated as a Register-Stop(S,G) for all A Register-Stop(*,G) should be treated as a Register-Stop(S,G) for all
skipping to change at page 43, line 32 skipping to change at page 43, line 32
drop the packet silently. drop the packet silently.
} }
} }
if ( SPTbit(S,G) OR if ( SPTbit(S,G) OR
( SwitchToSptDesired(S,G) AND ( inherited_olist(S,G) == NULL ))) { ( SwitchToSptDesired(S,G) AND ( inherited_olist(S,G) == NULL ))) {
send Register-Stop(S,G) to outer.src send Register-Stop(S,G) to outer.src
sentRegisterStop = TRUE; sentRegisterStop = TRUE;
} }
if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) { if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) {
if ( sentRegisterStop == TRUE ) { if ( sentRegisterStop == TRUE ) {
restart KeepaliveTimer(S,G) to RP_Keepalive_Period; set KeepaliveTimer(S,G) to RP_Keepalive_Period;
} else { } else {
restart KeepaliveTimer(S,G) to Keepalive_Period; set KeepaliveTimer(S,G) to Keepalive_Period;
} }
} }
if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) { if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) {
decapsulate and forward the inner packet to decapsulate and forward the inner packet to
inherited_olist(S,G,rpt) # Note (+) inherited_olist(S,G,rpt) # Note (+)
} }
} else { } else {
send Register-Stop(S,G) to outer.src send Register-Stop(S,G) to outer.src
# Note (*) # Note (*)
} }
skipping to change at page 44, line 47 skipping to change at page 44, line 47
When forwarding a packet from the Register Tunnel, the TTL of the When forwarding a packet from the Register Tunnel, the TTL of the
original data packet is decremented after it is decapsulated. original data packet is decremented after it is decapsulated.
The IP ECN bits should be copied from the IP header of the Register The IP ECN bits should be copied from the IP header of the Register
packet to the decapsulated packet. packet to the decapsulated packet.
The Diffserv Code Point (DSCP) should be copied from the IP header of The Diffserv Code Point (DSCP) should be copied from the IP header of
the Register packet to the decapsulated packet. The RP MAY retain the the Register packet to the decapsulated packet. The RP MAY retain the
DSCP of the inner packet, or re-classify the packet and apply a DSCP of the inner packet, or re-classify the packet and apply a
different DSCP. Scenarios where each of these might be useful are different DSCP. Scenarios where each of these might be useful are
discussed in [10]. discussed in [12].
4.5. PIM Join/Prune Messages 4.5. PIM Join/Prune Messages
A PIM Join/Prune message consists of a list of groups and a list of A PIM Join/Prune message consists of a list of groups and a list of
Joined and Pruned sources for each group. When processing a received Joined and Pruned sources for each group. When processing a received
Join/Prune message, each Joined or Pruned source for a Group is Join/Prune message, each Joined or Pruned source for a Group is
effectively considered individually, and applies to one or more of the effectively considered individually, and applies to one or more of the
following state machines. When considering a Join/Prune message whose following state machines. When considering a Join/Prune message whose
Upstream Neighbor Address field addresses this router, (*,G) Joins and Upstream Neighbor Address field addresses this router, (*,G) Joins and
skipping to change at page 46, line 21 skipping to change at page 46, line 21
Expiry of the ExpiryTimer causes the interface state to revert Expiry of the ExpiryTimer causes the interface state to revert
to NoInfo for this RP. to NoInfo for this RP.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(*,*,RP) is received. This timer is set when a valid Prune(*,*,RP) is received.
Expiry of the Prune-Pending Timer causes the interface state Expiry of the Prune-Pending Timer causes the interface state
to revert to NoInfo for this RP. to revert to NoInfo for this RP.
Figure 2: Downstream per-interface (*,*,RP) state machine in tabular form Figure 2: Downstream per-interface (*,*,RP) state machine in tabular form
r+-------------++----------------------------------------------------------+ +-------------++----------------------------------------------------------+
| || Event | | || Event |
| ++-------------+--------------+--------------+--------------+ | ++-------------+--------------+--------------+--------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer | |Prev State ||Receive | Receive | Prune- | Expiry Timer |
| ||Join(*,*,RP) | Prune | Pending | Expires | | ||Join(*,*,RP) | Prune | Pending | Expires |
| || | (*,*,RP) | Timer | | | || | (*,*,RP) | Timer | |
| || | | Expires | | | || | | Expires | |
|+-------------++-------------+--------------+--------------+--------------+ +-------------++-------------+--------------+--------------+--------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | | |NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | | | ||Timer | | | |
|+-------------++-------------+--------------+--------------+--------------+ +-------------++-------------+--------------+--------------+--------------+
| ||-> J state | -> PP state | - | -> NI state | | ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | | |Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | | | ||Expiry Timer | Pending | | |
| || | Timer | | | | || | Timer | | |
|+-------------++-------------+--------------+--------------+--------------+ +-------------++-------------+--------------+--------------+--------------+
|Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
|Pending (PP) ||restart | | Send Prune- | | |Pending (PP) ||restart | | Send Prune- | |
| ||Expiry Timer | | Echo(*,*,RP) | | | ||Expiry Timer | | Echo(*,*,RP) | |
|+-------------++-------------+--------------+--------------+--------------+ +-------------++-------------+--------------+--------------+--------------+
The transition events "Receive Join(*,*,RP)" and "Receive Prune(*,*,RP)" | The transition events "Receive Join(*,*,RP)" and "Receive Prune(*,*,RP)"
imply receiving a Join or Prune targeted to this router's primary IP | imply receiving a Join or Prune targeted to this router's primary IP
address on the received interface. If the destination address is not address on the received interface. If the upstream neighbor address
correct, these state transitions in this state machine must not occur, field is not correct, these state transitions in this state machine must
although seeing such a packet may cause state transitions in other state not occur, although seeing such a packet may cause state transitions in
machines. other state machines.
On unnumbered interfaces on point-to-point links, the router's address On unnumbered interfaces on point-to-point links, the router's address
should be the same as the source address it chose for the Hello message should be the same as the source address it chose for the Hello message
it sent over that interface. However on point-to-point links we also it sent over that interface. However on point-to-point links we also
recommend that for backwards compatibility PIM Join/Prune messages with recommend that for backwards compatibility PIM Join/Prune messages with
a destination address of all zeros are also accepted. a upstream neighbor address field of all zeros are also accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(*,*,RP) Receive Join(*,*,RP)
A Join(*,*,RP) is received on interface I with its Upstream A Join(*,*,RP) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
transitions to the Join state. The Expiry Timer (ET) is transitions to the Join state. The Expiry Timer (ET) is
started, and set to the HoldTime from the triggering started, and set to the HoldTime from the triggering
Join/Prune message. Join/Prune message.
Note that it is possible to receive a Join(*,*,RP) message for Note that it is possible to receive a Join(*,*,RP) message for
an RP that we do not have information telling us that it is an an RP that we do not have information telling us that it is an
RP. In the case of (*,*,RP) state, so long as we have a route RP. In the case of (*,*,RP) state, so long as we have a route
to the RP, this will not cause a problem, and the transition to the RP, this will not cause a problem, and the transition
should still take place. should still take place.
Transitions from Join State Transitions from Join State
When in Join state, the following events may trigger a transition: When in Join state, the following events may trigger a transition:
Receive Join(*,*,RP) Receive Join(*,*,RP)
A Join(*,*,RP) is received on interface I with its Upstream A Join(*,*,RP) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (*,*,RP) downstream state machine on interface I remains The (*,*,RP) downstream state machine on interface I remains
in Join state, and the Expiry Timer (ET) is restarted, set to in Join state, and the Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the maximum of its current value and the HoldTime from the
triggering Join/Prune message. triggering Join/Prune message.
Receive Prune(*,*,RP) Receive Prune(*,*,RP)
A Prune(*,*,RP) is received on interface I with its Upstream A Prune(*,*,RP) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
transitions to the Prune-Pending state. The Prune-Pending transitions to the Prune-Pending state. The Prune-Pending
Timer is started; it is set to the J/P_Override_Interval(I) if Timer is started; it is set to the J/P_Override_Interval(I) if
the router has more than one neighbor on that interface; the router has more than one neighbor on that interface;
otherwise it is set to zero causing it to expire immediately. otherwise it is set to zero causing it to expire immediately.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (*,*,RP) downstream state machine on The Expiry Timer for the (*,*,RP) downstream state machine on
interface I expires. interface I expires.
skipping to change at page 48, line 16 skipping to change at page 48, line 16
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
transitions to the NoInfo state. transitions to the NoInfo state.
Transitions from Prune-Pending State Transitions from Prune-Pending State
When in Prune-Pending state, the following events may trigger a When in Prune-Pending state, the following events may trigger a
transition: transition:
Receive Join(*,*,RP) Receive Join(*,*,RP)
A Join(*,*,RP) is received on interface I with its Upstream A Join(*,*,RP) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
transitions to the Join state. The Prune-Pending Timer is transitions to the Join state. The Prune-Pending Timer is
canceled (without triggering an expiry event). The Expiry canceled (without triggering an expiry event). The Expiry
Timer is restarted, set to maximum of its current value and Timer is restarted, set to maximum of its current value and
the HoldTime from the triggering Join/Prune message. the HoldTime from the triggering Join/Prune message.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (*,*,RP) downstream state machine on The Expiry Timer for the (*,*,RP) downstream state machine on
interface I expires. interface I expires.
skipping to change at page 49, line 7 skipping to change at page 49, line 7
the Upstream Neighbor Address field. Its purpose is to add the Upstream Neighbor Address field. Its purpose is to add
additional reliability so that if a Prune that should have additional reliability so that if a Prune that should have
been overridden by another router is lost locally on the LAN, been overridden by another router is lost locally on the LAN,
then the PruneEcho may be received and cause the override to then the PruneEcho may be received and cause the override to
happen. A PruneEcho(*,*,RP) need not be sent on an interface happen. A PruneEcho(*,*,RP) need not be sent on an interface
that contains only a single PIM neighbor during the time this that contains only a single PIM neighbor during the time this
state machine was in Prune-Pending state. state machine was in Prune-Pending state.
4.5.2. Receiving (*,G) Join/Prune Messages 4.5.2. Receiving (*,G) Join/Prune Messages
When a router receives a Join(*,G) or Prune(*,G) it must first check to When a router receives a Join(*,G) it must first check to see whether
see whether the RP in the message matches RP(G) (the router's idea of the RP in the message matches RP(G) (the router's idea of who the RP
who the RP is). If the RP in the message does not match RP(G) the is). If the RP in the message does not match RP(G) the Join(*,G) should
Join(*,G) or Prune(*,G) should be silently dropped. (Note that other be silently dropped. (Note that other source list entries such as
source list entries such as (S,G,rpt) or (S,G) in the same Group (S,G,rpt) or (S,G) in the same Group Specific Set should still be
Specific Set should still be processed.) If a router has no RP processed.) If a router has no RP information (e.g. has not recently
information (e.g. has not recently received a BSR message) then it may received a BSR message) then it may choose to accept Join(*,G) and treat
choose to accept Join(*,G) or Prune(*,G) and treat the RP in the message the RP in the message as RP(G). Received Prune(*,G) messages are
as RP(G). processed even if the RP in the message does not match RP(G).
The per-interface state machine for receiving (*,G) Join/Prune Messages The per-interface state machine for receiving (*,G) Join/Prune Messages
is given below. There are three states: is given below. There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (*,G) Join state and no timers running. The interface has no (*,G) Join state and no timers running.
Join (J) Join (J)
The interface has (*,G) Join state which will cause the router The interface has (*,G) Join state which will cause the router
to forward packets destined for G from this interface except to forward packets destined for G from this interface except
skipping to change at page 50, line 7 skipping to change at page 50, line 7
Expiry of the Expiry Timer causes the interface state to Expiry of the Expiry Timer causes the interface state to
revert to NoInfo for this group. revert to NoInfo for this group.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(*,G) is received. Expiry This timer is set when a valid Prune(*,G) is received. Expiry
of the Prune-Pending Timer causes the interface state to of the Prune-Pending Timer causes the interface state to
revert to NoInfo for this group. revert to NoInfo for this group.
Figure 3: Downstream per-interface (*,G) state machine in tabular form Figure 3: Downstream per-interface (*,G) state machine in tabular form
i+-------------++---------------------------------------------------------+ +-------------++---------------------------------------------------------+
| || Event | | || Event |
| ++-------------+--------------+-------------+--------------+ | ++-------------+--------------+-------------+--------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer | |Prev State ||Receive | Receive | Prune- | Expiry Timer |
| ||Join(*,G) | Prune(*,G) | Pending | Expires | | ||Join(*,G) | Prune(*,G) | Pending | Expires |
| || | | Timer | | | || | | Timer | |
| || | | Expires | | | || | | Expires | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | | |NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | | | ||Timer | | | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> PP state | - | -> NI state | | ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | | |Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | | | ||Expiry Timer | Pending | | |
| || | Timer | | | | || | Timer | | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
|Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
|Pending (PP) ||restart | | Send Prune- | | |Pending (PP) ||restart | | Send Prune- | |
| ||Expiry Timer | | Echo(*,G) | | | ||Expiry Timer | | Echo(*,G) | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply | The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply
receiving a Join or Prune targeted to this router's primary IP address | receiving a Join or Prune targeted to this router's primary IP address
on the received interface. If the destination address is not correct, on the received interface. If the upstream neighbor address field is
these state transitions in this state machine must not occur, although not correct, these state transitions in this state machine must not
seeing such a packet may cause state transitions in other state occur, although seeing such a packet may cause state transitions in
machines. other state machines.
On unnumbered interfaces on point-to-point links, the router's address On unnumbered interfaces on point-to-point links, the router's address
should be the same as the source address it chose for the Hello message should be the same as the source address it chose for the Hello message
it sent over that interface. However on point-to-point links we also it sent over that interface. However on point-to-point links we also
recommend that for backwards compatibility PIM Join/Prune messages with recommend that for backwards compatibility PIM Join/Prune messages with
a destination address of all zeros are also accepted. a upstream neighbor address field of all zeros are also accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I transitions
to the Join state. The Expiry Timer (ET) is started, and set to the Join state. The Expiry Timer (ET) is started, and set
to the HoldTime from the triggering Join/Prune message. to the HoldTime from the triggering Join/Prune message.
Transitions from Join State Transitions from Join State
When in Join state, the following events may trigger a transition: When in Join state, the following events may trigger a transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (*,G) downstream state machine on interface I remains in The (*,G) downstream state machine on interface I remains in
Join state, and the Expiry Timer (ET) is restarted, set to Join state, and the Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the maximum of its current value and the HoldTime from the
triggering Join/Prune message. triggering Join/Prune message.
Receive Prune(*,G) Receive Prune(*,G)
A Prune(*,G) is received on interface I with its Upstream A Prune(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I transitions
to the Prune-Pending state. The Prune-Pending Timer is to the Prune-Pending state. The Prune-Pending Timer is
started; it is set to the J/P_Override_Interval(I) if the started; it is set to the J/P_Override_Interval(I) if the
router has more than one neighbor on that interface; otherwise router has more than one neighbor on that interface; otherwise
it is set to zero causing it to expire immediately. it is set to zero causing it to expire immediately.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (*,G) downstream state machine on The Expiry Timer for the (*,G) downstream state machine on
interface I expires. interface I expires.
skipping to change at page 51, line 42 skipping to change at page 51, line 42
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I transitions
to the NoInfo state. to the NoInfo state.
Transitions from Prune-Pending State Transitions from Prune-Pending State
When in Prune-Pending state, the following events may trigger a When in Prune-Pending state, the following events may trigger a
transition: transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I transitions
to the Join state. The Prune-Pending Timer is canceled to the Join state. The Prune-Pending Timer is canceled
(without triggering an expiry event). The Expiry Timer is (without triggering an expiry event). The Expiry Timer is
restarted, set to maximum of its current value and the restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message. HoldTime from the triggering Join/Prune message.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (*,G) downstream state machine on The Expiry Timer for the (*,G) downstream state machine on
interface I expires. interface I expires.
skipping to change at page 53, line 17 skipping to change at page 53, line 17
of the Expiry Timer causes this state machine to revert to of the Expiry Timer causes this state machine to revert to
NoInfo state. NoInfo state.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(S,G) is received. Expiry This timer is set when a valid Prune(S,G) is received. Expiry
of the Prune-Pending Timer causes this state machine to revert of the Prune-Pending Timer causes this state machine to revert
to NoInfo state. to NoInfo state.
Figure 4: Downstream per-interface (S,G) state machine in tabular form Figure 4: Downstream per-interface (S,G) state machine in tabular form
i+-------------++---------------------------------------------------------+ +-------------++---------------------------------------------------------+
| || Event | | || Event |
| ++-------------+--------------+-------------+--------------+ | ++-------------+--------------+-------------+--------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer | |Prev State ||Receive | Receive | Prune- | Expiry Timer |
| ||Join(S,G) | Prune(S,G) | Pending | Expires | | ||Join(S,G) | Prune(S,G) | Pending | Expires |
| || | | Timer | | | || | | Timer | |
| || | | Expires | | | || | | Expires | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | | |NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | | | ||Timer | | | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> PP state | - | -> NI state | | ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | | |Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | | | ||Expiry Timer | Pending | | |
| || | Timer | | | | || | Timer | | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
|Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
|Pending (PP) ||restart | | Send Prune- | | |Pending (PP) ||restart | | Send Prune- | |
| ||Expiry Timer | | Echo(S,G) | | | ||Expiry Timer | | Echo(S,G) | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
The transition events "Receive Join(S,G)" and "Receive Prune(S,G)" imply | The transition events "Receive Join(S,G)" and "Receive Prune(S,G)" imply
receiving a Join or Prune targeted to this router's primary IP address | receiving a Join or Prune targeted to this router's primary IP address
on the received interface. If the destination address is not correct, on the received interface. If the upstream neighbor address field is
these state transitions in this state machine must not occur, although not correct, these state transitions in this state machine must not
seeing such a packet may cause state transitions in other state occur, although seeing such a packet may cause state transitions in
machines. other state machines.
On unnumbered interfaces on point-to-point links, the router's address On unnumbered interfaces on point-to-point links, the router's address
should be the same as the source address it chose for the Hello message should be the same as the source address it chose for the Hello message
it sent over that interface. However on point-to-point links we also it sent over that interface. However on point-to-point links we also
recommend that for backwards compatibility PIM Join/Prune messages with recommend that for backwards compatibility PIM Join/Prune messages with
a destination address of all zeros are also accepted. a upstream neighbor address field of all zeros are also accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(S,G) Receive Join(S,G)
A Join(S,G) is received on interface I with its Upstream A Join(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I transitions
to the Join state. The Expiry Timer (ET) is started, and set to the Join state. The Expiry Timer (ET) is started, and set
to the HoldTime from the triggering Join/Prune message. to the HoldTime from the triggering Join/Prune message.
Transitions from Join State Transitions from Join State
When in Join state, the following events may trigger a transition: When in Join state, the following events may trigger a transition:
Receive Join(S,G) Receive Join(S,G)
A Join(S,G) is received on interface I with its Upstream A Join(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (S,G) downstream state machine on interface I remains in The (S,G) downstream state machine on interface I remains in
Join state, and the Expiry Timer (ET) is restarted, set to Join state, and the Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the maximum of its current value and the HoldTime from the
triggering Join/Prune message. triggering Join/Prune message.
Receive Prune(S,G) Receive Prune(S,G)
A Prune(S,G) is received on interface I with its Upstream A Prune(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I transitions
to the Prune-Pending state. The Prune-Pending Timer is to the Prune-Pending state. The Prune-Pending Timer is
started; it is set to the J/P_Override_Interval(I) if the started; it is set to the J/P_Override_Interval(I) if the
router has more than one neighbor on that interface; otherwise router has more than one neighbor on that interface; otherwise
it is set to zero causing it to expire immediately. it is set to zero causing it to expire immediately.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (S,G) downstream state machine on The Expiry Timer for the (S,G) downstream state machine on
interface I expires. interface I expires.
skipping to change at page 55, line 7 skipping to change at page 55, line 7
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I transitions
to the NoInfo state. to the NoInfo state.
Transitions from Prune-Pending State Transitions from Prune-Pending State
When in Prune-Pending state, the following events may trigger a When in Prune-Pending state, the following events may trigger a
transition: transition:
Receive Join(S,G) Receive Join(S,G)
A Join(S,G) is received on interface I with its Upstream A Join(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I transitions
to the Join state. The Prune-Pending Timer is canceled to the Join state. The Prune-Pending Timer is canceled
(without triggering an expiry event). The Expiry Timer is (without triggering an expiry event). The Expiry Timer is
restarted, set to maximum of its current value and the restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message. HoldTime from the triggering Join/Prune message.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (S,G) downstream state machine on The Expiry Timer for the (S,G) downstream state machine on
interface I expires. interface I expires.
skipping to change at page 56, line 21 skipping to change at page 56, line 21
prune will be overridden by another downstream router. For prune will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly forwarding purposes, the Prune-Pending state functions exactly
like the NoInfo state. like the NoInfo state.
PruneTmp (P') PruneTmp (P')
This state is a transient state which for forwarding purposes This state is a transient state which for forwarding purposes
behaves exactly like the Prune state. A (*,G) Join has been behaves exactly like the Prune state. A (*,G) Join has been
received (which may cancel the (S,G,rpt) Prune). As we parse received (which may cancel the (S,G,rpt) Prune). As we parse
the Join/Prune message from top to bottom, we first enter this the Join/Prune message from top to bottom, we first enter this
state if the message contains a (*,G) Join. Later in the state if the message contains a (*,G) Join. Later in the
message we will normally encounter an (S,G,rpt) prune to re- message we will normally encounter an (S,G,rpt) prune to
instate the Prune state. However if we reach the end of the reinstate the Prune state. However if we reach the end of the
message without encountering such a (S,G,rpt) prune, then we message without encountering such a (S,G,rpt) prune, then we
will revert to NoInfo state in this state machine. will revert to NoInfo state in this state machine.
As no time is spent in this state, no timers can expire. As no time is spent in this state, no timers can expire.
Prune-Pending-Tmp (PP') Prune-Pending-Tmp (PP')
This state is a transient state which is identical to P' This state is a transient state which is identical to P'
except that it is associated with the PP state rather than the except that it is associated with the PP state rather than the
P state. For forwarding purposes, PP' behaves exactly like PP P state. For forwarding purposes, PP' behaves exactly like PP
state. state.
skipping to change at page 57, line 7 skipping to change at page 57, line 7
Expiry of the Expiry Timer causes this state machine to revert Expiry of the Expiry Timer causes this state machine to revert
to NoInfo state. to NoInfo state.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(S,G,rpt) is received. This timer is set when a valid Prune(S,G,rpt) is received.
Expiry of the Prune-Pending Timer causes this state machine to Expiry of the Prune-Pending Timer causes this state machine to
move on to Prune state. move on to Prune state.
Figure 5: Downstream per-interface (S,G,rpt) state machine in tabular form Figure 5: Downstream per-interface (S,G,rpt) state machine in tabular form
r+----------++----------------------------------------------------------------+ +----------++----------------------------------------------------------------+
| || Event | | || Event |
| ++----------+-----------+-----------+---------+---------+---------+ | ++----------+-----------+-----------+---------+---------+---------+
|Prev ||Receive | Receive | Receive | End of | Prune- | Expiry | |Prev ||Receive | Receive | Receive | End of | Prune- | Expiry |
|State ||Join(*,G) | Join | Prune | Message | Pending | Timer | |State ||Join(*,G) | Join | Prune | Message | Pending | Timer |
| || | (S,G,rpt) | (S,G,rpt) | | Timer | Expires | | || | (S,G,rpt) | (S,G,rpt) | | Timer | Expires |
| || | | | | Expires | | | || | | | | Expires | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
| ||- | - | -> PP | - | - | - | | ||- | - | -> PP | - | - | - |
| || | | state | | | | | || | | state | | | |
| || | | start | | | | | || | | start | | | |
skipping to change at page 57, line 36 skipping to change at page 57, line 36
| ||state | state | state | | | state | | ||state | state | state | | | state |
|Prune (P) || | | restart | | | | |Prune (P) || | | restart | | | |
| || | | Expiry | | | | | || | | Expiry | | | |
| || | | Timer | | | | | || | | Timer | | | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
|Prune- ||-> PP' | -> NI | - | - | -> P | - | |Prune- ||-> PP' | -> NI | - | - | -> P | - |
|Pending ||state | state | | | state | | |Pending ||state | state | | | state | |
|(PP) || | | | | | | |(PP) || | | | | | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
| ||- | - | -> P | -> NI | - | - | | ||- | - | -> P | -> NI | - | - |
|Prune-Tmp || | | state | state | | | |PruneTmp || | | state | state | | |
|(P') || | | restart | | | | |(P') || | | restart | | | |
| || | | Expiry | | | | | || | | Expiry | | | |
| || | | Timer | | | | | || | | Timer | | | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
| ||- | - | -> PP | -> NI | - | - | | ||- | - | -> PP | -> NI | - | - |
|Prune- || | | state | state | | | |Prune- || | | state | state | | |
|Pending- || | | restart | | | | |Pending- || | | restart | | | |
|Tmp (PP') || | | Expiry | | | | |Tmp (PP') || | | Expiry | | | |
| || | | Timer | | | | | || | | Timer | | | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
The transition events "Receive Join(S,G,rpt)", "Receive Prune(S,G,rpt)", The transition events "Receive Join(S,G,rpt)", "Receive Prune(S,G,rpt)",
and "Receive Join(*,G)" imply receiving a Join or Prune targeted to this | and "Receive Join(*,G)" imply receiving a Join or Prune targeted to this
router's primary IP address on the received interface. If the router's primary IP address on the received interface. If the upstream
destination address is not correct, these state transitions in this neighbor address field is not correct, these state transitions in this
state machine must not occur, although seeing such a packet may cause state machine must not occur, although seeing such a packet may cause
state transitions in other state machines. state transitions in other state machines.
On unnumbered interfaces on point-to-point links, the router's address On unnumbered interfaces on point-to-point links, the router's address
should be the same as the source address it chose for the Hello message should be the same as the source address it chose for the Hello message
it sent over that interface. However on point-to-point links we also it sent over that interface. However on point-to-point links we also
recommend that PIM Join/Prune messages with a destination address of all recommend that PIM Join/Prune messages with a upstream neighbor address
zeros are also accepted. field of all zeros are also accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo (NI) state, the following event may trigger a transition: When in NoInfo (NI) state, the following event may trigger a transition:
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
A Prune(S,G,rpt) is received on interface I with its Upstream A Prune(S,G,rpt) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the Prune-Pending state. The Expiry Timer (ET) transitions to the Prune-Pending state. The Expiry Timer (ET)
is started, and set to the HoldTime from the triggering is started, and set to the HoldTime from the triggering
Join/Prune message. The Prune-Pending Timer is started; it is Join/Prune message. The Prune-Pending Timer is started; it is
set to the J/P_Override_Interval(I) if the router has more set to the J/P_Override_Interval(I) if the router has more
than one neighbor on that interface; otherwise it is set to than one neighbor on that interface; otherwise it is set to
zero causing it to expire immediately. zero causing it to expire immediately.
Transitions from Prune-Pending State Transitions from Prune-Pending State
When in Prune-Pending (PP) state, the following events may trigger a When in Prune-Pending (PP) state, the following events may trigger a
transition: transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream | A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to Prune-Pending-Tmp state whilst the remainder of transitions to Prune-Pending-Tmp state whilst the remainder of
the compound Join/Prune message containing the Join(*,G) is the compound Join/Prune message containing the Join(*,G) is
processed. processed.
Receive Join(S,G,rpt) Receive Join(S,G,rpt)
A Join(S,G,rpt) is received on interface I with its Upstream A Join(S,G,rpt) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to NoInfo state. ET and PPT are canceled. transitions to NoInfo state. ET and PPT are canceled.
Prune-Pending Timer Expires Prune-Pending Timer Expires
The Prune-Pending Timer for the (S,G,rpt) downstream state The Prune-Pending Timer for the (S,G,rpt) downstream state
machine on interface I expires. machine on interface I expires.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the Prune state. transitions to the Prune state.
Transitions from Prune State Transitions from Prune State
When in Prune (P) state, the following events may trigger a transition: When in Prune (P) state, the following events may trigger a transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to PruneTmp state whilst the remainder of the transitions to PruneTmp state whilst the remainder of the
compound Join/Prune message containing the Join(*,G) is compound Join/Prune message containing the Join(*,G) is
processed. processed.
Receive Join(S,G,rpt) Receive Join(S,G,rpt)
A Join(S,G,rpt) is received on interface I with its Upstream A Join(S,G,rpt) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to NoInfo state. ET and PPT are canceled. transitions to NoInfo state. ET and PPT are canceled.
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
A Prune(S,G,rpt) is received on interface I with its Upstream A Prune(S,G,rpt) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. | Neighbor Address set to the router's primary IP address on I.
The (S,G,rpt) downstream state machine on interface I remains The (S,G,rpt) downstream state machine on interface I remains
in Prune state. The Expiry Timer (ET) is restarted, set to in Prune state. The Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the maximum of its current value and the HoldTime from the
triggering Join/Prune message. triggering Join/Prune message.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (S,G,rpt) downstream state machine on The Expiry Timer for the (S,G,rpt) downstream state machine on
interface I expires. interface I expires.
skipping to change at page 62, line 12 skipping to change at page 62, line 12
sending of a Join(*,*,RP) to the upstream next hop towards the RP, sending of a Join(*,*,RP) to the upstream next hop towards the RP,
NBR(RPF_interface(RP), MRIB.next_hop(RP)). NBR(RPF_interface(RP), MRIB.next_hop(RP)).
Figure 6: Upstream (*,*,RP) state machine in tabular form Figure 6: Upstream (*,*,RP) state machine in tabular form
+--------------------++-------------------------------------------------+ +--------------------++-------------------------------------------------+
| || Event | | || Event |
| Prev State ++-------------------------+-----------------------+ | Prev State ++-------------------------+-----------------------+
| || JoinDesired | JoinDesired | | || JoinDesired | JoinDesired |
| || (*,*,RP) ->True | (*,*,RP) ->False | | || (*,*,RP) ->True | (*,*,RP) ->False |
|
+--------------------++-------------------------+-----------------------+ +--------------------++-------------------------+-----------------------+
| || -> J state | - | | || -> J state | - |
| NotJoined (NJ) || Send Join(*,*,RP); | | | NotJoined (NJ) || Send Join(*,*,RP); | |
| || Set Join Timer to | | | || Set Join Timer to | |
| || t_periodic | | | || t_periodic | |
|
+--------------------++-------------------------+-----------------------+ +--------------------++-------------------------+-----------------------+
| Joined (J) || - | -> NJ state | | Joined (J) || - | -> NJ state |
| || | Send Prune | | || | Send Prune |
| || | (*,*,RP); Cancel | | || | (*,*,RP); Cancel |
| || | Join Timer | | || | Join Timer |
|
+--------------------++-------------------------+-----------------------+ +--------------------++-------------------------+-----------------------+
In addition, we have the following transitions which occur within the In addition, we have the following transitions which occur within the
Joined state: Joined state:
i+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+-------------------+--------------------+------------------------------+ +-------------------+--------------------+------------------------------+
| Timer Expires | See | See | | Timer Expires | See | See |
| | Join(*,*,RP) | Prune(*,*,RP) | | | Join(*,*,RP) | Prune(*,*,RP) |
| | to MRIB. | to MRIB. | | | to MRIB. | to MRIB. |
| | next_hop(RP) | next_hop(RP) | | | next_hop(RP) | next_hop(RP) |
|
+-------------------+--------------------+------------------------------+ +-------------------+--------------------+------------------------------+
| Send | Increase Join | Decrease Join | | Send | Increase Join | Decrease Join |
| Join(*,*,RP); | Timer to | Timer to | | Join(*,*,RP); | Timer to | Timer to |
| Set Join Timer | t_joinsuppress | t_override | | Set Join Timer | t_joinsuppress | t_override |
| to t_periodic | | | | to t_periodic | | |
|
+-------------------+--------------------+------------------------------+ +-------------------+--------------------+------------------------------+
T+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+-----------------------------------+-----------------------------------+ +-----------------------------------+-----------------------------------+
| NBR(RPF_interface(RP), | MRIB.next_hop(RP) GenID | | NBR(RPF_interface(RP), | MRIB.next_hop(RP) GenID |
| MRIB.next_hop(RP)) | changes | | MRIB.next_hop(RP)) | changes |
| changes | | | changes | |
|
+-----------------------------------+-----------------------------------+ +-----------------------------------+-----------------------------------+
| Send Join(*,*,RP) to new | Decrease Join Timer to | | Send Join(*,*,RP) to new | Decrease Join Timer to |
| next hop; Send | t_override | | next hop; Send | t_override |
| Prune(*,*,RP) to old | | | Prune(*,*,RP) to old | |
| next hop; set Join Timer | | | next hop; set Join Timer | |
| to t_periodic | | | to t_periodic | |
|
+-----------------------------------+-----------------------------------+ +-----------------------------------+-----------------------------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(*,*,RP) { bool JoinDesired(*,*,RP) {
if immediate_olist(*,*,RP) != NULL if immediate_olist(*,*,RP) != NULL
return TRUE return TRUE
else else
return FALSE return FALSE
} }
skipping to change at page 64, line 26 skipping to change at page 64, line 26
The Join Timer (JT) expires, indicating time to send a The Join Timer (JT) expires, indicating time to send a
Join(*,*,RP) Join(*,*,RP)
Send Join(*,*,RP) to the appropriate upstream neighbor, which Send Join(*,*,RP) to the appropriate upstream neighbor, which
is NBR(RPF_interface(RP), MRIB.next_hop(RP)). Restart the is NBR(RPF_interface(RP), MRIB.next_hop(RP)). Restart the
Join Timer (JT) to expire after t_periodic seconds. Join Timer (JT) to expire after t_periodic seconds.
See Join(*,*,RP) to MRIB.next_hop(RP) See Join(*,*,RP) to MRIB.next_hop(RP)
This event is only relevant if RPF_interface(RP) is a shared This event is only relevant if RPF_interface(RP) is a shared
medium. This router sees another router on RPF_interface(RP) medium. This router sees another router on RPF_interface(RP)
send a Join(*,*,RP) to NBR(RPF_interface(RP), | send a Join(*,*,RP) to NBR(RPF_interface(RP),
MRIB.next_hop(RP)). This causes this router to suppress its MRIB.next_hop(RP)). This causes this router to suppress its
own Join. own Join.
The upstream (*,*,RP) state machine remains in Joined state. The upstream (*,*,RP) state machine remains in Joined state.
Let t_joinsuppress be the minimum of t_suppressed and the Let t_joinsuppress be the minimum of t_suppressed and the
HoldTime from the Join/Prune message triggering this event. HoldTime from the Join/Prune message triggering this event.
If the Join Timer is set to expire in less than t_joinsuppress If the Join Timer is set to expire in less than t_joinsuppress
seconds, reset it so that it expires after t_joinsuppress seconds, reset it so that it expires after t_joinsuppress
seconds. If the Join Timer is set to expire in more than seconds. If the Join Timer is set to expire in more than
t_joinsuppress seconds, leave it unchanged. t_joinsuppress seconds, leave it unchanged.
See Prune(*,*,RP) to MRIB.next_hop(RP) See Prune(*,*,RP) to MRIB.next_hop(RP)
This event is only relevant if RPF_interface(RP) is a shared This event is only relevant if RPF_interface(RP) is a shared
medium. This router sees another router on RPF_interface(RP) medium. This router sees another router on RPF_interface(RP)
send a Prune(*,*,RP) to NBR(RPF_interface(RP), | send a Prune(*,*,RP) to NBR(RPF_interface(RP),
MRIB.next_hop(RP)). As this router is in Joined state, it MRIB.next_hop(RP)). As this router is in Joined state, it
must override the Prune after a short random interval. must override the Prune after a short random interval.
The upstream (*,*,RP) state machine remains in Joined state. The upstream (*,*,RP) state machine remains in Joined state.
If the Join Timer is set to expire in more than t_override If the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. seconds, reset it so that it expires after t_override seconds.
If the Join Timer is set to expire in less than t_override If the Join Timer is set to expire in less than t_override
seconds, leave it unchanged. seconds, leave it unchanged.
NBR(RPF_interface(RP), MRIB.next_hop(RP)) changes NBR(RPF_interface(RP), MRIB.next_hop(RP)) changes
skipping to change at page 67, line 12 skipping to change at page 67, line 12
sending of a Join(*,G) to the upstream next hop towards the RP, sending of a Join(*,G) to the upstream next hop towards the RP,
RPF'(*,G). RPF'(*,G).
Figure 7: Upstream (*,G) state machine in tabular form Figure 7: Upstream (*,G) state machine in tabular form
+--------------------++-------------------------------------------------+ +--------------------++-------------------------------------------------+
| || Event | | || Event |
| Prev State ++------------------------+------------------------+ | Prev State ++------------------------+------------------------+
| || JoinDesired(*,G) | JoinDesired(*,G) | | || JoinDesired(*,G) | JoinDesired(*,G) |
| || ->True | ->False | | || ->True | ->False |
|
+--------------------++------------------------+------------------------+ +--------------------++------------------------+------------------------+
| || -> J state | - | | || -> J state | - |
| NotJoined (NJ) || Send Join(*,G); | | | NotJoined (NJ) || Send Join(*,G); | |
| || Set Join Timer to | | | || Set Join Timer to | |
| || t_periodic | | | || t_periodic | |
|
+--------------------++------------------------+------------------------+ +--------------------++------------------------+------------------------+
| Joined (J) || - | -> NJ state | | Joined (J) || - | -> NJ state |
| || | Send Prune(*,G); | | || | Send Prune(*,G); |
| || | Cancel Join Timer | | || | Cancel Join Timer |
|
+--------------------++------------------------+------------------------+ +--------------------++------------------------+------------------------+
In addition, we have the following transitions which occur within the In addition, we have the following transitions which occur within the
Joined state: Joined state:
i+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) | |Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) |
| | to RPF'(*,G) | to RPF'(*,G) | changes due to | | | to RPF'(*,G) | to RPF'(*,G) | changes due to |
| | | | an Assert | | | | | an Assert |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
|Send | Increase Join | Decrease Join | Decrease Join | |Send | Increase Join | Decrease Join | Decrease Join |
|Join(*,G); Set | Timer to | Timer to | Timer to | |Join(*,G); Set | Timer to | Timer to | Timer to |
|Join Timer to | t_joinsuppress | t_override | t_override | |Join Timer to | t_joinsuppress | t_override | t_override |
|t_periodic | | | | |t_periodic | | | |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
-+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+----------------------------------+------------------------------------+ +----------------------------------+------------------------------------+
| RPF'(*,G) changes not | RPF'(*,G) GenID changes | | RPF'(*,G) changes not | RPF'(*,G) GenID changes |
| due to an Assert | | | due to an Assert | |
|
+----------------------------------+------------------------------------+ +----------------------------------+------------------------------------+
| Send Join(*,G) to new | Decrease Join Timer to | | Send Join(*,G) to new | Decrease Join Timer to |
| next hop; Send | t_override | | next hop; Send | t_override |
| Prune(*,G) to old next | | | Prune(*,G) to old next | |
| hop; Set Join Timer to | | | hop; Set Join Timer to | |
| t_periodic | | | t_periodic | |
|
+----------------------------------+------------------------------------+ +----------------------------------+------------------------------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(*,G) { bool JoinDesired(*,G) {
if (immediate_olist(*,G) != NULL OR if (immediate_olist(*,G) != NULL OR
(JoinDesired(*,*,RP(G)) AND (JoinDesired(*,*,RP(G)) AND
AssertWinner(*, G, RPF_interface(RP(G))) != NULL)) AssertWinner(*, G, RPF_interface(RP(G))) != NULL))
return TRUE return TRUE
else else
skipping to change at page 70, line 10 skipping to change at page 70, line 10
RPF'(*,G) changes not due to an Assert RPF'(*,G) changes not due to an Assert
An event occurred which caused the next hop towards the RP for An event occurred which caused the next hop towards the RP for
G to change. This may be caused by a change in the MRIB G to change. This may be caused by a change in the MRIB
routing database or the group-to-RP mapping. Note that this routing database or the group-to-RP mapping. Note that this
transition does not occur if an Assert is active and the transition does not occur if an Assert is active and the
upstream interface does not change. upstream interface does not change.
The upstream (*,G) state machine remains in Joined state. The upstream (*,G) state machine remains in Joined state.
Send Join(*,G) to the new upstream neighbor which is the new Send Join(*,G) to the new upstream neighbor which is the new
value of RPF'(*,G). Send Prune(*,G) to the old upstream value of RPF'(*,G). Send Prune(*,G) to the old upstream
neighbor, which is the old value of RPF'(*,G). Set the Join neighbor, which is the old value of RPF'(*,G). Use the new
Timer (JT) to expire after t_periodic seconds. value of RP(G) in the Prune(*,G) message or all-zeros if RP(G)
becomes unknown (old value of RP(G) may be used instead to
improve behavior in routers implementing older versions of
this spec). Set the Join Timer (JT) to expire after
t_periodic seconds.
RPF'(*,G) GenID changes RPF'(*,G) GenID changes
The Generation ID of the router that is RPF'(*,G) changes. The Generation ID of the router that is RPF'(*,G) changes.
This normally means that this neighbor has lost state, and so This normally means that this neighbor has lost state, and so
the state must be refreshed. the state must be refreshed.
The upstream (*,G) state machine remains in Joined state. If The upstream (*,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. seconds, reset it so that it expires after t_override seconds.
skipping to change at page 71, line 25 skipping to change at page 71, line 27
In addition, one timer JT(S,G) is kept which is used to trigger the In addition, one timer JT(S,G) is kept which is used to trigger the
sending of a Join(S,G) to the upstream next hop towards S, RPF'(S,G). sending of a Join(S,G) to the upstream next hop towards S, RPF'(S,G).
Figure 8: Upstream (S,G) state machine in tabular form Figure 8: Upstream (S,G) state machine in tabular form
+--------------------+--------------------------------------------------+ +--------------------+--------------------------------------------------+
| | Event | | | Event |
| Prev State +-------------------------+------------------------+ | Prev State +-------------------------+------------------------+
| | JoinDesired(S,G) | JoinDesired(S,G) | | | JoinDesired(S,G) | JoinDesired(S,G) |
| | ->True | ->False | | | ->True | ->False |
|
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
| NotJoined (NJ) | -> J state | - | | NotJoined (NJ) | -> J state | - |
| | Send Join(S,G); | | | | Send Join(S,G); | |
| | Set Join Timer to | | | | Set Join Timer to | |
| | t_periodic | | | | t_periodic | |
|
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
| Joined (J) | - | -> NJ state | | Joined (J) | - | -> NJ state |
| | | Send Prune(S,G); | | | | Send Prune(S,G); |
| | | Set SPTbit(S,G) to | | | | Set SPTbit(S,G) to |
| | | FALSE; Cancel Join | | | | FALSE; Cancel Join |
| | | Timer | | | | Timer |
|
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
In addition, we have the following transitions which occur within the In addition, we have the following transitions which occur within the
Joined state: Joined state:
i+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
| Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune | | Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune |
| | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to | | | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to |
| | | | RPF'(S,G) | | | | | RPF'(S,G) |
|
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
| Send | Increase Join | Decrease Join | Decrease Join | | Send | Increase Join | Decrease Join | Decrease Join |
| Join(S,G); Set | Timer to | Timer to | Timer to | | Join(S,G); Set | Timer to | Timer to | Timer to |
| Join Timer to | t_joinsuppress | t_override | t_override | | Join Timer to | t_joinsuppress | t_override | t_override |
| t_periodic | | | | | t_periodic | | | |
|
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
-+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
| See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) | | See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) |
| to RPF'(S,G) | changes not | GenID changes | changes due to | | to RPF'(S,G) | changes not | GenID changes | changes due to |
| | due to an | | an Assert | | | due to an | | an Assert |
| | Assert | | | | | Assert | | |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
| Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join | | Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join |
| Timer to | to new next | Timer to | Timer to | | Timer to | to new next | Timer to | Timer to |
| t_override | hop; Send | t_override | t_override | | t_override | hop; Send | t_override | t_override |
| | Prune(S,G) to | | | | | Prune(S,G) to | | |
| | old next hop; | | | | | old next hop; | | |
| | Set Join Timer | | | | | Set Join Timer | | |
| | to t_periodic | | | | | to t_periodic | | |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(S,G) { bool JoinDesired(S,G) {
return( immediate_olist(S,G) != NULL return( immediate_olist(S,G) != NULL
OR ( KeepaliveTimer(S,G) is running OR ( KeepaliveTimer(S,G) is running
AND inherited_olist(S,G) != NULL ) ) AND inherited_olist(S,G) != NULL ) )
} }
skipping to change at page 77, line 15 skipping to change at page 77, line 15
Figure 9: Upstream (S,G,rpt) state machine for triggered messages in Figure 9: Upstream (S,G,rpt) state machine for triggered messages in
tabular form tabular form
+---------------++-------------------------------------------------------------+ +---------------++-------------------------------------------------------------+
| || Event | | || Event |
| ++---------------+---------------+--------------+--------------+ | ++---------------+---------------+--------------+--------------+
|Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ | |Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ |
| || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist | | || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist |
| || ->True | ->False | ->False | (S,G,rpt) | | || ->True | ->False | ->False | (S,G,rpt) |
| || | | | ->non-NULL | | || | | | ->non-NULL |
->n+---------------++---------------+---------------+--------------+--------------+ +---------------++---------------+---------------+--------------+--------------+
|RPTNotJoined || -> P state | - | - | -> NP state | |RPTNotJoined || -> P state | - | - | -> NP state |
|(G) (NJ) || | | | | |(G) (NJ) || | | | |
+---------------++---------------+---------------+--------------+--------------+ +---------------++---------------+---------------+--------------+--------------+
|Pruned || - | -> NP state | -> NJ state | - | |Pruned || - | -> NP state | -> NJ state | - |
|(S,G,rpt) (P) || | Send Join | | | |(S,G,rpt) (P) || | Send Join | | |
| || | (S,G,rpt) | | | | || | (S,G,rpt) | | |
+---------------++---------------+---------------+--------------+--------------+ +---------------++---------------+---------------+--------------+--------------+
|NotPruned || -> P state | - | -> NJ state | - | |NotPruned || -> P state | - | -> NJ state | - |
|(S,G,rpt) || Send Prune | | Cancel OT | | |(S,G,rpt) || Send Prune | | Cancel OT | |
|(NP) || (S,G,rpt); | | | | |(NP) || (S,G,rpt); | | | |
| || Cancel OT | | | | | || Cancel OT | | | |
+---------------++---------------+---------------+--------------+--------------+ +---------------++---------------+---------------+--------------+--------------+
Additionally, we have the following transitions within the Additionally, we have the following transitions within the
NotPruned(S,G,rpt) state which are all used for prune override behavior. NotPruned(S,G,rpt) state which are all used for prune override behavior.
t+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In NotPruned(S,G,rpt) State | | In NotPruned(S,G,rpt) State |
|
+-----------+--------------+--------------+--------------+--------------+ +-----------+--------------+--------------+--------------+--------------+
|Override | See Prune | See Join | See Prune | RPF' | |Override | See Prune | See Join | See Prune | RPF' |
|Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> | |Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> |
|expires | RPF' | RPF' | RPF' | RPF' (*,G) | |expires | RPF' | RPF' | RPF' | RPF' (*,G) |
| | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | | | | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | |
|
+-----------+--------------+--------------+--------------+--------------+ +-----------+--------------+--------------+--------------+--------------+
|Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, | |Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, |
|(S,G,rpt); | t_override) | | t_override) | t_override) | |(S,G,rpt); | t_override) | | t_override) | t_override) |
|Leave OT | | | | | |Leave OT | | | | |
|unset | | | | | |unset | | | | |
|
+-----------+--------------+--------------+--------------+--------------+ +-----------+--------------+--------------+--------------+--------------+
Note that the min function in the above state machine considers a non- Note that the min function in the above state machine considers a non-
running timer to have an infinite value (e.g. min(not-running, running timer to have an infinite value (e.g. min(not-running,
t_override) = t_override). t_override) = t_override).
This state machine uses the following macros: This state machine uses the following macros:
bool RPTJoinDesired(G) { bool RPTJoinDesired(G) {
return (JoinDesired(*,G) OR JoinDesired(*,*,RP(G))) return (JoinDesired(*,G) OR JoinDesired(*,*,RP(G)))
skipping to change at page 83, line 13 skipping to change at page 83, line 13
membership requests that specifically refer to S (and G). membership requests that specifically refer to S (and G).
I am Assert Loser (L) I am Assert Loser (L)
This router has lost an (S,G) assert on interface I. It must not This router has lost an (S,G) assert on interface I. It must not
forward packets from S destined for G onto interface I. If it is forward packets from S destined for G onto interface I. If it is
the DR on I, it is no longer responsible for forwarding traffic the DR on I, it is no longer responsible for forwarding traffic
onto I to satisfy local hosts with membership requests that onto I to satisfy local hosts with membership requests that
specifically refer to S and G. specifically refer to S and G.
In addition, there is also an Assert Timer (AT) that is used to time out In addition, there is also an Assert Timer (AT) that is used to time out
asserts on the assert losers and to resend asserts on the assert winner. asserts on the assert losers and to re-send asserts on the assert
winner.
Figure 10: Per-interface (S,G) Assert State machine in tabular form Figure 10: Per-interface (S,G) Assert State machine in tabular form
F+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In NoInfo (NI) State | | In NoInfo (NI) State |
|
+---------------+-------------------+------------------+----------------+ +---------------+-------------------+------------------+----------------+
| Receive | Receive Assert | Data arrives | Receive | | Receive | Receive Assert | Data arrives | Receive |
| Inferior | with RPTbit | from S to G on | Acceptable | | Inferior | with RPTbit | from S to G on | Acceptable |
| Assert with | set and | I and | Assert with | | Assert with | set and | I and | Assert with |
| RPTbit clear | CouldAssert | CouldAssert | RPTbit clear | | RPTbit clear | CouldAssert | CouldAssert | RPTbit clear |
| and | (S,G,I) | (S,G,I) | and AssTrDes | | and | (S,G,I) | (S,G,I) | and AssTrDes |
| CouldAssert | | | (S,G,I) | | CouldAssert | | | (S,G,I) |
| (S,G,I) | | | | | (S,G,I) | | | |
|
+---------------+-------------------+------------------+----------------+ +---------------+-------------------+------------------+----------------+
| -> W state | -> W state | -> W state | -> L state | | -> W state | -> W state | -> W state | -> L state |
| [Actions A1] | [Actions A1] | [Actions A1] | [Actions A6] | | [Actions A1] | [Actions A1] | [Actions A1] | [Actions A6] |
|
+---------------+-------------------+------------------+----------------+ +---------------+-------------------+------------------+----------------+
-+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In I Am Assert Winner (W) State | | In I Am Assert Winner (W) State |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
| Assert Timer | Receive | Receive | CouldAssert | | Assert Timer | Receive | Receive | CouldAssert |
| Expires | Inferior | Preferred | (S,G,I) -> | | Expires | Inferior | Preferred | (S,G,I) -> |
| | Assert | Assert | FALSE | | | Assert | Assert | FALSE |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
| -> W state | -> W state | -> L state | -> NI state | | -> W state | -> W state | -> L state | -> NI state |
| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] | | [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
-+---------------------------------------------------------------------------+ +-------------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
+-------------+----------------+--------------+--------------+--------------+ +-------------+--------------+--------------+--------------+--------------+
|Receive | Receive | | Receive | Assert Timer | Current | |Receive | Receive | Receive | Assert Timer | Current |
|Preferred | Acceptable | | Inferior | Expires | Winner's | |Preferred | Acceptable | Inferior | Expires | Winner's |
|Assert | Assert with | | Assert from | | GenID | |Assert | Assert with | Assert or | | GenID |
| | RPTbit clear | | Current | | Changes or | | | RPTbit clear | Assert | | Changes or |
| | from Current | | Winner | | NLT Expires | | | from Current | Cancel from | | NLT Expires |
| | Winner | | | | | | Winner | Current | | |
+-------------+----------------+--------------+--------------+--------------+ | | | Winner | | |
+-------------+--------------+--------------+--------------+--------------+
|-> L state | -> L state | -> NI state | -> NI state | -> NI state | |-> L state | -> L state | -> NI state | -> NI state | -> NI state |
|[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] | |[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] |
A5]+-------------+----------------+--------------+--------------+--------------+ +-------------+--------------+--------------+--------------+--------------+
T+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
|
+----------------+-----------------+-------------------+----------------+ +----------------+-----------------+-------------------+----------------+
| AssTrDes | my_metric -> | RPF_interface | Receive | | AssTrDes | my_metric -> | RPF_interface | Receive |
| (S,G,I) -> | better than | (S) stops | Join(S,G) on | | (S,G,I) -> | better than | (S) stops | Join(S,G) on |
| FALSE | winner's | being I | interface I | | FALSE | winner's | being I | interface I |
| | metric | | | | | metric | | |
|
+----------------+-----------------+-------------------+----------------+ +----------------+-----------------+-------------------+----------------+
| -> NI state | -> NI state | -> NI state | -> NI State | | -> NI state | -> NI state | -> NI state | -> NI State |
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
|
+----------------+-----------------+-------------------+----------------+ +----------------+-----------------+-------------------+----------------+
Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in the Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in the
state machine table to refer to AssertTrackingDesired(S,G,I). state machine table to refer to AssertTrackingDesired(S,G,I).
Terminology: Terminology:
A "preferred assert" is one with a better metric than the current A "preferred assert" is one with a better metric than the current
winner. winner.
An "acceptable assert" is one that has a better metric than An "acceptable assert" is one that has a better metric than
my_assert_metric(S,G,I). my_assert_metric(S,G,I). An assert is never considered acceptable
if its metric is infinite.
An "inferior assert" is one with a worse metric than An "inferior assert" is one with a worse metric than
my_assert_metric(S,G,I). my_assert_metric(S,G,I). An assert is never considered inferior if
my_assert_metric(S,G,I) is infinite.
The state machine uses the following macros: The state machine uses the following macros:
CouldAssert(S,G,I) = CouldAssert(S,G,I) =
SPTbit(S,G)==TRUE SPTbit(S,G)==TRUE
AND (RPF_interface(S) != I) AND (RPF_interface(S) != I)
AND (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) AND (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G) (-) lost_assert(*,G)
(+) joins(S,G) (+) pim_include(S,G) ) ) (+) joins(S,G) (+) pim_include(S,G) ) )
skipping to change at page 88, line 35 skipping to change at page 88, line 35
We receive an assert that is better than that of the current We receive an assert that is better than that of the current
assert winner. We stay in Loser state, and perform actions A2 assert winner. We stay in Loser state, and perform actions A2
below. below.
Receive Acceptable Assert with RPTbit clear from Current Winner Receive Acceptable Assert with RPTbit clear from Current Winner
We receive an assert from the current assert winner that is We receive an assert from the current assert winner that is
better than our own metric for this (S,G) (although the metric better than our own metric for this (S,G) (although the metric
may be worse than the winner's previous metric). We stay in may be worse than the winner's previous metric). We stay in
Loser state, and perform actions A2 below. Loser state, and perform actions A2 below.
Receive Inferior Assert from Current Winner Receive Inferior Assert or Assert Cancel from Current Winner
We receive an assert from the current assert winner that is We receive an assert from the current assert winner that is
worse than our own metric for this group (typically the worse than our own metric for this group (typically the
winner's metric became worse). We transition to NoInfo state, winner's metric became worse or because it is an assert
deleting the (S,G) assert information and allowing the normal cancel). We transition to NoInfo state, deleting the (S,G)
PIM Join/Prune mechanisms to operate. Usually we will assert information and allowing the normal PIM Join/Prune
eventually re-assert and win when data packets from S have mechanisms to operate. Usually we will eventually re-assert
started flowing again. and win when data packets from S have started flowing again.
Assert Timer Expires Assert Timer Expires
The (S,G) Assert Timer expires. We transition to NoInfo The (S,G) Assert Timer expires. We transition to NoInfo
state, deleting the (S,G) assert information (action A5 state, deleting the (S,G) assert information (action A5
below). below).
Current Winner's GenID Changes or NLT Expires Current Winner's GenID Changes or NLT Expires
The Neighbor Liveness Timer associated with the current winner The Neighbor Liveness Timer associated with the current winner
expires or we receive a Hello message from the current winner expires or we receive a Hello message from the current winner
reporting a different GenID from the one it previously reporting a different GenID from the one it previously
skipping to change at page 89, line 35 skipping to change at page 89, line 35
mechanisms to operate. Usually we will eventually re-assert mechanisms to operate. Usually we will eventually re-assert
and win when data packets from S have started flowing again. and win when data packets from S have started flowing again.
RPF_interface(S) stops being interface I RPF_interface(S) stops being interface I
Interface I used to be the RPF interface for S, and now it is Interface I used to be the RPF interface for S, and now it is
not. We transition to NoInfo state, deleting this (S,G) not. We transition to NoInfo state, deleting this (S,G)
assert state (action A5 below). assert state (action A5 below).
Receive Join(S,G) on Interface I Receive Join(S,G) on Interface I
We receive a Join(S,G) that has the Upstream Neighbor Address We receive a Join(S,G) that has the Upstream Neighbor Address
field set to my primary IP address on interface I. The action | field set to my primary IP address on interface I. The action
is to transition to NoInfo state, and delete this (S,G) assert is to transition to NoInfo state, and delete this (S,G) assert
state (action A5 below), and allow the normal PIM Join/Prune state (action A5 below), and allow the normal PIM Join/Prune
mechanisms to operate. If whoever sent the Join was in error, mechanisms to operate. If whoever sent the Join was in error,
then the normal assert mechanism will eventually re-apply and then the normal assert mechanism will eventually re-apply and
we will lose the assert again. However whoever sent the we will lose the assert again. However whoever sent the
assert may know that the previous assert winner has died, and assert may know that the previous assert winner has died, and
so we may end up being the new forwarder. so we may end up being the new forwarder.
(S,G) Assert State machine Actions (S,G) Assert State machine Actions
skipping to change at page 91, line 6 skipping to change at page 91, line 6
local hosts on I. local hosts on I.
I am Assert Loser (L) I am Assert Loser (L)
This router has lost an (*,G) assert on interface I. It must not This router has lost an (*,G) assert on interface I. It must not
forward packets for G onto interface I with the exception of forward packets for G onto interface I with the exception of
traffic from sources for which is has (S,G) "I am Assert Winner" traffic from sources for which is has (S,G) "I am Assert Winner"
state. If it is the DR, it is no longer responsible for handling state. If it is the DR, it is no longer responsible for handling
the membership requests for group G from local hosts on I. the membership requests for group G from local hosts on I.
In addition, there is also an Assert Timer (AT) that is used to time out In addition, there is also an Assert Timer (AT) that is used to time out
asserts on the assert losers and to resend asserts on the assert winner. asserts on the assert losers and to re-send asserts on the assert
winner.
When an Assert message is received with a source address other than When an Assert message is received with a source address other than
zero, a PIM implementation must first match it against the possible zero, a PIM implementation must first match it against the possible
events in the (S,G) assert state machine and process any transitions and events in the (S,G) assert state machine and process any transitions and
actions, before considering whether the Assert message matches against actions, before considering whether the Assert message matches against
the (*,G) assert state machine. the (*,G) assert state machine.
It is important to note that NO TRANSITION CAN OCCUR in the (*,G) state It is important to note that NO TRANSITION CAN OCCUR in the (*,G) state
machine as a result of receiving an Assert message unless the (S,G) machine as a result of receiving an Assert message unless the (S,G)
assert state machine for the relevant S and G is in the "NoInfo" state assert state machine for the relevant S and G is in the "NoInfo" state
skipping to change at page 92, line 7 skipping to change at page 92, line 7
Another example: if the (S,G) assert state machine is in "L" state when Another example: if the (S,G) assert state machine is in "L" state when
an assert message is received, and the assert metric in the message is an assert message is received, and the assert metric in the message is
worse than my_assert_metric(S,G,I), then the (S,G) assert state machine worse than my_assert_metric(S,G,I), then the (S,G) assert state machine
will transition to NoInfo state. In such a case if the (*,G) assert will transition to NoInfo state. In such a case if the (*,G) assert
state machine were in NoInfo state, it might appear that it would state machine were in NoInfo state, it might appear that it would
transition to "W" state, but this is not the case because this message transition to "W" state, but this is not the case because this message
already triggered a transition in the (S,G) assert state machine. already triggered a transition in the (S,G) assert state machine.
Figure 11: Per-interface (*,G) Assert State machine in tabular form Figure 11: Per-interface (*,G) Assert State machine in tabular form
F+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In NoInfo (NI) State | | In NoInfo (NI) State |
|
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+
| Receive Inferior | Data arrives for G | Receive Acceptable | | Receive Inferior | Data arrives for G | Receive Acceptable |
| Assert with RPTbit | on I and | Assert with RPTbit | | Assert with RPTbit | on I and | Assert with RPTbit |
| set and | CouldAssert | set and AssTrDes | | set and | CouldAssert | set and AssTrDes |
| CouldAssert(*,G,I) | (*,G,I) | (*,G,I) | | CouldAssert(*,G,I) | (*,G,I) | (*,G,I) |
|
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+
| -> W state | -> W state | -> L state | | -> W state | -> W state | -> L state |
| [Actions A1] | [Actions A1] | [Actions A2] | | [Actions A1] | [Actions A1] | [Actions A2] |
|
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+
-+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In I Am Assert Winner (W) State | | In I Am Assert Winner (W) State |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
| Assert Timer | Receive | Receive | CouldAssert | | Assert Timer | Receive | Receive | CouldAssert |
| Expires | Inferior | Preferred | (*,G,I) -> | | Expires | Inferior | Preferred | (*,G,I) -> |
| | Assert | Assert | FALSE | | | Assert | Assert | FALSE |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
| -> W state | -> W state | -> L state | -> NI state | | -> W state | -> W state | -> L state | -> NI state |
| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] | | [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
-+-------------------------------------------------------------------------+ +-------------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
|+-------------+--------------+--------------+--------------+--------------+ +-------------+--------------+--------------+--------------+--------------+
|Receive | Receive | Receive | Assert Timer | Current | |Receive | Receive | Receive | Assert Timer | Current |
|Preferred | Acceptable | Inferior | Expires | Winner's | |Preferred | Acceptable | Inferior | Expires | Winner's |
|Assert | Assert from | Assert from | | GenID | |Assert with | Assert from | Assert or | | GenID |
| | Current | Current | | Changes or | |RPTbit set | Current | Assert | | Changes or |
| | Winner | Winner | | NLT Expires | | | Winner with | Cancel from | | NLT Expires |
|+-------------+--------------+--------------+--------------+--------------+ | | RPTbit set | Current | | |
| | | Winner | | |
+-------------+--------------+--------------+--------------+--------------+
|-> L state | -> L state | -> NI state | -> NI state | -> NI state | |-> L state | -> L state | -> NI state | -> NI state | -> NI state |
|[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] | |[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] |
A5]+-------------+--------------+--------------+--------------+--------------+ +-------------+--------------+--------------+--------------+--------------+
T+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
|
+----------------+----------------+------------------+------------------+ +----------------+----------------+------------------+------------------+
| AssTrDes | my_metric -> | RPF_interface | Receive | | AssTrDes | my_metric -> | RPF_interface | Receive |
| (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) or | | (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) or |
| FALSE | Winner's | being I | Join | | FALSE | Winner's | being I | Join |
| | metric | | (*,*,RP(G)) on | | | metric | | (*,*,RP(G)) on |
| | | | Interface I | | | | | Interface I |
|
+----------------+----------------+------------------+------------------+ +----------------+----------------+------------------+------------------+
| -> NI state | -> NI state | -> NI state | -> NI State | | -> NI state | -> NI state | -> NI state | -> NI State |
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
|
+----------------+----------------+------------------+------------------+ +----------------+----------------+------------------+------------------+
The state machine uses the following macros: The state machine uses the following macros:
CouldAssert(*,G,I) = CouldAssert(*,G,I) =
( I in ( joins(*,*,RP(G)) (+) joins(*,G) ( I in ( joins(*,*,RP(G)) (+) joins(*,G)
(+) pim_include(*,G)) ) (+) pim_include(*,G)) )
AND (RPF_interface(RP(G)) != I) AND (RPF_interface(RP(G)) != I)
CouldAssert(*,G,I) is true on downstream interfaces for which we have CouldAssert(*,G,I) is true on downstream interfaces for which we have
skipping to change at page 93, line 49 skipping to change at page 93, line 46
assert might affect our behavior. assert might affect our behavior.
Note that for reasons of compactness, "AssTrDes(*,G,I)" is used in the Note that for reasons of compactness, "AssTrDes(*,G,I)" is used in the
state machine table to refer to AssertTrackingDesired(*,G,I). state machine table to refer to AssertTrackingDesired(*,G,I).
Terminology: Terminology:
A "preferred assert" is one with a better metric than the current A "preferred assert" is one with a better metric than the current
winner. winner.
An "acceptable assert" is one that has a better metric than An "acceptable assert" is one that has a better metric than
my_assert_metric(S,G,I). my_assert_metric(*,G,I). An assert is never considered acceptable
if its metric is infinite.
An "inferior assert" is one with a worse metric than An "inferior assert" is one with a worse metric than
my_assert_metric(S,G,I). my_assert_metric(*,G,I). An assert is never considered inferior if
my_assert_metric(*,G,I) is infinite.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following events trigger transitions, but only When in NoInfo state, the following events trigger transitions, but only
if the (S,G) assert state machine is in NoInfo state before and after if the (S,G) assert state machine is in NoInfo state before and after
consideration of the received message: consideration of the received message:
Receive Inferior Assert with RPTbit set AND Receive Inferior Assert with RPTbit set AND
CouldAssert(*,G,I)==TRUE CouldAssert(*,G,I)==TRUE
An Inferior (*,G) assert is received for G on Interface I. If An Inferior (*,G) assert is received for G on Interface I. If
skipping to change at page 95, line 28 skipping to change at page 95, line 28
make CouldAssert(*,G,I) become false. We can no longer make CouldAssert(*,G,I) become false. We can no longer
perform the actions of the assert winner, and so we transition perform the actions of the assert winner, and so we transition
to NoInfo state and perform actions A4 (below). to NoInfo state and perform actions A4 (below).
Transitions from "I am Assert Loser" State Transitions from "I am Assert Loser" State
When in "I am Assert Loser" state, the following events trigger When in "I am Assert Loser" state, the following events trigger
transitions, but only if the (S,G) assert state machine is in NoInfo transitions, but only if the (S,G) assert state machine is in NoInfo
state before and after consideration of the received message: state before and after consideration of the received message:
Receive Preferred Assert Receive Preferred Assert with RPTbit set
We receive a (*,G) assert that is better than that of the We receive a (*,G) assert that is better than that of the
current assert winner. We stay in Loser state, and perform current assert winner. We stay in Loser state, and perform
actions A2 below. actions A2 below.
Receive Acceptable Assert from Current Winner Receive Acceptable Assert from Current Winner with RPTbit set
We receive a (*,G) assert from the current assert winner that We receive a (*,G) assert from the current assert winner that
is better than our own metric for this group (although the is better than our own metric for this group (although the
metric may be worse than the winner's previous metric). We metric may be worse than the winner's previous metric). We
stay in Loser state, and perform actions A2 below. stay in Loser state, and perform actions A2 below.
Receive Inferior Assert from Current Winner Receive Inferior Assert or Assert Cancel from Current Winner
We receive an assert from the current assert winner that is We receive an assert from the current assert winner that is
worse than our own metric for this group (typically because worse than our own metric for this group (typically because
the winner's metric became worse). We transition to NoInfo the winner's metric became worse or is now an assert cancel).
state, delete this (*,G) assert state (action A5), and allow We transition to NoInfo state, delete this (*,G) assert state
the normal PIM Join/Prune mechanisms to operate. Usually we (action A5), and allow the normal PIM Join/Prune mechanisms to
will eventually re-assert and win when data packets for G have operate. Usually we will eventually re-assert and win when
started flowing again. data packets for G have started flowing again.
When in "I am Assert Loser" state, the following events trigger When in "I am Assert Loser" state, the following events trigger
transitions: transitions:
Assert Timer Expires Assert Timer Expires
The (*,G) Assert Timer expires. We transition to NoInfo state The (*,G) Assert Timer expires. We transition to NoInfo state
and delete this (*,G) assert info (action A5). and delete this (*,G) assert info (action A5).
Current Winner's GenID Changes or NLT Expires Current Winner's GenID Changes or NLT Expires
The Neighbor Liveness Timer associated with the current winner The Neighbor Liveness Timer associated with the current winner
skipping to change at page 96, line 38 skipping to change at page 96, line 38
Usually we will eventually re-assert and win when data packets Usually we will eventually re-assert and win when data packets
for G have started flowing again. for G have started flowing again.
RPF_interface(RP(G)) stops being interface I RPF_interface(RP(G)) stops being interface I
Interface I used to be the RPF interface for RP(G), and now it Interface I used to be the RPF interface for RP(G), and now it
is not. We transition to NoInfo state, and delete this (*,G) is not. We transition to NoInfo state, and delete this (*,G)
assert state (action A5). assert state (action A5).
Receive Join(*,G) or Join(*,*,RP(G)) on interface I Receive Join(*,G) or Join(*,*,RP(G)) on interface I
We receive a Join(*,G) or a Join(*,*,RP(G)) that has the We receive a Join(*,G) or a Join(*,*,RP(G)) that has the
Upstream Neighbor Address field set to my IP address on Upstream Neighbor Address field set to my primary IP address
interface I. The action is to transition to NoInfo state, and on interface I. The action is to transition to NoInfo state,
delete this (*,G) assert state (action A5), and allow the and delete this (*,G) assert state (action A5), and allow the
normal PIM Join/Prune mechanisms to operate. If whoever sent normal PIM Join/Prune mechanisms to operate. If whoever sent
the Join was in error, then the normal assert mechanism will the Join was in error, then the normal assert mechanism will
eventually re-apply and we will lose the assert again. eventually re-apply and we will lose the assert again.
However whoever sent the assert may know that the previous However whoever sent the assert may know that the previous
assert winner has died, and so we may end up being the new assert winner has died, and so we may end up being the new
forwarder. forwarder.
(*,G) Assert State machine Actions (*,G) Assert State machine Actions
A1: Send Assert(*,G) A1: Send Assert(*,G)
skipping to change at page 101, line 35 skipping to change at page 101, line 35
5. Behavior: An (S,G,rpt) prune override is not sent (at all) if 5. Behavior: An (S,G,rpt) prune override is not sent (at all) if
RPF'(S,G,rpt) != RPF'(*,G). RPF'(S,G,rpt) != RPF'(*,G).
Rationale: This avoids keeping state alive on the (S,G) tree when Rationale: This avoids keeping state alive on the (S,G) tree when
only (*,G) downstream members are left. Also, it avoids sending only (*,G) downstream members are left. Also, it avoids sending
(S,G,rpt) joins to a router that is not on the (*,G) tree. This (S,G,rpt) joins to a router that is not on the (*,G) tree. This
behavior might be confusing although this specification does behavior might be confusing although this specification does
indicate that such a join should be dropped. indicate that such a join should be dropped.
6. Behavior: An assert loser that receives a Join(S,G) with an 6. Behavior: An assert loser that receives a Join(S,G) with an
Upstream Neighbor Address that is its primary IP address on that | Upstream Neighbor Address that is its primary IP address on that
interface cancels the (S,G) Assert Timer. interface cancels the (S,G) Assert Timer.
Rationale: This is necessary in order to have rapid convergence in Rationale: This is necessary in order to have rapid convergence in
the event that the downstream router that initially sent a join to the event that the downstream router that initially sent a join to
the prior Assert winner has undergone a topology change. the prior Assert winner has undergone a topology change.
7. Behavior: An assert loser that receives a Join(*,G) or a 7. Behavior: An assert loser that receives a Join(*,G) or a
Join(*,*,RP(G)) with an Upstream Neighbor Address that is one of Join(*,*,RP(G)) with an Upstream Neighbor Address that is its
its addresses on that interface cancels the (*,G) Assert Timer and primary IP address on that interface cancels the (*,G) Assert Timer
all (S,G) assert timers that do not have corresponding and all (S,G) assert timers that do not have corresponding
Prune(S,G,rpt) messages in the compound Join/Prune message. Prune(S,G,rpt) messages in the compound Join/Prune message.
Rationale: Same as 6. Rationale: Same as 6.
8. Behavior: An assert winner for (*,G) or (S,G) sends a canceling 8. Behavior: An assert winner for (*,G) or (S,G) sends a canceling
assert when it is about to stop forwarding on a (*,G) or an (S,G) assert when it is about to stop forwarding on a (*,G) or an (S,G)
entry. This behavior does not apply to (S,G,rpt). entry. This behavior does not apply to (S,G,rpt).
Rationale: This allows switching back to the shared tree after the Rationale: This allows switching back to the shared tree after the
last SPT router on the LAN leaves. Doing this prevents downstream last SPT router on the LAN leaves. Doing this prevents downstream
skipping to change at page 102, line 43 skipping to change at page 102, line 43
multiple administrative scope regions - these are regions where a border multiple administrative scope regions - these are regions where a border
has been configured so that a range of multicast groups will not be has been configured so that a range of multicast groups will not be
forwarded across that border. For more information on Administratively forwarded across that border. For more information on Administratively
Scoped IP Multicast, see RFC 2365. The modified criteria for admin- Scoped IP Multicast, see RFC 2365. The modified criteria for admin-
scoped regions are that the region is convex with respect to forwarding scoped regions are that the region is convex with respect to forwarding
based on the MRIB, and that all PIM routers within the scope region map based on the MRIB, and that all PIM routers within the scope region map
scoped groups to the same RP within that region. scoped groups to the same RP within that region.
This specification does not mandate the use of a single mechanism to This specification does not mandate the use of a single mechanism to
provide routers with the information to perform the group-to-RP mapping. provide routers with the information to perform the group-to-RP mapping.
Currently three mechanisms are possible, and all three have associated Currently four mechanisms are possible, and all four have associated
problems: problems:
Static Configuration Static Configuration
A PIM router MUST support the static configuration of group-to-RP A PIM router MUST support the static configuration of group-to-RP
mappings. Such a mechanism is not robust to failures, but does at mappings. Such a mechanism is not robust to failures, but does at
least provide a basic interoperability mechanism. least provide a basic interoperability mechanism.
Embedded-RP Embedded-RP
Embedded-RP defines an address allocation policy in which the Embedded-RP defines an address allocation policy in which the
address of the Rendezvous Point (RP) is encoded in an IPv6 address of the Rendezvous Point (RP) is encoded in an IPv6
multicast group address [15]. multicast group address [17].
Cisco's Auto-RP Cisco's Auto-RP
Auto-RP uses a PIM Dense-Mode multicast group to announce group-to- Auto-RP uses a PIM Dense-Mode multicast group to announce group-to-
RP mappings from a central location. This mechanism is not useful RP mappings from a central location. This mechanism is not useful
if PIM Dense-Mode is not being run in parallel with PIM Sparse- if PIM Dense-Mode is not being run in parallel with PIM Sparse-
Mode, and was only intended for use with PIM Sparse-Mode Version 1. Mode, and was only intended for use with PIM Sparse-Mode Version 1.
No standard specification currently exists. No standard specification currently exists.
BootStrap Router (BSR) BootStrap Router (BSR)
RFC 2362 specifies a bootstrap mechanism based around the automatic RFC 2362 specifies a bootstrap mechanism based around the automatic
skipping to change at page 103, line 47 skipping to change at page 103, line 47
Using one of the mechanisms described above, a PIM router receives one Using one of the mechanisms described above, a PIM router receives one
or more possible group-range-to-RP mappings. Each mapping specifies a or more possible group-range-to-RP mappings. Each mapping specifies a
range of multicast groups (expressed as a group and mask) and the RP to range of multicast groups (expressed as a group and mask) and the RP to
which such groups should be mapped. Each mapping may also have an which such groups should be mapped. Each mapping may also have an
associated priority. It is possible to receive multiple mappings all of associated priority. It is possible to receive multiple mappings all of
which might match the same multicast group - this is the common case which might match the same multicast group - this is the common case
with BSR. The algorithm for performing the group-to-RP mapping is as with BSR. The algorithm for performing the group-to-RP mapping is as
follows: follows:
1 Perform longest match on group-range to obtain a list of RPs. 1. Perform longest match on group-range to obtain a list of RPs.
2 From this list of matching RPs, find the one with highest priority. 2. From this list of matching RPs, find the one with highest priority.
Eliminate any RPs from the list that have lower priorities. Eliminate any RPs from the list that have lower priorities.
3 If only one RP remains in the list, use that RP. 3. If only one RP remains in the list, use that RP.
4 If multiple RPs are in the list, use the PIM hash function to 4. If multiple RPs are in the list, use the PIM hash function to
choose one. choose one.
Thus if two or more group-range-to-RP mappings cover a particular group, Thus if two or more group-range-to-RP mappings cover a particular group,
the one with the longest mask is the mapping to use. If the mappings the one with the longest mask is the mapping to use. If the mappings
have the same mask length, then the one with the highest priority is have the same mask length, then the one with the highest priority is
chosen. If there is more than one matching entry with the same longest chosen. If there is more than one matching entry with the same longest
mask and the priorities are identical, then a hash function (see Section mask and the priorities are identical, then a hash function (see Section
4.7.2) is applied to choose the RP. 4.7.2) is applied to choose the RP.
This algorithm is invoked by a DR when it needs to determine an RP for a This algorithm is invoked by a DR when it needs to determine an RP for a
skipping to change at page 105, line 5 skipping to change at page 105, line 5
to one of the RPs from the matching set of group-range-to-RP mappings to one of the RPs from the matching set of group-range-to-RP mappings
(this set all have the same longest mask length and same highest (this set all have the same longest mask length and same highest
priority). The algorithm takes as input the group address, and the priority). The algorithm takes as input the group address, and the
addresses of the candidate RPs from the mappings, and gives as output addresses of the candidate RPs from the mappings, and gives as output
one RP address to be used. one RP address to be used.
The protocol requires that all routers hash to the same RP within a The protocol requires that all routers hash to the same RP within a
domain (except for transients). The following hash function must be used domain (except for transients). The following hash function must be used
in each router: in each router:
1 For RP addresses in the matching group-range-to-RP mappings, 1. For RP addresses in the matching group-range-to-RP mappings,
compute a value: compute a value:
Value(G,M,C(i))= Value(G,M,C(i))=
(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31 (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. If BSR is being where C(i) is the RP address and M is a hash-mask. If BSR is being
used, the hash-mask is given in the Bootstrap messages. If BSR is used, the hash-mask is given in the Bootstrap messages. If BSR is
not being used, the alternative mechanism that supplies the group- not being used, the alternative mechanism that supplies the group-
range-to-RP mappings may supply the value, or else it defaults to a range-to-RP mappings may supply the value, or else it defaults to a
mask with the most significant 30 bits being one for IPv4 and the mask with the most significant 30 bits being one for IPv4 and the
skipping to change at page 105, line 33 skipping to change at page 105, line 33
C(i) and G must first be derived from the actual RP or group C(i) and G must first be derived from the actual RP or group
address. Such a digest method must be used consistently throughout address. Such a digest method must be used consistently throughout
the PIM domain. For IPv6 addresses, we recommend using the the PIM domain. For IPv6 addresses, we recommend using the
equivalent IPv4 address for an IPv4-compatible address, and the equivalent IPv4 address for an IPv4-compatible address, and the
exclusive-or of each 32-bit segment of the address for all other exclusive-or of each 32-bit segment of the address for all other
IPv6 addresses. For example, the digest of the IPv6 address IPv6 addresses. For example, the digest of the IPv6 address
3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^ 3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^
0x00000000 ^ 0x00000010, where ^ represents the exclusive-or 0x00000000 ^ 0x00000010, where ^ represents the exclusive-or
operation. operation.
2 The candidate RP with the highest resulting hash value is then the 2. The candidate RP with the highest resulting hash value is then the
RP chosen by this Hash Function. If more than one RP has the same RP chosen by this Hash Function. If more than one RP has the same
highest hash value, the RP with the highest IP address is chosen. highest hash value, the RP with the highest IP address is chosen.
4.8. Source-Specific Multicast 4.8. Source-Specific Multicast
The Source-Specific Multicast (SSM) service model [5] can be implemented The Source-Specific Multicast (SSM) service model [6] can be implemented
with a strict subset of the PIM-SM protocol mechanisms. Both regular IP with a strict subset of the PIM-SM protocol mechanisms. Both regular IP
Multicast and SSM semantics can coexist on a single router and both can Multicast and SSM semantics can coexist on a single router and both can
be implemented using the PIM-SM protocol. A range of multicast be implemented using the PIM-SM protocol. A range of multicast
addresses, currently 232.0.0.0/8 in IPv4 and FF3x::/32 for IPv6, is addresses, currently 232.0.0.0/8 in IPv4 and FF3x::/32 for IPv6, is
reserved for SSM, and the choice of semantics is determined by the reserved for SSM, and the choice of semantics is determined by the
multicast group address in both data packets and PIM messages. multicast group address in both data packets and PIM messages.
4.8.1. Protocol Modifications for SSM destination addresses 4.8.1. Protocol Modifications for SSM destination addresses
The following rules override the normal PIM-SM behavior for a multicast The following rules override the normal PIM-SM behavior for a multicast
skipping to change at page 108, line 25 skipping to change at page 108, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum | |PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver PIM Ver
PIM Version number is 2. PIM Version number is 2.
Type Types for specific PIM messages. PIM Types are: Type Types for specific PIM messages. PIM Types are:
Message Type Destination Message Type Destination
Mes--------------------------------------------------------------------------- ---------------------------------------------------------------------------
0 = Hello Multicast to ALL-PIM-ROUTERS 0 = Hello Multicast to ALL-PIM-ROUTERS
1 = Register Unicast to RP 1 = Register Unicast to RP
2 = Register-Stop Unicast to source of Register packet 2 = Register-Stop Unicast to source of Register packet
3 = Join/Prune Multicast to ALL-PIM-ROUTERS 3 = Join/Prune Multicast to ALL-PIM-ROUTERS
4 = Bootstrap Multicast to ALL-PIM-ROUTERS 4 = Bootstrap Multicast to ALL-PIM-ROUTERS
5 = Assert Multicast to ALL-PIM-ROUTERS 5 = Assert Multicast to ALL-PIM-ROUTERS
6 = Graft (used in PIM-DM only) Multicast to ALL-PIM-ROUTERS 6 = Graft (used in PIM-DM only) Unicast to RPF'(S)
7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft packet 7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft packet
8 = Candidate-RP-Advertisement Unicast to Domain's BSR 8 = Candidate-RP-Advertisement Unicast to Domain's BSR
Reserved Reserved
Set to zero on transmission. Ignored upon receipt. Set to zero on transmission. Ignored upon receipt.
Checksum Checksum
The checksum is a standard IP checksum, i.e. the 16-bit one's The checksum is a standard IP checksum, i.e. the 16-bit one's
complement of the one's complement sum of the entire PIM message, complement of the one's complement sum of the entire PIM message,
excluding the "Multicast data packet" section of the Register excluding the "Multicast data packet" section of the Register
message. For computing the checksum, the checksum field is zeroed. message. For computing the checksum, the checksum field is zeroed.
If the packet's length is not an integral number of 16-bit words, If the packet's length is not an integral number of 16-bit words,
the packet is padded with a trailing byte of zero before performing the packet is padded with a trailing byte of zero before performing
the checksum. the checksum.
For IPv6, the checksum also includes the IPv6 "pseudo-header", as For IPv6, the checksum also includes the IPv6 "pseudo-header", as
specified in RFC 2460, Section 8.1 [4]. This "pseudo-header" is specified in RFC 2460, Section 8.1 [5]. This "pseudo-header" is
prepended to the PIM header for the purposes of calculating the prepended to the PIM header for the purposes of calculating the
checksum. The "Upper-Layer Packet Length" in the pseudo-header is checksum. The "Upper-Layer Packet Length" in the pseudo-header is
set to the length of the PIM message, except in Register messages set to the length of the PIM message, except in Register messages
where it is set to the length of the PIM register header (8). The where it is set to the length of the PIM register header (8). The
Next Header value used in the pseudo-header is 103. Next Header value used in the pseudo-header is 103.
If a message is received with an unrecognized PIM Ver or Type field or a If a message is received with an unrecognized PIM Ver or Type field or a
message's destination does not correspond to the table above, it MUST be message's destination does not correspond to the table above, it MUST be
discarded and an error message SHOULD be logged to the administrator in discarded and an error message SHOULD be logged to the administrator in
a rate limited manner. a rate limited manner.
skipping to change at page 109, line 35 skipping to change at page 109, line 35
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 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 Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
The PIM address family of the `Unicast Address' field of this The PIM address family of the `Unicast Address' field of this
address. address.
Values of 0-127 are as assigned by the IANA for Internet Address Values of 0-127 are as assigned by the IANA for Internet Address
Families in [6]. Values 128-250 are reserved to be assigned by the Families in [7]. Values 128-250 are reserved to be assigned by the
IANA for PIM-specific Address Families. Values 251 though 255 are IANA for PIM-specific Address Families. Values 251 though 255 are
designated for private use. As there is no assignment authority designated for private use. As there is no assignment authority
for this space, collisions should be expected. for this space, collisions should be expected.
Encoding Type Encoding Type
The type of encoding used within a specific Address Family. The The type of encoding used within a specific Address Family. The
value `0' is reserved for this field, and represents the native value `0' is reserved for this field, and represents the native
encoding of the Address Family. encoding of the Address Family.
Unicast Address Unicast Address
skipping to change at page 110, line 24 skipping to change at page 110, line 24
| Group multicast Address | Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
described above. described above.
Encoding Type Encoding Type
described above. described above.
[B]idirectional PIM [B]idirectional PIM
indicates the group range should use Bidirectional PIM [12]. For indicates the group range should use Bidirectional PIM [13]. For
PIM-SM defined in this specification, this bit MUST be zero. PIM-SM defined in this specification, this bit MUST be zero.
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Admin Scope [Z]one Admin Scope [Z]one
indicates the group range is an admin scope zone. This is used in indicates the group range is an admin scope zone. This is used in
the Bootstrap Router Mechanism [11] only. For all other purposes, the Bootstrap Router Mechanism [11] only. For all other purposes,
this bit is set to zero and ignored on receipt. this bit is set to zero and ignored on receipt.
skipping to change at page 115, line 8 skipping to change at page 115, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Address N (Encoded-Unicast format) | | Secondary Address N (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the Address List Hello option are described in The contents of the Address List Hello option are described in
Section 4.3.4. All addresses within a single Address List must Section 4.3.4. All addresses within a single Address List must
belong to the same address family. belong to the same address family.
OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes
65001 through 65535 are reserved for Private Use, as defined in 65001 through 65535 are reserved for Private Use, as defined in
[8]. [9].
Unknown options MUST be ignored, and MUST NOT prevent a neighbor | Unknown options MUST be ignored, and MUST NOT prevent a neighbor
relationship from being formed. The "Holdtime" option MUST be relationship from being formed. The "Holdtime" option MUST be
implemented; the "DR Priority" and "Generation ID" options SHOULD implemented; the "DR Priority" and "Generation ID" options SHOULD
be implemented. The "Address List" option MUST be implemented for be implemented. The "Address List" option MUST be implemented for
IPv6. IPv6.
4.9.3. Register Message Format 4.9.3. Register Message Format
A Register message is sent by the DR or a PMBR to the RP when a A Register message is sent by the DR or a PMBR to the RP when a
multicast packet needs to be transmitted on the RP-tree. The IP source multicast packet needs to be transmitted on the RP-tree. The IP source
address is set to the address of the DR, the destination address to the address is set to the address of the DR, the destination address to the
skipping to change at page 121, line 35 skipping to change at page 121, line 35
Prune Sources. This section describes the different types of group sets Prune Sources. This section describes the different types of group sets
and source list entries that can exist in a Join / Prune message. and source list entries that can exist in a Join / Prune message.
There are two valid group set types: There are two valid group set types:
Wildcard Group Set Wildcard Group Set
The wildcard group set is represented by the entire multicast range The wildcard group set is represented by the entire multicast range
- the beginning of the multicast address range in the group address - the beginning of the multicast address range in the group address
field and the prefix length of the multicast address range in the field and the prefix length of the multicast address range in the
mask length field of the Multicast Group Address, i.e., mask length field of the Multicast Group Address, i.e.,
`224.0.0.0/4' for IPv4 or `ff00::/8' for IPv6. Each Join / Prune | `224.0.0.0/4' for IPv4 or `ff00::/8' for IPv6. Each Join / Prune
message SHOULD contain at most one wildcard group set. Each message SHOULD contain at most one wildcard group set. Each
wildcard group set may contain one or more (*,*,RP) source list wildcard group set may contain one or more (*,*,RP) source list
entries in either the Join or Prune lists. entries in either the Join or Prune lists.
A (*,*,RP) source list entry may only exist in a wildcard group A (*,*,RP) source list entry may only exist in a wildcard group
set. When added to a Join source list, this type of source entry set. When added to a Join source list, this type of source entry
expresses the router's interest in receiving traffic for all groups expresses the router's interest in receiving traffic for all groups
mapping to the specified RP. When added to a Prune source list a mapping to the specified RP. When added to a Prune source list a
(*,*,RP) entry expresses the router's interest to stop receiving (*,*,RP) entry expresses the router's interest to stop receiving
such traffic. Note that as indicated by the Join/Prune state such traffic. Note that as indicated by the Join/Prune state
machines, such a Join or Prune will NOT override Join/Prune state machines, such a Join or Prune will NOT override Join/Prune state
created using a Group-Specific Set (see below). created using a Group-Specific Set (see below).
(*,*,RP) source list entries have the Source-Address set to the (*,*,RP) source list entries have the Source-Address set to the
address of the RP, the Source-Address Mask-Len set to the full address of the RP, the Source-Address Mask-Len set to the full
length of the IP address and both the WC and RPT bits of the length of the IP address and both the WC and RPT bits of the
Source-Address set to 1. Source-Address set to 1.
Group Specific Set Group Specific Set
A Group Specific Set is represented by a valid IP multicast address A Group Specific Set is represented by a valid IP multicast address
in the group address field and the full length of the IP address in | in the group address field and the full length of the IP address in
the mask length field of the Multicast Group Address. Each Join / | the mask length field of the Multicast Group Address. Each Join /
Prune message SHOULD NOT contain more than one group specific set | Prune message SHOULD NOT contain more than one group specific set
for the same IP multicast address. Each group specific set may for the same IP multicast address. Each group specific set may
contain (*,G), (S,G,rpt) and (S,G) source list entries in the Join contain (*,G), (S,G,rpt) and (S,G) source list entries in the Join
or Prune lists. or Prune lists.
(*,G) (*,G)
The (*,G) source list entry is used in Join / Prune messages The (*,G) source list entry is used in Join / Prune messages
sent towards the RP for the specified group. It expresses sent towards the RP for the specified group. It expresses
interest (or lack of) in receiving traffic sent to the group interest (or lack of) in receiving traffic sent to the group
through the Rendezvous-Point shared tree. There may only be through the Rendezvous-Point shared tree. There may only be
one such entry in both the Join and Prune lists of a group one such entry in both the Join and Prune lists of a group
skipping to change at page 123, line 32 skipping to change at page 123, line 32
o The combination of a (*,G) Prune and a (S,G,rpt) Join is also not o The combination of a (*,G) Prune and a (S,G,rpt) Join is also not
generated. (S,G,rpt) Joins are only sent when the router is receiving generated. (S,G,rpt) Joins are only sent when the router is receiving
all traffic for a group on the shared tree and it wishes to indicate a all traffic for a group on the shared tree and it wishes to indicate a
change for the particular source. As a (*,G) prune indicates that the change for the particular source. As a (*,G) prune indicates that the
router no longer wishes to receive shared tree traffic, the (S,G,rpt) router no longer wishes to receive shared tree traffic, the (S,G,rpt)
Join would be meaningless. Join would be meaningless.
o As Join / Prune messages are targeted to a single PIM neighbor, o As Join / Prune messages are targeted to a single PIM neighbor,
including both a (S,G) Join and a (S,G,rpt) Prune in the same message including both a (S,G) Join and a (S,G,rpt) Prune in the same message
is redundant. The (S,G) Join informs the neighbor that the sender is usually redundant. The (S,G) Join informs the neighbor that the
wishes to receive the particular source on the shortest path tree. It sender wishes to receive the particular source on the shortest path
is therefore unnecessary for the router to say that it no longer tree. It is therefore unnecessary for the router to say that it no
wishes to receive it on the shared tree. longer wishes to receive it on the shared tree. However, there is a
valid interpretation for this combination of entries. A downstream
router may have to instruct its upstream to only start forwarding a
specific source once it has started receiving the source on the
shortest-path tree.
o The combination of a (S,G) Prune and a (S,G,rpt) Join could possibly o The combination of a (S,G) Prune and a (S,G,rpt) Join could possibly
be used by a router to switch from receiving a particular source on be used by a router to switch from receiving a particular source on
the shortest-path tree back to receiving it on the shared tree the shortest-path tree back to receiving it on the shared tree
(provided that the RPF neighbor for the shortest-path and shared trees (provided that the RPF neighbor for the shortest-path and shared trees
is common). However Sparse-Mode PIM does not provide a mechanism for is common). However Sparse-Mode PIM does not provide a mechanism for
switching back to the shared tree. explicitly switching back to the shared tree.
The rules are summarized in the tables below. The rules are summarized in the tables below.
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
| ||Join | Prune | Join | Prune | Join | Prune | | ||Join | Prune | Join | Prune | Join | Prune |
| ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) | | ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Join ||- | no | ? | yes | yes | yes | |Join ||- | no | ? | yes | yes | yes |
|(*,G) || | | | | | | |(*,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Prune ||no | - | ? | ? | yes | yes | |Prune ||no | - | ? | ? | yes | yes |
|(*,G) || | | | | | | |(*,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Join ||? | ? | - | no | yes | ? | |Join ||? | ? | - | no | yes | ? |
|(S,G,rpt) || | | | | | | |(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | ? | no | - | ? | yes | |Prune ||yes | ? | no | - | yes | ? |
|(S,G,rpt) || | | | | | | |(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Join ||yes | yes | yes | ? | - | no | |Join ||yes | yes | yes | yes | - | no |
|(S,G) || | | | | | | |(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | yes | yes | ? | no | - | |Prune ||yes | yes | ? | ? | no | - |
|(S,G) || | | | | | | |(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
+---------------++--------------+----------------+------------+ +---------------++--------------+----------------+------------+
| ||Join (*,*,RP) | Prune (*,*,RP) | all others | | ||Join (*,*,RP) | Prune (*,*,RP) | all others |
+---------------++--------------+----------------+------------+ +---------------++--------------+----------------+------------+
|Join (*,*,RP) ||- | no | yes | |Join (*,*,RP) ||- | no | yes |
+---------------++--------------+----------------+------------+ +---------------++--------------+----------------+------------+
|Prune (*,*,RP) ||no | - | yes | |Prune (*,*,RP) ||no | - | yes |
+---------------++--------------+----------------+------------+ +---------------++--------------+----------------+------------+
skipping to change at page 129, line 12 skipping to change at page 129, line 12
of a timer on a specific interface. When timers are initialized in this of a timer on a specific interface. When timers are initialized in this
document the value specific to the interface in context must be used. document the value specific to the interface in context must be used.
Some of the timers listed below (Prune-Pending, Upstream Join, Upstream Some of the timers listed below (Prune-Pending, Upstream Join, Upstream
Override) can be set to values which depend on the settings of the Override) can be set to values which depend on the settings of the
Propagation_Delay and Override_Interval of the corresponding interface. Propagation_Delay and Override_Interval of the corresponding interface.
The default values for these are given below. The default values for these are given below.
Variable Name: Propagation_Delay(I) Variable Name: Propagation_Delay(I)
r+-------------------------------+---------------+-----------------------+ +-------------------------------+---------------+-----------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+-------------------------------+---------------+-----------------------+ +-------------------------------+---------------+-----------------------+
| Propagation_delay_default | 0.5 secs | Expected | | Propagation_delay_default | 0.5 secs | Expected |
| | | propagation delay | | | | propagation delay |
| | | over the local | | | | over the local |
| | | link. | | | | link. |
|
+-------------------------------+---------------+-----------------------+ +-------------------------------+---------------+-----------------------+
The default value of the Propagation_delay_default is chosen to be The default value of the Propagation_delay_default is chosen to be
relatively large to provide compatibility with older PIM relatively large to provide compatibility with older PIM
implementations. implementations.
Variable Name: Override_Interval(I) Variable Name: Override_Interval(I)
r+--------------------------+-----------------+--------------------------+ +--------------------------+-----------------+--------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+--------------------------+-----------------+--------------------------+ +--------------------------+-----------------+--------------------------+
| t_override_default | 2.5 secs | Default delay | | t_override_default | 2.5 secs | Default delay |
| | | interval over | | | | interval over |
| | | which to randomize | | | | which to randomize |
| | | when scheduling a | | | | when scheduling a |
| | | delayed Join | | | | delayed Join |
| | | message. | | | | message. |
|
+--------------------------+-----------------+--------------------------+ +--------------------------+-----------------+--------------------------+
Timer Name: Hello Timer (HT(I)) Timer Name: Hello Timer (HT(I))
m+----------------------+---------+---------------------------------------+ +----------------------+---------+---------------------------------------+
|Value Name | Value | Explanation | |Value Name | Value | Explanation |
|
+----------------------+---------+---------------------------------------+ +----------------------+---------+---------------------------------------+
|Hello_Period | 30 secs | Periodic interval for Hello messages. | |Hello_Period | 30 secs | Periodic interval for Hello messages. |
|
+----------------------+---------+---------------------------------------+ +----------------------+---------+---------------------------------------+
|Triggered_Hello_Delay | 5 secs | Randomized interval for initial Hello | |Triggered_Hello_Delay | 5 secs | Randomized interval for initial Hello |
| | | message on bootup or triggered Hello | | | | message on bootup or triggered Hello |
| | | message to a rebooting neighbor. | | | | message to a rebooting neighbor. |
|
+----------------------+---------+---------------------------------------+ +----------------------+---------+---------------------------------------+
At system power-up, the timer is initialized to rand(0, At system power-up, the timer is initialized to rand(0,
Triggered_Hello_Delay) to prevent synchronization. When a new or Triggered_Hello_Delay) to prevent synchronization. When a new or
rebooting neighbor is detected, a responding Hello is sent within rebooting neighbor is detected, a responding Hello is sent within
rand(0, Triggered_Hello_Delay). rand(0, Triggered_Hello_Delay).
Timer Name: Neighbor Liveness Timer (NLT(N,I)) Timer Name: Neighbor Liveness Timer (NLT(N,I))
m+--------------------------+-----------------------+--------------------+ +--------------------------+-----------------------+--------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+--------------------------+-----------------------+--------------------+ +--------------------------+-----------------------+--------------------+
| Default_Hello_Holdtime | 3.5 * Hello_Period | Default holdtime | | Default_Hello_Holdtime | 3.5 * Hello_Period | Default holdtime |
| | | to keep neighbor | | | | to keep neighbor |
| | | state alive | | | | state alive |
|
+--------------------------+-----------------------+--------------------+ +--------------------------+-----------------------+--------------------+
| Hello_Holdtime | from message | Holdtime from | | Hello_Holdtime | from message | Holdtime from |
| | | Hello Message | | | | Hello Message |
| | | Holdtime option. | | | | Holdtime option. |
|
+--------------------------+-----------------------+--------------------+ +--------------------------+-----------------------+--------------------+
The Holdtime in a Hello Message should be set to (3.5 * Hello_Period), The Holdtime in a Hello Message should be set to (3.5 * Hello_Period),
giving a default value of 105 seconds. giving a default value of 105 seconds.
Timer Names: Expiry Timer (ET(*,*,RP,I), ET(*,G,I), ET(S,G,I), Timer Names: Expiry Timer (ET(*,*,RP,I), ET(*,G,I), ET(S,G,I),
ET(S,G,rpt,I)) ET(S,G,rpt,I))
(+----------------+-----------------+------------------------------------+ +----------------+-----------------+------------------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+----------------+-----------------+------------------------------------+ +----------------+-----------------+------------------------------------+
| J/P_HoldTime | from message | Holdtime from Join/Prune Message | | J/P_HoldTime | from message | Holdtime from Join/Prune Message |
|
+----------------+-----------------+------------------------------------+ +----------------+-----------------+------------------------------------+
See details of JT(*,G) for the Holdtime that is included in Join/Prune See details of JT(*,G) for the Holdtime that is included in Join/Prune
Messages. Messages.
Timer Names: Prune-Pending Timer (PPT(*,*,RP,I), PPT(*,G,I), PPT(S,G,I), Timer Names: Prune-Pending Timer (PPT(*,*,RP,I), PPT(*,G,I), PPT(S,G,I),
PPT(S,G,rpt,I)) PPT(S,G,rpt,I))
T+---------------------------+---------------------+---------------------+ +---------------------------+---------------------+---------------------+
|Value Name | Value | Explanation | |Value Name | Value | Explanation |
|
+---------------------------+---------------------+---------------------+ +---------------------------+---------------------+---------------------+
|J/P_Override_Interval(I) | Default: | Short period after | |J/P_Override_Interval(I) | Default: | Short period after |
| | Effective_ | a join or prune to | | | Effective_ | a join or prune to |
| | Propagation_ | allow other | | | Propagation_ | allow other |
| | Delay(I) + | routers on the LAN | | | Delay(I) + | routers on the LAN |
| | EffectiveOverride_ | to override the | | | EffectiveOverride_ | to override the |
| | Interval(I) | join or prune | | | Interval(I) | join or prune |
|
+---------------------------+---------------------+---------------------+ +---------------------------+---------------------+---------------------+
Note that both the Effective_Propagation_Delay(I) and the Note that both the Effective_Propagation_Delay(I) and the
Effective_Override_Interval(I) are interface specific values that may Effective_Override_Interval(I) are interface specific values that may
change when Hello messages are received (see section 4.3.3). change when Hello messages are received (see section 4.3.3).
Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I)) Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))
m+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
| Assert_Override_Interval | Default: 3 secs | Short interval | | Assert_Override_Interval | Default: 3 secs | Short interval |
| | | before an assert | | | | before an assert |
| | | times out where | | | | times out where |
| | | the assert winner | | | | the assert winner |
| | | resends an Assert | | | | resends an Assert |
| | | message | | | | message |
|
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
| Assert_Time | Default: 180 secs | Period after last | | Assert_Time | Default: 180 secs | Period after last |
| | | assert before | | | | assert before |
| | | assert state is | | | | assert state is |
| | | timed out | | | | timed out |
|
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
Note that for historical reasons, the Assert message lacks a Holdtime Note that for historical reasons, the Assert message lacks a Holdtime
field. Thus changing the Assert Time from the default value is not field. Thus changing the Assert Time from the default value is not
recommended. recommended.
Timer Names: Upstream Join Timer (JT(*,*,RP), JT(*,G), JT(S,G)) Timer Names: Upstream Join Timer (JT(*,*,RP), JT(*,G), JT(S,G))
m+-------------+--------------------+-------------------------------------+ +-------------+--------------------+-------------------------------------+
|Value Name | Value | Explanation | |Value Name | Value | Explanation |
|
+-------------+--------------------+-------------------------------------+ +-------------+--------------------+-------------------------------------+
|t_periodic | Default: 60 secs | Period between Join/Prune Messages | |t_periodic | Default: 60 secs | Period between Join/Prune Messages |
|
+-------------+--------------------+-------------------------------------+ +-------------+--------------------+-------------------------------------+
|t_suppressed | rand(1.1 * | Suppression period when someone | |t_suppressed | rand(1.1 * | Suppression period when someone |
| | t_periodic, 1.4 * | else sends a J/P message so we | | | t_periodic, 1.4 * | else sends a J/P message so we |
| | t_periodic) when | don't need to do so. | | | t_periodic) when | don't need to do so. |
| | Suppression_ | | | | Suppression_ | |
| | Enabled(I) is | | | | Enabled(I) is | |
| | true, 0 otherwise | | | | true, 0 otherwise | |
|
+-------------+--------------------+-------------------------------------+ +-------------+--------------------+-------------------------------------+
|t_override | rand(0, Effective_ | Randomized delay to prevent | |t_override | rand(0, Effective_ | Randomized delay to prevent |
| | Override_ | response implosion when sending a | | | Override_ | response implosion when sending a |
| | Interval(I)) | join message to override someone | | | Interval(I)) | join message to override someone |
| | | else's Prune message. | | | | else's Prune message. |
|
+-------------+--------------------+-------------------------------------+ +-------------+--------------------+-------------------------------------+
t_periodic may be set to take into account such things as the configured t_periodic may be set to take into account such things as the configured
bandwidth and expected average number of multicast route entries for the bandwidth and expected average number of multicast route entries for the
attached network or link (e.g., the period would be longer for lower- attached network or link (e.g., the period would be longer for lower-
speed links, or for routers in the center of the network that expect to speed links, or for routers in the center of the network that expect to
have a larger number of entries). If the Join/Prune-Period is modified have a larger number of entries). If the Join/Prune-Period is modified
during operation, these changes should be made relatively infrequently during operation, these changes should be made relatively infrequently
and the router should continue to refresh at its previous Join/Prune- and the router should continue to refresh at its previous Join/Prune-
Period for at least Join/Prune-Holdtime, in order to allow the upstream Period for at least Join/Prune-Holdtime, in order to allow the upstream
skipping to change at page 133, line 7 skipping to change at page 133, line 7
t_periodic). t_periodic).
t_override depends on the Effective_Override_Interval of the upstream t_override depends on the Effective_Override_Interval of the upstream
interface which may change when Hello messages are received. interface which may change when Hello messages are received.
t_suppressed depends on the Suppression State of the upstream interface t_suppressed depends on the Suppression State of the upstream interface
(Section 4.3.3) and becomes zero when suppression is disabled. (Section 4.3.3) and becomes zero when suppression is disabled.
Timer Name: Upstream Override Timer (OT(S,G,rpt)) Timer Name: Upstream Override Timer (OT(S,G,rpt))
m+---------------+---------------------------+---------------------------+ +---------------+---------------------------+---------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+---------------+---------------------------+---------------------------+ +---------------+---------------------------+---------------------------+
| t_override | see Upstream Join Timer | see Upstream Join Timer | | t_override | see Upstream Join Timer | see Upstream Join Timer |
|
+---------------+---------------------------+---------------------------+ +---------------+---------------------------+---------------------------+
The upstream Override Timer is only ever set to t_override; this value The upstream Override Timer is only ever set to t_override; this value
is defined in the section on Upstream Join Timers. is defined in the section on Upstream Join Timers.
Timer Name: Keepalive Timer (KAT(S,G)) Timer Name: Keepalive Timer (KAT(S,G))
m+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
| Keepalive_Period | Default: 210 secs | Period after last | | Keepalive_Period | Default: 210 secs | Period after last |
| | | (S,G) data packet | | | | (S,G) data packet |
| | | during which (S,G) | | | | during which (S,G) |
| | | Join state will be | | | | Join state will be |
| | | maintained even in | | | | maintained even in |
| | | the absence of | | | | the absence of |
| | | (S,G) Join | | | | (S,G) Join |
| | | messages. | | | | messages. |
|
+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
| RP_Keepalive_Period | ( 3 * Register_ | As | | RP_Keepalive_Period | ( 3 * Register_ | As |
| | Suppression_Time ) | Keepalive_Period, | | | Suppression_Time ) | Keepalive_Period, |
| | + Register_ | but at the RP when | | | + Register_ | but at the RP when |
| | Probe_Time | a Register-Stop is | | | Probe_Time | a Register-Stop is |
| | | sent. | | | | sent. |
|
+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
The normal keepalive period for the KAT(S,G) defaults to 210 seconds. The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
However at the RP, the keepalive period must be at least the However at the RP, the keepalive period must be at least the
Register_Suppression_Time or the RP may time out the (S,G) state before Register_Suppression_Time or the RP may time out the (S,G) state before
the next Null-Register arrives. Thus the KAT(S,G) is set to the next Null-Register arrives. Thus the KAT(S,G) is set to
max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent. max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent.
Timer Name: Register-Stop Timer (RST(S,G)) Timer Name: Register-Stop Timer (RST(S,G))
m+----------------------------+--------------------+---------------------+ +----------------------------+--------------------+---------------------+
|Value Name | Value | Explanation | |Value Name | Value | Explanation |
|
+----------------------------+--------------------+---------------------+ +----------------------------+--------------------+---------------------+
|Register_Suppression_Time | Default: 60 secs | Period during | |Register_Suppression_Time | Default: 60 secs | Period during |
| | | which a DR stops | | | | which a DR stops |
| | | sending Register- | | | | sending Register- |
| | | encapsulated data | | | | encapsulated data |
| | | to the RP after | | | | to the RP after |
| | | receiving a | | | | receiving a |
| | | Register-Stop | | | | Register-Stop |
| | | message. | | | | message. |
|
+----------------------------+--------------------+---------------------+ +----------------------------+--------------------+---------------------+
|Register_Probe_Time | Default: 5 secs | Time before RST | |Register_Probe_Time | Default: 5 secs | Time before RST |
| | | expires when a DR | | | | expires when a DR |
| | | may send a Null- | | | | may send a Null- |
| | | Register to the RP | | | | Register to the RP |
| | | to cause it to | | | | to cause it to re- |
| | | resend a Register- | | | | send a Register- |
| | | Stop message. | | | | Stop message. |
|
+----------------------------+--------------------+---------------------+ +----------------------------+--------------------+---------------------+
If the the Register_Suppression_Time or the Register_Probe_Time are If the the Register_Suppression_Time or the Register_Probe_Time are
configured to values other than the defaults it MUST be ensured that the configured to values other than the defaults it MUST be ensured that the
value of the Register_Probe_Time is less than half the value of the value of the Register_Probe_Time is less than half the value of the
Register_Suppression_Time to prevent a possible negative value in the Register_Suppression_Time to prevent a possible negative value in the
setting of the Register-Stop Timer. setting of the Register-Stop Timer.
5. IANA Considerations 5. IANA Considerations
5.1. PIM Address Family 5.1. PIM Address Family
The PIM Address Family field was chosen to be 8 bits as a tradeoff The PIM Address Family field was chosen to be 8 bits as a tradeoff
between packet format and use of the IANA assigned numbers. Since when between packet format and use of the IANA assigned numbers. Since when
the PIM packet format was designed only 15 values were assigned for the PIM packet format was designed only 15 values were assigned for
Address Families, and large numbers of new Address Family values were Address Families, and large numbers of new Address Family values were
not envisioned, 8 bits seemed large enough. However, the IANA assigns not envisioned, 8 bits seemed large enough. However, the IANA assigns
Address Families in a 16-bit field. Therefore, the PIM Address Family Address Families in a 16-bit field. Therefore, the PIM Address Family
is allocated as follows: is allocated as follows:
Values 0 through 127 are designated to have the same meaning as Values 0 through 127 are designated to have the same meaning as
IANA-assigned Address Family Numbers [6]. IANA-assigned Address Family Numbers [7].
Values 128 through 250 are designated to be assigned for PIM by the Values 128 through 250 are designated to be assigned for PIM by the
IANA based upon IESG Approval, as defined in [8]. IANA based upon IESG Approval, as defined in [9].
Values 251 through 255 are designated for Private Use, as defined Values 251 through 255 are designated for Private Use, as defined
in [8]. in [9].
5.2. PIM Hello Options 5.2. PIM Hello Options
Values 17 through 65000 are to be assigned by the IANA. Since the space Values 17 through 65000 are to be assigned by the IANA. Since the space
is large, they may be assigned as First Come First Served as defined in is large, they may be assigned as First Come First Served as defined in
[8]. Such assignments are valid for one year, and may be renewed. [9]. Such assignments are valid for one year, and may be renewed.
Permanent assignments require a specification (see "Specification Permanent assignments require a specification (see "Specification
Required" in [8].) Required" in [9].)
6. Security Considerations 6. Security Considerations
The IPsec authentication header [7] MAY be used to provide data This section describes various possible security concerns related to the
integrity protection and groupwise data origin authentication of PIM PIM-SM protocol, including a description of how to use IPsec to secure
protocol messages. Authentication of PIM messages can protect against the protocol. The reader is referred to [15] and [16] for a further
unwanted behaviors caused by unauthorized or altered PIM messages. discussion of PIM-SM and multicast security. The IPsec authentication
header [8] MAY be used to provide data integrity protection and
groupwise data origin authentication of PIM protocol messages.
Authentication of PIM messages can protect against unwanted behaviors
caused by unauthorized or altered PIM messages.
6.1. Attacks based on forged messages 6.1. Attacks based on forged messages
The extent of possible damage depends on the type of counterfeit The extent of possible damage depends on the type of counterfeit
messages accepted. We next consider the impact of possible forgeries, messages accepted. We next consider the impact of possible forgeries,
including forged link-local (Join/Prune, Hello, and Assert) and forged including forged link-local (Join/Prune, Hello, and Assert) and forged
unicast (Register and Register-Stop) messages. unicast (Register and Register-Stop) messages.
6.1.1. Forged link-local messages 6.1.1. Forged link-local messages
skipping to change at page 136, line 20 skipping to change at page 136, line 24
downstream of that LAN from receiving traffic. downstream of that LAN from receiving traffic.
6.1.2. Forged unicast messages 6.1.2. Forged unicast messages
Register messages and Register-Stop messages are forwarded by Register messages and Register-Stop messages are forwarded by
intermediate routers to their destination using normal IP forwarding. intermediate routers to their destination using normal IP forwarding.
Without data origin authentication, an attacker who is located anywhere Without data origin authentication, an attacker who is located anywhere
in the network may be able to forge a Register or Register-Stop message. in the network may be able to forge a Register or Register-Stop message.
We consider the effect of a forgery of each of these messages next. We consider the effect of a forgery of each of these messages next.
1 By forging a Register message, an attacker can cause the RP to 1. By forging a Register message, an attacker can cause the RP to
inject forged traffic onto the shared multicast tree. inject forged traffic onto the shared multicast tree.
2 By forging a Register-stop message, an attacker can prevent a 2. By forging a Register-stop message, an attacker can prevent a
legitimate DR from Registering packets to the RP. This can prevent legitimate DR from Registering packets to the RP. This can prevent
local hosts on that LAN from sending multicast packets. local hosts on that LAN from sending multicast packets.
The above two PIM messages are not changed by intermediate routers and The above two PIM messages are not changed by intermediate routers and
need only be examined by the intended receiver. Thus these messages can need only be examined by the intended receiver. Thus these messages can
be authenticated end-to-end, using AH. Attacks on Register and be authenticated end-to-end, using AH. Attacks on Register and
Register-Stop messages do not apply to a PIM-SSM-only implementation, as Register-Stop messages do not apply to a PIM-SSM-only implementation, as
these messages are not required for PIM-SSM. these messages are not required for PIM-SSM.
6.2. Non-cryptographic Authentication Mechanisms 6.2. Non-cryptographic Authentication Mechanisms
skipping to change at page 137, line 10 skipping to change at page 137, line 14
An implementation SHOULD provide a mechanism to allow an RP to restrict An implementation SHOULD provide a mechanism to allow an RP to restrict
the range of source addresses from which it accepts Register- the range of source addresses from which it accepts Register-
encapsulated packets. encapsulated packets.
All options that restrict the range of addresses from which packets are All options that restrict the range of addresses from which packets are
accepted MUST default to allowing all packets. accepted MUST default to allowing all packets.
6.3. Authentication using IPsec 6.3. Authentication using IPsec
The IPsec [7] transport mode using the Authentication Header (AH) is the The IPsec [8] transport mode using the Authentication Header (AH) is the
recommended method to prevent the above attacks against PIM. The recommended method to prevent the above attacks against PIM. The
specific AH authentication algorithm and parameters, including the specific AH authentication algorithm and parameters, including the
choice of authentication algorithm and the choice of key, are configured choice of authentication algorithm and the choice of key, are configured
by the network administrator. When IPsec authentication is used, a PIM by the network administrator. When IPsec authentication is used, a PIM
router should reject (drop without processing) any unauthorized PIM router should reject (drop without processing) any unauthorized PIM
protocol messages. protocol messages.
As of this writing, the IPsec anti-replay option does not handle the
case of a Security Association identified by a multicast destination
address. Thus, the anti-replay option currently must be disabled on
these Security Associations. Until replay prevention for link-local
multicast messages is addressed (one such proposal is [14]), the anti-
replay option SHOULD be enabled on all security associations having a
unicast destination address.
To use IPsec, the administrator of a PIM network configures each PIM To use IPsec, the administrator of a PIM network configures each PIM
router with one or more Security Associations and associated SPI(s) that | router with one or more Security Associations and associated SPI(s) that
are used by senders to authenticate PIM protocol messages and are used are used by senders to authenticate PIM protocol messages and are used
by receivers to authenticate received PIM protocol messages. This by receivers to authenticate received PIM protocol messages. This
document does not describe protocols for establishing Security document does not describe protocols for establishing Security
Associations. It assumes that manual configuration of Security Associations. It assumes that manual configuration of Security
Associations is performed, but it does not preclude the use of a Associations is performed, but it does not preclude the use of a
negotiation protocol such as The Internet Key Exchange [13] to establish negotiation protocol such as The Internet Key Exchange [14] to establish
Security Associations. Security Associations.
IPsec [8] provides protection against replayed unicast and multicast
messages. The anti-replay option for IPsec SHOULD be enabled on all
security associations.
The following sections describe the Security Associations required to The following sections describe the Security Associations required to
protect PIM protocol messages. protect PIM protocol messages.
6.3.1. Protecting link-local multicast messages 6.3.1. Protecting link-local multicast messages
The network administrator defines a Security Association (SA) and The network administrator defines a Security Association (SA) and
Security Parameters Index (SPI) that is to be used to authenticate all Security Parameters Index (SPI) that is to be used to authenticate all
link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each
link in a PIM domain. All link-local PIM protocol messages use SPI 0. link in a PIM domain.
The Security Policy Database at a PIM router should be configured to
ensure that all incoming and outgoing Join/Prune, Assert, and Hello
packets use the SA associated with the interface to which the packet is
sent.
Note that, according to [7] there is nominally a different Security
Association Database (SAD) for each router interface. Thus, the
selected Security Association for an inbound PIM packet can vary IPsec [8] allows (but does not require) there to be different Security
depending on the interface on which the packet arrived. This fact Policy Databases (SPD) for each router interface. If available, it may
allows the network administrator to use different authentication methods be desirable to configure the Security Policy Database at a PIM router
for each link, even though the destination address is the same for all such that all incoming and outgoing Join/Prune, Assert, and Hello
link-local PIM packets, regardless of interface. packets use a different SA for each incoming or outgoing interface.
6.3.2. Protecting unicast messages 6.3.2. Protecting unicast messages
IPSec can also be used to provide data origin authentication and data IPsec can also be used to provide data origin authentication and data
integrity protection for the Register and Register-Stop unicast integrity protection for the Register and Register-Stop unicast
messages. messages.
6.3.2.1. Register messages 6.3.2.1. Register messages
The Security Policy Database at every PIM router is configured to select The Security Policy Database at every PIM router is configured to select
a Security Association to use when sending PIM Register packets to each a Security Association to use when sending PIM Register packets to each
rendezvous point. rendezvous point.
In the most general mode of operation, the Security Policy Database at In the most general mode of operation, the Security Policy Database at
skipping to change at page 139, line 32 skipping to change at page 139, line 25
- Sending packets to many different group addresses quickly can be a - Sending packets to many different group addresses quickly can be a
denial of service attack in and of itself. This will cause many denial of service attack in and of itself. This will cause many
register-encapsulated packets, loading the DR, the RP, and the register-encapsulated packets, loading the DR, the RP, and the
routers between the DR and the RP. routers between the DR and the RP.
- Forging Join messages can cause a multicast tree to get set up. A - Forging Join messages can cause a multicast tree to get set up. A
large number of forged joins can consume router resources and large number of forged joins can consume router resources and
result in denial of service. result in denial of service.
- The (*,*,RP) forwarding model has some unique security concerns.
In particular, a (*,*,RP) join presents a possibility for a denial
of service attack by causing all traffic in the domain to flow to
the PMBR issuing the join. (*,*,RP) behavior is included here
primarily for backwards compatibility with prior revisions of the
spec. However, the implementation of (*,*,RP) and PMBR is
optional. When using (*,*,RP), the security concerns should be
carefully considered.
7. Authors' Addresses 7. Authors' Addresses
Bill Fenner Bill Fenner
AT&T Labs - Research AT&T Labs - Research
75 Willow Road 75 Willow Road
Menlo Park, CA 94025 Menlo Park, CA 94025
fenner@research.att.com fenner@research.att.com
Mark Handley Mark Handley
Department of Computer Science Department of Computer Science
University College London University College London
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
United Kingdom United Kingdom
M.Handley@cs.ucl.ac.uk M.Handley@cs.ucl.ac.uk
Hugh Holbrook Hugh Holbrook
Cisco Systems Arastra, Inc.
170 W. Tasman Drive P.O. Box 10905
San Jose, CA 95134 Palo Alto, CA 94303
holbrook@cisco.com holbrook@arastra.com
Isidor Kouvelas Isidor Kouvelas
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
kouvelas@cisco.com kouvelas@cisco.com
8. Acknowledgments 8. Acknowledgments
PIM-SM was designed over many years by a large group of people, PIM-SM was designed over many years by a large group of people,
skipping to change at page 140, line 32 skipping to change at page 140, line 32
Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly
Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian
Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike
Davison, James Huang, Christopher Thomas Brown, and James Lingard. Davison, James Huang, Christopher Thomas Brown, and James Lingard.
Thanks are due to the American Licorice Company, for its obscure but Thanks are due to the American Licorice Company, for its obscure but
possibly essential role in the creation of this document. possibly essential role in the creation of this document.
9. Normative References 9. Normative References
[1] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
"Internet Group Management Protocol, Version 3", RFC 3376. Levels", BCP 14, RFC 2119, March 1997.
[2] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan,
1989. "Internet Group Management Protocol, Version 3", RFC 3376, October
2002.
[3] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery [3] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112,
(MLD) for IPv6", RFC 2710. August 1989.
[4] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) [4] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Specification", RFC 2460. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[5] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft- [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
ietf-ssm-arch-04.txt, work in progress. Specification", RFC 2460, December 1998.
[6] IANA, "Address Family Numbers", linked from [6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", draft-
ietf-ssm-arch, work in progress.
[7] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
[7] S. Kent, R. Atkinson, "Security Architecture for the Internet [8] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol.", RFC 2401. Protocol", RFC 4301, December 2005.
[8] T. Narten , H. Alvestrand, "Guidelines for Writing an IANA [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
10. Informative References 10. Informative References
[9] T. Bates , R. Chandra , D. Katz , Y. Rekhter, "Multiprotocol [10] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2283 Extensions for BGP-4", draft-ietf-idr-rfc2858bis, work in progress.
[10] D. Black, "Differentiated Services and Tunnels", RFC 2983. [11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap
Router (BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr,
work in progress.
[11] W. Fenner, M. Handley, R. Kermode, D. Thaler, "Bootstrap Router [12] Black, D., "Differentiated Services and Tunnels", RFC 2983, October
(BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, 2000.
[13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-
directional Protocol Independent Multicast", draft-ietf-pim-bidir,
work in progress. work in progress.
[12] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional [14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC
Protocol Independent Multicast", draft-ietf-pim-bidir-05.txt, work 2409, November 1998.
in progress.
[13] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)", RFC [15] P. Savola, R. Lehtonen, D. Meyer, "PIM-SM Multicast Routing
2409. Security Issues and Enhancements", draft-savola-mboned-
mroutesec-00.txt, work in progress.
[14] S. Kent, "IP Encapsulating Security Payload (ESP)", draft-ietf- [16] P. Savola, J. Lingard, "Last-hop Threats to Protocol Independent
ipsec-esp-v3-06.txt, work in progress. Multicast (PIM)" draft-savola-pim-lasthop-threats-01.txt, work in
progress.
[15] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP) [17] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP)
Address in an IPv6 Multicast Address" draft-ietf-mboned- Address in an IPv6 Multicast Address" draft-ietf-mboned-embeddedrp,
embeddedrp-04.txt, work in progress. work in progress.
[16] D. Thaler, "Interoperability Rules for Multicast Routing [18] Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", RFC 2715. Protocols", RFC 2715, October 1999.
11. Appendix A: PIM Multicast Border Router Behavior 11. Appendix A: PIM Multicast Border Router Behavior
In some cases PIM-SM domains will interconnect with non-PIM multicast In some cases PIM-SM domains will interconnect with non-PIM multicast
domains. In these cases, the border routers of the PIM domain speak domains. In these cases, the border routers of the PIM domain speak
PIM-SM on some interfaces and speak other multicast routing protocols on PIM-SM on some interfaces and speak other multicast routing protocols on
other interfaces. Such routers are termed PIM Multicast Border Routers other interfaces. Such routers are termed PIM Multicast Border Routers
or PMBRs. In general, RFC 2715 [16] provides rules for interoperability or PMBRs. In general, RFC 2715 [18] provides rules for interoperability
between different multicast routing protocols. In this section we between different multicast routing protocols. In this section we
specify how PMBRs differ from regular PIM-SM routers. specify how PMBRs differ from regular PIM-SM routers.
From the point of view of PIM-SM, a PMBR has two tasks: From the point of view of PIM-SM, a PMBR has two tasks:
o To ensure that traffic from sources outside the PIM-SM domain reaches o To ensure that traffic from sources outside the PIM-SM domain reaches
receivers inside the domain. receivers inside the domain.
o To ensure that traffic from sources inside the PIM-SM domain reaches o To ensure that traffic from sources inside the PIM-SM domain reaches
receivers outside the domain. receivers outside the domain.
skipping to change at page 145, line 6 skipping to change at page 145, line 6
o If the router receives a (*,G) prune alert, it will need to set o If the router receives a (*,G) prune alert, it will need to set
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface for all DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface for all
active sources sending to G. active sources sending to G.
The rationale for this is that there is no way in PIM-SM to prune The rationale for this is that there is no way in PIM-SM to prune
traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and then traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and then
pruning each source individually. pruning each source individually.
12. Index 12. Index
Address_List . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Assert(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .27,127 Assert(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .27,127
Assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .27,127 Assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .27,127
AssertCancel(*,G). . . . . . . . . . . . . . . . . . . . . . . . . 97,99 AssertCancel(*,G). . . . . . . . . . . . . . . . . . . . . . . . . 97,99
AssertCancel(S,G). . . . . . . . . . . . . . . . . . . . . . . .79,90,99 AssertCancel(S,G). . . . . . . . . . . . . . . . . . . . . . . .79,90,99
AssertTimer(*,G,I) . . . . . . . . . . . . . . . . . . . . .16,25,91,131 AssertTimer(*,G,I) . . . . . . . . . . . . . . . . . . . . .17,25,91,131
AssertTimer(S,G,I) . . . . . . . . . . . . . . . . . . . . .18,25,83,131 AssertTimer(S,G,I) . . . . . . . . . . . . . . . . . . . . .18,25,83,131
AssertTrackingDesired(*,G,I) . . . . . . . . . . . . . . . . . .93,94,96 AssertTrackingDesired(*,G,I) . . . . . . . . . . . . . . . . . .93,94,96
AssertTrackingDesired(S,G,I) . . . . . . . . . . . . . . . . 85,85,87,89 AssertTrackingDesired(S,G,I) . . . . . . . . . . . . . . . . 85,85,87,89
AssertWinner(*,G,I). . . . . . . . . . . . . . . . . .17,22,25,93,97,100 AssertWinner(*,G,I). . . . . . . . . . . . . . . . . .17,23,25,93,97,100
AssertWinner(S,G,I). . . . . . . . . . . . . . . . 18,23,25,85,89,99,100 AssertWinner(S,G,I). . . . . . . . . . . . . . . . 18,23,25,85,89,99,100
AssertWinnerMetric(*,G,I). . . . . . . . . . . . . . . . . . . 17,97,100 AssertWinnerMetric(*,G,I). . . . . . . . . . . . . . . . . . . 17,97,100
AssertWinnerMetric(S,G,I). . . . . . . . . . . . . . . . . . . 18,89,100 AssertWinnerMetric(S,G,I). . . . . . . . . . . . . . . . . . . 18,89,100
assert_metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 assert_metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Assert_Override_Interval . . . . . . . . . . . . . . . . . . . 89,96,131 Assert_Override_Interval . . . . . . . . . . . . . . . . . . . 89,96,131
Assert_Time. . . . . . . . . . . . . . . . . . . . . . . . . . 89,96,131 Assert_Time. . . . . . . . . . . . . . . . . . . . . . . . . . 89,96,131
AT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . .16,25,91,128,131 AT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . .17,25,91,128,131
AT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . .18,25,83,128,131 AT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . .18,25,83,128,131
CheckSwitchToSpt(S,G). . . . . . . . . . . . . . . . . . . . . . . 27,28 CheckSwitchToSpt(S,G). . . . . . . . . . . . . . . . . . . . . . . 27,28
CouldAssert(*,G,I) . . . . . . . . . . . . . . . . . . . .91,93,94,95,98 CouldAssert(*,G,I) . . . . . . . . . . . . . . . . . . . .91,93,94,95,98
CouldAssert(S,G,I) . . . . . . . . . . . . . . . . . . 83,85,87,88,89,98 CouldAssert(S,G,I) . . . . . . . . . . . . . . . . . . 83,85,87,88,89,98
CouldRegister(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 38,40 CouldRegister(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 38,40
Default_Hello_Holdtime . . . . . . . . . . . . . . . . . . . . . . . 33 Default_Hello_Holdtime . . . . . . . . . . . . . . . . . . . . . . . 33
DirectlyConnected(S) . . . . . . . . . . . . . . . . . . 27,27,29,40,142 DirectlyConnected(S) . . . . . . . . . . . . . . . . . . 27,27,29,40,142
DownstreamJPState(*,*,RP,I). . . . . . . . . . . . . . . . . . . .23,144 DownstreamJPState(*,*,RP,I). . . . . . . . . . . . . . . . . . . .23,144
DownstreamJPState(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 23 DownstreamJPState(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 23
DownstreamJPState(S,G,I) . . . . . . . . . . . . . . . . . . . . . 24,40 DownstreamJPState(S,G,I) . . . . . . . . . . . . . . . . . . . . . 24,40
DownstreamJPState(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . 24 DownstreamJPState(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . 24
DR(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 DR(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
dr_is_better(a,b,I). . . . . . . . . . . . . . . . . . . . . . . . 33,33 dr_is_better(a,b,I). . . . . . . . . . . . . . . . . . . . . . . . 33,33
DR_Priority. . . . . . . . . . . . . . . . . . . . . . . . . . .31,32,33 DR_Priority. . . . . . . . . . . . . . . . . . . . . . . . . . .31,32,33
Effective_Override_Interval(I) . . . . . . . . . . . . . . . .36,113,131 Effective_Override_Interval(I) . . . . . . . . . . . . . . . .36,113,131
Effective_Propagation_Delay(I) . . . . . . . . . . . . . . . . . .35,131 Effective_Propagation_Delay(I) . . . . . . . . . . . . . . . . . .35,131
ET(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . . . 15,46,127,130 ET(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . . . 15,46,127,130
ET(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . . 16,49,128,130 ET(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . . 17,49,128,130
ET(S,G,I). . . . . . . . . . . . . . . . . . . . . . . . . 18,53,128,130 ET(S,G,I). . . . . . . . . . . . . . . . . . . . . . . . . 18,53,128,130
ET(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . . .21,56,58,128,130 ET(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . . .21,56,58,128,130
GenID. . . . . . . . . . . . . . . . . . . 16,18,20,31,63,67,70,72,83,91 GenID. . . . . . . . . . . . . . . . . . . 16,18,20,31,63,67,70,72,83,91
Hash_Function. . . . . . . . . . . . . . . . . . . . . . . . . . .13,105 Hash_Function. . . . . . . . . . . . . . . . . . . . . . . . . . .13,105
Hello_Holdtime . . . . . . . . . . . . . . . . . . . . . . . . . .33,130 Hello_Holdtime . . . . . . . . . . . . . . . . . . . . . . . . . .33,130
Hello_Period . . . . . . . . . . . . . . . . . . . . . . . . . . .31,129 Hello_Period . . . . . . . . . . . . . . . . . . . . . . . . . . .31,129
HT(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31,129 HT(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31,129
IGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7,9,17,23,101,104 IGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7,9,17,23,101,104
immediate_olist(*,*,RP). . . . . . . . . . . . . . . . . . . . . . 22,63 immediate_olist(*,*,RP). . . . . . . . . . . . . . . . . . . . . . 22,63
immediate_olist(*,G) . . . . . . . . . . . . . . . . . . . . . . . 22,68 immediate_olist(*,G) . . . . . . . . . . . . . . . . . . . . . . . 22,68
immediate_olist(S,G) . . . . . . . . . . . . . . . . . . . . . .22,40,72 immediate_olist(S,G) . . . . . . . . . . . . . . . . . . . . . .22,40,72
infinite_assert_metric() . . . . . . . . . . . . . . . . . . . . . . 98 infinite_assert_metric() . . . . . . . . . . . . . . . . . . . . . . 98
inherited_olist(S,G) . . . . . . . . . . . . . . . . .22,27,43,72,85,107
inherited_olist(S,G) . . . . . . . . . . . . . . . 22,27,40,43,72,85,107
inherited_olist(S,G,rpt) . . . . . . . . . . . . . . . 22,27,29,76,78,80 inherited_olist(S,G,rpt) . . . . . . . . . . . . . . . 22,27,29,76,78,80
Interface_Address_List . . . . . . . . . . . . . . . . . . . . . . . 31
I_Am_Assert_Loser(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 25 I_Am_Assert_Loser(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 25
I_Am_Assert_Loser(S,G,I) . . . . . . . . . . . . . . . . . . . . . . 25 I_Am_Assert_Loser(S,G,I) . . . . . . . . . . . . . . . . . . . . . . 25
I_am_DR(I) . . . . . . . . . . . . . . . . . . . . . . . .22,33,40,85,93 I_am_DR(I) . . . . . . . . . . . . . . . . . . . . . . . .23,33,40,85,93
I_am_RP(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43,44 I_am_RP(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43,44
J/P_Holdtime . . . . . . . . . . . . . .47,50,54,58,64,69,74,120,130,132 J/P_Holdtime . . . . . . . . . . . . . .47,50,54,58,64,69,74,120,130,132
J/P_Override_Interval(I) . . . . . . . . . . . . . . 47,51,54,58,120,131 J/P_Override_Interval(I) . . . . . . . . . . . . . . 47,51,54,58,120,131
JoinDesired(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 63,77 JoinDesired(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 63,77
JoinDesired(*,G) . . . . . . . . . . . . . . . . . . . . .17,68,77,85,97 JoinDesired(*,G) . . . . . . . . . . . . . . . . . . . . .17,68,77,85,97
JoinDesired(S,G) . . . . . . . . . . . . . . . . . . . 19,29,72,85,88,90 JoinDesired(S,G) . . . . . . . . . . . . . . . . . . . 19,29,72,85,88,90
joins(*,*,RP(G)) . . . . . . . . . . . . . . . . . . . . . . . . . . 22 joins(*,*,RP(G)) . . . . . . . . . . . . . . . . . . . . . . . . . . 22
joins(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 22,23,85,93 joins(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 22,23,85,93
joins(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 22,23,85,93 joins(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 22,23,85,93
joins(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . .22,24,85 joins(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . .22,24,85
JT(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . . . 15,61,128,132 JT(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . . . 16,61,128,132
JT(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 17,66,128,132 JT(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 17,66,128,132
JT(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . 18,71,128,132 JT(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . 19,71,128,132
KAT(S,G) . . . . . . . . . . . . . . . .19,26,27,28,40,43,72,107,128,133 KAT(S,G) . . . . . . . . . . . . . . . .19,26,27,28,40,43,72,107,128,133
KeepaliveTimer(S,G). . . . . . . . . 19,26,27,27,28,40,43,72,107,128,133 KeepaliveTimer(S,G). . . . . . . . . 19,26,27,27,28,40,43,72,107,128,133
Keepalive_Period . . . . . . . . . . . . . . . . . . . . . . . . .27,133 Keepalive_Period . . . . . . . . . . . . . . . . . . . . . . . . .27,133
lan_delay_enabled(I) . . . . . . . . . . . . . . . . . . . . . . . 35,36 lan_delay_enabled(I) . . . . . . . . . . . . . . . . . . . . . . . 35,36
LAN_Prune_Delay. . . . . . . . . . . . . . . . . . . . . . . . . . . 31 LAN_Prune_Delay. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
local_receiver_exclude(S,G,I). . . . . . . . . . . . . . . . . . . . 23 local_receiver_exclude(S,G,I). . . . . . . . . . . . . . . . . . . . 23
local_receiver_include(*,G,I). . . . . . . . . . . . . . . . . 23,93,143 local_receiver_include(*,G,I). . . . . . . . . . . . . . . . . 23,93,143
local_receiver_include(S,G,I). . . . . . . . . . . . . . . . . . . 23,85 local_receiver_include(S,G,I). . . . . . . . . . . . . . . . . . . 23,85
local_receiver_include(S,G,I). . . . . . . . . . . . . . . . . . . . 143 local_receiver_include(S,G,I). . . . . . . . . . . . . . . . . . . . 143
lost_assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . .22,24,85 lost_assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . .22,24,85
lost_assert(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 22,24,100 lost_assert(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 23,24,100
lost_assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 22,24 lost_assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 22,24
lost_assert(S,G,I) . . . . . . . . . . . . . . . . . . . . . . .23,24,99 lost_assert(S,G,I) . . . . . . . . . . . . . . . . . . . . . . .23,24,99
lost_assert(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . . . 24 lost_assert(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . . . 24
lost_assert(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . . . 24,99 lost_assert(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . . . 24,99
MBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7,8 MBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7,8
MFIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7,14 MFIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7,14
MLD. . . . . . . . . . . . . . . . . . . . . . . . . . 7,9,17,23,101,104 MLD. . . . . . . . . . . . . . . . . . . . . . . . . . 7,9,17,23,101,104
MRIB . . . . . . . . . . . . . . .7,8,12,16,20,25,61,65,65,75,98,102,127 MRIB . . . . . . . . . . . . . . .7,8,12,16,20,25,61,65,65,75,98,102,127
MRIB.next_hop(host). . . . . . . . . . . . . . . . . . . . . 25,25,61,63 MRIB.next_hop(host). . . . . . . . . . . . . . . . . . . . . 25,25,61,63
my_assert_metric(S,G,I). . . . . . . . . . . . . . . . . .85,89,91,93,98 my_assert_metric(*,G,I). . . . . . . . . . . . . . . . . . . . . . . 93
my_assert_metric(S,G,I). . . . . . . . . . . . . . . . . . . 85,89,91,98
NBR(Interface,IP_address). . . . . . . . . . . . . . . . .26,37,61,63,65 NBR(Interface,IP_address). . . . . . . . . . . . . . . . .26,37,61,63,65
NLT(N,I) . . . . . . . . . . . . . . . . . . . . . . . . . 15,33,127,130 NLT(N,I) . . . . . . . . . . . . . . . . . . . . . . . . . 15,33,127,130
OT(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . 21,76,128,133 OT(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . 21,76,128,133
Override_Interval(I) . . . . . . . . . . . . . . 14,31,34,36,113,129,131 Override_Interval(I) . . . . . . . . . . . . . . 15,31,34,36,113,129,131
packet_arrives_on_rp_tunnel(pkt) . . . . . . . . . . . . . . . . . . 43 packet_arrives_on_rp_tunnel(pkt) . . . . . . . . . . . . . . . . . . 43
pim_exclude(S,G) . . . . . . . . . . . . . . . . . . . . . . 22,23,28,85 pim_exclude(S,G) . . . . . . . . . . . . . . . . . . . . . . 22,23,28,85
pim_include(*,G) . . . . . . . . . . . . . . . . . . . 17,22,22,28,85,93 pim_include(*,G) . . . . . . . . . . . . . . . . . . . 17,22,23,28,85,93
pim_include(S,G) . . . . . . . . . . . . . . . . . . . . .19,22,23,28,85 pim_include(S,G) . . . . . . . . . . . . . . . . . . . . .19,22,23,28,85
PPT(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . . 15,46,127,131
PPT(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . . 15,46,127,131
PPT(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . 16,49,128,131 PPT(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . 16,49,128,131
PPT(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . 18,53,128,131 PPT(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . 18,53,128,131
PPT(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . .21,56,58,128,131 PPT(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . .21,56,58,128,131
Propagation_Delay(I) . . . . . . . . . . . . . . . . . . . 31,35,129,131 Propagation_Delay(I) . . . . . . . . . . . . . . . . . . . 31,35,129,131
Propagation_delay_default. . . . . . . . . . . . . . . . . . . . .35,129 Propagation_delay_default. . . . . . . . . . . . . . . . . . . . .35,129
PruneDesired(S,G,rpt). . . . . . . . . . . . . . . . . . . . 78,79,88,90 PruneDesired(S,G,rpt). . . . . . . . . . . . . . . . . . . . 78,79,88,90
prunes(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . .22,24,85 prunes(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . .22,24,85
Register-Stop(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 41 Register-Stop(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 41
Register-Stop(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 43 Register-Stop(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 43
Register-StopTimer(S,G). . . . . . . . . . . . . . . . . . 38,39,128,133 Register-StopTimer(S,G). . . . . . . . . . . . . . . . . . 38,39,128,133
skipping to change at page 148, line 29 skipping to change at page 148, line 29
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf- standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to Copyright (C) The Internet Society (2006). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 289 change blocks. 
421 lines changed or deleted 373 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/