draft-ietf-pim-sm-v2-new-10.txt   draft-ietf-pim-sm-v2-new-11.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-10.txt Mark Handley/UCL draft-ietf-pim-sm-v2-new-11.txt Mark Handley/UCL
Hugh Holbrook/Cisco Hugh Holbrook/Cisco
Isidor Kouvelas/Cisco Isidor Kouvelas/Cisco
18 July 2004 25 October 2004
Expires: January 2005 Expires: April 2005
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, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or will be or other IPR claims of which I am aware have been disclosed, or will be
disclosed, and any of which I become aware will be disclosed, in disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668. accordance with RFC 3668.
skipping to change at page 3, line 22 skipping to change at page 3, line 22
4. Protocol Specification. . . . . . . . . . . . . . . . . 13 4. Protocol Specification. . . . . . . . . . . . . . . . . 13
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . 13 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . 13
4.1.1. General Purpose State . . . . . . . . . . . . . . 14 4.1.1. General Purpose State . . . . . . . . . . . . . . 14
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 . . . . . . 28 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
4.3.2. DR Election . . . . . . . . . . . . . . . . . . . 32 4.3.2. DR Election . . . . . . . . . . . . . . . . . . . 32
4.3.3. Reducing Prune Propagation Delay on LANs. . . . . 34 4.3.3. Reducing Prune Propagation Delay on LANs. . . . . 34
4.3.4. Maintaining Secondary Address Lists . . . . . . . 36 4.3.4. Maintaining Secondary Address Lists . . . . . . . 37
4.4. PIM Register Messages. . . . . . . . . . . . . . . . 37 4.4. PIM Register Messages. . . . . . . . . . . . . . . . 38
4.4.1. Sending Register Messages from the DR . . . . . . 38 4.4.1. Sending Register Messages from the DR . . . . . . 38
4.4.2. Receiving Register Messages at the RP . . . . . . 42 4.4.2. Receiving Register Messages at the RP . . . . . . 42
4.5. PIM Join/Prune Messages. . . . . . . . . . . . . . . 44 4.5. PIM Join/Prune Messages. . . . . . . . . . . . . . . 44
4.5.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . 45 4.5.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . 45
4.5.2. Receiving (*,G) Join/Prune Messages . . . . . . . 49 4.5.2. Receiving (*,G) Join/Prune Messages . . . . . . . 49
4.5.3. Receiving (S,G) Join/Prune Messages . . . . . . . 52 4.5.3. Receiving (S,G) Join/Prune Messages . . . . . . . 52
4.5.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . 55 4.5.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . 55
4.5.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . 61 4.5.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . 61
4.5.6. Sending (*,G) Join/Prune Messages . . . . . . . . 65 4.5.6. Sending (*,G) Join/Prune Messages . . . . . . . . 65
4.5.7. Sending (S,G) Join/Prune Messages . . . . . . . . 70 4.5.7. Sending (S,G) Join/Prune Messages . . . . . . . . 70
skipping to change at page 6, line 46 skipping to change at page 6, line 46
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):
A shared-media LAN like Ethernet may have multiple PIM-SM routers | A shared-media LAN like Ethernet may have multiple PIM-SM routers
connected to it. A single one of these routers, the DR, will act | connected to it. A single one of these routers, the DR, will act
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.
skipping to change at page 9, line 46 skipping to change at page 9, line 46
Phase Two: Register-Stop Phase Two: Register-Stop
Register-encapsulation of data packets is inefficient for two reasons: Register-encapsulation of data packets is inefficient for two reasons:
o Encapsulation and decapsulation may be relatively expensive operations o Encapsulation and decapsulation may be relatively expensive operations
for a router to perform, depending on whether or not the router has for a router to perform, depending on whether or not the router has
appropriate hardware for these tasks. appropriate hardware for these tasks.
o Traveling all the way to the RP, and then back down the shared tree o Traveling all the way to the RP, and then back down the shared tree
may entail the packets traveling a relatively long distance to reach may entail the packets traveling a relatively long distance to reach
receivers that are close to the sender. For some applications, this | receivers that are close to the sender. For some applications, this
increased latency or bandwidth consumption is undesirable. increased latency or bandwidth consumption is undesirable.
Although Register-encapsulation may continue indefinitely, for these Although Register-encapsulation may continue indefinitely, for these
reasons, the RP will normally choose to switch to native forwarding. To reasons, the RP will normally choose to switch to native forwarding. To
do this, when the RP receives a register-encapsulated data packet from do this, when the RP receives a register-encapsulated data packet from
source S on group G, it will normally initiate an (S,G) source-specific source S on group G, it will normally initiate an (S,G) source-specific
Join towards S. This Join message travels hop-by-hop towards S, Join towards S. This Join message travels hop-by-hop towards S,
instantiating (S,G) multicast tree state in the routers along the path. instantiating (S,G) multicast tree state in the routers along the path.
(S,G) multicast tree state is used only to forward packets for group G (S,G) multicast tree state is used only to forward packets for group G
skipping to change at page 10, line 42 skipping to change at page 10, line 42
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 utilisation, 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
skipping to change at page 11, line 47 skipping to change at page 11, line 47
Source-specific Prunes Source-specific Prunes
IGMPv3 also permits a receiver to join a group and specify that it only IGMPv3 also permits a receiver to join a group and specify that it only
wants to receive traffic for a group if that traffic does not come from wants to receive traffic for a group if that traffic does not come from
a specific source or sources. In this case, the DR will perform a (*,G) a specific source or sources. In this case, the DR will perform a (*,G)
join as normal, but may combine this with an (S,G,rpt) prune for each of join as normal, but may combine this with an (S,G,rpt) prune for each of
the sources the receiver does not wish to receive. the sources the receiver does not wish to receive.
Multi-access Transit LANs Multi-access Transit LANs
The overview so far has concerned itself with point-to-point transit | The overview so far has concerned itself with point-to-point transit
links. However, using multi-access LANs such as Ethernet for transit is links. However, using multi-access LANs such as Ethernet for transit is
not uncommon. This can cause complications for three reasons: not uncommon. This can cause complications for three reasons:
o Two or more routers on the LAN may issue (*,G) Joins to different o Two or more routers on the LAN may issue (*,G) Joins to different
upstream routers on the LAN because they have inconsistent MRIB upstream routers on the LAN because they have inconsistent MRIB
entries regarding how to reach the RP. Both paths on the RP tree will entries regarding how to reach the RP. Both paths on the RP tree will
be set up, causing two copies of all the shared tree traffic to appear be set up, causing two copies of all the shared tree traffic to appear
on the LAN. on the LAN.
o Two or more routers on the LAN may issue (S,G) Joins to different o Two or more routers on the LAN may issue (S,G) Joins to different
skipping to change at page 12, line 41 skipping to change at page 12, line 41
router has (S,G) state, then in favor of the router with the best metric router has (S,G) state, then in favor of the router with the best metric
to the RP for RP trees, or the best metric to the source to source- to the RP for RP trees, or the best metric to the source to source-
specific trees. specific trees.
These Assert messages are also received by the downstream routers on the These Assert messages are also received by the downstream routers on the
LAN, and these cause subsequent Join messages to be sent to the upstream LAN, and these cause subsequent Join messages to be sent to the upstream
router that won the Assert. router that won the Assert.
RP Discovery RP Discovery
PIM-SM routers need to know the address of the RP for each group for | PIM-SM routers need to know the address of the RP for each group for
which they have (*,G) state. This address is obtained either | which they have (*,G) state. This address is obtained either
automatically (e.g., embedded-RP), through a bootstrap mechanism or | automatically (e.g., embedded-RP), through a bootstrap mechanism or
through static configuration. through static configuration.
One dynamic way to do this is to use the Bootstrap Router (BSR) One dynamic way to do this is to use the Bootstrap Router (BSR)
mechanism [11]. One router in each PIM domain is elected the Bootstrap mechanism [11]. One router in each PIM domain is elected the Bootstrap
Router through a simple election process. All the routers in the domain Router through a simple election process. All the routers in the domain
that are configured to be candidates to be RPs periodically unicast that are configured to be candidates to be RPs periodically unicast
their candidacy to the BSR. From the candidates, the BSR picks an RP- their candidacy to the BSR. From the candidates, the BSR picks an RP-
set, and periodically announces this set in a Bootstrap message. set, and periodically announces this set in a Bootstrap message.
Bootstrap messages are flooded hop-by-hop throughout the domain until Bootstrap messages are flooded hop-by-hop throughout the domain until
skipping to change at page 13, line 41 skipping to change at page 13, line 41
o Section 4.7 specifies the RP discovery mechanisms. o Section 4.7 specifies the RP discovery mechanisms.
o The subset of PIM required to support Source-Specific Multicast, PIM- o The subset of PIM required to support Source-Specific Multicast, PIM-
SSM, is described in Section 4.8. SSM, is described in Section 4.8.
o PIM packet formats are specified in Section 4.9. o PIM packet formats are specified in Section 4.9.
o A summary of PIM-SM timers and their default values is given in o A summary of PIM-SM timers and their default values is given in
Section 4.10. Section 4.10.
o Appendix A in Section 11 specifies the PIM Multicast Border Router | o Appendix A in Section 11 specifies the PIM Multicast Border Router
behavior. behavior.
4.1. PIM Protocol State 4.1. PIM Protocol State
This section specifies all the protocol state that a PIM implementation This section specifies all the protocol state that a PIM implementation
should maintain in order to function correctly. We term this state the should maintain in order to function correctly. We term this state the
Tree Information Base or TIB, as it holds the state of all the multicast Tree Information Base or TIB, as it holds the state of all the multicast
distribution trees at this router. In this specification we define PIM distribution trees at this router. In this specification we define PIM
mechanisms in terms of the TIB. However, only a very simple mechanisms in terms of the TIB. However, only a very simple
implementation would actually implement packet forwarding operations in implementation would actually implement packet forwarding operations in
skipping to change at page 15, line 12 skipping to change at page 15, line 12
o 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 Override Interval, the Propagation Delay and the Interface
skipping to change at page 17, line 4 skipping to change at page 17, line 4
o Prune-Pending Timer (PPT) o Prune-Pending Timer (PPT)
o Join/Prune Expiry Timer (ET) o Join/Prune Expiry Timer (ET)
(*,G) Assert Winner State (*,G) Assert Winner State
o State: One of {"NoInfo" (NI), "I lost Assert" (L), o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)} "I won Assert" (W)}
o Assert Timer (AT) o Assert Timer (AT)
o Assert winner's IP Address (AssertWinner) | o Assert winner's IP Address (AssertWinner)
o Assert winner's Assert Metric (AssertWinnerMetric) o Assert winner's Assert Metric (AssertWinnerMetric)
Not interface specific: Not interface specific:
Upstream (*,G) Join/Prune State: Upstream (*,G) Join/Prune State:
o State: One of {"NotJoined(*,G)", "Joined(*,G)"} o State: One of {"NotJoined(*,G)", "Joined(*,G)"}
o Upstream Join/Prune Timer (JT) o Upstream Join/Prune Timer (JT)
skipping to change at page 18, line 41 skipping to change at page 18, line 41
o Join/Prune Expiry Timer (ET) o Join/Prune Expiry Timer (ET)
(S,G) Assert Winner State (S,G) Assert Winner State
o State: One of {"NoInfo" (NI), "I lost Assert" (L), o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)} "I won Assert" (W)}
o Assert Timer (AT) o Assert Timer (AT)
o Assert winner's IP Address (AssertWinner) | o Assert winner's IP Address (AssertWinner)
o Assert winner's Assert Metric (AssertWinnerMetric) o Assert winner's Assert Metric (AssertWinnerMetric)
Not interface specific: Not interface specific:
Upstream (S,G) Join/Prune State: Upstream (S,G) Join/Prune State:
o State: One of {"NotJoined(S,G)", "Joined(S,G)"} o State: One of {"NotJoined(S,G)", "Joined(S,G)"}
o Upstream (S,G) Join/Prune Timer (JT) o Upstream (S,G) Join/Prune Timer (JT)
o Last RPF Neighbor towards S that was used o Last RPF Neighbor towards S that was used
o SPTbit (indicates (S,G) state is active) | o SPTbit (indicates (S,G) state is active)
o (S,G) Keepalive Timer (KAT) o (S,G) Keepalive Timer (KAT)
Additional (S,G) state at the DR: Additional (S,G) state at the DR:
o Register state: One of {"Join" (J), "Prune" (P), o Register state: One of {"Join" (J), "Prune" (P),
"Join-Pending" (JP), "NoInfo" (NI)} "Join-Pending" (JP), "NoInfo" (NI)}
o Register-Stop timer o Register-Stop timer
Additional (S,G) state at the RP: | Additional (S,G) state at the RP:
o PMBR: the first PMBR to send a Register for this | o PMBR: the first PMBR to send a Register for this
source with the Border bit set. | source with the Border bit set.
Local membership is the result of the local source-specific membership Local membership is the result of the local source-specific membership
mechanism (such as IGMP version 3) running on that interface and mechanism (such as IGMP version 3) running on that interface and
specifying that this particular source should be included. As stored specifying that this particular source should be included. As stored
here, this state is the resulting state after any IGMPv3 inconsistencies here, this state is the resulting state after any IGMPv3 inconsistencies
have been resolved. It need not be kept if this router is not the DR on have been resolved. It need not be kept if this router is not the DR on
that interface unless this router won a (S,G) assert on this interface that interface unless this router won a (S,G) assert on this interface
for this group. However, we recommend storing this information if for this group. However, we recommend storing this information if
possible, as it reduces latency converging to stable operating possible, as it reduces latency converging to stable operating
conditions after a failure causing a change of DR. This information is conditions after a failure causing a change of DR. This information is
skipping to change at page 20, line 32 skipping to change at page 20, line 32
absence of explicit (S,G) Joins. Amongst other things, this is absence of explicit (S,G) Joins. Amongst other things, this is
necessary for the so-called "turnaround rules" - when the RP uses (S,G) necessary for the so-called "turnaround rules" - when the RP uses (S,G)
joins to stop encapsulation, and then (S,G) prunes to prevent traffic joins to stop encapsulation, and then (S,G) prunes to prevent traffic
from unnecessarily reaching the RP. from unnecessarily reaching the RP.
On a DR, the (S,G) Register State is used to keep track of whether to On a DR, the (S,G) Register State is used to keep track of whether to
encapsulate data to the RP on the Register Tunnel; the (S,G) Register- encapsulate data to the RP on the Register Tunnel; the (S,G) Register-
Stop timer tracks how long before encapsulation begins again for a given Stop timer tracks how long before encapsulation begins again for a given
(S,G). (S,G).
On an RP, the PMBR value must be cleared when the Keepalive Timer | On an RP, the PMBR value must be cleared when the Keepalive Timer
expires. expires.
4.1.5. (S,G,rpt) State 4.1.5. (S,G,rpt) State
For every source/group pair (S,G) for which a router also has (*,G) For every source/group pair (S,G) for which a router also has (*,G)
state, it also keeps the following state: state, it also keeps the following state:
(S,G,rpt) state: (S,G,rpt) state:
For each interface: For each interface:
skipping to change at page 22, line 34 skipping to change at page 22, line 34
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) (+) immediate_olist(S,G) inherited_olist(S,G,rpt) (+) |
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) =
{ all interfaces I such that: { all interfaces I such that:
skipping to change at page 23, line 4 skipping to change at page 23, line 5
requested traffic on a group or source/group pair. requested traffic on a group or source/group pair.
pim_include(*,G) = pim_include(*,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_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(S,G,I) == FALSE ) ( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE ) |
OR AssertWinner(S,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 there are module or other local membership mechanism has determined that local |
local members on interface I that desire to receive traffic sent members on interface I desire to receive traffic sent specifically by S
specifically by S to G. "local_receiver_include(*,G,I)" is true if the to G. "local_receiver_include(*,G,I)" is true if the IGMP/MLD module or
IGMP/MLD module or other local membership mechanism has determined that other local membership mechanism has determined that local members on |
there are local members on interface I that desire to receive all interface I desire to receive all traffic sent to G (possibly excluding |
traffic sent to G. "local_receiver_exclude(S,G,I) is true if traffic from a specific set of sources). "local_receiver_exclude(S,G,I) |
"local_receiver_include(*,G,I)" is true but none of the local members is true if "local_receiver_include(*,G,I)" is true but none of the local
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 }
DownstreamJPState(*,*,RP,I) is the state of the finite state machine in DownstreamJPState(*,*,RP,I) is the state of the finite state machine in
skipping to change at page 25, line 48 skipping to change at page 25, line 48
messages that we send to RPF'(*,G) (See Section 4.5.8). messages that we send to RPF'(*,G) (See Section 4.5.8).
The function MRIB.next_hop( S ) returns an address of the next-hop PIM The function MRIB.next_hop( S ) returns an address of the next-hop PIM
neighbor toward the host S, as indicated by the current MRIB. If S is neighbor toward the host S, as indicated by the current MRIB. If S is
directly adjacent, then MRIB.next_hop( S ) returns NULL. At the RP for directly adjacent, then MRIB.next_hop( S ) returns NULL. At the RP for
G, MRIB.next_hop( RP(G)) returns NULL. G, MRIB.next_hop( RP(G)) returns NULL.
The function NBR( I, A ) uses information gathered through PIM Hello The function NBR( I, A ) uses information gathered through PIM Hello
messages to map the IP address A of a directly connected PIM neighbor messages to map the IP address A of a directly connected PIM neighbor
router on interface I to the primary IP address of the same router router on interface I to the primary IP address of the same router
(Section 4.3.4). The primary IP address of a neighbor is the address | (Section 4.3.4). The primary IP address of a neighbor is the address
that it uses as the source of its PIM Hello messages. Note that a that it uses as the source of its PIM Hello messages. Note that a
neighbor's IP address may be non-unique within the PIM neighbor database neighbor's IP address may be non-unique within the PIM neighbor database
due to scope issues. The address must however be unique amongst the due to scope issues. The address must however be unique amongst the
addresses of all the PIM neighbors on a specific interface. addresses of all the PIM neighbors on a specific interface.
I_Am_Assert_Loser(S, G, I) is true if the Assert state machine (in | I_Am_Assert_Loser(S, G, I) is true if the Assert state machine (in
Section 4.6.1) for (S,G) on Interface I is in "I am Assert Loser" state. Section 4.6.1) for (S,G) on Interface I is in "I am Assert Loser" state.
I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in | I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in
Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser" state. Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser" state.
4.2. Data Packet Forwarding Rules 4.2. Data Packet Forwarding Rules
The PIM-SM packet forwarding rules are defined below in pseudocode. The PIM-SM packet forwarding rules are defined below in pseudocode.
iif is the incoming interface of the packet. iif is the incoming interface of the packet.
S is the source address of the packet. S is the source address of the packet.
G is the destination address of the packet (group address). G is the destination address of the packet (group address).
RP is the address of the Rendezvous Point for this group. RP is the address of the Rendezvous Point for this group.
RPF_interface(S) is the interface the MRIB indicates would be used RPF_interface(S) is the interface the MRIB indicates would be used
to route packets to S. to route packets to S.
RPF_interface(RP) is the interface the MRIB indicates would be used RPF_interface(RP) is the interface the MRIB indicates would be used
to route packets to RP, except at the RP when it is the to route packets to RP, except at the RP when it is the
decapsulation interface (the "virtual" interface on which register decapsulation interface (the "virtual" interface on which register
packets are received). packets are received).
First, we restart (or start) the Keepalive Timer if the source is on a First, we restart (or start) the Keepalive Timer if the source is on a
directly connected subnet. directly connected subnet.
Second, we check to see if the SPTbit should be set because we've now | Second, we check to see if the SPTbit should be set because we've now
switched from the RP tree to the SPT. switched from the RP tree to the SPT.
Next we check to see whether the packet should be accepted based on TIB Next we check to see whether the packet should be accepted based on TIB
state and the interface that the packet arrived on. state and the interface that the packet arrived on.
If the packet should be forwarded using (S,G) state, we then build an If the packet should be forwarded using (S,G) state, we then build an
outgoing interface list for the packet. If this list is not empty, then outgoing interface list for the packet. If this list is not empty, then
we restart the (S,G) state Keepalive Timer. we restart the (S,G) state Keepalive Timer.
If the packet should be forwarded using (*,*,RP) or (*,G) state, then we If the packet should be forwarded using (*,*,RP) or (*,G) state, then we
just build an outgoing interface list for the packet. We also check if just build an outgoing interface list for the packet. We also check if
we should initiate a switch to start receiving this source on a shortest we should initiate a switch to start receiving this source on a shortest
path tree. path tree.
Finally we remove the incoming interface from the outgoing interface Finally we remove the incoming interface from the outgoing interface
list we've created, and if the resulting outgoing interface list is not list we've created, and if the resulting outgoing interface list is not
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 |
inherited_olist(S,G) != NULL ) { |
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 UpstreamJPState(S,G) == Joined ) { if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) { |
oiflist = inherited_olist(S,G) oiflist = inherited_olist(S,G)
if( oiflist != NULL ) {
set KeepaliveTimer(S,G) to Keepalive_Period
}
} 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) |
# or Assert(*,G) message to be sent out interface iif. |
# 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 31 skipping to change at page 28, line 39
router it has the option of switching to receive the traffic on a router it has the option of switching to receive the traffic on a
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); restart KeepaliveTimer(S,G);
} }
} }
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 29, line 20 skipping to change at page 29, line 26
Thus, when a packet arrives, the (S,G) SPTbit is updated as follows: Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:
void void
Update_SPTbit(S,G,iif) { Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S) if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP(G)) OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) ) | ( RPF'(S,G) != NULL ) )
OR ( I_Am_Assert_Loser(S,G,iif) ) { | OR ( I_Am_Assert_Loser(S,G,iif) ) {
Set SPTbit(S,G) to TRUE Set SPTbit(S,G) to TRUE
} }
} }
Additionally a router can set SPTbit(S,G) to TRUE in other cases, such Additionally a router can set SPTbit(S,G) to TRUE in other cases, such
as when it receives an Assert(S,G) on RPF_interface(S) (see Section as when it receives an Assert(S,G) on RPF_interface(S) (see Section
4.6.1). 4.6.1).
JoinDesired(S,G) is defined in Section 4.5.7, and indicates whether we JoinDesired(S,G) is defined in Section 4.5.7, and indicates whether we
have the appropriate (S,G) Join state to wish to send a Join(S,G) have the appropriate (S,G) Join state to wish to send a Join(S,G)
upstream. upstream.
Basically Update_SPTbit will set the SPTbit if we have the appropriate | Basically Update_SPTbit will set the SPTbit if we have the appropriate
(S,G) join state and the packet arrived on the correct upstream (S,G) join state and the packet arrived on the correct upstream
interface for S, and one or more of the following conditions applies: interface for S, and one or more of the following conditions applies:
1. The source is directly connected, in which case the switch to the 1. The source is directly connected, in which case the switch to the
SPT is a no-op. SPT is a no-op.
2. The RPF interface to S is different from the RPF interface to the 2. The RPF interface to S is different from the RPF interface to the
RP. The packet arrived on RPF_interface(S), and so the SPT must RP. The packet arrived on RPF_interface(S), and so the SPT must
have been completed. have been completed.
skipping to change at page 30, line 11 skipping to change at page 30, line 17
4. RPF'(S,G) == RPF'(*,G). In this case the router will never be able 4. RPF'(S,G) == RPF'(*,G). In this case the router will never be able
to tell if the SPT has been completed, so it should just switch to tell if the SPT has been completed, so it should just switch
immediately. immediately.
In the case where the RPF interface is the same for the RP and for S, In the case where the RPF interface is the same for the RP and for S,
but RPF'(S,G) and RPF'(*,G) differ, then we wait for an Assert(S,G) but RPF'(S,G) and RPF'(*,G) differ, then we wait for an Assert(S,G)
which indicates that the upstream router with (S,G) state believes the which indicates that the upstream router with (S,G) state believes the
SPT has been completed. However item (3) above is needed because there SPT has been completed. However item (3) above is needed because there
may not be any (*,G) state to trigger an Assert(S,G) to happen. may not be any (*,G) state to trigger an Assert(S,G) to happen.
The SPTbit is cleared in the (S,G) upstream state machine (see Section | The SPTbit is cleared in the (S,G) upstream state machine (see Section
4.5.7) when JoinDesired(S,G) becomes FALSE. 4.5.7) when JoinDesired(S,G) becomes FALSE.
4.3. Designated Routers (DR) and Hello Messages 4.3. Designated Routers (DR) and Hello Messages
A shared-media LAN like Ethernet may have multiple PIM-SM routers | A shared-media LAN like Ethernet may have multiple PIM-SM routers
connected to it. A single one of these routers, the DR, will act on | connected to it. A single one of these routers, the DR, will act on
behalf of directly connected hosts with respect to the PIM-SM protocol. | behalf of directly connected hosts with respect to the PIM-SM protocol.
Because the distinction between LANs and point-to-point interfaces can | Because the distinction between LANs and point-to-point interfaces can
sometimes be blurred, and because routers may also have multicast host | sometimes be blurred, and because routers may also have multicast host
functionality, the PIM-SM specification makes no distinction between the | functionality, the PIM-SM specification makes no distinction between the
two. Thus DR election will happen on all interfaces, LAN or otherwise. two. Thus DR election will happen on all interfaces, LAN or otherwise.
DR election is performed using Hello messages. Hello messages are also DR election is performed using Hello messages. Hello messages are also
the way that option negotiation takes place in PIM, so that additional the way that option negotiation takes place in PIM, so that additional
functionality can be enabled, or parameters tuned. functionality can be enabled, or parameters tuned.
4.3.1. Sending Hello Messages 4.3.1. Sending Hello Messages
PIM Hello messages are sent periodically on each PIM-enabled interface. | PIM Hello messages are sent periodically on each PIM-enabled interface.
They allow a router to learn about the neighboring PIM routers on each They allow a router to learn about the neighboring PIM routers on each
interface. Hello messages are also the mechanism used to elect a interface. Hello messages are also the mechanism used to elect a
Designated Router (DR), and to negotiate additional capabilities. A Designated Router (DR), and to negotiate additional capabilities. A
router must record the Hello information received from each PIM router must record the Hello information received from each PIM
neighbor. neighbor.
Hello messages MUST be sent on all active interfaces, including physical Hello messages MUST be sent on all active interfaces, including physical
point-to-point links, and are multicast to the `ALL-PIM-ROUTERS' group point-to-point links, and are multicast to the `ALL-PIM-ROUTERS' group
address (`224.0.0.13' for IPv4 and `ff02::d' for IPv6). address (`224.0.0.13' for IPv4 and `ff02::d' for IPv6).
skipping to change at page 32, line 25 skipping to change at page 32, line 31
remove this neighbor (or its old IP address) immediately. After an remove this neighbor (or its old IP address) immediately. After an
interface has changed its IP address, it MUST send a Hello message with interface has changed its IP address, it MUST send a Hello message with
its new IP address. If an interface changes one of its secondary IP its new IP address. If an interface changes one of its secondary IP
addresses, a Hello message with an updated Address_List option and a addresses, a Hello message with an updated Address_List option and a
non-zero HoldTime should be sent immediately. This will cause PIM non-zero HoldTime should be sent immediately. This will cause PIM
neighbors to update this neighbor's list of secondary addresses neighbors to update this neighbor's list of secondary addresses
immediately. immediately.
4.3.2. DR Election 4.3.2. DR Election
When a PIM Hello message is received on interface I the following | When a PIM Hello message is received on interface I the following
information about the sending neighbor is recorded: information about the sending neighbor is recorded:
neighbor.interface neighbor.interface
The interface on which the Hello message arrived. The interface on which the Hello message arrived.
neighbor.primary_ip_address neighbor.primary_ip_address
The IP address that the PIM neighbor used as the source The IP address that the PIM neighbor used as the source
address of the Hello message. address of the Hello message.
neighbor.genid neighbor.genid
skipping to change at page 33, line 44 skipping to change at page 34, line 7
The trivial function I_am_DR(I) is defined to aid readability: The trivial function I_am_DR(I) is defined to aid readability:
bool bool
I_am_DR(I) { I_am_DR(I) {
return DR(I) == me return DR(I) == me
} }
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 in 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.
skipping to change at page 34, line 24 skipping to change at page 34, line 32
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
A flag indicating if the LAN Prune Delay option was present in A flag indicating if the LAN Prune Delay option was present in
the Hello message. the Hello message.
neighbor.tracking_support neighbor.tracking_support
A flag storing the value of the T bit in the LAN Prune Delay A flag storing the value of the T bit in the LAN Prune Delay
option if it is present in the Hello message. This indicates option if it is present in the Hello message. This indicates
the neighbor's capability to disable Join message suppression. | the neighbor's capability to disable Join message suppression.
neighbor.propagation_delay | neighbor.propagation_delay
The Propagation Delay field of the LAN Prune Delay option (if | The Propagation Delay field of the LAN Prune Delay option (if
present) in the Hello message. present) in the Hello message.
neighbor.override_interval neighbor.override_interval
The Override_Interval field of the LAN Prune Delay option (if The Override_Interval field of the LAN Prune Delay option (if
present) in the Hello message. present) in the Hello message.
The additional state described above is deleted along with the DR The additional state described above is deleted along with the DR
neighbor state when the neighbor timeout expires. neighbor state when the neighbor timeout expires.
Just like the DR_Priority option, the information provided in the LAN Just like the DR_Priority option, the information provided in the LAN
skipping to change at page 35, line 5 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 Propataion 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
temporary forwarding outages because a downstream router will not be temporary forwarding outages because a downstream router will not be
able to override a neighbor's Prune message before the upstream neighbor able to override a neighbor's Prune message before the upstream neighbor
stops forwarding. stops forwarding.
When all routers on a link are in a position to negotiate a different When all routers on a link are in a position to negotiate a different
than default Propagation Delay, the largest value from those advertised than default Propagation Delay, the largest value from those advertised
by each neighbor is chosen. The function for computing the | by each neighbor is chosen. The function for computing the
Effective_Propagation_Delay of interface I is: Effective_Propagation_Delay of interface I is:
time_interval time_interval
Effective_Propagation_Delay(I) { | Effective_Propagation_Delay(I) {
if ( lan_delay_enabled(I) == false ) { if ( lan_delay_enabled(I) == false ) {
return Propagation_delay_default | return Propagation_delay_default
} }
delay = Propagation_Delay(I) | delay = Propagation_Delay(I)
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.propagation_delay > delay ) { | if ( neighbor.propagation_delay > delay ) {
delay = neighbor.propagation_delay | delay = neighbor.propagation_delay
} }
} }
return delay return delay
} }
To avoid synchronization of override messages when multiple downstream To avoid synchronization of override messages when multiple downstream
routers share a multi-access link, sending of such messages is delayed routers share a multi-access link, sending of such messages is delayed
by a small random amount of time. The period of randomization should by a small random amount of time. The period of randomization should
represent the size of the PIM router population on the link. Each represent the size of the PIM router population on the link. Each
router expresses its view of the amount of randomization necessary in | router expresses its view of the amount of randomization necessary in
the Override Interval field of the LAN Prune Delay option. the Override Interval field of the LAN Prune Delay option.
When all routers on a link are in a position to negotiate a different | When all routers on a link are in a position to negotiate a different
than default Override Interval, the largest value from those advertised | than default Override Interval, the largest value from those advertised
by each neighbor is chosen. The function for computing the Effective | by each neighbor is chosen. The function for computing the Effective
Override Interval of interface I is: Override Interval of interface I is:
time_interval time_interval
Effective_Override_Interval(I) { | Effective_Override_Interval(I) {
if ( lan_delay_enabled(I) == false ) { if ( lan_delay_enabled(I) == false ) {
return t_override_default return t_override_default
} }
delay = Override_Interval(I) | delay = Override_Interval(I)
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.override_interval > delay ) { if ( neighbor.override_interval > delay ) {
delay = neighbor.override_interval delay = neighbor.override_interval
} }
} }
return delay return delay
} }
Although the mechanisms are not specified in this document, it is Although the mechanisms are not specified in this document, it is
possible for upstream routers to explicitly track the join membership of possible for upstream routers to explicitly track the join membership of
skipping to change at page 41, line 14 skipping to change at page 41, line 14
Note that on reception of a packet at the DR from a directly connected Note that on reception of a packet at the DR from a directly connected
source, KeepaliveTimer(S,G) needs to be set by the packet forwarding source, KeepaliveTimer(S,G) needs to be set by the packet forwarding
rules before computing CouldRegister(S,G) in the register state machine, rules before computing CouldRegister(S,G) in the register state machine,
or the first packet from a source won't be registered. or the first packet from a source won't be registered.
Encapsulating data packets in the Register Tunnel Encapsulating data packets in the Register Tunnel
Conceptually, the Register Tunnel is an interface with a smaller MTU Conceptually, the Register Tunnel is an interface with a smaller MTU
than the underlying IP interface towards the RP. IP fragmentation on than the underlying IP interface towards the RP. IP fragmentation on
packets forwarded on the Register Tunnel is performed based upon this | packets forwarded on the Register Tunnel is performed based upon this
smaller MTU. The encapsulating DR may perform Path MTU Discovery to the smaller MTU. The encapsulating DR may perform Path MTU Discovery to the
RP to determine the effective MTU of the tunnel. Fragmentation for the | RP to determine the effective MTU of the tunnel. Fragmentation for the
smaller MTU should take both the outer IP header and the PIM register smaller MTU should take both the outer IP header and the PIM register
header overhead into account. If a multicast packet is fragmented on header overhead into account. If a multicast packet is fragmented on
the way into the Register Tunnel, each fragment is encapsulated the way into the Register Tunnel, each fragment is encapsulated
individually so it contains IP, PIM, and inner IP headers. individually so it contains IP, PIM, and inner IP headers.
In IPv6, the DR MUST perform Path MTU discovery, and an ICMP Packet Too | In IPv6, the DR MUST perform Path MTU discovery, and an ICMP Packet Too
Big message MUST be sent by the encapsulating DR if it receives a packet Big message MUST be sent by the encapsulating DR if it receives a packet
that will not fit in the effective MTU of the tunnel. If the MTU that will not fit in the effective MTU of the tunnel. If the MTU
between the DR and the RP results in the effective tunnel MTU being between the DR and the RP results in the effective tunnel MTU being
smaller than 1280 (the IPv6 minimum MTU), the DR MUST send Fragmentation smaller than 1280 (the IPv6 minimum MTU), the DR MUST send Fragmentation
Required messages with an MTU value of 1280 and MUST fragment its PIM Required messages with an MTU value of 1280 and MUST fragment its PIM
register messages as required, using an IPv6 fragmentation header register messages as required, using an IPv6 fragmentation header
between the outer IPv6 header and the PIM Register header. between the outer IPv6 header and the PIM Register header.
The TTL of a forwarded data packet is decremented before it is | The TTL of a forwarded data packet is decremented before it is
encapsulated in the Register Tunnel. The encapsulating packet uses the encapsulated in the Register Tunnel. The encapsulating packet uses the
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
skipping to change at page 43, line 13 skipping to change at page 43, line 13
active after the Register-Stop(*,G) was received. active after the Register-Stop(*,G) was received.
4.4.2. Receiving Register Messages at the RP 4.4.2. Receiving Register Messages at the RP
When an RP receives a Register message, the course of action is decided When an RP receives a Register message, the course of action is decided
according to the following pseudocode: according to the following pseudocode:
packet_arrives_on_rp_tunnel( pkt ) { packet_arrives_on_rp_tunnel( pkt ) {
if( outer.dst is not one of my addresses ) { if( outer.dst is not one of my addresses ) {
drop the packet silently. drop the packet silently.
# Note: this may be a spoofing attempt | # Note: this may be a spoofing attempt
} }
if( I_am_RP(G) AND outer.dst == RP(G) ) { if( I_am_RP(G) AND outer.dst == RP(G) ) {
sentRegisterStop = FALSE; | sentRegisterStop = FALSE;
if ( register.borderbit == TRUE ) { | if ( register.borderbit == TRUE ) {
if ( PMBR(S,G) == unknown ) { | if ( PMBR(S,G) == unknown ) {
PMBR(S,G) = outer.src | PMBR(S,G) = outer.src
} else if ( outer.src != PMBR(S,G) ) { | } else if ( outer.src != PMBR(S,G) ) {
send Register-Stop(S,G) to outer.src | send Register-Stop(S,G) to outer.src
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; restart KeepaliveTimer(S,G) to RP_Keepalive_Period;
} else { | } else {
restart KeepaliveTimer(S,G) to Keepalive_Period; | restart 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 (*)
} }
} }
outer.dst is the IP destination address of the encapsulating header. outer.dst is the IP destination address of the encapsulating header.
outer.src is the IP source address of the encapsulating header, i.e., outer.src is the IP source address of the encapsulating header, i.e.,
skipping to change at page 44, line 15 skipping to change at page 44, line 15
I_am_RP(G) is true if the group-to-RP mapping indicates that this router I_am_RP(G) is true if the group-to-RP mapping indicates that this router
is the RP for the group. is the RP for the group.
Note (*): This may block traffic from S for Register_Suppression_Time if Note (*): This may block traffic from S for Register_Suppression_Time if
the DR learned about a new group-to-RP mapping before the RP did. the DR learned about a new group-to-RP mapping before the RP did.
However, this doesn't matter unless we figure out some way for the However, this doesn't matter unless we figure out some way for the
RP to also accept (*,G) joins when it doesn't yet realize that it RP to also accept (*,G) joins when it doesn't yet realize that it
is about to become the RP for G. This will all get sorted out once is about to become the RP for G. This will all get sorted out once
the RP learns the new group-to-rp mapping. We decided to do the RP learns the new group-to-rp mapping. We decided to do
nothing about this and just accept the fact that PIM may suffer nothing about this and just accept the fact that PIM may suffer
interrupted (*,G) connectivity following an RP change. | interrupted (*,G) connectivity following an RP change.
Note (+): Implementations are advised to not make this a special case, | Note (+): Implementations are advised to not make this a special case,
but to arrange that this path rejoin the normal packet forwarding | but to arrange that this path rejoin the normal packet forwarding
path. All of the appropriate actions from the "On receipt of data | path. All of the appropriate actions from the "On receipt of data
from S to G on interface iif" pseudocode in Section 4.2 should be | from S to G on interface iif" pseudocode in Section 4.2 should be
performed. performed.
KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the
proper tunnel interface and the RP desires to switch to the SPT or the proper tunnel interface and the RP desires to switch to the SPT or the
SPTbit is already set. This may cause the upstream (S,G) state machine SPTbit is already set. This may cause the upstream (S,G) state machine
to trigger a join if the inherited_olist(S,G) is not NULL; to trigger a join if the inherited_olist(S,G) is not NULL;
An RP should preserve (S,G) state that was created in response to a An RP should preserve (S,G) state that was created in response to a
Register message for at least ( 3 * Register_Suppression_Time ), Register message for at least ( 3 * Register_Suppression_Time ),
otherwise the RP may stop joining (S,G) before the DR for S has otherwise the RP may stop joining (S,G) before the DR for S has
restarted sending registers. Traffic would then be interrupted until restarted sending registers. Traffic would then be interrupted until
the Register-Stop Timer expires at the DR. the Register-Stop Timer expires at the DR.
Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 * Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 *
Register_Suppression_Time + Register_Probe_Time ). Register_Suppression_Time + Register_Probe_Time ).
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 [10].
skipping to change at page 46, line 28 skipping to change at page 46, line 28
Figure 2: Downstream per-interface (*,*,RP) state machine in tabular form Figure 2: Downstream per-interface (*,*,RP) state machine in tabular form
r+-------------++----------------------------------------------------------+ 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 address on the imply receiving a Join or Prune targeted to this router's primary IP |
received interface. If the destination address is not correct, these address on the received interface. If the destination address is not
state transitions in this state machine must not occur, although seeing correct, these state transitions in this state machine must not occur,
such a packet may cause state transitions in other state machines. although seeing such a packet may cause 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 |
recommend that for backwards compatibility PIM Join/Prune messages with | it sent over that interface. However on point-to-point links we also
recommend that for backwards compatibility PIM Join/Prune messages with
a destination address of all zeros are also accepted. a destination address 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 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 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 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 15 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 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 50, line 33 skipping to change at page 50, line 33
| ||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 address on the receiving a Join or Prune targeted to this router's primary IP address |
received interface. If the destination address is not correct, these on the received interface. If the destination address is not correct,
state transitions in this state machine must not occur, although seeing these state transitions in this state machine must not occur, although
such a packet may cause state transitions in other state machines. seeing such a packet may cause 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 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 destination address 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 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 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 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 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 43 skipping to change at page 53, line 43
| ||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 address on the receiving a Join or Prune targeted to this router's primary IP address |
received interface. If the destination address is not correct, these on the received interface. If the destination address is not correct,
state transitions in this state machine must not occur, although seeing these state transitions in this state machine must not occur, although
such a packet may cause state transitions in other state machines. seeing such a packet may cause 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 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 destination address 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 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 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 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 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 57, line 49 skipping to change at page 57, line 49
| || | | 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 address on the received interface. If the destination address router's primary IP address on the received interface. If the
is not correct, these state transitions in this state machine must not destination address is not correct, these state transitions in this
occur, although seeing such a packet may cause state transitions in state machine must not occur, although seeing such a packet may cause
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 destination address of all
zeros are also accepted. 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 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 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 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 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 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 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 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 any of the addresses belonging to send a Join(*,*,RP) to NBR(RPF_interface(RP), |
NBR(RPF_interface(RP), MRIB.next_hop(RP)). This causes this MRIB.next_hop(RP)). This causes this router to suppress its
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 any of the addresses belonging to send a Prune(*,*,RP) to NBR(RPF_interface(RP), |
NBR(RPF_interface(RP), MRIB.next_hop(RP)). As this router is MRIB.next_hop(RP)). As this router is in Joined state, it
in Joined state, it must override the Prune after a short must override the Prune after a short random interval.
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
A change in the MRIB routing base causes the next hop towards A change in the MRIB routing base causes the next hop towards
the RP to change. the RP to change.
skipping to change at page 68, line 28 skipping to change at page 68, line 28
although JoinDesired is true, the router's sending of a Join(*,G) although JoinDesired is true, the router's sending of a Join(*,G)
message may be suppressed by another router sending a Join(*,G) onto the message may be suppressed by another router sending a Join(*,G) onto the
upstream interface. upstream interface.
Transitions from NotJoined State Transitions from NotJoined State
When the upstream (*,G) state machine is in NotJoined state, the When the upstream (*,G) state machine is in NotJoined state, the
following event may trigger a state transition: following event may trigger a state transition:
JoinDesired(*,G) becomes True JoinDesired(*,G) becomes True
The macro JoinDesired(*,G) becomes True, e.g., because the | The macro JoinDesired(*,G) becomes True, e.g., because the
downstream state for (*,G) has changed so that at least one | downstream state for (*,G) has changed so that at least one
interface is in immediate_olist(*,G). interface is in immediate_olist(*,G).
The upstream (*,G) state machine transitions to Joined state. The upstream (*,G) state machine transitions to Joined state.
Send Join(*,G) to the appropriate upstream neighbor, which is Send Join(*,G) to the appropriate upstream neighbor, which is
RPF'(*,G). Set the Join Timer (JT) to expire after t_periodic RPF'(*,G). Set the Join Timer (JT) to expire after t_periodic
seconds. seconds.
Transitions from Joined State Transitions from Joined State
When the upstream (*,G) state machine is in Joined state, the following When the upstream (*,G) state machine is in Joined state, the following
events may trigger state transitions: events may trigger state transitions:
JoinDesired(*,G) becomes False JoinDesired(*,G) becomes False
The macro JoinDesired(*,G) becomes False, e.g., because the | The macro JoinDesired(*,G) becomes False, e.g., because the
downstream state for (*,G) has changed so no interface is in | downstream state for (*,G) has changed so no interface is in
immediate_olist(*,G). immediate_olist(*,G).
The upstream (*,G) state machine transitions to NotJoined The upstream (*,G) state machine transitions to NotJoined
state. Send Prune(*,G) to the appropriate upstream neighbor, state. Send Prune(*,G) to the appropriate upstream neighbor,
which is RPF'(*,G). Cancel the Join Timer (JT). which is RPF'(*,G). Cancel the Join Timer (JT).
Join Timer Expires Join Timer Expires
The Join Timer (JT) expires, indicating time to send a The Join Timer (JT) expires, indicating time to send a
Join(*,G) Join(*,G)
skipping to change at page 73, line 11 skipping to change at page 73, line 11
state. Note that although JoinDesired is true, the router's sending of a state. Note that although JoinDesired is true, the router's sending of a
Join(S,G) message may be suppressed by another router sending a Join(S,G) message may be suppressed by another router sending a
Join(S,G) onto the upstream interface. Join(S,G) onto the upstream interface.
Transitions from NotJoined State Transitions from NotJoined State
When the upstream (S,G) state machine is in NotJoined state, the When the upstream (S,G) state machine is in NotJoined state, the
following event may trigger a state transition: following event may trigger a state transition:
JoinDesired(S,G) becomes True JoinDesired(S,G) becomes True
The macro JoinDesired(S,G) becomes True, e.g., because the | The macro JoinDesired(S,G) becomes True, e.g., because the
downstream state for (S,G) has changed so that at least one | downstream state for (S,G) has changed so that at least one
interface is in inherited_olist(S,G). interface is in inherited_olist(S,G).
The upstream (S,G) state machine transitions to Joined state. The upstream (S,G) state machine transitions to Joined state.
Send Join(S,G) to the appropriate upstream neighbor, which is Send Join(S,G) to the appropriate upstream neighbor, which is
RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic
seconds. seconds.
Transitions from Joined State Transitions from Joined State
When the upstream (S,G) state machine is in Joined state, the following When the upstream (S,G) state machine is in Joined state, the following
events may trigger state transitions: events may trigger state transitions:
JoinDesired(S,G) becomes False JoinDesired(S,G) becomes False
The macro JoinDesired(S,G) becomes False, e.g., because the | The macro JoinDesired(S,G) becomes False, e.g., because the
downstream state for (S,G) has changed so no interface is in | downstream state for (S,G) has changed so no interface is in
inherited_olist(S,G). inherited_olist(S,G).
The upstream (S,G) state machine transitions to NotJoined The upstream (S,G) state machine transitions to NotJoined
state. Send Prune(S,G) to the appropriate upstream neighbor, state. Send Prune(S,G) to the appropriate upstream neighbor,
which is RPF'(S,G). Cancel the Join Timer (JT), and set which is RPF'(S,G). Cancel the Join Timer (JT), and set
SPTbit(S,G) to FALSE. SPTbit(S,G) to FALSE.
Join Timer Expires Join Timer Expires
The Join Timer (JT) expires, indicating time to send a The Join Timer (JT) expires, indicating time to send a
Join(S,G) Join(S,G)
skipping to change at page 82, line 26 skipping to change at page 82, line 26
election is performed using PIM Assert messages. Assert messages are election is performed using PIM Assert messages. Assert messages are
also received by downstream routers on the LAN, and these cause also received by downstream routers on the LAN, and these cause
subsequent Join/Prune messages to be sent to the upstream router that subsequent Join/Prune messages to be sent to the upstream router that
won the Assert. won the Assert.
In general, a PIM Assert message should only be accepted for processing In general, a PIM Assert message should only be accepted for processing
if it comes from a known PIM neighbor. A PIM router hears about PIM if it comes from a known PIM neighbor. A PIM router hears about PIM
neighbors through PIM Hello messages. If a router receives an Assert neighbors through PIM Hello messages. If a router receives an Assert
message from a particular IP source address and it has not seen a PIM message from a particular IP source address and it has not seen a PIM
Hello message from that source address, then the Assert message SHOULD Hello message from that source address, then the Assert message SHOULD
be discarded without further processing. In addition, if the Hello | be discarded without further processing. In addition, if the Hello
message from a neighbor was authenticated using the IPsec Authentication | message from a neighbor was authenticated using the IPsec Authentication
Header (AH) (see Section 6.3) then all Assert messages from that Header (AH) (see Section 6.3) then all Assert messages from that
neighbor MUST also be authenticated using IPsec AH. neighbor MUST also be authenticated using IPsec AH.
We note that some older PIM implementations incorrectly fail to send We note that some older PIM implementations incorrectly fail to send
Hello messages on point-to-point interfaces, so we also RECOMMEND that a Hello messages on point-to-point interfaces, so we also RECOMMEND that a
configuration option be provided to allow interoperation with such older configuration option be provided to allow interoperation with such older
routers, but that this configuration option SHOULD NOT be enabled by routers, but that this configuration option SHOULD NOT be enabled by
default. default.
4.6.1. (S,G) Assert Message State Machine 4.6.1. (S,G) Assert Message State Machine
skipping to change at page 84, line 39 skipping to change at page 84, line 39
| 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 from | Assert from | | GenID | | | RPTbit clear | | Current | | Changes or |
| | Current | Current | | Changes or | | | from Current | | Winner | | NLT Expires |
| | Winner | Winner | | NLT Expires | | | 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]+-------------+--------------+--------------+--------------+--------------+ A5]+-------------+----------------+--------------+--------------+--------------+
T+-----------------------------------------------------------------------+ 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 | | |
| |
skipping to change at page 87, line 21 skipping to change at page 87, line 21
the assert winner. We transition to the "I am Assert Winner" the assert winner. We transition to the "I am Assert Winner"
state, and perform Actions A1 (below). state, and perform Actions A1 (below).
An (S,G) data packet arrives on interface I, AND An (S,G) data packet arrives on interface I, AND
CouldAssert(S,G,I)==TRUE CouldAssert(S,G,I)==TRUE
An (S,G) data packet arrived on an downstream interface which An (S,G) data packet arrived on an downstream interface which
is in our (S,G) outgoing interface list. We optimistically is in our (S,G) outgoing interface list. We optimistically
assume that we will be the assert winner for this (S,G), and assume that we will be the assert winner for this (S,G), and
so we transition to the "I am Assert Winner" state, and so we transition to the "I am Assert Winner" state, and
perform Actions A1 (below) which will initiate the assert perform Actions A1 (below) which will initiate the assert
negotiation for (S,G). | negotiation for (S,G).
Receive Acceptable Assert with RPT bit clear AND | Receive Acceptable Assert with RPT bit clear AND
AssertTrackingDesired(S,G,I)==TRUE | AssertTrackingDesired(S,G,I)==TRUE
We're interested in (S,G) Asserts, either because I is a We're interested in (S,G) Asserts, either because I is a
downstream interface for which we have (S,G) or (*,G) downstream interface for which we have (S,G) or (*,G)
forwarding state, or because I is the upstream interface for S forwarding state, or because I is the upstream interface for S
and we have (S,G) forwarding state. The received assert has a and we have (S,G) forwarding state. The received assert has a
better metric than our own, so we do not win the Assert. We better metric than our own, so we do not win the Assert. We
transition to "I am Assert Loser" and perform actions A6 transition to "I am Assert Loser" and perform actions A6
(below). (below).
Transitions from "I am Assert Winner" State Transitions from "I am Assert Winner" State
skipping to change at page 88, line 29 skipping to change at page 88, line 29
Transitions from "I am Assert Loser" State Transitions from "I am Assert Loser" State
When in "I am Assert Loser" state, the following transitions can occur: When in "I am Assert Loser" state, the following transitions can occur:
Receive Preferred Assert Receive Preferred Assert
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 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 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). We transition to NoInfo state,
deleting the (S,G) assert information and allowing the normal deleting the (S,G) assert information and allowing the normal
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 one my IP address on interface I. The action is field set to my primary IP address on interface I. The action |
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
A1: Send Assert(S,G) A1: Send Assert(S,G)
skipping to change at page 90, line 23 skipping to change at page 90, line 23
AssertWinnerMetric(S,G,I) will then return their default AssertWinnerMetric(S,G,I) will then return their default
values). values).
A5: Delete assert info (AssertWinner(S,G,I) and A5: Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return their default AssertWinnerMetric(S,G,I) will then return their default
values). values).
A6: Store new assert winner as AssertWinner(S,G,I) and assert A6: Store new assert winner as AssertWinner(S,G,I) and assert
winner metric as AssertWinnerMetric(S,G,I). winner metric as AssertWinnerMetric(S,G,I).
Set Assert Timer to Assert_Time Set Assert Timer to Assert_Time
If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == true) | If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == true)
set SPTbit(S,G) to TRUE. set SPTbit(S,G) to TRUE.
Note that some of these actions may cause the value of JoinDesired(S,G), Note that some of these actions may cause the value of JoinDesired(S,G),
PruneDesired(S,G,rpt), or RPF'(S,G) to change, which could cause further PruneDesired(S,G,rpt), or RPF'(S,G) to change, which could cause further
transitions in other state machines. transitions in other state machines.
4.6.2. (*,G) Assert Message State Machine 4.6.2. (*,G) Assert Message State Machine
The (*,G) Assert state machine for interface I is shown in Figure 11. The (*,G) Assert state machine for interface I is shown in Figure 11.
There are three states: There are three states:
skipping to change at page 91, line 20 skipping to change at page 91, line 20
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
after the (S,G) state machine has processed the message. Also NO after the (S,G) state machine has processed the message. Also NO
TRANSITION CAN OCCUR in the (*,G) state machine as a result of receiving TRANSITION CAN OCCUR in the (*,G) state machine as a result of receiving
an assert message if that message triggers any change of state in the an assert message if that message triggers any change of state in the
(S,G) state machine. Obviously when the source address in the received | (S,G) state machine. Obviously when the source address in the received
message is set to zero an (S,G) state machine for the S and G does not | message is set to zero an (S,G) state machine for the S and G does not
exist and can be assumed to be in the "NoInfo" state. exist and can be assumed to be in the "NoInfo" state.
For example, if both the (S,G) and (*,G) assert state machines where in For example, if both the (S,G) and (*,G) assert state machines where in
the NoInfo state when an Assert message arrives, and the message causes the NoInfo state when an Assert message arrives, and the message causes
the (S,G) state machine to transition to either "W" or "L" state, then the (S,G) state machine to transition to either "W" or "L" state, then
the assert would not be processed by the (*,G) assert state machine. the assert would not be processed by the (*,G) assert state machine.
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
skipping to change at page 92, line 38 skipping to change at page 92, line 38
| | 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 | Assert from | Assert from | | GenID |
| | Current | Current | | Changes or | | | Current | Current | | Changes or |
| | Winner | Winner | | NLT Expires | | | Winner | Winner | | NLT Expires |
| |+-------------+--------------+--------------+--------------+--------------+
+-------------+--------------+--------------+--------------+--------------+
|-> 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]+-------------+--------------+--------------+--------------+--------------+ A5]+-------------+--------------+--------------+--------------+--------------+
T+-----------------------------------------------------------------------+ 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 |
skipping to change at page 94, line 26 skipping to change at page 94, line 26
interface, so we should be the assert winner. We transition interface, so we should be the assert winner. We transition
to the "I am Assert Winner" state, and perform Actions A1 to the "I am Assert Winner" state, and perform Actions A1
(below). (below).
A data packet destined for G arrives on interface I, AND A data packet destined for G arrives on interface I, AND
CouldAssert(*,G,I)==TRUE CouldAssert(*,G,I)==TRUE
A data packet destined for G arrived on a downstream interface A data packet destined for G arrived on a downstream interface
which is in our (*,G) outgoing interface list. We therefore which is in our (*,G) outgoing interface list. We therefore
believe we should be the forwarder for this (*,G), and so we believe we should be the forwarder for this (*,G), and so we
transition to the "I am Assert Winner" state, and perform transition to the "I am Assert Winner" state, and perform
Actions A1 (below). | Actions A1 (below).
Receive Acceptable Assert with RPT bit set AND | Receive Acceptable Assert with RPT bit set AND
AssertTrackingDesired(*,G,I)==TRUE | AssertTrackingDesired(*,G,I)==TRUE
We're interested in (*,G) Asserts, either because I is a We're interested in (*,G) Asserts, either because I is a
downstream interface for which we have (*,G) forwarding state, downstream interface for which we have (*,G) forwarding state,
or because I is the upstream interface for RP(G) and we have or because I is the upstream interface for RP(G) and we have
(*,G) forwarding state. We get a (*,G) Assert that has a (*,G) forwarding state. We get a (*,G) Assert that has a
better metric than our own, so we do not win the Assert. We better metric than our own, so we do not win the Assert. We
transition to "I am Assert Loser" and perform actions A2 transition to "I am Assert Loser" and perform actions A2
(below). (below).
Transitions from "I am Assert Winner" State Transitions from "I am Assert Winner" State
skipping to change at page 99, line 12 skipping to change at page 99, line 12
An AssertCancel message is simply an RPT Assert message but with An AssertCancel message is simply an RPT Assert message but with
infinite metric. It is sent by the assert winner when it deletes the infinite metric. It is sent by the assert winner when it deletes the
forwarding state that had caused the assert to occur. Other routers forwarding state that had caused the assert to occur. Other routers
will see this metric, and it will cause any other router that has will see this metric, and it will cause any other router that has
forwarding state to send its own assert, and to take over forwarding. forwarding state to send its own assert, and to take over forwarding.
An AssertCancel(S,G) is an infinite metric assert with the RPT bit set An AssertCancel(S,G) is an infinite metric assert with the RPT bit set
that names S as the source. that names S as the source.
An AssertCancel(*,G) is an infinite metric assert with the RPT bit set | An AssertCancel(*,G) is an infinite metric assert with the RPT bit set
and the source set to zero. and the source set to zero.
AssertCancel messages are simply an optimization. The original Assert AssertCancel messages are simply an optimization. The original Assert
timeout mechanism will allow a subnet to eventually become consistent; timeout mechanism will allow a subnet to eventually become consistent;
the AssertCancel mechanism simply causes faster convergence. No special the AssertCancel mechanism simply causes faster convergence. No special
processing is required for an AssertCancel message, since it is simply processing is required for an AssertCancel message, since it is simply
an Assert message from the current winner. an Assert message from the current winner.
4.6.5. Assert State Macros 4.6.5. Assert State Macros
skipping to change at page 100, line 5 skipping to change at page 100, line 5
AssertWinner(S,G,I) != me AND AssertWinner(S,G,I) != me AND
(AssertWinnerMetric(S,G,I) is better (AssertWinnerMetric(S,G,I) is better
than spt_assert_metric(S,I) ) than spt_assert_metric(S,I) )
} }
} }
Note: the term "AssertWinnerMetric(S,G,I) is better than Note: the term "AssertWinnerMetric(S,G,I) is better than
spt_assert_metric(S,I)" is required to correctly handle the transition spt_assert_metric(S,I)" is required to correctly handle the transition
phase when a router has (S,G) join state, but has not yet set the SPT phase when a router has (S,G) join state, but has not yet set the SPT
bit. In this case it needs to ignore the assert state if it will win | bit. In this case it needs to ignore the assert state if it will win
the assert once the SPTbit is set. the assert once the SPTbit is set.
bool lost_assert(*,G,I) { bool lost_assert(*,G,I) {
if ( RPF_interface(RP(G)) == I ) { if ( RPF_interface(RP(G)) == I ) {
return FALSE return FALSE
} else { } else {
return ( AssertWinner(*,G,I) != NULL AND return ( AssertWinner(*,G,I) != NULL AND
AssertWinner(*,G,I) != me ) AssertWinner(*,G,I) != me )
} }
} }
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 one of its addresses 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 one of
its addresses on that interface cancels the (*,G) Assert Timer and its addresses on that interface cancels the (*,G) Assert Timer and
all (S,G) assert timers that do not have corresponding all (S,G) assert timers that do not have corresponding
skipping to change at page 102, line 29 skipping to change at page 102, line 29
Rationale: This allows switching back to the RPT after the last SPT Rationale: This allows switching back to the RPT after the last SPT
member leaves. member leaves.
4.7. PIM Bootstrap and RP Discovery 4.7. PIM Bootstrap and RP Discovery
For correct operation, every PIM router within a PIM domain must be able For correct operation, every PIM router within a PIM domain must be able
to map a particular multicast group address to the same RP. If this is to map a particular multicast group address to the same RP. If this is
not the case then black holes may appear, where some receivers in the not the case then black holes may appear, where some receivers in the
domain cannot receive some groups. A domain in this context is a domain cannot receive some groups. A domain in this context is a
contiguous set of routers that all implement PIM and are configured to | contiguous set of routers that all implement PIM and are configured to
operate within a common boundary. operate within a common boundary.
A notable exception to this is where a PIM domain is broken up into A notable exception to this is where a PIM domain is broken up into
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 three mechanisms are possible, and all three 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.
Embeded-RP | Embedded-RP
Embeded-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 [15].
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)
skipping to change at page 103, line 33 skipping to change at page 103, line 33
2362, BSR is flawed in its handling of admin-scoped regions that 2362, BSR is flawed in its handling of admin-scoped regions that
are smaller than a PIM domain, but the mechanism does work for are smaller than a PIM domain, but the mechanism does work for
global-scoped groups. global-scoped groups.
As far as PIM-SM is concerned, the only important requirement is that As far as PIM-SM is concerned, the only important requirement is that
all routers in the domain (or admin scope zone for scoped regions) all routers in the domain (or admin scope zone for scoped regions)
receive the same set of group-range-to-RP mappings. This may be receive the same set of group-range-to-RP mappings. This may be
achieved through the use of any of these mechanisms, or through achieved through the use of any of these mechanisms, or through
alternative mechanisms not currently specified. alternative mechanisms not currently specified.
It must be operationally ensured that any RP address configured, learned | It must be operationally ensured that any RP address configured, learned
or advertised is reachable from all routers in the PIM domain. or advertised is reachable from all routers in the PIM domain.
4.7.1. Group-to-RP Mapping 4.7.1. Group-to-RP Mapping
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
skipping to change at page 105, line 42 skipping to change at page 105, line 42
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 [5] 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
address G in the SSM range: address G in the SSM range:
o A router MUST NOT send a (*,G) Join/Prune message for any reason. o A router MUST NOT send a (*,G) Join/Prune message for any reason.
skipping to change at page 108, line 43 skipping to change at page 108, line 43
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 [4]. 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.
4.9.1. Encoded Source and Group Address Formats 4.9.1. Encoded Source and Group Address Formats
Encoded-Unicast address Encoded-Unicast address
An Encoded-Unicast address takes the following format: An Encoded-Unicast address takes the following format:
skipping to change at page 113, line 36 skipping to change at page 113, line 36
the receiving routers should immediately time out the neighbor the receiving routers should immediately time out the neighbor
information for the sender. information for the sender.
o OptionType 2: LAN Prune Delay o OptionType 2: LAN Prune Delay
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 4 | | Type = 2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Propagation_Delay | Override_Interval | | |T| Propagation_Delay | Override_Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LAN Prune Delay option is used to tune the prune propagation The LAN Prune Delay option is used to tune the prune propagation
delay on multi-access LANs. The T bit specifies the ability of delay on multi-access LANs. The T bit specifies the ability of
the sending router to disable joins suppression. | the sending router to disable joins suppression.
Propagation_Delay and Override_Interval are time intervals in | Propagation_Delay and Override_Interval are time intervals in
units of milliseconds. A router originating a LAN Prune Delay | units of milliseconds. A router originating a LAN Prune Delay
option on interface I sets the Propagation_Delay field to the | option on interface I sets the Propagation_Delay field to the
configured value of Propagation_Delay(I) and the value of the | configured value of Propagation_Delay(I) and the value of the
Override_Interval field to the value of Override_Interval(I). On | Override_Interval field to the value of Override_Interval(I). On
a receiving router the values of the fields are used to tune the | a receiving router the values of the fields are used to tune the
value of the Effective_Override_Interval(I) and its derived timer | value of the Effective_Override_Interval(I) and its derived timer
values. Section 4.3.3 describes how these values affect the values. Section 4.3.3 describes how these values affect the
behavior of a router. behavior of a router.
o OptionType 3 to 16: reserved to be defined in future versions of o OptionType 3 to 16: reserved to be defined in future versions of
this document. this document.
o OptionType 18: deprecated and should not be used. o OptionType 18: deprecated and should not be used.
o OptionType 19: DR Priority o OptionType 19: DR Priority
skipping to change at page 115, line 9 skipping to change at page 115, line 9
| 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]. [8].
Unknown options may be ignored. The "Holdtime" option MUST be Unknown options MUST be ignored, and MUST NOT prevent a neighbor |
implemented; the "DR Priority" and "Generation ID" options SHOULD | relationship from being formed. The "Holdtime" option MUST be
be implemented. The "Address List" option MUST be implemented for | implemented; the "DR Priority" and "Generation ID" options SHOULD
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
RP's address. The IP TTL of the PIM packet is the system's normal RP's address. The IP TTL of the PIM packet is the system's normal
unicast TTL. unicast TTL.
skipping to change at page 117, line 18 skipping to change at page 117, line 18
Next Header 103 (PIM) Next Header 103 (PIM)
Length 4 Length 4
PIM Version 0 PIM Version 0
PIM Type 0 PIM Type 0
PIM Reserved 0 PIM Reserved 0
PIM Checksum PIM checksum including PIM Checksum PIM checksum including
IPv6 "pseudo-header"; IPv6 "pseudo-header";
see Section 4.9 see Section 4.9
On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM header On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM header
is present, the recipient SHOULD check the checksum and discard | is present, the recipient SHOULD check the checksum and discard
Null-Registers that have a bad checksum. Null-Registers that have a bad checksum.
4.9.4. Register-Stop Message Format 4.9.4. Register-Stop Message Format
A Register-Stop is unicast from the RP to the sender of the Register A Register-Stop is unicast from the RP to the sender of the Register
message. The IP source address is the address to which the register was message. The IP source address is the address to which the register was
addressed. The IP destination address is the source address of the addressed. The IP destination address is the source address of the
register message. register message.
0 1 2 3 0 1 2 3
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 wildcard group `224.0.0.0/4' for IPv4 or `ff00::/8' for IPv6. Each Join / Prune |
set may contain one or more (*,*,RP) source list entries in either message SHOULD contain at most one wildcard group set. Each
the Join or Prune lists. wildcard group set may contain one or more (*,*,RP) source list
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 group the mask length field of the Multicast Group Address. Each Join / |
specific set may contain (*,G), (S,G,rpt) and (S,G) source list Prune message SHOULD NOT contain more than one group specific set |
entries in the Join or Prune lists. 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
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
specific set. specific set.
(*,G) source list entries have the Source-Address set to the (*,G) source list entries have the Source-Address set to the
skipping to change at page 127, line 6 skipping to change at page 127, line 6
Metric Metric
The unicast routing table metric associated with the route used to The unicast routing table metric associated with the route used to
reach the multicast source or Rendezvous-Point. The metric is in reach the multicast source or Rendezvous-Point. The metric is in
units applicable to the unicast routing protocol used. units applicable to the unicast routing protocol used.
Assert messages can be sent to resolve a forwarding conflict for all Assert messages can be sent to resolve a forwarding conflict for all
traffic to given group or for a specific source and group. traffic to given group or for a specific source and group.
Assert(S,G) Assert(S,G)
Source specific asserts are sent by routers forwarding a specific | Source specific asserts are sent by routers forwarding a specific
source on the shortest-path tree (SPTbit is TRUE). (S,G) Asserts | source on the shortest-path tree (SPTbit is TRUE). (S,G) Asserts
have the Group-Address field set to the group G and the Source- have the Group-Address field set to the group G and the Source-
Address field set to the source S. The RPT-bit is set to 0, the Address field set to the source S. The RPT-bit is set to 0, the
Metric-Preference is set to MRIB.pref(S) and the Metric is set to Metric-Preference is set to MRIB.pref(S) and the Metric is set to
MRIB.metric(S). MRIB.metric(S).
Assert(*,G) Assert(*,G)
Group specific asserts are sent by routers forwarding data for the Group specific asserts are sent by routers forwarding data for the
group and source(s) under contention on the shared tree. (*,G) group and source(s) under contention on the shared tree. (*,G)
asserts have the Group-Address field set to the group G. For data asserts have the Group-Address field set to the group G. For data
triggered Asserts the Source-Address field MAY be set to the IP triggered Asserts the Source-Address field MAY be set to the IP
skipping to change at page 129, line 23 skipping to change at page 129, line 23
| 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+--------------------------+-----------------+--------------------------+ 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 |
skipping to change at page 132, line 42 skipping to change at page 132, line 42
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
router to adapt. router to adapt.
The holdtime specified in a Join/Prune message should be set to (3.5 * The holdtime specified in a Join/Prune message should be set to (3.5 *
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+---------------+---------------------------+---------------------------+ m+---------------+---------------------------+---------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
| |
skipping to change at page 134, line 30 skipping to change at page 134, line 30
+----------------------------+--------------------+---------------------+ +----------------------------+--------------------+---------------------+
|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 |
| | | resend a Register- | | | | resend 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 [6].
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 [8].
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 [8].
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. [8]. Such assignments are valid for one year, and may be renewed.
skipping to change at page 137, line 27 skipping to change at page 137, line 27
As of this writing, the IPsec anti-replay option does not handle the As of this writing, the IPsec anti-replay option does not handle the
case of a Security Association identified by a multicast destination case of a Security Association identified by a multicast destination
address. Thus, the anti-replay option currently must be disabled on address. Thus, the anti-replay option currently must be disabled on
these Security Associations. Until replay prevention for link-local these Security Associations. Until replay prevention for link-local
multicast messages is addressed (one such proposal is [14]), the anti- multicast messages is addressed (one such proposal is [14]), the anti-
replay option SHOULD be enabled on all security associations having a replay option SHOULD be enabled on all security associations having a
unicast destination address. 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 sign PIM protocol messages and are used by are used by senders to authenticate PIM protocol messages and are used
receivers to authenticate received PIM protocol messages. This document by receivers to authenticate received PIM protocol messages. This
does not describe protocols for establishing Security Associations. It document does not describe protocols for establishing Security
assumes that manual configuration of Security Associations is performed, Associations. It assumes that manual configuration of Security
but it does not preclude the use of a negotiation protocol such as The Associations is performed, but it does not preclude the use of a
Internet Key Exchange [13] to establish Security Associations. negotiation protocol such as The Internet Key Exchange [13] to establish
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. All link-local PIM protocol messages use SPI 0.
The Security Policy Database at a PIM router should be configured to The Security Policy Database at a PIM router should be configured to
ensure that all incoming and outgoing Join/Prune, Assert, and Hello ensure that all incoming and outgoing Join/Prune, Assert, and Hello
packets use the SA associated with the interface to which the packet is packets use the SA associated with the interface to which the packet is
sent. sent.
Note that, according to [7] there is nominally a different Security Note that, according to [7] there is nominally a different Security
Association Database (SAD) for each router interface. Thus, the Association Database (SAD) for each router interface. Thus, the
selected Security Association for an inbound PIM packet can vary
selected Security Association for an inbound PIM packet can vary
depending on the interface on which the packet arrived. This fact depending on the interface on which the packet arrived. This fact
allows the network administrator to use different authentication methods allows the network administrator to use different authentication methods
for each link, even though the destination address is the same for all for each link, even though the destination address is the same for all
link-local PIM packets, regardless of interface. link-local PIM packets, regardless of 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.
skipping to change at page 138, line 51 skipping to change at page 139, line 4
the key distribution problem is simplified. Note however, that this the key distribution problem is simplified. Note however, that this
method has the property that, in order to change the authentication method has the property that, in order to change the authentication
method or authentication key used, all routers in the domain must be method or authentication key used, all routers in the domain must be
updated. updated.
6.3.2.2. Register-Stop messages 6.3.2.2. Register-Stop messages
Similarly, the Security Policy Database at each Rendezvous Point should Similarly, the Security Policy Database at each Rendezvous Point should
be configured to choose a Security Association to use when sending be configured to choose a Security Association to use when sending
Register-Stop messages. Because Register-Stop messages are unicast to Register-Stop messages. Because Register-Stop messages are unicast to
the destination DR, a different Security Association and a potentially
the destination DR, a different Security Association and a potentially
unique SPI is required for each DR. unique SPI is required for each DR.
In order to simplify the management problem, it may be acceptable to use In order to simplify the management problem, it may be acceptable to use
the same authentication algorithm and authentication parameters, the same authentication algorithm and authentication parameters,
regardless of the sending RP and regardless of the destination DR. regardless of the sending RP and regardless of the destination DR.
Although a unique Security Association is needed for each DR, the same Although a unique Security Association is needed for each DR, the same
authentication algorithm and authentication algorithm parameters (secret authentication algorithm and authentication algorithm parameters (secret
key) can be shared by all DRs and by all RPs. key) can be shared by all DRs and by all RPs.
6.4. Denial of Service Attacks 6.4. Denial of Service Attacks
skipping to change at page 140, line 24 skipping to change at page 140, line 24
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,
including ideas, comments, and corrections from Deborah Estrin, Dino including ideas, comments, and corrections from Deborah Estrin, Dino
Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C. Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C.
Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott
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] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan,
"Internet Group Management Protocol, Version 3", RFC 3376. "Internet Group Management Protocol, Version 3", RFC 3376.
skipping to change at page 142, line 5 skipping to change at page 142, line 5
[14] S. Kent, "IP Encapsulating Security Payload (ESP)", draft-ietf- [14] S. Kent, "IP Encapsulating Security Payload (ESP)", draft-ietf-
ipsec-esp-v3-06.txt, work in progress. ipsec-esp-v3-06.txt, work in progress.
[15] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP) [15] 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-04.txt, work in progress. embeddedrp-04.txt, work in progress.
[16] D. Thaler, "Interoperability Rules for Multicast Routing [16] D. Thaler, "Interoperability Rules for Multicast Routing
Protocols", RFC 2715. Protocols", RFC 2715.
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 [16] 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.
We note that multiple PIM-SM domains are sometimes connected together | We note that multiple PIM-SM domains are sometimes connected together
using protocols such as MSDP, which provides information about active | using protocols such as MSDP, which provides information about active
external sources, but does not follow RFC 2715. In such cases the | external sources, but does not follow RFC 2715. In such cases the
domains are not connected via PMBRs because Join(S,G) messages traverse | domains are not connected via PMBRs because Join(S,G) messages traverse
the border between domains. A PMBR is required when no PIM messages can | the border between domains. A PMBR is required when no PIM messages can
traverse the border. | traverse the border.
11.1. Sources External to the PIM-SM Domain | 11.1. Sources External to the PIM-SM Domain
A PMBR needs to ensure that traffic from multicast sources external to | A PMBR needs to ensure that traffic from multicast sources external to
the PIM-SM domain reaches receivers inside the domain. The PMBR will | the PIM-SM domain reaches receivers inside the domain. The PMBR will
follow the rules in RFC 2715, such that traffic from external sources | follow the rules in RFC 2715, such that traffic from external sources
reaches the PMBR itself. | reaches the PMBR itself.
According to RFC 2715, the PIM-SM component of the PMBR will receive an | According to RFC 2715, the PIM-SM component of the PMBR will receive an
(S,G) Creation event when data from an (S,G) data packet from an | (S,G) Creation event when data from an (S,G) data packet from an
external source first reaches the PMBR. If RPF_interface(S) is an | external source first reaches the PMBR. If RPF_interface(S) is an
interface in the PIM-SM domain, the packet cannot be originated into the | interface in the PIM-SM domain, the packet cannot be originated into the
PIM domain at this router, and the PIM-SM component of the PMBR will not | PIM domain at this router, and the PIM-SM component of the PMBR will not
process the packet. Otherwise the PMBR will then act exactly as if it | process the packet. Otherwise the PMBR will then act exactly as if it
were the DR for this source (see Section 4.4.1), with the following | were the DR for this source (see Section 4.4.1), with the following
modifications: | modifications:
o The Border-bit is set in all PIM Register message sent for these | o The Border-bit is set in all PIM Register message sent for these
sources. | sources.
o DirectlyConnected(S) is treated as being TRUE for these sources. | o DirectlyConnected(S) is treated as being TRUE for these sources.
o The PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to be | o The PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to be
TRUE if iif is any interface that is not part of the PIM-SM component | TRUE if iif is any interface that is not part of the PIM-SM component
of the PMBR (see Section 4.2). | of the PMBR (see Section 4.2).
11.2. Sources Internal to the PIM-SM Domain | 11.2. Sources Internal to the PIM-SM Domain
A PMBR needs to ensure that traffic from sources inside the PIM-SM | A PMBR needs to ensure that traffic from sources inside the PIM-SM
domain reaches receivers outside the domain. Using terminology from RFC | domain reaches receivers outside the domain. Using terminology from RFC
2715, there are two possible scenarios for this: | 2715, there are two possible scenarios for this:
o Another component of the PMBR is a wildcard receiver. In this case | o Another component of the PMBR is a wildcard receiver. In this case
the PIM-SM component of the PMBR must ensure that traffic from all | the PIM-SM component of the PMBR must ensure that traffic from all
internal sources reaches the PMBR until it is informed otherwise. | internal sources reaches the PMBR until it is informed otherwise.
Note that certain profiles of PIM-SM, e.g., PIM-SSM, PIM-SM with | Note that certain profiles of PIM-SM, e.g., PIM-SSM, PIM-SM with
Embedded RP, cannot interoperate with a neighboring wildcard receiver | Embedded RP, cannot interoperate with a neighboring wildcard receiver
domain. | domain.
o No other component of the PMBR is a wildcard receiver. In this case | o No other component of the PMBR is a wildcard receiver. In this case
the PMBR will receive explicit information as to which groups or | the PMBR will receive explicit information as to which groups or
(source,group) pairs the external domains wish to receive. | (source,group) pairs the external domains wish to receive.
In the former case, the PMBR will need to send a Join(*,*,RP) to all the | In the former case, the PMBR will need to send a Join(*,*,RP) to all the
active RPs in the PIM-SM domain. It may also send a Join(*,*,RP) to all | active RPs in the PIM-SM domain. It may also send a Join(*,*,RP) to all
the candidate RPs in the PIM-SM domain. This will cause all traffic in | the candidate RPs in the PIM-SM domain. This will cause all traffic in
the domain to reach the PMBR. The PMBR may then act as if it were a DR | the domain to reach the PMBR. The PMBR may then act as if it were a DR
with directly connected receivers, and trigger the transition to a | with directly connected receivers, and trigger the transition to a
shortest path tree (see Section 4.2.1). | shortest path tree (see Section 4.2.1).
In the latter case, the PMBR will not need to send Join(*,*,RP) | In the latter case, the PMBR will not need to send Join(*,*,RP)
messages. However the PMBR will still need to act as a DR with directly | messages. However the PMBR will still need to act as a DR with directly
connected receivers on behalf of the external receivers in terms of | connected receivers on behalf of the external receivers in terms of
being able to switch to the shortest-path tree for internally-reached | being able to switch to the shortest-path tree for internally-reached
sources. | sources.
According to RFC 2715, the PIM-SM component of the PMBR may receive a | According to RFC 2715, the PIM-SM component of the PMBR may receive a
number of alerts generated by events in the external routing components. | number of alerts generated by events in the external routing components.
To implement the above behavior, one reasonable way to map these alerts | To implement the above behavior, one reasonable way to map these alerts
into PIM-SM state as follows: | into PIM-SM state as follows:
o When a PIM-SM component receives an (S,G) Prune alert, it sets | o When a PIM-SM component receives an (S,G) Prune alert, it sets
local_receiver_include(S,G,I) to FALSE for the discard interface. | local_receiver_include(S,G,I) to FALSE for the discard interface.
o When a PIM-SM component receives a (*,G) Prune alert, it sets | o When a PIM-SM component receives a (*,G) Prune alert, it sets
local_receiver_include(*,G,I) to FALSE for the discard interface. | local_receiver_include(*,G,I) to FALSE for the discard interface.
o When a PIM-SM component receives an (S,G) Join alert, it sets | o When a PIM-SM component receives an (S,G) Join alert, it sets
local_receiver_include(S,G,I) to TRUE for the discard interface. | local_receiver_include(S,G,I) to TRUE for the discard interface.
o When a PIM-SM component receives a (*,G) Join alert, it sets | o When a PIM-SM component receives a (*,G) Join alert, it sets
local_receiver_include(*,G,I) to TRUE for the discard interface. | local_receiver_include(*,G,I) to TRUE for the discard interface.
o When a PIM-SM component receives a (*,*) Join alert, it sets | o When a PIM-SM component receives a (*,*) Join alert, it sets
DownstreamJPState(*,*,RP,I) to Join state on the discard interface for | DownstreamJPState(*,*,RP,I) to Join state on the discard interface for
all RPs in the PIM-SM domain. | all RPs in the PIM-SM domain.
o When a PIM-SM component receives a (*,*) Prune alert, then it sets | o When a PIM-SM component receives a (*,*) Prune alert, then it sets
DownstreamJPState(*,*,RP,I) to NoInfo state on the discard interface | DownstreamJPState(*,*,RP,I) to NoInfo state on the discard interface
for all RPs in the PIM-SM domain. | for all RPs in the PIM-SM domain.
We refer above to the discard interface because the macros and state | We refer above to the discard interface because the macros and state
machines are interface-specific, but we need to have PIM state that is | machines are interface-specific, but we need to have PIM state that is
not associated with any actual PIM-SM interface. Implementors are free | not associated with any actual PIM-SM interface. Implementors are free
to implement this in any reasonable manner. | to implement this in any reasonable manner.
Note that these state changes will then cause additional PIM-SM state | Note that these state changes will then cause additional PIM-SM state
machine transitions in the normal way. | machine transitions in the normal way.
These rules are however not sufficient to allow pruning off the (*,*,RP) | These rules are however not sufficient to allow pruning off the (*,*,RP)
tree. Some additional rules provide guidance as to one way this may be | tree. Some additional rules provide guidance as to one way this may be
done: | done:
o If the PMBR has joined on the (*,*,RP) tree, then it should set | o If the PMBR has joined on the (*,*,RP) tree, then it should set
DownstreamJPState(*,G,I) to JOIN on the discard interface for all | DownstreamJPState(*,G,I) to JOIN on the discard interface for all
active groups. | active groups.
o If the router receives a (S,G) prune alert it will need to set | o If the router receives a (S,G) prune alert it will need to set
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface. | DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.
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
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) . . . . . . . . . . . . . . . . . . . . .16,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
AssertWinerMetric(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 17
AssertWinner(*,G,I). . . . . . . . . . . . . . . . . .17,22,25,93,97,100 AssertWinner(*,G,I). . . . . . . . . . . . . . . . . .17,22,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). . . . . . . . . . . . . . . . . . . . .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). . . . . . . . . . . . . . . . . . . . . . . .16,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
skipping to change at page 146, line 20 skipping to change at page 146, line 19
I_am_DR(I) . . . . . . . . . . . . . . . . . . . . . . . .22,33,40,85,93 I_am_DR(I) . . . . . . . . . . . . . . . . . . . . . . . .22,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,23,85 joins(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . .22,24,85
JT(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . . . 15,61,128,132 JT(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . . . 15,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). . . . . . . . . . . . . . . . . . . . . . . . . . 18,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) . . . . . . . . . . . . . . . . . . . . . . . 34,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) . . . . . . . . . . . . . . . . . . . . . . 22,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(S,G,I). . . . . . . . . . . . . . . . . .85,89,91,93,98
NBR(Interface,IP_address). . . . . . . . . . . . . . . . .26,36,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) . . . . . . . . . . . . . . 14,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,22,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 147, line 39 skipping to change at page 147, line 38
spt_assert_metric(S,I) . . . . . . . . . . . . . . . . . . . . .89,98,99 spt_assert_metric(S,I) . . . . . . . . . . . . . . . . . . . . .89,98,99
SSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11,105 SSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11,105
Suppression_Enabled(I) . . . . . . . . . . . . . . . . . . . . . .36,132 Suppression_Enabled(I) . . . . . . . . . . . . . . . . . . . . . .36,132
SwitchToSptDesired(S,G). . . . . . . . . . . . . . . . . . . . .28,28,43 SwitchToSptDesired(S,G). . . . . . . . . . . . . . . . . . . . .28,28,43
TIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7,14,26 TIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7,14,26
Triggered_Hello_Delay. . . . . . . . . . . . . . . . . . . . . 31,32,129 Triggered_Hello_Delay. . . . . . . . . . . . . . . . . . . . . 31,32,129
t_joinsuppress . . . . . . . . . . . . . . . . . . . . . .63,64,67,69,74 t_joinsuppress . . . . . . . . . . . . . . . . . . . . . .63,64,67,69,74
t_override . . . . . . . . . . . . . . . . . . . . . 63,67,72,77,132,133 t_override . . . . . . . . . . . . . . . . . . . . . 63,67,72,77,132,133
t_override_default . . . . . . . . . . . . . . . . . . . . . . . .36,129 t_override_default . . . . . . . . . . . . . . . . . . . . . . . .36,129
t_periodic . . . . . . . . . . . . . . . . . . . . . . . . .63,67,72,132 t_periodic . . . . . . . . . . . . . . . . . . . . . . . . .63,67,72,132
t_suppressed . . . . . . . . . . . . . . . . . . . . .36,64,69,72,74,132 t_suppressed . . . . . . . . . . . . . . . . . . . . .37,64,69,72,74,132
Update_SPTbit(S,G,iif) . . . . . . . . . . . . . . . . . . . . . . 27,29 Update_SPTbit(S,G,iif) . . . . . . . . . . . . . . . . . . . . . . 27,29
UpstreamJPState(S,G) . . . . . . . . . . . . . . . . . . . . . . .27,107 UpstreamJPState(S,G) . . . . . . . . . . . . . . . . . . . . . . .27,107
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP procedures with respect to rights in RFC documents can be found in BCP
 End of changes. 

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