draft-ietf-pim-sm-v2-new-04.txt   draft-ietf-pim-sm-v2-new-05.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-04.txt Mark Handley/ACIRI draft-ietf-pim-sm-v2-new-05.txt Mark Handley/ICIR
Hugh Holbrook/Cisco Hugh Holbrook/Cisco
Isidor Kouvelas/Cisco Isidor Kouvelas/Cisco
21 November 2001 1 March 2002
Expires: May 2002 Expires: September 2002
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
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at page 2, line 8 skipping to change at page 3, line 5
Abstract Abstract
This document specifies Protocol Independent Multicast - This document specifies Protocol Independent Multicast -
Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol
that can use the underlying unicast routing information base that can use the underlying unicast routing information base
or a separate multicast-capable routing information base. It or a separate multicast-capable routing information base. It
builds unidirectional shared trees rooted at a Rendezvous builds unidirectional shared trees rooted at a Rendezvous
Point (RP) per group, and optionally creates shortest-path Point (RP) per group, and optionally creates shortest-path
trees per source. trees per source.
Note on PIM-SM status
PIM-SM v2 is currently widely implemented and deployed, but the existing
specification in RFC 2362 is insufficient to implement from, and is
incorrect in a number of aspects. This document is a complete re-write
from RFC 2362, and is intended to obsolete RFC 2362. The authors have
attempted to document current practice as far as possible, but a number
of cases have arisen where current practice is clearly incorrect,
typically leading to traffic being black-holed. In these cases we
diverge from current practice, but always in a way that will
interoperate successfully with the legacy PIM v2 implementations that we
are aware of.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions. . . . . . . . . . . . . . . . . . . . . 6
2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . . . . . . 6 2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . 7
3. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . . . . . . 7 3. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . 8
4. Protocol Specification. . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Specification. . . . . . . . . . . . . . . . . 13
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . . 12 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . 13
4.1.1. General Purpose State . . . . . . . . . . . . . . . . . . . 13 4.1.1. General Purpose State . . . . . . . . . . . . . . 14
4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . 15
4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . 16
4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . 17
4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . . . . . . 18 4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . 19
4.1.6. State Summarization Macros. . . . . . . . . . . . . . . . . 19 4.1.6. State Summarization Macros. . . . . . . . . . . . 20
4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . . 24 4.2. Data Packet Forwarding Rules . . . . . . . . . . . . 25
4.2.1. Last hop switchover to the SPT. . . . . . . . . . . . . . . 26 4.2.1. Last hop switchover to the SPT. . . . . . . . . . 27
4.2.2. Setting and Clearing the (S,G) SPT bit. . . . . . . . . . . 26 4.2.2. Setting and Clearing the (S,G) SPT bit. . . . . . 27
4.3. PIM Register Messages. . . . . . . . . . . . . . . . . . . . . 28 4.3. Designated Routers (DR) and Hello Messages . . . . . 29
4.3.1. Sending Register Messages from the DR . . . . . . . . . . . 28 4.3.1. Sending Hello Messages. . . . . . . . . . . . . . 29
4.3.2. Receiving Register Messages at the RP . . . . . . . . . . . 32 4.3.2. DR Election . . . . . . . . . . . . . . . . . . . 31
4.4. PIM Join/Prune Messages. . . . . . . . . . . . . . . . . . . . 33 4.3.3. Reducing Prune Propagation Delay on LANs. . . . . 32
4.4.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . . . . . . 34 4.4. PIM Register Messages. . . . . . . . . . . . . . . . 35
4.4.2. Receiving (*,G) Join/Prune Messages . . . . . . . . . . . . 37 4.4.1. Sending Register Messages from the DR . . . . . . 35
4.4.3. Receiving (S,G) Join/Prune Messages . . . . . . . . . . . . 41 4.4.2. Receiving Register Messages at the RP . . . . . . 39
4.4.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . . . . 45 4.5. PIM Join/Prune Messages. . . . . . . . . . . . . . . 41
4.4.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . . . . . . 51 4.5.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . 42
4.4.6. Sending (*,G) Join/Prune Messages . . . . . . . . . . . . . 55 4.5.2. Receiving (*,G) Join/Prune Messages . . . . . . . 45
4.4.7. Sending (S,G) Join/Prune Messages . . . . . . . . . . . . . 59 4.5.3. Receiving (S,G) Join/Prune Messages . . . . . . . 49
4.4.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . . . . . . 64 4.5.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . 52
4.4.9. State Machine for (S,G,rpt) Triggered 4.5.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . 58
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.5.6. Sending (*,G) Join/Prune Messages . . . . . . . . 62
4.5. PIM Assert Messages. . . . . . . . . . . . . . . . . . . . . . 69 4.5.7. Sending (S,G) Join/Prune Messages . . . . . . . . 66
4.5.1. (S,G) Assert Message State Machine. . . . . . . . . . . . . 69 4.5.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . 71
4.5.2. (*,G) Assert Message State Machine. . . . . . . . . . . . . 77 4.5.9. State Machine for (S,G,rpt) Triggered
4.5.3. Assert Metrics. . . . . . . . . . . . . . . . . . . . . . . 83 Messages . . . . . . . . . . . . . . . . . . . . . . . . 72
4.5.4. AssertCancel Messages . . . . . . . . . . . . . . . . . . . 84 4.6. PIM Assert Messages. . . . . . . . . . . . . . . . . 76
4.5.5. Assert State Macros . . . . . . . . . . . . . . . . . . . . 84 4.6.1. (S,G) Assert Message State Machine. . . . . . . . 76
4.6. Designated Routers (DR) and Hello Messages . . . . . . . . . . 87 4.6.2. (*,G) Assert Message State Machine. . . . . . . . 84
4.6.1. Sending Hello Messages. . . . . . . . . . . . . . . . . . . 87 4.6.3. Assert Metrics. . . . . . . . . . . . . . . . . . 91
4.6.2. DR Election . . . . . . . . . . . . . . . . . . . . . . . . 89 4.6.4. AssertCancel Messages . . . . . . . . . . . . . . 92
4.6.3. Reducing Prune Propagation Delay on LANs. . . . . . . . . . 90 4.6.5. Assert State Macros . . . . . . . . . . . . . . . 93
4.7. PIM Multicast Border Router Behavior . . . . . . . . . . . . . 93 4.7. PIM Multicast Border Router Behavior . . . . . . . . 96
4.7.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.7.1. Sources External to the PIM-SM Domain . . . . . . 96
4.7.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.7.2. Sources Internal to the PIM-SM Domain . . . . . . 97
4.8. PIM Bootstrap and RP Discovery . . . . . . . . . . . . . . . . 95 4.8. PIM Bootstrap and RP Discovery . . . . . . . . . . . 98
4.8.1. Group-to-RP Mapping . . . . . . . . . . . . . . . . . . . . 97 4.8.1. Group-to-RP Mapping . . . . . . . . . . . . . . . 99
4.8.2. Hash Function . . . . . . . . . . . . . . . . . . . . . . . 97 4.8.2. Hash Function . . . . . . . . . . . . . . . . . . 100
4.9. Source-Specific Multicast. . . . . . . . . . . . . . . . . . . 98 4.9. Source-Specific Multicast. . . . . . . . . . . . . . 101
4.9.1. Protocol Modifications for SSM destination 4.9.1. Protocol Modifications for SSM destination
addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 addresses. . . . . . . . . . . . . . . . . . . . . . . . 102
4.9.2. PIM-SSM-only Routers. . . . . . . . . . . . . . . . . . . . 99 4.9.2. PIM-SSM-only Routers. . . . . . . . . . . . . . . 102
4.10. PIM Packet Formats. . . . . . . . . . . . . . . . . . . . . . 101 4.10. PIM Packet Formats. . . . . . . . . . . . . . . . . 104
4.10.1. Encoded Source and Group Address 4.10.1. Encoded Source and Group Address
Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Formats. . . . . . . . . . . . . . . . . . . . . . . . . 105
4.10.2. Hello Message Format . . . . . . . . . . . . . . . . . . . 105 4.10.2. Hello Message Format . . . . . . . . . . . . . . 108
4.10.3. Register Message Format. . . . . . . . . . . . . . . . . . 107 4.10.3. Register Message Format. . . . . . . . . . . . . 110
4.10.4. RegisterStop Message Format. . . . . . . . . . . . . . . . 109 4.10.4. RegisterStop Message Format. . . . . . . . . . . 112
4.10.5. Join/Prune Message Format. . . . . . . . . . . . . . . . . 109 4.10.5. Join/Prune Message Format. . . . . . . . . . . . 112
4.10.5.1. Group Set Source List Rules . . . . . . . . . . . . . . 112 4.10.5.1. Group Set Source List Rules . . . . . . . . . 115
4.10.5.2. Group Set Fragmentation . . . . . . . . . . . . . . . . 115 4.10.5.2. Group Set Fragmentation . . . . . . . . . . . 119
4.10.6. Assert Message Format. . . . . . . . . . . . . . . . . . . 116 4.10.6. Assert Message Format. . . . . . . . . . . . . . 119
4.11. PIM Timers. . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.11. PIM Timers. . . . . . . . . . . . . . . . . . . . . 121
4.12. Timer Values. . . . . . . . . . . . . . . . . . . . . . . . . 119 4.12. Timer Values. . . . . . . . . . . . . . . . . . . . 122
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 125 5. IANA Considerations . . . . . . . . . . . . . . . . . . 128
5.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . . 125 5.1. PIM Address Family . . . . . . . . . . . . . . . . . 128
5.2. PIM Hello Options. . . . . . . . . . . . . . . . . . . . . . . 126 5.2. PIM Hello Options. . . . . . . . . . . . . . . . . . 129
6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 126 6. Security Considerations . . . . . . . . . . . . . . . . 129
6.1. Attacks based on forged messages . . . . . . . . . . . . . . . 126 6.1. Attacks based on forged messages . . . . . . . . . . 129
6.1.1. Forged link-local messages. . . . . . . . . . . . . . . . . 126 6.1.1. Forged link-local messages. . . . . . . . . . . . 129
6.1.2. Forged unicast messages . . . . . . . . . . . . . . . . . . 127 6.1.2. Forged unicast messages . . . . . . . . . . . . . 130
6.2. Non-cryptographic Authentication Mechanisms. . . . . . . . . . 127 6.2. Non-cryptographic Authentication Mechanisms. . . . . 130
6.3. Authentication using IPsec . . . . . . . . . . . . . . . . . . 128 6.3. Authentication using IPsec . . . . . . . . . . . . . 131
6.3.1. Protecting link-local multicast messages. . . . . . . . . . 128 6.3.1. Protecting link-local multicast messages. . . . . 131
6.3.2. Protecting unicast messages . . . . . . . . . . . . . . . . 129 6.3.2. Protecting unicast messages . . . . . . . . . . . 132
6.3.2.1. Register messages. . . . . . . . . . . . . . . . . . . . 129 6.3.2.1. Register messages. . . . . . . . . . . . . . . 132
6.3.2.2. Register Stop messages . . . . . . . . . . . . . . . . . 129 6.3.2.2. Register Stop messages . . . . . . . . . . . . 132
6.4. Denial of Service Attacks. . . . . . . . . . . . . . . . . . . 130 6.4. Denial of Service Attacks. . . . . . . . . . . . . . 133
7. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 130 7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 133
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 131 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 134
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 9. References. . . . . . . . . . . . . . . . . . . . . . . 134
10. Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 10. Index. . . . . . . . . . . . . . . . . . . . . . . . . 136
List of Figures
Figure 1. Per-(S,G) register state-machine at a DR . . . . 36
Figure 2. Downstream (*,*,RP) per-interface
state-machine. . . . . . . . . . . . . . . . . . . . . . . 42
Figure 3. Downstream (*,G) per-interface
state-machine. . . . . . . . . . . . . . . . . . . . . . . 46
Figure 4. Downstream per-interface (S,G)
state-machine. . . . . . . . . . . . . . . . . . . . . . . 50
Figure 5. Downstream per-interface (S,G,rpt)
state-machine. . . . . . . . . . . . . . . . . . . . . . . 53
Figure 6. Upstream (*,*,RP) state-machine. . . . . . . . . 58
Figure 7. Upstream (*,G) state-machine . . . . . . . . . . 62
Figure 8. Upstream (S,G) state-machine . . . . . . . . . . 67
Figure 9. Upstream (S,G,rpt) state-machine for trig-
gered messages . . . . . . . . . . . . . . . . . . . . . . 72
Figure 10. Per-interface (S,G) Assert
State-machine. . . . . . . . . . . . . . . . . . . . . . . 78
Figure 11. (*,G) Assert State-machine. . . . . . . . . . . 85
1. Introduction 1. Introduction
This document specifies a protocol for efficiently routing multicast This document specifies a protocol for efficiently routing multicast
groups that may span wide-area (and inter-domain) internets. This groups that may span wide-area (and inter-domain) internets. This
protocol is called Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol is called Protocol Independent Multicast - Sparse Mode (PIM-SM)
because, although it may use the underlying unicast routing to provide because, although it may use the underlying unicast routing to provide
reverse-path information for multicast tree building, it is not reverse-path information for multicast tree building, it is not
dependent on any particular unicast routing protocol. dependent on any particular unicast routing protocol.
skipping to change at page 5, line 50 skipping to change at page 6, line 50
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. If the LAN has directly connected hosts, then a connected to it. If the LAN has directly connected hosts, then a
single one of these routers, the DR, will act on behalf of those single one of these routers, the DR, will act on behalf of those
hosts with respect to the PIM-SM protocol. A single DR is elected hosts with respect to the PIM-SM protocol. A single DR is elected
per LAN using a simple election process. per interface (LAN or otherwise) 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 12, line 18 skipping to change at page 13, line 18
RP for that group. RP for that group.
4. Protocol Specification 4. Protocol Specification
The specification of PIM-SM is broken into several parts: The specification of PIM-SM is broken into several parts:
o Section 4.1 details the protocol state stored. o Section 4.1 details the protocol state stored.
o Section 4.2 specifies the data packet forwarding rules. o Section 4.2 specifies the data packet forwarding rules.
o Section 4.3 specifies the PIM Register generation and processing o Section 4.3. specifies Designated Router (DR) election and the rules
rules. for sending and processing Hello messages.
o Section 4.4 specifies the PIM Join/Prune generation and processing o Section 4.4 specifies the PIM Register generation and processing
rules. rules.
o Section 4.5 specifies the PIM Assert generation and processing rules. o Section 4.5 specifies the PIM Join/Prune generation and processing
rules.
o Designated Router (DR) election is specified in Section 4.6. o Section 4.6 specifies the PIM Assert generation and processing rules.
o Section 4.8 specifies the RP discovery mechanisms. o Section 4.8 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.9. SSM, is described in Section 4.9.
o PIM packet formats are specified in Section 4.10. o PIM packet formats are specified in Section 4.10.
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.11. Section 4.11.
skipping to change at page 14, line 18 skipping to change at page 15, line 18
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
suppression state are described in section 4.6.3. Designated Router suppression state are described in section 4.3.3. Designated Router
state is described in section 4.6. state is described in section 4.3.
4.1.2. (*,*,RP) State 4.1.2. (*,*,RP) State
For every RP a router keeps the following state: For every RP a router keeps the following state:
(*,*,RP) state: (*,*,RP) state:
For each interface: For each interface:
PIM (*,*,RP) Join/Prune State: PIM (*,*,RP) Join/Prune State:
skipping to change at page 14, line 45 skipping to change at page 15, line 45
o Join/Prune Expiry Timer (ET) o Join/Prune Expiry Timer (ET)
Not interface specific: Not interface specific:
o Upstream Join/Prune Timer (JT) o Upstream Join/Prune Timer (JT)
o Last RPF Neighbor towards RP that was used o Last RPF Neighbor towards RP that was used
PIM (*,*,RP) Join/Prune state is the result of receiving PIM (*,*,RP) PIM (*,*,RP) Join/Prune state is the result of receiving PIM (*,*,RP)
Join/Prune messages on this interface, and is specified in section Join/Prune messages on this interface, and is specified in section
4.4.1. 4.5.1.
The upstream (*,*,RP) Join/Prune timer is used to send out periodic The upstream (*,*,RP) Join/Prune timer is used to send out periodic
Join(*,*,RP) messages, and to override Prune(*,*,RP) messages from peers Join(*,*,RP) messages, and to override Prune(*,*,RP) messages from peers
on an upstream LAN interface. on an upstream LAN interface.
The last RPF neighbor towards the RP is stored because if the MRIB The last RPF neighbor towards the RP is stored because if the MRIB
changes then the RPF neighbor towards the RP may change. If it does so, changes then the RPF neighbor towards the RP may change. If it does so,
then we need to trigger a new Join(*,*,RP) to the new upstream neighbor then we need to trigger a new Join(*,*,RP) to the new upstream neighbor
and a Prune(*,*,RP) to the old upstream neighbor. Similarly, if a and a Prune(*,*,RP) to the old upstream neighbor. Similarly, if a
router detects through a changed GenID in a Hello message that the router detects through a changed GenID in a Hello message that the
upstream neighbor towards the RP has rebooted, then it should re- upstream neighbor towards the RP has rebooted, then it should re-
instantiate state by sending a Join(*,*,RP). These mechanisms are instantiate state by sending a Join(*,*,RP). These mechanisms are
specified in Section 4.4.5. specified in Section 4.5.5.
4.1.3. (*,G) State 4.1.3. (*,G) State
For every group G a router keeps the following state: For every group G a router keeps the following state:
(*,G) state: (*,G) state:
For each interface: For each interface:
Local Membership: Local Membership:
State: One of {"NoInfo", "Include"} State: One of {"NoInfo", "Include"}
skipping to change at page 16, line 14 skipping to change at page 17, line 14
assert on this interface for this group, although implementations may assert on this interface for this group, although implementations may
optionally keep this state in case they become the DR or assert winner. optionally keep this state in case they become the DR or assert winner.
We recommend storing this information if possible, as it reduces latency We recommend storing this information if possible, as it reduces latency
converging to stable operating conditions after a failure causing a converging to stable operating conditions after a failure causing a
change of DR. This information is used by the pim_include(*,G) macro change of DR. This information is used by the pim_include(*,G) macro
described in section 4.1.6. described in section 4.1.6.
PIM (*,G) Join/Prune state is the result of receiving PIM (*,G) PIM (*,G) Join/Prune state is the result of receiving PIM (*,G)
Join/Prune messages on this interface, and is specified in section Join/Prune messages on this interface, and is specified in section
4.4.2. The state is used by the macros that calculate the outgoing 4.5.2. The state is used by the macros that calculate the outgoing
interface list in section 4.1.6, and in the JoinDesired(*,G) macro interface list in section 4.1.6, and in the JoinDesired(*,G) macro
(defined in section 4.4.6) that is used in deciding whether a Join(*,G) (defined in section 4.5.6) that is used in deciding whether a Join(*,G)
should be sent upstream. should be sent upstream.
(*,G) Assert Winner state is the result of sending or receiving (*,G) (*,G) Assert Winner state is the result of sending or receiving (*,G)
Assert messages on this interface. It is specified in section 4.5.2. Assert messages on this interface. It is specified in section 4.6.2.
The upstream (*,G) Join/Prune timer is used to send out periodic The upstream (*,G) Join/Prune timer is used to send out periodic
Join(*,G) messages, and to override Prune(*,G) messages from peers on an Join(*,G) messages, and to override Prune(*,G) messages from peers on an
upstream LAN interface. upstream LAN interface.
The last RP used must be stored because if the RP Set changes (section The last RP used must be stored because if the RP Set changes (section
4.8) then state must be torn down and rebuilt for groups whose RP 4.8) then state must be torn down and rebuilt for groups whose RP
changes. changes.
The last RPF neighbor towards the RP is stored because if the MRIB The last RPF neighbor towards the RP is stored because if the MRIB
changes then the RPF neighbor towards the RP may change. If it does so, changes then the RPF neighbor towards the RP may change. If it does so,
then we need to trigger a new Join(*,G) to the new upstream neighbor and then we need to trigger a new Join(*,G) to the new upstream neighbor and
a Prune(*,G) to the old upstream neighbor. Similarly, if a router a Prune(*,G) to the old upstream neighbor. Similarly, if a router
detects through a changed GenID in a Hello message that the upstream detects through a changed GenID in a Hello message that the upstream
neighbor towards the RP has rebooted, then it should re-instantiate neighbor towards the RP has rebooted, then it should re-instantiate
state by sending a Join(*,G). These mechanisms are specified in Section state by sending a Join(*,G). These mechanisms are specified in Section
4.4.6. 4.5.6.
4.1.4. (S,G) State 4.1.4. (S,G) State
For every source/group pair (S,G) a router keeps the following state: For every source/group pair (S,G) a router keeps the following state:
(S,G) state: (S,G) state:
For each interface: For each interface:
Local Membership: Local Membership:
skipping to change at page 17, line 46 skipping to change at page 18, line 46
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
used by the pim_include(S,G) macro described in section 4.1.6. used by the pim_include(S,G) macro described in section 4.1.6.
PIM (S,G) Join/Prune state is the result of receiving PIM (S,G) PIM (S,G) Join/Prune state is the result of receiving PIM (S,G)
Join/Prune messages on this interface, and is specified in section Join/Prune messages on this interface, and is specified in section
4.4.2. The state is used by the macros that calculate the outgoing 4.5.2. The state is used by the macros that calculate the outgoing
interface list in section 4.1.6, and in the JoinDesired(S,G) macro interface list in section 4.1.6, and in the JoinDesired(S,G) macro
(defined in section 4.4.7) that is used in deciding whether a Join(S,G) (defined in section 4.5.7) that is used in deciding whether a Join(S,G)
should be sent upstream. should be sent upstream.
(S,G) Assert Winner state is the result of sending or receiving (S,G) (S,G) Assert Winner state is the result of sending or receiving (S,G)
Assert messages on this interface. It is specified in section 4.5.1. Assert messages on this interface. It is specified in section 4.6.1.
The upstream (S,G) Join/Prune timer is used to send out periodic The upstream (S,G) Join/Prune timer is used to send out periodic
Join(S,G) messages, and to override Prune(S,G) messages from peers on an Join(S,G) messages, and to override Prune(S,G) messages from peers on an
upstream LAN interface. upstream LAN interface.
The last RPF neighbor towards S is stored because if the MRIB changes The last RPF neighbor towards S is stored because if the MRIB changes
then the RPF neighbor towards S may change. If it does so, then we need then the RPF neighbor towards S may change. If it does so, then we need
to trigger a new Join(S,G) to the new upstream neighbor and a Prune(S,G) to trigger a new Join(S,G) to the new upstream neighbor and a Prune(S,G)
to the old upstream neighbor. Similarly, if the router detects through to the old upstream neighbor. Similarly, if the router detects through
a changed GenID in a Hello message that the upstream neighbor towards S a changed GenID in a Hello message that the upstream neighbor towards S
has rebooted, then it should re-instantiate state by sending a has rebooted, then it should re-instantiate state by sending a
Join(S,G). These mechanisms are specified in Section 4.4.7. Join(S,G). These mechanisms are specified in Section 4.5.7.
The SPTbit is used to indicate whether forwarding is taking place on the The SPTbit is used to indicate whether forwarding is taking place on the
(S,G) Shortest Path Tree (SPT) or on the (*,G) tree. A router can have (S,G) Shortest Path Tree (SPT) or on the (*,G) tree. A router can have
(S,G) state and still be forwarding on (*,G) state during the interval (S,G) state and still be forwarding on (*,G) state during the interval
when the source-specific tree is being constructed. When SPTbit is when the source-specific tree is being constructed. When SPTbit is
FALSE, only (*,G) forwarding state is used to forward packets from S to FALSE, only (*,G) forwarding state is used to forward packets from S to
G. When SPTbit is TRUE, both (*,G) and (S,G) forwarding state are used. G. When SPTbit is TRUE, both (*,G) and (S,G) forwarding state are used.
The (S,G) Keepalive Timer is updated by data being forwarded using this The (S,G) Keepalive Timer is updated by data being forwarded using this
(S,G) forwarding state. It is used to keep (S,G) state alive in the (S,G) forwarding state. It is used to keep (S,G) state alive in the
skipping to change at page 19, line 26 skipping to change at page 20, line 26
IGMPv3 inconsistencies between LAN members have been resolved. It need IGMPv3 inconsistencies between LAN members have been resolved. It need
not be kept if this router is not the DR on that interface unless this not be kept if this router is not the DR on that interface unless this
router won a (*,G) assert on this interface for this group. However, we router won a (*,G) assert on this interface for this group. However, we
recommend storing this information if possible, as it reduces latency recommend storing this information if possible, as it reduces latency
converging to stable operating conditions after a failure causing a converging to stable operating conditions after a failure causing a
change of DR. This information is used by the pim_exclude(S,G) macro change of DR. This information is used by the pim_exclude(S,G) macro
described in section 4.1.6. described in section 4.1.6.
PIM (S,G,rpt) Join/Prune state is the result of receiving PIM (S,G,rpt) PIM (S,G,rpt) Join/Prune state is the result of receiving PIM (S,G,rpt)
Join/Prune messages on this interface, and is specified in section Join/Prune messages on this interface, and is specified in section
4.4.4. The state is used by the macros that calculate the outgoing 4.5.4. The state is used by the macros that calculate the outgoing
interface list in section 4.1.6, and in the rules for adding interface list in section 4.1.6, and in the rules for adding
Prune(S,G,rpt) messages to Join(*,G) messages specified in section Prune(S,G,rpt) messages to Join(*,G) messages specified in section
4.4.8. 4.5.8.
The upstream (S,G,rpt) Join/Prune state is used along with the Override The upstream (S,G,rpt) Join/Prune state is used along with the Override
Timer to send the correct override messages in response to Join/Prune Timer to send the correct override messages in response to Join/Prune
messages sent by upstream peers on a LAN. This state and behavior are messages sent by upstream peers on a LAN. This state and behavior are
specified in section 4.4.9. specified in section 4.5.9.
4.1.6. State Summarization Macros 4.1.6. State Summarization Macros
Using this state, we define the following "macro" definitions which we Using this state, we define the following "macro" definitions which we
will use in the descriptions of the state machines and pseudocode in the will use in the descriptions of the state machines and pseudocode in the
following sections. following sections.
The most important macros are those that define the outgoing interface The most important macros are those that define the outgoing interface
list (or "olist") for the relevant state. An olist can be "immediate" list (or "olist") for the relevant state. An olist can be "immediate"
if it is built directly from the state of the relevant type. For if it is built directly from the state of the relevant type. For
skipping to change at page 21, line 28 skipping to change at page 22, line 28
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
PrunePending } PrunePending }
DownstreamJPState(*,*,RP,I) is the state of the finite state machine in DownstreamJPState(*,*,RP,I) is the state of the finite state machine in
section 4.4.1. section 4.5.1.
The set "joins(*,G)" is the set of all interfaces on which the router The set "joins(*,G)" is the set of all interfaces on which the router
has received (*,G) Joins: has received (*,G) Joins:
joins(*,G) = joins(*,G) =
{ all interfaces I such that { all interfaces I such that
DownstreamJPState(*,G,I) is either Join or PrunePending } DownstreamJPState(*,G,I) is either Join or PrunePending }
DownstreamJPState(*,G,I) is the state of the finite state machine in DownstreamJPState(*,G,I) is the state of the finite state machine in
section 4.4.2. section 4.5.2.
The set "joins(S,G)" is the set of all interfaces on which the router The set "joins(S,G)" is the set of all interfaces on which the router
has received (S,G) Joins: has received (S,G) Joins:
joins(S,G) = joins(S,G) =
{ all interfaces I such that { all interfaces I such that
DownstreamJPState(S,G,I) is either Join or PrunePending } DownstreamJPState(S,G,I) is either Join or PrunePending }
DownstreamJPState(S,G,I) is the state of the finite state machine in DownstreamJPState(S,G,I) is the state of the finite state machine in
section 4.4.3. section 4.5.3.
The set "prunes(S,G,rpt)" is the set of all interfaces on which the The set "prunes(S,G,rpt)" is the set of all interfaces on which the
router has received (*,G) joins and (S,G,rpt) prunes. router has received (*,G) joins and (S,G,rpt) prunes.
prunes(S,G,rpt) = prunes(S,G,rpt) =
{ all interfaces I such that { all interfaces I such that
DownstreamJPState(S,G,rpt,I) is Prune or PruneTmp } DownstreamJPState(S,G,rpt,I) is Prune or PruneTmp }
DownstreamJPState(S,G,rpt,I) is the state of the finite state machine in DownstreamJPState(S,G,rpt,I) is the state of the finite state machine in
section 4.4.4. section 4.5.4.
The set "lost_assert(*,G)" is the set of all interfaces on which the The set "lost_assert(*,G)" is the set of all interfaces on which the
router has received (*,G) joins but has lost a (*,G) assert. The macro router has received (*,G) joins but has lost a (*,G) assert. The macro
lost_assert(*,G,I) is defined in Section 4.5.5. lost_assert(*,G,I) is defined in Section 4.6.5.
lost_assert(*,G) = lost_assert(*,G) =
{ all interfaces I such that { all interfaces I such that
lost_assert(*,G,I) == TRUE } lost_assert(*,G,I) == TRUE }
The set "lost_assert(S,G,rpt)" is the set of all interfaces on which the The set "lost_assert(S,G,rpt)" is the set of all interfaces on which the
router has received (*,G) joins but has lost an (S,G) assert. The macro router has received (*,G) joins but has lost an (S,G) assert. The macro
lost_assert(S,G,rpt,I) is defined in Section 4.5.5. lost_assert(S,G,rpt,I) is defined in Section 4.6.5.
lost_assert(S,G,rpt) = lost_assert(S,G,rpt) =
{ all interfaces I such that { all interfaces I such that
lost_assert(S,G,rpt,I) == TRUE } lost_assert(S,G,rpt,I) == TRUE }
The set "lost_assert(S,G)" is the set of all interfaces on which the The set "lost_assert(S,G)" is the set of all interfaces on which the
router has received (S,G) joins but has lost an (S,G) assert. The macro router has received (S,G) joins but has lost an (S,G) assert. The macro
lost_assert(S,G,I) is defined in Section 4.5.5. lost_assert(S,G,I) is defined in Section 4.6.5.
lost_assert(S,G) = lost_assert(S,G) =
{ all interfaces I such that { all interfaces I such that
lost_assert(S,G,I) == TRUE } lost_assert(S,G,I) == TRUE }
The following pseudocode macro definitions are also used in many places The following pseudocode macro definitions are also used in many places
in the specification. Basically RPF' is the RPF neighbor towards an RP in the specification. Basically RPF' is the RPF neighbor towards an RP
or source unless a PIM-Assert has overridden the normal choice of or source unless a PIM-Assert has overridden the normal choice of
neighbor. neighbor.
skipping to change at page 23, line 38 skipping to change at page 24, line 38
RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets
should be coming and to which joins should be sent on the RP tree and should be coming and to which joins should be sent on the RP tree and
SPT respectively. SPT respectively.
RPF'(S,G,rpt) is basically RPF'(*,G) modified by the result of an RPF'(S,G,rpt) is basically RPF'(*,G) modified by the result of an
Assert(S,G) on RPF_interface(RP(G)). In such a case, packets from S Assert(S,G) on RPF_interface(RP(G)). In such a case, packets from S
will be originating from a different router than RPF'(*,G). If we only will be originating from a different router than RPF'(*,G). If we only
have active (*,G) Join state, we need to accept packets from have active (*,G) Join state, we need to accept packets from
RPF'(S,G,rpt), and add a Prune(S,G,rpt) to the periodic Join(*,G) RPF'(S,G,rpt), and add a Prune(S,G,rpt) to the periodic Join(*,G)
messages that we send to RPF'(*,G) (See Section 4.4.8). messages that we send to RPF'(*,G) (See Section 4.5.8).
The function MRIB.next_hop( S ) returns the next-hop PIM neighbor toward The function MRIB.next_hop( S ) returns the next-hop PIM neighbor toward
the host S, as indicated by the current MRIB. If S is directly 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 G, adjacent, then MRIB.next_hop( S ) returns NULL. At the RP for G,
MRIB.next_hop( RP(G )) returns NULL. MRIB.next_hop( RP(G )) returns NULL.
I_Am_Assert_Loser(S, G, I) is true if the Assert start machine (in I_Am_Assert_Loser(S, G, I) is true if the Assert start machine (in
section 4.5.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 start machine (in I_Am_Assert_Loser(*, G, I) is true if the Assert start machine (in
section 4.5.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
skipping to change at page 26, line 10 skipping to change at page 27, line 10
inherited_olist(S,G,rpt) is the outgoing interface for packets forwarded inherited_olist(S,G,rpt) is the outgoing interface for packets forwarded
on (*,*,RP) or (*,G) state taking into account (S,G,rpt) prune state, on (*,*,RP) or (*,G) state taking into account (S,G,rpt) prune state,
and asserts, etc. and asserts, etc.
Update_SPTbit(S,G,iif) is defined in section 4.2.2. Update_SPTbit(S,G,iif) is defined in section 4.2.2.
CheckSwitchToSpt(S,G) is defined in section 4.2.1. CheckSwitchToSpt(S,G) is defined in section 4.2.1.
UpstreamJPState(S,G) is the state of the finite state machine in section UpstreamJPState(S,G) is the state of the finite state machine in section
4.4.7. 4.5.7.
Keepalive_Period is defined in Section 4.11. Keepalive_Period is defined in Section 4.11.
Data triggered PIM-Assert messages sent from the above forwarding code Data triggered PIM-Assert messages sent from the above forwarding code
should be rate-limited in a implementation-dependent manner. should be rate-limited in a implementation-dependent manner.
4.2.1. Last hop switchover to the SPT 4.2.1. Last hop switchover to the SPT
In Sparse-Mode PIM, last-hop routers join the shared tree towards the In Sparse-Mode PIM, last-hop routers join the shared tree towards the
RP. Once traffic from sources to joined groups arrives at a last-hop RP. Once traffic from sources to joined groups arrives at a last-hop
skipping to change at page 26, line 36 skipping to change at page 27, line 36
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) ) {
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 threshhold" 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.
4.2.2. Setting and Clearing the (S,G) SPT bit 4.2.2. Setting and Clearing the (S,G) SPT bit
The (S,G) SPTbit is used to distinguish whether to forward on The (S,G) SPTbit is used to distinguish whether to forward on
(*,*,RP)/(*,G) or on (S,G) state. When switching from the RP tree to (*,*,RP)/(*,G) or on (S,G) state. When switching from the RP tree to
the source tree, there is a transition period when data is arriving due the source tree, there is a transition period when data is arriving due
skipping to change at page 27, line 26 skipping to change at page 28, line 26
OR RPF_interface(S) != RPF_interface(RP) OR RPF_interface(S) != RPF_interface(RP)
OR inherited_olist(S,G,rpt) == NULL OR inherited_olist(S,G,rpt) == NULL
OR RPF'(S,G) == RPF'(*,G) ) ) { OR RPF'(S,G) == RPF'(*,G) ) ) {
Set SPTbit(S,G) to TRUE Set SPTbit(S,G) to TRUE
} }
} }
Additionally a router sets SPTbit(S,G) to TRUE when it receives an Additionally a router sets SPTbit(S,G) to TRUE when it receives an
Assert(S,G) on RPF_interface(S). Assert(S,G) on RPF_interface(S).
JoinDesired(S,G) is defined in Section 4.4.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 SPT bit if we have the appropriate Basically Update_SPTbit will set the SPT bit 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.
skipping to change at page 28, line 6 skipping to change at page 29, line 6
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 SPT bit is cleared in the (S,G) upstream state machine (see Section The SPT bit is cleared in the (S,G) upstream state machine (see Section
4.4.7) when JoinDesired(S,G) becomes FALSE. 4.5.7) when JoinDesired(S,G) becomes FALSE.
4.3. PIM Register Messages 4.3. Designated Routers (DR) and Hello Messages
A shared-media LAN like Ethernet may have multiple PIM-SM routers
connected to it. If the LAN has directly connected hosts, then a single
one of these routers, the DR, will act on behalf of those hosts with
respect to the PIM-SM protocol. Because the distinction between LANs
and point-to-point interfaces can sometimes be blurred, and because
routers may also have multicast host functionality, the PIM-SM
specification makes no distinction between the two. Thus DR election
will happen on all interfaces, LAN or otherwise.
DR election is performed using Hello messages. Hello messages are also
the way that option negotiation takes place in PIM, so that additional
functionality can be enabled, or parameters tuned.
4.3.1. Sending Hello Messages
PIM-Hello messages are sent periodically on each PIM-enabled interface.
They allow a router to learn about the neighboring PIM routers on each
interface. Hello messages are also the mechanism used to elect a
Designated Router (DR), and to negotiate additional capabilities A
router must record the Hello information received from each PIM
neighbor.
Hello messages MUST be sent on all active interfaces, including physical
point-to-point links, and are multicast to address 224.0.0.13 (the ALL-
PIM-ROUTERS group).
We note that some implementations do not send Hello messages
on point-to-point interfaces. This is non-compliant behavior.
A compliant PIM router MUST send Hello messages, even on
point-to-point interfaces.
A per interface hello timer (HT(I)) is used to trigger sending Hello
messages on each active interface. When PIM is enabled on an interface
or a router first starts, the hello timer of that interface is set to a
random value between 0 and Triggered_Hello_Delay. This prevents
synchronization of Hello messages if multiple routers are powered on
simultaneously. After the initial randomized interval, Hello messages
must be sent every Hello_Period seconds. The hello timer should not be
reset except when it expires.
Note that neighbors will not accept Join/Prune or Assert messages from a
router unless they have first heard a Hello message from that router.
Thus if a router needs to send a Join/Prune or Assert message on an
interface on which it has not yet sent a Hello message, then it MUST
immediately send the relevant without Hello message without waiting for
the Hello timer to expire, followed by the Join/Prune or Assert message.
The DR_Election_Priority Option allows a network administrator to give
preference to a particular router in the DR election process by giving
it a numerically larger DR Election Priority. The DR_Election_Priority
Option SHOULD be included in every Hello message, even if no DR election
priority is explicitly configured on that interface. This is necessary
because priority-based DR election is only enabled when all neighbors on
an interface advertise that they are capable of using the DR Election
Priority Option. The default priority is 1.
The Generation_Identifier (GenID) Option SHOULD be included in all Hello
messages. The GenID option contains a randomly generated 32-bit value
that is regenerated each time PIM forwarding is started or restarted on
the interface, including when the router itself restarts. When a Hello
message with a new GenID is received from a neighbor, any old Hello
information about that neighbor SHOULD be discarded and superseded by
the information from the new Hello message. This may cause a new DR to
be chosen on that interface.
The LAN_Prune_Delay Option SHOULD be included in all Hello messages sent
on multi-access LANs. This option advertises a router's capability to
use values other than the default for the Propagation_Delay and
Override_Interval which affect the setting of the Prune Pending,
Upstream Join and Override Timers (defined in section 4.11).
To allow new or rebooting routers to learn of PIM neighbors quickly,
when a Hello message is received from a new neighbor, or a Hello message
with a new GenID is received from an existing neighbor, a new Hello
message should be sent on this interface after a randomized delay
between 0 and Triggered_Hello_Delay. This triggered message need not
change the timing of the scheduled periodic message. If a router needs
to send a Join/Prune to the new neighbor or send an Assert message in
response to an Assert message from the new neighbor before this
randomized delay has expired, then it MUST immediately send the relevant
without Hello message without waiting for the Hello timer to expire,
followed by the Join/Prune or Assert message. If it does not do this,
then the new neighbor will discard the Join/Prune or Assert message.
Before an interface goes down or changes IP address, a Hello message
with a zero HoldTime should be sent immediately (with the old IP address
if the IP address changed). This will cause PIM neighbors to remove
this neighbor (or its old IP address) immediately.
4.3.2. DR Election
When a PIM-Hello message is received on interface I the following
information about the sending neighbor is recorded:
neighbor.interface
The interface on which the Hello message arrived.
neighbor.ip_address
The IP address of the PIM neighbor.
neighbor.genid
The Generation ID of the PIM neighbor.
neighbor.dr_priority
The DR Priority field of the PIM neighbor if it is present in
the Hello message.
neighbor.dr_priority_present
A flag indicating if the DR Priority field was present in the
Hello message.
neighbor.timeout
A timer value to time out the neighbor state when it becomes
stale.
The Neighbor Liveness Timer (NLT(N,I)) is reset to
Hello_Holdtime (from the Hello Holdtime option) whenever a
Hello message is received containing a Holdtime option, or to
Default_Hello_Holdtime if the Hello message does not contain
the Holdtime option.
Neighbor state is deleted when the neighbor timeout expires.
The function for computing the DR on interface I is:
host
DR(I) {
dr = me
for each neighbor on interface I {
if ( dr_is_better( neighbor, dr, I ) == TRUE ) {
dr = neighbor
}
}
return dr
}
The function used for comparing DR "metrics" on interface I is:
bool
dr_is_better(a,b,I) {
if( there is a neighbor n on I for which n.dr_priority_present
is false ) {
return a.ip_address > b.ip_address
} else {
return ( a.dr_priority > b.dr_priority ) OR
( a.dr_priority == b.dr_priority AND
a.ip_address > b.ip_address )
}
}
The trivial function I_am_DR(I) is defined to aid readability:
bool
I_am_DR(I) {
return DR(I) == me
}
The DR election 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 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
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
determined by that state-machine.
We note that some PIM implementations do not send Hello
messages on point-to-point interfaces, and so cannot perform
DR election on such interfaces. This in non-compliant
behavior. DR election MUST be performed on ALL active PIM-SM
interfaces.
4.3.3. Reducing Prune Propagation Delay on LANs
In addition to the information recorded for the DR Election, the
following per neighbor information is obtained from the LAN Prune Delay
Hello option:
neighbor.lan_prune_delay_present
A flag indicating if the LAN Prune Delay option was present in
the Hello message.
neighbor.tracking_support
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
the neighbor's capability to disable Join message suppression.
neighbor.lan_delay
The LAN Delay field of the LAN Prune Delay option (if present)
in the Hello message.
neighbor.override_interval
The Override_Interval field of the LAN Prune Delay option (if
present) in the Hello message.
The additional state described above is deleted along with the DR
neighbor state when the neighbor timeout expires.
Just like the DR priority option, the information provided in the LAN
Prune Delay option is not used unless all neighbors on a link advertise
the option. The function below computes this state:
bool
lan_delay_enabled(I) {
for each neighbor on interface I {
if ( neighbor.lan_prune_delay_present == false ) {
return false
}
}
return true
}
The LAN Delay inserted by a router in the LAN Prune Delay option
expresses the expected message propagation delay on the link and should
be configurable by the system administrator. It is used by upstream
routers to figure out how long they should wait for a Join override
message before pruning an interface.
PIM implementors should enforce a lower bound on the permitted values
for this delay to allow for scheduling and processing delays within
their router. Such delays may cause received messages to be processed
later as well as triggered messages to be sent later than intended.
Setting this LAN Prune Delay to too low a value may result in temporary
forwarding outages because a downstream router will not be able to
override a neighbor's Prune message before the upstream neighbor stops
forwarding.
When all routers on a link are in a position to negotiate a different
than default Propagation Delay, the largest value from those advertised
by each neighbor is chosen. The function for computing the Propagation
Delay of interface I is:
time_interval
Propagation_Delay(I) {
if ( lan_delay_enabled(I) == false ) {
return LAN_delay_default
}
delay = 0
for each neighbor on interface I {
if ( neighbor.lan_delay > delay ) {
delay = neighbor.lan_delay
}
}
return delay
}
To avoid synchronization of override messages when multiple downstream
routers share a multi-access link, sending of such messages is delayed
by a small random amount of time. The period of randomization should
represent the size of the PIM router population on the link. Each
router expresses its view of the amount of randomization necessary in
the Override Delay field of the LAN Prune Delay option.
When all routers on a link are in a position to negotiate a different
than default Override Delay, the largest value from those advertised by
each neighbor is chosen. The function for computing the Override
Interval of interface I is:
time_interval
Override_Interval(I) {
if ( lan_delay_enabled(I) == false ) {
return t_override_default
}
delay = 0
for each neighbor on interface I {
if ( neighbor.override_interval > delay ) {
delay = neighbor.override_interval
}
}
return delay
}
Although the mechanisms are not specified in this document, it is
possible for upstream routers to explicitly track the join membership of
individual downstream routers if Join suppression is disabled. A router
can advertise its willingness to disable Join suppression by using the T
bit in the LAN Prune Delay Hello option. Unless all PIM routers on a
link negotiate this capability, explicit tracking and the disabling of
the Join suppression mechanism are not possible. The function for
computing the state of Suppression on interface I is:
bool
Suppression_Enabled(I) {
if ( lan_delay_enabled(I) == false ) {
return true
}
for each neighbor on interface I {
if ( neighbor.tracking_support == false ) {
return true
}
}
return false
}
Note that the setting of Suppression_Enabled(I) affects the value of
t_suppressed (see section 4.11).
4.4. PIM Register Messages
Overview Overview
The Designated Router (DR) on a LAN or point-to-point link encapsulates The Designated Router (DR) on a LAN or point-to-point link encapsulates
multicast packets from local sources to the RP for the relevant group multicast packets from local sources to the RP for the relevant group
unless it recently received a Register Stop message for that (S,G) or unless it recently received a Register Stop message for that (S,G) or
(*,G) from the RP. When the DR receives a Register Stop message from (*,G) from the RP. When the DR receives a Register Stop message from
the RP, it starts a Register Stop timer to maintain this state. Just the RP, it starts a Register Stop timer to maintain this state. Just
before the Register Stop timer expires, the DR sends a Null-Register before the Register Stop timer expires, the DR sends a Null-Register
Message to the RP to allow the RP to refresh the Register Stop Message to the RP to allow the RP to refresh the Register Stop
information at the DR. If the Register Stop timer actually expires, the information at the DR. If the Register Stop timer actually expires, the
DR will resume encapsulating packets from the source to the RP. DR will resume encapsulating packets from the source to the RP.
4.3.1. Sending Register Messages from the DR 4.4.1. Sending Register Messages from the DR
Every PIM-SM router has the capability to be a DR. The state machine Every PIM-SM router has the capability to be a DR. The state machine
below is used to implement Register functionality. For the purposes of below is used to implement Register functionality. For the purposes of
specification, we represent the mechanism to encapsulate packets to the specification, we represent the mechanism to encapsulate packets to the
RP as a Register-Tunnel interface, which is added to or removed from the RP as a Register-Tunnel interface, which is added to or removed from the
(S,G) olist. The tunnel interface then takes part in the normal packet (S,G) olist. The tunnel interface then takes part in the normal packet
forwarding rules is specified in Section 4.2. forwarding rules is specified in Section 4.2.
If register state is maintained, it is maintained only for directly If register state is maintained, it is maintained only for directly
connected sources, and is per-(S,G). There are four states in the DR's connected sources, and is per-(S,G). There are four states in the DR's
skipping to change at page 29, line 8 skipping to change at page 37, line 5
The register tunnel is pruned but the DR is contemplating adding it The register tunnel is pruned but the DR is contemplating adding it
back. back.
No Info (NI) No Info (NI)
No information. This is the initial state, and the state when the No information. This is the initial state, and the state when the
router is not the DR. router is not the DR.
In addition, a RegisterStop timer (RST) is kept if the state machine in In addition, a RegisterStop timer (RST) is kept if the state machine in
not in the No Info state. not in the No Info state.
+-----------------------------------+ Figure 1: Per-(S,G) register state-machine at a DR in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 1: Per-(S,G) register state-machine at a DR
In tabular form, the state-machine is:
+-----------++------------------------------------------------------------------------------------------+ +-----------++------------------------------------------------------------------------------------------+
| || Event | | || Event |
| ++------------------+------------------+----------------------+--------------+--------------+ | ++------------------+------------------+----------------------+--------------+--------------+
|Prev State ||Register-Stop |Could-Register | Could-Register |Register- |RP changed | |Prev State ||Register-Stop |Could-Register | Could-Register |Register- |RP changed |
| ||Timer expires |->True | ->False |Stop | | | ||Timer expires |->True | ->False |Stop | |
| || | | |received | | | || | | |received | |
+-----------++------------------+------------------+----------------------+--------------+--------------+ +-----------++------------------+------------------+----------------------+--------------+--------------+
|No Info ||- |-> J state | - |- |- | |No Info ||- |-> J state | - |- |- |
|(NI) || |add reg tunnel | | | | |(NI) || |add reg tunnel | | | |
skipping to change at page 32, line 15 skipping to change at page 40, line 5
some circumstances. some circumstances.
We specify that an RP should not send RegisterStop(*,G) messages, but We specify that an RP should not send RegisterStop(*,G) messages, but
for compatibility, a DR should be able to accept one if it is received. for compatibility, a DR should be able to accept one if it is received.
A RegisterStop(*,G) should be treated as a RegisterStop(S,G) for all A RegisterStop(*,G) should be treated as a RegisterStop(S,G) for all
existing (S,G) Register state machines. A router should not apply a existing (S,G) Register state machines. A router should not apply a
RegisterStop(*,G) to sources that become active after the RegisterStop(*,G) to sources that become active after the
RegisterStop(*,G) was received. RegisterStop(*,G) was received.
4.3.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 that this should not happen if the lower layer is working # note that this should not happen if the lower layer is working
} }
if( I_am_RP( G ) && outer.dst == RP(G) ) { if( I_am_RP( G ) && outer.dst == RP(G) ) {
skipping to change at page 33, line 39 skipping to change at page 41, line 26
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 [2]. discussed in [2].
4.4. PIM Join/Prune Messages 4.5. PIM Join/Prune Messages
A PIM Join/Prune message consists of a list of groups and a list of A PIM Join/Prune message consists of a list of groups and a list of
Joined and Pruned sources for each group. When processing a received Joined and Pruned sources for each group. When processing a received
Join/Prune message, each Joined or Pruned source for a Group is Join/Prune message, each Joined or Pruned source for a Group is
effectively considered individually, and applies to one or more of the effectively considered individually, and applies to one or more of the
following state machines. When considering a Join/Prune message whose following state machines. When considering a Join/Prune message whose
PIM Destination field addresses this router, (*,G) Joins and Prunes can PIM Destination field addresses this router, (*,G) Joins and Prunes can
affect both the (*,G) and (S,G,rpt) downstream state machines, while affect both the (*,G) and (S,G,rpt) downstream state machines, while
(*,*,RP), (S,G) and (S,G,rpt) Joins and Prunes can only affect their (*,*,RP), (S,G) and (S,G,rpt) Joins and Prunes can only affect their
respective downstream state machines. When considering a Join/Prune respective downstream state machines. When considering a Join/Prune
message whose PIM Destination field addresses another router, most Join message whose PIM Destination field addresses another router, most Join
or Prune messages could affect each upstream state machine. or Prune messages could affect each upstream state machine.
4.4.1. Receiving (*,*,RP) Join/Prune Messages In general, a PIM Join/Prune message should only be accepted for
processing if it comes from a known PIM neighbor. A PIM router hears
about PIM neighbors through PIM Hello messages. If a router receives a
Join/Prune message from a particular IP source address and it has not
seen a PIM Hello message from that source address, then the Join/Prune
message SHOULD be discarded without further processing. In addition, if
the Hello message from a neighbor was authenticated using IPsec AH (see
section 6.3) then all Join/Prune messages from that neighbor MUST also
be authenticated using IPsec AH.
We note that some older PIM implementations incorrectly fail to send
Hello messages on point-to-point interfaces, so we also RECOMMEND that a
configuration option be provided to allow interoperation with such older
routers, but that this configuration option SHOULD NOT be enabled by
default.
4.5.1. Receiving (*,*,RP) Join/Prune Messages
The per-interface state-machine for receiving (*,*,RP) Join/Prune The per-interface state-machine for receiving (*,*,RP) Join/Prune
Messages is given below. There are three states: Messages is given below. There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (*,*,RP) Join state and no timers The interface has no (*,*,RP) Join state and no timers
running. running.
Join (J) Join (J)
The interface has (*,*,RP) Join state which will cause us to The interface has (*,*,RP) Join state which will cause us to
forward packets destined for any group handled by RP from this forward packets destined for any group handled by RP from this
interface except if there is also (S,G,rpt) prune information interface except if there is also (S,G,rpt) prune information
(see Section 4.4.4) or the router lost an assert on this (see Section 4.5.4) or the router lost an assert on this
interface. interface.
PrunePending (PP) PrunePending (PP)
The router has received a Prune(*,*,RP) on this interface from The router has received a Prune(*,*,RP) on this interface from
a downstream neighbor and is waiting to see whether the prune a downstream neighbor and is waiting to see whether the prune
will be overridden by another downstream router. For will be overridden by another downstream router. For
forwarding purposes, the PrunePending state functions exactly forwarding purposes, the PrunePending state functions exactly
like the Join state. like the Join state.
In addition the state-machine uses two timers: In addition the state-machine uses two timers:
skipping to change at page 34, line 40 skipping to change at page 43, line 5
ExpiryTimer (ET) ExpiryTimer (ET)
This timer is restarted when a valid Join(*,*,RP) is received. This timer is restarted when a valid Join(*,*,RP) is received.
Expiry of the ExpiryTimer causes the interface state to revert Expiry of the ExpiryTimer causes the interface state to revert
to NoInfo for this RP. to NoInfo for this RP.
PrunePendingTimer (PPT) PrunePendingTimer (PPT)
This timer is set when a valid Prune(*,*,RP) is received. This timer is set when a valid Prune(*,*,RP) is received.
Expiry of the PrunePendingTimer causes the interface state to Expiry of the PrunePendingTimer causes the interface state to
revert to NoInfo for this RP. revert to NoInfo for this RP.
+-----------------------------------+ Figure 2: Downstream (*,*,RP) per-interface state-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 2: Downstream (*,*,RP) per-interface state-machine
In tabular form, the per-interface (*,*,RP) state-machine is:
+-------------++---------------------------------------------------------+ +-------------++---------------------------------------------------------+
| || 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 | - | - |
skipping to change at page 35, line 42 skipping to change at page 43, line 42
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 address on the
received interface. If the destination address is not correct, these received interface. If the destination address is not correct, these
state transitions in this state machine must not occur, although seeing state transitions in this state machine must not occur, although seeing
such a packet may cause state transitions in other state machines. 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 PIM messages with a destination address of all zeros is recommend that PIM messages with a destination address of all zeros are
also accepted. 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 address on I.
skipping to change at page 37, line 43 skipping to change at page 45, line 43
onto the subnet connected to interface I. onto the subnet connected to interface I.
The action "Send PruneEcho(*,*,RP)" is triggered when the The action "Send PruneEcho(*,*,RP)" is triggered when the
router stops forwarding on an interface as a result of a router stops forwarding on an interface as a result of a
prune. A PruneEcho(*,*,RP) is simply a Prune(*,*,RP) message prune. A PruneEcho(*,*,RP) is simply a Prune(*,*,RP) message
sent by the upstream router on a LAN with its own address in sent by the upstream router on a LAN with its own address in
the Upstream Neighbor Address field. Its purpose is to add the Upstream Neighbor Address field. Its purpose is to add
additional reliability so that if a Prune that should have additional reliability so that if a Prune that should have
been overridden by another router is lost locally on the LAN, been overridden by another router is lost locally on the LAN,
then the PruneEcho may be received and cause the override to then the PruneEcho may be received and cause the override to
happen. A PruneEcho(*,*,RP) need not be sent on a point-to- happen. A PruneEcho(*,*,RP) need not be sent on an interface
point interface. containing only one PIM neighbor.
4.4.2. Receiving (*,G) Join/Prune Messages 4.5.2. Receiving (*,G) Join/Prune Messages
When a router receives a Join(*,G) or Prune(*,G) it must first check to When a router receives a Join(*,G) or Prune(*,G) it must first check to
see whether the RP in the message matches RP(G) (the router's idea of see whether the RP in the message matches RP(G) (the router's idea of
who the RP is). If the RP in the message does not match RP(G) the Join who the RP is). If the RP in the message does not match RP(G) the Join
or Prune should be silently dropped. If a router has no RP information or Prune should be silently dropped. If a router has no RP information
(e.g. has not recently received a BSR message) then it may choose to (e.g. has not recently received a BSR message) then it may choose to
accept Join(*,G) or Prune(*,G) and treat the RP in the message as RP(G). accept Join(*,G) or Prune(*,G) and treat the RP in the message as RP(G).
The per-interface state-machine for receiving (*,G) Join/Prune Messages The per-interface state-machine for receiving (*,G) Join/Prune Messages
is given below. There are three states: is given below. There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (*,G) Join state and no timers running. The interface has no (*,G) Join state and no timers running.
Join (J) Join (J)
The interface has (*,G) Join state which will cause us to The interface has (*,G) Join state which will cause us to
forward packets destined for G from this interface except if forward packets destined for G from this interface except if
there is also (S,G,rpt) prune information (see Section 4.4.4) there is also (S,G,rpt) prune information (see Section 4.5.4)
or the router lost an assert on this interface. or the router lost an assert on this interface.
PrunePending (PP) PrunePending (PP)
The router has received a Prune(*,G) on this interface from a The router has received a Prune(*,G) on this interface from a
downstream neighbor and is waiting to see whether the prune downstream neighbor and is waiting to see whether the prune
will be overridden by another downstream router. For will be overridden by another downstream router. For
forwarding purposes, the PrunePending state functions exactly forwarding purposes, the PrunePending state functions exactly
like the Join state. like the Join state.
In addition the state-machine uses two timers: In addition the state-machine uses two timers:
skipping to change at page 38, line 39 skipping to change at page 47, line 5
ExpiryTimer (ET) ExpiryTimer (ET)
This timer is restarted when a valid Join(*,G) is received. This timer is restarted when a valid Join(*,G) is received.
Expiry of the ExpiryTimer causes the interface state to revert Expiry of the ExpiryTimer causes the interface state to revert
to NoInfo for this group. to NoInfo for this group.
PrunePendingTimer (PPT) PrunePendingTimer (PPT)
This timer is set when a valid Prune(*,G) is received. Expiry This timer is set when a valid Prune(*,G) is received. Expiry
of the PrunePendingTimer causes the interface state to revert of the PrunePendingTimer causes the interface state to revert
to NoInfo for this group. to NoInfo for this group.
+-----------------------------------+ Figure 3: Downstream (*,G) per-interface state-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 3: Downstream (*,G) per-interface state-machine
In tabular form, the per-interface (*,G) state-machine is:
+-------------++--------------------------------------------------------+ +-------------++--------------------------------------------------------+
| || Event | | || Event |
| ++-------------+-------------+-------------+--------------+ | ++-------------+-------------+-------------+--------------+
|Prev State ||Receive | Receive | Prune | Expiry Timer | |Prev State ||Receive | Receive | Prune | Expiry Timer |
| ||Join(*,G) | Prune(*,G) | Pending | Expires | | ||Join(*,G) | Prune(*,G) | Pending | Expires |
| || | | Timer | | | || | | Timer | |
| || | | Expires | | | || | | Expires | |
+-------------++-------------+-------------+-------------+--------------+ +-------------++-------------+-------------+-------------+--------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
skipping to change at page 41, line 28 skipping to change at page 49, line 28
connected to interface I. connected to interface I.
The action "Send PruneEcho(*,G)" is triggered when the router The action "Send PruneEcho(*,G)" is triggered when the router
stops forwarding on an interface as a result of a prune. A stops forwarding on an interface as a result of a prune. A
PruneEcho(*,G) is simply a Prune(*,G) message sent by the PruneEcho(*,G) is simply a Prune(*,G) message sent by the
upstream router on a LAN with its own address in the Upstream upstream router on a LAN with its own address in the Upstream
Neighbor Address field. Its purpose is to add additional Neighbor Address field. Its purpose is to add additional
reliability so that if a Prune that should have been reliability so that if a Prune that should have been
overridden by another router is lost locally on the LAN, then overridden by another router is lost locally on the LAN, then
the PruneEcho may be received and cause the override to the PruneEcho may be received and cause the override to
happen. A PruneEcho(*,G) need not be sent on a point-to-point happen. A PruneEcho(*,G) need not be sent on an interface
interface. containing only one PIM neighbor.
4.4.3. Receiving (S,G) Join/Prune Messages 4.5.3. Receiving (S,G) Join/Prune Messages
The per-interface state machine for receiving (S,G) Join/Prune messages The per-interface state machine for receiving (S,G) Join/Prune messages
is given below, and is almost identical to that for (*,G) messages. is given below, and is almost identical to that for (*,G) messages.
There are three states: There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (S,G) Join state and no (S,G) timers The interface has no (S,G) Join state and no (S,G) timers
running. running.
Join (J) Join (J)
skipping to change at page 42, line 17 skipping to change at page 50, line 17
ExpiryTimer (ET) ExpiryTimer (ET)
This timer is set when a valid Join(S,G) is received. Expiry This timer is set when a valid Join(S,G) is received. Expiry
of the ExpiryTimer causes this state machine to revert to of the ExpiryTimer causes this state machine to revert to
NoInfo state. NoInfo state.
PrunePendingTimer (PPT) PrunePendingTimer (PPT)
This timer is set when a valid Prune(S,G) is received. Expiry This timer is set when a valid Prune(S,G) is received. Expiry
of the PrunePendingTimer this state machine to revert to of the PrunePendingTimer this state machine to revert to
NoInfo state. NoInfo state.
+-----------------------------------+ Figure 4: Downstream per-interface (S,G) state-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 4: Downstream per-interface (S,G) state-machine
In tabular form, the state machine is:
+-------------++--------------------------------------------------------+ +-------------++--------------------------------------------------------+
| || Event | | || Event |
| ++-------------+-------------+-------------+--------------+ | ++-------------+-------------+-------------+--------------+
|Prev State ||Receive | Receive | Prune | Expiry Timer | |Prev State ||Receive | Receive | Prune | Expiry Timer |
| ||Join(S,G) | Prune(S,G) | Pending | Expires | | ||Join(S,G) | Prune(S,G) | Pending | Expires |
| || | | Timer | | | || | | Timer | |
| || | | Expires | | | || | | Expires | |
+-------------++-------------+-------------+-------------+--------------+ +-------------++-------------+-------------+-------------+--------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
skipping to change at page 44, line 50 skipping to change at page 52, line 43
connected to interface I. connected to interface I.
The action "Send PruneEcho(S,G)" is triggered when the router The action "Send PruneEcho(S,G)" is triggered when the router
stops forwarding on an interface as a result of a prune. A stops forwarding on an interface as a result of a prune. A
PruneEcho(S,G) is simply a Prune(S,G) message sent by the PruneEcho(S,G) is simply a Prune(S,G) message sent by the
upstream router on a LAN with its own address in the Upstream upstream router on a LAN with its own address in the Upstream
Neighbor Address field. Its purpose is to add additional Neighbor Address field. Its purpose is to add additional
reliability so that if a Prune that should have been reliability so that if a Prune that should have been
overridden by another router is lost locally on the LAN, then overridden by another router is lost locally on the LAN, then
the PruneEcho may be received and cause the override to the PruneEcho may be received and cause the override to
happen. A PruneEcho(S,G) need not be sent on a point-to-point happen. A PruneEcho(S,G) need not be sent on an interface
interface. containing only one PIM neighbor.
4.4.4. Receiving (S,G,rpt) Join/Prune Messages 4.5.4. Receiving (S,G,rpt) Join/Prune Messages
The per-interface state machine for receiving (S,G,rpt) Join/Prune The per-interface state machine for receiving (S,G,rpt) Join/Prune
messages is given below. There are five states: messages is given below. There are five states:
NoInfo (NI) NoInfo (NI)
The interface has no (S,G,rpt) Prune state and no (S,G,rpt) The interface has no (S,G,rpt) Prune state and no (S,G,rpt)
timers running. timers running.
Prune (P) Prune (P)
The interface has (S,G,rpt) Prune state which will cause us The interface has (S,G,rpt) Prune state which will cause us
skipping to change at page 46, line 10 skipping to change at page 54, line 5
ExpiryTimer (ET) ExpiryTimer (ET)
This timer is set when a valid Prune(S,G,rpt) is received. This timer is set when a valid Prune(S,G,rpt) is received.
Expiry of the ExpiryTimer causes this state machine to revert Expiry of the ExpiryTimer causes this state machine to revert
to NoInfo state. to NoInfo state.
PrunePendingTimer (PPT) PrunePendingTimer (PPT)
This timer is set when a valid Prune(S,G,rpt) is received. This timer is set when a valid Prune(S,G,rpt) is received.
Expiry of the PrunePendingTimer causes this state machine to Expiry of the PrunePendingTimer causes this state machine to
move on to Prune state. move on to Prune state.
+-----------------------------------+ Figure 5: Downstream per-interface (S,G,rpt) state-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 5: Downstream per-interface (S,G,rpt) state-machine
In tabular form, the state machine is:
+----------++----------------------------------------------------------------+ +----------++----------------------------------------------------------------+
| || Event | | || Event |
| ++----------+-----------+-----------+---------+---------+---------+ | ++----------+-----------+-----------+---------+---------+---------+
|Prev ||Receive | Receive | Receive | End of | Prune | Expiry | |Prev ||Receive | Receive | Receive | End of | Prune | Expiry |
|State ||Join(*,G) | Join | Prune | Message | Pending | Timer | |State ||Join(*,G) | Join | Prune | Message | Pending | Timer |
| || | (S,G,rpt) | (S,G,rpt) | | Timer | Expires | | || | (S,G,rpt) | (S,G,rpt) | | Timer | Expires |
| || | | | | Expires | | | || | | | | Expires | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
| ||- | - | -> PP | - | n/a | n/a | | ||- | - | -> PP | - | n/a | n/a |
skipping to change at page 51, line 5 skipping to change at page 58, line 5
Receiving a Join(*,*,RP) does not affect the (S,G,rpt) downstream state Receiving a Join(*,*,RP) does not affect the (S,G,rpt) downstream state
machine. If a router has originated Join(*,*,RP) and pruned a source machine. If a router has originated Join(*,*,RP) and pruned a source
off it using Prune(S,G,rpt), then to receive that source again it should off it using Prune(S,G,rpt), then to receive that source again it should
explicitly re-join using Join(S,G,rpt) or Join(*,G). In some LAN explicitly re-join using Join(S,G,rpt) or Join(*,G). In some LAN
topologies it is possible for a router sending a new Join(*,*,RP) to topologies it is possible for a router sending a new Join(*,*,RP) to
have to wait as much as a Join/Prune Interval before noticing that it have to wait as much as a Join/Prune Interval before noticing that it
needs to override a neighbor's pre-existing Prune(S,G,rpt). This is needs to override a neighbor's pre-existing Prune(S,G,rpt). This is
considered acceptable, as (*,*,RP) state is intended to be used only in considered acceptable, as (*,*,RP) state is intended to be used only in
long-lived and persistent scenarios. long-lived and persistent scenarios.
4.4.5. Sending (*,*,RP) Join/Prune Messages 4.5.5. Sending (*,*,RP) Join/Prune Messages
The per-interface state-machines for (*,*,RP) hold join state from The per-interface state-machines for (*,*,RP) hold join state from
downstream PIM routers. This state then determines whether a router downstream PIM routers. This state then determines whether a router
needs to propagate a Join(*,*,RP) upstream towards the RP. needs to propagate a Join(*,*,RP) upstream towards the RP.
If a router wishes to propagate a Join(*,*,RP) upstream, it must also If a router wishes to propagate a Join(*,*,RP) upstream, it must also
watch for messages on its upstream interface from other routers on that watch for messages on its upstream interface from other routers on that
subnet, and these may modify its behavior. If it sees a Join(*,*,RP) to subnet, and these may modify its behavior. If it sees a Join(*,*,RP) to
the correct upstream neighbor, it should suppress its own Join(*,*,RP). the correct upstream neighbor, it should suppress its own Join(*,*,RP).
If it sees a Prune(*,*,RP) to the correct upstream neighbor, it should If it sees a Prune(*,*,RP) to the correct upstream neighbor, it should
be prepared to override that prune by sending a Join(*,*,RP) almost be prepared to override that prune by sending a Join(*,*,RP) almost
immediately. Finally, if it sees the Generation ID (see Section 4.6) of immediately. Finally, if it sees the Generation ID (see Section 4.3) of
the correct upstream neighbor change, it knows that the upstream the correct upstream neighbor change, it knows that the upstream
neighbor has lost state, and it should be prepared to refresh the state neighbor has lost state, and it should be prepared to refresh the state
by sending a Join(*,*,RP) almost immediately. by sending a Join(*,*,RP) almost immediately.
In addition if the MRIB changes to indicate that the next hop towards In addition if the MRIB changes to indicate that the next hop towards
the RP has changed, the router should prune off from the old next hop, the RP has changed, the router should prune off from the old next hop,
and join towards the new next hop. and join towards the new next hop.
The upstream (*,*,RP) state-machine contains only two states: The upstream (*,*,RP) state-machine contains only two states:
skipping to change at page 51, line 40 skipping to change at page 59, line 5
need to join the (*,*,RP) tree for this RP. need to join the (*,*,RP) tree for this RP.
Joined Joined
The downstream state-machines indicate that the router would like The downstream state-machines indicate that the router would like
to join the (*,*,RP) tree for this RP. to join the (*,*,RP) tree for this RP.
In addition, one timer JT(*,*,RP) is kept which is used to trigger the In addition, one timer JT(*,*,RP) is kept which is used to trigger the
sending of a Join(*,*,RP) to the upstream next hop towards the RP, sending of a Join(*,*,RP) to the upstream next hop towards the RP,
MRIB.next_hop(RP). MRIB.next_hop(RP).
+-----------------------------------+ Figure 6: Upstream (*,*,RP) state-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 6: Upstream (*,*,RP) state-machine
In tabular form, the state machine is:
+-------------------+---------------------------------------------------+ +-------------------+---------------------------------------------------+
| | Event | | | Event |
| Prev State +--------------------------+------------------------+ | Prev State +--------------------------+------------------------+
| | JoinDesired(*,*,RP) | JoinDesired(*,*,RP) | | | JoinDesired(*,*,RP) | JoinDesired(*,*,RP) |
| | ->True | ->False | | | ->True | ->False |
+-------------------+--------------------------+------------------------+ +-------------------+--------------------------+------------------------+
| | -> J state | - | | | -> J state | - |
| NotJoined (NJ) | Send Join(*,*,RP); | | | NotJoined (NJ) | Send Join(*,*,RP); | |
| | Set Join Timer to | | | | Set Join Timer to | |
skipping to change at page 55, line 9 skipping to change at page 62, line 9
MRIB.next_hop(RP) GenID changes MRIB.next_hop(RP) GenID changes
The Generation ID of the router that is MRIB.next_hop(RP) The Generation ID of the router that is MRIB.next_hop(RP)
changes. This normally means that this neighbor has lost changes. This normally means that this neighbor has lost
state, and so the state must be refreshed. state, and so the state must be refreshed.
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.
4.4.6. Sending (*,G) Join/Prune Messages 4.5.6. Sending (*,G) Join/Prune Messages
The per-interface state-machines for (*,G) hold join state from The per-interface state-machines for (*,G) hold join state from
downstream PIM routers. This state then determines whether a router downstream PIM routers. This state then determines whether a router
needs to propagate a Join(*,G) upstream towards the RP. needs to propagate a Join(*,G) upstream towards the RP.
If a router wishes to propagate a Join(*,G) upstream, it must also watch If a router wishes to propagate a Join(*,G) upstream, it must also watch
for messages on its upstream interface from other routers on that for messages on its upstream interface from other routers on that
subnet, and these may modify its behavior. If it sees a Join(*,G) to subnet, and these may modify its behavior. If it sees a Join(*,G) to
the correct upstream neighbor, it should suppress its own Join(*,G). If the correct upstream neighbor, it should suppress its own Join(*,G). If
it sees a Prune(*,G) to the correct upstream neighbor, it should be it sees a Prune(*,G) to the correct upstream neighbor, it should be
prepared to override that prune by sending a Join(*,G) almost prepared to override that prune by sending a Join(*,G) almost
immediately. Finally, if it sees the Generation ID (see Section 4.6) of immediately. Finally, if it sees the Generation ID (see Section 4.3) of
the correct upstream neighbor change, it knows that the upstream the correct upstream neighbor change, it knows that the upstream
neighbor has lost state, and it should be prepared to refresh the state neighbor has lost state, and it should be prepared to refresh the state
by sending a Join(*,G) almost immediately. by sending a Join(*,G) almost immediately.
In addition if the MRIB changes to indicate that the next hop towards In addition if the MRIB changes to indicate that the next hop towards
the RP has changed, the router should prune off from the old next hop, the RP has changed, the router should prune off from the old next hop,
and join towards the new next hop. and join towards the new next hop.
The upstream (*,G) state-machine only contains two states: The upstream (*,G) state-machine only contains two states:
skipping to change at page 55, line 44 skipping to change at page 63, line 5
need to join the RP tree for this group. need to join the RP tree for this group.
Joined Joined
The downstream state-machines indicate that the router would like The downstream state-machines indicate that the router would like
to join the RP tree for this group. to join the RP tree for this group.
In addition, one timer JT(*,G) is kept which is used to trigger the In addition, one timer JT(*,G) is kept which is used to trigger the
sending of a Join(*,G) to the upstream next hop towards the RP, sending of a Join(*,G) to the upstream next hop towards the RP,
RPF'(*,G). RPF'(*,G).
+-----------------------------------+ Figure 7: Upstream (*,G) state-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 7: Upstream (*,G) state-machine
In tabular form, the state machine is:
+--------------------++-------------------------------------------------+ +--------------------++-------------------------------------------------+
| || Event | | || Event |
| Prev State ++------------------------+------------------------+ | Prev State ++------------------------+------------------------+
| || JoinDesired(*,G) | JoinDesired(*,G) | | || JoinDesired(*,G) | JoinDesired(*,G) |
| || ->True | ->False | | || ->True | ->False |
+--------------------++------------------------+------------------------+ +--------------------++------------------------+------------------------+
| || -> J state | - | | || -> J state | - |
| NotJoined (NJ) || Send Join(*,G); | | | NotJoined (NJ) || Send Join(*,G); | |
| || Set Join Timer to | | | || Set Join Timer to | |
skipping to change at page 59, line 27 skipping to change at page 66, line 27
RPF'(*,G) GenID changes RPF'(*,G) GenID changes
The Generation ID of the router that is RPF'(*,G) changes. The Generation ID of the router that is RPF'(*,G) changes.
This normally means that this neighbor has lost state, and so This normally means that this neighbor has lost state, and so
the state must be refreshed. the state must be refreshed.
The upstream (*,G) state machine remains in Joined state. If The upstream (*,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. seconds, reset it so that it expires after t_override seconds.
4.4.7. Sending (S,G) Join/Prune Messages 4.5.7. Sending (S,G) Join/Prune Messages
The per-interface state-machines for (S,G) hold join state from The per-interface state-machines for (S,G) hold join state from
downstream PIM routers. This state then determines whether a router downstream PIM routers. This state then determines whether a router
needs to propagate a Join(S,G) upstream towards the source. needs to propagate a Join(S,G) upstream towards the source.
If a router wishes to propagate a Join(S,G) upstream, it must also watch If a router wishes to propagate a Join(S,G) upstream, it must also watch
for messages on its upstream interface from other routers on that for messages on its upstream interface from other routers on that
subnet, and these may modify its behavior. If it sees a Join(S,G) to subnet, and these may modify its behavior. If it sees a Join(S,G) to
the correct upstream neighbor, it should suppress its own Join(S,G). If the correct upstream neighbor, it should suppress its own Join(S,G). If
it sees a Prune(S,G), Prune(S,G,rpt), or Prune(*,G) to the correct it sees a Prune(S,G), Prune(S,G,rpt), or Prune(*,G) to the correct
skipping to change at page 60, line 18 skipping to change at page 67, line 18
for this (S,G). for this (S,G).
Joined Joined
The downstream state machines and local membership information The downstream state machines and local membership information
indicate that the router should join the shortest-path tree for indicate that the router should join the shortest-path tree for
this (S,G). this (S,G).
In addition, one timer JT(S,G) is kept which is used to trigger the In addition, one timer JT(S,G) is kept which is used to trigger the
sending of a Join(S,G) to the upstream next hop toward S, RPF'(S,G). sending of a Join(S,G) to the upstream next hop toward S, RPF'(S,G).
+-----------------------------------+ Figure 8: Upstream (S,G) state-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 8: Upstream (S,G) state-machine
In tabular form, the state machine is:
+--------------------+--------------------------------------------------+ +--------------------+--------------------------------------------------+
| | Event | | | Event |
| Prev State +-------------------------+------------------------+ | Prev State +-------------------------+------------------------+
| | JoinDesired(S,G) | JoinDesired(S,G) | | | JoinDesired(S,G) | JoinDesired(S,G) |
| | ->True | ->False | | | ->True | ->False |
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
| NotJoined (NJ) | -> J state | - | | NotJoined (NJ) | -> J state | - |
| | Send Join(S,G); | | | | Send Join(S,G); | |
| | Set Join Timer to | | | | Set Join Timer to | |
skipping to change at page 61, line 17 skipping to change at page 68, line 17
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
| Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune | | Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune |
| | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to | | | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to |
| | | | RPF'(S,G) | | | | | RPF'(S,G) |
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
| Send | Increase Join | Decrease Join | Decrease Join | | Send | Increase Join | Decrease Join | Decrease Join |
| Join(S,G); Set | Timer to | Timer to | Timer to | | Join(S,G); Set | Timer to | Timer to | Timer to |
| Join Timer to | t_suppr | t_override | t_override | | Join Timer to | t_joinsuppress | t_override | t_override |
| t_periodic | | | | | t_periodic | | | |
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
+-----------------------+-------------------------+---------------------+ +-----------------+-------------------+----------------+----------------+
| See Prune(*,G) to | MRIB.next_hop(S) | RPF'(S,G) GenID | |See Prune(*,G) | MRIB.next_hop(S) | RPF'(S,G) | RPF'(S,G) |
| RPF'(S,G) | changes | changes | |to RPF'(S,G) | changes | GenID changes | changes |
+-----------------------+-------------------------+---------------------+ +-----------------+-------------------+----------------+----------------+
| Decrease Join | Send Join(S,G) to | Decrease Join | |Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join |
| Timer to | new next hop; Send | Timer to | |Timer to | to new next hop; | Timer to | Timer to |
| t_override | Prune(S,G) to old | t_override | |t_override | Send Prune(S,G) | t_override | t_override |
| | next hop; Set Join | | | | to old next hop; | | |
| | Timer to | | | | Set Join Timer | | |
| | t_periodic | | | | to t_periodic | | |
+-----------------------+-------------------------+---------------------+ +-----------------+-------------------+----------------+----------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(S,G) { bool JoinDesired(S,G) {
return( immediate_olist(S,G) != NULL return( immediate_olist(S,G) != NULL
OR ( KeepaliveTimer(S,G) is running OR ( KeepaliveTimer(S,G) is running
AND inherited_olist(S,G) != NULL ) ) AND inherited_olist(S,G) != NULL ) )
} }
JoinDesired(S,G) is true when the router has forwarding state that would JoinDesired(S,G) is true when the router has forwarding state that would
skipping to change at page 64, line 30 skipping to change at page 71, line 30
RPF'(S,G) GenID changes RPF'(S,G) GenID changes
The Generation ID of the router that is RPF'(S,G) changes. The Generation ID of the router that is RPF'(S,G) changes.
This normally means that this neighbor has lost state, and so This normally means that this neighbor has lost state, and so
the state must be refreshed. the state must be refreshed.
The upstream (S,G) state machine remains in Joined state. If The upstream (S,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. seconds, reset it so that it expires after t_override seconds.
4.4.8. (S,G,rpt) Periodic Messages 4.5.8. (S,G,rpt) Periodic Messages
(S,G,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP tree (S,G,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP tree
with the RPT bit set, either to modify the results of (*,G) Joins, or to with the RPT bit set, either to modify the results of (*,G) Joins, or to
override the behavior of other upstream LAN peers. The next section override the behavior of other upstream LAN peers. The next section
describes the rules for sending triggered messages. This section describes the rules for sending triggered messages. This section
describes the rules for including an Prune(S,G,rpt) message with a describes the rules for including an Prune(S,G,rpt) message with a
Join(*,G). Join(*,G).
When a router is going to send a Join(*,G), it should use the following When a router is going to send a Join(*,G), it should use the following
pseudocode, for each (S,G) for which it has state, to decide whether to pseudocode, for each (S,G) for which it has state, to decide whether to
skipping to change at page 65, line 23 skipping to change at page 72, line 23
add Prune(S,G,rpt) to compound message add Prune(S,G,rpt) to compound message
} else if ( RPF'(*,G) != RPF'(S,G,rpt) { } else if ( RPF'(*,G) != RPF'(S,G,rpt) {
# Note: we joined the shared tree, but there was an (S,G) assert and # Note: we joined the shared tree, but there was an (S,G) assert and
# the source tree RPF neighbor is different. # the source tree RPF neighbor is different.
add Prune(S,G,rpt) to compound message add Prune(S,G,rpt) to compound message
} }
Note that Join(S,G,rpt) is not normally sent as a periodic message, but Note that Join(S,G,rpt) is not normally sent as a periodic message, but
only as a triggered message. only as a triggered message.
4.4.9. State Machine for (S,G,rpt) Triggered Messages 4.5.9. State Machine for (S,G,rpt) Triggered Messages
The state machine for (S,G,rpt) triggered messages is required per-(S,G) The state machine for (S,G,rpt) triggered messages is required per-(S,G)
when there is (*,G) or (*,*,RP) join state at a router, and the router when there is (*,G) or (*,*,RP) join state at a router, and the router
or any of its upstream LAN peers wishes to prune S off the RP tree. or any of its upstream LAN peers wishes to prune S off the RP tree.
There are three states in the state-machine. One of the states is when There are three states in the state-machine. One of the states is when
there is neither (*,G) nor (*,*,RP(G)) join state at this router. If there is neither (*,G) nor (*,*,RP(G)) join state at this router. If
there is (*,G) or (*,*,RP(G)) join state at the router, then the state there is (*,G) or (*,*,RP(G)) join state at the router, then the state
machine must be at one of the other two states: machine must be at one of the other two states:
skipping to change at page 66, line 5 skipping to change at page 73, line 5
NotPruned(S,G,rpt) NotPruned(S,G,rpt)
(*,G) or (*,*,RP(G)) Joined, and (S,G,rpt) not pruned (*,G) or (*,*,RP(G)) Joined, and (S,G,rpt) not pruned
RPTNotJoined(G) RPTNotJoined(G)
neither (*,G) nor (*,*,RP(G)) has not been joined. neither (*,G) nor (*,*,RP(G)) has not been joined.
In addition there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which is In addition there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which is
used to delay triggered Join(S,G,rpt) messages to prevent implosions of used to delay triggered Join(S,G,rpt) messages to prevent implosions of
triggered messages. triggered messages.
+-----------------------------------+ Figure 9: Upstream (S,G,rpt) state-machine for triggered messages in
| Figures omitted from text version | tabular form
+-----------------------------------+
Figure 9: Upstream (S,G,rpt) state-machine for triggered messages
In tabular form, the state machine is:
+--------------++------------------------------------------------------------------+ +--------------++------------------------------------------------------------------+
| || Event | | || Event |
| ++-------------+--------------+-------------------+-----------------+ | ++-------------+--------------+-------------------+-----------------+
|Prev State ||PruneDesired | PruneDesired | RPTJoinDesired(G) | inherited_olist | |Prev State ||PruneDesired | PruneDesired | RPTJoinDesired(G) | inherited_olist |
| ||(S,G,rpt) | (S,G,rpt) | ->False | (S,G,rpt) | | ||(S,G,rpt) | (S,G,rpt) | ->False | (S,G,rpt) |
| ||->True | ->False | | ->non-NULL | | ||->True | ->False | | ->non-NULL |
+--------------++-------------+--------------+-------------------+-----------------+ +--------------++-------------+--------------+-------------------+-----------------+
|RPTNotJoined ||-> P state | - | - | -> NP state | |RPTNotJoined ||-> P state | - | - | -> NP state |
|(G) (NJ) || | | | | |(G) (NJ) || | | | |
skipping to change at page 69, line 40 skipping to change at page 76, line 36
transition should be interpreted as "PruneDesired(S,G,rpt)->FALSE transition should be interpreted as "PruneDesired(S,G,rpt)->FALSE
AND RPTJoinDesired(G)==TRUE" AND RPTJoinDesired(G)==TRUE"
The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt). The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt).
RPTJoinDesired(G)->FALSE RPTJoinDesired(G)->FALSE
This event is relevant in the "Pruned" and "NotPruned" states. This event is relevant in the "Pruned" and "NotPruned" states.
The router no longer wishes to receive any traffic destined for G The router no longer wishes to receive any traffic destined for G
on the RP Tree. This causes a transition to the RPTNotJoined(G) on the RP Tree. This causes a transition to the RPTNotJoined(G)
state, and the Override Timer is cancelled if it was running. Any state, and the Override Timer is canceled if it was running. Any
further actions are handled by the appropriate upstream state further actions are handled by the appropriate upstream state
machine for (*,G) or (*,*,RP). machine for (*,G) or (*,*,RP).
inherited_olist(S,G,rpt) becomes non-NULL inherited_olist(S,G,rpt) becomes non-NULL
This transition is only relevant in the RPTNotJoined(G) state. This transition is only relevant in the RPTNotJoined(G) state.
The router has joined the RP tree (handled by the (*,G) or (*,*,RP) The router has joined the RP tree (handled by the (*,G) or (*,*,RP)
upstream state machine as appropriate), and wants to receive upstream state machine as appropriate), and wants to receive
traffic from S. This does not trigger any events in this state traffic from S. This does not trigger any events in this state
machine, but causes a transition to the NotPruned(S,G,rpt) state. machine, but causes a transition to the NotPruned(S,G,rpt) state.
4.5. PIM Assert Messages 4.6. PIM Assert Messages
4.5.1. (S,G) Assert Message State Machine Where multiple PIM routers peer over a shared LAN it is possible for
more than one upstream router to have valid forwarding state for a
packet, which can lead to packet duplication (see Section 3 "Multi-
access LANs"). PIM does not attempt to prevent this from occurring.
Instead it detects when this has happened and elects a single forwarder
amongst the upstream routers to prevent further duplication. This
election is performed using PIM Assert messages. Assert messages are
also received by downstream routers on the LAN, and these cause
subsequent Join/Prune messages to be sent to the upstream router that
won the Assert.
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
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
Hello message from that source address, then the Assert message SHOULD
be discarded without further processing. In addition, if the Hello
message from a neighbor was authenticated using IPsec AH (see section
6.3) then all Assert messages from that neighbor MUST also be
authenticated using IPsec AH.
4.6.1. (S,G) Assert Message State Machine
The (S,G) Assert state machine for interface I is shown in Figure 10. The (S,G) Assert state machine for interface I is shown in Figure 10.
There are three states: There are three states:
NoInfo (NI) NoInfo (NI)
This router has no (S,G) assert state on interface I. This router has no (S,G) assert state on interface I.
I am Assert Winner (W) I am Assert Winner (W)
This router has won an (S,G) assert on interface I. It is now This router has won an (S,G) assert on interface I. It is now
responsible for forwarding traffic from S destined for G out of responsible for forwarding traffic from S destined for G out of
skipping to change at page 70, line 33 skipping to change at page 78, line 5
I am Assert Loser (L) I am Assert Loser (L)
This router has lost an (S,G) assert on interface I. It must not This router has lost an (S,G) assert on interface I. It must not
forward packets from S destined for G onto interface I. If it is forward packets from S destined for G onto interface I. If it is
the DR on I, it is no longer responsible for forwarding traffic the DR on I, it is no longer responsible for forwarding traffic
onto I to satisfy local hosts with membership requests that onto I to satisfy local hosts with membership requests that
specifically refer to S and G. specifically refer to S and G.
In addition there is also a assert timer (AT) that is used to time out In addition there is also a assert timer (AT) that is used to time out
asserts on the assert losers and to resend asserts on the assert winner. asserts on the assert losers and to resend asserts on the assert winner.
+-----------------------------------+ Figure 10: Per-interface (S,G) Assert State-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 10: Per-interface (S,G) Assert State-machine
In tabular form the state machine is:
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In NoInfo (NI) State | | In NoInfo (NI) State |
+---------------+-------------------+------------------+----------------+ +---------------+-------------------+------------------+----------------+
| Receive | Receive Assert | Data arrives | Receive | | Receive | Receive Assert | Data arrives | Receive |
| Inferior | with RPTbit | from S to G on | Preferred | | Inferior | with RPTbit | from S to G on | Preferred |
| Assert with | set and | I and | Assert with | | Assert with | set and | I and | Assert with |
| RPTbit clear | CouldAssert | CouldAssert | RPTbit clear | | RPTbit clear | CouldAssert | CouldAssert | RPTbit clear |
| and | (S,G,I) | (S,G,I) | and AssTrDes | | and | (S,G,I) | (S,G,I) | and AssTrDes |
| CouldAssert | | | (S,G,I) | | CouldAssert | | | (S,G,I) |
skipping to change at page 71, line 33 skipping to change at page 78, line 33
| In I Am Assert Winner (W) State | | In I Am Assert Winner (W) State |
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
| Timer Expires | Receive | Receive | CouldAssert | | Timer Expires | Receive | Receive | CouldAssert |
| | Inferior | Preferred | (S,G,I) -> | | | 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 | Timer Expires | |Receive | Receive | Receive | Timer | Current |
| Preferred | Inferior | Acceptable | | |Preferred | Acceptable | Inferior | Expires | Winner's |
| Assert | Assert from | Assert from | | |Assert | Assert from | Assert from | | GenID |
| | Current Winner | Current Winner | | | | Current | Current | | changes |
+---------------+------------------+------------------+-----------------+ | | Winner | Winner | | |
| -> L state | -> L state | -> NI state | -> NI state | +-------------+--------------+--------------+--------------+--------------+
| [Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | |-> L state | -> L state | -> NI state | -> NI state | -> NI state |
+---------------+------------------+------------------+-----------------+ |[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] |
+-------------+--------------+--------------+--------------+--------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
+----------------+-----------------+-------------------+----------------+ +----------------+-----------------+-------------------+----------------+
| AssTrDes | my_metric -> | RPF_interface | Receive | | AssTrDes | my_metric -> | RPF_interface | Receive |
| (S,G,I) -> | better than | (S) stops | Join(S,G) on | | (S,G,I) -> | better than | (S) stops | Join(S,G) on |
| FALSE | winner's | being I | interface I | | FALSE | winner's | being I | interface I |
| | metric | | | | | metric | | |
+----------------+-----------------+-------------------+----------------+ +----------------+-----------------+-------------------+----------------+
| -> NI state | -> NI state | -> NI state | -> NI State | | -> NI state | -> NI state | -> NI state | -> NI State |
skipping to change at page 75, line 17 skipping to change at page 82, line 17
own. We transition to "I am Assert Loser" state and perform own. We transition to "I am Assert Loser" state and perform
actions A2 (below). Note that this may affect the value of actions A2 (below). Note that this may affect the value of
JoinDesired(S,G) and PruneDesired(S,G,rpt) which could cause JoinDesired(S,G) and PruneDesired(S,G,rpt) which could cause
transitions in the upstream (S,G) or (S,G,rpt) state machines. transitions in the upstream (S,G) or (S,G,rpt) state machines.
CouldAssert(S,G,I) -> FALSE CouldAssert(S,G,I) -> FALSE
Our (S,G) forwarding state or RPF interface changed so as to Our (S,G) forwarding state or RPF interface changed so as to
make CouldAssert(S,G,I) become false. We can no longer make CouldAssert(S,G,I) become false. We can no longer
perform the actions of the assert winner, and so we transition perform the actions of the assert winner, and so we transition
to NoInfo state and perform actions A4 (below). This includes to NoInfo state and perform actions A4 (below). This includes
sending a "cancelling assert" with an infinite metric. sending a "canceling assert" with an infinite metric.
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.
skipping to change at page 75, line 45 skipping to change at page 82, line 45
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
PIM Join/Prune mechanisms to operate. Usually we will PIM Join/Prune mechanisms to operate. Usually we will
eventually re-assert and win when data packets from S have eventually re-assert and win when data packets from S have
started flowing again. started flowing again.
Timer Expires Timer Expires
The (S,G) assert timer expires. We transition to NoInfo The (S,G) assert timer expires. We transition to NoInfo
state, deleting the (S,G) assert information. state, deleting the (S,G) assert information (action A5
below).
Current Winner's GenID Changes
We receive a Hello message from the current winner reporting a
different GenID from the one it previously reported. This
indicates that the current winner's interface or router has
gone down and come back up, and so we must assume it no longer
knows it was the winner. We transition to the NoInfo state,
deleting this (S,G) assert information (action A5 below).
AssertTrackingDesired(S,G,I)->FALSE AssertTrackingDesired(S,G,I)->FALSE
AssertTrackingDesired(S,G,I) becomes FALSE. Our forwarding AssertTrackingDesired(S,G,I) becomes FALSE. Our forwarding
state has changed so that (S,G) Asserts on interface I are no state has changed so that (S,G) Asserts on interface I are no
longer of interest to us. We transition to the NoInfo state, longer of interest to us. We transition to the NoInfo state,
deleting the (S,G) assert information. deleting the (S,G) assert information.
My metric becomes better than the assert winner's metric My metric becomes better than the assert winner's metric
my_assert_metric(S,G,I) has changed so that now my assert my_assert_metric(S,G,I) has changed so that now my assert
metric for (S,G) is better than the metric we have stored for metric for (S,G) is better than the metric we have stored for
skipping to change at page 77, line 12 skipping to change at page 84, line 22
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 timer to Assert_Time Set timer to Assert_Time
If I is RPF_interface(S) set SPTbit(S,G) to TRUE. If I is RPF_interface(S) 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) 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.5.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:
NoInfo (NI) NoInfo (NI)
This router has no (*,G) assert state on interface I. This router has no (*,G) assert state on interface I.
I am Assert Winner (W) I am Assert Winner (W)
This router has won an (*,G) assert on interface I. It is now This router has won an (*,G) assert on interface I. It is now
responsible for forwarding traffic destined for G onto interface I responsible for forwarding traffic destined for G onto interface I
skipping to change at page 77, line 41 skipping to change at page 85, line 5
I am Assert Loser (L) I am Assert Loser (L)
This router has lost an (*,G) assert on interface I. It must not This router has lost an (*,G) assert on interface I. It must not
forward packets for G onto interface I with the exception of forward packets for G onto interface I with the exception of
traffic from sources for which is has (S,G) "I am Assert Winner" traffic from sources for which is has (S,G) "I am Assert Winner"
state. If it is the DR, it is no longer responsible for handling state. If it is the DR, it is no longer responsible for handling
the membership requests for group G from local hosts on I. the membership requests for group G from local hosts on I.
In addition there is also an assert timer (AT) that is used to time out In addition there is also an assert timer (AT) that is used to time out
asserts on the assert losers and to resend asserts on the assert winner. asserts on the assert losers and to resend asserts on the assert winner.
It is important to note that no transition occurs in the (*,G) state When an Assert message is received, a PIM implementation must first
machine as a result of receiving an Assert message if the (S,G) assert match it against the possible events in the (S,G) assert state machine
state machine for the relevant S and G is not in the "NoInfo" state. and process any transitions and actions, before considering whether the
Assert message matches against the (*,G) assert state machine.
+-----------------------------------+ It is important to note that NO TRANSITION CAN OCCUR in the (*,G) state
| Figures omitted from text version | 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
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
an assert message if that message triggers any change of state in the
(S,G) state machine.
Figure 11: (*,G) Assert State-machine 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 (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.
In tabular form the state machine is: 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
worse than my_assert_metric(S,G,I), then the (S,G) assert state machine
will transition to NoInfo state. In such a case if the (*,G) assert
state machine were in NoInfo state, it might appear that it would
transition to "W" state, but this is not the case because this message
already triggered a transition in the (S,G) assert state machine.
Figure 11: (*,G) Assert State-machine in tabular form
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In NoInfo (NI) State | | In NoInfo (NI) State |
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+
| Receive Inferior | Data arrives for G | Receive Preferred | | Receive Inferior | Data arrives for G | Receive Preferred |
| Assert with RPTbit | and CouldAssert | Assert with RPTbit | | Assert with RPTbit | and CouldAssert | Assert with RPTbit |
| set and | (*,G,I) | set and AssTrDes | | set and | (*,G,I) | set and AssTrDes |
| CouldAssert(*,G,I) | | (*,G,I) | | CouldAssert(*,G,I) | | (*,G,I) |
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+
| -> W state | -> W state | -> L state | | -> W state | -> W state | -> L state |
skipping to change at page 78, line 30 skipping to change at page 86, line 30
| In I Am Assert Winner (W) State | | In I Am Assert Winner (W) State |
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
| Timer Expires | Receive | Receive | CouldAssert | | Timer Expires | Receive | Receive | CouldAssert |
| | Inferior | Preferred | (*,G,I) -> | | | Inferior | Preferred | (*,G,I) -> |
| | Assert | Assert | FALSE | | | Assert | Assert | FALSE |
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
| -> W state | -> W state | -> L state | -> NI state | | -> W state | -> W state | -> L state | -> NI state |
| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] | | [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
+-----------------------------------------------------------------------+ +-------------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
+---------------+------------------+------------------+-----------------+ +-------------+--------------+--------------+--------------+--------------+
| Receive | Receive | Receive | Timer Expires | |Receive | Receive | Receive | Timer | Current |
| Preferred | Acceptable | Inferior | | |Preferred | Acceptable | Inferior | Expires | Winner's |
| Assert | Assert from | Assert from | | |Assert | Assert from | Assert from | | GenID |
| | Current Winner | Current Winner | | | | Current | Current | | Changes |
+---------------+------------------+------------------+-----------------+ | | Winner | Winner | | |
| -> L state | -> L state | -> NI state | -> NI state | +-------------+--------------+--------------+--------------+--------------+
| [Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | |-> L state | -> L state | -> NI state | -> NI state | -> NI state |
+---------------+------------------+------------------+-----------------+ |[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] |
+-------------+--------------+--------------+--------------+--------------+
+-----------------------------------------------------------------------+ -------------------------------------------------------------------------
| In I Am Assert Loser (L) State | In I Am Assert Loser (L) State
+---------------+-----------------+-----------------+-------------------+ -------------------------------------------------------------------------
| AssTrDes | my_metric -> | RPF_interface | Receive | AssTrDes my_metric -> RPF_interface Receive
| (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) or | (*,G,I) -> better than (RP(G)) stops Join(*,G) or
| FALSE | Winner's | being I | Join(*,*,RP(G)) | FALSE Winner's being I Join(*,*,RP(G))
| | metric | | on Interface I | metric on Interface I
+---------------+-----------------+-----------------+-------------------+ -------------------------------------------------------------------------
| -> NI state | -> NI state | -> NI state | -> NI State | -> NI state -> NI state -> NI state -> NI State
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] [Actions A5] [Actions A5] [Actions A5]
| | | | |
| | | | |
| | | | |
INTERNET-DRAFT | Expires: September 2002 | March 2002|
| | | | |
| | | | |
+---------------+-----------------+-----------------+-------------------+ +---------------+-----------------+-----------------+-------------------+
The state machine uses the following macros: The state machine uses the following macros:
CouldAssert(*,G,I) = CouldAssert(*,G,I) =
( I in ( joins(*,*,RP(G)) (+) joins(*,G) ( I in ( joins(*,*,RP(G)) (+) joins(*,G)
(+) pim_include(*,G)) ) (+) pim_include(*,G)) )
AND RPF_interface(RP(G)) != I AND RPF_interface(RP(G)) != I
CouldAssert(*,G,I) is true on downstream interfaces for which we have CouldAssert(*,G,I) is true on downstream interfaces for which we have
skipping to change at page 79, line 33 skipping to change at page 87, line 41
assert might affect our behavior. assert might affect our behavior.
Note that for reasons of compactness, "AssTrDes(*,G,I)" is used in the Note that for reasons of compactness, "AssTrDes(*,G,I)" is used in the
state-machine table to refer to AssertTrackingDesired(*,G,I). state-machine table to refer to AssertTrackingDesired(*,G,I).
Terminology: Terminology:
A "preferred assert" is one with a better metric than the current A "preferred assert" is one with a better metric than the current
winner. winner.
An "acceptable assert" is one that has a better metric than An "acceptable assert" is one that has a better metric than
my_assert_metric(*,G,I). my_assert_metric(S,G,I).
An "inferior assert" is one with a worse metric than An "inferior assert" is one with a worse metric than
my_assert_metric(S,G). my_assert_metric(S,G,I).
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following events trigger transitions, but only When in NoInfo state, the following events trigger transitions, but only
if the (S,G) assert state machine is in NoInfo state: if the (S,G) assert state machine is in NoInfo state:
Receive Inferior Assert with RPTbit set AND Receive Inferior Assert with RPTbit set AND
CouldAssert(*,G,I)==TRUE CouldAssert(*,G,I)==TRUE
An Inferior (*,G) assert is received for G on Interface I. If An Inferior (*,G) assert is received for G on Interface I. If
CouldAssert(*,G,I) is TRUE, then I is our downstream CouldAssert(*,G,I) is TRUE, then I is our downstream
skipping to change at page 81, line 40 skipping to change at page 89, line 44
will eventually re-assert and win when data packets for G have will eventually re-assert and win when data packets for G have
started flowing again. started flowing again.
When in "I am Assert Loser" state, the following events trigger When in "I am Assert Loser" state, the following events trigger
transitions: transitions:
Timer Expires Timer Expires
The (*,G) assert timer expires. We transition to NoInfo state The (*,G) assert timer expires. We transition to NoInfo state
and delete this (*,G) assert info (action A5). and delete this (*,G) assert info (action A5).
Current Winner's GenID Changes
We receive a Hello message from the current winner reporting a
different GenID from the one it previously reported. This
indicates that the current winner's interface or router has
gone down and come back up, and so we must assume it no longer
knows it was the winner. We transition to the NoInfo state,
deleting the (*,G) assert information (action A5).
AssertTrackingDesired(*,G,I)->FALSE AssertTrackingDesired(*,G,I)->FALSE
AssertTrackingDesired(*,G,I) becomes FALSE. Our forwarding AssertTrackingDesired(*,G,I) becomes FALSE. Our forwarding
state has changed so that (*,G) Asserts on interface I are no state has changed so that (*,G) Asserts on interface I are no
longer of interest to us. We transition to NoInfo state and longer of interest to us. We transition to NoInfo state and
delete this (*,G) assert info (action A5). delete this (*,G) assert info (action A5).
My metric becomes better than the assert winner's metric My metric becomes better than the assert winner's metric
My routing metric, rpt_assert_metric(G,I), has changed so that My routing metric, rpt_assert_metric(G,I), has changed so that
now my assert metric for (*,G) is better than the metric we now my assert metric for (*,G) is better than the metric we
have stored for current assert winner. We transition to have stored for current assert winner. We transition to
skipping to change at page 82, line 30 skipping to change at page 90, line 42
eventually re-apply and we will lose the assert again. eventually re-apply and we will lose the assert again.
However whoever sent the assert may know that the previous However whoever sent the assert may know that the previous
assert winner has died, and so we may end up being the new assert winner has died, and so we may end up being the new
forwarder. forwarder.
(*,G) Assert State-machine Actions (*,G) Assert State-machine Actions
A1: Send Assert(*,G) A1: Send Assert(*,G)
Set timer to (Assert_Time - Assert_Override_Interval) Set timer to (Assert_Time - Assert_Override_Interval)
Store self as AssertWinner(*,G,I). Store self as AssertWinner(*,G,I).
Store rpt_assert_metric as AssertWinnerMetric(*,G,I). Store rpt_assert_metric(G,I) as AssertWinnerMetric(*,G,I).
A2: Store new assert winner as AssertWinner(*,G,I) and assert A2: Store new assert winner as AssertWinner(*,G,I) and assert
winner metric as AssertWinnerMetric(*,G,I). winner metric as AssertWinnerMetric(*,G,I).
Set timer to Assert_Time Set timer to Assert_Time
A3: Send Assert(*,G) A3: Send Assert(*,G)
Set timer to (Assert_Time - Assert_Override_Interval) Set timer to (Assert_Time - Assert_Override_Interval)
A4: Send AssertCancel(*,G) A4: Send AssertCancel(*,G)
Delete assert info (AssertWinner(*,G,I) and Delete assert info (AssertWinner(*,G,I) and
skipping to change at page 83, line 5 skipping to change at page 91, line 15
values). values).
A5: Delete assert info (AssertWinner(*,G,I) and A5: Delete assert info (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return their default AssertWinnerMetric(*,G,I) will then return their default
values). values).
Note that some of these actions may cause the value of JoinDesired(*,G) Note that some of these actions may cause the value of JoinDesired(*,G)
or RPF'(*,G)) to change, which could cause further transitions in other or RPF'(*,G)) to change, which could cause further transitions in other
state machines. state machines.
4.5.3. Assert Metrics 4.6.3. Assert Metrics
Assert metrics are defined as: Assert metrics are defined as:
struct assert_metric { struct assert_metric {
rpt_bit_flag; rpt_bit_flag;
metric_preference; metric_preference;
route_metric; route_metric;
ip_address; ip_address;
}; };
skipping to change at page 84, line 23 skipping to change at page 92, line 34
IP address that is associated with the local interface I. IP address that is associated with the local interface I.
infinite_assert_metric() gives the assert metric we need to send an infinite_assert_metric() gives the assert metric we need to send an
assert but don't match either (S,G) or (*,G) forwarding state: assert but don't match either (S,G) or (*,G) forwarding state:
assert_metric assert_metric
infinite_assert_metric() { infinite_assert_metric() {
return {1,infinity,infinity,0} return {1,infinity,infinity,0}
} }
4.5.4. AssertCancel Messages 4.6.4. AssertCancel Messages
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 typically will name RP(G) as the source as it cannot name an and typically will name RP(G) as the source as it cannot name an
appropriate S. appropriate S.
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.5.5. Assert State Macros 4.6.5. Assert State Macros
The macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and The macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and
lost_assert(*,G,I) are used in the olist computations of Section 4.1, lost_assert(*,G,I) are used in the olist computations of Section 4.1,
and are defined as: and are defined as:
bool lost_assert(S,G,rpt,I) { bool lost_assert(S,G,rpt,I) {
if ( RPF_interface(RP) == I OR if ( RPF_interface(RP) == I OR
( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) { ( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) {
return FALSE return FALSE
} else { } else {
skipping to change at page 88, line 5 skipping to change at page 96, line 22
Rationale: This prevents the periodic duplicates that would Rationale: This prevents the periodic duplicates that would
otherwise occur each time that an assert times out and is then re- otherwise occur each time that an assert times out and is then re-
established. established.
10. Behavior: When RPF'(S,G,rpt) changes to be the same as RPF'(*,G) we 10. Behavior: When RPF'(S,G,rpt) changes to be the same as RPF'(*,G) we
need to trigger a Join(S,G,rpt) to MRIB.next_hop(RP(G)). need to trigger a Join(S,G,rpt) to MRIB.next_hop(RP(G)).
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.6. Designated Routers (DR) and Hello Messages
4.6.1. Sending Hello Messages
PIM-Hello messages are sent periodically on each PIM-enabled interface.
They allow a router to learn about the neighboring PIM routers on each
interface. Hello messages are also the mechanism used to elect a
Designated Router (DR), and to negotiate additional capabilities A
router must record the Hello information received from each PIM
neighbor.
Hello messages must be sent on all active interfaces, including physical
point-to-point links, and are multicast to address 224.0.0.13 (the ALL-
PIM-ROUTERS group).
A per interface hello timer (HT(I)) is used to trigger sending Hello
messages on each active interface. When PIM is enabled on an interface
or a router first starts, the hello timer of that interface is set to a
random value between 0 and Triggered_Hello_Delay. This prevents
synchronization of Hello messages if multiple routers are powered on
simultaneously. After the initial randomized interval, Hello messages
must be sent every Hello_Period seconds. The hello timer should not be
reset except when it expires.
The DR_Election_Priority Option allows a network administrator to give
preference to a particular router in the DR election process by giving
it a numerically larger DR Election Priority. The DR_Election_Priority
Option SHOULD be included in every Hello message, even if no DR election
priority is explicitly configured on that interface. This is necessary
because priority-based DR election is only enabled when all neighbors on
an interface advertise that they are capable of using the DR Election
Priority Option. The default priority is 1.
The Generation_Identifier (GenID) Option SHOULD be included in all Hello
messages. The GenID option contains a randomly generated 32-bit value
that is regenerated each time PIM forwarding is started or restarted on
the interface, including when the router itself restarts. When a Hello
message with a new GenID is received from a neighbor, any old Hello
information about that neighbor SHOULD be discarded and superseded by
the information from the new Hello message. This may cause a new DR to
be chosen on that interface.
The LAN_Prune_Delay Option SHOULD be included in all Hello messages sent
on multi-access LANs. This option advertises a router's capability to
use values other than the default for the Propagation_Delay and
Override_Interval which affect the setting of the Prune Pending,
Upstream Join and Override Timers (defined in section 4.11).
To allow new or rebooting routers to learn of PIM neighbors quickly,
when a Hello message is received from a new neighbor, or a Hello message
with a new GenID is received from an existing neighbor, a new Hello
message should be sent on this interface after a randomized delay
between 0 and Triggered_Hello_Delay. This triggered message need not
change the timing of the scheduled periodic message.
When an interface goes down or changes IP address, a Hello message with
a zero HoldTime should be sent immediately (with the old IP address if
the IP address changed). This will cause PIM neighbors to remove this
neighbor (or its old IP address) immediately.
4.6.2. DR Election
When a PIM-Hello message is received on interface I the following
information about the sending neighbor is recorded:
neighbor.interface
The interface on which the Hello message arrived.
neighbor.ip_address
The IP address of the PIM neighbor.
neighbor.genid
The Generation ID of the PIM neighbor.
neighbor.dr_priority
The DR Priority field of the PIM neighbor if it is present in
the Hello message.
neighbor.dr_priority_present
A flag indicating if the DR Priority field was present in the
Hello message.
neighbor.timeout
A timer to time out the neighbor state when it becomes stale.
This is reset to Hello_Holdtime (from the Hello Holdtime
option) whenever a Hello message is received containing a
Holdtime option, or to Default_Hello_Holdtime if the Hello
message does not contain the Holdtime option.
Neighbor state is deleted when the neighbor timeout expires.
The function for computing the DR on interface I is:
host
DR(I) {
dr = me
for each neighbor on interface I {
if ( dr_is_better( neighbor, dr, I ) == TRUE ) {
dr = neighbor
}
}
return dr
}
The function used for comparing DR "metrics" on interface I is:
bool
dr_is_better(a,b,I) {
if( there is a neighbor n on I for which n.dr_priority_present
is false ) {
return a.ip_address > b.ip_address
} else {
return ( a.dr_priority > b.dr_priority ) OR
( a.dr_priority == b.dr_priority AND
a.ip_address > b.ip_address )
}
}
The DR election 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 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
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
determined by that state-machine.
4.6.3. Reducing Prune Propagation Delay on LANs
In addition to the information recorded for the DR Election, the
following per neighbor information is obtained from the LAN Prune Delay
Hello option:
neighbor.lan_prune_delay_present
A flag indicating if the LAN Prune Delay option was present in
the Hello message.
neighbor.tracking_support
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
the neighbor's capability to disable Join message suppression.
neighbor.lan_delay
The LAN Delay field of the LAN Prune Delay option (if present)
in the Hello message.
neighbor.override_interval
The Override_Interval field of the LAN Prune Delay option (if
present) in the Hello message.
The additional state described above is deleted along with the DR
neighbor state when the neighbor timeout expires.
Just like the DR priority option, the information provided in the LAN
Prune Delay option is not used unless all neighbors on a link advertise
the option. The function below computes this state:
bool
lan_delay_enabled(I) {
for each neighbor on interface I {
if ( neighbor.lan_prune_delay_present == false ) {
return false
}
}
return true
}
The LAN Delay inserted by a router in the LAN Prune Delay option
expresses the expected message propagation delay on the link and should
be configurable by the system administrator. It is used by upstream
routers to figure out how long they should wait for a Join override
message before pruning an interface.
PIM implementors should enforce a lower bound on the permitted values
for this delay to allow for scheduling and processing delays within
their router. Such delays may cause received messages to be processed
later as well as triggered messages to be sent later than intended.
Setting this LAN Prune Delay to too low a value may result in temporary
forwarding outages because a downstream router will not be able to
override a neighbor's Prune message before the upstream neighbor stops
forwarding.
When all routers on a link are in a position to negotiate a different
than default Propagation Delay, the largest value from those advertised
by each neighbor is chosen. The function for computing the Propagation
Delay of interface I is:
time_interval
Propagation_Delay(I) {
if ( lan_delay_enabled(I) == false ) {
return LAN_delay_default
}
delay = 0
for each neighbor on interface I {
if ( neighbor.lan_delay > delay ) {
delay = neighbor.lan_delay
}
}
return delay
}
To avoid synchronisation of override messages when multiple downstream
routers share a multi-access link, sending of such messages is delayed
by a small random amount of time. The period of randomisation should
represent the size of the PIM router poppulation on the link. Each
router expresses its view of the amount of randomisation necessary in
the Override Delay field of the LAN Prune Delay option.
When all routers on a link are in a position to negotiate a different
than default Override Delay, the largest value from those advertised by
each neighbor is chosen. The function for computing the Override
Interval of interface I is:
time_interval
Override_Interval(I) {
if ( lan_delay_enabled(I) == false ) {
return t_override_default
}
delay = 0
for each neighbor on interface I {
if ( neighbor.override_interval > delay ) {
delay = neighbor.override_interval
}
}
return delay
}
Although the mechanisms are not specified in this document, it is
possible for upstream routers to explicitly track the join membership of
individual downstream routers if Join suppression is disabled. A router
can advertise its willingness to disable Join suppression by using the T
bit in the LAN Prune Delay Hello option. Unless all PIM routers on a
link negotiate this capability, explicit tracking and the disabling of
the Join suppression mechanism are not possible. The function for
computing the state of Suppression on interface I is:
bool
Suppression_Enabled(I) {
if ( lan_delay_enabled(I) == false ) {
return true
}
for each neighbor on interface I {
if ( neighbor.tracking_support == false ) {
return true
}
}
return false
}
Note that the setting of Suppression_Enabled(I) affects the value of
t_suppressed (see section 4.11).
4.7. PIM Multicast Border Router Behavior 4.7. PIM Multicast Border Router Behavior
In some cases PIM-SM domains will interconnect with non-PIM domains. In In some cases PIM-SM domains will interconnect with non-PIM domains. In
these cases, the border routers of the PIM domain speak PIM-SM on some these cases, the border routers of the PIM domain speak PIM-SM on some
interfaces and speak other multicast routing protocols on other interfaces and speak other multicast routing protocols on other
interfaces. Such routers are termed PIM Multicast Border Routers or interfaces. Such routers are termed PIM Multicast Border Routers or
PMBRs. In general, RFC 2715 [13] provides rules for interoperability PMBRs. In general, RFC 2715 [13] provides rules for interoperability
between different multicast routing protocols. In this section we between different multicast routing protocols. In this section we
specify how PBMRs 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
receives outside the domain. receives outside the domain.
We note that multiple PIM-SM domains are sometimes conencted 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; typically this is because the routing protocol in traverse the border; typically this is because the routing protocol in
the neighboring domain is not PIM-SM. the neighboring domain is not PIM-SM.
4.7.1. Sources External to the PIM-SM Domain 4.7.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 PBMR 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 PBMR 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 not an external source first reaches the PMBR. If RPF_interface(S) is not an
inteface 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.3.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).
skipping to change at page 94, line 44 skipping to change at page 97, line 40
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.
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 PBMR will need to issue send a Join(*,*,RP) to In the former case, the PMBR will need to issue send a Join(*,*,RP) to
all the RPs in the PIM-SM domain. This will cause all traffic in the all the 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 with 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 shortest directly connected receivers, and trigger the transition to a shortest
path tree (see section 4.2.1). 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.
skipping to change at page 96, line 44 skipping to change at page 99, line 40
that is configured to be a possible RP reports its candidacy to the that is configured to be a possible RP reports its candidacy to the
BSR, and then a domain-wide flooding mechanism distributes the BSR, and then a domain-wide flooding mechanism distributes the
BSR's chosen set of RPs throughout the domain. As specified in RFC BSR's chosen set of RPs throughout the domain. As specified in RFC
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 mechansms, or through achieved through the use of any of these mechanisms, or through
alternative mechanisms not currently specified. alternative mechanisms not currently specified.
Any RP address configured or learned MUST be a domain-wide reachable Any RP address configured or learned MUST be a domain-wide reachable
address. address.
4.8.1. Group-to-RP Mapping 4.8.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
skipping to change at page 97, line 46 skipping to change at page 100, line 40
invoked by any router that has (*,*,RP) state when a packet is received invoked by any router that has (*,*,RP) state when a packet is received
for which there is no corresponding (S,G) or (*,G) entry. Furthermore, for which there is no corresponding (S,G) or (*,G) entry. Furthermore,
the mapping function is invoked by all routers upon receiving a (*,G) or the mapping function is invoked by all routers upon receiving a (*,G) or
(*,*,RP) Join/Prune message. (*,*,RP) Join/Prune message.
Note that if the set of possible group-range-to-RP mappings changes, Note that if the set of possible group-range-to-RP mappings changes,
each router will need to check whether any existing groups are affected. each router will need to check whether any existing groups are affected.
This may, for example, cause a DR or acting DR to re-join a group, or This may, for example, cause a DR or acting DR to re-join a group, or
cause it to re-start register encapsulation to the new RP. cause it to re-start register encapsulation to the new RP.
Implementation note: the bootstrap mechanism described in RFC
2362 omitted step (1) above. However of the implementations
we are are of, approximately half performed step (1) anyway.
It should be noted that implementations of BSR that omit step
1 will not correctly interoperate with implementations of this
specification when used with the BSR mechanism described in
[7].
4.8.2. Hash Function 4.8.2. Hash Function
The hash function is used by all routers within a domain, to map a group The hash function is used by all routers within a domain, to map a group
to one of the RPs from the matching set of group-range-to-RP mappings to one of the RPs from the matching set of group-range-to-RP mappings
(this set all have the same longest mask length and same highest (this set all have the same longest mask length and same highest
priority). The algorithm takes as input the group address, and the priority). The algorithm takes as input the group address, and the
addresses of the candidate RPs from the mappings, and gives as output addresses of the candidate RPs from the mappings, and gives as output
one RP address to be used. one RP address to be used.
The protocol requires that all routers hash to the same RP within a The protocol requires that all routers hash to the same RP within a
domain (except for transients). The following hash function must be used domain (except for transients). The following hash function must be used
in each router: in each router:
1 For RP addresses in the matching group-range-to-RP mappings, 1 For RP addresses in the matching group-range-to-RP mappings,
compute a value: compute a value:
skipping to change at page 99, line 50 skipping to change at page 103, line 5
needed for SSM packets. needed for SSM packets.
4.9.2. PIM-SSM-only Routers 4.9.2. PIM-SSM-only Routers
An implementor may choose to implement only the subset of PIM Sparse- An implementor may choose to implement only the subset of PIM Sparse-
Mode that provides SSM forwarding semantics. Mode that provides SSM forwarding semantics.
A PIM-SSM-only router MUST implement the following portions of this A PIM-SSM-only router MUST implement the following portions of this
specification: specification:
o Upstream (S,G) state machine (Section 4.4.7) o Upstream (S,G) state machine (Section 4.5.7)
o Downstream (S,G) state machine (Section 4.4.3) o Downstream (S,G) state machine (Section 4.5.3)
o (S,G) Assert state machine (Section 4.5.1) o (S,G) Assert state machine (Section 4.6.1)
o Hello messages, neighbor discovery and DR election (Section 4.6) o Hello messages, neighbor discovery and DR election (Section 4.3)
o Packet forwarding rules (Section 4.2) o Packet forwarding rules (Section 4.2)
A PIM-SSM-only router does not need to implement the following protocol A PIM-SSM-only router does not need to implement the following protocol
elements: elements:
o Register state machine (Section 4.3) o Register state machine (Section 4.4)
o (*,G), (S,G,rpt) and (*,*,RP) Downstream state machines (Sections o (*,G), (S,G,rpt) and (*,*,RP) Downstream state machines (Sections
4.4.2, 4.4.4, and 4.4.1) 4.5.2, 4.5.4, and 4.5.1)
o (*,G), (S,G,rpt), and (*,*,RP) Upstream state machines (Sections o (*,G), (S,G,rpt), and (*,*,RP) Upstream state machines (Sections
4.4.6, 4.4.8, and 4.4.5) 4.5.6, 4.5.8, and 4.5.5)
o (*,G) Assert state machine (Section 4.5.2) o (*,G) Assert state machine (Section 4.6.2)
o Bootstrap RP Election (Section 4.8) o Bootstrap RP Election (Section 4.8)
o Keepalive Timer o Keepalive Timer
o SptBit (Section 4.2.2) o SptBit (Section 4.2.2)
The KeepaliveTimer should be treated as always running and SptBit should The KeepaliveTimer should be treated as always running and SptBit should
be treated as being always set for an SSM address. Additionally, the be treated as being always set for an SSM address. Additionally, the
Packet forwarding rules of Section 4.2 can be simplified in a PIM-SSM- Packet forwarding rules of Section 4.2 can be simplified in a PIM-SSM-
skipping to change at page 103, line 44 skipping to change at page 106, line 44
this bit is set to zero and ignored on receipt. this bit is set to zero and ignored on receipt.
Mask Len Mask Len
The Mask length field is 8 bits. The value is the number of The Mask length field is 8 bits. The value is the number of
contiguous one bits left justified used as a mask which, combined contiguous one bits left justified used as a mask which, combined
with the group address, describes a range of groups. It is less with the group address, describes a range of groups. It is less
than or equal to the address length in bits for the given Address than or equal to the address length in bits for the given Address
Family and Encoding Type. If the message is sent for a single group Family and Encoding Type. If the message is sent for a single group
then the Mask length must equal the address length in bits for the then the Mask length must equal the address length in bits for the
given Address Family and Encoding Type. (e.g. 32 for IPv4 native given Address Family and Encoding Type. (e.g. 32 for IPv4 native
encoding and 128 for IPv6 native encoding). encoding, 128 for IPv6 native encoding).
Group multicast Address Group multicast Address
Contains the group address. Contains the group address.
Encoded-Source address Encoded-Source address
Encoded-Source address takes the following format: Encoded-Source address takes the following format:
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
skipping to change at page 106, line 25 skipping to change at page 109, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Holdtime is the amount of time a receiver must keep the neighbor Holdtime is the amount of time a receiver must keep the neighbor
reachable, in seconds. If the Holdtime is set to `0xffff', the reachable, in seconds. If the Holdtime is set to `0xffff', the
receiver of this message never times out the neighbor. This may receiver of this message never times out the neighbor. This may
be used with dial-on-demand links, to avoid keeping the link up be used with dial-on-demand links, to avoid keeping the link up
with periodic Hello messages. with periodic Hello messages.
Hello messages with a Holdtime value set to `0' are also sent by Hello messages with a Holdtime value set to `0' are also sent by
a router on an interface about to go down or changing IP address a router on an interface about to go down or changing IP address
(see section 4.6.1). These are effectively goodbuy messages and (see section 4.3.1). These are effectively goodbye messages and
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 106, line 47 skipping to change at page 109, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. delay on multi-access LANs.
The T bit specifies the ability of the sending router to disable The T bit specifies the ability of the sending router to disable
joins suppression. joins suppression.
LAN Delay and Override_Interval are time intervals in units of LAN Delay and Override_Interval are time intervals in units of
milliseconds are are used to tune the value of the milliseconds are are used to tune the value of the
Override_Interval(I) and its derived timer values. Section 4.6.3 Override_Interval(I) and its derived timer values. Section 4.3.3
describes how these values affect the behaviour of a router. describes how these values affect the 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
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 = 19 | Length = 4 | | Type = 19 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DR Priority | | DR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DR Priority is a 32-bit unsigned number and should be considered DR Priority is a 32-bit unsigned number and should be considered
in the DR election as described in section 4.6.2. in the DR election as described in section 4.3.2.
o OptionType 20: Generation ID o OptionType 20: Generation ID
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 = 20 | Length = 4 | | Type = 20 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation ID | | Generation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 108, line 19 skipping to change at page 111, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|N| Reserved2 | |B|N| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Multicast data packet . . Multicast data packet .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described above. Note that the checksum for Registers is done only Described above. Note that the checksum for Registers is done only
on first 8 bytes of packet, including the PIM header and the next 4 on first 8 bytes of the packet, including the PIM header and the
bytes, excluding the data packet portion. For interoperability next 4 bytes, excluding the data packet portion. For
reasons, a message carrying a checksum calculated over the entire interoperability reasons, a message carrying a checksum calculated
PIM Register message should also be accepted. over the entire PIM Register message should also be accepted.
B The Border bit. If the router is a DR for a source that it is B The Border bit. If the router is a DR for a source that it is
directly connected to, it sets the B bit to 0. If the router is a directly connected to, it sets the B bit to 0. If the router is a
PMBR for a source in a directly connected cloud, it sets the B bit PMBR for a source in a directly connected cloud, it sets the B bit
to 1. to 1.
N The Null-Register bit. Set to 1 by a DR that is probing the RP N The Null-Register bit. Set to 1 by a DR that is probing the RP
before expiring its local Register-Suppression timer. Set to 0 before expiring its local Register-Suppression timer. Set to 0
otherwise. otherwise.
skipping to change at page 111, line 23 skipping to change at page 114, line 23
This address should be the link-local address of the upstream This address should be the link-local address of the upstream
neighbor, as obtained from the RPF lookup. neighbor, as obtained from the RPF lookup.
Reserved Reserved
Transmitted as zero, ignored on receipt. Transmitted as zero, ignored on receipt.
Holdtime Holdtime
The amount of time a receiver must keep the Join/Prune state alive, The amount of time a receiver must keep the Join/Prune state alive,
in seconds. If the Holdtime is set to `0xffff', the receiver of in seconds. If the Holdtime is set to `0xffff', the receiver of
this message should hold the state until canceled by the this message should hold the state until canceled by the
appropriate cancelling Join/Prune message, or timed out according appropriate canceling Join/Prune message, or timed out according to
to local policy. This may be used with dial-on-demand links, to local policy. This may be used with dial-on-demand links, to avoid
avoid keeping the link up with periodic Join/Prune messages. keeping the link up with periodic Join/Prune messages.
Note that the HoldTime must be larger than the Note that the HoldTime must be larger than the
J/P_Override_Interval(I). J/P_Override_Interval(I).
Number of Groups Number of Groups
The number of multicast group sets contained in the message. The number of multicast group sets contained in the message.
Multicast group address Multicast group address
For format description see Section 4.10.1. For format description see Section 4.10.1.
skipping to change at page 112, line 13 skipping to change at page 115, line 13
See Encoded-Source-Address format in section 4.10.1. See Encoded-Source-Address format in section 4.10.1.
Number of Pruned Sources Number of Pruned Sources
Number of prune source addresses listed for a group. Number of prune source addresses listed for a group.
Prune Source Address 1 .. n Prune Source Address 1 .. n
This list contains the sources that the sending router does not This list contains the sources that the sending router does not
want to forward multicast datagrams for when received on the want to forward multicast datagrams for when received on the
interface this message is sent on. interface this message is sent on.
Within one PIM Join/Prune message, all the Multicast Group Addresses,
Joined Source addresses and Pruned Source addresses MUST be of the same
address family. It is NOT PERMITTED to mix IPv4 and IPv6 addresses
within the same message. In addition, the address family of the fields
in the message SHOULD be the same as the IP source and destination
addresses of the packet. This permits maximum implementation
flexibility for dual-stack IPv4/IPv6 routers.
4.10.5.1. Group Set Source List Rules 4.10.5.1. Group Set Source List Rules
As described above, Join / Prune messages are composed by one or more As described above, Join / Prune messages are composed of one or more
group sets. Each set contains two source lists, the Join Sources and the group sets. Each set contains two source lists, the Join Sources and the
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, e.g. 224.0.0.0/4 mask length field of the Multicast Group Address, e.g. 224.0.0.0/4
for IPv4. Each wildcard group set may contain one or more (*,*,RP) for IPv4 or ff00::/8 for IPv6. Each wildcard group set may contain
source list entries in either the Join or Prune lists. 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 routers interest in receiving traffic for all groups expresses the routers 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 routers interest to stop receiving (*,*,RP) entry expresses the routers interest to stop receiving
such traffic. such traffic. Note that as indicated by the Join/Prune state
machines, such a Join or Prune will NOT override Join/Prune state
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
For IPv4, a Group Specific Set is represented by a valid IP A Group Specific Set is represented by a valid IP multicast address
multicast address in the group address field and the full length of in the group address field and the full length of the IP address in
the IP address in the mask length field of the Multicast Group the mask length field of the Multicast Group Address. Each group
Address. Each group specific set may contain (*,G), (S,G,rpt) and specific set may contain (*,G), (S,G,rpt) and (S,G) source list
(S,G) source list entries in the Join or Prune lists. 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 114, line 16 skipping to change at page 117, line 26
is redundant as the (*,G) entry covers the information provided by the is redundant as the (*,G) entry covers the information provided by the
(S,G,rpt) entry. (S,G,rpt) entry.
o The same applies for a (*,G) Prunes and (S,G,rpt) Prunes. o The same applies for a (*,G) Prunes and (S,G,rpt) Prunes.
o The combination of a (*,G) Prune and a (S,G,rpt) Join is also not o The combination of a (*,G) Prune and a (S,G,rpt) Join is also not
generated. (S,G,rpt) Joins are only sent when the router is receiving generated. (S,G,rpt) Joins are only sent when the router is receiving
all traffic for a group on the shared tree and it wishes to indicate a all traffic for a group on the shared tree and it wishes to indicate a
change for the particular source. As a (*,G) prune indicates that the change for the particular source. As a (*,G) prune indicates that the
router no longer wishes to receive shared tree traffic, the (S,G,rpt) router no longer wishes to receive shared tree traffic, the (S,G,rpt)
Join is meaningless. Join would be meaningless.
o As Join / Prune messages are targeted to a single PIM neighbour, o As Join / Prune messages are targeted to a single PIM neighbor,
including both a (S,G) Join and a (S,G,rpt) prune in the same message including both a (S,G) Join and a (S,G,rpt) prune in the same message
is redundant. The (S,G) Join informs the neighbour that the sender is redundant. The (S,G) Join informs the neighbor that the sender
wishes to receive the particular source on the shortest path tree. It wishes to receive the particular source on the shortest path tree. It
is therefore unnecessary for the router to say that it no longer is therefore unnecessary for the router to say that it no longer
wishes to receive it on the shared tree. wishes to receive it on the shared tree.
o The combination of a (S,G) Prune and a (S,G,rpt) Join could possibly o The combination of a (S,G) Prune and a (S,G,rpt) Join could possibly
be used by a router to switch from receiving a particular source on be used by a router to switch from receiving a particular source on
the shortest-path tree back to receiving it on the shared tree the shortest-path tree back to receiving it on the shared tree
(provided that the RPF neighbor for the shortest-path and shared trees (provided that the RPF neighbor for the shortest-path and shared trees
is common). However Sparse-Mode PIM does not provide a mechanism for is common). However Sparse-Mode PIM does not provide a mechanism for
switching back to the shared tree. switching back to the shared tree.
The rules are summarised in the table below. The rules are summarized in the tables below.
+-----------++-------+--------+------------+------------+--------+--------+ +----------++------+-------+-----------+-----------+-------+-------+
| ||(*,G)J | (*,G)P | (S,G,rpt)J | (S,G,rpt)P | (S,G)J | (S,G)P | | ||Join | Prune | Join | Prune | Join | Prune |
+-----------++-------+--------+------------+------------+--------+--------+ | ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
|(*,G)J ||- | no | ? | yes | yes | yes | +----------++------+-------+-----------+-----------+-------+-------+
+-----------++-------+--------+------------+------------+--------+--------+ |Join ||- | no | ? | yes | yes | yes |
|(*,G)P || | - | ? | ? | yes | yes | |(*,G) || | | | | | |
+-----------++-------+--------+------------+------------+--------+--------+ +----------++------+-------+-----------+-----------+-------+-------+
|(S,G,rpt)J || | | - | no | yes | yes | |Prune ||no | - | ? | ? | yes | yes |
+-----------++-------+--------+------------+------------+--------+--------+ |(*,G) || | | | | | |
|(S,G,rpt)P || | | | - | ? | ? | +----------++------+-------+-----------+-----------+-------+-------+
+-----------++-------+--------+------------+------------+--------+--------+ |Join ||? | ? | - | no | yes | yes |
|(S,G)J || | | | | - | no | |(S,G,rpt) || | | | | | |
+-----------++-------+--------+------------+------------+--------+--------+ +----------++------+-------+-----------+-----------+-------+-------+
|(S,G)P || | | | | | - | |Prune ||yes | ? | no | - | ? | ? |
+-----------++-------+--------+------------+------------+--------+--------+ |(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Join ||yes | yes | yes | ? | - | no |
|(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | yes | yes | ? | no | - |
|(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
+---------------++--------------+----------------+------------+
| ||Join (*,*,RP) | Prune (*,*,RP) | all others |
+---------------++--------------+----------------+------------+
|Join (*,*,RP) ||- | no | yes |
+---------------++--------------+----------------+------------+
|Prune (*,*,RP) ||no | - | yes |
+---------------++--------------+----------------+------------+
|all others ||yes | yes | see above |
+---------------++--------------+----------------+------------+
yes Allowed and expected. yes Allowed and expected.
no Combination is not allowed by the protocol and MUST not be no Combination is not allowed by the protocol and MUST NOT be
generated by a router. generated by a router.
? Combination not expected by the protocol, but well-defined. A ? Combination not expected by the protocol, but well-defined. A
router MAY accept it but SHOULD not generate it. router MAY accept it but SHOULD NOT generate it.
The order of source list entries in a group set source list is not The order of source list entries in a group set source list is not
important. As a result the table above is symmetric and only entries on important, except where limited by the packet format itself.
the upper right half have been specified as entries on the lower left
are just a mirror.
4.10.5.2. Group Set Fragmentation 4.10.5.2. Group Set Fragmentation
When building a Join / Prune for a particular neighbour, a router should When building a Join / Prune for a particular neighbor, a router should
try and include in the message as much of the information it needs to try and include in the message as much of the information it needs to
convey to the neighbour as possible. This implies adding one group set convey to the neighbor as possible. This implies adding one group set
for each multicast group that has information pending transmission and for each multicast group that has information pending transmission and
within each set including all relevant source list entries. within each set including all relevant source list entries.
On a router with a large amount of multicast state the number of entries On a router with a large amount of multicast state the number of entries
that must be included may result in packets that are larger in the that must be included may result in packets that are larger in the
maximum IP packet size. In most such cases the information may be split maximum IP packet size. In most such cases the information may be split
into multiple messages. into multiple messages.
There is an exception with group sets that contain a (*,G) Join source There is an exception with group sets that contain a (*,G) Join source
list entry. The group set expresses the routers interest in receiving list entry. The group set expresses the routers interest in receiving
skipping to change at page 116, line 19 skipping to change at page 119, line 37
If only N (S,G,rpt) Prune entries fit into a maximum-sized Join / Prune If only N (S,G,rpt) Prune entries fit into a maximum-sized Join / Prune
message, but the router has more than N (S,G,rpt) Prunes to add, then message, but the router has more than N (S,G,rpt) Prunes to add, then
the router MUST choose to include the first N (numerically smallest in the router MUST choose to include the first N (numerically smallest in
network byte order) IP addresses. network byte order) IP addresses.
4.10.6. Assert Message Format 4.10.6. Assert Message Format
The Assert message is used to resolve forwarder conflicts between The Assert message is used to resolve forwarder conflicts between
routers on a link. It is sent when a multicast data packet is received routers on a link. It is sent when a multicast data packet is received
on an interface that the router would normaly forward that packet. on an interface that the router would normally forward that packet.
Assert messages may also be sent in response to an Assert message from Assert messages may also be sent in response to an Assert message from
another router. another router.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum | |PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) | | Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 119, line 24 skipping to change at page 122, line 51
Per Source,Group pair (S,G): Per Source,Group pair (S,G):
Register Stop Timer: RST(S,G) Register Stop Timer: RST(S,G)
4.12. Timer Values 4.12. Timer Values
When timers are started or restarted, they are set to default values. When timers are started or restarted, they are set to default values.
This section summarizes those default values. This section summarizes those default values.
Note that protocol events or configuration may change the default value Note that protocol events or configuration may change the default value
of a timer on a specific interface. When timers are initialised in this of a timer on a specific interface. When timers are initialized in this
document the value specific to the interface in context must be used. document the value specific to the interface in context must be used.
Some of the timers listed below (Prune Pending, Upstream Join, Upstream Some of the timers listed below (Prune Pending, Upstream Join, Upstream
Override) can be set to values which depend on the settings of the Override) can be set to values which depend on the settings of the
Propagation Delay and Override_Interval of the corresponding interface. Propagation Delay and Override_Interval of the corresponding interface.
The default values for these are given below. Note that the value of The default values for these are given below. Note that the value of
both the Propagation Delay and Override Interval of an interface can both the Propagation Delay and Override Interval of an interface can
change as a result of receiving Hello messages on that interface change as a result of receiving Hello messages on that interface
(section 4.6.3). (section 4.3.3).
Variable Name: Propagation_Delay(I) Variable Name: Propagation_Delay(I)
+--------------------------+-----------------+--------------------------+ +--------------------------+-----------------+--------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+--------------------------+-----------------+--------------------------+ +--------------------------+-----------------+--------------------------+
| LAN_delay_default | 0.5 sec | Expected | | LAN_delay_default | 0.5 sec | Expected |
| | | propagation delay | | | | propagation delay |
| | | over the local | | | | over the local |
| | | link. | | | | link. |
skipping to change at page 123, line 18 skipping to change at page 126, line 42
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 Override Interval of the upstream interface t_override depends on the Override Interval of the upstream interface
which may change when Hello messages are received. 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
( 4.6.3) and becomes zero when suppression is disabled. ( 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))
+---------------+---------------------------+---------------------------+ +---------------+---------------------------+---------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+---------------+---------------------------+---------------------------+ +---------------+---------------------------+---------------------------+
| t_override | see Upstream Join Timer | see Upstream Join Timer | | t_override | see Upstream Join Timer | see Upstream Join Timer |
+---------------+---------------------------+---------------------------+ +---------------+---------------------------+---------------------------+
The upstream Override Timer is only ever set to t_override; this value The upstream Override Timer is only ever set to t_override; this value
skipping to change at page 126, line 36 skipping to change at page 129, line 36
6.1.1. Forged link-local messages 6.1.1. Forged link-local messages
Join/Prune, Hello, and Assert messages are all sent to the link-local Join/Prune, Hello, and Assert messages are all sent to the link-local
ALL_PIM_ROUTERS multicast addresses, and thus are not forwarded by a ALL_PIM_ROUTERS multicast addresses, and thus are not forwarded by a
compliant router. A forged message of this type can only reach a LAN if compliant router. A forged message of this type can only reach a LAN if
it was sent by a local host or if it was allowed onto the LAN by a it was sent by a local host or if it was allowed onto the LAN by a
compromised or non-compliant router. compromised or non-compliant router.
1. A forged Join/Prune message can cause multicast traffic to be 1. A forged Join/Prune message can cause multicast traffic to be
delivered to links where there are no legitimate requestors, delivered to links where there are no legitimate requesters,
potentially wasting bandwidth on that link. A forged leave message potentially wasting bandwidth on that link. A forged leave message
on a multi-access LAN is generally not a significant attack in PIM, on a multi-access LAN is generally not a significant attack in PIM,
because any legitimately joined router on the LAN would override because any legitimately joined router on the LAN would override
the leave with a join before the upstream router stops forwarding the leave with a join before the upstream router stops forwarding
data to the LAN. data to the LAN.
2. By forging a Hello message, an unauthorized router can cause 2. By forging a Hello message, an unauthorized router can cause
itself to be elected as the designated router on a LAN. The itself to be elected as the designated router on a LAN. The
designated router on a LAN is (in the absence of asserts) designated router on a LAN is (in the absence of asserts)
responsible for forwarding traffic to that LAN on behalf of any responsible for forwarding traffic to that LAN on behalf of any
skipping to change at page 129, line 36 skipping to change at page 132, line 36
In this "single shared key" mode of operation, the network administrator In this "single shared key" mode of operation, the network administrator
must choose an SPI for each DR that will be used to send it PIM protocol must choose an SPI for each DR that will be used to send it PIM protocol
packets. The Security Policy Database at every DR is configured to packets. The Security Policy Database at every DR is configured to
select a Security Association (including the authentication algorithm, select a Security Association (including the authentication algorithm,
authentication parameters, and this SPI) when sending Register messages authentication parameters, and this SPI) when sending Register messages
to this RP. to this RP.
By using a single authentication algorithm and associated parameters, By using a single authentication algorithm and associated parameters,
the key distribution problem is simplified. Note however, that this the key distribution problem is simplified. Note however, that this
metohd 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.
[xxx Can we reserve a single SPI at all routers in the domain to [XXX Can we reserve a single SPI at all routers in the domain to
simplify the configuration problem?] simplify the configuration problem?]
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.
skipping to change at page 130, line 27 skipping to change at page 133, line 27
- Sending packets to many different group addresses quickly can be a - Sending packets to many different group addresses quickly can be a
denial of service attack in and of itself. This will cause many denial of service attack in and of itself. This will cause many
register-encapsulated packets, loading the DR, the RP, and the register-encapsulated packets, loading the DR, the RP, and the
routers between the DR and the RP. routers between the DR and the RP.
- Forging Join messages can cause a multicast tree to get set up. A - Forging Join messages can cause a multicast tree to get set up. A
large number of forged joins can consume router resources and large number of forged joins can consume router resources and
result in denial of service. result in denial of service.
- [xxx Many others] - [XXX Many others]
7. Authors' Addresses 7. Authors' Addresses
Bill Fenner Bill Fenner
AT&T Labs - Research AT&T Labs - Research
75 Willow Road 75 Willow Road
Menlo Park, CA 94025 Menlo Park, CA 94025
fenner@research.att.com fenner@research.att.com
Mark Handley Mark Handley
ACIRI/ICSI ICIR/ICSI
1947 Center St, Suite 600 1947 Center St, Suite 600
Berkeley, CA 94708 Berkeley, CA 94708
mjh@aciri.org mjh@icir.org
Hugh Holbrook Hugh Holbrook
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
holbrook@cisco.com holbrook@cisco.com
Isidor Kouvelas Isidor Kouvelas
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 131, line 43 skipping to change at page 134, line 43
[4] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery [4] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery
(MLD) for IPv6", RFC 2710. (MLD) for IPv6", RFC 2710.
[5] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) [5] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460. Specification", RFC 2460.
[6] W. Fenner, "Internet Group Management Protocol, Version 2", RFC [6] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
2236. 2236.
[7] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Bootstrap Router [7] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Bootstrap Router
(BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-00.txt, (BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-02.txt,
work in progress. work in progress.
[8] IANA, "Address Family Numbers", linked from [8] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
[9] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional [9] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
Protocol Independent Multicast", draft-ietf-pim-bidir-02.txt, work Protocol Independent Multicast", draft-ietf-pim-bidir-02.txt, work
in progress. in progress.
[10] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft- [10] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft-
holbrook-ssm-00.txt, work in progress. holbrook-ssm-00.txt, work in progress.
[11] S. Kent, R. Atkinson, "Security Architecture for the Internet [11] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.", RFC 2401. Protocol.", RFC 2401.
[12] T. Narten , H. Alvestrand, "Guidelines for Writing an IANA [12] T. Narten , H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434. [13] D. Thaler, Considerations Section in RFCs", RFC 2434. [13] D. Thaler,
"Interoperability Rules for Multicast Routing Protocols", RFC 2715. "Interoperability Rules for Multicast Routing Protocols", RFC 2715.
10. Index 10. Index
Assert(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Assert(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .26,121
Assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .26,121
AssertCancel(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 82 AssertCancel(*,G). . . . . . . . . . . . . . . . . . . . . . . . . 90,92
AssertTimer(*,G,I) . . . . . . . . . . . . . . . . . . . . .15,23,77,122 AssertCancel(S,G). . . . . . . . . . . . . . . . . . . . . . . .75,84,92
AssertTimer(S,G,I) . . . . . . . . . . . . . . . . . . . . .17,23,70,122 AssertTimer(*,G,I) . . . . . . . . . . . . . . . . . . . . .16,24,84,125
AssertTrackingDesired(*,G,I) . . . . . . . . . . . . . . . . . . . . 79 AssertTimer(S,G,I) . . . . . . . . . . . . . . . . . . . . .18,24,77,125
AssertTrackingDesired(S,G,I) . . . . . . . . . . . . . . . . . . . . 72 AssertTrackingDesired(*,G,I) . . . . . . . . . . . . . . . . . .87,88,90
AssertWinner(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . 20,23 AssertTrackingDesired(S,G,I) . . . . . . . . . . . . . . . . 79,79,81,83
AssertWinner(S,G,I). . . . . . . . . . . . . . . . . . . . . 20,23,76,85 AssertWinner(*,G,I). . . . . . . . . . . . . . . . . . . .21,24,87,90,94
AssertWinnerMetric(S,G,I). . . . . . . . . . . . . . . . . . . . . . 76 AssertWinner(S,G,I). . . . . . . . . . . . . . . . . . 21,24,79,83,93,94
assert_metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 AssertWinnerMetric(*,G,I). . . . . . . . . . . . . . . . . . . . . 90,94
Assert_Override_Interval . . . . . . . . . . . . . . . . . . . 76,82,122 AssertWinnerMetric(S,G,I). . . . . . . . . . . . . . . . . . . . . 83,94
Assert_Time. . . . . . . . . . . . . . . . . . . . . . . . . . 76,82,122 assert_metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
AT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . . .15,23,77,122 Assert_Override_Interval . . . . . . . . . . . . . . . . . . . 83,90,125
AT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . . . .17,23,70,122 Assert_Time. . . . . . . . . . . . . . . . . . . . . . . . . . 83,90,125
CheckSwitchToSpt(S,G). . . . . . . . . . . . . . . . . . . . . . . . 26 AT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . .16,24,84,122,125
CouldAssert(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . 79 AT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . .18,24,77,122,125
CouldAssert(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . 72 CheckSwitchToSpt(S,G). . . . . . . . . . . . . . . . . . . . . . . 26,27
CouldRegister(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 31 CouldAssert(*,G,I) . . . . . . . . . . . . . . . . . . . .85,87,88,89,91
DirectlyConnected(S) . . . . . . . . . . . . . . . . . . . . . .25,27,31 CouldAssert(S,G,I) . . . . . . . . . . . . . . . . . . 78,79,81,82,83,91
DownstreamJPState(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . 21 CouldRegister(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 36,38
DownstreamJPState(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 21 Default_Hello_Holdtime . . . . . . . . . . . . . . . . . . . . . . . 31
DownstreamJPState(S,G,I) . . . . . . . . . . . . . . . . . . . . . . 21 DirectlyConnected(S) . . . . . . . . . . . . . . . . . . .26,26,28,38,97
DownstreamJPState(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . 22 DownstreamJPState(*,*,RP,I). . . . . . . . . . . . . . . . . . . . 22,98
DR(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 DownstreamJPState(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 22
dr_is_better(a,b,I). . . . . . . . . . . . . . . . . . . . . . . . . 90 DownstreamJPState(S,G,I) . . . . . . . . . . . . . . . . . . . . . 22,38
ET(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . . . . . 14,34,121 DownstreamJPState(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . 23
ET(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 15,38,121 DR(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ET(S,G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 17,42,121 dr_is_better(a,b,I). . . . . . . . . . . . . . . . . . . . . . . . 31,32
ET(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . . . . . . 18,45,121 DR_priority. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31,32
Hash_Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 ET(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . . . 15,42,121,124
Hello_Holdtime . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 ET(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . . 16,46,122,124
Hello_Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 ET(S,G,I). . . . . . . . . . . . . . . . . . . . . . . . . 18,50,122,124
HT(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88,120 ET(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . . .19,53,55,122,124
immediate_olist(*,*,RP). . . . . . . . . . . . . . . . . . . . . . 20,53 GenID. . . . . . . . . . . . . . . . . . . 16,17,19,30,59,63,66,68,78,85
immediate_olist(*,G) . . . . . . . . . . . . . . . . . . . . . . . 20,57 Hash_Function. . . . . . . . . . . . . . . . . . . . . . . . . . .13,101
immediate_olist(S,G) . . . . . . . . . . . . . . . . . . . . . .20,61,83 Hello_Holdtime . . . . . . . . . . . . . . . . . . . . . . . . . .31,124
infinite_assert_metric() . . . . . . . . . . . . . . . . . . . . . . 84 Hello_Period . . . . . . . . . . . . . . . . . . . . . . . . . . .29,124
inherited_olist(S,G) . . . . . . . . . . . . . . . . . . .20,25,32,61,72 HT(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29,124
inherited_olist(S,G,rpt) . . . . . . . . . . . . . .20,25,27,65,67,69,83 IGMP . . . . . . . . . . . . . . . . . . . . . . . . . .7,9,17,22,95,100
I_am_DR(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20,31 immediate_olist(*,*,RP). . . . . . . . . . . . . . . . . . . . . . 21,60
I_am_RP(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 immediate_olist(*,G) . . . . . . . . . . . . . . . . . . . . . . . 21,64
J/P_HoldTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 immediate_olist(S,G) . . . . . . . . . . . . . . . . . . . . . .21,38,68
J/P_Override_Interval(I) . . . . . . . . . . . . . . . . 36,40,43,48,121 infinite_assert_metric() . . . . . . . . . . . . . . . . . . . . . . 92
Join(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 inherited_olist(S,G) . . . . . . . . . . . . . . . . .21,26,40,68,79,103
JoinDesired(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 53,67 inherited_olist(S,G,rpt) . . . . . . . . . . . . . . . 21,26,28,72,74,76
JoinDesired(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 57,67 I_Am_Assert_Loser(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 24
JoinDesired(S,G) . . . . . . . . . . . . . . . . . . . . . . . .27,61,72 I_Am_Assert_Loser(S,G,I) . . . . . . . . . . . . . . . . . . . . . . 24
joins(*,*,RP(G)) . . . . . . . . . . . . . . . . . . . . . . . . . . 72 I_am_DR(I) . . . . . . . . . . . . . . . . . . . . . . . .21,32,38,79,87
joins(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 21,72,72,79 I_am_RP(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40,40
joins(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 21,72,72,79 J/P_Holdtime . . . . . . . . . . . . . .43,48,51,55,61,65,70,114,124,126
joins(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21,72 J/P_Override_Interval(I) . . . . . . . . . . . . . . 44,48,51,55,114,125
JT(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . . . . . 14,51,122 JoinDesired(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 60,73
JT(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . 15,55,122 JoinDesired(*,G) . . . . . . . . . . . . . . . . . . . . .17,64,73,79,91
JT(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . 17,60,122 JoinDesired(S,G) . . . . . . . . . . . . . . . . . . . 18,28,68,79,82,84
KAT(S,G) . . . . . . . . . . . . . . . . . . . . . . .17,25,31,32,61,123 joins(*,*,RP(G)) . . . . . . . . . . . . . . . . . . . . . . . . . . 21
KeepaliveTimer(S,G). . . . . . . . . . . . . . . . . .17,25,31,32,61,123 joins(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 21,22,79,87
Keepalive_Period . . . . . . . . . . . . . . . . . . . . . . . . . . 123 joins(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 21,22,79,87
lan_delay_enabled(I) . . . . . . . . . . . . . . . . . . . . . . . . 91 joins(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . .21,22,79
local_receiver_exclude(S,G,I). . . . . . . . . . . . . . . . . . . . 21 JT(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . . . 15,58,122,126
local_receiver_include(*,G,I). . . . . . . . . . . . . . . . . . . . 20 JT(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 16,62,122,126
local_receiver_include(S,G,I). . . . . . . . . . . . . . . . . . . . 20 JT(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . 18,67,122,126
lost_assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . .22,72,72 KAT(S,G) . . . . . . . . . . . . . . . .18,25,26,27,38,40,68,103,122,127
lost_assert(*,G,I) . . . . . . . . . . . . . . . . . . . . . . .20,22,85 KeepaliveTimer(S,G). . . . . . . . . 18,25,26,26,27,38,40,68,103,122,127
lost_assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Keepalive_Period . . . . . . . . . . . . . . . . . . . . . . . . .26,127
lost_assert(S,G,I) . . . . . . . . . . . . . . . . . . . . . . .20,22,85 LAN_delay_default. . . . . . . . . . . . . . . . . . . . . . . . .34,123
lost_assert(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . . . 22 lan_delay_enabled(I) . . . . . . . . . . . . . . . . . . . . . . . 33,35
lost_assert(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . . . 22,85 LAN_Prune_Delay. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
MBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 local_receiver_exclude(S,G,I). . . . . . . . . . . . . . . . . . . . 22
MRIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 local_receiver_include(*,G,I). . . . . . . . . . . . . . . . . .22,87,98
MRIB.next_hop(host). . . . . . . . . . . . . . . . . . . . . . . . . 23 local_receiver_include(S,G,I). . . . . . . . . . . . . . . . . .22,79,98
my_assert_metric(S,G,I). . . . . . . . . . . . . . . . . . . . . . . 83 lost_assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . .21,23,79
NLT(N,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14,120 lost_assert(*,G,I) . . . . . . . . . . . . . . . . . . . . . . .21,23,94
OT(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . . . . .19,123 lost_assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 21,23
Override_Interval. . . . . . . . . . . . . . . . . . . . . . . . . . 119 lost_assert(S,G,I) . . . . . . . . . . . . . . . . . . . . . . .21,23,93
Override_Interval(I) . . . . . . . . . . . . . . . . . . . . .92,106,121 lost_assert(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . . . 23
packet_arrives_on_rp_tunnel(pkt) . . . . . . . . . . . . . . . . . . 32 lost_assert(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . . . 23,93
pim_exclude(S,G) . . . . . . . . . . . . . . . . . . . . . . . .21,72,72 MBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7,8
pim_include(*,G) . . . . . . . . . . . . . . . . . . . . . . 20,72,72,79 MFIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7,13
pim_include(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 20,72 MLD. . . . . . . . . . . . . . . . . . . . . . . . . . .7,9,17,22,95,100
PPT(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . . . . 14,34,121 MRIB . . . . . . . . . . . . . . . 7,8,12,16,19,24,58,61,62,71,92,99,121
PPT(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . 15,38,121 MRIB.next_hop(host). . . . . . . . . . . . . . . . .24,24,58,59,63,68,96
PPT(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . 17,42,121 my_assert_metric(S,G,I). . . . . . . . . . . . . . . . . .79,83,85,87,91
PPT(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . . . . . 18,46,121 NLT(N,I) . . . . . . . . . . . . . . . . . . . . . . . . . 15,31,121,124
Propagation_Delay. . . . . . . . . . . . . . . . . . . . . . . . . . 119 OT(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . 20,72,122,127
Propagation_Delay(I) . . . . . . . . . . . . . . . . . . . . . . .92,121 Override_Interval(I) . . . . . . . . . . . . . . 14,30,33,34,109,123,125
PruneDesired(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . 67,69 packet_arrives_on_rp_tunnel(pkt) . . . . . . . . . . . . . . . . . . 40
prunes(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . .22,72,72 pim_exclude(S,G) . . . . . . . . . . . . . . . . . . . . . . 21,22,27,79
RegisterStop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 pim_include(*,G) . . . . . . . . . . . . . . . . . . . 17,21,21,27,79,87
RegisterStop(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 31 pim_include(S,G) . . . . . . . . . . . . . . . . . . . . .18,21,21,27,79
RegisterStop(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . 32 PPT(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . . 15,42,121,125
RegisterStop_timer . . . . . . . . . . . . . . . . . . . . . . . . . 29 PPT(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . 16,46,122,125
Register_Probe_Time. . . . . . . . . . . . . . . . . . . . . . 30,33,125 PPT(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . 18,50,122,125
Register_Suppression_Time. . . . . . . . . . . . . . . . . 30,33,124,125 PPT(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . .19,53,55,122,125
RP(G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23,79,79 Propagation_Delay(I) . . . . . . . . . . . . . . . . . . . 30,34,123,125
RPF'(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .23,27,65 PruneDesired(S,G,rpt). . . . . . . . . . . . . . . . . . . . 74,75,82,84
RPF'(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .23,27,65 prunes(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . .21,23,79
RPF'(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . . .23,65,67 RegisterStop(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 39
RPF_interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 RegisterStop(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . 40
RPF_interface(host). . . . . . . . . . . . . . . . .23,25,27,31,72,79,85 RegisterStopTimer(S,G) . . . . . . . . . . . . . . . . . . 36,37,122,128
RPTJoinDesired(G). . . . . . . . . . . . . . . . . . . . . . . .67,69,79 Register_Probe_Time. . . . . . . . . . . . . . . . . . . . . . 37,41,128
rpt_assert_metric(G,I) . . . . . . . . . . . . . . . . . . . . . . . 84 Register_Suppression_Time. . . . . . . . . . . . . . . . . . . 37,41,128
RST(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29,125 RP(G). . . . . . . . . . . . . . .6,21,24,38,40,46,64,72,79,87,92,95,121
SPTbit(S,G). . . . . . . . . . . . . . . . . . . . .25,27,32,65,72,72,83 RPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
spt_assert_metric(S,I) . . . . . . . . . . . . . . . . . . . . . . 76,83 RPF'(*,G). . . . . . . . . . . . . . . . . . .24,28,62,63,66,72,73,91,94
SSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 RPF'(S,G). . . . . . . . . . . . . . . . . . . . . .24,28,67,72,73,84,94
Suppression_Enabled(I) . . . . . . . . . . . . . . . . . . . . . . . 93 RPF'(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . 24,72,74,95
SwitchToSptDesired(S,G). . . . . . . . . . . . . . . . . . . . . . . 26 RPF_interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Triggered_Hello_Delay. . . . . . . . . . . . . . . . . . . . . . . . 120 RPF_interface(host). . . . . . . . .24,26,28,38,64,65,70,79,87,93,97,103
t_joinsuppress . . . . . . . . . . . . . . . . . . . . . .52,54,56,58,63 RPTJoinDesired(G). . . . . . . . . . . . . . . . . . . . . . . .73,76,87
t_override . . . . . . . . . . . . . . . . . . . . . . .52,56,66,122,123 rpt_assert_metric(G,I) . . . . . . . . . . . . . . . . . . . . . . 90,92
t_periodic . . . . . . . . . . . . . . . . . . . . . . . . . . 52,56,122 RST(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 36,37,122,128
t_suppressed . . . . . . . . . . . . . . . . . . . . . . . .54,58,63,122 SPTbit(S,G). . . . . . . . . .19,26,28,40,49,69,72,74,79,79,83,84,93,103
Update_SPTbit(S,G,iif) . . . . . . . . . . . . . . . . . . . . . . . 27 spt_assert_metric(S,I) . . . . . . . . . . . . . . . . . . . . .83,92,93
UpstreamJPState(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 25 SSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11,101
Suppression_Enabled(I) . . . . . . . . . . . . . . . . . . . . . .35,126
SwitchToSptDesired(S,G). . . . . . . . . . . . . . . . . . . . . . 27,27
TIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7,13,25
Triggered_Hello_Delay. . . . . . . . . . . . . . . . . . . . . 29,30,124
t_joinsuppress . . . . . . . . . . . . . . . . . . . . . .59,61,63,65,70
t_override . . . . . . . . . . . . . . . . . . . . . 59,63,68,73,126,127
t_override_default . . . . . . . . . . . . . . . . . . . . . . . .34,123
t_periodic . . . . . . . . . . . . . . . . . . . . . . . . .59,63,68,126
t_suppressed . . . . . . . . . . . . . . . . . . . . .35,61,65,68,70,126
Update_SPTbit(S,G,iif) . . . . . . . . . . . . . . . . . . . . . . 26,28
UpstreamJPState(S,G) . . . . . . . . . . . . . . . . . . . . . . .26,103
 End of changes. 

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