draft-ietf-pim-sm-v2-new-02.txt   draft-ietf-pim-sm-v2-new-03.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-02.txt Mark Handley/ACIRI draft-ietf-pim-sm-v2-new-03.txt Mark Handley/ACIRI
Hugh Holbrook/Cisco Hugh Holbrook/Cisco
Isidor Kouvelas/Cisco Isidor Kouvelas/Cisco
2 March 2001 20 July 2001
Expires: September 2001 Expires: January 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 3, line 16 skipping to change at page 3, line 16
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . . . . . . 6 2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . . . . . . 6
3. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . . . . . . 7 3. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Specification. . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Specification. . . . . . . . . . . . . . . . . . . . . . 12
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . . 12 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. General Purpose State . . . . . . . . . . . . . . . . . . . 13 4.1.1. General Purpose State . . . . . . . . . . . . . . . . . . . 13
4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . . . . . . 14
4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . . . . . . 18 4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . . . . . . 18
4.1.6. State Summarization Macros. . . . . . . . . . . . . . . . . 19 4.1.6. State Summarization Macros. . . . . . . . . . . . . . . . . 19
4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . . 23 4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . . 23
4.2.1. Setting and Clearing the (S,G) SPT bit. . . . . . . . . . . 25 4.2.1. Last hop switchover to the SPT. . . . . . . . . . . . . . . 26
4.3. PIM Register Messages. . . . . . . . . . . . . . . . . . . . . 26 4.2.2. Setting and Clearing the (S,G) SPT bit. . . . . . . . . . . 26
4.3.1. Sending Register Messages from the DR . . . . . . . . . . . 26 4.3. PIM Register Messages. . . . . . . . . . . . . . . . . . . . . 28
4.3.2. Receiving Register Messages at the RP . . . . . . . . . . . 30 4.3.1. Sending Register Messages from the DR . . . . . . . . . . . 28
4.4. PIM Join/Prune Messages. . . . . . . . . . . . . . . . . . . . 31 4.3.2. Receiving Register Messages at the RP . . . . . . . . . . . 31
4.4.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . . . . . . 31 4.4. PIM Join/Prune Messages. . . . . . . . . . . . . . . . . . . . 33
4.4.2. Receiving (*,G) Join/Prune Messages . . . . . . . . . . . . 35 4.4.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . . . . . . 33
4.4.3. Receiving (S,G) Join/Prune Messages . . . . . . . . . . . . 39 4.4.2. Receiving (*,G) Join/Prune Messages . . . . . . . . . . . . 37
4.4.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . . . . 43 4.4.3. Receiving (S,G) Join/Prune Messages . . . . . . . . . . . . 41
4.4.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . . . . . . 48 4.4.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . . . . 44
4.4.6. Sending (*,G) Join/Prune Messages . . . . . . . . . . . . . 53 4.4.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . . . . . . 50
4.4.7. Sending (S,G) Join/Prune Messages . . . . . . . . . . . . . 57 4.4.6. Sending (*,G) Join/Prune Messages . . . . . . . . . . . . . 55
4.4.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . . . . . . 62 4.4.7. Sending (S,G) Join/Prune Messages . . . . . . . . . . . . . 59
4.4.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . . . . . . 64
4.4.9. State Machine for (S,G,rpt) Triggered 4.4.9. State Machine for (S,G,rpt) Triggered
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5. PIM Assert Messages. . . . . . . . . . . . . . . . . . . . . . 67 4.5. PIM Assert Messages. . . . . . . . . . . . . . . . . . . . . . 69
4.5.1. (S,G) Assert Message State Machine. . . . . . . . . . . . . 67 4.5.1. (S,G) Assert Message State Machine. . . . . . . . . . . . . 69
4.5.2. (*,G) Assert Message State Machine. . . . . . . . . . . . . 74 4.5.2. (*,G) Assert Message State Machine. . . . . . . . . . . . . 76
4.5.3. Assert Metrics. . . . . . . . . . . . . . . . . . . . . . . 80 4.5.3. Assert Metrics. . . . . . . . . . . . . . . . . . . . . . . 82
4.5.4. AssertCancel Messages . . . . . . . . . . . . . . . . . . . 82 4.5.4. AssertCancel Messages . . . . . . . . . . . . . . . . . . . 84
4.5.5. Assert State Macros . . . . . . . . . . . . . . . . . . . . 82 4.5.5. Assert State Macros . . . . . . . . . . . . . . . . . . . . 84
4.6. Designated Routers (DR) and Hello Messages . . . . . . . . . . 84 4.6. Designated Routers (DR) and Hello Messages . . . . . . . . . . 87
4.6.1. Sending Hello Messages. . . . . . . . . . . . . . . . . . . 84 4.6.1. Sending Hello Messages. . . . . . . . . . . . . . . . . . . 87
4.6.2. DR Election . . . . . . . . . . . . . . . . . . . . . . . . 85 4.6.2. DR Election . . . . . . . . . . . . . . . . . . . . . . . . 88
4.7. PIM Bootstrap and RP Discovery . . . . . . . . . . . . . . . . 87 4.6.3. Reducing Prune Propagation Delay on LANs. . . . . . . . . . 90
4.7.1. Group-to-RP Mapping . . . . . . . . . . . . . . . . . . . . 88 4.7. PIM Bootstrap and RP Discovery . . . . . . . . . . . . . . . . 92
4.7.2. Hash Function . . . . . . . . . . . . . . . . . . . . . . . 89 4.7.1. Group-to-RP Mapping . . . . . . . . . . . . . . . . . . . . 94
4.8. Source-Specific Multicast. . . . . . . . . . . . . . . . . . . 90 4.7.2. Hash Function . . . . . . . . . . . . . . . . . . . . . . . 94
4.8. Source-Specific Multicast. . . . . . . . . . . . . . . . . . . 95
4.8.1. Protocol Modifications for SSM destination 4.8.1. Protocol Modifications for SSM destination
addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.8.2. PIM-SSM-only Routers. . . . . . . . . . . . . . . . . . . . 91 4.8.2. PIM-SSM-only Routers. . . . . . . . . . . . . . . . . . . . 96
4.9. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . . 92 4.9. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . . 98
4.9.1. Encoded Source and Group Address Formats. . . . . . . . . . 93 4.9.1. Encoded Source and Group Address Formats. . . . . . . . . . 99
4.9.2. Hello Message Format. . . . . . . . . . . . . . . . . . . . 96 4.9.2. Hello Message Format. . . . . . . . . . . . . . . . . . . . 102
4.9.3. Register Message Format . . . . . . . . . . . . . . . . . . 99 4.9.3. Register Message Format . . . . . . . . . . . . . . . . . . 104
4.9.4. Register-Stop Message Format. . . . . . . . . . . . . . . . 100 4.9.4. Register-Stop Message Format. . . . . . . . . . . . . . . . 106
4.9.5. Join/Prune Message Format . . . . . . . . . . . . . . . . . 101 4.9.5. Join/Prune Message Format . . . . . . . . . . . . . . . . . 106
4.9.5.1. Group Set Source List Rules. . . . . . . . . . . . . . . 104 4.9.5.1. Group Set Source List Rules. . . . . . . . . . . . . . . 109
4.9.5.2. Group Set Fragmentation. . . . . . . . . . . . . . . . . 107 4.9.5.2. Group Set Fragmentation. . . . . . . . . . . . . . . . . 112
4.9.6. Assert Message Format . . . . . . . . . . . . . . . . . . . 108 4.9.6. Assert Message Format . . . . . . . . . . . . . . . . . . . 113
4.10. PIM Timers. . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.10. PIM Timers. . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.11. Timer Values. . . . . . . . . . . . . . . . . . . . . . . . . 110 4.11. Timer Values. . . . . . . . . . . . . . . . . . . . . . . . . 116
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 115 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 122
5.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . . 115 5.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . . 122
5.2. PIM Hello Options. . . . . . . . . . . . . . . . . . . . . . . 116 5.2. PIM Hello Options. . . . . . . . . . . . . . . . . . . . . . . 123
6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 116 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 123
7. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 116 6.1. Attacks based on forged messages . . . . . . . . . . . . . . . 123
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1.1. Forged link-local messages. . . . . . . . . . . . . . . . . 123
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1.2. Forged unicast messages . . . . . . . . . . . . . . . . . . 124
10. Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2. Non-cryptographic Authentication Mechanisms. . . . . . . . . . 124
6.2.1. Register Nonces . . . . . . . . . . . . . . . . . . . . . . 125
6.3. Authentication using IPsec . . . . . . . . . . . . . . . . . . 125
6.3.1. Protecting link-local multicast messages. . . . . . . . . . 126
6.3.2. Protecting unicast messages . . . . . . . . . . . . . . . . 126
6.3.2.1. Register messages. . . . . . . . . . . . . . . . . . . . 126
6.3.2.2. Register Stop messages . . . . . . . . . . . . . . . . . 127
6.4. Denial of Service Attacks. . . . . . . . . . . . . . . . . . . 127
7. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 127
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 128
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
10. Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
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 9, line 38 skipping to change at page 9, line 38
shared tree to the receiver is built. shared tree to the receiver is built.
Phase 3: Shortest-Path Tree Phase 3: Shortest-Path Tree
Although having the RP join back towards the source removes the Although having the RP join back towards the source removes the
encapsulation overhead, it does not completely optimize the forwarding encapsulation overhead, it does not completely optimize the forwarding
paths. For many receivers the route via the RP may involve a paths. For many receivers the route via the RP may involve a
significant detour when compared with the shortest path from the source significant detour when compared with the shortest path from the source
to the receiver. to the receiver.
To obtain lower latencies, a receiver's DR may optionally initiate a To obtain lower latencies, a router on the sender's LAN, typically the |
transfer from the shared tree to a source-specific shortest-path tree DR, may optionally initiate a transfer from the shared tree to a source- |
(SPT). To do this, it issues an (S,G) Join towards S. This specific shortest-path tree (SPT). To do this, it issues an (S,G) Join
instantiates state in the routers along the path to S. Eventually this towards S. This instantiates state in the routers along the path to S.
join either reaches S's subnet, or reaches a router that already has Eventually this join either reaches S's subnet, or reaches a router that
(S,G) state. When this happens, data packets from S start to flow already has (S,G) state. When this happens, data packets from S start
following the (S,G) state until they reach the receiver. to flow following the (S,G) state until they reach the receiver.
At this point the receiver (or a router upstream of the receiver) will At this point the receiver (or a router upstream of the receiver) will
be receiving two copies of the data - one from the SPT and one from the be receiving two copies of the data - one from the SPT and one from the
RPT. When the first traffic starts to arrive from the SPT, the DR or RPT. When the first traffic starts to arrive from the SPT, the DR or
upstream router starts to drop the packets for G from S that arrive via upstream router starts to drop the packets for G from S that arrive via
the RP tree. In addition, it sends an (S,G) prune message towards the the RP tree. In addition, it sends an (S,G) prune message towards the
RP. This is known as an (S,G,rpt) Prune. The prune message travels RP. This is known as an (S,G,rpt) Prune. The prune message travels
hop-by-hop, instantiating state along the path towards the RP indicating hop-by-hop, instantiating state along the path towards the RP indicating
that traffic from S for G should NOT be forwarded in this direction. that traffic from S for G should NOT be forwarded in this direction.
skipping to change at page 11, line 35 skipping to change at page 11, line 35
router has (S,G) state, then in favor of the router with the best metric router has (S,G) state, then in favor of the router with the best metric
to the RP for RP trees, or the best metric to the source to source- to the RP for RP trees, or the best metric to the source to source-
specific trees. specific trees.
These Assert messages are also received by the downstream routers on the These Assert messages are also received by the downstream routers on the
LAN, and these cause subsequent join messages to be sent to the upstream LAN, and these cause subsequent join messages to be sent to the upstream
router that won the Assert. router that won the Assert.
RP Discovery RP Discovery
PIM-SM routers need to know the address of the RP for each group for | PIM-SM routers need to know the address of the RP for each group for
which they have (*,G) state. This address is obtained either through a | which they have (*,G) state. This address is obtained either through a
bootstrap mechanism or through static configuration. | bootstrap mechanism or through static configuration.
One dynamic way to do this is to use the Bootstrap Router (BSR) | One dynamic way to do this is to use the Bootstrap Router (BSR)
mechanism [4]. One router in each PIM domain is elected the Bootstrap | mechanism [4]. One router in each PIM domain is elected the Bootstrap
Router through a simple election process. All the routers in the domain | Router through a simple election process. All the routers in the domain
that are configured to be candidates to be RPs periodically unicast | that are configured to be candidates to be RPs periodically unicast
their candidacy to the BSR. From the candidates, the BSR picks an RP- | their candidacy to the BSR. From the candidates, the BSR picks an RP-
set, and periodically announces this set in a bootstrap message. | set, and periodically announces this set in a bootstrap message.
Bootstrap messages are flooded hop-by-hop throughout the domain until | Bootstrap messages are flooded hop-by-hop throughout the domain until
all routers in the domain know the RP-Set. | all routers in the domain know the RP-Set.
To map a group to an RP, a router hashes the group address into the RP- To map a group to an RP, a router hashes the group address into the RP-
set using an order-preserving hash function (one that minimizes changes set using an order-preserving hash function (one that minimizes changes
if the RP set changes). The resulting RP is the one that it uses as the if the RP set changes). The resulting RP is the one that it uses as the
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:
skipping to change at page 12, line 23 skipping to change at page 12, line 23
o Section 4.3 specifies the PIM Register generation and processing o Section 4.3 specifies the PIM Register generation and processing
rules. rules.
o Section 4.4 specifies the PIM Join/Prune generation and processing o Section 4.4 specifies the PIM Join/Prune generation and processing
rules. rules.
o Section 4.5 specifies the PIM Assert generation and processing rules. o Section 4.5 specifies the PIM Assert generation and processing rules.
o Designated Router (DR) election is specified in Section 4.6. o Designated Router (DR) election is specified in Section 4.6.
o Section 4.7 specifies the RP discovery mechanisms. | o Section 4.7 specifies the RP discovery mechanisms.
o The subset of PIM required to support Source-Specific Multicast, PIM- o The subset of PIM required to support Source-Specific Multicast, PIM-
SSM, is described in Section 4.8. SSM, is described in Section 4.8.
o PIM packet formats are specified in Section 4.9. o PIM packet formats are specified in Section 4.9.
o A summary of PIM-SM timers and their default values is given in o A summary of PIM-SM timers and their default values is given in
Section 4.10. Section 4.10.
4.1. PIM Protocol State 4.1. PIM Protocol State
skipping to change at page 13, line 36 skipping to change at page 13, line 36
forwarding operations - for example, the "NoInfo" state might be assumed forwarding operations - for example, the "NoInfo" state might be assumed
from the lack of other state information, rather than being held from the lack of other state information, rather than being held
explicitly. explicitly.
4.1.1. General Purpose State 4.1.1. General Purpose State
A router holds the following non-group-specific state: A router holds the following non-group-specific state:
For each interface: For each interface:
o Override Interval
o Propagation Delay
o Suppression state: One of {"Enable", "Disable"}
Neighbor State: Neighbor State:
For each neighbor: For each neighbor:
o Information from neighbor's Hello o Information from neighbor's Hello
o Neighbor's Gen ID. o Neighbor's Gen ID.
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
Designated Router state is described in section 4.6. | The Override Interval, the Propagation Delay and the Interface |
suppression state are described in section 4.6.3. Designated Router |
state is described in section 4.6.
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 21, line 40 skipping to change at page 21, line 42
{ all interfaces I such that { all interfaces I such that
DownstreamJPState(S,G,I) is either Joined or PrunePending } DownstreamJPState(S,G,I) is either Joined 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.4.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,I) is Pruned or PruneTmp } DownstreamJPState(S,G,rpt,I) is Pruned or PruneTmp } |
DownstreamJPState(S,G,rpt,I) is the state of the finite state machine in
section 4.4.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.5.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
skipping to change at page 24, line 4 skipping to change at page 24, line 13
directly connected subnet. directly connected subnet.
Second, we check to see if the SPT bit should be set because we've now Second, we check to see if the SPT bit should be set because we've now
switched from the RP tree to the SPT. switched from the RP tree to the SPT.
Next we check to see whether the packet should be accepted based on TIB Next we check to see whether the packet should be accepted based on TIB
state and the interface that the packet arrived on. state and the interface that the packet arrived on.
If the packet should be forwarded using (S,G) state, we then build an If the packet should be forwarded using (S,G) state, we then build an
outgoing interface list for the packet. If this list is not empty, then outgoing interface list for the packet. If this list is not empty, then
we refresh the (S,G) state keepalive timer. we refresh the (S,G) state keepalive timer.
If the packet should be forwarded using (*,*,RP) or (*,G) state, then we If the packet should be forwarded using (*,*,RP) or (*,G) state, then we
just build an outgoing interface list for the packet. just build an outgoing interface list for the packet. We also check if |
we should initiate a switch to start receiving this source on a shortest |
path tree. |
Finally we remove the incoming interface from the outgoing interface Finally we remove the incoming interface from the outgoing interface
list we've created, and if the resulting outgoing interface list is not list we've created, and if the resulting outgoing interface list is not
empty, we forward the packet out of those interfaces. empty, we forward the packet out of those interfaces.
On receipt on a data from S to G on interface iif: On receipt on a data from S to G on interface iif:
if( DirectlyConnected(S) == TRUE ) { if( DirectlyConnected(S) == TRUE ) {
set KeepaliveTimer(S,G) to Keepalive_Period set KeepaliveTimer(S,G) to Keepalive_Period
# Note: register state transition may happen as a result # Note: register state transition may happen as a result
# of restarting KeepaliveTimer, and must be dealt with here. # of restarting KeepaliveTimer, and must be dealt with here.
} }
Update_SPTbit(S,G,iif) Update_SPTbit(S,G,iif)
oiflist = NULL |
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) { if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) { |
oiflist = inherited_olist(S,G) oiflist = inherited_olist(S,G) |
if( oiflist != NULL ) { if( oiflist != NULL ) { |
restart KeepaliveTimer(S,G) restart KeepaliveTimer(S,G) |
} } |
} else if( iif == RPF_interface(RP) AND SPTbit(S,G) == FALSE) { } else if( iif == RPF_interface(RP) AND SPTbit(S,G) == FALSE) { |
oiflist = inherited_olist(S,G,rpt) oiflist = inherited_olist(S,G,rpt) |
} else { CheckSwitchToSpt(S,G) |
# Note: RPF check failed } else { |
if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) { # Note: RPF check failed |
send Assert(S,G) on iif if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) { |
} else if ( SPTbit(S,G) == FALSE AND send Assert(S,G) on iif |
iif is in inherited_olist(S,G,rpt) { } else if ( SPTbit(S,G) == FALSE AND |
send Assert(*,G) on iif iif is in inherited_olist(S,G,rpt) { |
} send Assert(*,G) on iif |
} } |
} |
oiflist = oiflist (-) iif oiflist = oiflist (-) iif |
forward packet on all interfaces in oiflist forward packet on all interfaces in oiflist |
This pseudocode employs several "macro" definitions: This pseudocode employs several "macro" definitions:
directly_connected(S) is TRUE if the source S is on any subnet that is directly_connected(S) is TRUE if the source S is on any subnet that is
directly connected to this router (or for packets originating on this directly connected to this router (or for packets originating on this
router). router).
inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section
4.1. 4.1.
Basically inherited_olist(S,G) is the outgoing interface list for Basically inherited_olist(S,G) is the outgoing interface list for
packets forwarded on (S,G) state taking into account (*,*,RP) state, packets forwarded on (S,G) state taking into account (*,*,RP) state,
(*,G) state, asserts, etc. (*,G) state, asserts, etc.
inherited_olist(S,G,rpt) is the outgoing interface for packets forwarded inherited_olist(S,G,rpt) is the outgoing interface 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.1. Update_SPTbit(S,G,iif) is defined in section 4.2.2.
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.4.7.
Keepalive_Period is defined in Section 4.10. Keepalive_Period is defined in Section 4.10.
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. Setting and Clearing the (S,G) SPT bit 4.2.1. Last hop switchover to the SPT |
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 |
router it has the option of switching to receive the traffic on a |
shortest path tree (SPT). |
The decision for a rotuer to switch to the SPT is controlled as follows: |
void |
CheckSwitchToSpt(S,G) { |
if ( ( pim_include(*,G) (-) pim_exclude(S,G) |
(+) pim_include(S,G) != NULL ) |
AND SwitchToSptDesired(S,G) ) { |
restart KeepAliveTimer(S,G); |
} |
} |
SwitchToSptDesired(S,G) is a policy function that is implementation |
defined. An "infinite threshhold" policy can be implemented making |
SwitchToSptDesired(S,G) return false all the time. A "switch on first |
packet" policy can be implemented by making SwitchToSptDesired(S,G) |
return true once a single packet has been received for the source and |
group. |
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
to upstream (*,*,RP)/(*,G) state while upstream (S,G) state is being to upstream (*,*,RP)/(*,G) state while upstream (S,G) state is being
established during which time a router should continue to forward only established during which time a router should continue to forward only
on (*,*,RP)/(*,G) state. This prevents temporary black-holes that would on (*,*,RP)/(*,G) state. This prevents temporary black-holes that would
be caused by sending a Prune(S,G,rpt) before the upstream (S,G) state be caused by sending a Prune(S,G,rpt) before the upstream (S,G) state
has finished being established. has finished being established.
Thus, when a packet arrives, the (S,G) SPTbit is updated as follows: Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:
void void
Update_SPTbit(S,G,iif) { Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S) if ( iif == RPF_interface(S)
skipping to change at page 25, line 48 skipping to change at page 27, line 24
if ( iif == RPF_interface(S) if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP) 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 sees 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.4.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
skipping to change at page 26, line 46 skipping to change at page 28, line 21
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 to the RP. | DR will resume encapsulating packets from the source to the RP. |
4.3.1. Sending Register Messages from the DR 4.3.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 specified in Section 4.2. forwarding rules 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
per-(S,G) Register state-machine: per-(S,G) Register state-machine:
Join (J) Join (J)
skipping to change at page 28, line 5 skipping to change at page 29, line 15
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.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 1: Per-(S,G) register state-machine at a DR Figure 1: Per-(S,G) register state-machine at a DR
In tabular form, the state-machine is: In tabular form, the state-machine is: |
+---------+-----------------------------------------------------------------+ +---------------------++-------------------------------------------------|---------------------------------------|
| | Event | | || Event || |
| +------------+--------------+-------------+-----------+-----------+ | ++----------------+--------------+-----------------|------------------|--------------------|
Prev StateRegister- CouldRegister CouldRegister Register- RP changed | |Prev State | ||Register- | | Could- | | Could- | | Register- || | RP changed || |
| Stop Timer ->True ->False Stop | | | ||Stop Timer | | Register | | Register | | Stop || | |
| expires | | received | | | ||expires | | ->True | | ->False | | received || | |
+---------+------------+--------------+-------------+-----------+-----------+ +---------------------++----------------+--------------+-----------------+------------------+--------------------|
No Info + +> J state + + + | |No Info (NI) | ||- | -> J state | - | - | -| |
(NI) | add tunnel | | | | | || | add tunnel | | | |
+---------+------------+--------------+-------------+-----------+-----------+ +---------------------++----------------+--------------+-----------------+------------------+--------------------|
| + + +> NI state +> P state +> J state | | ||- | - | -> NI state | -> P state | -> J state| |
| | | remove tunnel remove redirect | | || | | remove tunnel | remove || | redirect || |
| | | | tunnel; tunnel to | |Join (J) | || | | | tunnel; set || | tunnel to || |
Join (J) | | | set new RP; | | || | | | Register- || | new RP || |
| | | | Register- stop | | || | | | Stop || | |
| | | | Stop Register- | | || | | | timer(*) || | |
| | | | timer(*) Stop timer | +---------------------++----------------+--------------+-----------------+------------------+--------------------|
+---------+------------+--------------+-------------+-----------+-----------+ | ||-> J state | - | -> NI state | -> P state | -> J state| |
| +> J state + +> NI state +> P state +> J state | | ||add tunnel | | remove tunnel | set Register- ||| redirect || |
| add tunnel | remove tunnel set redirect | |Join Pending | || | | | Stop timer(*) ||| tunnel to new || |
Join | | | Register- tunnel to | |(JP) | || | | | | RP; cancel || |
Pending | | | Stop new RP; | | || | | | | Register-Stop || |
(JP) | | | timer(*) stop | | || | | | | timer || |
| | | | | Register- | +---------------------++----------------+--------------+-----------------+------------------+--------------------|
| | | | | Stop timer | | ||-> JP state | - | -> NI state | - | -> J state| |
+---------+------------+--------------+-------------+-----------+-----------+ | ||set Register- | | | remove tunnel | | redirect tunnel |||
| +> JP state + +> NI state + +> J state | |Prune (P) | ||Stop | | | | | to new RP; |||
| set | remove tunnel | redirect | | ||timer(**); | | | | | cancel Register- |||
| Register- | | | tunnel to | | ||send null | | | | | Stop timer |||
Prune (P) Stop | | | new RP; | | ||register | | | | | |
| timer(**); | | | stop | +---------------------++----------------+--------------+-----------------+------------------+--------------------|
| send null | | | Register- |
| register | | | Stop timer |
+---------+------------+--------------+-------------+-----------+-----------+
Notes: Notes:
(*) The RegisterStopTimer is set to a random value chosen uniformly from (*) The RegisterStopTimer is set to a random value chosen uniformly from
the interval ( 0.5 * Register_Suppression_Time, 1.5 * the interval ( 0.5 * Register_Suppression_Time, 1.5 *
Register_Suppression_Time) minus Register_Probe_Time; Register_Suppression_Time) minus Register_Probe_Time;
Subtracting off register_probe_time is a bit unnecessary because it is Subtracting off register_probe_time is a bit unnecessary because it is
really small compared to register suppression timeout, but was in the really small compared to register suppression timeout, but was in the
old spec and is kept for compatibility. old spec and is kept for compatibility.
skipping to change at page 29, line 20 skipping to change at page 30, line 30
return ( I_am_DR( RPF_interface(S) ) AND return ( I_am_DR( RPF_interface(S) ) AND
KeepaliveTimer(S,G) is running AND KeepaliveTimer(S,G) is running AND
DirectlyConnected(S) == TRUE ) DirectlyConnected(S) == TRUE )
} }
Note that on reception of a packet at the DR from a directly connected Note that on reception of a packet at the DR from a directly connected
source, KeepaliveTimer(S,G) needs to be set by the packet forwarding source, KeepaliveTimer(S,G) needs to be set by the packet forwarding
rules before computing CouldRegister(S,G) in the register state machine, rules before computing CouldRegister(S,G) in the register state machine,
or the first packet from a source won't be registered. or the first packet from a source won't be registered.
Encapsulating data packets in the Register Tunnel | Encapsulating data packets in the Register Tunnel
Conceptually, the Register Tunnel is an interface with a smaller MTU | Conceptually, the Register Tunnel is an interface with a smaller MTU
than the underlying IP interface towards the RP. IP fragmentation on | than the underlying IP interface towards the RP. IP fragmentation on
packets forwarded on the Register Tunnel is performed based upon this | packets forwarded on the Register Tunnel is performed based upon this
smaller MTU. The encapsulating DR may perform Path-MTU Discovery to the | smaller MTU. The encapsulating DR may perform Path-MTU Discovery to the
RP to determine the effective MTU of the tunnel. | RP to determine the effective MTU of the tunnel. This smaller MTU takes |
both the outer IP header and the PIM register header overhead into |
account. If a multicast packet is fragmented on the way into the |
Register Tunnel, each fragment is encapsulated individually so contains |
IP, PIM, and inner IP headers. |
In IPv6, an ICMP Fragmentation Required message may be sent by the | In IPv6, an ICMP Fragmentation Required message may be sent by the
encapsulating DR. | encapsulating DR.
Just like any forwarded packet, the TTL of the original data packet is | Just like any forwarded packet, the TTL of the original data packet is
decremented before it is encapsulated in the Register Tunnel. | decremented before it is encapsulated in the Register Tunnel. |
Handling RegisterStop(*,G) Messages at the DR | The IP ECN bits should be copied from the original packet to the IP |
header of the encapsulating packet. They SHOULD NOT be set |
An old RP might send a RegisterStop message with the source address set | independently by the encapsulating router. |
to all-zeros. This was the normal course of action in RFC 2326 when the |
The Diffserv Code Point (DSCP) should be copied from the original packet |
to the IP header of the encapsulating packet. It MAY be set |
independently by the encapsulating router, based upon static |
configuration or traffic classification. See [11] for more discussion |
on setting the DSCP on tunnels. |
Handling RegisterStop(*,G) Messages at the DR
An old RP might send a RegisterStop message with the source address set
to all-zeros. This was the normal course of action in RFC 2326 when the
register message matched against (*,G) state at the RP, and was defined register message matched against (*,G) state at the RP, and was defined
as meaning "stop encapsulating all sources for this group". However, as meaning "stop encapsulating all sources for this group". However,
the behavior of such a RegisterStop(*,G) is ambiguous or incorrect in the behavior of such a RegisterStop(*,G) is ambiguous or incorrect in
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.3.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.
skipping to change at page 31, line 16 skipping to change at page 33, line 12
proper tunnel interface. This may cause the upstream (S,G) state proper tunnel interface. This may cause the upstream (S,G) state
machine to trigger a join if the inherited_olist(S,G) is not NULL; machine to trigger a join if the inherited_olist(S,G) is not NULL;
An RP should preserve (S,G) state that was created in response to a An RP should preserve (S,G) state that was created in response to a
Register message for at least ( 3 * Register_Suppression_Time ), Register message for at least ( 3 * Register_Suppression_Time ),
otherwise the RP may stop joining (S,G) before the DR for S has otherwise the RP may stop joining (S,G) before the DR for S has
restarted sending registers. Traffic would then be interrupted until restarted sending registers. Traffic would then be interrupted until
the Register-Stop timer expires at the DR. the Register-Stop timer expires at the DR.
Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 * Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 *
Register_Suppression_Time + Register_Probe_Time ). | Register_Suppression_Time + Register_Probe_Time ).
Just like any forwarded packet, the TTL of the original data packet is | Just like any forwarded packet, the TTL of the original data packet is
decremented after it is decapsulated from the Register Tunnel. | decremented after it is decapsulated from the Register Tunnel. |
The IP ECN bits should be copied from the IP header of the Register |
packet to the decapsulated packet. |
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 |
DSCP of the inner packet, or re-classify the packet and apply a |
different DSCP. Scenarios where each of these might be useful are |
discussed in [11]. |
4.4. PIM Join/Prune Messages 4.4. 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, (*,*,RP) Joins and Prunes PIM Destination field addresses this router, (*,*,RP) Joins and Prunes
can affect the (*,*,RP) and (S,G,rpt) downstream state machines, (*,G) can affect the (*,*,RP) and (S,G,rpt) downstream state machines, (*,G)
Joins and Prunes can affect both the (*,G) and (S,G,rpt) downstream Joins and Prunes can affect both the (*,G) and (S,G,rpt) downstream
state machines, while (S,G) and (S,G,rpt) Joins and Prunes can only state machines, while (S,G) and (S,G,rpt) Joins and Prunes can only
affect their respective downstream state machines. When considering a affect their respective downstream state machines. When considering a
Join/Prune message whose PIM Destination field addresses another router, Join/Prune message whose PIM Destination field addresses another router,
most Join or Prune messages could affect each upstream state machine. most Join or Prune messages could affect each upstream state machine.
(... it's possible to enumerate this ...) XXX
4.4.1. Receiving (*,*,RP) Join/Prune Messages 4.4.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.
skipping to change at page 33, line 5 skipping to change at page 35, line 5
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 group. revert to NoInfo for this group.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 2: Downstream (*,*,RP) per-interface state-machine Figure 2: Downstream (*,*,RP) per-interface state-machine
In tabular form, the per-interface (*,*,RP) state-machine is: 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(*,*,RP) |Pending |Expires | | ||Join(*,*,RP) | | Prune(*,*,RP)| | Pending| || | Expires |||
| | | |Timer | | | || | | Timer || | |
| | | |Expires | | | || | | Expires || | |
+-------------+-------------+--------------+--------------+------------+ +---------------------++---------------------+------------------+------------------+----------------|
| |-> J state |-> NI state |- |- | | ||-> J state | -> NI state | - | -| |
|NoInfo (NI) |start Expiry | | | | |NoInfo (NI) | ||start Expiry | | | | | |
| |Timer | | | | | ||Timer | | | | | |
+-------------+-------------+--------------+--------------+------------+ +---------------------++---------------------+------------------+------------------+----------------|
| |-> J state |-> PP state |- |-> NI state | | ||-> J state | -> PP state | - | -> NI state| |
|Join (J) |restart |start Prune | | | |Join (J) | ||restart Expiry | | start Prune | | | | |
| |Expiry Timer |Pending Timer | | | | ||Timer | | Pending Timer | | | | |
+-------------+-------------+--------------+--------------+------------+ +---------------------++---------------------+------------------+------------------+----------------|
| |-> J state |-> PP state |-> NI state |-> NI state | | ||-> J state | -> PP state | -> NI state | -> NI state| |
| |restart | |Send Prune- | | | ||restart Expiry | | | Send Prune- ||| |
|Prune |Expiry | |Echo(*,*,RP) | | |Prune Pending (PP) | ||Timer; cancel | | | Echo(*,*,RP) ||| |
|Pending (PP) |Timer; stop | | | | | ||Prune Pending | | | | | |
| |Prune | | | | | ||Timer | | | | | |
| |Pending | | | | +---------------------++---------------------+------------------+------------------+----------------|
| |Timer | | | |
+-------------+-------------+--------------+--------------+------------+
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 packet should be the same as the source address it chose for the hello packet
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 0.0.0.0 destination address are also recommend that PIM messages with a 0.0.0.0 destination address are also
accepted. 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 IP A Join(*,*,RP) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I |
transitions to the Join state. The Expiry Timer (ET) is transitions to the Join state. The Expiry Timer (ET) is |
started, and set to the HoldTime from the triggering | started, and set to the HoldTime from the triggering |
Join/Prune message. | Join/Prune message. |
Transitions from Join State Transitions from Join State
When in Join state, the following events may trigger a transition: When in Join state, the following events may trigger a transition:
Receive Join(*,*,RP) Receive Join(*,*,RP)
A Join(*,*,RP) is received on interface I with its IP A Join(*,*,RP) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (*,*,RP) downstream state machine on interface I remains The (*,*,RP) downstream state machine on interface I remains
in Join state, and the Expiry Timer (ET) is restarted, set to | in Join state, and the Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the | maximum of its current value and the HoldTime from the
triggering Join/Prune message. | triggering Join/Prune message.
Receive Prune(*,*,RP) Receive Prune(*,*,RP)
A Prune(*,*,RP) is received on interface I with its IP A Prune(*,*,RP) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
transitions to the PrunePending state. The PrunePending timer transitions to the PrunePending state. The PrunePending timer
is started; it is set to the J/P_Override_Interval if the is started; it is set to the J/P_Override_Interval if the
router has more than one neighbor on that interface; otherwise router has more than one neighbor on that interface; otherwise
it is set to zero causing it to expire immediately. it is set to zero causing it to expire immediately.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (*,*,RP) downstream state machine on The Expiry Timer for the (*,*,RP) downstream state machine on
interface I expires. interface I expires.
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
transitions to the NoInfo state. transitions to the NoInfo state.
Transitions from PrunePending State Transitions from PrunePending State
When in PrunePending state, the following events may trigger a When in PrunePending state, the following events may trigger a
transition: transition:
Receive Join(*,*,RP) Receive Join(*,*,RP)
A Join(*,*,RP) is received on interface I with its IP A Join(*,*,RP) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
transitions to the Join state. The PrunePending timer is transitions to the Join state. The PrunePending timer is
canceled (without triggering an expiry event). The Expiry | canceled (without triggering an expiry event). The Expiry
Timer is restarted, set to maximum of its current value and | Timer is restarted, set to maximum of its current value and
the HoldTime from the triggering Join/Prune message. | the HoldTime from the triggering Join/Prune message.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (*,*,RP) downstream state machine on The Expiry Timer for the (*,*,RP) downstream state machine on
interface I expires. interface I expires.
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
transitions to the NoInfo state. transitions to the NoInfo state.
PrunePending Timer Expires PrunePending Timer Expires
The PrunePending Timer for the (*,*,RP) downstream state The PrunePending Timer for the (*,*,RP) downstream state
machine on interface I expires. machine on interface I expires.
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
transitions to the NoInfo state. A PruneEcho(*,*,RP) is sent transitions to the NoInfo state. A PruneEcho(*,*,RP) is sent
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 to itself on a LAN. By "to | sent by the upstream router on a LAN with its own address in |
itself" we mean that the Upstream Neighbor Address field of | the Upstream Neighbor Address field. Its purpose is to add |
the enclosing Join/Prune message is set to the address of the | additional reliability so that if a Prune that should have
sending router. Its purpose is to add additional reliability | been overridden by another router is lost locally on the LAN,
so that if a Prune that should have been overridden by another | then the PruneEcho may be received and cause the override to
router is lost locally on the LAN, then the PruneEcho may be happen. A PruneEcho(*,*,RP) need not be sent on a point-to-
received and cause the override to happen. A point interface.
PruneEcho(*,*,RP) need not be sent on a point-to-point
interface.
4.4.2. Receiving (*,G) Join/Prune Messages 4.4.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).
skipping to change at page 37, line 5 skipping to change at page 39, line 5
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.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 3: Downstream (*,G) per-interface state-machine Figure 3: Downstream (*,G) per-interface state-machine
In tabular form, the per-interface (*,G) state-machine is: 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 | - | -| |
|NoInfo (NI) ||start Expiry | | | | |NoInfo (NI) | ||start Expiry | | | | | |
| ||Timer | | | | | ||Timer | | | | | |
+-------------++-------------+-------------+-------------+--------------+ +---------------------++---------------------+------------------+------------------+----------------|
| ||-> J state | -> PP state | - | -> NI state | | ||-> J state | -> PP state | - | -> NI state| |
|Join (J) ||restart | start Prune | | | |Join (J) | ||restart Expiry | | start Prune | | | | |
| ||Expiry Timer | Pending | | | | ||Timer | | Pending Timer | | | | |
| || | Timer | | | +---------------------++---------------------+------------------+------------------+----------------|
+-------------++-------------+-------------+-------------+--------------+ | ||-> J state | -> PP state | -> NI state | -> NI state| |
| ||-> J state | -> PP state | -> NI state | -> NI state | | ||restart Expiry | | | Send Prune- ||| |
| ||restart | | Send Prune- | | |Prune Pending (PP) | ||Timer; cancel | | | Echo(*,G) ||| |
|Prune ||Expiry | | Echo(*,G) | | | ||Prune Pending | | | | | |
|Pending (PP) ||Timer; stop | | | | | ||Timer | | | | | |
| ||Prune | | | | +---------------------++---------------------+------------------+------------------+----------------|
| ||Pending | | | |
| ||Timer | | | |
+-------------++-------------+-------------+-------------+--------------+
The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply
receiving a Join or Prune targeted to this router's address on the receiving a Join or Prune targeted to this router's 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 packet should be the same as the source address it chose for the hello packet
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 0.0.0.0 destination address are also recommend that PIM messages with a 0.0.0.0 destination address are also
accepted. accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its IP destination A Join(*,G) is received on interface I with its Upstream |
set to the router's address on I. Neighbor Address set to the router's address on I. |
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I transitions
to the Join state. The Expiry Timer (ET) is started, and set to the Join state. The Expiry Timer (ET) is started, and set
to the HoldTime from the triggering Join/Prune message. | to the HoldTime from the triggering Join/Prune message.
Transitions from Join State Transitions from Join State
When in Join state, the following events may trigger a transition: When in Join state, the following events may trigger a transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its IP destination A Join(*,G) is received on interface I with its Upstream |
set to the router's address on I. Neighbor Address set to the router's address on I. |
The (*,G) downstream state machine on interface I remains in The (*,G) downstream state machine on interface I remains in
Join state, and the Expiry Timer (ET) is restarted, set to | Join state, and the Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the | maximum of its current value and the HoldTime from the
triggering Join/Prune message. | triggering Join/Prune message.
Receive Prune(*,G) Receive Prune(*,G)
A Prune(*,G) is received on interface I with its IP A Prune(*,G) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I transitions
to the PrunePending state. The PrunePending timer is started; to the PrunePending state. The PrunePending timer is started;
it is set to the J/P_Override_Interval if the router has more it is set to the J/P_Override_Interval if the router has more
than one neighbor on that interface; otherwise it is set to than one neighbor on that interface; otherwise it is set to
zero causing it to expire immediately. zero causing it to expire immediately.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (*,G) downstream state machine on The Expiry Timer for the (*,G) downstream state machine on
interface I expires. interface I expires.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I transitions
to the NoInfo state. to the NoInfo state.
Transitions from PrunePending State Transitions from PrunePending State
When in PrunePending state, the following events may trigger a When in PrunePending state, the following events may trigger a
transition: transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its IP destination A Join(*,G) is received on interface I with its Upstream |
set to the router's address on I. Neighbor Address set to the router's address on I. |
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I transitions
to the Join state. The PrunePending timer is canceled to the Join state. The PrunePending timer is canceled
(without triggering an expiry event). The Expiry Timer is | (without triggering an expiry event). The Expiry Timer is
restarted, set to maximum of its current value and the | restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message. | HoldTime from the triggering Join/Prune message.
Expiry Timer Expires |
The Expiry Timer for the (*,G) downstream state machine on |
interface I expires. |
The (*,G) downstream state machine on interface I transitions | Expiry Timer Expires
to the NoInfo state. | The Expiry Timer for the (*,G) downstream state machine on
interface I expires.
PrunePending Timer Expires | The (*,G) downstream state machine on interface I transitions
The PrunePending Timer for the (*,G) downstream state machine | to the NoInfo state.
on interface I expires. |
The (*,G) downstream state machine on interface I transitions | PrunePending Timer Expires
to the NoInfo state. A PruneEcho(*,G) is sent onto the subnet | The PrunePending Timer for the (*,G) downstream state machine
connected to interface I. | on interface I expires.
The action "Send PruneEcho(*,G)" is triggered when the router | The (*,G) downstream state machine on interface I transitions
stops forwarding on an interface as a result of a prune. A | to the NoInfo state. A PruneEcho(*,G) is sent onto the subnet
connected to interface I.
The action "Send PruneEcho(*,G)" is triggered when the router
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 to itself on a LAN. By "to itself" we mean | upstream router on a LAN with its own address in the Upstream |
that the Upstream Neighbor Address field of the enclosing | Neighbor Address field. Its purpose is to add additional |
Join/Prune message is set to the address of the sending | reliability so that if a Prune that should have been
router. Its purpose is to add additional reliability so that | overridden by another router is lost locally on the LAN, then
if a Prune that should have been overridden by another router | the PruneEcho may be received and cause the override to
is lost locally on the LAN, then the PruneEcho may be received happen. A PruneEcho(*,G) need not be sent on a point-to-point
and cause the override to happen. A PruneEcho(*,G) need not interface.
be sent on a point-to-point interface.
4.4.3. Receiving (S,G) Join/Prune Messages 4.4.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.
skipping to change at page 41, line 5 skipping to change at page 42, line 21
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 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.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 4: Downstream per-interface (S,G) state-machine Figure 4: Downstream per-interface (S,G) state-machine
In tabular form, the state machine is: 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 | - | -| |
|NoInfo (NI) ||start Expiry | | | | |NoInfo (NI) | ||start Expiry | | | | | |
| ||Timer | | | | | ||Timer | | | | | |
+-------------++-------------+-------------+-------------+--------------+ +---------------------++---------------------+------------------+------------------+----------------|
| ||-> J state | -> PP state | - | -> NI state | | ||-> J state | -> PP state | - | -> NI state| |
|Join (J) ||restart | start Prune | | | |Join (J) | ||restart Expiry | | start Prune | | | | |
| ||Expiry Timer | Pending | | | | ||Timer | | Pending Timer | | | | |
| || | Timer | | | +---------------------++---------------------+------------------+------------------+----------------|
+-------------++-------------+-------------+-------------+--------------+ | ||-> J state | -> PP state | -> NI state | -> NI state| |
| ||-> J state | -> PP state | -> NI state | -> NI state | | ||restart Expiry | | | Send Prune- ||| |
| ||restart | | Send Prune- | | |Prune Pending (PP) | ||Timer; cancel | | | Echo(S,G) ||| |
|Prune ||Expiry | | Echo(S,G) | | | ||Prune Pending | | | | | |
|Pending (PP) ||Timer; stop | | | | | ||Timer | | | | | |
| ||Prune | | | | +---------------------++---------------------+------------------+------------------+----------------|
| ||Pending | | | |
| ||Timer | | | |
+-------------++-------------+-------------+-------------+--------------+
The transition events "Receive Join(S,G)" and "Receive Prune(S,G)" imply The transition events "Receive Join(S,G)" and "Receive Prune(S,G)" imply
receiving a Join or Prune targeted to this router's address on the receiving a Join or Prune targeted to this router's 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 packet should be the same as the source address it chose for the hello packet
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 0.0.0.0 destination address are also recommend that PIM messages with a 0.0.0.0 destination address are also
accepted. accepted.
Transitions from NoInfo State Transitions from NoInfo State
skipping to change at page 41, line 50 skipping to change at page 43, line 18
should be the same as the source address it chose for the hello packet should be the same as the source address it chose for the hello packet
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 0.0.0.0 destination address are also recommend that PIM messages with a 0.0.0.0 destination address are also
accepted. accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(S,G) Receive Join(S,G)
A Join(S,G) is received on interface I with its IP destination A Join(S,G) is received on interface I with its Upstream |
set to the router's address on I. Neighbor Address set to the router's address on I. |
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I transitions
to the Join state. The Expiry Timer (ET) is started, and set to the Join state. The Expiry Timer (ET) is started, and set
to the HoldTime from the triggering Join/Prune message. | to the HoldTime from the triggering Join/Prune message.
Transitions from Join State Transitions from Join State
When in Join state, the following events may trigger a transition: When in Join state, the following events may trigger a transition:
Receive Join(S,G) Receive Join(S,G)
A Join(S,G) is received on interface I with its IP destination A Join(S,G) is received on interface I with its Upstream |
set to the router's address on I. Neighbor Address set to the router's address on I. |
The (S,G) downstream state machine on interface I remains in The (S,G) downstream state machine on interface I remains in
Join state, and the Expiry Timer (ET) is restarted, set to | Join state, and the Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the | maximum of its current value and the HoldTime from the
triggering Join/Prune message. | triggering Join/Prune message.
Receive Prune(S,G) Receive Prune(S,G)
A Prune(S,G) is received on interface I with its IP A Prune(S,G) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I transitions
to the PrunePending state. The PrunePending timer is started; to the PrunePending state. The PrunePending timer is started;
it is set to the J/P_Override_Interval if the router has more it is set to the J/P_Override_Interval if the router has more
than one neighbor on that interface; otherwise it is set to than one neighbor on that interface; otherwise it is set to
zero causing it to expire immediately. zero causing it to expire immediately.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (S,G) downstream state machine on The Expiry Timer for the (S,G) downstream state machine on
interface I expires. interface I expires.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I transitions
to the NoInfo state. to the NoInfo state.
Transitions from PrunePending State Transitions from PrunePending State
When in PrunePending state, the following events may trigger a When in PrunePending state, the following events may trigger a
transition: transition:
Receive Join(S,G) Receive Join(S,G)
A Join(S,G) is received on interface I with its IP destination A Join(S,G) is received on interface I with its Upstream |
set to the router's address on I. Neighbor Address set to the router's address on I. |
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I transitions
to the Join state. The PrunePending timer is canceled to the Join state. The PrunePending timer is canceled
(without triggering an expiry event). The Expiry Timer is | (without triggering an expiry event). The Expiry Timer is
restarted, set to maximum of its current value and the | restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message. | HoldTime from the triggering Join/Prune message.
Expiry Timer Expires |
The Expiry Timer for the (S,G) downstream state machine on |
interface I expires. |
The (S,G) downstream state machine on interface I transitions | Expiry Timer Expires
to the NoInfo state. | The Expiry Timer for the (S,G) downstream state machine on
interface I expires.
PrunePending Timer Expires | The (S,G) downstream state machine on interface I transitions
The PrunePending Timer for the (S,G) downstream state machine | to the NoInfo state.
on interface I expires. |
The (S,G) downstream state machine on interface I transitions | PrunePending Timer Expires
to the NoInfo state. A PruneEcho(S,G) is sent onto the subnet | The PrunePending Timer for the (S,G) downstream state machine
connected to interface I. | on interface I expires.
The action "Send PruneEcho(S,G)" is triggered when the router | The (S,G) downstream state machine on interface I transitions
stops forwarding on an interface as a result of a prune. A | to the NoInfo state. A PruneEcho(S,G) is sent onto the subnet
connected to interface I.
The action "Send PruneEcho(S,G)" is triggered when the router
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 to itself on a LAN. By "to itself" we mean | upstream router on a LAN with its own address in the Upstream |
that the Upstream Neighbor Address field of the enclosing | Neighbor Address field. Its purpose is to add additional |
Join/Prune message is set to the address of the sending | reliability so that if a Prune that should have been
router. Its purpose is to add additional reliability so that | overridden by another router is lost locally on the LAN, then
if a Prune that should have been overridden by another router | the PruneEcho may be received and cause the override to
is lost locally on the LAN, then the PruneEcho may be received happen. A PruneEcho(S,G) need not be sent on a point-to-point
and cause the override to happen. A PruneEcho(S,G) need not interface.
be sent on a point-to-point interface.
4.4.4. Receiving (S,G,rpt) Join/Prune Messages 4.4.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.
skipping to change at page 45, line 7 skipping to change at page 47, line 7
move on to Prune state. move on to Prune state.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 5: Downstream per-interface (S,G,rpt) state-machine Figure 5: Downstream per-interface (S,G,rpt) state-machine
In tabular form, the state machine is: 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 |
| |or |(S,G,rpt) (S,G,rpt) | |Timer |Expires | | ||or | (S,G,rpt) | (S,G,rpt) | | Timer | Expires |
| |Join(*,*,RP(G)) | | | |Expires| | | ||Join(*,*,RP(G)) | | | | Expires | |
+-------+----------------+----------+---------+--------+-------+--------+ +--------++----------------+-----------+-----------+---------+---------+---------+
| |- |- +> PP |- |n/a |n/a | | ||- | - | -> PP | - | n/a | n/a |
| | | state | | | | | || | | state | | | |
| | | start | | | | | || | | start | | | |
| | | Prune | | | | | || | | Prune | | | |
|No Info| | Pending | | | | |No Info || | | Pending | | | |
|(NI) | | Timer; | | | | |(NI) || | | Timer; | | | |
| | | start | | | | | || | | start | | | |
| | | Expiry | | | | | || | | Expiry | | | |
| | | Timer | | | | | || | | Timer | | | |
| | | Timer | | | | | || | | Timer | | | |
+-------+----------------+----------+---------+--------+-------+--------+ +--------++----------------+-----------+-----------+---------+---------+---------+
| |-> P' state |-> NI +> P |- |n/a |-> NI | | ||-> P' state | -> NI | -> P | - | n/a | -> NI |
|Pruned | |state state | | |state | |Pruned || | state | state | | | state |
|(P) | | restart | | | | |(P) || | | restart | | | |
| | | Expiry | | | | | || | | Expiry | | | |
| | | Timer | | | | | || | | Timer | | | |
+-------+----------------+----------+---------+--------+-------+--------+ +--------++----------------+-----------+-----------+---------+---------+---------+
|Prune |-> PP' state |-> NI + |- |-> P |n/a | |Prune ||-> PP' state | -> NI | - | - | -> P | n/a |
|Pending| |state | | |state | | |Pending || | state | | | state | |
|(PP) | | | | | | | |(PP) || | | | | | |
+-------+----------------+----------+---------+--------+-------+--------+ +--------++----------------+-----------+-----------+---------+---------+---------+
| |error |error +> P |-> NI |n/a |n/a | | ||error | error | -> P | -> NI | n/a | n/a |
|Temp. | | state |state | | | |Temp. || | | state | state | | |
|Pruned | | restart | | | | |Pruned || | | restart | | | |
|(P') | | Expiry | | | | |(P') || | | Expiry | | | |
| | | Timer | | | | | || | | Timer | | | |
+-------+----------------+----------+---------+--------+-------+--------+ +--------++----------------+-----------+-----------+---------+---------+---------+
|Temp. |error |error +> PP |-> NI |n/a |n/a | |Temp. ||error | error | -> PP | -> NI | n/a | n/a |
|Prune | | state |state | | | |Prune || | | state | state | | |
|Pending| | restart | | | | |Pending || | | restart | | | |
|(PP') | | Expiry | | | | |(PP') || | | Expiry | | | |
| | | Timer | | | | | || | | Timer | | | |
+-------+----------------+----------+---------+--------+-------+--------+ +--------++----------------+-----------+-----------+---------+---------+---------+
The transition events "Receive Join(S,G,rpt)", "Receive Prune(S,G,rpt)", The transition events "Receive Join(S,G,rpt)", "Receive Prune(S,G,rpt)",
"Receive Join(*,G)" and "Receive Join(*,*,RP(G))" imply receiving a Join "Receive Join(*,G)" and "Receive Join(*,*,RP(G))" imply receiving a Join
or Prune targeted to this router's address on the received interface. or Prune targeted to this router's address on the received interface.
If the destination address is not correct, these state transitions in If the destination address is not correct, these state transitions in
this state machine must not occur, although seeing such a packet may this state machine must not occur, although seeing such a packet may
cause state transitions in other state machines. 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 packet should be the same as the source address it chose for the hello packet
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 0.0.0.0 destination address are also recommend that PIM messages with a 0.0.0.0 destination address are also
accepted. accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo (NI) state, the following event may trigger a transition: When in NoInfo (NI) state, the following event may trigger a transition:
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
A Prune(S,G,rpt) is received on interface I with its IP A Prune(S,G,rpt) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the PrunePending state. The Expiry Timer (ET) transitions to the PrunePending state. The Expiry Timer (ET)
is started, and set to the HoldTime from the triggering | is started, and set to the HoldTime from the triggering
Join/Prune message. The PrunePending timer is started; it is | Join/Prune message. The PrunePending timer is started; it is
set to the J/P_Override_Interval if the router has more than set to the J/P_Override_Interval if the router has more than
one neighbor on that interface; otherwise it is set to zero one neighbor on that interface; otherwise it is set to zero
causing it to expire immediately. causing it to expire immediately.
Transitions from PrunePending State Transitions from PrunePending State
When in PrunePending (PP) state, the following events may trigger a When in PrunePending (PP) state, the following events may trigger a
transition: transition:
Receive Join(*,G) or Join(*,*,RP(G)) Receive Join(*,G) or Join(*,*,RP(G))
A Join(*,*,RP(G)) or Join(*,G) is received on interface I with A Join(*,*,RP(G)) or Join(*,G) is received on interface I with |
its IP destination set to the router's address on I. its Upstream Neighbor Address set to the router's address on |
I. |
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to Temp. PrunePending state whilst the remainder transitions to Temp. PrunePending state whilst the remainder
of the compound Join/Prune message containing the of the compound Join/Prune message containing the
Join(*,*,RP(G)) or Join(*,G) is processed. Join(*,*,RP(G)) or Join(*,G) is processed.
Receive Join(S,G,rpt) Receive Join(S,G,rpt)
A Join(S,G,rpt) is received on interface I with its IP A Join(S,G,rpt) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to NoInfo state. ET and PPT are canceled. transitions to NoInfo state. ET and PPT are canceled.
PrunePending Timer Expires PrunePending Timer Expires
The PrunePending Timer for the (S,G,rpt) downstream state The PrunePending Timer for the (S,G,rpt) downstream state
machine on interface I expires. machine on interface I expires.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the Pruned state. transitions to the Pruned state.
Transitions from Pruned State Transitions from Pruned State
When in Pruned (P) state, the following events may trigger a transition: When in Pruned (P) state, the following events may trigger a transition:
Receive Join(*,G) or Join(*,*,RP(G)) Receive Join(*,G) or Join(*,*,RP(G))
A Join(*,*,RP(G)) or Join(*,G) is received on interface I with A Join(*,*,RP(G)) or Join(*,G) is received on interface I with |
its IP destination set to the router's address on I. its Upstream Neighbor Address set to the router's address on |
I. |
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to Temp. Pruned state whilst the remainder of the transitions to Temp. Pruned state whilst the remainder of the
compound Join/Prune message containing the Join(*,*,RP(G)) or compound Join/Prune message containing the Join(*,*,RP(G)) or
Join(*,G) is processed. Join(*,G) is processed.
Receive Join(S,G,rpt) Receive Join(S,G,rpt)
A Join(S,G,rpt) is received on interface I with its IP A Join(S,G,rpt) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to NoInfo state. ET and PPT are canceled. transitions to NoInfo state. ET and PPT are canceled.
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
A Prune(S,G,rpt) is received on interface I with its IP A Prune(S,G,rpt) is received on interface I with its Upstream |
destination set to the router's address on I. Neighbor Address set to the router's address on I. |
The (S,G,rpt) downstream state machine on interface I remains The (S,G,rpt) downstream state machine on interface I remains
in Pruned state. The Expiry Timer (ET) is restarted, set to | in Pruned state. The Expiry Timer (ET) is restarted, set to
maximum of its current value and the HoldTime from the | maximum of its current value and the HoldTime from the
triggering Join/Prune message. | triggering Join/Prune message.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (S,G,rpt) downstream state machine on The Expiry Timer for the (S,G,rpt) downstream state machine on
interface I expires. interface I expires.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the NoInfo state. ET and PPT are canceled. transitions to the NoInfo state. ET and PPT are canceled.
Transitions from Temp. PrunePending State Transitions from Temp. PrunePending State
When in Temp. PrunePending (PP') state and processing a compound When in Temp. PrunePending (PP') state and processing a compound
Join/Prune message, the following events may trigger a transition: Join/Prune message, the following events may trigger a transition:
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
The compound Join/Prune message contains a Prune(S,G,rpt). The compound Join/Prune message contains a Prune(S,G,rpt).
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions back to the PrunePending state. The Expiry Timer | transitions back to the PrunePending state. The Expiry Timer
(ET) is restarted, set to maximum of its current value and the | (ET) is restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message. | HoldTime from the triggering Join/Prune message.
End of Message End of Message
The end of the compound Join/Prune message is reached. The end of the compound Join/Prune message is reached.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the NoInfo state. ET and PPT are canceled. transitions to the NoInfo state. ET and PPT are canceled.
Transitions from Temp. Pruned State Transitions from Temp. Pruned State
When in Temp. Pruned (P') state and processing a compound Join/Prune When in Temp. Pruned (P') state and processing a compound Join/Prune
message, the following events may trigger a transition: message, the following events may trigger a transition:
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
The compound Join/Prune message contains a Prune(S,G,rpt). The compound Join/Prune message contains a Prune(S,G,rpt).
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions back to the Pruned state. The Expiry Timer (ET) | transitions back to the Pruned state. The Expiry Timer (ET)
is restarted, set to maximum of its current value and the | is restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message. | HoldTime from the triggering Join/Prune message.
End of Message End of Message
The end of the compound Join/Prune message is reached. The end of the compound Join/Prune message is reached.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the NoInfo state. ET and PPT are canceled. transitions to the NoInfo state. ET and PPT are canceled.
Notes: Notes:
Receiving a Prune(*,*,RP(G)) or Prune(*,G) does not affect the (S,G,rpt) Receiving a Prune(*,*,RP(G)) or Prune(*,G) does not affect the (S,G,rpt)
skipping to change at page 50, line 39 skipping to change at page 52, line 39
| | Join(*,*,RP) | Prune(*,*,RP) | | | Join(*,*,RP) | Prune(*,*,RP) |
| | to | to | | | to | to |
| | MRIB.next_hop(RP) | MRIB.next_hop(RP) | | | MRIB.next_hop(RP) | MRIB.next_hop(RP) |
+-----------------+---------------------+-------------------------------+ +-----------------+---------------------+-------------------------------+
| Send | Increase Timer to | Decrease Timer to | | Send | Increase Timer to | Decrease Timer to |
| Join(*,*,RP); | t_suppressed | t_override | | Join(*,*,RP); | t_suppressed | t_override |
| Set Timer to | | | | Set Timer to | | |
| t_periodic | | | | t_periodic | | |
+-----------------+---------------------+-------------------------------+ +-----------------+---------------------+-------------------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+|
| In Joined (J) State | | In Joined (J) State ||
+-----------------------------------+-----------------------------------+ +-----------------------------------+-----------------------------------+|
| topology change wrt | MRIB.next_hop(RP) GenID | | MRIB.next_hop(RP) | | MRIB.next_hop(RP) GenID | ||
| MRIB.next_hop(RP) | changes | | changes | | changes | ||
+-----------------------------------+-----------------------------------+ +-----------------------------------+-----------------------------------+|
| Send Join(*,*,RP) to new | Decrease Timer to | | Send Join(*,*,RP) to new | | Decrease Timer to | ||
| next hop; Send | t_override | | next hop; Send | | t_override | ||
| Prune(*,*,RP) to old | | | Prune(*,*,RP) to old next | | ||
| next hop; set Timer to | | | hop; set Timer to | | ||
| t_periodic | | | t_periodic | | ||
+-----------------------------------+-----------------------------------+ +-----------------------------------+-----------------------------------+|
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(*,*,RP) { bool JoinDesired(*,*,RP) {
if immediate_olist(*,*,RP) != NULL if immediate_olist(*,*,RP) != NULL
return TRUE return TRUE
else else
return FALSE return FALSE
} }
skipping to change at page 52, line 31 skipping to change at page 54, line 31
This event is only relevant if RPF_interface(RP) is a shared This event is only relevant if RPF_interface(RP) is a shared
medium. This router sees another router on RPF_interface(RP) medium. This router sees another router on RPF_interface(RP)
send a Prune(*,*,RP) to MRIB.next_hop(RP). As this router is send a Prune(*,*,RP) to MRIB.next_hop(RP). As this router is
in Joined state, it must override the Prune after a short in Joined state, it must override the Prune after a short
random interval. random interval.
The upstream (*,*,RP) state machine remains in Joined state. The upstream (*,*,RP) state machine remains in Joined state.
If the Join Timer is set to expire in more than t_override If the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. seconds, reset it so that it expires after t_override seconds.
If the Join Timer is set to expire in less than t_override If the Join Timer is set to expire in less than t_override
seconds, leave it unchanged. seconds, leave it unchanged. |
Topology Change wrt MRIB.next_hop(RP) MRIB.next_hop(RP) changes |
A route changed in the routing base stored in the MRIB so that A change in the MRIB routing base causes the next hop towards |
the next hop towards the RP is a different neighbor from the RP to change. |
before.
The upstream (*,*,RP) state machine remains in Joined state. The upstream (*,*,RP) state machine remains in Joined state.
Send Prune(*,*,RP) to the old upstream neighbor, which is the Send Prune(*,*,RP) to the old upstream neighbor, which is the
old value of MRIB.next_hop(RP). Send Join(*,*,RP) to the new old value of MRIB.next_hop(RP). Send Join(*,*,RP) to the new
upstream neighbor which is the new value of MRIB.next_hop(RP). upstream neighbor which is the new value of MRIB.next_hop(RP).
Set the Join Timer (JT) to expire after t_periodic seconds. Set the Join Timer (JT) to expire after t_periodic seconds.
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
skipping to change at page 54, line 23 skipping to change at page 56, line 23
| | -> J state | - | | | -> J state | - |
| NotJoined (NJ) | Send Join(*,G); | | | NotJoined (NJ) | Send Join(*,G); | |
| | Set Timer to | | | | Set Timer to | |
| | t_periodic | | | | t_periodic | |
+---------------------+-------------------------+-----------------------+ +---------------------+-------------------------+-----------------------+
| Joined (J) | - | -> NJ state | | Joined (J) | - | -> NJ state |
| | | Send Prune(*,G) | | | | Send Prune(*,G) |
+---------------------+-------------------------+-----------------------+ +---------------------+-------------------------+-----------------------+
In addition, we have the following transitions which occur within the In addition, we have the following transitions which occur within the
Joined state: Joined state: |
+-----------------------------------------------------------------------+ +------------------------------------------------------------------------|--------------------|
| In Joined (J) State | | In Joined (J) State | |
+-----------------+-----------------+-----------------+-----------------+ +-----------------+------------------+------------------+----------------|-|------------------|
|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) | |Timer | | See | | See | | RPF'(*,G) | | | RPF'(*,G) || |
| | to RPF'(*,G) | to RPF'(*,G) | changes | |Expires | | Join(*,G) to | | Prune(*,G) | | changes | | | changes due || |
+-----------------+-----------------+-----------------+-----------------+ | | RPF'(*,G) | | to RPF'(*,G) | | | | to Assert || |
|Send | Increase Timer | Decrease Timer | Decrease Timer | +-----------------+------------------+------------------+------------------+------------------|
|Join(*,G); Set | to | to t_override | to t_override | |Send | | Increase Timer | | Decrease Timer | | Decrease Timer ||| Send |||
|Timer to | t_suppressed | | | |Join(*,G); Set | | to | | to t_override | | to t_override ||| Join(*,G); Set |||
|t_periodic | | | | |Timer to | | t_suppressed | | | | | Timer to |||
+-----------------+-----------------+-----------------+-----------------+ |t_periodic | | | | | | t_periodic |||
+-----------------+------------------+------------------+------------------+------------------|
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+|
| In Joined (J) State | | In Joined (J) State ||
+----------------------------------+------------------------------------+ +-----------------------------------+-----------------------------------+|
| topology change wrt | RPF'(*,G) GenID changes | | MRIB.next_hop(RP(G)) | | RPF'(*,G) GenID changes | ||
| MRIB.next_hop(RP) | | | changes | | ||
+----------------------------------+------------------------------------+ +-----------------------------------+-----------------------------------+|
| Send Join(*,G) to new | Decrease Timer to | | Send Join(*,G) to new next | | Decrease Timer to | ||
| next hop; Send | t_override | | hop; Send Prune(*,G) to | | t_override | ||
| Prune(*,G) to old next | | | old next hop; set Timer to | | ||
| hop; set Timer to | | | t_periodic | | ||
| t_periodic | | +-----------------------------------+-----------------------------------+|
+----------------------------------+------------------------------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(*,G) { bool JoinDesired(*,G) {
if immediate_olist(*,G) != NULL if (immediate_olist(*,G) != NULL || |
return TRUE (JoinDesired(*,*,RP(G)) && |
else AssertWinner(*,G,RPF_interface(RP(G))) != NULL)) |
return FALSE return TRUE |
} else |
return FALSE |
} |
JoinDesired(*,G) is true when the router has forwarding state that would JoinDesired(*,G) is true when the router has forwarding state that would
cause it to forward traffic for G using shared tree state. Note that cause it to forward traffic for G using shared tree state. Note that
although JoinDesired is true, the router's sending of a Join(*,G) although JoinDesired is true, the router's sending of a Join(*,G)
message may be suppressed by another router sending a Join(*,G) onto the message may be suppressed by another router sending a Join(*,G) onto the
upstream interface. upstream interface.
Transitions from NotJoined State Transitions from NotJoined State
When the upstream (*,G) state-machine is in NotJoined state, the When the upstream (*,G) state-machine is in NotJoined state, the
skipping to change at page 56, line 34 skipping to change at page 58, line 34
router is in Joined state, it must override the Prune after a router is in Joined state, it must override the Prune after a
short random interval. short random interval.
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.
If the Join Timer is set to expire in less than t_override If the Join Timer is set to expire in less than t_override
seconds, leave it unchanged. seconds, leave it unchanged.
RPF'(*,G) changes RPF'(*,G) changes
The current net hop towards the RP changes due an Assert(*,G) The current next hop towards the RP changes due an Assert(*,G) |
on the RPF_interface(RP(G)). on the RPF_interface(RP(G)). |
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.
If the Join Timer is set to expire in less than t_override If the Join Timer is set to expire in less than t_override
seconds, leave it unchanged. seconds, leave it unchanged. |
Topology Change wrt MRIB.next_hop(RP)
A route changed in the routing base stored in the MRIB so that
the next hop towards the RP is a different neighbor from
before.
The upstream (*,G) state machine remains in Joined state. MRIB.next_hop(RP(G)) changes |
Send Prune(*,G) to the old upstream neighbor, which is the old An event occurred which caused the next hop towards the RP for |
value of RPF'(*,G). Send Join(*,G) to the new upstream G to change. This may be caused by a change in the MRIB |
neighbor which is the new value of RPF(*,G). Note that the routing database or by the installation of a different RP-to- |
Join goes to RPF(*,G) and not RPF'(*,G) even if the new group mapping. Note that this transition should occur even if |
neighbor is on the same interface as the old one because the RPF'(*,G) is not equal to the new next hop towards RP(G), |
routing change may cause the assert state to be incorrect. Set because it may be that the new neighbor is a better path to |
the Join Timer (JT) to expire after t_periodic seconds. RP(G) than RPF'(*,G); this transition ensures that the better |
path is discovered even if an assert occurred previously. |
The upstream (*,G) state machine remains in Joined state. |
Send Prune(*,G) to the old upstream neighbor, which is the old |
value of RPF'(*,G). Send Join(*,G) to the new upstream |
neighbor which is the new value of MRIB.next_hop(RP(G)). Note |
that the Join goes to MRIB.next_hop(RP(G)) and not RPF'(*,G) |
even if the new neighbor is on the same interface as the old
one because the routing change may cause the assert state to
be incorrect. Set the Join Timer (JT) to expire after
t_periodic seconds.
RPF'(*,G) GenID changes RPF'(*,G) GenID changes
The Generation ID of the router that is RPF'(*,G) changes. The Generation ID of the router that is RPF'(*,G) changes.
This normally means that this neighbor has lost state, and so This normally means that this neighbor has lost state, and so
the state must be refreshed. the state must be refreshed.
The upstream (*,G) state machine remains in Joined state. If The upstream (*,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. seconds, reset it so that it expires after t_override seconds.
skipping to change at page 59, line 21 skipping to change at page 61, line 21
|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 Timer | Decrease Timer | Decrease Timer | |Send | Increase Timer | Decrease Timer | Decrease Timer |
|Join(S,G); Set | to t_suppr | to t_override | to t_override | |Join(S,G); Set | to t_suppr | to t_override | to t_override |
|Timer to | | | | |Timer to | | | |
|t_periodic | | | | |t_periodic | | | |
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
+-----------------------------------------------------------------------+ +------------------------------------------------------------------------||
| In Joined (J) State | | In Joined (J) State ||
+----------------------+-------------------------+----------------------+ +-----------------------+------------------------+-----------------------||
| See Prune(*,G) to | topology change | RPF'(S,G) GenID | |See Prune(*,G) to | | MRIB.next_hop(S) | | RPF'(S,G) GenID | ||
| RPF'(S,G) | wrt | changes | |RPF'(S,G) | | changes | | changes | ||
| | MRIB.next_hop(S) | | +-----------------------+------------------------+------------------------|
+----------------------+-------------------------+----------------------+ |Decrease Timer to | | Send Join(S,G) to | | Decrease Timer to |||
| Decrease Timer to | Send Join(S,G) to | Decrease Timer to | |t_override | | new next hop; Send | | t_override |||
| t_override | new next hop; Send | t_override | | | Prune(S,G) to old | | ||
| | Prune(S,G) to old | | | | next hop; Set Timer | | ||
| | next hop; Set | | | | to t_periodic | | ||
| | Timer 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 61, line 42 skipping to change at page 63, line 42
send a Prune(*,G) to RPF'(S,G). If the upstream router is an send a Prune(*,G) to RPF'(S,G). If the upstream router is an
RFC 2362 compliant PIM router, then the Prune(*,G) will cause RFC 2362 compliant PIM router, then the Prune(*,G) will cause
it to stop forwarding. For backwards compatibility, this it to stop forwarding. For backwards compatibility, this
router should override the prune so that forwarding continues. router should override the prune so that forwarding continues.
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.
RPF'(S,G) changes RPF'(S,G) changes
The current net hop towards the RP changes due an Assert(S,G) The current next hop towards the RP changes due an Assert(S,G) |
on the RPF_interface(S). on the RPF_interface(S). |
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.
If the Join Timer is set to expire in less than t_override If the Join Timer is set to expire in less than t_override
seconds, leave it unchanged. seconds, leave it unchanged. |
Topology Change wrt MRIB.next_hop(S) MRIB.next_hop(S) changes |
A route changed in the routing base stored in the MRIB so that A change in the routing base stored in the MRIB causes the |
the next hop towards S is a different neighbor from before. next hop towards S to change. |
The upstream (S,G) state machine remains in Joined state. The upstream (S,G) state machine remains in Joined state.
Send Prune(S,G) to the old upstream neighbor, which is the old Send Prune(S,G) to the old upstream neighbor, which is the old
value of RPF'(S,G). Send Join(S,G) to the new upstream value of RPF'(S,G). Send Join(S,G) to the new upstream
neighbor which is the new value of RPF(S,G). Note that the neighbor which is the new value of MRIB.next_hop(S). Note |
Join goes to RPF(S,G) and not RPF'(S,G) even if the new that the Join goes to MRIB.next_hop(S) and not RPF'(S,G) even |
neighbor is on the same interface as the old one because the if the new neighbor is on the same interface as the old one |
routing change may cause the assert state to be incorrect. Set because the routing change may cause MRIB.next_hop(S) to have |
the Join Timer (JT) to expire after t_periodic seconds. a better path to S than RPF'(S,G); sending to MRIB.next_hop(S) |
ensures that this is discovered. Set the Join Timer (JT) to |
expire after t_periodic seconds. |
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.
skipping to change at page 64, line 5 skipping to change at page 66, line 11
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.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 9: Upstream (S,G,rpt) state-machine for triggered messages Figure 9: Upstream (S,G,rpt) state-machine for triggered messages
In tabular form, the state machine is: In tabular form, the state machine is: |
+----------------------++-------------------------------------------------------|------------------------|
| || Event ||
| ++------------------+-------------------+----------------|-----|------------------|
|Prev State | ||PruneDesired | | PruneDesired | | RPTJoinDesired(G)|| | inherited_olist|||
| ||(S,G,rpt) | | (S,G,rpt) | | ->False || | (S,G,rpt) || |
| ||->True | | ->False | | | | ->non-NULL || |
+----------------------++------------------+-------------------+----------------------+------------------|
|RPTNotJoined | ||-> P state | - | - | | -> NP state| |
|(G) (NJ) | || | | | | |
+----------------------++------------------+-------------------+----------------------+------------------|
|Pruned (S,G,rpt) | ||- | -> NP state | -> NJ state | | -| |
|(P) | || | Send Join | | | | |
| || | (S,G,rpt) | | | | |
+----------------------++------------------+-------------------+----------------------+------------------|
| ||-> P state | - | -> NJ state | -| |
|NotPruned (S,G,rpt) | ||Send Prune | | | Cancel OT timer| ||| |
|(NP) | ||(S,G,rpt); | | | | | |
| ||Cancel OT timer | | | | | |
+----------------------++------------------+-------------------+----------------------+------------------|
+-------------++---------------------------------------------------------------+
| || Event |
| ++-------------+-------------+------------------+----------------+
|Prev State |PruneDesired |PruneDesired |RPTJoinDesired(G) |inherited_olist |
| |(S,G,rpt) |(S,G,rpt) |->False |(S,G,rpt) |
| |->True |->False | |->non-NULL |
+-------------++-------------+-------------+------------------+----------------+
|RPTNotJoined |+> P state |- |- |-> NP state |
|(G) (NJ) || | | | |
+-------------++-------------+-------------+------------------+----------------+
|Pruned |+ |-> NP state |-> NJ state |- |
|(S,G,rpt) (P)|| |Send Join | | |
| || |(S,G,rpt) | | |
+-------------++-------------+-------------+------------------+----------------+
|NotPruned |+> P state |- |-> NJ state |- |
|(S,G,rpt) |Send Prune | | | |
|(NP) |(S,G,rpt); | | | |
| |Stop OT timer | | | |
+-------------++-------------+-------------+------------------+----------------+
Additionally, we have the following transitions within the Additionally, we have the following transitions within the
NotPruned(S,G,rpt) state which are all used for prune override behavior. NotPruned(S,G,rpt) state which are all used for prune override behavior. |
+-----------------------------------------------------------------------+ +------------------------------------------------------------------------|--------------------|
| In NotPruned(S,G,rpt) State | | In NotPruned(S,G,rpt) State ||
+------------+--------------+---------------+------------+--------------+ +-----------------+------------------+------------------+----------------|-|------------------|
|OT timer |See Prune | See Join |See Prune | RPF' | |OT timer | | See Prune | | See Join | | See Prune | | | RPF' || |
|expires |(S,G,rpt) to | (S,G,rpt) to |(S,G) to | (S,G,rpt) -> | |expires | | (S,G,rpt) to | | (S,G,rpt) to | | (S,G) to | | | (S,G,rpt) -> || |
| |RPF' | RPF' |RPF' | RPF' (*,G) | | | RPF' | | RPF' | | RPF' | | | RPF' (*,G) || |
| |(S,G,rpt) | (S,G,rpt) |(S,G,rpt) | | | | (S,G,rpt) | | (S,G,rpt) | | (S,G,rpt) | | | |
+------------+--------------+---------------+------------+--------------+ +-----------------+------------------+------------------+------------------+------------------|
|Send Join |OT timer = | stop OT |OT timer = | OT timer = | |Send Join | | OT timer = | | Cancel OT | | OT timer = ||| OT timer = |||
|(S,G,rpt); |min(timer, | timer |min(timer, | min(timer, | |(S,G,rpt); | | min(timer, | | timer | | min(timer, ||| min(timer, |||
|Stop OT |t_po) | |t_po) | t_po) | |Cancel OT | | t_po) | | | t_po) ||| t_po) |||
|timer | | | | | |timer | | | | | | |
+------------+--------------+---------------+------------+--------------+ +-----------------+------------------+------------------+------------------+------------------|
Note that the min function in the above state machine considers a non- Note that the min function in the above state machine considers a non-
running timer to have an infinite value (e.g. min(not-running, t_po) = running timer to have an infinite value (e.g. min(not-running, t_po) =
t_po). t_po).
This state machine uses the following macros: This state machine uses the following macros:
bool RPTJoinDesired(G) { bool RPTJoinDesired(G) {
return (JoinDesired(*,G) || JoinDesired(*,*,RP(G))) return (JoinDesired(*,G) || JoinDesired(*,*,RP(G)))
} }
skipping to change at page 70, line 26 skipping to change at page 72, line 26
Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in the Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in the
state-machine table to refer to AssertTrackingDesired(S,G,I). state-machine table to refer to AssertTrackingDesired(S,G,I).
Terminology: Terminology:
A "preferred assert" is one with a better metric than the current A "preferred assert" is one with a better metric than the current
winner. winner.
An "inferior assert" is one with a worse metric than An "inferior assert" is one with a worse metric than
my_assert_metric(S,G,I). my_assert_metric(S,G,I).
The state machine uses the following macros: The state machine uses the following macros:
CouldAssert(S,G,I) = CouldAssert(S,G,I) =
SPTbit(S,G)==TRUE SPTbit(S,G)==TRUE
AND (RPF_interface(S) != I) AND (RPF_interface(S) != I) |
AND (I in ( ( joins(*,G) (-) prunes(S,G,rpt) ) AND (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) |
(+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) ) |
(-) lost_assert(*,G) (-) lost_assert(*,G) |
(+) joins(S,G) (+) pim_include(S,G) ) ) (+) joins(S,G) (+) pim_include(S,G) ) ) |
CouldAssert(S,G,I) is true for downstream interfaces which would be in CouldAssert(S,G,I) is true for downstream interfaces which would be in |
the inherited_olist(S,G) if (S,G) assert information was not taken into the inherited_olist(S,G) if (S,G) assert information was not taken into |
account. account. |
AssertTrackingDesired(S,G,I) = AssertTrackingDesired(S,G,I) = |
(I in ( ( joins(*,G) (-) prunes(S,G,rpt) ) (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) |
(+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) ) |
(-) lost_assert(*,G) (-) lost_assert(*,G) |
(+) joins(S,G) (+) pim_include(S,G) ) ) (+) joins(S,G) (+) pim_include(S,G) ) ) |
OR (RPF_interface(S)==I AND JoinDesired(S,G)==TRUE) OR (RPF_interface(S)==I AND JoinDesired(S,G)==TRUE) |
OR (RPF_interface(RP)==I AND JoinDesired(*,G)==TRUE OR (RPF_interface(RP)==I AND JoinDesired(*,G)==TRUE |
AND SPTbit(S,G)==FALSE) AND SPTbit(S,G)==FALSE) |
AssertTrackingDesired(S,G,I) is true on any interface in which an (S,G) AssertTrackingDesired(S,G,I) is true on any interface in which an (S,G) |
assert might affect our behavior. assert might affect our behavior. |
The first three lines of AssertTrackingDesired account for (*,G) join The first three lines of AssertTrackingDesired account for (*,G) join
information received on I that might cause the router to be interested information received on I that might cause the router to be interested
in asserts on I. in asserts on I.
The 4th line accounts for (S,G) join information received on I that The 4th line accounts for (S,G) join information received on I that
might cause the router to be interested in asserts on I. might cause the router to be interested in asserts on I.
The last three lines account for the fact that a router must keep track The last three lines account for the fact that a router must keep track
of assert information on upstream interfaces in order to send joins and of assert information on upstream interfaces in order to send joins and
skipping to change at page 73, line 22 skipping to change at page 75, line 34
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.
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
current assert winner. This might happen the underlying | current assert winner. This might happen the underlying
routing metric changes, or when when CouldAssert(S,G,I) | routing metric changes, or when when CouldAssert(S,G,I)
becomes true; for example, when SPTbit(S,G) becomes true. We | becomes true; for example, when SPTbit(S,G) becomes true. We
transition to NoInfo state, delete this (S,G) assert state, | transition to NoInfo state, delete this (S,G) assert state,
and allow the normal PIM Join/Prune mechanisms to operate. | and allow the normal PIM Join/Prune mechanisms to operate.
Usually we will eventually re-assert and win when data packets | Usually we will eventually re-assert and win when data packets
from S have started flowing again. | from S have started flowing again.
RPF interface changed away from interface I RPF interface changed away from interface I
Interface I used to be the RPF interface for S, and now it is Interface I used to be the RPF interface for S, and now it is
not. We transition to NoInfo state, delete this (S,G) assert not. We transition to NoInfo state, delete this (S,G) assert
state. state.
Receive Join(S,G) Receive Join(S,G)
We receive a Join(S,G) directed to my IP address in interface We receive a Join(S,G) directed to my IP address in interface
I. The action is to transition to NoInfo state, and delete I. The action is to transition to NoInfo state, and delete
this (S,G) assert state, and allow the normal PIM Join/Prune this (S,G) assert state, and allow the normal PIM Join/Prune
mechanisms to operate. If whoever sent the Join was in error, mechanisms to operate. If whoever sent the Join was in error,
then the normal assert mechanism will eventually re-apply and then the normal assert mechanism will eventually re-apply and
we will lose the assert again. However whoever sent the we will lose the assert again. However whoever sent the
assert may know that the previous assert winner has died, and assert may know that the previous assert winner has died, and
so we may end up being the new forwarder. so we may end up being the new forwarder.
(S,G) Assert State-machine Actions (S,G) Assert State-machine Actions
A1: Send Assert(S,G) A1: Send Assert(S,G)
Set timer to (Assert_Time - Assert_Override_Interval) Set timer to (Assert_Time - Assert_Override_Interval)
Store self as AssertWinner Store self as AssertWinner(S,G,I)
A2: Store new assert winner Store spt_assert_metric(S,I) as AssertWinnerMetric(S,G,I)
A2: Store new assert winner as AssertWinner(S,G,I) and assert |
winner metric as AssertWinnerMetric(S,G,I). |
Set timer to Assert_Time Set timer to Assert_Time
A3: Send Assert(S,G) A3: Send Assert(S,G)
Set timer to (Assert_Time - Assert_Override_Interval) Set timer to (Assert_Time - Assert_Override_Interval)
A4: Send AssertCancel(S,G) A4: Send AssertCancel(S,G)
Delete assert info Delete assert info (AssertWinner(S,G,I) and |
AssertWinnerMetric(S,G,I) assume default values). |
A5: Delete assert info A5: Delete assert info (AssertWinner(S,G,I) and |
AssertWinnerMetric(S,G,I) assume default values). |
A6: Store new assert winner A6: Store new assert winner as AssertWinner(S,G,I) and assert |
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.
4.5.2. (*,G) Assert Message State Machine 4.5.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.
skipping to change at page 76, line 5 skipping to change at page 78, line 5
It is important to note that no transition occurs in the (*,G) state It is important to note that no transition occurs in the (*,G) state
machine as a result of receiving an assert message if the (S,G) assert machine as a result of receiving an assert message if the (S,G) assert
state machine for the relevant S and G is not in the "NoInfo" state. state machine for the relevant S and G is not in the "NoInfo" state.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 11: (*,G) Assert State-machine Figure 11: (*,G) Assert State-machine
In tabular form the state machine is: In tabular form the state machine is: |
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+|
| 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 | (*,G,I) | set and AssTrDes | |set and | | (*,G,I) | | set and AssTrDes | ||
| | | (*,G,I) | |CouldAssert(*,G,I) | | | (*,G,I) | ||
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+|
| -> Winner state | -> Winner state | -> Loser state | |-> Winner state | -> Winner state | -> Loser state ||
| [Actions A1] | [Actions A1] | [Actions A2] | |[Actions A1] | [Actions A1] | [Actions A2] ||
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+|
+-----------------------------------------------------------------------+ +------------------------------------------------------------------------|-|
| In I Am Assert Winner (W) State | | In I Am Assert Winner (W) State ||
+-----------------+-----------------+------------------+----------------+ +-----------------+------------------+------------------+----------------|-|
| 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 | Timer Expires | AssTrDes | |Receive | | Receive | | Timer Expires | | AssTrDes |||
| Preferred | Inferior | | (*,G,I) -> | |Preferred | | Inferior | | | (*,G,I) -> |||
| Assert | Assert from | | FALSE | |Assert | | Assert from | | | FALSE |||
| | Current Winner | | | | | Current Winner | | | | |
+---------------+-------------------+-----------------+-----------------+ +-----------------+------------------+------------------+------------------|
| -> L state | -> NI state | -> NI state | -> NI state | |-> L state | -> NI state | -> NI state | -> NI state | |
| [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] | |[Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] | |
+---------------+-------------------+-----------------+-----------------+ +-----------------+------------------+------------------+------------------|
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+|
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State ||
+----------------------+----------------------+-------------------------+ +-----------------------+-----------------------+-----------------------+|
| my_metric -> | RPF interface | Receive Join(*,G) | |my_metric -> | | RPF interface | | Receive Join(*,G) | ||
| better than | stops being I | or Join(*,*,RP(G)) | |better than | | stops being I | | or Join(*,*,RP(G)) | ||
| Winner's metric | | on Interface I | |Winner's metric | | | on Interface I | ||
+----------------------+----------------------+-------------------------+ +-----------------------+-----------------------+-----------------------+|
| -> NI state | -> NI state | -> NI State | |-> NI state | -> NI state | -> NI State ||
| [Actions A5] | [Actions A5] | [Actions A5] | |[Actions A5] | [Actions A5] | [Actions A5] ||
+----------------------+----------------------+-------------------------+ +-----------------------+-----------------------+-----------------------+|
The state machine uses the following macros: The state machine uses the following macros:
CouldAssert(*,G,I) = CouldAssert(*,G,I) = |
( I in ( joins(*,G) (+) joins(*,*,RP(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 |
(*,G) or (*,*,RP(G) join state, or local members that requested any (*,*,RP(G)) or (*,G) join state, or local members that requested any |
traffic destined for G. traffic destined for G. |
AssertTrackingDesired(*,G,I) = AssertTrackingDesired(*,G,I) = |
CouldAssert(*,G) OR CouldAssert(*,G) OR |
( RPF_interface(RP(G)) == I AND RPTJoinDesired(G) ) ( RPF_interface(RP(G)) == I AND RPTJoinDesired(G) ) |
AssertTrackingDesired(*,G,I) is true on any interface on which an (*,G) AssertTrackingDesired(*,G,I) is true on any interface on which an (*,G) |
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 "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). |
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 |
interface, and we have (*,G) forwarding state on this interface, and we have (*,G) forwarding state on this |
interface, so we should be the assert winner. We transition interface, so we should be the assert winner. We transition |
to the "I am Assert Winner" state, and perform Actions A1 to the "I am Assert Winner" state, and perform Actions A1 |
(below). (below). |
A data packet destined for G arrives on interface I, AND A data packet destined for G arrives on interface I, AND |
CouldAssert(*,G,I)==TRUE CouldAssert(*,G,I)==TRUE |
A data packet destined for G arrived on a downstream interface A data packet destined for G arrived on a downstream interface |
which is in our (*,G) outgoing interface list. We therefore which is in our (*,G) outgoing interface list. We therefore |
believe we should be the forwarder for this (*,G), and so we believe we should be the forwarder for this (*,G), and so we |
transition to the "I am Assert Winner" state, and perform transition to the "I am Assert Winner" state, and perform |
Actions A1 (below). Actions A1 (below). |
Receive Preferred Assert with RPT bit set AND Receive Preferred Assert with RPT bit set AND |
AssertTrackingDesired(*,G,I)==TRUE AssertTrackingDesired(*,G,I)==TRUE |
We're interested in (*,G) Asserts, either because I is a We're interested in (*,G) Asserts, either because I is a |
downstream interface for which we have (*,G) forwarding state, downstream interface for which we have (*,G) forwarding state, |
or because I is the upstream interface for RP(G) and we have or because I is the upstream interface for RP(G) and we have |
(*,G) forwarding state. We get a (*,G) Assert that has a (*,G) forwarding state. We get a (*,G) Assert that has a |
better metric than our own, so we do not win the Assert. We better metric than our own, so we do not win the Assert. We |
transition to "I am Assert Loser" and perform actions A2 transition to "I am Assert Loser" and perform actions A2 |
(below). (below). |
Transitions from Winner State Transitions from Winner State |
When in "I am Assert Winner" state, the following events trigger When in "I am Assert Winner" state, the following events trigger |
transitions, but only if the (S,G) assert state machine is in NoInfo transitions, but only if the (S,G) assert state machine is in NoInfo |
state: state: |
Receive Inferior Assert Receive Inferior Assert |
We receive a (*,G) assert that has a worse metric than our We receive a (*,G) assert that has a worse metric than our |
own. Whoever sent the assert has lost, and so we re-send a own. Whoever sent the assert has lost, and so we re-send a |
(*,G) Assert, and restart the timer (Action A3 below). (*,G) Assert, and restart the timer (Action A3 below). |
Receive Preferred Assert Receive Preferred Assert |
We receive a (*,G) assert that has a better metric than our We receive a (*,G) assert that has a better metric than our |
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). actions A2 (below). |
When in "I am Assert Winner" state, the following events trigger When in "I am Assert Winner" state, the following events trigger |
transitions: transitions: |
Timer Expires Timer Expires |
The (*,G) assert timer expires. As we're in the Winner state, The (*,G) assert timer expires. As we're in the Winner state, |
then we must still have (*,G) forwarding state that is then we must still have (*,G) forwarding state that is |
actively being kept alive. To prevent unnecessary thrashing actively being kept alive. To prevent unnecessary thrashing |
of the forwarder and periodic flooding of duplicate packets, of the forwarder and periodic flooding of duplicate packets, |
we re-send the (*,G) Assert, and restart the timer (Action A3 we re-send the (*,G) Assert, and restart the timer (Action A3 |
below). below). |
CouldAssert(*,G,I) -> FALSE CouldAssert(*,G,I) -> FALSE |
Our (*,G) forwarding state or RPF interface changed so as to Our (*,G) forwarding state or RPF interface changed so as to |
make CouldAssert(*,G,I) become false. We can no longer make CouldAssert(*,G,I) become false. We can no longer |
perform the actions of the assert winner, and so we transition perform the actions of the assert winner, and so we transition |
to NoInfo state and perform actions A4 (below). to NoInfo state and perform actions A4 (below). |
Transitions from Loser State Transitions from Loser State |
When in "I am Assert Loser" state, the following events trigger When in "I am Assert Loser" state, the following events trigger |
transitions, but only if the (S,G) assert state machine is in NoInfo transitions, but only if the (S,G) assert state machine is in NoInfo |
state: state: |
Receive Preferred Assert Receive Preferred Assert |
We receive a (*,G) assert that is better than that of the We receive a (*,G) assert that is better than that of the |
current assert winner. We stay in Loser state, and perform current assert winner. We stay in Loser state, and perform |
actions A2 below. actions A2 below. |
Receive Inferior Assert from Current Winner Receive Inferior Assert from Current Winner |
We receive an assert from the current assert winner that is We receive an assert from the current assert winner that is |
worse than our own metric for this group (typically because worse than our own metric for this group (typically because |
the winner's metric became worse). We transition to NoInfo the winner's metric became worse). We transition to NoInfo |
state, delete this (*,G) assert state, and allow the normal state, delete this (*,G) assert state, and allow 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 for G have 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. and delete this (*,G) assert info. |
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. delete this (*,G) assert info. |
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 |
NoInfo state, and delete this (*,G) assert state, and allow | NoInfo state, and delete this (*,G) assert state, and allow |
the normal PIM Join/Prune mechanisms to operate. Usually we | the normal PIM Join/Prune mechanisms to operate. Usually we |
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. |
RPF interface changed away from interface I RPF interface changed away from interface I |
Interface I used to be the RPF interface for RP(G), and now it Interface I used to be the RPF interface for RP(G), and now it |
is not. We transition to NoInfo state, and delete this (*,G) is not. We transition to NoInfo state, and delete this (*,G) |
assert state. assert state. |
Receive Join(*,G) or Join(*,*,RP(G)) |
Receive Join(*,G) or Join(*,*,RP(G)) We receive a Join(*,G) or a Join(*,*,RP(G)) directed to my IP |
We receive a Join(*,G) or a Join(*,*,RP(G)) directed to my IP address in interface I. The action is to transition to NoInfo |
address in interface I. The action is to transition to NoInfo state, and delete this (*,G) assert state, and allow the |
state, and delete this (*,G) assert state, and allow the normal PIM Join/Prune mechanisms to operate. If whoever sent |
normal PIM Join/Prune mechanisms to operate. If whoever sent the Join was in error, then the normal assert mechanism will |
the Join was in error, then the normal assert mechanism will eventually re-apply and we will lose the assert again. |
eventually re-apply and we will lose the assert again. However whoever sent the assert may know that the previous |
However whoever sent the assert may know that the previous assert winner has died, and so we may end up being the new |
assert winner has died, and so we may end up being the new forwarder. |
forwarder.
(*,G) Assert State-machine Actions (*,G) Assert State-machine Actions |
A1: Send Assert(*,G) A1: Send Assert(*,G) |
Set timer to (Assert_Time - Assert_Override_Interval) Set timer to (Assert_Time - Assert_Override_Interval) |
Store self as AssertWinner(*,G) Store self as AssertWinner(*,G,I). |
Store rpt_assert_metric as AssertWinnerMetric(*,G,I). |
A2: Store new AssertWinner(*,G) A2: Store new assert winner as AssertWinner(*,G,I) and assert |
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 Delete assert info (AssertWinner(*,G,I) and |
AssertWinnerMetric(*,G,I) assume default values). |
A5: Delete assert info A5: Delete assert info (AssertWinner(*,G,I) and |
AssertWinnerMetric(*,G,I) assume default values). |
4.5.3. Assert Metrics 4.5.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 82, line 33 skipping to change at page 84, line 38
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.5.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 {
return ( AssertWinner(S,G,I) != me ) | return ( AssertWinner(S,G,I) != NULL AND |
AssertWinner(S,G,I) != me ) |
} | } |
} | } |
bool lost_assert(S,G,I) { bool lost_assert(S,G,I) {
if ( RPF_interface(S) == I ) { if ( RPF_interface(S) == I ) {
return FALSE return FALSE
} else { } else {
return ( AssertWinner(S,G,I) != me AND return ( AssertWinner(S,G,I) != NULL AND |
(AssertWinnerMetric(S,G,I) is better AssertWinner(S,G,I) != me AND |
than spt_assert_metric(S,G,I) ) (AssertWinnerMetric(S,G,I) is better |
} than spt_assert_metric(S,G,I) ) |
} } |
} |
bool lost_assert(*,G,I) { bool lost_assert(*,G,I) {
if ( RPF_interface(RP) == I ) { if ( RPF_interface(RP) == I ) {
return FALSE return FALSE
} else { } else {
return ( AssertWinner(*,G,I) != me ) return ( AssertWinner(*,G,I) != NULL AND |
} AssertWinner(*,G,I) != me ) |
} } |
} |
AssertWinner(S,G,I) is the IP source address of the Assert(S,G) packet
that won an Assert.
AssertWinner(S,G,I) is the IP source address of the Assert(*,G) packet
that won an Assert.
AssertWinnerMetric(S,G,I) is the Assert metric of the Assert(S,G) packet
tht won an Assert.
AssertWinnerMetric(*,G,I) is the Assert metric of the Assert(*,G) packet
ht won an Assert.
AssertWinner(S,G,I) defaults to Null and AssertWinnerMetric(S,G,I) AssertWinner(S,G,I) defaults to Null and AssertWinnerMetric(S,G,I)
defaults to Infinity when in the NoInfo state. defaults to Infinity when in the NoInfo state.
Rationale for Assert Rules Rationale for Assert Rules
The following is a summary of the rules for sending and reacting to The following is a summary of the rules for sending and reacting to
asserts. It is not intended to be definitive (the state machines and asserts. It is not intended to be definitive (the state machines and
pseudocode provide the definitive behavior). Instead it provides some pseudocode provide the definitive behavior). Instead it provides some
rationale for the behavior. rationale for the behavior.
skipping to change at page 84, line 33 skipping to change at page 87, line 10
rule does not apply to (S,G,rpt). rule does not apply to (S,G,rpt).
This allow switching back to the shared tree after the last SPT This allow switching back to the shared tree after the last SPT
router on the lan leaves. We don't want RPT downstream routers to router on the lan leaves. We don't want RPT downstream routers to
keep SPT state alive. keep SPT state alive.
9. [Optionally] re-assert before timing out. 9. [Optionally] re-assert before timing out.
This prevents periodic duplicates. This prevents periodic duplicates.
10. When RPF'(S,G,rpt) changes to be the same as RPF'(*,G) we need to 10. When RPF'(S,G,rpt) changes to be the same as RPF'(*,G) we need to |
trigger a Join(S,G,rpt) to RPF(*,G). trigger a Join(S,G,rpt) to MRIB.next_hop(RP(G)). |
This allows switching back to the RPT after the last SPT member This allows switching back to the RPT after the last SPT member
leaves. leaves.
4.6. Designated Routers (DR) and Hello Messages 4.6. Designated Routers (DR) and Hello Messages
4.6.1. Sending Hello Messages 4.6.1. Sending Hello Messages
PIM-Hello messages are sent periodically on each PIM-enabled interface. PIM-Hello messages are sent periodically on each PIM-enabled interface. |
They allow a router to learn about the neighboring PIM routers on each They allow a router to learn about the neighboring PIM routers on each |
interface. Hello messages are also the mechanism used to elect a interface. Hello messages are also the mechanism used to elect a |
Designated Router (DR). A router must record the Hello information Designated Router (DR), and to negotiate additional capabilities A |
received from each PIM neighbor. router must record the Hello information received from each PIM |
neighbor. |
Hello messages are sent periodically on each PIM-enabled interface. Hello messages must be sent on all active interfaces, including physical |
Hello messages are multicast to address 224.0.0.13 (the ALL-PIM-ROUTERS point-to-point links, and are multicast to address 224.0.0.13 (the ALL- |
PIM-ROUTERS group). |
group). Hello messages must be sent on all active interfaces, including A per interface hello timer (HT(I)) is used to trigger sending Hello |
physical point-to-point links. When PIM is enabled on an interface or a messages on each active interface. When PIM is enabled on an interface |
router first starts, the hello timer is set to a random value between 0 or a router first starts, the hello timer of that interface is set to a |
and Triggered_Hello_Delay to prevent synchronization of Hello messages | random value between 0 and Triggered_Hello_Delay. This prevents |
if multiple routers are powered on simultaneously. After the initial | synchronization of Hello messages if multiple routers are powered on |
randomized interval, Hello messages must be sent every Hello_Period simultaneously. After the initial randomized interval, Hello messages |
seconds. A single hello timer is used to trigger sending Hello messages must be sent every Hello_Period seconds. The hello timer should not be |
on all active interfaces. The hello timer should not be reset except reset except when it expires. |
when it expires.
The DR Election Priority Option allows a network administrator to give The DR_Election_Priority Option allows a network administrator to give |
preference to a particular router in the DR election process by giving preference to a particular router in the DR election process by giving
it a numerically larger DR Election Priority. The DR Election Priority it a numerically larger DR Election Priority. The DR_Election_Priority |
Option SHOULD be included in every Hello message, even if no DR election Option SHOULD be included in every Hello message, even if no DR election |
priority is explicitly configured on that interface. This is necessary priority is explicitly configured on that interface. This is necessary
because priority-based DR election is only enabled when all neighbors on because priority-based DR election is only enabled when all neighbors on
an interface advertise that they are capable of using the DR Election an interface advertise that they are capable of using the DR Election
Priority Option. The default priority is 1. Priority Option. The default priority is 1.
The Generation Identifier (GenID) Option SHOULD be included in all Hello The Generation_Identifier (GenID) Option SHOULD be included in all Hello |
messages. The generation ID option contains a randomly generated 32-bit messages. The GenID option contains a randomly generated 32-bit value |
value that is regenerated each time PIM forwarding is started or that is regenerated each time PIM forwarding is started or restarted on
restarted on the interface, including when the router itself restarts. the interface, including when the router itself restarts. When a Hello
When a Hello message with a new GenID is received from a neighbor, any message with a new GenID is received from a neighbor, any old Hello
old Hello information about that neighbor SHOULD be discarded and information about that neighbor SHOULD be discarded and superseded by
superseded by the information from the new Hello message. This may the information from the new Hello message. This may cause a new DR to
cause a new DR to be chosen on that interface. | be chosen on that interface. |
To allow new or rebooting routers to learn of PIM neighbors quickly, | The LAN_Prune_Delay Option SHOULD be included in all Hello messages sent |
when a Hello message is received from a new neighbor, or a Hello message | on multi-access LANs. This option advertises a router's capability to |
with a new GenID is received from an existing neighbor, a new Hello | use values other than the default for the Propagation Delay and Override |
message should be sent on this interface after a randomized delay | Interval which affect the setting of the Prune Pending, Upstream Join |
between 0 and Triggered_Hello_Delay. This triggered message need not | and Override timers (defined in section 4.10). |
change the timing of the scheduled periodic message. |
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 When an interface goes down or changes IP address, a Hello message with
a zero Hold Time should be sent immediately (with the old IP address if a zero Hold Time should be sent immediately (with the old IP address if
the IP address changed). This will cause PIM neighbors to remove this the IP address changed). This will cause PIM neighbors to remove this
neighbor (or its old IP address) immediately. neighbor (or its old IP address) immediately.
4.6.2. DR Election 4.6.2. DR Election
When a PIM-Hello message is received on interface I the following When a PIM-Hello message is received on interface I the following
information about the sending neighbor is recorded: information about the sending neighbor is recorded:
skipping to change at page 87, line 20 skipping to change at page 89, line 43
} else { } else {
return ( a.dr_priority > b.dr_priority ) OR return ( a.dr_priority > b.dr_priority ) OR
( a.dr_priority == b.dr_priority AND ( a.dr_priority == b.dr_priority AND
a.ip_address > b.ip_address ) a.ip_address > b.ip_address )
} }
} }
The DR election priority is a 32-bit unsigned number and the numerically 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 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 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 | neighbor times out, or when a router's own DR priority changes. If the
router becomes the DR or ceases to be the DR, this will normally cause | router becomes the DR or ceases to be the DR, this will normally cause
the DR Register state-machine to change state. Subsequent actions are the DR Register state-machine to change state. Subsequent actions are
determined by that state-machine. determined by that state-machine.
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 neighbors prune messages 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: |
int |
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: |
int |
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: |
state |
Suppression_State(I) { |
if ( lan_delay_enabled(I) == false ) { |
return enabled |
} |
for each neighbor on interface I { |
if ( neighbor.tracking_support == false ) { |
return enabled |
} |
} |
return disabled |
} |
Note that the setting of Suppression_State(I) affects the value of |
t_suppressed (see section 4.10). |
4.7. PIM Bootstrap and RP Discovery 4.7. PIM Bootstrap and RP Discovery
For correct operation, every PIM router within a PIM domain must be able | For correct operation, every PIM router within a PIM domain must be able
to map a particular multicast group address to the same RP. If this is | to map a particular multicast group address to the same RP. If this is
not the case then black holes may appear, where some receivers in the | not the case then black holes may appear, where some receivers in the
domain cannot receive some groups. A domain in this context is a | domain cannot receive some groups. A domain in this context is a
contiguous set of routers that all implement PIM and are configured to | contiguous set of routers that all implement PIM and are configured to
operate within a common boundary defined by PIM Multicast Border Routers | operate within a common boundary defined by PIM Multicast Border Routers
(PMBRs). PMBRs connect each PIM domain to the rest of the Internet. |
A notable exception to this is where a PIM domain is broken up into | (PMBRs). PMBRs connect each PIM domain to the rest of the Internet.
multiple administrative scope regions - these are regions where a border |
has been configured so that a range of multicast groups will not be |
forwarded across that border. For more information on Administratively |
Scoped IP Multicast, see RFC 2365. The modified criteria for admin- |
scoped regions are that the region is convex with respect to forwarding |
based on the MRIB, and that all PIM routers within the scope region map |
scoped groups to the same RP within that region. |
This specification does not mandate the use of a single mechanism to | A notable exception to this is where a PIM domain is broken up into
provide routers with the information to perform the group-to-RP mapping. | multiple administrative scope regions - these are regions where a border
Currently three mechanisms are possible, and all three have associated | has been configured so that a range of multicast groups will not be
problems: | forwarded across that border. For more information on Administratively
Scoped IP Multicast, see RFC 2365. The modified criteria for admin-
scoped regions are that the region is convex with respect to forwarding
based on the MRIB, and that all PIM routers within the scope region map
scoped groups to the same RP within that region.
Static Configuration | This specification does not mandate the use of a single mechanism to
A PIM router MUST support the static configuration of group-to-RP | provide routers with the information to perform the group-to-RP mapping.
mappings. Such a mechanism is not robust to failures, but does at | Currently three mechanisms are possible, and all three have associated
least provide a basic interoperability mechanism. | problems:
Cisco's Auto-RP | Static Configuration
Auto-RP uses a PIM Dense-Mode multicast group to announce group-to- | A PIM router MUST support the static configuration of group-to-RP
RP mappings from a central location. This mechanism is not useful | mappings. Such a mechanism is not robust to failures, but does at
if PIM Dense-Mode is not being run in parallel with PIM Sparse- | least provide a basic interoperability mechanism.
Mode, and was only intended for use with PIM Sparse-Mode Version 1. |
No standard specification currently exists. |
BootStrap Router (BSR) | Cisco's Auto-RP
RFC 2362 specifies a bootstrap mechanism based around the automatic | Auto-RP uses a PIM Dense-Mode multicast group to announce group-to-
election of a bootstrap router (BSR). Any router in the domain | RP mappings from a central location. This mechanism is not useful
that is configured to be a possible RP reports its candidacy to the | if PIM Dense-Mode is not being run in parallel with PIM Sparse-
BSR, and then a domain-wide flooding mechanism distributes the | Mode, and was only intended for use with PIM Sparse-Mode Version 1.
BSR's chosen set of RPs throughout the domain. As specified in RFC | No standard specification currently exists.
2362, BSR is flawed in its handling of admin-scoped regions that |
are smaller than a PIM domain, but the mechanism does work for |
global-scoped groups. |
As far as PIM-SM is concerned, the only important requirement is that | BootStrap Router (BSR)
all routers in the domain (or admin scope zone for scoped regions) | RFC 2362 specifies a bootstrap mechanism based around the automatic
receive the same set of group-range-to-RP mappings. This may be | election of a bootstrap router (BSR). Any router in the domain
achieved through the use of any of these mechansms, or through | that is configured to be a possible RP reports its candidacy to the
alternative mechanisms not currently specified. | BSR, and then a domain-wide flooding mechanism distributes the
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
are smaller than a PIM domain, but the mechanism does work for
global-scoped groups.
Any RP address configured or learned MUST be a domain-wide reachable | As far as PIM-SM is concerned, the only important requirement is that
address. | 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
achieved through the use of any of these mechansms, or through
alternative mechanisms not currently specified.
Any RP address configured or learned MUST be a domain-wide reachable
address.
4.7.1. Group-to-RP Mapping 4.7.1. Group-to-RP Mapping
Using one of the mechanisms described above, a PIM router receives one | Using one of the mechanisms described above, a PIM router receives one
or more possible group-range-to-RP mappings. Each mapping specifies a | or more possible group-range-to-RP mappings. Each mapping specifies a
range of multicast groups (expressed as a group and mask) and the RP to | range of multicast groups (expressed as a group and mask) and the RP to
which such groups should be mapped. Each mapping may also have an | which such groups should be mapped. Each mapping may also have an
associated priority. It is possible to receive multiple mappings all of | associated priority. It is possible to receive multiple mappings all of
which might match the same multicast group - this is the common case | which might match the same multicast group - this is the common case
with BSR. The algorithm for performing the group-to-RP mapping is as | with BSR. The algorithm for performing the group-to-RP mapping is as
follows: | follows:
1 Perform longest match on group-range to obtain a list of RPs. | 1 Perform longest match on group-range to obtain a list of RPs.
2 From this list of matching RPs, find the one with highest priority. | 2 From this list of matching RPs, find the one with highest priority.
Eliminate any RPs from the list that have lower priorities. | Eliminate any RPs from the list that have lower priorities.
3 If only one RP remains in the list, use that RP. | 3 If only one RP remains in the list, use that RP.
4 If multiple RPs are in the list, use the PIM hash function to | 4 If multiple RPs are in the list, use the PIM hash function to
choose one. | choose one.
Thus if two or more group-range-to-RP mappings cover a particular group, | Thus if two or more group-range-to-RP mappings cover a particular group,
the one with the longest mask is the mapping to use. If the mappings | the one with the longest mask is the mapping to use. If the mappings
have the same mask length, then the one with the highest priority is | have the same mask length, then the one with the highest priority is
chosen. If there is more than one matching entry with the same longest | chosen. If there is more than one matching entry with the same longest
mask and the priorities are identical, then a hash function (see Section | mask and the priorities are identical, then a hash function (see Section
4.7.2) is applied to choose the RP. | 4.7.2) is applied to choose the RP.
This algorithm is invoked by a DR when it needs to determine an RP for a | This algorithm is invoked by a DR when it needs to determine an RP for a
given group, e.g. upon reception of a packet or IGMP membership | given group, e.g. upon reception of a packet or IGMP membership
indication for a group for which the DR does not know the RP. It is | indication for a group for which the DR does not know the RP. It is
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.
4.7.2. Hash Function 4.7.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 |
one RP address to be used. | addresses of the candidate RPs from the mappings, and gives as output
one RP address to be used.
The protocol requires that all routers hash to the same RP within a The protocol requires that all routers hash to the same RP within a
domain (except for transients). The following hash function must be used domain (except for transients). The following hash function must be used
in each router: in each router:
1 For RP addresses in the matching group-range-to-RP mappings, | 1 For RP addresses in the matching group-range-to-RP mappings,
compute a value: | compute a value:
Value(G,M,C(i))= Value(G,M,C(i))=
(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31 (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31
where C(i) is the RP address and M is a hash-mask included in where C(i) is the RP address and M is a hash-mask included in
Bootstrap messages. The hash-mask allows a small number of Bootstrap messages. The hash-mask allows a small number of
consecutive groups (e.g., 4) to always hash to the same RP. For consecutive groups (e.g., 4) to always hash to the same RP. For
instance, hierarchically-encoded data can be sent on consecutive instance, hierarchically-encoded data can be sent on consecutive
group addresses to get the same delay and fate-sharing group addresses to get the same delay and fate-sharing
characteristics. characteristics.
For address families other than IPv4, a 32-bit digest to be used as | For address families other than IPv4, a 32-bit digest to be used as
C(i) and G must first be derived from the actual RP or group | C(i) and G must first be derived from the actual RP or group
address. Such a digest method must be used consistently throughout | address. Such a digest method must be used consistently throughout
the PIM domain. For IPv6 addresses, we recommend using the the PIM domain. For IPv6 addresses, we recommend using the
equivalent IPv4 address for an IPv4-compatible address, and the | equivalent IPv4 address for an IPv4-compatible address, and the
exclusive-or of each 32-bit segment of the address for all other | exclusive-or of each 32-bit segment of the address for all other
IPv6 addresses. For example, the digest of the IPv6 address | IPv6 addresses. For example, the digest of the IPv6 address
3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^ | 3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^
0x00000000 ^ 0x00000010, where ^ represents the exclusive-or | 0x00000000 ^ 0x00000010, where ^ represents the exclusive-or
operation. | operation.
2 The candidate RP with the highest resulting hash value is then | 2 The candidate RP with the highest resulting hash value is then
chosen as the RP for that group, and its identity and hash value chosen as the RP for that group, and its identity and hash value
are stored with the entry created. are stored with the entry created.
Ties between RPs having the same hash value are broken in advantage | Ties between RPs having the same hash value are broken in advantage
of the highest address. of the highest address.
4.8. Source-Specific Multicast 4.8. Source-Specific Multicast
The Source-Specific Multicast (SSM) service model [11] can be The Source-Specific Multicast (SSM) service model [10] can be
implemented with a strict subset of the PIM-SM protocol mechanisms. implemented with a strict subset of the PIM-SM protocol mechanisms.
Both regular IP Multicast and SSM semantics can coexist on a single Both regular IP Multicast and SSM semantics can coexist on a single
router and both can be implemented using the PIM-SM protocol. A range router and both can be implemented using the PIM-SM protocol. A range
of multicast addresses, currently 232.0.0.0/8 in IPv4, is reserved for of multicast addresses, currently 232.0.0.0/8 in IPv4, is reserved for
SSM, and the choice of semantics is determined by the multicast group SSM, and the choice of semantics is determined by the multicast group
address in both data packets and PIM messages. address in both data packets and PIM messages.
4.8.1. Protocol Modifications for SSM destination addresses 4.8.1. Protocol Modifications for SSM destination addresses
The following rules override the normal PIM-SM behavior for a multicast The following rules override the normal PIM-SM behavior for a multicast
address G in the SSM reserved range: address G in the SSM reserved range:
o A router MUST NOT send a (*,G) Join/Prune message for any reason. o A router MUST NOT send a (*,G) Join/Prune message for any reason.
o A router MUST NOT send an (S,G,rpt) Join/Prune message for any reason. o A router MUST NOT send an (S,G,rpt) Join/Prune message for any reason.
skipping to change at page 92, line 11 skipping to change at page 97, line 30
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.4.6, 4.4.8, and 4.4.5)
o (*,G) Assert state machine (Section 4.5.2) o (*,G) Assert state machine (Section 4.5.2)
o Bootstrap RP Election (Section 4.7) o Bootstrap RP Election (Section 4.7)
o Keepalive Timer o Keepalive Timer
o SptBit (Section 4.2.1) 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-
only router: only router:
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) { if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
oiflist = inherited_olist(S,G) oiflist = inherited_olist(S,G)
} else if( iif is in inherited_olist(S,G) ) { } else if( iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif send Assert(S,G) on iif
skipping to change at page 92, line 35 skipping to change at page 98, line 10
forward packet on all interfaces in oiflist forward packet on all interfaces in oiflist
This is nothing more than the reduction of the normal PIM-SM forwarding This is nothing more than the reduction of the normal PIM-SM forwarding
rule, with all (S,G,rpt) and (*,G) clauses replaced with NULL. rule, with all (S,G,rpt) and (*,G) clauses replaced with NULL.
4.9. PIM Packet Formats 4.9. PIM Packet Formats
This section describes the details of the packet formats for PIM control This section describes the details of the packet formats for PIM control
messages. messages.
All PIM control messages have IP protocol number 103. | All PIM control messages have IP protocol number 103.
PIM messages are either unicast (e.g. Registers and Register-Stop), or | PIM messages are either unicast (e.g. Registers and Register-Stop), or
multicast with TTL 1 to the `ALL-PIM-ROUTERS' group (e.g. Join/Prune, | multicast with TTL 1 to the `ALL-PIM-ROUTERS' group (e.g. Join/Prune,
Asserts, etc.). The source address used for unicast messages is a | Asserts, etc.). The source address used for unicast messages is a
domain-wide reachable address; the source address used for multicast | domain-wide reachable address; the source address used for multicast
messages is the link-local address of the interface on which the message | messages is the link-local address of the interface on which the message
is being sent. | is being sent.
The IPv4 `ALL-PIM-ROUTERS' group is `224.0.0.13'. The IPv6 `ALL-PIM-
ROUTERS' group is `ff02::d'.
The IPv4 `ALL-PIM-ROUTERS' group is `224.0.0.13'. The IPv6 `ALL-PIM- |
ROUTERS' group is `ff02::d'. |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver PIM Ver
PIM Version number is 2. PIM Version number is 2.
Type Types for specific PIM messages. PIM Types are: Type Types for specific PIM messages. PIM Types are: |
0 = Hello Message Type Destination ||
1 = Register --------------------------------------------------------------------------||
2 = Register-Stop 0 = Hello Multicast to ALL-PIM-ROUTERS ||
3 = Join/Prune 1 = Register Unicast to RP ||
4 = Bootstrap 2 = Register-Stop Unicast to source of Register packet||
5 = Assert 3 = Join/Prune Multicast to ALL-PIM-ROUTERS ||
6 = Graft (used in PIM-DM only) 4 = Bootstrap Multicast to ALL-PIM-ROUTERS ||
7 = Graft-Ack (used in PIM-DM only) 5 = Assert Multicast to ALL-PIM-ROUTERS ||
8 = Candidate-RP-Advertisement 6 = Graft (used in PIM-DM only) Multicast to ALL-PIM-ROUTERS ||
7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft packet ||
8 = Candidate-RP-Advertisement Unicast to Domain's BSR ||
Reserved Reserved
Set to zero on transmission. Ignored upon receipt. Set to zero on transmission. Ignored upon receipt.
Checksum Checksum
The checksum is a standard IP checksum, i.e. the 16-bit one's | The checksum is a standard IP checksum, i.e. the 16-bit one's
complement of the one's complement sum of the entire PIM message, complement of the one's complement sum of the entire PIM message,
excluding the data portion in the Register message. For computing excluding the data portion in the Register message. For computing
the checksum, the checksum field is zeroed. | the checksum, the checksum field is zeroed.
For IPv6, the checksum also includes the IPv6 "pseudo-header", as | For IPv6, the checksum also includes the IPv6 "pseudo-header", as
specified in RFC 2460, section 8.1 [8]. This "pseudo-header" is | specified in RFC 2460, section 8.1 [9]. This "pseudo-header" is
prepended to the PIM header for the purposes of calculating the | prepended to the PIM header for the purposes of calculating the
checksum. The "Upper-Layer Packet Length" in the pseudo-header is | checksum. The "Upper-Layer Packet Length" in the pseudo-header is
set to the length of the PIM message. The Next Header value used | set to the length of the PIM message. The Next Header value used
in the pseudo-header is 103. If the packet's length is not an | in the pseudo-header is 103. If the packet's length is not an
integral number of 16-bit words, the packet is padded with a byte | integral number of 16-bit words, the packet is padded with a byte
of zero before performing the checksum. | of zero before performing the checksum.
4.9.1. Encoded Source and Group Address Formats 4.9.1. Encoded Source and Group Address Formats
Encoded-Unicast address Encoded-Unicast address
An Encoded-Unicast address takes the following format: An Encoded-Unicast address takes the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address | Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
The PIM address family of the `Unicast Address' field of this | The PIM address family of the `Unicast Address' field of this
address. address.
Values of 0-127 are as assigned by the IANA for Internet Address Values of 0-127 are as assigned by the IANA for Internet Address
Families in [5]. Values 128-250 are reserved to be assigned by the Families in [5]. Values 128-250 are reserved to be assigned by the
IANA for PIM-specific Address Families. Values 251 though 255 are IANA for PIM-specific Address Families. Values 251 though 255 are
designated for private use. As there is no assignment authority designated for private use. As there is no assignment authority
for this space, collisions should be expected. for this space, collisions should be expected.
Encoding Type Encoding Type
The type of encoding used within a specific Address Family. The The type of encoding used within a specific Address Family. The
skipping to change at page 94, line 43 skipping to change at page 100, line 13
The unicast address as represented by the given Address Family and The unicast address as represented by the given Address Family and
Encoding Type. Encoding Type.
Encoded-Group address Encoded-Group address
Encoded-Group addresses take the following format: Encoded-Group addresses take 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Reserved | Mask Len | | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Group multicast Address | Group multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... <span class="insert">|</span>
Addr Family Addr Family
described above. described above.
Encoding Type Encoding Type
described above. described above.
[B]idirectional PIM
indicates the group range should use Bidirectional PIM [6]. For
PIM-SM defined in this specification, this bit MUST be zero.
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Admin Scope [Z]one |
indicates the group range is an admin scope zone. This is used in |
the Bootstrap Router Mechanism [4] only. For all other purposes, |
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 and 128 for IPv6 native encoding).
skipping to change at page 96, line 11 skipping to change at page 101, line 33
Encoding Type Encoding Type
described above. described above.
Reserved Reserved
Transmitted as zero, ignored on receipt. Transmitted as zero, ignored on receipt.
S The Sparse bit is a 1 bit value, set to 1 for PIM-SM. It is used S The Sparse bit is a 1 bit value, set to 1 for PIM-SM. It is used
for PIM version 1 compatibility. for PIM version 1 compatibility.
W The WC (or WildCard) bit is a 1 bit value for use with PIM | W The WC (or WildCard) bit is a 1 bit value for use with PIM
Join/Prune messages (see section 4.9.5.1 ). | Join/Prune messages (see section 4.9.5.1 ).
R The RPT (or Rendezvous Point Tree) bit is a 1 bit value for use | R The RPT (or Rendezvous Point Tree) bit is a 1 bit value for use
with PIM Join/Prune messages (see section 4.9.5.1 ). If the WC bit | with PIM Join/Prune messages (see section 4.9.5.1 ). If the WC bit
is 1, the RPT bit MUST be 1. | is 1, the RPT bit MUST be 1.
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 Source Address, describes a source subnet. The mask length with the Source Address, describes a source subnet. The mask length |
must be less than or equal to the address length in bits for the MUST be equal to the mask length in bits for the given Address |
given Address Family and Encoding Type. If the message is sent for Family and Encoding Type (32 for IPv4 native and 128 for IPv6 |
a single source then the Mask length must equal the address length native). A router SHOULD ignore any messages received with any |
in bits for the given Address Family and Encoding Type. In version other mask length. |
2 of PIM, it is strongly recommended that this field be set to 32
for IPv4 native encoding.
Source Address Source Address
The source address. The source address.
4.9.2. Hello Message Format 4.9.2. Hello Message Format
It is sent periodically by routers on all interfaces. It is sent periodically by routers on all interfaces.
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 98, line 15 skipping to change at page 103, line 23
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 = 1 | Length = 2 | | Type = 1 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time | | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hold Time is the amount of time a receiver must keep the neighbor Hold Time 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. Furthermore, if the Holdtime is with periodic Hello messages. |
set to `0', the information is timed out immediately.
o OptionType 2 to 16: reserved to be defined in future versions of Hello messages with a Holdtime value set to `0' are also sent by |
this document. a router on an interface about to go down or changing IP address |
(see section 4.6.1). These are effectively goodbuy messages and |
the receiving routers should immediately time out the neighbor |
information for the sender. |
o OptionType 2: LAN Prune Delay |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Type = 2 | Length = 4 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|T| LAN Delay | Override Interval | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
The LAN_Prune_Delay option is used to tune the prune propagation |
delay on multi-access LANs. |
The T bit specifies the ability of the sending router to disable |
joins suppression. |
LAN Delay and Override Interval are time intervals in units of |
milliseconds are are used to tune the value of the J/P Override |
Interval and its derived timer values. Section 4.6.3 describes how |
these values affect the behaviour of a router. |
o OptionType 3 to 16: reserved to be defined in future versions of |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 99, line 7 skipping to change at page 104, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation ID | | Generation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Generation ID is a random 32-bit value for the interface on which Generation ID is a random 32-bit value for the interface on which
the Hello message is sent. The Generation ID is regenerated the Hello message is sent. The Generation ID is regenerated
whenever PIM forwarding is started or restarted on the interface. whenever PIM forwarding is started or restarted on the interface.
OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes
65001 through 65535 are reserved for Private Use, as defined in 65001 through 65535 are reserved for Private Use, as defined in
[6]. [7].
Unknown options may be ignored. The "Hold Time" option MUST be Unknown options may be ignored. The "Hold Time" option MUST be
implemented; the "DR Priority" and "Generation ID" options SHOULD implemented; the "DR Priority" and "Generation ID" options SHOULD
be implemented. be implemented.
4.9.3. Register Message Format 4.9.3. Register Message Format
A Register message is sent by the DR or a PMBR to the RP when a | A Register message is sent by the DR or a PMBR to the RP when a
multicast packet needs to be transmitted on the RP-tree. The IP source | multicast packet needs to be transmitted on the RP-tree. The IP source
address is set to the address of the DR, the destination address to the | address is set to the address of the DR, the destination address to the
RP's address. The IP TTL of the PIM packet is the system's normal | RP's address. The IP TTL of the PIM packet is the system's normal
unicast TTL. | unicast TTL.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 packet, including the PIM header and the next 4
bytes, excluding the data packet portion. For interoperability bytes, excluding the data packet portion. For interoperability
reasons, a message carrying a checksum calculated over the entire reasons, a message carrying a checksum calculated over the entire
PIM register message should be accepted. PIM register message should 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
skipping to change at page 100, line 11 skipping to change at page 105, line 39
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.
Reserved2 Reserved2
Transmitted as zero, ignored on receipt. Transmitted as zero, ignored on receipt.
Multicast data packet Multicast data packet
The original packet sent by the source. This packet must be the of The original packet sent by the source. This packet must be the of
the same address family as the encapsulating PIM packet, e.g. an the same address family as the encapsulating PIM packet, e.g. an
IPv6 data packet must be encapsulated in an IPv6 PIM packet. Note | IPv6 data packet must be encapsulated in an IPv6 PIM packet. Note
that the TTL of the original packet is decremented before | that the TTL of the original packet is decremented before
encapsulation, just like any other packet that is forwarded. In | encapsulation, just like any other packet that is forwarded. In
addition, the RP decrements the TTL after decapsulating, before | addition, the RP decrements the TTL after decapsulating, before
forwarding the packet down the shared tree. | forwarding the packet down the shared tree.
For (S,G) null Registers, the Multicast data packet portion For (S,G) null Registers, the Multicast data packet portion
contains only a dummy header with S as the source address, G as the contains only a dummy header with S as the source address, G as the
destination address, and a data length of zero. destination address, and a data length of zero.
4.9.4. Register-Stop Message Format 4.9.4. Register-Stop Message Format
A Register-Stop is unicast from the RP to the sender of the Register A Register-Stop is unicast from the RP to the sender of the Register
message. The IP source address is the address to which the register was message. The IP source address is the address to which the register was
addressed. The IP destination address is the source address of the addressed. The IP destination address is the source address of the
skipping to change at page 101, line 6 skipping to change at page 106, line 32
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described above. Described above.
Group Address Group Address
The group address from the multicast data packet in the Register. The group address from the multicast data packet in the Register.
Format described in section 4.9.1. Note that for Register-Stops the Format described in section 4.9.1. Note that for Register-Stops the
Mask Len field contains the full address length * 8 (e.g. 32 for Mask Len field contains the full address length * 8 (e.g. 32 for
IPv4 native encoding), if the message is sent for a single group. IPv4 native encoding), if the message is sent for a single group.
Source Address Source Address
Host address of source from multicast data packet in register. The The host address of the source from the multicast data packet in |
format for this address is given in the Encoded-Unicast address in the register. The format for this address is given in the Encoded- |
section 4.9.1. A special wild card value (0's), can be used to Unicast address in section 4.9.1. A special wild card value |
indicate any source. XXX note that "(0's)" doesn't really describe consisting of an address field of all zeroes can be used to |
what the rest of the field in encoded-unicast-address should be indicate any source. |
4.9.5. Join/Prune Message Format 4.9.5. Join/Prune Message Format
A Join/Prune message is sent by routers towards upstream sources and A Join/Prune message is sent by routers towards upstream sources and
RPs. Joins are sent to build shared trees (RP trees) or source trees RPs. Joins are sent to build shared trees (RP trees) or source trees
(SPT). Prunes are sent to prune source trees when members leave groups (SPT). Prunes are sent to prune source trees when members leave groups
as well as sources that do not use the shared tree. as well as sources that do not use the shared tree.
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 103, line 12 skipping to change at page 108, line 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) | | Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described above. Described above.
Unicast Upstream Neighbor Address Unicast Upstream Neighbor Address
The address of the RPF or upstream neighbor. The format for this The address of the RPF or upstream neighbor. The format for this
address is given in the Encoded-Unicast address in section 4.9.1. | address is given in the Encoded-Unicast address in section 4.9.1.
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 cancelling Join/Prune message, or timed out according
to local policy. This may be used with dial-on-demand links, to | to local policy. This may be used with dial-on-demand links, to
avoid keeping the link up with periodic Join/Prune messages. | avoid 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. | J/P_Override_Interval.
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.9.1. For format description see Section 4.9.1.
Number of Joined Sources Number of Joined Sources
Number of join source addresses listed for a given group. Number of join source addresses listed for a given group.
skipping to change at page 104, line 7 skipping to change at page 109, line 10
multicast datagrams for if received on the interface this message multicast datagrams for if received on the interface this message
is sent on. is sent on.
See Encoded-Source-Address format in section 4.9.1. See Encoded-Source-Address format in section 4.9.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.
4.9.5.1. Group Set Source List Rules | 4.9.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 by 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. Each wildcard group set may contain one or more (*,*,RP)
source list entries in either the Join or Prune lists. | 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.
(*,*,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 | For IPv4, a Group Specific Set is represented by a valid IP
multicast address in the group address field and the full length of | multicast address in the group address field and the full length of
the IP address in the mask length field of the Multicast Group | the IP address in the mask length field of the Multicast Group
Address. Each group specific set may contain (*,G), (S,G,rpt) and | Address. Each group specific set may contain (*,G), (S,G,rpt) and
(S,G) source list entries in the Join or Prune lists. | (S,G) source list entries in the Join or Prune lists.
(*,G) | (*,G)
The (*,G) source list entry is used in Join / Prune messages | The (*,G) source list entry is used in Join / Prune messages
sent towards the RP for the specified group. It expresses | sent towards the RP for the specified group. It expresses
interest (or lack of) in receiving traffic sent to the group | interest (or lack of) in receiving traffic sent to the group
through the Rendezvous-Point shared tree. There may only be | through the Rendezvous-Point shared tree. There may only be
one such entry in both the Join and Prune lists of a group | one such entry in both the Join and Prune lists of a group
specific set. | specific set.
(*,G) source list entries have the Source-Address set to the | (*,G) source list entries have the Source-Address set to the
address of the RP for group G, the Source-Address Mask-Len set | address of the RP for group G, the Source-Address Mask-Len set
to the full length of the IP address and have both the WC and | to the full length of the IP address and have both the WC and
RPT bits of the Encoded-Source-Address set. | RPT bits of the Encoded-Source-Address set.
(S,G,rpt) | (S,G,rpt)
The (S,G,rpt) source list entry is used in Join / Prune | The (S,G,rpt) source list entry is used in Join / Prune
messages sent towards the RP for the specified group. It | messages sent towards the RP for the specified group. It
expresses interest (or lack of) in receiving traffic through | expresses interest (or lack of) in receiving traffic through
the shared tree sent by the specified source to this group. | the shared tree sent by the specified source to this group. |
There may only be one such entry for each source address in | For each source address the entry may exist in only one of the |
both the Join and Prune lists of a group specific set. | Join and Prune source lists of a group specific set but not |
both. |
(S,G,rpt) source list entries have the Source-Address set to | (S,G,rpt) source list entries have the Source-Address set to
the address of the source S, the Source-Address Mask-Len set | the address of the source S, the Source-Address Mask-Len set
to the full length of the IP address and have the WC bit clear | to the full length of the IP address and have the WC bit clear
and the RPT bit set in the Encoded-Source-Address. | and the RPT bit set in the Encoded-Source-Address.
(S,G) |
The (S,G) source list entry is used in Join / Prune messages |
sent towards the specified source. It expresses interest (or |
lack of) in receiving traffic through the shortest path tree |
sent by the source to the specified group. There may only be |
one such entry for each source address in both the Join and |
Prune lists of a group specific set. |
(S,G) source list entries have the Source-Address set to the | (S,G)
address of the source S, the Source-Address Mask-Len set to | The (S,G) source list entry is used in Join / Prune messages
sent towards the specified source. It expresses interest (or
lack of) in receiving traffic through the shortest path tree
sent by the source to the specified group. For each source |
address the entry may exist in only one of the Join and Prune |
source lists of a group specific set but not both. |
(S,G) source list entries have the Source-Address set to the
address of the source S, the Source-Address Mask-Len set to
the full length of the IP address and have both the WC and RPT | the full length of the IP address and have both the WC and RPT |
bits of the Encoded-Source-Address clear. | bits of the Encoded-Source-Address cleared. |
The rules described above are sufficient to prevent invalid combinations | The rules described above are sufficient to prevent invalid combinations
of source list entries in group-specific sets. There are however a | of source list entries in group-specific sets. There are however a
number of combinations that have a valid interpretation but which are | number of combinations that have a valid interpretation but which are
not generated by the protocol as described in this specification: | not generated by the protocol as described in this specification:
o Combining a (*,G) Join and a (S,G,rpt) Join entry in the same message | o Combining a (*,G) Join and a (S,G,rpt) Join entry in the same message
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 is meaningless.
o As Join / Prune messages are targeted to a single PIM neighbour, | o As Join / Prune messages are targeted to a single PIM neighbour,
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 neighbour 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 summarised in the table below.
+-----------++-------+--------+------------+------------+--------+-------|| +-----------++-------+--------+------------+------------+--------+--------+
| ||(*,G)J | (*,G)P | (S,G,rpt)J | (S,G,rpt)P | (S,G)J | (S,G)P|| | ||(*,G)J | (*,G)P | (S,G,rpt)J | (S,G,rpt)P | (S,G)J | (S,G)P |
+-----------++-------+--------+------------+------------+--------+--------| +-----------++-------+--------+------------+------------+--------+--------+
|(*,G)J ||- | no | ? | yes | yes | yes || |(*,G)J ||- | no | ? | yes | yes | yes |
+-----------++-------+--------+------------+------------+--------+--------| +-----------++-------+--------+------------+------------+--------+--------+
|(*,G)P || | - | ? | ? | yes | yes || |(*,G)P || | - | ? | ? | yes | yes |
+-----------++-------+--------+------------+------------+--------+--------| +-----------++-------+--------+------------+------------+--------+--------+
|(S,G,rpt)J || | | - | no | yes | yes || |(S,G,rpt)J || | | - | no | yes | yes |
+-----------++-------+--------+------------+------------+--------+--------| +-----------++-------+--------+------------+------------+--------+--------+
|(S,G,rpt)P || | | | - | ? | ? || |(S,G,rpt)P || | | | - | ? | ? |
+-----------++-------+--------+------------+------------+--------+--------| +-----------++-------+--------+------------+------------+--------+--------+
|(S,G)J || | | | | - | no || |(S,G)J || | | | | - | no |
+-----------++-------+--------+------------+------------+--------+--------| +-----------++-------+--------+------------+------------+--------+--------+
|(S,G)P || | | | | | - || |(S,G)P || | | | | | - |
+-----------++-------+--------+------------+------------+--------+--------| +-----------++-------+--------+------------+------------+--------+--------+
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. As a result the table above is symmetric and only entries on
the upper right half have been specified as entries on the lower left | the upper right half have been specified as entries on the lower left
are just a mirror. | are just a mirror.
4.9.5.2. Group Set Fragmentation | 4.9.5.2. Group Set Fragmentation
When building a Join / Prune for a prticular neighbour, a router should | When building a Join / Prune for a prticular neighbour, 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 neighbour 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
all traffic for the specified group on the shared tree and it MUST | all traffic for the specified group on the shared tree and it MUST
include an (S,G,rpt) Prune source list entry for every source that the | include an (S,G,rpt) Prune source list entry for every source that the
router does not wish to receive. This list of (S,G,rpt) Prune source- | router does not wish to receive. This list of (S,G,rpt) Prune source-
list entries MUST not be split in multiple messages. | list entries MUST not be split in multiple messages.
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) IP | the router MUST choose to include the first N (numerically smallest) IP
addresses. | addresses.
4.9.6. Assert Message Format 4.9.6. Assert Message Format
The Assert message is sent when a multicast data packet is received on The Assert message is used to resolve forwarder conflicts between |
an outgoing interface corresponding to the (S,G) or (*,G) associated routers on a link. It is sent when a multicast data packet is received |
with the source. on an interface that the router would normaly forward that packet. |
Assert messages may also be sent in response to an Assert message from |
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) | | Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference | |R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described above. Described above.
Group Address Group Address
The group address to which the data packet was addressed, and which The group address for which the router wishes to resolve the |
triggered the Assert. This is an Encoded-Group address, as forwarding conflict. This is an Encoded-Group address, as |
specified in 4.9.1. specified in 4.9.1. |
Source Address Source Address
Source address from multicast datagram that triggered the Assert Source address for which the router wishes to resolve the |
packet to be sent. The format for this address is given in Encoded- forwarding conflict. The source address MAY be set to INADDR_ANY |
Unicast-Address in section 4.9.1. for (*,G) asserts (see below). The format for this address is |
given in Encoded-Unicast-Address in section 4.9.1. |
R RPT-bit is a 1 bit value. If the multicast datagram that triggered R RPT-bit is a 1 bit value. The RPT-bit is set to 1 for (*,G) Assert |
the Assert packet is routed down the RP tree, then the RPT-bit is messages and 0 for (S,G) assert messages. |
1; if the multicast datagram is routed down the SPT, it is 0.
Metric Preference Metric Preference
Preference value assigned to the unicast routing protocol that Preference value assigned to the unicast routing protocol that |
provided the route to Host address. provided the route to the multicast source or Rendezvous-Point. |
Metric Metric
The unicast routing table metric. The metric is in units The unicast routing table metric associated with the route used to |
applicable to the unicast routing protocol used. reach the multicast source or Rendezvous-Point. The metric is in |
units applicable to the unicast routing protocol used. |
Assert messages can be sent to resolve a forwarding conflict for all |
traffic to given group or for a specific source and group. |
(S,G) Asserts |
Source specific asserts are sent by routers forwarding a specific |
source on the shortest-path tree (SPT bit is TRUE). (S,G) Asserts |
have the Group-Address field set to the group G and the Source- |
Address field set to the source S. The RPT-bit is set to 0, the |
Metric-Preference is set to MRIB.pref(S) and the Metric is set to |
MRIB.metric(S). |
(*,G) Asserts |
Group specific asserts are sent by routers forwarding data for the |
group and source(s) under contention on the shared tree. (*,G) |
asserts have the Group-Address field set to the group G. For data |
triggered Asserts the Source-Address field MAY be set to the IP |
source address of the data packet that triggered the Assert and is |
set to INADDR_ANY otherwise. The RPT-bit is set to 1, the Metric- |
Preference is set to MRIB.pref(RP(G)) and the Metric is set to |
MRIB.metric(RP(G)). |
4.10. PIM Timers 4.10. PIM Timers
PIM-SM maintains the following timers, as discussed in section 4.1. All PIM-SM maintains the following timers, as discussed in section 4.1. All
timers are countdown timers - they are set to a value and count down to timers are countdown timers - they are set to a value and count down to
zero, at which point they typically trigger an action. Of course they zero, at which point they typically trigger an action. Of course they
can just as easily be implemented as count-up timers, where the absolute can just as easily be implemented as count-up timers, where the absolute
expiry time is stored and compared against a real-time clock, but the expiry time is stored and compared against a real-time clock, but the
language in this specification assumes that they count downwards to language in this specification assumes that they count downwards to
zero. zero.
Global Timers Global Timers
Hello Timer: HT
Per interface (I): Per interface (I):
Hello Timer: HT(I)
Per neighbor (N): Per neighbor (N):
Neighbor liveness Timer: NLT(N,I) Neighbor liveness Timer: NLT(N,I)
Per active RP (RP): Per active RP (RP):
(*,*,RP) Join Expiry Timer: ET(*,*,RP,I) (*,*,RP) Join Expiry Timer: ET(*,*,RP,I)
(*,*,RP) PrunePending Timer: PPT(*,*,RP,I) (*,*,RP) PrunePending Timer: PPT(*,*,RP,I)
skipping to change at page 110, line 45 skipping to change at page 116, line 21
At the DRs or relevant Assert Winners only: At the DRs or relevant Assert Winners only:
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.11. Timer Values 4.11. 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. |
Timer Name: Hello Timer (HT) Note that protocol events or configuration may change the default value |
of a timer on a specific interface. When timers are initialised in this |
document the value specific to the interface in context must be used. |
+----------------------+--------+---------------------------------------+| Some of the timers listed below (Prune Pending, Upstream Join, Upstream |
Override) can be set to values which depend on the settings of the |
Propagation Delay and Override Interval of the corresponding interface. |
The default values for these are given below. Note that the value of |
both the Propagation Delay and Override Interval of an interface can |
change as a result of receiving Hello messages on that interface |
(section 4.6.3). |
Variable Name: Propagation Delay (PD(I)) |
+-------------------------+----------------+----------------------------+|
| Value Name | Value | Explanation ||
+-------------------------+----------------+----------------------------+|
| LAN_delay_default | 0.5 sec | Expected | ||
| | | propagation delay | ||
| | | over the local | ||
| | | link. | ||
+-------------------------+----------------+----------------------------+|
The default value of the LAN_delay_default is chosen to be relatively
large to provide compatibility with older PIM implementations.
Variable Name: Override Interval (OI(I))
+--------------------------+-----------------+--------------------------+
| Value Name | Value | Explanation |
+--------------------------+-----------------+--------------------------+
| t_override_default | 2.5 sec | Default delay |
| | | interval over |
| | | which to randomize |
| | | when scheduling a |
| | | delayed Join |
| | | message. |
+--------------------------+-----------------+--------------------------+
Timer Name: Hello Timer (HT(I))
+----------------------+--------+---------------------------------------+
|Value Name | Value | Explanation | |Value Name | Value | Explanation |
+----------------------+--------+---------------------------------------+ +----------------------+--------+---------------------------------------+
|Hello_Period | 30 sec | Periodic interval for hello messages. | |Hello_Period | 30 sec | Periodic interval for hello messages. |
+----------------------+--------+---------------------------------------+| +----------------------+--------+---------------------------------------+
|Triggered_Hello_Delay | 5 sec | Randomized interval for initial Hello || |Triggered_Hello_Delay | 5 sec | Randomized interval for initial Hello |
| | | message on bootup or triggered Hello || | | | message on bootup or triggered Hello |
| | | message to a rebooting neighbor. || | | | message to a rebooting neighbor. |
+----------------------+--------+---------------------------------------+| +----------------------+--------+---------------------------------------+
Hello messages are sent on every active interface once every At system power-up, the timer is initialized to
Hello_Period seconds. At system power-up, the timer is initialized to | rand(0,Triggered_Hello_Delay) to prevent synchronization. When a new or
rand(0,Triggered_Hello_Delay) to prevent synchronization. When a new or |
rebooting neighbor is detected, a responding Hello is sent within rebooting neighbor is detected, a responding Hello is sent within
rand(0,Triggered_Hello_Delay). rand(0,Triggered_Hello_Delay).
Timer Name: Neighbor Liveness Timer (NLT(N,I)) Timer Name: Neighbor Liveness Timer (NLT(N,I))
+-------------------+-----------------+---------------------------------+ +-------------------+-----------------+---------------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+-------------------+-----------------+---------------------------------+ +-------------------+-----------------+---------------------------------+
| Hello Holdtime | from message | Hold Time from Hello Message | | Hello Holdtime | from message | Hold Time from Hello Message |
+-------------------+-----------------+---------------------------------+ +-------------------+-----------------+---------------------------------+
skipping to change at page 112, line 8 skipping to change at page 118, line 20
+----------------+----------------+-------------------------------------+ +----------------+----------------+-------------------------------------+
| J/P HoldTime | from message | Hold Time from Join/Prune Message | | J/P HoldTime | from message | Hold Time from Join/Prune Message |
+----------------+----------------+-------------------------------------+ +----------------+----------------+-------------------------------------+
See details of JT(*,G) for the Hold Time that is included in Join/Prune See details of JT(*,G) for the Hold Time that is included in Join/Prune
Messages. Messages.
Timer Names: Prune Pending Timer (PPT(*,*,RP,I), PPT(*,G,I), PPT(S,G,I), Timer Names: Prune Pending Timer (PPT(*,*,RP,I), PPT(*,G,I), PPT(S,G,I),
PPT(S,G,rpt,I)) PPT(S,G,rpt,I))
+--------------------------+--------------------+-----------------------+ +-----------------------+------------------------+----------------------+|
| Value Name | Value | Explanation | |Value Name | Value | Explanation ||
+--------------------------+--------------------+-----------------------+ +-----------------------+------------------------+----------------------+|
| J/P Override Interval | Default: 3 secs | Short period after | |J/P Override Interval | Default: | | Short period after | ||
| | | a join or prune to | | | Propagation Delay | | a join or prune to | ||
| | | allow other | | | + Override | | allow other | ||
| | | routers on the LAN | | | Interval | | routers on the LAN | ||
| | | to override the | | | | to override the | ||
| | | join or prune | | | | join or prune | ||
+--------------------------+--------------------+-----------------------+ +-----------------------+------------------------+----------------------+|
Note that both the Propagation Delay and the Override Interval are |
interface specific values that may change when Hello messages are |
received. |
Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I)) Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
| Assert Override Interval | Default: 3 secs | Short interval | | Assert Override Interval | Default: 3 secs | Short interval |
| | | before an assert | | | | before an assert |
| | | times out where | | | | times out where |
| | | the assert winner | | | | the assert winner |
skipping to change at page 113, line 7 skipping to change at page 119, line 29
| | | assert state is | | | | assert state is |
| | | timed out | | | | timed out |
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
Note that for historical reasons, the Assert message lacks a Holdtime Note that for historical reasons, the Assert message lacks a Holdtime
field. Thus changing the Assert Time from the default value is not field. Thus changing the Assert Time from the default value is not
recommended. recommended.
Timer Names: Upstream Join Timer (JT(*,*,RP), JT(*,G), JT(S,G)) Timer Names: Upstream Join Timer (JT(*,*,RP), JT(*,G), JT(S,G))
+-------------+--------------------+------------------------------------+ +-------------+-------------------------+--------------------------------|--------|
|Value Name |Value |Explanation | |Value Name | Value | Explanation | |
+-------------+--------------------+------------------------------------+ +-------------+-------------------------+-----------------------------------------|
|t_periodic |Default: 60 secs |Period between Join/Prune Messages | |t_periodic | Default: 60 secs | Period between Join/Prune Messages| |
+-------------+--------------------+------------------------------------+ +-------------+-------------------------+-----------------------------------------|
|t_suppressed |rand(1.1 * |Suppression period when someone | |t_suppressed | rand(1.1 * | | Suppression period when someone| || |
| |t_periodic, 1.4 * |else sends a J/P message so we | | | t_periodic, 1.4 * | | else sends a J/P message so we | || |
| |t_periodic) |don't need to do so. | | | t_periodic) when | | don't need to do so. | || |
+-------------+--------------------+------------------------------------+ | | Suppression_State(I)| | | |
|t_override |rand(0, 0.9 * J/P |Randomized delay to prevent | | | is enabled, 0 | | | |
| |Override Interval) |response implosion when sending a | | | otherwise | | | |
| | |join message to override someone | +-------------+-------------------------+-----------------------------------------|
| | |else's prune message. | |t_override | rand(0, Override | | Randomized delay to prevent response |||
+-------------+--------------------+------------------------------------+ | | Interval) | | implosion when sending a join message |||
| | | to override someone else's prune |||
| | | message. |||
+-------------+-------------------------+-----------------------------------------|
t_periodic may be set to take into account such things as the configured t_periodic may be set to take into account such things as the configured
bandwidth and expected average number of multicast route entries for the bandwidth and expected average number of multicast route entries for the
attached network or link (e.g., the period would be longer for lower- attached network or link (e.g., the period would be longer for lower-
speed links, or for routers in the center of the network that expect to speed links, or for routers in the center of the network that expect to
have a larger number of entries). If the Join/Prune-Period is modified have a larger number of entries). If the Join/Prune-Period is modified
during operation, these changes should be made relatively infrequently during operation, these changes should be made relatively infrequently
and the router should continue to refresh at its previous Join/Prune- and the router should continue to refresh at its previous Join/Prune-
Period for at least Join/Prune-Holdtime, in order to allow the upstream Period for at least Join/Prune-Holdtime, in order to allow the upstream
router to adapt. router to adapt.
0.9 * J/P Override Interval is really an attempt to estimate the true
desired max value of t_override, which is the J/P Override Interval
minus the local network's propagation delay. If the network's
propagation delay is actually known, the value (J/P Override Interval -
propagation delay) may be used instead.
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 |
which may change when Hello messages are received. |
t_suppressed depends on the Suppression State of the upstream interface |
( 4.6.3) and becomes zero when suppression is disabled. |
Timer Name: Upstream Override Timer (OT(S,G,rpt))
+---------------+---------------------------+---------------------------+
| Value Name | Value | Explanation |
+---------------+---------------------------+---------------------------+
| t_override | see Upstream Join Timer | see Upstream Join Timer |
+---------------+---------------------------+---------------------------+
The upstream override timer is only ever set to t_override; this value
is defined in the section on Upstream Join Timers.
Timer Name: KeepAlive Timer (KAT(S,G)) Timer Name: KeepAlive Timer (KAT(S,G))
+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
| Keepalive_Period | Default: 210 secs | Period after last | | Keepalive_Period | Default: 210 secs | Period after last |
| | | (S,G) data packet | | | | (S,G) data packet |
| | | during which (S,G) | | | | during which (S,G) |
| | | Join state will be | | | | Join state will be |
skipping to change at page 114, line 31 skipping to change at page 122, line 5
| | ) + Register Probe | but at the RP when | | | ) + Register Probe | but at the RP when |
| | Time | a RegisterStop is | | | Time | a RegisterStop is |
| | | sent. | | | | sent. |
+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
The normal keepalive period for the KAT(S,G) defaults to 210 seconds. The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
However at the RP, the keepalive period must be at least the However at the RP, the keepalive period must be at least the
Register_Suppression_Time or the RP may time out the (S,G) state before Register_Suppression_Time or the RP may time out the (S,G) state before
the next Null-Register arrives. Thus the KAT(S,G) is set to the next Null-Register arrives. Thus the KAT(S,G) is set to
max(Keepalive_Period, RP_Keepalive_Period). max(Keepalive_Period, RP_Keepalive_Period).
Timer Name: Upstream Override Timer (OT(S,G,rpt))
+------------------+--------------------------+-------------------------+
| Value Name | Value | Explanation |
+------------------+--------------------------+-------------------------+
| t_po | rand(0, 0.9 * | Randomized delay |
| | Join/Prune | to prevent |
| | Override Interval) | response implosion |
| | | when sending a |
| | | join message to |
| | | override someone |
| | | else's prune |
| | | message. |
+------------------+--------------------------+-------------------------+
As with t_override, the network's propagation delay may be used if
known. XXX t_po and t_override seem to be the same thing???
Timer Name: Register Stop Timer (RST(S,G)) Timer Name: Register Stop Timer (RST(S,G))
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
|Value Name |Value | Explanation | |Value Name |Value | Explanation |
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
|Register Suppression Time |Default: 60 seconds | Period during | |Register Suppression Time |Default: 60 seconds | Period during |
| | | which a DR stops | | | | which a DR stops |
| | | sending Register- | | | | sending Register- |
| | | encapsulated data | | | | encapsulated data |
| | | to the RP after | | | | to the RP after |
skipping to change at page 115, line 45 skipping to change at page 122, line 45
packet format was designed only 15 values were assigned for Address packet format was designed only 15 values were assigned for Address
Families, and large numbers of new Address Family values were not Families, and large numbers of new Address Family values were not
envisioned, 8 bits seemed large enough. However, the IANA assigns envisioned, 8 bits seemed large enough. However, the IANA assigns
Address Families in a 16-bit field. Therefore, the PIM Address Family Address Families in a 16-bit field. Therefore, the PIM Address Family
is allocated as follows: is allocated as follows:
Values 0 through 127 are designated to have the same meaning as Values 0 through 127 are designated to have the same meaning as
IANA-assigned Address Family Numbers [5]. IANA-assigned Address Family Numbers [5].
Values 128 through 250 are designated to be assigned by the IANA Values 128 through 250 are designated to be assigned by the IANA
based upon IESG Approval, as defined in [6]. XXX note: is the IESG based upon IESG Approval, as defined in [7].
OK with this?
Values 251 through 255 are designated for Private Use, as defined Values 251 through 255 are designated for Private Use, as defined
in [6]. in [7].
5.2. PIM Hello Options 5.2. PIM Hello Options
Values 17 through 65000 are to be assigned by the IANA. Since the space Values 17 through 65000 are to be assigned by the IANA. Since the space
is large, they may be assigned as First Come First Served as defined in is large, they may be assigned as First Come First Served as defined in
[6]. Such assignments are valid for one year, and may be renewed. [7]. Such assignments are valid for one year, and may be renewed.
Permanent assignments require a specification (see "Specification Permanent assignments require a specification (see "Specification
Required" in [6].) Required" in [7].)
6. Security Considerations 6. Security Considerations
All PIM control messages MAY use IPsec [7] to address security concerns. The IPsec authentication header [8] MAY be used to provide data |
The authentication methods are addressed in a companion document [9]. integrity protection and groupwise data origin authentication of PIM
Keys may be distributed as described in [10]. protocol messages. Authentication of PIM messages can protect against
unwanted behaviors caused by unauthorized or altered PIM messages.
XXX This probably needs more. 6.1. Attacks based on forged messages
The extent of possible damage depends on the type of counterfeit
messages accepted. We next consider the impact of possible forgeries,
including forged link-local (Join/Prune, Hello, and Assert) and forged
unicast (Register and Register-Stop) messages.
6.1.1. Forged link-local messages
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
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
compromised or non-compliant router.
1. A forged Join/Prune message can cause multicast traffic to be
delivered to links where there are no legitimate requestors,
potentially wasting bandwidth on that link. A forged leave message
on a multi-access LAN is generally not a significant attack in PIM,
because any legitimately joined router on the LAN would override
the leave with a join before the upstream router stops forwarding
data to the LAN.
2. By forging a hello message, an unauthorized router can cause
itself to be elected as the designated router on a LAN. The
designated router on a LAN is (in the absence of asserts)
responsible for forwarding traffic to that LAN on behalf of any
local members. The designated router is also responsible for
register-encapsulating to the RP any packets that are originated by
hosts on the LAN. Thus, the ability of local hosts to send and
receive multicast traffic may be compromised by a forged hello
message.
3. By forging an Assert message on a multi-access LAN, an attacker
could cause the legitimate designated forwarder to stop forwarding
traffic to the LAN. Such a forgery would prevent any hosts
downstream of that LAN from receiving traffic.
6.1.2. Forged unicast messages
Register messages and Register-Stop messages are sent by a source and
forwarded by intermediate routers to their destination using normal IP
forwarding. Therefore, without data origin authentication, an attacker
who is located anywhere in the network may be able to forge a Register
or Register-Stop message. The following attacks do not apply to a PIM-
SSM-only implementation, as these messages are not required for PIM-SSM.
We consider the effect of a forgery of each of these messages next.
1 By forging a Register message, an attacker can cause the RP to
inject forged traffic onto the shared multicast tree.
2 By forging a Register-stop message, an attacker can prevent a
legitimate DR from Registering packets to the RP. This can prevent
local hosts on that LAN from sending multicast packets.
The above two PIM messages are not changed by intermediate routers and
need only be examined by the intended receiver. Thus these messages can
be authenticated end-to-end, using AH.
6.2. Non-cryptographic Authentication Mechanisms
A PIM router SHOULD provide an option to limit the set of neighbors from
which it will accept Join/Prune, Assert, and Hello messages. Either
static configuration of IP addresses or an IPsec security association
may be used. Furthermore, a PIM router SHOULD NOT accept protocol
messages from a router from which it has not yet received a valid Hello
message.
A Designated Router MUST NOT register-encapsulate a packet and send it
to the RP unless the source address of the packet is a legal address for
the subnet on which the packet was received. Similarly, a Designated
Router SHOULD NOT accept a Register-Stop packet whose IP source address
is not a valid RP address for the local domain.
An implementation SHOULD provide a mechanism to allow a DR to restrict
the range of source addresses from which it accepts Register-
encapsulated packets.
All options that restrict the range of addresses from which packets are
accepted MUST default to allowing all packets.
6.2.1. Register Nonces
A Register Nonce mechanism MAY be used to provide a limited form of
protection against forged Register Stop messages. In this approach,
each register packet carries a 32-bit nonce which is randomly generated
by the registering DR. A Register-Stop packet is only accepted by the
DR if it carries a nonce that it recently transmitted to the RP. The DR
should periodically change the nonce that it is sending. It is
RECOMMENDED to change the nonce at least every 30 minutes. A DR MUST
keep track of every nonce that it has sent in the last 3.5 * Register
Suppression Time, in order to ensure that it recognizes a nonce used by
the DR.
The nonce is carried as an option in the Register and Register-Stop
messages [xxx details tbd].
This option should only be enabled if the DR has knowledge that the RP
supports the register nonce mechanism. The mechanism for determining
that the RP supports the Register Nonce mechanism is out of the scope of
this document. Implementations that support the Register Nonce MUST
provide (at least) a manual configuration option for it, and the
capability MUST default to off.
6.3. Authentication using IPsec
The IPsec [8] transport mode using the Authentication Header (AH) is the |
recommended method to prevent the above attacks PIM. The anti-replay |
option provided by IPsec SHOULD also be enabled. The specific AH |
authentication algorithm and parameters, including the choice of |
authentication algorithm and the choice of key, are configured by the |
network administrator. The Encapsulating Security Payload (ESP) MAY |
also be used to provide both encryption and authentication of PIM |
protocol messages. When IPsec authentication is used, a PIM router |
should reject (drop without processing) any unauthorized PIM protocol |
messages. |
To use IPsec, the administrator of a PIM network configures each PIM |
router with one or more Security Associations and associated SPI(s) that |
are used by senders to sign PIM protocol messages and are used by |
receivers to authenticate received PIM protocol messages. This document |
does not describe protocols for establishing Security Associations. It |
assumes that manual configuration of Security Associations is performed, |
but it does not preclude the use of some future negotiation protocol to |
establish Security Associations. |
The following sections describe the Security Associations required to |
protect PIM protocol messages. |
6.3.1. Protecting link-local multicast messages |
The network administrator defines a Security Association (SA) and |
Security Parameters Index (SPI) that is to be used to authenticate all |
link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each |
link in a PIM domain. All link-local PIM protocol messages use SPI 0. |
The Security Policy Database at a PIM router should be configured to |
ensure that all incoming and outgoing Join/Prune, Assert, and Hello |
packets use the SA associated with the interface to which the packet is |
sent. |
Note that, according to [8] there is nominally a different Security |
Association Database (SAD) for each router interface. Thus, the |
selected Security Association for an inbound PIM packet can vary |
depending on the interface on which the packet arrived. This fact |
allows the network administrator to use different authentication methods |
for each link, even though the destination address is the same for all |
link-local PIM packets, regardless of interface. |
6.3.2. Protecting unicast messages |
IPSec can also be used to provide data origin authentication and data |
integrity protection for the Register and Register-Stop unicast |
messages. |
6.3.2.1. Register messages |
The Security Policy Database at every PIM router is configured to select |
a Security Association to use when sending PIM Register packets to each |
rendezvous point. |
In the most general mode of operation, the Security Policy Database at |
each DR is configured to select a unique SA and SPI for traffic sent to |
each RP. This allows each DR to have a different authentication |
algorithm and key to talk to the RP. However, this creates a daunting |
key management and distribution problem for the network administrator. |
Therefore, it may be preferable in PIM domains where all Designated |
Routers are under a single administrative control, to use the same |
authentication algorithm parameters (including the key) for all |
Registered packets in a domain, regardless of who is the RP and |
regardless of who is the DR. |
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 |
packets. The Security Policy Database at every DR is configured to |
select a Security Association (including the authentication algorithm, |
authentication parameters, and this SPI) when sending register messages |
to this RP. |
By using a single authentication algorithm and associated parameters, |
the key distribution problem is simplified. Note however, that this |
metohd has the property that, in order to change the authentication |
method or authentication key used, all routers in the domain must be |
updated. |
6.3.2.2. Register Stop messages |
Similarly, the Security Policy Database at each Rendezvous Point should |
be configured to choose a Security Association to use when sending |
Register Stop messages. Because Register Stop messages are unicast to |
the destination DR, a different Security Association and a potentially |
unique SPI is required for each DR. |
[xxx Can we reserve a single SPI at all routers in the domain to |
simplify the configuration problem?] |
In order to simplify the management problem, it may be acceptable to use |
the same authentication algorithm and authentication parameters, |
regardless of the sending RP and regardless of the destination DR. |
Although a unique Security Association is needed for each DR, the same |
authentication algorithm and authentication algorithm parameters (secret |
key) can be shared by all DRs and by all RPs. |
6.4. Denial of Service Attacks |
There are a number of possible denial of service attacks against PIM |
that can be caused by generating false PIM protocol messages or even by |
generating data false traffic. Authenticating PIM protocol traffic |
prevents some, but not all of these attacks. The possible attacks |
include: |
- Sending packets to many different group addresses quickly can be a |
denial of service attack in and of itself. This will cause many |
register-encapsulated packets, loading the DR, the RP, and the |
routers between the DR and the RP. |
- Forging Join messages can cause a multicast tree to get set up. A |
large number of forged joins can consume router resources and |
result in denial of service. |
- [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
skipping to change at page 117, line 7 skipping to change at page 128, line 33
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
kouvelas@cisco.com kouvelas@cisco.com
8. Acknowledgments 8. Acknowledgments
PIM-SM was designed over many years by a large group of people, PIM-SM was designed over many years by a large group of people, |
including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, David including ideas, comments, and corrections from Deborah Estrin, Dino |
Thaler, Steve Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C. |
Tom Pusateri, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott |
Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, | Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly |
Girish Chandranmenon, Brian Haberman, Hal Sandick, and Garry Kump. | Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian |
Haberman, Hal Sandick, Mike Mroz and Garry Kump. |
Thanks are due to the American Licorice Company, for its obscure but Thanks are due to the American Licorice Company, for its obscure but
possibly essential role in the creation of this document. possibly essential role in the creation of this document.
This specification has been blessed by St. Isidor.
9. References 9. References
[1] T. Bates , R. Chandra , D. Katz , Y. Rekhter, "Multiprotocol [1] T. Bates , R. Chandra , D. Katz , Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2283 Extensions for BGP-4", RFC 2283
[2] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug [2] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug
1989. 1989.
[3] W. Fenner, "Internet Group Management Protocol, Version 2", RFC [3] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
2236. 2236.
[4] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Bootstrap Router | [4] 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-00.txt,
work in progress. | work in progress.
[5] IANA, "Address Family Numbers", linked from | [5] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
[6] T. Narten , H. Alvestrand, "Guidelines for Writing an IANA [6] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
Protocol Independent Multicast", draft-ietf-pim-bidir-02.txt, work
in progress.
[7] T. Narten , H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434. Considerations Section in RFCs", RFC 2434.
[7] S. Kent, R. Atkinson, "Security Architecture for the Internet [8] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.", RFC 2401. Protocol.", RFC 2401.
[8] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) [9] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460. Specification", RFC 2460.
[9] L. Wei, "Authenticating PIM version 2 messages", draft-ietf-pim- [10] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft-
v2-auth-01.txt, work in progress.
[10] T. Hardjono, B. Cain, "Simple Key Management Protocol for PIM",
draft-ietf-pim-simplekmp-01.txt, work in progress.
[11] 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] D. Black, "Differentiated Services and Tunnels", RFC 2983.
10. Index 10. Index
AssertCancel(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 80 AssertCancel(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 82
AssertTimer(*,G,I) . . . . . . . . . . . . . . . . . . . . .15,22,74,112 AssertTimer(*,G,I) . . . . . . . . . . . . . . . . . . . . .15,22,77,119
AssertTimer(S,G,I) . . . . . . . . . . . . . . . . . . . . .16,22,68,112 AssertTimer(S,G,I) . . . . . . . . . . . . . . . . . . . . .17,22,70,119
AssertTrackingDesired(*,G,I) . . . . . . . . . . . . . . . . . . . . 77 AssertTrackingDesired(*,G,I) . . . . . . . . . . . . . . . . . . . . 79
AssertTrackingDesired(S,G,I) . . . . . . . . . . . . . . . . . . . . 70 AssertTrackingDesired(S,G,I) . . . . . . . . . . . . . . . . . . . . 72
AssertWinner(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . 20,22 AssertWinner(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . 20,22
AssertWinner(S,G,I). . . . . . . . . . . . . . . . . . . . . . .20,22,82 AssertWinner(S,G,I). . . . . . . . . . . . . . . . . . . . . 20,22,76,84
assert_metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 AssertWinnerMetric(S,G,I). . . . . . . . . . . . . . . . . . . . . . 76
Assert_Override_Interval . . . . . . . . . . . . . . . . . . . 73,80,112 assert_metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Assert_Time. . . . . . . . . . . . . . . . . . . . . . . . . . 73,80,112 Assert_Override_Interval . . . . . . . . . . . . . . . . . . . 76,82,119
AT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . . .15,22,74,112 Assert_Time. . . . . . . . . . . . . . . . . . . . . . . . . . 76,82,119
AT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . . . .16,22,68,112 AT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . . .15,22,77,119
CouldAssert(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . 77 AT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . . . .17,22,70,119
CouldAssert(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . 70,70 CheckSwitchToSpt(S,G). . . . . . . . . . . . . . . . . . . . . . . . 26
CouldRegister(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 29 CouldAssert(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . 79
DirectlyConnected(S) . . . . . . . . . . . . . . . . . . . . . .24,25,29 CouldAssert(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . 72
DownstreamJPState(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . 20 CouldRegister(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 30
DirectlyConnected(S) . . . . . . . . . . . . . . . . . . . . . .25,27,30
DownstreamJPState(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . 21
DownstreamJPState(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 21 DownstreamJPState(*,G,I) . . . . . . . . . . . . . . . . . . . . . . 21
DownstreamJPState(S,G,I) . . . . . . . . . . . . . . . . . . . . . . 21 DownstreamJPState(S,G,I) . . . . . . . . . . . . . . . . . . . . . . 21
DR(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 DownstreamJPState(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . 21
dr_is_better(a,b,I). . . . . . . . . . . . . . . . . . . . . . . . . 87 DR(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
ET(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . . . . . 14,32,111 dr_is_better(a,b,I). . . . . . . . . . . . . . . . . . . . . . . . . 89
ET(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 15,36,111 ET(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . . . . . 14,34,118
ET(S,G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 16,40,111 ET(*,G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 15,38,118
ET(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . . . . . . 18,44,111 ET(S,G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 16,42,118
Hash_Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 ET(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . . . . . . 18,45,118
Hello_Holdtime . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Hash_Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Hello_Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Hello_Holdtime . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
HT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Hello_Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
immediate_olist(*,*,RP). . . . . . . . . . . . . . . . . . . . . . 19,51 HT(I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87,117
immediate_olist(*,G) . . . . . . . . . . . . . . . . . . . . . . . 19,54 immediate_olist(*,*,RP). . . . . . . . . . . . . . . . . . . . . . 19,53
immediate_olist(S,G) . . . . . . . . . . . . . . . . . . . . . .19,59,81 immediate_olist(*,G) . . . . . . . . . . . . . . . . . . . . . . . 20,56
infinite_assert_metric() . . . . . . . . . . . . . . . . . . . . . . 82 immediate_olist(S,G) . . . . . . . . . . . . . . . . . . . . . .20,61,83
inherited_olist(S,G) . . . . . . . . . . . . . . . . . . .20,24,30,59,70 infinite_assert_metric() . . . . . . . . . . . . . . . . . . . . . . 84
inherited_olist(S,G,rpt) . . . . . . . . . . . . . .20,24,25,63,65,67,81 inherited_olist(S,G) . . . . . . . . . . . . . . . . . . .20,25,32,61,72
I_am_DR(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20,29 inherited_olist(S,G,rpt) . . . . . . . . . . . . . .20,25,27,65,67,69,83
I_am_RP(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 I_am_DR(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20,30
J/P_HoldTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 I_am_RP(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
J/P_Override_Interval. . . . . . . . . . . . . . . . . . 34,38,42,46,112 J/P_HoldTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
J/P_Override_Interval. . . . . . . . . . . . . . . . 36,40,43,48,103,118
Join(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Join(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
join(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 JoinDesired(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 53,67
JoinDesired(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 51,64 JoinDesired(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 56,67
JoinDesired(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 54,64 JoinDesired(S,G) . . . . . . . . . . . . . . . . . . . . . . . .27,61,72
JoinDesired(S,G) . . . . . . . . . . . . . . . . . . . . . . . .25,59,70 joins(*,*,RP(G)) . . . . . . . . . . . . . . . . . . . . . . . . . . 72
joins(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . . . . 20,77
joins(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . . .21,70,77
joins(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
JT(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . . . . . 14,49,113 joins(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . . 21,72,72,79
JT(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . 15,53,113 joins(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 21,72,72,79
JT(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . 17,58,113 joins(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21,72
KAT(S,G) . . . . . . . . . . . . . . . . . . . . . . .17,24,29,30,59,113 JT(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . . . . . 14,51,119
KeepaliveTimer(S,G). . . . . . . . . . . . . . . . . .17,24,29,30,59,113 JT(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . 15,55,119
Keepalive_Period . . . . . . . . . . . . . . . . . . . . . . . . . . 113 JT(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . 17,60,119
KAT(S,G) . . . . . . . . . . . . . . . . . . . . . . .17,25,30,32,61,120
KeepaliveTimer(S,G). . . . . . . . . . . . . . . . . .17,25,30,32,61,120
Keepalive_Period . . . . . . . . . . . . . . . . . . . . . . . . . . 120
lan_delay_enabled(I) . . . . . . . . . . . . . . . . . . . . . . . . 90
local_receiver_exclude(S,G,I). . . . . . . . . . . . . . . . . . . . 20 local_receiver_exclude(S,G,I). . . . . . . . . . . . . . . . . . . . 20
local_receiver_include(*,G,I). . . . . . . . . . . . . . . . . . . . 20 local_receiver_include(*,G,I). . . . . . . . . . . . . . . . . . . . 20
local_receiver_include(S,G,I). . . . . . . . . . . . . . . . . . . . 20 local_receiver_include(S,G,I). . . . . . . . . . . . . . . . . . . . 20
lost_assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . . 21 lost_assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . .22,72,72
lost_assert(*,G,I) . . . . . . . . . . . . . . . . . . . . . 20,21,70,83 lost_assert(*,G,I) . . . . . . . . . . . . . . . . . . . . . . .20,22,85
lost_assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . 22 lost_assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . 22
lost_assert(S,G,I) . . . . . . . . . . . . . . . . . . . . . . .20,22,83 lost_assert(S,G,I) . . . . . . . . . . . . . . . . . . . . . . .20,22,85
lost_assert(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . . . 22 lost_assert(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . . . 22
lost_assert(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . . . 22,82 lost_assert(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . . . 22,84
MBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 MBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
MRIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 MRIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
MRIB.next_hop(host). . . . . . . . . . . . . . . . . . . . . . . . . 22 MRIB.next_hop(host). . . . . . . . . . . . . . . . . . . . . . . . . 22
my_assert_metric(S,G,I). . . . . . . . . . . . . . . . . . . . . . . 81 my_assert_metric(S,G,I). . . . . . . . . . . . . . . . . . . . . . . 83
NLT(N,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13,111 NLT(N,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13,117
OT(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . . . . .18,114 OT(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . . . . .18,120
packet_arrives_on_rp_tunnel(pkt) . . . . . . . . . . . . . . . . . . 30 Override_Interval. . . . . . . . . . . . . . . . . . . . . . . . . . 116
pim_exclude(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Override_Interval(I) . . . . . . . . . . . . . . . . . . . . . . . . 92
pim_exclude(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . 70 packet_arrives_on_rp_tunnel(pkt) . . . . . . . . . . . . . . . . . . 32
pim_include(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . 20,77 pim_exclude(S,G) . . . . . . . . . . . . . . . . . . . . . . . .20,72,72
pim_include(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . 70 pim_include(*,G) . . . . . . . . . . . . . . . . . . . . . . 20,72,72,79
pim_include(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 20,70 pim_include(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . 20,72
PPT(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . . . . 14,32,112 PPT(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . . . . 14,34,118
PPT(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . 15,36,112 PPT(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . 15,38,118
PPT(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . 16,40,112 PPT(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . 16,42,118
PPT(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . . . . . 18,44,112 PPT(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . . . . . . 18,45,118
PruneDesired(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . 65,66 Propagation_Delay. . . . . . . . . . . . . . . . . . . . . . . . . . 116
prunes(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . . . 21,70 Propagation_Delay(I) . . . . . . . . . . . . . . . . . . . . . . . . 91
PruneDesired(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . 67,69
prunes(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . .21,72,72
RegisterStop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 RegisterStop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
RegisterStop(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 29 RegisterStop(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . 31
RegisterStop(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . 30 RegisterStop(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . 32
RegisterStop_timer . . . . . . . . . . . . . . . . . . . . . . . . . 27 RegisterStop_timer . . . . . . . . . . . . . . . . . . . . . . . . . 29
Register_Probe_Time. . . . . . . . . . . . . . . . . . . . . . 28,31,115 Register_Probe_Time. . . . . . . . . . . . . . . . . . . . . . 30,33,122
Register_Suppression_Time. . . . . . . . . . . . . . . . . 28,31,114,115 Register_Suppression_Time. . . . . . . . . . . . . . . . . 30,33,121,122
RP(G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22,77,77 RP(G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22,79,79
RPF'(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .22,25,63 RPF'(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .22,27,65
RPF'(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .22,25,63 RPF'(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .23,27,65
RPF'(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . . .22,63,65
RPF_interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
RPF_interface(host). . . . . . . . . . . . . . . . .22,24,25,29,70,77,82
RPTJoinDesired(G). . . . . . . . . . . . . . . . . . . . . . . .64,67,77
rpt_assert_metric(G,I) . . . . . . . . . . . . . . . . . . . . . . . 81
RST(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27,115
SPTbit(S,G). . . . . . . . . . . . . . . . . . . . . . . .24,25,30,63,81 RPF'(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . . . .22,65,67
spt_assert_metric(S,I) . . . . . . . . . . . . . . . . . . . . . . . 81 RPF_interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
SSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 RPF_interface(host). . . . . . . . . . . . . . . . .22,25,27,30,72,79,84
Triggered_Hello_Delay. . . . . . . . . . . . . . . . . . . . . . . . 111 RPTJoinDesired(G). . . . . . . . . . . . . . . . . . . . . . . .67,69,79
t_override . . . . . . . . . . . . . . . . . . . . . . . . . . 50,54,113 rpt_assert_metric(G,I) . . . . . . . . . . . . . . . . . . . . . . . 83
t_periodic . . . . . . . . . . . . . . . . . . . . . . . . . . 50,54,113 RST(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29,122
t_po . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64,114 SPTbit(S,G). . . . . . . . . . . . . . . . . . . . .25,27,32,65,72,72,83
t_suppressed . . . . . . . . . . . . . . . . . . . . . . . . . 50,54,113 spt_assert_metric(S,I) . . . . . . . . . . . . . . . . . . . . . . 76,83
Update_SPTbit(S,G,iif) . . . . . . . . . . . . . . . . . . . . . . . 25 SSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
UpstreamJPState(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 24 Suppression_State(I) . . . . . . . . . . . . . . . . . . . . . . . . 92
SwitchToSptDesired(S,G). . . . . . . . . . . . . . . . . . . . . . . 26
Triggered_Hello_Delay. . . . . . . . . . . . . . . . . . . . . . . . 117
t_override . . . . . . . . . . . . . . . . . . . . . . . . . . 52,56,119
t_periodic . . . . . . . . . . . . . . . . . . . . . . . . . . 52,56,119
t_po . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66,120
t_suppressed . . . . . . . . . . . . . . . . . . . . . . . . . 52,56,119
Update_SPTbit(S,G,iif) . . . . . . . . . . . . . . . . . . . . . . . 27
UpstreamJPState(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 25
 End of changes. 

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