draft-ietf-pim-sm-v2-new-09.txt   draft-ietf-pim-sm-v2-new-10.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-09.txt Mark Handley/ICIR draft-ietf-pim-sm-v2-new-10.txt Mark Handley/UCL
Hugh Holbrook/Cisco Hugh Holbrook/Cisco
Isidor Kouvelas/Cisco Isidor Kouvelas/Cisco
16 February 2004 18 July 2004
Expires: August 2004 Expires: January 2005
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised) Protocol Specification (Revised)
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all By submitting this Internet-Draft, I certify that any applicable patent
provisions of Section 10 of RFC2026. or other IPR claims of which I am aware have been disclosed, or will be
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the IETF PIM WG. Comments should be This document is a product of the IETF PIM WG. Comments should be
addressed to the authors, or the WG's mailing list at addressed to the authors, or the mailing list at pim@ietf.org.
pim@catarina.usc.edu.
Abstract Abstract
This document specifies Protocol Independent Multicast - This document specifies Protocol Independent Multicast -
Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol
that can use the underlying unicast routing information base that can use the underlying unicast routing information base
or a separate multicast-capable routing information base. It or a separate multicast-capable routing information base. It
builds unidirectional shared trees rooted at a Rendezvous builds unidirectional shared trees rooted at a Rendezvous
Point (RP) per group, and optionally creates shortest-path Point (RP) per group, and optionally creates shortest-path
trees per source. trees per source.
Table of Contents Table of Contents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . 7 2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . 7
3. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . 8 3. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . 8
4. Protocol Specification. . . . . . . . . . . . . . . . . 13 4. Protocol Specification. . . . . . . . . . . . . . . . . 13
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . 13 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . 13
4.1.1. General Purpose State . . . . . . . . . . . . . . 14 4.1.1. General Purpose State . . . . . . . . . . . . . . 14
4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . 15 4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . 15
4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . 16 4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . 16
4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . 18 4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . 18
4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . 20 4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . 20
4.1.6. State Summarization Macros. . . . . . . . . . . . 21 4.1.6. State Summarization Macros. . . . . . . . . . . . 21
4.2. Data Packet Forwarding Rules . . . . . . . . . . . . 25 4.2. Data Packet Forwarding Rules . . . . . . . . . . . . 26
4.2.1. Last-hop switchover to the SPT. . . . . . . . . . 28 4.2.1. Last-hop Switchover to the SPT. . . . . . . . . . 28
4.2.2. Setting and Clearing the (S,G) SPT bit. . . . . . 28 4.2.2. Setting and Clearing the (S,G) SPT bit. . . . . . 28
4.3. Designated Routers (DR) and Hello Messages . . . . . 30 4.3. Designated Routers (DR) and Hello Messages . . . . . 30
4.3.1. Sending Hello Messages. . . . . . . . . . . . . . 30 4.3.1. Sending Hello Messages. . . . . . . . . . . . . . 30
4.3.2. DR Election . . . . . . . . . . . . . . . . . . . 32 4.3.2. DR Election . . . . . . . . . . . . . . . . . . . 32
4.3.3. Reducing Prune Propagation Delay on LANs. . . . . 34 4.3.3. Reducing Prune Propagation Delay on LANs. . . . . 34
4.3.4. Maintaining Secondary Address Lists . . . . . . . 36 4.3.4. Maintaining Secondary Address Lists . . . . . . . 36
4.4. PIM Register Messages. . . . . . . . . . . . . . . . 37 4.4. PIM Register Messages. . . . . . . . . . . . . . . . 37
4.4.1. Sending Register Messages from the DR . . . . . . 38 4.4.1. Sending Register Messages from the DR . . . . . . 38
4.4.2. Receiving Register Messages at the RP . . . . . . 42 4.4.2. Receiving Register Messages at the RP . . . . . . 42
4.5. PIM Join/Prune Messages. . . . . . . . . . . . . . . 44 4.5. PIM Join/Prune Messages. . . . . . . . . . . . . . . 44
4.5.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . 45 4.5.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . 45
4.5.2. Receiving (*,G) Join/Prune Messages . . . . . . . 48 4.5.2. Receiving (*,G) Join/Prune Messages . . . . . . . 49
4.5.3. Receiving (S,G) Join/Prune Messages . . . . . . . 52 4.5.3. Receiving (S,G) Join/Prune Messages . . . . . . . 52
4.5.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . 55 4.5.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . 55
4.5.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . 61 4.5.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . 61
4.5.6. Sending (*,G) Join/Prune Messages . . . . . . . . 65 4.5.6. Sending (*,G) Join/Prune Messages . . . . . . . . 65
4.5.7. Sending (S,G) Join/Prune Messages . . . . . . . . 70 4.5.7. Sending (S,G) Join/Prune Messages . . . . . . . . 70
4.5.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . 75 4.5.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . 75
4.5.9. State Machine for (S,G,rpt) Triggered Mes- 4.5.9. State Machine for (S,G,rpt) Triggered
sages. . . . . . . . . . . . . . . . . . . . . . . . . . 76 Messages. . . . . . . . . . . . . . . . . . . . . 76
4.5.10. Background: (*,*,RP) and (S,G,rpt) inter- 4.5.10. Background: (*,*,RP) and (S,G,rpt)
action . . . . . . . . . . . . . . . . . . . . . . . . . 80 Interaction. . . . . . . . . . . . . . . . . . . 80
4.6. PIM Assert Messages. . . . . . . . . . . . . . . . . 82 4.6. PIM Assert Messages. . . . . . . . . . . . . . . . . 82
4.6.1. (S,G) Assert Message State Machine. . . . . . . . 82 4.6.1. (S,G) Assert Message State Machine. . . . . . . . 82
4.6.2. (*,G) Assert Message State Machine. . . . . . . . 90 4.6.2. (*,G) Assert Message State Machine. . . . . . . . 90
4.6.3. Assert Metrics. . . . . . . . . . . . . . . . . . 97 4.6.3. Assert Metrics. . . . . . . . . . . . . . . . . . 97
4.6.4. AssertCancel Messages . . . . . . . . . . . . . . 98 4.6.4. AssertCancel Messages . . . . . . . . . . . . . . 98
4.6.5. Assert State Macros . . . . . . . . . . . . . . . 99 4.6.5. Assert State Macros . . . . . . . . . . . . . . . 99
4.7. PIM Multicast Border Router Behavior . . . . . . . . 102 4.7. PIM Bootstrap and RP Discovery . . . . . . . . . . . 102
4.7.1. Sources External to the PIM-SM Domain . . . . . . 103 4.7.1. Group-to-RP Mapping . . . . . . . . . . . . . . . 103
4.7.2. Sources Internal to the PIM-SM Domain . . . . . . 103 4.7.2. Hash Function . . . . . . . . . . . . . . . . . . 104
4.8. PIM Bootstrap and RP Discovery . . . . . . . . . . . 105 4.8. Source-Specific Multicast. . . . . . . . . . . . . . 105
4.8.1. Group-to-RP Mapping . . . . . . . . . . . . . . . 106 4.8.1. Protocol Modifications for SSM destination
4.8.2. Hash Function . . . . . . . . . . . . . . . . . . 107 addresses . . . . . . . . . . . . . . . . . . . . 105
4.9. Source-Specific Multicast. . . . . . . . . . . . . . 108 4.8.2. PIM-SSM-only Routers. . . . . . . . . . . . . . . 106
4.9.1. Protocol Modifications for SSM destination 4.9. PIM Packet Formats . . . . . . . . . . . . . . . . . 107
addresses. . . . . . . . . . . . . . . . . . . . . . . . 108 4.9.1. Encoded Source and Group Address Formats. . . . . 109
4.9.2. PIM-SSM-only Routers. . . . . . . . . . . . . . . 109 4.9.2. Hello Message Format. . . . . . . . . . . . . . . 112
4.10. PIM Packet Formats. . . . . . . . . . . . . . . . . 110 4.9.3. Register Message Format . . . . . . . . . . . . . 115
4.10.1. Encoded Source and Group Address 4.9.4. Register-Stop Message Format. . . . . . . . . . . 117
Formats. . . . . . . . . . . . . . . . . . . . . . . . . 111 4.9.5. Join/Prune Message Format . . . . . . . . . . . . 118
4.10.2. Hello Message Format . . . . . . . . . . . . . . 115 4.9.5.1. Group Set Source List Rules. . . . . . . . . . 121
4.10.3. Register Message Format. . . . . . . . . . . . . 118 4.9.5.2. Group Set Fragmentation. . . . . . . . . . . . 125
4.10.4. Register-Stop Message Format . . . . . . . . . . 120 4.9.6. Assert Message Format . . . . . . . . . . . . . . 125
4.10.5. Join/Prune Message Format. . . . . . . . . . . . 121 4.10. PIM Timers. . . . . . . . . . . . . . . . . . . . . 127
4.10.5.1. Group Set Source List Rules . . . . . . . . . 124 4.11. Timer Values. . . . . . . . . . . . . . . . . . . . 128
4.10.5.2. Group Set Fragmentation . . . . . . . . . . . 128 5. IANA Considerations . . . . . . . . . . . . . . . . . . 134
4.10.6. Assert Message Format. . . . . . . . . . . . . . 128 5.1. PIM Address Family . . . . . . . . . . . . . . . . . 134
4.11. PIM Timers. . . . . . . . . . . . . . . . . . . . . 130 5.2. PIM Hello Options. . . . . . . . . . . . . . . . . . 135
4.12. Timer Values. . . . . . . . . . . . . . . . . . . . 131 6. Security Considerations . . . . . . . . . . . . . . . . 135
5. IANA Considerations . . . . . . . . . . . . . . . . . . 137 6.1. Attacks based on forged messages . . . . . . . . . . 135
5.1. PIM Address Family . . . . . . . . . . . . . . . . . 137 6.1.1. Forged link-local messages. . . . . . . . . . . . 135
5.2. PIM Hello Options. . . . . . . . . . . . . . . . . . 138 6.1.2. Forged unicast messages . . . . . . . . . . . . . 136
6. Security Considerations . . . . . . . . . . . . . . . . 138 6.2. Non-cryptographic Authentication Mechanisms. . . . . 136
6.1. Attacks based on forged messages . . . . . . . . . . 138 6.3. Authentication using IPsec . . . . . . . . . . . . . 137
6.1.1. Forged link-local messages. . . . . . . . . . . . 138 6.3.1. Protecting link-local multicast messages. . . . . 137
6.1.2. Forged unicast messages . . . . . . . . . . . . . 139 6.3.2. Protecting unicast messages . . . . . . . . . . . 138
6.2. Non-cryptographic Authentication Mechanisms. . . . . 139 6.3.2.1. Register messages. . . . . . . . . . . . . . . 138
6.3. Authentication using IPsec . . . . . . . . . . . . . 140 6.3.2.2. Register-Stop messages . . . . . . . . . . . . 138
6.3.1. Protecting link-local multicast messages. . . . . 140 6.4. Denial of Service Attacks. . . . . . . . . . . . . . 139
6.3.2. Protecting unicast messages . . . . . . . . . . . 141 7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 139
6.3.2.1. Register messages. . . . . . . . . . . . . . . 141 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 140
6.3.2.2. Register-Stop messages . . . . . . . . . . . . 141 9. Normative References. . . . . . . . . . . . . . . . . . 140
6.4. Denial of Service Attacks. . . . . . . . . . . . . . 142 10. Informative References . . . . . . . . . . . . . . . . 141
7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 142 11. Appendix A: PIM Multicast Border Router
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 143 Behavior . . . . . . . . . . . . . . . . . . . . . . . 142
9. Normative References. . . . . . . . . . . . . . . . . . 143 11.1. Sources External to the PIM-SM Domain . . . . . . . 142
10. Informative References . . . . . . . . . . . . . . . . 144 11.2. Sources Internal to the PIM-SM Domain . . . . . . . 143
11. Index. . . . . . . . . . . . . . . . . . . . . . . . . 145 12. Index. . . . . . . . . . . . . . . . . . . . . . . . . 145
13. Full Copyright Statement . . . . . . . . . . . . . . . 148
List of Figures List of Figures
Figure 1. Per-(S,G) register state-machine at a DR . . . . 38 Figure 1. Per-(S,G) register state machine at a DR . . . . 38
Figure 2. Downstream per-interface (*,*,RP) state- Figure 2. Downstream per-interface (*,*,RP) state
machine. . . . . . . . . . . . . . . . . . . . . . . . . . 46 machine. . . . . . . . . . . . . . . . . . . . . 46
Figure 3. Downstream per-interface (*,G) state- Figure 3. Downstream per-interface (*,G) state
machine. . . . . . . . . . . . . . . . . . . . . . . . . . 49 machine. . . . . . . . . . . . . . . . . . . . . 49
Figure 4. Downstream per-interface (S,G) state- Figure 4. Downstream per-interface (S,G) state
machine. . . . . . . . . . . . . . . . . . . . . . . . . . 53 machine. . . . . . . . . . . . . . . . . . . . . 53
Figure 5. Downstream per-interface (S,G,rpt) state- Figure 5. Downstream per-interface (S,G,rpt) state
machine. . . . . . . . . . . . . . . . . . . . . . . . . . 56 machine. . . . . . . . . . . . . . . . . . . . . 56
Figure 6. Upstream (*,*,RP) state-machine. . . . . . . . . 61 Figure 6. Upstream (*,*,RP) state machine. . . . . . . . . 61
Figure 7. Upstream (*,G) state-machine . . . . . . . . . . 66 Figure 7. Upstream (*,G) state machine . . . . . . . . . . 66
Figure 8. Upstream (S,G) state-machine . . . . . . . . . . 71 Figure 8. Upstream (S,G) state machine . . . . . . . . . . 71
Figure 9. Upstream (S,G,rpt) state-machine for trig- Figure 9. Upstream (S,G,rpt) state machine for
gered messages . . . . . . . . . . . . . . . . . . . . . . 76 triggered messages . . . . . . . . . . . . . . . 76
Figure 10. Per-interface (S,G) Assert Figure 10. Per-interface (S,G) Assert State
State-machine. . . . . . . . . . . . . . . . . . . . . . . 83 machine . . . . . . . . . . . . . . . . . . . . 83
Figure 11. Per-interface (*,G) Assert Figure 11. Per-interface (*,G) Assert State
State-machine. . . . . . . . . . . . . . . . . . . . . . . 91 machine . . . . . . . . . . . . . . . . . . . . 91
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 6, line 46 skipping to change at page 6, line 46
Rendezvous Point (RP): Rendezvous Point (RP):
An RP is a router that has been configured to be used as the root An RP is a router that has been configured to be used as the root
of the non-source-specific distribution tree for a multicast of the non-source-specific distribution tree for a multicast
group. Join messages from receivers for a group are sent towards group. Join messages from receivers for a group are sent towards
the RP, and data from senders is sent to the RP so that receivers the RP, and data from senders is sent to the RP so that receivers
can discover who the senders are, and start to receive traffic can discover who the senders are, and start to receive traffic
destined for the group. destined for the group.
Designated Router (DR): Designated Router (DR):
A shared-media LAN like Ethernet may have multiple PIM-SM routers A shared-media LAN like Ethernet may have multiple PIM-SM routers |
connected to it. If the LAN has directly connected hosts, then a connected to it. A single one of these routers, the DR, will act |
single one of these routers, the DR, will act on behalf of those on behalf of directly connected hosts with respect to the PIM-SM |
hosts with respect to the PIM-SM protocol. A single DR is elected protocol. A single DR is elected per interface (LAN or otherwise) |
per interface (LAN or otherwise) using a simple election process. using a simple election process.
MRIB Multicast Routing Information Base. This is the multicast MRIB Multicast Routing Information Base. This is the multicast
topology table, which is typically derived from the unicast topology table, which is typically derived from the unicast
routing table, or routing protocols such as MBGP that carry routing table, or routing protocols such as MBGP that carry
multicast-specific topology information. In PIM-SM, the MRIB is multicast-specific topology information. In PIM-SM, the MRIB is
used to decide where to send Join/Prune messages. A secondary used to decide where to send Join/Prune messages. A secondary
function of the MRIB is to provide routing metrics for destination function of the MRIB is to provide routing metrics for destination
addresses, these metrics are used when sending and processing addresses, these metrics are used when sending and processing
Assert messages. Assert messages.
skipping to change at page 8, line 28 skipping to change at page 8, line 28
3. PIM-SM Protocol Overview 3. PIM-SM Protocol Overview
This section provides an overview of PIM-SM behavior. It is intended as This section provides an overview of PIM-SM behavior. It is intended as
an introduction to how PIM-SM works, and is NOT definitive. For the an introduction to how PIM-SM works, and is NOT definitive. For the
definitive specification, see Section 4. definitive specification, see Section 4.
PIM relies on an underlying topology-gathering protocol to populate a PIM relies on an underlying topology-gathering protocol to populate a
routing table with routes. This routing table is called the MRIB or routing table with routes. This routing table is called the MRIB or
Multicast Routing Information Base. The routes in this table may be Multicast Routing Information Base. The routes in this table may be
taken directly from the unicast routing table, or it may be different taken directly from the unicast routing table, or it may be different
and provided by a separate routing protocol such as MBGP [12]. and provided by a separate routing protocol such as MBGP [9]. Regardless
Regardless of how it is created, the primary role of the MRIB in the PIM of how it is created, the primary role of the MRIB in the PIM protocol
protocol is to provide the next hop router along a multicast-capable is to provide the next hop router along a multicast-capable path to each
path to each destination subnet. The MRIB is used to determine the next destination subnet. The MRIB is used to determine the next hop neighbor
hop neighbor to which any PIM Join/Prune message is sent. Data flows to which any PIM Join/Prune message is sent. Data flows along the
along the reverse path of the Join messages. Thus, in contrast to the reverse path of the Join messages. Thus, in contrast to the unicast RIB
unicast RIB which specifies the next hop that a data packet would take which specifies the next hop that a data packet would take to get to
to get to some subnet, the MRIB gives reverse-path information, and some subnet, the MRIB gives reverse-path information, and indicates the
indicates the path that a multicast data packet would take from its path that a multicast data packet would take from its origin subnet to
origin subnet to the router that has the MRIB. the router that has the MRIB.
Like all multicast routing protocols that implement the service model Like all multicast routing protocols that implement the service model
from RFC 1112 [2], PIM-SM must be able to route data packets from from RFC 1112 [2], PIM-SM must be able to route data packets from
sources to receivers without either the sources or receivers knowing a- sources to receivers without either the sources or receivers knowing a-
priori of the existence of the others. This is essentially done in priori of the existence of the others. This is essentially done in
three phases, although as senders and receivers may come and go at any three phases, although as senders and receivers may come and go at any
time, all three phases may be occur simultaneously. time, all three phases may be occur simultaneously.
Phase One: RP Tree Phase One: RP Tree
In phase one, a multicast receiver expresses its interest in receiving In phase one, a multicast receiver expresses its interest in receiving
traffic destined for a multicast group. Typically it does this using traffic destined for a multicast group. Typically it does this using
IGMP [5] or MLD [3], but other mechanisms might also serve this purpose. IGMP [1] or MLD [3], but other mechanisms might also serve this purpose.
One of the receiver's local routers is elected as the Designated Router One of the receiver's local routers is elected as the Designated Router
(DR) for that subnet. On receiving the receiver's expression of (DR) for that subnet. On receiving the receiver's expression of
interest, the DR then sends a PIM Join message towards the RP for that interest, the DR then sends a PIM Join message towards the RP for that
multicast group. This Join message is known as a (*,G) Join because it multicast group. This Join message is known as a (*,G) Join because it
joins group G for all sources to that group. The (*,G) Join travels joins group G for all sources to that group. The (*,G) Join travels
hop-by-hop towards the RP for the group, and in each router it passes hop-by-hop towards the RP for the group, and in each router it passes
through, multicast tree state for group G is instantiated. Eventually through, multicast tree state for group G is instantiated. Eventually
the (*,G) Join either reaches the RP, or reaches a router that already the (*,G) Join either reaches the RP, or reaches a router that already
has (*,G) Join state for that group. When many receivers join the has (*,G) Join state for that group. When many receivers join the
skipping to change at page 9, line 46 skipping to change at page 9, line 46
Phase Two: Register-Stop Phase Two: Register-Stop
Register-encapsulation of data packets is inefficient for two reasons: Register-encapsulation of data packets is inefficient for two reasons:
o Encapsulation and decapsulation may be relatively expensive operations o Encapsulation and decapsulation may be relatively expensive operations
for a router to perform, depending on whether or not the router has for a router to perform, depending on whether or not the router has
appropriate hardware for these tasks. appropriate hardware for these tasks.
o Traveling all the way to the RP, and then back down the shared tree o Traveling all the way to the RP, and then back down the shared tree
may entail the packets traveling a relatively long distance to reach may entail the packets traveling a relatively long distance to reach
receivers that are close to the sender. For some applications, this receivers that are close to the sender. For some applications, this |
increased latency is undesirable. increased latency or bandwidth consumption is undesirable.
Although Register-encapsulation may continue indefinitely, for these Although Register-encapsulation may continue indefinitely, for these
reasons, the RP will normally choose to switch to native forwarding. To reasons, the RP will normally choose to switch to native forwarding. To
do this, when the RP receives a register-encapsulated data packet from do this, when the RP receives a register-encapsulated data packet from
source S on group G, it will normally initiate an (S,G) source-specific source S on group G, it will normally initiate an (S,G) source-specific
Join towards S. This Join message travels hop-by-hop towards S, Join towards S. This Join message travels hop-by-hop towards S,
instantiating (S,G) multicast tree state in the routers along the path. instantiating (S,G) multicast tree state in the routers along the path.
(S,G) multicast tree state is used only to forward packets for group G (S,G) multicast tree state is used only to forward packets for group G
if those packets come from source S. Eventually the Join message if those packets come from source S. Eventually the Join message
skipping to change at page 10, line 42 skipping to change at page 10, line 42
shared tree to the receiver is built. shared tree to the receiver is built.
Phase 3: Shortest-Path Tree Phase 3: Shortest-Path Tree
Although having the RP join back towards the source removes the Although having the RP join back towards the source removes the
encapsulation overhead, it does not completely optimize the forwarding encapsulation overhead, it does not completely optimize the forwarding
paths. For many receivers the route via the RP may involve a paths. For many receivers the route via the RP may involve a
significant detour when compared with the shortest path from the source significant detour when compared with the shortest path from the source
to the receiver. to the receiver.
To obtain lower latencies, a router on the receiver's LAN, typically the To obtain lower latencies or more efficient bandwidth utilisation, a |
DR, may optionally initiate a transfer from the shared tree to a source- router on the receiver's LAN, typically the DR, may optionally initiate
specific shortest-path tree (SPT). To do this, it issues an (S,G) Join a transfer from the shared tree to a source-specific shortest-path tree
towards S. This instantiates state in the routers along the path to S. (SPT). To do this, it issues an (S,G) Join towards S. This instantiates
Eventually this join either reaches S's subnet, or reaches a router that state in the routers along the path to S. Eventually this join either
already has (S,G) state. When this happens, data packets from S start reaches S's subnet, or reaches a router that already has (S,G) state.
to flow following the (S,G) state until they reach the receiver. When this happens, data packets from S start 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.
The prune is propagated until it reaches the RP or a router that still The prune is propagated until it reaches the RP or a router that still
needs the traffic from S for other receivers. needs the traffic from S for other receivers.
By now, the receiver will be receiving traffic from S along the By now, the receiver will be receiving traffic from S along the
skipping to change at page 11, line 33 skipping to change at page 11, line 35
to receive traffic for a group if that traffic comes from a particular to receive traffic for a group if that traffic comes from a particular
source. If a receiver does this, and no other receiver on the LAN source. If a receiver does this, and no other receiver on the LAN
requires all the traffic for the group, then the DR may omit performing requires all the traffic for the group, then the DR may omit performing
a (*,G) join to set up the shared tree, and instead issue a source- a (*,G) join to set up the shared tree, and instead issue a source-
specific (S,G) join only. specific (S,G) join only.
The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is
currently set aside for source-specific multicast in IPv4. For groups currently set aside for source-specific multicast in IPv4. For groups
in this range, receivers should only issue source-specific IGMPv3 joins. in this range, receivers should only issue source-specific IGMPv3 joins.
If a PIM router receives a non-source-specific join for a group in this If a PIM router receives a non-source-specific join for a group in this
range, it should ignore it, as described in Section 4.9. range, it should ignore it, as described in Section 4.8.
Source-specific Prunes Source-specific Prunes
IGMPv3 also permits a receiver to join a group and specify that it only IGMPv3 also permits a receiver to join a group and specify that it only
wants to receive traffic for a group if that traffic does not come from wants to receive traffic for a group if that traffic does not come from
a specific source or sources. In this case, the DR will perform a (*,G) a specific source or sources. In this case, the DR will perform a (*,G)
join as normal, but may combine this with an (S,G,rpt) prune for each of join as normal, but may combine this with an (S,G,rpt) prune for each of
the sources the receiver does not wish to receive. the sources the receiver does not wish to receive.
Multi-access Transit LANs Multi-access Transit LANs
The overview so far has concerned itself with point-to-point links. The overview so far has concerned itself with point-to-point transit |
However, using multi-access LANs such as Ethernet for transit is not links. However, using multi-access LANs such as Ethernet for transit is
uncommon. This can cause complications for three reasons: not uncommon. This can cause complications for three reasons:
o Two or more routers on the LAN may issue (*,G) Joins to different o Two or more routers on the LAN may issue (*,G) Joins to different
upstream routers on the LAN because they have inconsistent MRIB upstream routers on the LAN because they have inconsistent MRIB
entries regarding how to reach the RP. Both paths on the RP tree will entries regarding how to reach the RP. Both paths on the RP tree will
be set up, causing two copies of all the shared tree traffic to appear be set up, causing two copies of all the shared tree traffic to appear
on the LAN. on the LAN.
o Two or more routers on the LAN may issue (S,G) Joins to different o Two or more routers on the LAN may issue (S,G) Joins to different
upstream routers on the LAN because they have inconsistent MRIB upstream routers on the LAN because they have inconsistent MRIB
entries regarding how to reach source S. Both paths on the source- entries regarding how to reach source S. Both paths on the source-
skipping to change at page 12, line 38 skipping to change at page 12, line 41
router has (S,G) state, then in favor of the router with the best metric router has (S,G) state, then in favor of the router with the best metric
to the RP for RP trees, or the best metric to the source to source- to the RP for RP trees, or the best metric to the source to source-
specific trees. specific trees.
These Assert messages are also received by the downstream routers on the These Assert messages are also received by the downstream routers on the
LAN, and these cause subsequent Join messages to be sent to the upstream LAN, and these cause subsequent Join messages to be sent to the upstream
router that won the Assert. router that won the Assert.
RP Discovery RP Discovery
PIM-SM routers need to know the address of the RP for each group for PIM-SM routers need to know the address of the RP for each group for |
which they have (*,G) state. This address is obtained either through a which they have (*,G) state. This address is obtained either |
bootstrap mechanism or through static configuration. automatically (e.g., embedded-RP), through a 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 [13]. One router in each PIM domain is elected the Bootstrap mechanism [11]. One router in each PIM domain is elected the Bootstrap
Router through a simple election process. All the routers in the domain Router through a simple election process. All the routers in the domain
that are configured to be candidates to be RPs periodically unicast that are configured to be candidates to be RPs periodically unicast
their candidacy to the BSR. From the candidates, the BSR picks an RP- their candidacy to the BSR. From the candidates, the BSR picks an RP-
set, and periodically announces this set in a Bootstrap message. set, and periodically announces this set in a Bootstrap message.
Bootstrap messages are flooded hop-by-hop throughout the domain until Bootstrap messages are flooded hop-by-hop throughout the domain until
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 13, line 29 skipping to change at page 13, line 31
for sending and processing Hello messages. for sending and processing Hello messages.
o Section 4.4 specifies the PIM Register generation and processing o Section 4.4 specifies the PIM Register generation and processing
rules. rules.
o Section 4.5 specifies the PIM Join/Prune generation and processing o Section 4.5 specifies the PIM Join/Prune generation and processing
rules. rules.
o Section 4.6 specifies the PIM Assert generation and processing rules. o Section 4.6 specifies the PIM Assert generation and processing rules.
o Section 4.7 specifies the PIM Multicast Border Router behavior. o Section 4.7 specifies the RP discovery mechanisms.
o Section 4.8 specifies the RP discovery mechanisms.
o The subset of PIM required to support Source-Specific Multicast, PIM- o The subset of PIM required to support Source-Specific Multicast, PIM-
SSM, is described in Section 4.9. SSM, is described in Section 4.8.
o PIM packet formats are specified in Section 4.10. 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.11. Section 4.10.
o Appendix A in Section 11 specifies the PIM Multicast Border Router |
behavior.
4.1. PIM Protocol State 4.1. PIM Protocol State
This section specifies all the protocol state that a PIM implementation This section specifies all the protocol state that a PIM implementation
should maintain in order to function correctly. We term this state the should maintain in order to function correctly. We term this state the
Tree Information Base or TIB, as it holds the state of all the multicast Tree Information Base or TIB, as it holds the state of all the multicast
distribution trees at this router. In this specification we define PIM distribution trees at this router. In this specification we define PIM
mechanisms in terms of the TIB. However, only a very simple mechanisms in terms of the TIB. However, only a very simple
implementation would actually implement packet forwarding operations in implementation would actually implement packet forwarding operations in
terms of this state. Most implementations will use this state to build terms of this state. Most implementations will use this state to build
a multicast forwarding table, which would then be updated when the a multicast forwarding table, which would then be updated when the
relevant state in the TIB changes. relevant state in the TIB changes.
Although we specify precisely the state to be kept, this does not mean Although we specify precisely the state to be kept, this does not mean
that an implementation of PIM-SM needs to hold the state in this form. that an implementation of PIM-SM needs to hold the state in this form.
This is actually an abstract state definition, which is needed in order This is actually an abstract state definition, which is needed in order
to specify the router's behavior. A PIM-SM implementation is free to to specify the router's behavior. A PIM-SM implementation is free to
hold whatever internal state it requires, and will still be conformant hold whatever internal state it requires, and will still be conformant
with this specification so long as it results in the same externally with this specification so long as it results in the same externally
skipping to change at page 14, line 48 skipping to change at page 15, line 4
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 Override Interval
o Propagation Delay o Propagation Delay
o Suppression state: One of {"Enable", "Disable"} o Suppression state: One of {"Enable", "Disable"}
Neighbor State: Neighbor State:
For each neighbor: For each neighbor:
o Information from neighbor's Hello o Information from neighbor's Hello
o Neighbor's Gen ID. o Neighbor's GenID. |
o Neighbor Liveness Timer (NLT) o Neighbor Liveness Timer (NLT)
Designated Router (DR) State: Designated Router (DR) State:
o Designated Router's IP Address o Designated Router's IP Address
o DR's DR Priority o DR's DR Priority
The Override Interval, the Propagation Delay and the Interface The Override Interval, the Propagation Delay and the Interface
skipping to change at page 16, line 46 skipping to change at page 17, line 4
o Prune-Pending Timer (PPT) o Prune-Pending Timer (PPT)
o Join/Prune Expiry Timer (ET) o Join/Prune Expiry Timer (ET)
(*,G) Assert Winner State (*,G) Assert Winner State
o State: One of {"NoInfo" (NI), "I lost Assert" (L), o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)} "I won Assert" (W)}
o Assert Timer (AT) o Assert Timer (AT)
o Assert winner's IP Address (AssertWinner) |
o Assert winner's IP Address o Assert winner's Assert Metric (AssertWinnerMetric)
o Assert winner's Assert Metric
Not interface specific: Not interface specific:
Upstream (*,G) Join/Prune State: Upstream (*,G) Join/Prune State:
o State: One of {"NotJoined(*,G)", "Joined(*,G)"} o State: One of {"NotJoined(*,G)", "Joined(*,G)"}
o Upstream Join/Prune Timer (JT) o Upstream Join/Prune Timer (JT)
o Last RP Used o Last RP Used
skipping to change at page 17, line 43 skipping to change at page 17, line 48
Assert messages on this interface. It is specified in Section 4.6.2. Assert messages on this interface. It is specified in Section 4.6.2.
The upstream (*,G) Join/Prune State reflects the state of the upstream The upstream (*,G) Join/Prune State reflects the state of the upstream
(*,G) state machine described in Section 4.5.6. (*,G) state machine described in Section 4.5.6.
The upstream (*,G) Join/Prune Timer is used to send out periodic The upstream (*,G) Join/Prune Timer is used to send out periodic
Join(*,G) messages, and to override Prune(*,G) messages from peers on an Join(*,G) messages, and to override Prune(*,G) messages from peers on an
upstream LAN interface. upstream LAN interface.
The last RP used must be stored because if the RP-Set changes (Section The last RP used must be stored because if the RP-Set changes (Section
4.8) then state must be torn down and rebuilt for groups whose RP 4.7) then state must be torn down and rebuilt for groups whose RP
changes. changes.
The last RPF neighbor towards the RP is stored because if the MRIB The last RPF neighbor towards the RP is stored because if the MRIB
changes then the RPF neighbor towards the RP may change. If it does so, changes then the RPF neighbor towards the RP may change. If it does so,
then we need to trigger a new Join(*,G) to the new upstream neighbor and then we need to trigger a new Join(*,G) to the new upstream neighbor and
a Prune(*,G) to the old upstream neighbor. Similarly, if a router a Prune(*,G) to the old upstream neighbor. Similarly, if a router
detects through a changed GenID in a Hello message that the upstream detects through a changed GenID in a Hello message that the upstream
neighbor towards the RP has rebooted, then it should re-instantiate neighbor towards the RP has rebooted, then it should re-instantiate
state by sending a Join(*,G). These mechanisms are specified in Section state by sending a Join(*,G). These mechanisms are specified in Section
4.5.6. 4.5.6.
4.1.4. (S,G) State 4.1.4. (S,G) State
For every source/group pair (S,G) a router keeps the following state: For every source/group pair (S,G) a router keeps the following state:
(S,G) state: (S,G) state:
For each interface: For each interface:
skipping to change at page 18, line 34 skipping to change at page 18, line 41
o Join/Prune Expiry Timer (ET) o Join/Prune Expiry Timer (ET)
(S,G) Assert Winner State (S,G) Assert Winner State
o State: One of {"NoInfo" (NI), "I lost Assert" (L), o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)} "I won Assert" (W)}
o Assert Timer (AT) o Assert Timer (AT)
o Assert winner's IP Address o Assert winner's IP Address (AssertWinner) |
o Assert winner's Assert Metric o Assert winner's Assert Metric (AssertWinnerMetric)
Not interface specific: Not interface specific:
Upstream (S,G) Join/Prune State: Upstream (S,G) Join/Prune State:
o State: One of {"NotJoined(S,G)", "Joined(S,G)"} o State: One of {"NotJoined(S,G)", "Joined(S,G)"}
o Upstream (S,G) Join/Prune Timer (JT) o Upstream (S,G) Join/Prune Timer (JT)
o Last RPF Neighbor towards S that was used o Last RPF Neighbor towards S that was used
o SPT bit (indicates (S,G) state is active) o SPTbit (indicates (S,G) state is active) |
o (S,G) Keepalive Timer (KAT) o (S,G) Keepalive Timer (KAT)
Additional (S,G) state at the DR: Additional (S,G) state at the DR:
o Register state: One of {"Join" (J), "Prune" (P), o Register state: One of {"Join" (J), "Prune" (P),
"Join-Pending" (JP), "NoInfo" (NI)} "Join-Pending" (JP), "NoInfo" (NI)}
o Register-Stop timer o Register-Stop timer
Additional (S,G) state at the RP: |
o PMBR: the first PMBR to send a Register for this |
source with the Border bit set. |
Local membership is the result of the local source-specific membership Local membership is the result of the local source-specific membership
mechanism (such as IGMP version 3) running on that interface and mechanism (such as IGMP version 3) running on that interface and
specifying that this particular source should be included. As stored specifying that this particular source should be included. As stored
here, this state is the resulting state after any IGMPv3 inconsistencies here, this state is the resulting state after any IGMPv3 inconsistencies
have been resolved. It need not be kept if this router is not the DR on have been resolved. It need not be kept if this router is not the DR on
that interface unless this router won a (S,G) assert on this interface that interface unless this router won a (S,G) assert on this interface
for this group. However, we recommend storing this information if for this group. However, we recommend storing this information if
possible, as it reduces latency converging to stable operating possible, as it reduces latency converging to stable operating
conditions after a failure causing a change of DR. This information is conditions after a failure causing a change of DR. This information is
used by the pim_include(S,G) macro described in Section 4.1.6. used by the pim_include(S,G) macro described in Section 4.1.6.
skipping to change at page 20, line 19 skipping to change at page 20, line 32
absence of explicit (S,G) Joins. Amongst other things, this is absence of explicit (S,G) Joins. Amongst other things, this is
necessary for the so-called "turnaround rules" - when the RP uses (S,G) necessary for the so-called "turnaround rules" - when the RP uses (S,G)
joins to stop encapsulation, and then (S,G) prunes to prevent traffic joins to stop encapsulation, and then (S,G) prunes to prevent traffic
from unnecessarily reaching the RP. from unnecessarily reaching the RP.
On a DR, the (S,G) Register State is used to keep track of whether to On a DR, the (S,G) Register State is used to keep track of whether to
encapsulate data to the RP on the Register Tunnel; the (S,G) Register- encapsulate data to the RP on the Register Tunnel; the (S,G) Register-
Stop timer tracks how long before encapsulation begins again for a given Stop timer tracks how long before encapsulation begins again for a given
(S,G). (S,G).
On an RP, the PMBR value must be cleared when the Keepalive Timer |
expires.
4.1.5. (S,G,rpt) State 4.1.5. (S,G,rpt) State
For every source/group pair (S,G) for which a router also has (*,G) For every source/group pair (S,G) for which a router also has (*,G)
state, it also keeps the following state: state, it also keeps the following state:
(S,G,rpt) state: (S,G,rpt) state:
For each interface: For each interface:
Local Membership: Local Membership:
skipping to change at page 25, line 31 skipping to change at page 25, line 48
messages that we send to RPF'(*,G) (See Section 4.5.8). messages that we send to RPF'(*,G) (See Section 4.5.8).
The function MRIB.next_hop( S ) returns an address of the next-hop PIM The function MRIB.next_hop( S ) returns an address of the next-hop PIM
neighbor toward the host S, as indicated by the current MRIB. If S is neighbor toward the host S, as indicated by the current MRIB. If S is
directly adjacent, then MRIB.next_hop( S ) returns NULL. At the RP for directly adjacent, then MRIB.next_hop( S ) returns NULL. At the RP for
G, MRIB.next_hop( RP(G)) returns NULL. G, MRIB.next_hop( RP(G)) returns NULL.
The function NBR( I, A ) uses information gathered through PIM Hello The function NBR( I, A ) uses information gathered through PIM Hello
messages to map the IP address A of a directly connected PIM neighbor messages to map the IP address A of a directly connected PIM neighbor
router on interface I to the primary IP address of the same router router on interface I to the primary IP address of the same router
(Section 4.3.4). The primary IP address of a neighbor is the link-local (Section 4.3.4). The primary IP address of a neighbor is the address |
address that it uses as the source of its PIM Hello messages. Note that that it uses as the source of its PIM Hello messages. Note that a
a neighbor's IP address may be non-unique within the PIM neighbor
database due to scope issues. The address must however be unique amongst
the addresses of all the PIM neighbors on a specific interface.
I_Am_Assert_Loser(S, G, I) is true if the Assert start machine (in neighbor's IP address may be non-unique within the PIM neighbor database
due to scope issues. The address must however be unique amongst the
addresses of all the PIM neighbors on a specific interface.
I_Am_Assert_Loser(S, G, I) is true if the Assert state machine (in |
Section 4.6.1) for (S,G) on Interface I is in "I am Assert Loser" state. Section 4.6.1) for (S,G) on Interface I is in "I am Assert Loser" state.
I_Am_Assert_Loser(*, G, I) is true if the Assert start machine (in I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in |
Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser" state. Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser" state.
4.2. Data Packet Forwarding Rules 4.2. Data Packet Forwarding Rules
The PIM-SM packet forwarding rules are defined below in pseudocode. The PIM-SM packet forwarding rules are defined below in pseudocode.
iif is the incoming interface of the packet. iif is the incoming interface of the packet.
S is the source address of the packet. S is the source address of the packet.
G is the destination address of the packet (group address). G is the destination address of the packet (group address).
RP is the address of the Rendezvous Point for this group. RP is the address of the Rendezvous Point for this group.
skipping to change at page 26, line 15 skipping to change at page 26, line 33
RPF_interface(S) is the interface the MRIB indicates would be used RPF_interface(S) is the interface the MRIB indicates would be used
to route packets to S. to route packets to S.
RPF_interface(RP) is the interface the MRIB indicates would be used RPF_interface(RP) is the interface the MRIB indicates would be used
to route packets to RP, except at the RP when it is the to route packets to RP, except at the RP when it is the
decapsulation interface (the "virtual" interface on which register decapsulation interface (the "virtual" interface on which register
packets are received). packets are received).
First, we restart (or start) the Keepalive Timer if the source is on a First, we restart (or start) the Keepalive Timer if the source is on a
directly connected subnet. directly connected subnet.
Second, we check to see if the SPT bit should be set because we've now Second, we check to see if the SPTbit should be set because we've now |
switched from the RP tree to the SPT. switched from the RP tree to the SPT.
Next we check to see whether the packet should be accepted based on TIB Next we check to see whether the packet should be accepted based on TIB
state and the interface that the packet arrived on. state and the interface that the packet arrived on.
If the packet should be forwarded using (S,G) state, we then build an If the packet should be forwarded using (S,G) state, we then build an
outgoing interface list for the packet. If this list is not empty, then outgoing interface list for the packet. If this list is not empty, then
we restart the (S,G) state Keepalive Timer. we restart the (S,G) state Keepalive Timer.
If the packet should be forwarded using (*,*,RP) or (*,G) state, then we If the packet should be forwarded using (*,*,RP) or (*,G) state, then we
just build an outgoing interface list for the packet. We also check if just build an outgoing interface list for the packet. We also check if
we should initiate a switch to start receiving this source on a shortest we should initiate a switch to start receiving this source on a shortest
path tree. path tree.
Finally we remove the incoming interface from the outgoing interface Finally we remove the incoming interface from the outgoing interface
list we've created, and if the resulting outgoing interface list is not list we've created, and if the resulting outgoing interface list is not
empty, we forward the packet out of those interfaces. empty, we forward the packet out of those interfaces.
On receipt of data from S to G on interface iif: On receipt of data from S to G on interface iif:
if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) { |
if( DirectlyConnected(S) == TRUE ) {
set KeepaliveTimer(S,G) to Keepalive_Period set KeepaliveTimer(S,G) to Keepalive_Period
# Note: a register state transition or UpstreamJPState(S,G) # Note: a register state transition or UpstreamJPState(S,G)
# transition may happen as a result of restarting # transition may happen as a result of restarting
# KeepaliveTimer, and must be dealt with here. # KeepaliveTimer, and must be dealt with here.
} }
Update_SPTbit(S,G,iif) Update_SPTbit(S,G,iif)
oiflist = NULL oiflist = NULL
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) { if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
skipping to change at page 28, line 4 skipping to change at page 27, line 52
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.2. Update_SPTbit(S,G,iif) is defined in Section 4.2.2.
CheckSwitchToSpt(S,G) is defined in Section 4.2.1. CheckSwitchToSpt(S,G) is defined in Section 4.2.1.
UpstreamJPState(S,G) is the state of the finite state machine in Section UpstreamJPState(S,G) is the state of the finite state machine in Section
4.5.7. 4.5.7.
Keepalive_Period is defined in Section 4.11. 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. Last-hop switchover to the SPT 4.2.1. Last-hop Switchover to the SPT
In Sparse-Mode PIM, last-hop routers join the shared tree towards the In Sparse-Mode PIM, last-hop routers join the shared tree towards the
RP. Once traffic from sources to joined groups arrives at a last-hop RP. Once traffic from sources to joined groups arrives at a last-hop
router it has the option of switching to receive the traffic on a router it has the option of switching to receive the traffic on a
shortest path tree (SPT). shortest path tree (SPT).
The decision for a router to switch to the SPT is controlled as follows: The decision for a router to switch to the SPT is controlled as follows:
void void
CheckSwitchToSpt(S,G) { CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) pim_exclude(S,G) if ( ( pim_include(*,G) (-) pim_exclude(S,G)
(+) pim_include(S,G) != NULL ) (+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) { AND SwitchToSptDesired(S,G) ) {
# Note: Restarting the KAT will result in the SPT switch |
restart KeepaliveTimer(S,G); restart KeepaliveTimer(S,G);
} }
} }
SwitchToSptDesired(S,G) is a policy function that is implementation SwitchToSptDesired(S,G) is a policy function that is implementation
defined. An "infinite threshold" policy can be implemented making defined. An "infinite threshold" policy can be implemented making
SwitchToSptDesired(S,G) return false all the time. A "switch on first SwitchToSptDesired(S,G) return false all the time. A "switch on first
packet" policy can be implemented by making SwitchToSptDesired(S,G) packet" policy can be implemented by making SwitchToSptDesired(S,G)
return true once a single packet has been received for the source and return true once a single packet has been received for the source and
group. group.
skipping to change at page 29, line 21 skipping to change at page 29, line 20
Thus, when a packet arrives, the (S,G) SPTbit is updated as follows: Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:
void void
Update_SPTbit(S,G,iif) { Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S) if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP(G)) OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) ) ) { ( RPF'(S,G) != NULL ) ) |
OR ( I_Am_Assert_Loser(S,G,iif) ) { |
Set SPTbit(S,G) to TRUE Set SPTbit(S,G) to TRUE
} }
} }
Additionally a router can set SPTbit(S,G) to TRUE in other cases, such Additionally a router can set SPTbit(S,G) to TRUE in other cases, such
as when it receives an Assert(S,G) on RPF_interface(S) (see Section as when it receives an Assert(S,G) on RPF_interface(S) (see Section
4.6.1). 4.6.1).
JoinDesired(S,G) is defined in Section 4.5.7, and indicates whether we JoinDesired(S,G) is defined in Section 4.5.7, and indicates whether we
have the appropriate (S,G) Join state to wish to send a Join(S,G) have the appropriate (S,G) Join state to wish to send a Join(S,G)
upstream. upstream.
Basically Update_SPTbit will set the SPT bit if we have the appropriate Basically Update_SPTbit will set the SPTbit if we have the appropriate |
(S,G) join state and the packet arrived on the correct upstream (S,G) join state and the packet arrived on the correct upstream
interface for S, and one or more of the following conditions applies: interface for S, and one or more of the following conditions applies:
1. The source is directly connected, in which case the switch to the 1. The source is directly connected, in which case the switch to the
SPT is a no-op. SPT is a no-op.
2. The RPF interface to S is different from the RPF interface to the 2. The RPF interface to S is different from the RPF interface to the
RP. The packet arrived on RPF_interface(S), and so the SPT must RP. The packet arrived on RPF_interface(S), and so the SPT must
have been completed. have been completed.
skipping to change at page 30, line 11 skipping to change at page 30, line 11
4. RPF'(S,G) == RPF'(*,G). In this case the router will never be able 4. RPF'(S,G) == RPF'(*,G). In this case the router will never be able
to tell if the SPT has been completed, so it should just switch to tell if the SPT has been completed, so it should just switch
immediately. immediately.
In the case where the RPF interface is the same for the RP and for S, In the case where the RPF interface is the same for the RP and for S,
but RPF'(S,G) and RPF'(*,G) differ, then we wait for an Assert(S,G) but RPF'(S,G) and RPF'(*,G) differ, then we wait for an Assert(S,G)
which indicates that the upstream router with (S,G) state believes the which indicates that the upstream router with (S,G) state believes the
SPT has been completed. However item (3) above is needed because there SPT has been completed. However item (3) above is needed because there
may not be any (*,G) state to trigger an Assert(S,G) to happen. may not be any (*,G) state to trigger an Assert(S,G) to happen.
The SPT bit is cleared in the (S,G) upstream state machine (see Section The SPTbit is cleared in the (S,G) upstream state machine (see Section |
4.5.7) when JoinDesired(S,G) becomes FALSE. 4.5.7) when JoinDesired(S,G) becomes FALSE.
4.3. Designated Routers (DR) and Hello Messages 4.3. Designated Routers (DR) and Hello Messages
A shared-media LAN like Ethernet may have multiple PIM-SM routers A shared-media LAN like Ethernet may have multiple PIM-SM routers |
connected to it. If the LAN has directly connected hosts, then a single connected to it. A single one of these routers, the DR, will act on |
one of these routers, the DR, will act on behalf of those hosts with behalf of directly connected hosts with respect to the PIM-SM protocol. |
respect to the PIM-SM protocol. Because the distinction between LANs Because the distinction between LANs and point-to-point interfaces can |
and point-to-point interfaces can sometimes be blurred, and because sometimes be blurred, and because routers may also have multicast host |
routers may also have multicast host functionality, the PIM-SM functionality, the PIM-SM specification makes no distinction between the |
specification makes no distinction between the two. Thus DR election two. Thus DR election will happen on all interfaces, LAN or otherwise.
will happen on all interfaces, LAN or otherwise.
DR election is performed using Hello messages. Hello messages are also DR election is performed using Hello messages. Hello messages are also
the way that option negotiation takes place in PIM, so that additional the way that option negotiation takes place in PIM, so that additional
functionality can be enabled, or parameters tuned. functionality can be enabled, or parameters tuned.
4.3.1. Sending Hello Messages 4.3.1. Sending Hello Messages
PIM-Hello messages are sent periodically on each PIM-enabled interface. PIM Hello messages are sent periodically on each PIM-enabled interface. |
They allow a router to learn about the neighboring PIM routers on each They allow a router to learn about the neighboring PIM routers on each
interface. Hello messages are also the mechanism used to elect a interface. Hello messages are also the mechanism used to elect a
Designated Router (DR), and to negotiate additional capabilities. A Designated Router (DR), and to negotiate additional capabilities. A
router must record the Hello information received from each PIM router must record the Hello information received from each PIM
neighbor. neighbor.
Hello messages MUST be sent on all active interfaces, including physical Hello messages MUST be sent on all active interfaces, including physical
point-to-point links, and are multicast to the `ALL-PIM-ROUTERS' group point-to-point links, and are multicast to the `ALL-PIM-ROUTERS' group
address (`224.0.0.13' for IPv4 and `ff02::d' for IPv6). address (`224.0.0.13' for IPv4 and `ff02::d' for IPv6).
skipping to change at page 31, line 36 skipping to change at page 31, line 35
The Generation_Identifier (GenID) Option SHOULD be included in all Hello The Generation_Identifier (GenID) Option SHOULD be included in all Hello
messages. The GenID option contains a randomly generated 32-bit value messages. The GenID option contains a randomly generated 32-bit value
that is regenerated each time PIM forwarding is started or restarted on that is regenerated each time PIM forwarding is started or restarted on
the interface, including when the router itself restarts. When a Hello the interface, including when the router itself restarts. When a Hello
message with a new GenID is received from a neighbor, any old Hello message with a new GenID is received from a neighbor, any old Hello
information about that neighbor SHOULD be discarded and superseded by information about that neighbor SHOULD be discarded and superseded by
the information from the new Hello message. This may cause a new DR to the information from the new Hello message. This may cause a new DR to
be chosen on that interface. be chosen on that interface.
The LAN_Prune_Delay Option SHOULD be included in all Hello messages sent The LAN Prune Delay Option SHOULD be included in all Hello messages sent
on multi-access LANs. This option advertises a router's capability to on multi-access LANs. This option advertises a router's capability to
use values other than the default for the Propagation_Delay and use values other than the default for the Propagation_Delay and
Override_Interval which affect the setting of the Prune-Pending, Override_Interval which affect the setting of the Prune-Pending,
Upstream Join and Override Timers (defined in Section 4.11). Upstream Join and Override Timers (defined in Section 4.10).
The Interface_Address_List Option advertises all the secondary addresses The Interface_Address_List Option advertises all the secondary addresses
associated with the source interface of the router originating the associated with the source interface of the router originating the
message. The option MUST be included in all Hello messages if there are message. The option MUST be included in all Hello messages if there are
secondary addresses associated with the source interface and MAY be secondary addresses associated with the source interface and MAY be
omitted if no secondary addresses exist. omitted if no secondary addresses exist.
To allow new or rebooting routers to learn of PIM neighbors quickly, To allow new or rebooting routers to learn of PIM neighbors quickly,
when a Hello message is received from a new neighbor, or a Hello message when a Hello message is received from a new neighbor, or a Hello message
with a new GenID is received from an existing neighbor, a new Hello with a new GenID is received from an existing neighbor, a new Hello
skipping to change at page 32, line 26 skipping to change at page 32, line 25
remove this neighbor (or its old IP address) immediately. After an remove this neighbor (or its old IP address) immediately. After an
interface has changed its IP address, it MUST send a Hello message with interface has changed its IP address, it MUST send a Hello message with
its new IP address. If an interface changes one of its secondary IP its new IP address. If an interface changes one of its secondary IP
addresses, a Hello message with an updated Address_List option and a addresses, a Hello message with an updated Address_List option and a
non-zero HoldTime should be sent immediately. This will cause PIM non-zero HoldTime should be sent immediately. This will cause PIM
neighbors to update this neighbor's list of secondary addresses neighbors to update this neighbor's list of secondary addresses
immediately. immediately.
4.3.2. DR Election 4.3.2. DR Election
When a PIM-Hello message is received on interface I the following When a PIM Hello message is received on interface I the following |
information about the sending neighbor is recorded: information about the sending neighbor is recorded:
neighbor.interface neighbor.interface
The interface on which the Hello message arrived. The interface on which the Hello message arrived.
neighbor.primary_ip_address neighbor.primary_ip_address
The IP address that the PIM neighbor used as the source The IP address that the PIM neighbor used as the source
address of the Hello message. address of the Hello message.
neighbor.genid neighbor.genid
skipping to change at page 33, line 45 skipping to change at page 33, line 44
The trivial function I_am_DR(I) is defined to aid readability: The trivial function I_am_DR(I) is defined to aid readability:
bool bool
I_am_DR(I) { I_am_DR(I) {
return DR(I) == me return DR(I) == me
} }
The DR Priority is a 32-bit unsigned number and the numerically larger The DR Priority is a 32-bit unsigned number and the numerically larger
priority is always preferred. A router's idea of the current DR on an priority is always preferred. A router's idea of the current DR on an
interface can change when a PIM-Hello message is received, when a interface can change when a PIM Hello message is received, when a |
neighbor times out, or when a router's own DR Priority changes. If the neighbor times out, or when a router's own DR Priority changes. If the
router becomes the DR or ceases to be the DR, this will normally cause router becomes the DR or ceases to be the DR, this will normally cause
the DR Register state-machine to change state. Subsequent actions are the DR Register state machine to change state. Subsequent actions are
determined by that state-machine. determined by that state machine.
We note that some PIM implementations do not send Hello We note that some PIM implementations do not send Hello
messages on point-to-point interfaces, and so cannot perform messages on point-to-point interfaces, and so cannot perform
DR election on such interfaces. This in non-compliant DR election on such interfaces. This in non-compliant
behavior. DR election MUST be performed on ALL active PIM-SM behavior. DR election MUST be performed on ALL active PIM-SM
interfaces. interfaces.
4.3.3. Reducing Prune Propagation Delay on LANs 4.3.3. Reducing Prune Propagation Delay on LANs
In addition to the information recorded for the DR Election, the In addition to the information recorded for the DR Election, the
following per neighbor information is obtained from the LAN Prune Delay following per neighbor information is obtained from the LAN Prune Delay
Hello option: Hello option:
neighbor.lan_prune_delay_present neighbor.lan_prune_delay_present
A flag indicating if the LAN Prune Delay option was present in A flag indicating if the LAN Prune Delay option was present in
the Hello message. the Hello message.
neighbor.tracking_support neighbor.tracking_support
A flag storing the value of the T bit in the LAN Prune Delay A flag storing the value of the T bit in the LAN Prune Delay
option if it is present in the Hello message. This indicates option if it is present in the Hello message. This indicates
the neighbor's capability to disable Join message suppression. the neighbor's capability to disable Join message suppression. |
neighbor.lan_delay neighbor.propagation_delay |
The LAN Delay field of the LAN Prune Delay option (if present) The Propagation Delay field of the LAN Prune Delay option (if |
in the Hello message. present) in the Hello message.
neighbor.override_interval neighbor.override_interval
The Override_Interval field of the LAN Prune Delay option (if The Override_Interval field of the LAN Prune Delay option (if
present) in the Hello message. present) in the Hello message.
The additional state described above is deleted along with the DR The additional state described above is deleted along with the DR
neighbor state when the neighbor timeout expires. neighbor state when the neighbor timeout expires.
Just like the DR_Priority option, the information provided in the LAN Just like the DR_Priority option, the information provided in the LAN
Prune Delay option is not used unless all neighbors on a link advertise Prune Delay option is not used unless all neighbors on a link advertise
skipping to change at page 35, line 5 skipping to change at page 35, line 5
bool bool
lan_delay_enabled(I) { lan_delay_enabled(I) {
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.lan_prune_delay_present == false ) { if ( neighbor.lan_prune_delay_present == false ) {
return false return false
} }
} }
return true return true
} }
The LAN Delay inserted by a router in the LAN Prune Delay option The Propataion Delay inserted by a router in the LAN Prune Delay option |
expresses the expected message propagation delay on the link and should expresses the expected message propagation delay on the link and should
be configurable by the system administrator. It is used by upstream be configurable by the system administrator. It is used by upstream
routers to figure out how long they should wait for a Join override routers to figure out how long they should wait for a Join override
message before pruning an interface. message before pruning an interface.
PIM implementors should enforce a lower bound on the permitted values PIM implementors should enforce a lower bound on the permitted values
for this delay to allow for scheduling and processing delays within for this delay to allow for scheduling and processing delays within
their router. Such delays may cause received messages to be processed their router. Such delays may cause received messages to be processed
later as well as triggered messages to be sent later than intended. later as well as triggered messages to be sent later than intended. |
Setting this LAN Prune Delay to too low a value may result in temporary Setting this Propagation Delay to too low a value may result in
forwarding outages because a downstream router will not be able to temporary forwarding outages because a downstream router will not be
override a neighbor's Prune message before the upstream neighbor stops able to override a neighbor's Prune message before the upstream neighbor
forwarding. stops forwarding.
When all routers on a link are in a position to negotiate a different When all routers on a link are in a position to negotiate a different
than default Propagation Delay, the largest value from those advertised than default Propagation Delay, the largest value from those advertised
by each neighbor is chosen. The function for computing the Propagation by each neighbor is chosen. The function for computing the |
Delay of interface I is: Effective_Propagation_Delay of interface I is:
time_interval time_interval
Propagation_Delay(I) { Effective_Propagation_Delay(I) { |
if ( lan_delay_enabled(I) == false ) { if ( lan_delay_enabled(I) == false ) {
return LAN_delay_default return Propagation_delay_default |
} }
delay = 0 delay = Propagation_Delay(I) |
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.lan_delay > delay ) { if ( neighbor.propagation_delay > delay ) { |
delay = neighbor.lan_delay delay = neighbor.propagation_delay |
} }
} }
return delay return delay
} }
To avoid synchronization of override messages when multiple downstream To avoid synchronization of override messages when multiple downstream
routers share a multi-access link, sending of such messages is delayed routers share a multi-access link, sending of such messages is delayed
by a small random amount of time. The period of randomization should by a small random amount of time. The period of randomization should
represent the size of the PIM router population on the link. Each represent the size of the PIM router population on the link. Each
router expresses its view of the amount of randomization necessary in router expresses its view of the amount of randomization necessary in |
the Override Delay field of the LAN Prune Delay option. the Override Interval field of the LAN Prune Delay option.
When all routers on a link are in a position to negotiate a different When all routers on a link are in a position to negotiate a different |
than default Override Delay, the largest value from those advertised by than default Override Interval, the largest value from those advertised |
each neighbor is chosen. The function for computing the Override by each neighbor is chosen. The function for computing the Effective |
Interval of interface I is: Override Interval of interface I is:
time_interval time_interval
Override_Interval(I) { Effective_Override_Interval(I) { |
if ( lan_delay_enabled(I) == false ) { if ( lan_delay_enabled(I) == false ) {
return t_override_default return t_override_default
} }
delay = 0 delay = Override_Interval(I) |
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.override_interval > delay ) { if ( neighbor.override_interval > delay ) {
delay = neighbor.override_interval delay = neighbor.override_interval
} }
} }
return delay return delay
} }
Although the mechanisms are not specified in this document, it is Although the mechanisms are not specified in this document, it is
possible for upstream routers to explicitly track the join membership of possible for upstream routers to explicitly track the join membership of
skipping to change at page 36, line 42 skipping to change at page 36, line 42
} }
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.tracking_support == false ) { if ( neighbor.tracking_support == false ) {
return true return true
} }
} }
return false return false
} }
Note that the setting of Suppression_Enabled(I) affects the value of Note that the setting of Suppression_Enabled(I) affects the value of
t_suppressed (see Section 4.11). t_suppressed (see Section 4.10).
4.3.4. Maintaining Secondary Address Lists 4.3.4. Maintaining Secondary Address Lists
Communication of a routers interface secondary addresses to its PIM Communication of a router's interface secondary addresses to its PIM
neighbors is necessary to provide the neighbors with a mechanism for neighbors is necessary to provide the neighbors with a mechanism for
mapping next_hop information obtained through their MRIB to a primary mapping next_hop information obtained through their MRIB to a primary
address that can be used as a destination for Join/Prune messages. The address that can be used as a destination for Join/Prune messages. The
mapping is performed through the NBR macro. The primary address of a mapping is performed through the NBR macro. The primary address of a
PIM neighbor is obtained from the source IP address used in its PIM PIM neighbor is obtained from the source IP address used in its PIM
Hello messages. Secondary addresses are carried within the Hello message Hello messages. Secondary addresses are carried within the Hello message
in an Address List Hello option. The primary address of the source in an Address List Hello option. The primary address of the source
interface of the router MUST NOT be listed within the Address List Hello interface of the router MUST NOT be listed within the Address List Hello
option. option.
skipping to change at page 38, line 21 skipping to change at page 38, line 21
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 as specified in Section 4.2. forwarding rules as 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)
The register tunnel is "joined" (the join is actually implicit, but The register tunnel is "joined" (the join is actually implicit, but
the DR acts as if the RP has joined the DR on the tunnel the DR acts as if the RP has joined the DR on the tunnel
interface). interface).
Prune (P) Prune (P)
The register tunnel is "pruned" (this occurs when a Register-Stop The register tunnel is "pruned" (this occurs when a Register-Stop
is received). is received).
skipping to change at page 39, line 5 skipping to change at page 39, line 5
The register tunnel is pruned but the DR is contemplating adding it The register tunnel is pruned but the DR is contemplating adding it
back. back.
NoInfo (NI) NoInfo (NI)
No information. This is the initial state, and the state when the No information. This is the initial state, and the state when the
router is not the DR. router is not the DR.
In addition, a Register-Stop Timer (RST) is kept if the state machine is In addition, a Register-Stop Timer (RST) is kept if the state machine is
not in the NoInfo state. not in the NoInfo state.
Figure 1: Per-(S,G) register state-machine at a DR in tabular form Figure 1: Per-(S,G) register state machine at a DR in tabular form
+-----------++---------------------------------------------------------------+ +-----------++---------------------------------------------------------------+
| || Event | | || Event |
| ++-----------+------------+------------+------------+------------+ | ++-----------+------------+------------+------------+------------+
|Prev State ||Register- | Could | Could | Register- | RP changed | |Prev State ||Register- | Could | Could | Register- | RP changed |
| ||Stop Timer | Register | Register | Stop | | | ||Stop Timer | Register | Register | Stop | |
| ||expires | ->True | ->False | received | | | ||expires | ->True | ->False | received | |
+-----------++-----------+------------+------------+------------+------------+ +-----------++-----------+------------+------------+------------+------------+
|NoInfo ||- | -> J state | - | - | - | |NoInfo ||- | -> J state | - | - | - |
|(NI) || | add reg | | | | |(NI) || | add reg | | | |
skipping to change at page 39, line 34 skipping to change at page 39, line 34
| || | | | Stop | | | || | | | Stop | |
| || | | | Timer(*) | | | || | | | Timer(*) | |
+-----------++-----------+------------+------------+------------+------------+ +-----------++-----------+------------+------------+------------+------------+
| ||-> J state | - | -> NI | -> P state | -> J state | | ||-> J state | - | -> NI | -> P state | -> J state |
| || | | state | | | | || | | state | | |
|Join- ||add reg | | | set | add reg | |Join- ||add reg | | | set | add reg |
|Pending ||tunnel | | | Register- | tunnel; | |Pending ||tunnel | | | Register- | tunnel; |
|(JP) || | | | Stop | cancel | |(JP) || | | | Stop | cancel |
| || | | | Timer(*) | Register- | | || | | | Timer(*) | Register- |
| || | | | | Stop Timer | | || | | | | Stop Timer |
+-----------++-----------+------------+------------+------------+------------+ Tim+-----------++-----------+------------+------------+------------+------------+
| ||-> JP | - | -> NI | - | -> J state | | ||-> JP | - | -> NI | - | -> J state |
| ||state | | state | | | | ||state | | state | | |
| ||set | | | | add reg | | ||set | | | | add reg |
|Prune (P) ||Register- | | | | tunnel; | |Prune (P) ||Register- | | | | tunnel; |
| ||Stop | | | | cancel | | ||Stop | | | | cancel |
| ||Timer(**); | | | | Register- | | ||Timer(**); | | | | Register- |
| ||send Null- | | | | Stop Timer | | ||send Null- | | | | Stop Timer |
| ||Register | | | | | | ||Register | | | | |
+-----------++-----------+------------+------------+------------+------------+ +-----------++-----------+------------+------------+------------+------------+
skipping to change at page 41, line 14 skipping to change at page 41, line 14
Note that on reception of a packet at the DR from a directly connected Note that on reception of a packet at the DR from a directly connected
source, KeepaliveTimer(S,G) needs to be set by the packet forwarding source, KeepaliveTimer(S,G) needs to be set by the packet forwarding
rules before computing CouldRegister(S,G) in the register state machine, rules before computing CouldRegister(S,G) in the register state machine,
or the first packet from a source won't be registered. or the first packet from a source won't be registered.
Encapsulating data packets in the Register Tunnel Encapsulating data packets in the Register Tunnel
Conceptually, the Register Tunnel is an interface with a smaller MTU Conceptually, the Register Tunnel is an interface with a smaller MTU
than the underlying IP interface towards the RP. IP fragmentation on than the underlying IP interface towards the RP. IP fragmentation on
packets forwarded on the Register Tunnel is performed based upon this packets forwarded on the Register Tunnel is performed based upon this |
smaller MTU. The encapsulating DR may perform Path-MTU Discovery to the smaller MTU. The encapsulating DR may perform Path MTU Discovery to the
RP to determine the effective MTU of the tunnel. This smaller MTU takes RP to determine the effective MTU of the tunnel. Fragmentation for the |
both the outer IP header and the PIM register header overhead into smaller MTU should take both the outer IP header and the PIM register
account. If a multicast packet is fragmented on the way into the header overhead into account. If a multicast packet is fragmented on
Register Tunnel, each fragment is encapsulated individually so it the way into the Register Tunnel, each fragment is encapsulated
contains IP, PIM, and inner IP headers. individually so it contains IP, PIM, and inner IP headers.
In IPv6, the DR MUST perform Path-MTU discovery, and an ICMP In IPv6, the DR MUST perform Path MTU discovery, and an ICMP Packet Too |
Fragmentation Required message MUST be sent by the encapsulating DR if Big message MUST be sent by the encapsulating DR if it receives a packet
it receives a packet that will not fit in the effective MTU of the that will not fit in the effective MTU of the tunnel. If the MTU
tunnel. If the MTU between the DR and the RP results in the effective between the DR and the RP results in the effective tunnel MTU being
tunnel MTU being smaller than 1280 (the IPv6 minimum MTU), the DR MUST smaller than 1280 (the IPv6 minimum MTU), the DR MUST send Fragmentation
send Fragmentation Required messages with an MTU value of 1280 and MUST Required messages with an MTU value of 1280 and MUST fragment its PIM
fragment its PIM register messages as required, using an IPv6 register messages as required, using an IPv6 fragmentation header
fragmentation header between the outer IPv6 header and the PIM Register between the outer IPv6 header and the PIM Register header.
header.
Just like any forwarded packet, the TTL of the original data packet is The TTL of a forwarded data packet is decremented before it is |
decremented before it is encapsulated in the Register Tunnel. The encapsulated in the Register Tunnel. The encapsulating packet uses the
encapsulating packet uses the normal TTL that the router would use for normal TTL that the router would use for any locally-generated IP
any locally-generated IP packet. packet.
The IP ECN bits should be copied from the original packet to the IP The IP ECN bits should be copied from the original packet to the IP
header of the encapsulating packet. They SHOULD NOT be set header of the encapsulating packet. They SHOULD NOT be set
independently by the encapsulating router. independently by the encapsulating router.
The Diffserv Code Point (DSCP) should be copied from the original packet The Diffserv Code Point (DSCP) should be copied from the original packet
to the IP header of the encapsulating packet. It MAY be set to the IP header of the encapsulating packet. It MAY be set
independently by the encapsulating router, based upon static independently by the encapsulating router, based upon static
configuration or traffic classification. See [1] for more discussion on configuration or traffic classification. See [10] for more discussion
setting the DSCP on tunnels. on setting the DSCP on tunnels.
Handling Register-Stop(*,G) Messages at the DR Handling Register-Stop(*,G) Messages at the DR
An old RP might send a Register-Stop message with the source address set An old RP might send a Register-Stop message with the source address set
to all-zeros. This was the normal course of action in RFC 2326 when the to all-zeros. This was the normal course of action in RFC 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 Register-Stop(*,G) is ambiguous or incorrect in the behavior of such a Register-Stop(*,G) is ambiguous or incorrect in
some circumstances. some circumstances.
We specify that an RP should not send Register-Stop(*,G) messages, but We specify that an RP should not send Register-Stop(*,G) messages, but
for compatibility, a DR should be able to accept one if it is received. for compatibility, a DR should be able to accept one if it is received.
A Register-Stop(*,G) should be treated as a Register-Stop(S,G) for all A Register-Stop(*,G) should be treated as a Register-Stop(S,G) for all
(S,G) Register state machines that are not in the NoInfo state. A (S,G) Register state machines that are not in the NoInfo state. A
router should not apply a Register-Stop(*,G) to sources that become router should not apply a Register-Stop(*,G) to sources that become
active after the Register-Stop(*,G) was received. active after the Register-Stop(*,G) was received.
skipping to change at page 43, line 13 skipping to change at page 43, line 13
active after the Register-Stop(*,G) was received. active after the Register-Stop(*,G) was received.
4.4.2. Receiving Register Messages at the RP 4.4.2. Receiving Register Messages at the RP
When an RP receives a Register message, the course of action is decided When an RP receives a Register message, the course of action is decided
according to the following pseudocode: according to the following pseudocode:
packet_arrives_on_rp_tunnel( pkt ) { packet_arrives_on_rp_tunnel( pkt ) {
if( outer.dst is not one of my addresses ) { if( outer.dst is not one of my addresses ) {
drop the packet silently. drop the packet silently.
# Note: this should not happen if the lower layer is working properly # Note: this may be a spoofing attempt |
} }
if( I_am_RP(G) AND outer.dst == RP(G) ) { if( I_am_RP(G) AND outer.dst == RP(G) ) {
bool sentRegisterStop = FALSE; sentRegisterStop = FALSE; |
if ( register.borderbit == TRUE ) { |
if ( PMBR(S,G) == unknown ) { |
PMBR(S,G) = outer.src |
} else if ( outer.src != PMBR(S,G) ) { |
send Register-Stop(S,G) to outer.src |
drop the packet silently. |
} |
} |
if ( SPTbit(S,G) OR if ( SPTbit(S,G) OR
( SwitchToSptDesired(S,G) AND ( inherited_olist(S,G) == NULL ))) { ( SwitchToSptDesired(S,G) AND ( inherited_olist(S,G) == NULL ))) {
send Register-Stop(S,G) to outer.src send Register-Stop(S,G) to outer.src
sentRegisterStop = TRUE; sentRegisterStop = TRUE;
} }
if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) { if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) {
if ( sentRegisterStop == TRUE ) { if ( sentRegisterStop == TRUE ) {
restart KeepaliveTimer(S,G) to Keepalive_Period;
} else {
restart KeepaliveTimer(S,G) to RP_Keepalive_Period; restart KeepaliveTimer(S,G) to RP_Keepalive_Period;
} else { |
restart KeepaliveTimer(S,G) to Keepalive_Period; |
} }
} }
if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) { if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) {
decapsulate and pass the inner packet to the normal decapsulate and forward the inner packet to |
forwarding path for forwarding on the (*,G) tree. inherited_olist(S,G,rpt) # Note (+) |
} }
} else { } else {
send Register-Stop(S,G) to outer.src send Register-Stop(S,G) to outer.src
# Note (*) # Note (*)
} }
} }
outer.dst is the IP destination address of the encapsulating header. outer.dst is the IP destination address of the encapsulating header.
outer.src is the IP source address of the encapsulating header, i.e., outer.src is the IP source address of the encapsulating header, i.e.,
skipping to change at page 44, line 7 skipping to change at page 44, line 15
I_am_RP(G) is true if the group-to-RP mapping indicates that this router I_am_RP(G) is true if the group-to-RP mapping indicates that this router
is the RP for the group. is the RP for the group.
Note (*): This may block traffic from S for Register_Suppression_Time if Note (*): This may block traffic from S for Register_Suppression_Time if
the DR learned about a new group-to-RP mapping before the RP did. the DR learned about a new group-to-RP mapping before the RP did.
However, this doesn't matter unless we figure out some way for the However, this doesn't matter unless we figure out some way for the
RP to also accept (*,G) joins when it doesn't yet realize that it RP to also accept (*,G) joins when it doesn't yet realize that it
is about to become the RP for G. This will all get sorted out once is about to become the RP for G. This will all get sorted out once
the RP learns the new group-to-rp mapping. We decided to do the RP learns the new group-to-rp mapping. We decided to do
nothing about this and just accept the fact that PIM may suffer nothing about this and just accept the fact that PIM may suffer
interrupted (*,G) connectivity following an RP change. interrupted (*,G) connectivity following an RP change. |
Note (+): Implementations are advised to not make this a special case, |
but to arrange that this path rejoin the normal packet forwarding |
path. All of the appropriate actions from the "On receipt of data |
from S to G on interface iif" pseudocode in Section 4.2 should be |
performed.
KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the
proper tunnel interface and the RP desires to switch to the SPT or the proper tunnel interface and the RP desires to switch to the SPT or the
SPTbit is already set. This may cause the upstream (S,G) state machine SPTbit is already set. This may cause the upstream (S,G) state machine
to trigger a join if the inherited_olist(S,G) is not NULL; to trigger a join if the inherited_olist(S,G) is not NULL;
An RP should preserve (S,G) state that was created in response to a An RP should preserve (S,G) state that was created in response to a
Register message for at least ( 3 * Register_Suppression_Time ), Register message for at least ( 3 * Register_Suppression_Time ),
otherwise the RP may stop joining (S,G) before the DR for S has otherwise the RP may stop joining (S,G) before the DR for S has
restarted sending registers. Traffic would then be interrupted until restarted sending registers. Traffic would then be interrupted until
the Register-Stop Timer expires at the DR. the Register-Stop Timer expires at the DR.
Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 * Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 *
Register_Suppression_Time + Register_Probe_Time ). Register_Suppression_Time + Register_Probe_Time ).
Just like any forwarded packet, the TTL of the original data packet is When forwarding a packet from the Register Tunnel, the TTL of the |
decremented after it is decapsulated from the Register Tunnel. original data packet is decremented after it is decapsulated.
The IP ECN bits should be copied from the IP header of the Register The IP ECN bits should be copied from the IP header of the Register
packet to the decapsulated packet. packet to the decapsulated packet.
The Diffserv Code Point (DSCP) should be copied from the IP header of The Diffserv Code Point (DSCP) should be copied from the IP header of
the Register packet to the decapsulated packet. The RP MAY retain the the Register packet to the decapsulated packet. The RP MAY retain the
DSCP of the inner packet, or re-classify the packet and apply a DSCP of the inner packet, or re-classify the packet and apply a
different DSCP. Scenarios where each of these might be useful are different DSCP. Scenarios where each of these might be useful are
discussed in [1]. discussed in [10].
4.5. PIM Join/Prune Messages 4.5. PIM Join/Prune Messages
A PIM Join/Prune message consists of a list of groups and a list of A PIM Join/Prune message consists of a list of groups and a list of
Joined and Pruned sources for each group. When processing a received Joined and Pruned sources for each group. When processing a received
Join/Prune message, each Joined or Pruned source for a Group is Join/Prune message, each Joined or Pruned source for a Group is
effectively considered individually, and applies to one or more of the effectively considered individually, and applies to one or more of the
following state machines. When considering a Join/Prune message whose following state machines. When considering a Join/Prune message whose
Upstream Neighbor Address field addresses this router, (*,G) Joins and Upstream Neighbor Address field addresses this router, (*,G) Joins and
Prunes can affect both the (*,G) and (S,G,rpt) downstream state Prunes can affect both the (*,G) and (S,G,rpt) downstream state
machines, while (*,*,RP), (S,G) and (S,G,rpt) Joins and Prunes can only machines, while (*,*,RP), (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 Upstream Neighbor Address field addresses Join/Prune message whose Upstream Neighbor Address field addresses
another router, most Join or Prune messages could affect each upstream another router, most Join or Prune messages could affect each upstream
state machine. state machine.
skipping to change at page 45, line 21 skipping to change at page 45, line 34
be authenticated using IPsec AH. be authenticated using IPsec AH.
We note that some older PIM implementations incorrectly fail to send We note that some older PIM implementations incorrectly fail to send
Hello messages on point-to-point interfaces, so we also RECOMMEND that a Hello messages on point-to-point interfaces, so we also RECOMMEND that a
configuration option be provided to allow interoperation with such older configuration option be provided to allow interoperation with such older
routers, but that this configuration option SHOULD NOT be enabled by routers, but that this configuration option SHOULD NOT be enabled by
default. default.
4.5.1. Receiving (*,*,RP) Join/Prune Messages 4.5.1. Receiving (*,*,RP) Join/Prune Messages
The per-interface state-machine for receiving (*,*,RP) Join/Prune The per-interface state machine for receiving (*,*,RP) Join/Prune
Messages is given below. There are three states: Messages is given below. There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (*,*,RP) Join state and no timers The interface has no (*,*,RP) Join state and no timers
running. running.
Join (J) Join (J)
The interface has (*,*,RP) Join state which will cause us to The interface has (*,*,RP) Join state which will cause the
forward packets destined for any group handled by RP from this router to forward packets destined for any group handled by RP
interface except if there is also (S,G,rpt) prune information from this interface except if there is also (S,G,rpt) prune
(see Section 4.5.4) or the router lost an assert on this information (see Section 4.5.4) or the router lost an assert
interface. on this interface.
Prune-Pending (PP) Prune-Pending (PP)
The router has received a Prune(*,*,RP) on this interface from The router has received a Prune(*,*,RP) on this interface from
a downstream neighbor and is waiting to see whether the prune a downstream neighbor and is waiting to see whether the prune
will be overridden by another downstream router. For will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly forwarding purposes, the Prune-Pending state functions exactly
like the Join state. like the Join state.
In addition, the state-machine uses two timers: In addition, the state machine uses two timers:
ExpiryTimer (ET) ExpiryTimer (ET)
This timer is restarted when a valid Join(*,*,RP) is received. This timer is restarted when a valid Join(*,*,RP) is received.
Expiry of the ExpiryTimer causes the interface state to revert Expiry of the ExpiryTimer causes the interface state to revert
to NoInfo for this RP. to NoInfo for this RP.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(*,*,RP) is received. This timer is set when a valid Prune(*,*,RP) is received.
Expiry of the Prune-Pending Timer causes the interface state Expiry of the Prune-Pending Timer causes the interface state
to revert to NoInfo for this RP. to revert to NoInfo for this RP.
Figure 2: Downstream per-interface (*,*,RP) state-machine in tabular form Figure 2: Downstream per-interface (*,*,RP) state machine in tabular form
+-------------++----------------------------------------------------------+ r+-------------++----------------------------------------------------------+
| || Event | | || Event |
| ++-------------+--------------+--------------+--------------+ | ++-------------+--------------+--------------+--------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer | |Prev State ||Receive | Receive | Prune- | Expiry Timer |
| ||Join(*,*,RP) | Prune | Pending | Expires | | ||Join(*,*,RP) | Prune | Pending | Expires |
| || | (*,*,RP) | Timer | | | || | (*,*,RP) | Timer | |
| || | | Expires | | | || | | Expires | |
|
+-------------++-------------+--------------+--------------+--------------+ +-------------++-------------+--------------+--------------+--------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | | |NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | | | ||Timer | | | |
|
+-------------++-------------+--------------+--------------+--------------+ +-------------++-------------+--------------+--------------+--------------+
| ||-> J state | -> PP state | - | -> NI state | | ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | | |Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | | | ||Expiry Timer | Pending | | |
| || | Timer | | | | || | Timer | | |
|
+-------------++-------------+--------------+--------------+--------------+ +-------------++-------------+--------------+--------------+--------------+
| ||-> J state | -> PP state | -> NI state | -> NI state | |Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
| ||restart | | Send Prune- | | |Pending (PP) ||restart | | Send Prune- | |
| ||Expiry | | Echo(*,*,RP) | | | ||Expiry Timer | | Echo(*,*,RP) | |
|Prune- ||Timer; | | | | |
|Pending (PP) ||cancel | | | |
| ||Prune- | | | |
| ||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 message should be the same as the source address it chose for the Hello message |
it sent over that interface. However on point-to-point links we also it sent over that interface. However on point-to-point links we also |
recommend that PIM Join/Prune messages with a destination address of all
zeros are also accepted. recommend that for backwards compatibility PIM Join/Prune messages with |
a destination address of all zeros are also accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(*,*,RP) Receive Join(*,*,RP)
A Join(*,*,RP) is received on interface I with its Upstream A Join(*,*,RP) is received on interface I with its Upstream
Neighbor Address set to the router's address on I. Neighbor Address set to the router's address on I.
The (*,*,RP) downstream state machine on interface I The (*,*,RP) downstream state machine on interface I
skipping to change at page 49, line 4 skipping to change at page 49, line 10
then the PruneEcho may be received and cause the override to then the PruneEcho may be received and cause the override to
happen. A PruneEcho(*,*,RP) need not be sent on an interface happen. A PruneEcho(*,*,RP) need not be sent on an interface
that contains only a single PIM neighbor during the time this that contains only a single PIM neighbor during the time this
state machine was in Prune-Pending state. state machine was in Prune-Pending state.
4.5.2. Receiving (*,G) Join/Prune Messages 4.5.2. Receiving (*,G) Join/Prune Messages
When a router receives a Join(*,G) or Prune(*,G) it must first check to When a router receives a Join(*,G) 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 who the RP is). If the RP in the message does not match RP(G) the
Join(*,G) or Prune(*,G) should be silently dropped. (Note that other Join(*,G) or Prune(*,G) should be silently dropped. (Note that other
source list entries such as (S,G,rpt) or (S,G) in the same Group source list entries such as (S,G,rpt) or (S,G) in the same Group
Specific Set should still be processed.) If a router has no RP Specific Set should still be processed.) If a router has no RP
information (e.g. has not recently received a BSR message) then it may information (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 choose to accept Join(*,G) or Prune(*,G) and treat the RP in the message
as RP(G). as RP(G).
The per-interface state-machine for receiving (*,G) Join/Prune Messages The per-interface state machine for receiving (*,G) Join/Prune Messages
is given below. There are three states: is given below. There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (*,G) Join state and no timers running. The interface has no (*,G) Join state and no timers running.
Join (J) Join (J)
The interface has (*,G) Join state which will cause us to The interface has (*,G) Join state which will cause the router
forward packets destined for G from this interface except if to forward packets destined for G from this interface except
there is also (S,G,rpt) prune information (see Section 4.5.4) if there is also (S,G,rpt) prune information (see Section
or the router lost an assert on this interface. 4.5.4) or the router lost an assert on this interface.
Prune-Pending (PP) Prune-Pending (PP)
The router has received a Prune(*,G) on this interface from a The router has received a Prune(*,G) on this interface from a
downstream neighbor and is waiting to see whether the prune downstream neighbor and is waiting to see whether the prune
will be overridden by another downstream router. For will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly forwarding purposes, the Prune-Pending state functions exactly
like the Join state. like the Join state.
In addition, the state-machine uses two timers: In addition, the state machine uses two timers:
Expiry Timer (ET) Expiry Timer (ET)
This timer is restarted when a valid Join(*,G) is received. This timer is restarted when a valid Join(*,G) is received.
Expiry of the Expiry Timer causes the interface state to Expiry of the Expiry Timer causes the interface state to
revert to NoInfo for this group. revert to NoInfo for this group.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(*,G) is received. Expiry This timer is set when a valid Prune(*,G) is received. Expiry
of the Prune-Pending Timer causes the interface state to of the Prune-Pending Timer causes the interface state to
revert to NoInfo for this group. revert to NoInfo for this group.
Figure 3: Downstream per-interface (*,G) state-machine in tabular form Figure 3: Downstream per-interface (*,G) state machine in tabular form
+-------------++---------------------------------------------------------+ i+-------------++---------------------------------------------------------+
| || Event | | || Event |
| ++-------------+--------------+-------------+--------------+ | ++-------------+--------------+-------------+--------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer | |Prev State ||Receive | Receive | Prune- | Expiry Timer |
| ||Join(*,G) | Prune(*,G) | Pending | Expires | | ||Join(*,G) | Prune(*,G) | Pending | Expires |
| || | | Timer | | | || | | Timer | |
| || | | Expires | | | || | | Expires | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | | |NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | | | ||Timer | | | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> PP state | - | -> NI state | | ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | | |Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | | | ||Expiry Timer | Pending | | |
| || | Timer | | | | || | Timer | | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> PP state | -> NI state | -> NI state | |Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
| ||restart | | Send Prune- | | |Pending (PP) ||restart | | Send Prune- | |
| ||Expiry | | Echo(*,G) | | | ||Expiry Timer | | Echo(*,G) | |
|Prune- ||Timer; | | | | |
|Pending (PP) ||cancel | | | |
| ||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 message should be the same as the source address it chose for the Hello message |
it sent over that interface. However on point-to-point links we also it sent over that interface. However on point-to-point links we also |
recommend that PIM Join/Prune messages with a destination address of all recommend that for backwards compatibility PIM Join/Prune messages with |
zeros are also accepted. a destination address of all zeros are also accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's address on I. Neighbor Address set to the router's address on I.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I transitions
skipping to change at page 52, line 43 skipping to change at page 52, line 39
The per-interface state machine for receiving (S,G) Join/Prune messages The per-interface state machine for receiving (S,G) Join/Prune messages
is given below, and is almost identical to that for (*,G) messages. is given below, and is almost identical to that for (*,G) messages.
There are three states: There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (S,G) Join state and no (S,G) timers The interface has no (S,G) Join state and no (S,G) timers
running. running.
Join (J) Join (J)
The interface has (S,G) Join state which will cause us to The interface has (S,G) Join state which will cause the router
forward packets from S destined for G from this interface if to forward packets from S destined for G from this interface
the (S,G) state is active (the SPTbit is set) except if the if the (S,G) state is active (the SPTbit is set) except if the
router lost an assert on this interface. router lost an assert on this interface.
Prune-Pending (PP) Prune-Pending (PP)
The router has received a Prune(S,G) on this interface from a The router has received a Prune(S,G) on this interface from a
downstream neighbor and is waiting to see whether the prune downstream neighbor and is waiting to see whether the prune
will be overridden by another downstream router. For will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly forwarding purposes, the Prune-Pending state functions exactly
like the Join state. like the Join state.
In addition, there are two timers: In addition, there are two timers:
skipping to change at page 53, line 18 skipping to change at page 53, line 15
Expiry Timer (ET) Expiry Timer (ET)
This timer is set when a valid Join(S,G) is received. Expiry This timer is set when a valid Join(S,G) is received. Expiry
of the Expiry Timer causes this state machine to revert to of the Expiry Timer causes this state machine to revert to
NoInfo state. NoInfo state.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(S,G) is received. Expiry This timer is set when a valid Prune(S,G) is received. Expiry
of the Prune-Pending Timer causes this state machine to revert of the Prune-Pending Timer causes this state machine to revert
to NoInfo state. to NoInfo state.
Figure 4: Downstream per-interface (S,G) state-machine in tabular form Figure 4: Downstream per-interface (S,G) state machine in tabular form
+-------------++---------------------------------------------------------+ i+-------------++---------------------------------------------------------+
| || Event | | || Event |
| ++-------------+--------------+-------------+--------------+ | ++-------------+--------------+-------------+--------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer | |Prev State ||Receive | Receive | Prune- | Expiry Timer |
| ||Join(S,G) | Prune(S,G) | Pending | Expires | | ||Join(S,G) | Prune(S,G) | Pending | Expires |
| || | | Timer | | | || | | Timer | |
| || | | Expires | | | || | | Expires | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | | |NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | | | ||Timer | | | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> PP state | - | -> NI state | | ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | | |Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | | | ||Expiry Timer | Pending | | |
| || | Timer | | | | || | Timer | | |
|
+-------------++-------------+--------------+-------------+--------------+ +-------------++-------------+--------------+-------------+--------------+
| ||-> J state | -> PP state | -> NI state | -> NI state | |Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
| ||restart | | Send Prune- | | |Pending (PP) ||restart | | Send Prune- | |
| ||Expiry | | Echo(S,G) | | | ||Expiry Timer | | Echo(S,G) | |
|Prune- ||Timer; | | | | |
|Pending (PP) ||cancel | | | |
| ||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 message should be the same as the source address it chose for the Hello message |
it sent over that interface. However on point-to-point links we also it sent over that interface. However on point-to-point links we also |
recommend that PIM Join/Prune messages with a destination address of all recommend that for backwards compatibility PIM Join/Prune messages with |
zeros are also accepted. a destination address of all zeros are also accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(S,G) Receive Join(S,G)
A Join(S,G) is received on interface I with its Upstream A Join(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's address on I. Neighbor Address set to the router's address on I.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I transitions
skipping to change at page 56, line 10 skipping to change at page 55, line 52
4.5.4. Receiving (S,G,rpt) Join/Prune Messages 4.5.4. Receiving (S,G,rpt) Join/Prune Messages
The per-interface state machine for receiving (S,G,rpt) Join/Prune The per-interface state machine for receiving (S,G,rpt) Join/Prune
messages is given below. There are five states: messages is given below. There are five states:
NoInfo (NI) NoInfo (NI)
The interface has no (S,G,rpt) Prune state and no (S,G,rpt) The interface has no (S,G,rpt) Prune state and no (S,G,rpt)
timers running. timers running.
Prune (P) Prune (P)
The interface has (S,G,rpt) Prune state which will cause us The interface has (S,G,rpt) Prune state which will cause the
not to forward packets from S destined for G from this router not to forward packets from S destined for G from this
interface even though the interface has active (*,G) Join interface even though the interface has active (*,G) Join
state. state.
Prune-Pending (PP) Prune-Pending (PP)
The router has received a Prune(S,G,rpt) on this interface The router has received a Prune(S,G,rpt) on this interface
from a downstream neighbor and is waiting to see whether the from a downstream neighbor and is waiting to see whether the
prune will be overridden by another downstream router. For prune will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly forwarding purposes, the Prune-Pending state functions exactly
like the NoInfo state. like the NoInfo state.
skipping to change at page 57, line 5 skipping to change at page 57, line 5
Expiry Timer (ET) Expiry Timer (ET)
This timer is set when a valid Prune(S,G,rpt) is received. This timer is set when a valid Prune(S,G,rpt) is received.
Expiry of the Expiry Timer causes this state machine to revert Expiry of the Expiry Timer causes this state machine to revert
to NoInfo state. to NoInfo state.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(S,G,rpt) is received. This timer is set when a valid Prune(S,G,rpt) is received.
Expiry of the Prune-Pending Timer causes this state machine to Expiry of the Prune-Pending Timer causes this state machine to
move on to Prune state. move on to Prune state.
Figure 5: Downstream per-interface (S,G,rpt) state-machine in tabular form Figure 5: Downstream per-interface (S,G,rpt) state machine in tabular form
+----------++----------------------------------------------------------------+ r+----------++----------------------------------------------------------------+
| || Event | | || Event |
| ++----------+-----------+-----------+---------+---------+---------+ | ++----------+-----------+-----------+---------+---------+---------+
|Prev ||Receive | Receive | Receive | End of | Prune- | Expiry | |Prev ||Receive | Receive | Receive | End of | Prune- | Expiry |
|State ||Join(*,G) | Join | Prune | Message | Pending | Timer | |State ||Join(*,G) | Join | Prune | Message | Pending | Timer |
| || | (S,G,rpt) | (S,G,rpt) | | Timer | Expires | | || | (S,G,rpt) | (S,G,rpt) | | Timer | Expires |
| || | | | | Expires | | | || | | | | Expires | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
| ||- | - | -> PP | - | n/a | n/a | | ||- | - | -> PP | - | - | - |
| || | | state | | | | | || | | state | | | |
| || | | start | | | | | || | | start | | | |
|NoInfo || | | Prune- | | | | |NoInfo || | | Prune- | | | |
|(NI) || | | Pending | | | | |(NI) || | | Pending | | | |
| || | | Timer; | | | | | || | | Timer; | | | |
| || | | start | | | | | || | | start | | | |
| || | | Expiry | | | | | || | | Expiry | | | |
| || | | Timer | | | | | || | | Timer | | | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
| ||-> P' | -> NI | -> P | - | n/a | -> NI | | ||-> P' | -> NI | -> P | - | - | -> NI |
| ||state | state | state | | | state | | ||state | state | state | | | state |
|Prune (P) || | | restart | | | | |Prune (P) || | | restart | | | |
| || | | Expiry | | | | | || | | Expiry | | | |
| || | | Timer | | | | | || | | Timer | | | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
|Prune- ||-> PP' | -> NI | - | - | -> P | n/a | |Prune- ||-> PP' | -> NI | - | - | -> P | - |
|Pending ||state | state | | | state | | |Pending ||state | state | | | state | |
|(PP) || | | | | | | |(PP) || | | | | | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
| ||error | error | -> P | -> NI | n/a | n/a | | ||- | - | -> P | -> NI | - | - |
|Prune-Tmp || | | state | state | | | |Prune-Tmp || | | state | state | | |
|(P') || | | restart | | | | |(P') || | | restart | | | |
| || | | Expiry | | | | | || | | Expiry | | | |
| || | | Timer | | | | | || | | Timer | | | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
| ||error | error | -> PP | -> NI | n/a | n/a | | ||- | - | -> PP | -> NI | - | - |
|Prune- || | | state | state | | | |Prune- || | | state | state | | |
|Pending- || | | restart | | | | |Pending- || | | restart | | | |
|Tmp (PP') || | | Expiry | | | | |Tmp (PP') || | | Expiry | | | |
| || | | Timer | | | | | || | | Timer | | | |
+----------++----------+-----------+-----------+---------+---------+---------+ +----------++----------+-----------+-----------+---------+---------+---------+
The transition events "Receive Join(S,G,rpt)", "Receive Prune(S,G,rpt)", The transition events "Receive Join(S,G,rpt)", "Receive Prune(S,G,rpt)",
and "Receive Join(*,G)" imply receiving a Join or Prune targeted to this and "Receive Join(*,G)" imply receiving a Join or Prune targeted to this
router's address on the received interface. If the destination address router's address on the received interface. If the destination address
is not correct, these state transitions in this state machine must not is not correct, these state transitions in this state machine must not
skipping to change at page 61, line 7 skipping to change at page 61, line 7
off it using Prune(S,G,rpt), then to receive that source again it should off it using Prune(S,G,rpt), then to receive that source again it should
explicitly re-join using Join(S,G,rpt) or Join(*,G). In some LAN explicitly re-join using Join(S,G,rpt) or Join(*,G). In some LAN
topologies it is possible for a router sending a new Join(*,*,RP) to topologies it is possible for a router sending a new Join(*,*,RP) to
have to wait as much as a Join/Prune Interval before noticing that it have to wait as much as a Join/Prune Interval before noticing that it
needs to override a neighbor's pre-existing Prune(S,G,rpt). This is needs to override a neighbor's pre-existing Prune(S,G,rpt). This is
considered acceptable, as (*,*,RP) state is intended to be used only in considered acceptable, as (*,*,RP) state is intended to be used only in
long-lived and persistent scenarios. long-lived and persistent scenarios.
4.5.5. Sending (*,*,RP) Join/Prune Messages 4.5.5. Sending (*,*,RP) Join/Prune Messages
The per-interface state-machines for (*,*,RP) hold join state from The per-interface state machines for (*,*,RP) hold join state from
downstream PIM routers. This state then determines whether a router downstream PIM routers. This state then determines whether a router
needs to propagate a Join(*,*,RP) upstream towards the RP. needs to propagate a Join(*,*,RP) upstream towards the RP.
If a router wishes to propagate a Join(*,*,RP) upstream, it must also If a router wishes to propagate a Join(*,*,RP) upstream, it must also
watch for messages on its upstream interface from other routers on that watch for messages on its upstream interface from other routers on that
subnet, and these may modify its behavior. If it sees a Join(*,*,RP) to subnet, and these may modify its behavior. If it sees a Join(*,*,RP) to
the correct upstream neighbor, it should suppress its own Join(*,*,RP). the correct upstream neighbor, it should suppress its own Join(*,*,RP).
If it sees a Prune(*,*,RP) to the correct upstream neighbor, it should If it sees a Prune(*,*,RP) to the correct upstream neighbor, it should
be prepared to override that prune by sending a Join(*,*,RP) almost be prepared to override that prune by sending a Join(*,*,RP) almost
immediately. Finally, if it sees the Generation ID (see Section 4.3) of immediately. Finally, if it sees the Generation ID (see Section 4.3) of
the correct upstream neighbor change, it knows that the upstream the correct upstream neighbor change, it knows that the upstream
neighbor has lost state, and it should be prepared to refresh the state neighbor has lost state, and it should be prepared to refresh the state
by sending a Join(*,*,RP) almost immediately. by sending a Join(*,*,RP) almost immediately.
In addition, if the MRIB changes to indicate that the next hop towards In addition, if the MRIB changes to indicate that the next hop towards
the RP has changed, the router should prune off from the old next hop, the RP has changed, the router should prune off from the old next hop,
and join towards the new next hop. and join towards the new next hop.
The upstream (*,*,RP) state-machine contains only two states: The upstream (*,*,RP) state machine contains only two states:
Not Joined Not Joined
The downstream state-machines and local membership information do The downstream state machines and local membership information do
not indicate that the router needs to join the (*,*,RP) tree for not indicate that the router needs to join the (*,*,RP) tree for
this RP. this RP.
Joined Joined
The downstream state-machines and local membership information The downstream state machines and local membership information
indicate that the router should join the (*,*,RP) tree for this RP. indicate that the router should join the (*,*,RP) tree for this RP.
In addition, one timer JT(*,*,RP) is kept which is used to trigger the In addition, one timer JT(*,*,RP) is kept which is used to trigger the
sending of a Join(*,*,RP) to the upstream next hop towards the RP, sending of a Join(*,*,RP) to the upstream next hop towards the RP,
NBR(RPF_interface(RP), MRIB.next_hop(RP)). NBR(RPF_interface(RP), MRIB.next_hop(RP)).
Figure 6: Upstream (*,*,RP) state-machine in tabular form Figure 6: Upstream (*,*,RP) state machine in tabular form
+--------------------++-------------------------------------------------+ +--------------------++-------------------------------------------------+
| || Event | | || Event |
| Prev State ++-------------------------+-----------------------+ | Prev State ++-------------------------+-----------------------+
| || JoinDesired | JoinDesired | | || JoinDesired | JoinDesired |
| || (*,*,RP) ->True | (*,*,RP) ->False | | || (*,*,RP) ->True | (*,*,RP) ->False |
|
+--------------------++-------------------------+-----------------------+ +--------------------++-------------------------+-----------------------+
| || -> J state | - | | || -> J state | - |
| NotJoined (NJ) || Send Join(*,*,RP); | | | NotJoined (NJ) || Send Join(*,*,RP); | |
| || Set Join Timer to | | | || Set Join Timer to | |
| || t_periodic | | | || t_periodic | |
|
+--------------------++-------------------------+-----------------------+ +--------------------++-------------------------+-----------------------+
| Joined (J) || - | -> NJ state | | Joined (J) || - | -> NJ state |
| || | Send Prune | | || | Send Prune |
| || | (*,*,RP); Cancel | | || | (*,*,RP); Cancel |
| || | Join Timer | | || | Join Timer |
|
+--------------------++-------------------------+-----------------------+ +--------------------++-------------------------+-----------------------+
In addition, we have the following transitions which occur within the In addition, we have the following transitions which occur within the
Joined state: Joined state:
+-----------------------------------------------------------------------+ i+-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+-------------------+--------------------+------------------------------+ +-------------------+--------------------+------------------------------+
| Timer Expires | See | See | | Timer Expires | See | See |
| | Join(*,*,RP) | Prune(*,*,RP) | | | Join(*,*,RP) | Prune(*,*,RP) |
| | to MRIB. | to MRIB. | | | to MRIB. | to MRIB. |
| | next_hop(RP) | next_hop(RP) | | | next_hop(RP) | next_hop(RP) |
|
+-------------------+--------------------+------------------------------+ +-------------------+--------------------+------------------------------+
| Send | Increase Join | Decrease Join | | Send | Increase Join | Decrease Join |
| Join(*,*,RP); | Timer to | Timer to | | Join(*,*,RP); | Timer to | Timer to |
| Set Join Timer | t_joinsuppress | t_override | | Set Join Timer | t_joinsuppress | t_override |
| to t_periodic | | | | to t_periodic | | |
|
+-------------------+--------------------+------------------------------+ +-------------------+--------------------+------------------------------+
In Joined (J) State T+-----------------------------------------------------------------------+
NBR(RPF_interface(RP), MRIB.next_hop(RP) GenID | In Joined (J) State |
MRIB.next_hop(RP)) changes |
changes +-----------------------------------+-----------------------------------+
Send Join(*,*,RP) to new Decrease Join Timer to | NBR(RPF_interface(RP), | MRIB.next_hop(RP) GenID |
next hop; Send t_override | MRIB.next_hop(RP)) | changes |
Prune(*,*,RP) to old | changes | |
next hop; set Join Timer |
to t_periodic +-----------------------------------+-----------------------------------+
| Send Join(*,*,RP) to new | Decrease Join Timer to |
| | | | next hop; Send | t_override |
| | | | Prune(*,*,RP) to old | |
| | | | next hop; set Join Timer | |
INTERNET-DRAFT Expires: August 2004 February 2004| | to t_periodic | |
| | | |
| | |
+-----------------------------------+-----------------------------------+ +-----------------------------------+-----------------------------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(*,*,RP) { bool JoinDesired(*,*,RP) {
if immediate_olist(*,*,RP) != NULL if immediate_olist(*,*,RP) != NULL
return TRUE return TRUE
else else
return FALSE return FALSE
} }
JoinDesired(*,*,RP) is true when the router has received (*,*,RP) Joins JoinDesired(*,*,RP) is true when the router has received (*,*,RP) Joins
from any downstream interface. Note that although JoinDesired is true, from any downstream interface. Note that although JoinDesired is true,
the router's sending of a Join(*,*,RP) message may be suppressed by the router's sending of a Join(*,*,RP) message may be suppressed by
another router sending a Join(*,*,RP) onto the upstream interface. another router sending a Join(*,*,RP) onto the upstream interface.
Transitions from NotJoined State Transitions from NotJoined State
When the upstream (*,*,RP) state-machine is in NotJoined state, the When the upstream (*,*,RP) state machine is in NotJoined state, the
following event may trigger a state transition: following event may trigger a state transition:
JoinDesired(*,*,RP) becomes True JoinDesired(*,*,RP) becomes True
The downstream state for (*,*,RP) has changed so that at least The downstream state for (*,*,RP) has changed so that at least
one interface is in immediate_olist(*,*,RP), making one interface is in immediate_olist(*,*,RP), making
JoinDesired(*,*,RP) become True. JoinDesired(*,*,RP) become True.
The upstream (*,*,RP) state machine transitions to Joined The upstream (*,*,RP) state machine transitions to Joined
state. Send Join(*,*,RP) to the appropriate upstream state. Send Join(*,*,RP) to the appropriate upstream
neighbor, which is NBR(RPF_interface(RP), MRIB.next_hop(RP)). neighbor, which is NBR(RPF_interface(RP), 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.
Transitions from Joined State Transitions from Joined State
When the upstream (*,*,RP) state-machine is in Joined state, the When the upstream (*,*,RP) state machine is in Joined state, the
following events may trigger state transitions: following events may trigger state transitions:
JoinDesired(*,*,RP) becomes False JoinDesired(*,*,RP) becomes False
The downstream state for (*,*,RP) has changed so no interface The downstream state for (*,*,RP) has changed so no interface
is in immediate_olist(*,*,RP), making JoinDesired(*,*,RP) is in immediate_olist(*,*,RP), making JoinDesired(*,*,RP)
become False. become False.
The upstream (*,*,RP) state machine transitions to NotJoined The upstream (*,*,RP) state machine transitions to NotJoined
state. Send Prune(*,*,RP) to the appropriate upstream state. Send Prune(*,*,RP) to the appropriate upstream
neighbor, which is NBR(RPF_interface(RP), MRIB.next_hop(RP)). neighbor, which is NBR(RPF_interface(RP), MRIB.next_hop(RP)).
skipping to change at page 65, line 16 skipping to change at page 65, line 27
The Generation ID of the router that is MRIB.next_hop(RP) The Generation ID of the router that is MRIB.next_hop(RP)
changes. This normally means that this neighbor has lost changes. This normally means that this neighbor has lost
state, and so the state must be refreshed. state, and so the state must be refreshed.
The upstream (*,*,RP) state machine remains in Joined state. The upstream (*,*,RP) state machine remains in Joined state.
If the Join Timer is set to expire in more than t_override If the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. seconds, reset it so that it expires after t_override seconds.
4.5.6. Sending (*,G) Join/Prune Messages 4.5.6. Sending (*,G) Join/Prune Messages
The per-interface state-machines for (*,G) hold join state from The per-interface state machines for (*,G) hold join state from
downstream PIM routers. This state then determines whether a router downstream PIM routers. This state then determines whether a router
needs to propagate a Join(*,G) upstream towards the RP. needs to propagate a Join(*,G) upstream towards the RP.
If a router wishes to propagate a Join(*,G) upstream, it must also watch If a router wishes to propagate a Join(*,G) upstream, it must also watch
for messages on its upstream interface from other routers on that for messages on its upstream interface from other routers on that
subnet, and these may modify its behavior. If it sees a Join(*,G) to subnet, and these may modify its behavior. If it sees a Join(*,G) to
the correct upstream neighbor, it should suppress its own Join(*,G). If the correct upstream neighbor, it should suppress its own Join(*,G). If
it sees a Prune(*,G) to the correct upstream neighbor, it should be it sees a Prune(*,G) to the correct upstream neighbor, it should be
prepared to override that prune by sending a Join(*,G) almost prepared to override that prune by sending a Join(*,G) almost
immediately. Finally, if it sees the Generation ID (see Section 4.3) of immediately. Finally, if it sees the Generation ID (see Section 4.3) of
skipping to change at page 65, line 41 skipping to change at page 66, line 5
If a (*,G) Assert occurs on the upstream interface, and this changes If a (*,G) Assert occurs on the upstream interface, and this changes
this router's idea of the upstream neighbor, it should be prepared to this router's idea of the upstream neighbor, it should be prepared to
ensure that the Assert winner is aware of downstream routers by sending ensure that the Assert winner is aware of downstream routers by sending
a Join(*,G) almost immediately. a Join(*,G) almost immediately.
In addition, if the MRIB changes to indicate that the next hop towards In addition, if the MRIB changes to indicate that the next hop towards
the RP has changed, and either the upstream interface changes or there the RP has changed, and either the upstream interface changes or there
is no Assert winner on the upstream interface, the router should prune is no Assert winner on the upstream interface, the router should prune
off from the old next hop, and join towards the new next hop. off from the old next hop, and join towards the new next hop.
The upstream (*,G) state-machine only contains two states: The upstream (*,G) state machine only contains two states:
Not Joined Not Joined
The downstream state-machines indicate that the router does not The downstream state machines indicate that the router does not
need to join the RP tree for this group. need to join the RP tree for this group.
Joined Joined
The downstream state-machines indicate that the router should join The downstream state machines indicate that the router should join
the RP tree for this group. the RP tree for this group.
In addition, one timer JT(*,G) is kept which is used to trigger the In addition, one timer JT(*,G) is kept which is used to trigger the
sending of a Join(*,G) to the upstream next hop towards the RP, sending of a Join(*,G) to the upstream next hop towards the RP,
RPF'(*,G). RPF'(*,G).
Figure 7: Upstream (*,G) state-machine in tabular form Figure 7: Upstream (*,G) state machine in tabular form
+--------------------++-------------------------------------------------+ +--------------------++-------------------------------------------------+
| || Event | | || Event |
| Prev State ++------------------------+------------------------+ | Prev State ++------------------------+------------------------+
| || JoinDesired(*,G) | JoinDesired(*,G) | | || JoinDesired(*,G) | JoinDesired(*,G) |
| || ->True | ->False | | || ->True | ->False |
|
+--------------------++------------------------+------------------------+ +--------------------++------------------------+------------------------+
| || -> J state | - | | || -> J state | - |
| NotJoined (NJ) || Send Join(*,G); | | | NotJoined (NJ) || Send Join(*,G); | |
| || Set Join Timer to | | | || Set Join Timer to | |
| || t_periodic | | | || t_periodic | |
|
+--------------------++------------------------+------------------------+ +--------------------++------------------------+------------------------+
| Joined (J) || - | -> NJ state | | Joined (J) || - | -> NJ state |
| || | Send Prune(*,G); | | || | Send Prune(*,G); |
| || | Cancel Join Timer | | || | Cancel Join Timer |
|
+--------------------++------------------------+------------------------+ +--------------------++------------------------+------------------------+
In addition, we have the following transitions which occur within the In addition, we have the following transitions which occur within the
Joined state: Joined state:
+-----------------------------------------------------------------------+ i+-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) | |Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) |
| | to RPF'(*,G) | to RPF'(*,G) | changes due to | | | to RPF'(*,G) | to RPF'(*,G) | changes due to |
| | | | an Assert | | | | | an Assert |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
|Send | Increase Join | Decrease Join | Decrease Join | |Send | Increase Join | Decrease Join | Decrease Join |
|Join(*,G); Set | Timer to | Timer to | Timer to | |Join(*,G); Set | Timer to | Timer to | Timer to |
|Join Timer to | t_joinsuppress | t_override | t_override | |Join Timer to | t_joinsuppress | t_override | t_override |
|t_periodic | | | | |t_periodic | | | |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
+-----------------------------------------------------------------------+ -+-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+----------------------------------+------------------------------------+ +----------------------------------+------------------------------------+
| RPF'(*,G) changes not | RPF'(*,G) GenID changes | | RPF'(*,G) changes not | RPF'(*,G) GenID changes |
| due to an Assert | | | due to an Assert | |
|
+----------------------------------+------------------------------------+ +----------------------------------+------------------------------------+
| Send Join(*,G) to new | Decrease Join Timer to | | Send Join(*,G) to new | Decrease Join Timer to |
| next hop; Send | t_override | | next hop; Send | t_override |
| Prune(*,G) to old next | | | Prune(*,G) to old next | |
| hop; Set Join Timer to | | | hop; Set Join Timer to | |
| t_periodic | | | t_periodic | |
|
+----------------------------------+------------------------------------+ +----------------------------------+------------------------------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(*,G) { bool JoinDesired(*,G) {
if (immediate_olist(*,G) != NULL OR if (immediate_olist(*,G) != NULL OR
(JoinDesired(*,*,RP(G)) AND (JoinDesired(*,*,RP(G)) AND
AssertWinner(*, G, RPF_interface(RP(G))) != NULL)) AssertWinner(*, G, RPF_interface(RP(G))) != NULL))
return TRUE return TRUE
else else
skipping to change at page 68, line 24 skipping to change at page 68, line 24
} }
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
following event may trigger a state transition: following event may trigger a state transition:
JoinDesired(*,G) becomes True JoinDesired(*,G) becomes True
The downstream state for (*,G) has changed so that at least The macro JoinDesired(*,G) becomes True, e.g., because the |
one interface is in immediate_olist(*,G), making downstream state for (*,G) has changed so that at least one |
JoinDesired(*,G) become True. interface is in immediate_olist(*,G).
The upstream (*,G) state machine transitions to Joined state. The upstream (*,G) state machine transitions to Joined state.
Send Join(*,G) to the appropriate upstream neighbor, which is Send Join(*,G) to the appropriate upstream neighbor, which is
RPF'(*,G). Set the Join Timer (JT) to expire after t_periodic RPF'(*,G). Set the Join Timer (JT) to expire after t_periodic
seconds. seconds.
Transitions from Joined State Transitions from Joined State
When the upstream (*,G) state-machine is in Joined state, the following When the upstream (*,G) state machine is in Joined state, the following
events may trigger state transitions: events may trigger state transitions:
JoinDesired(*,G) becomes False JoinDesired(*,G) becomes False
The downstream state for (*,G) has changed so no interface is The macro JoinDesired(*,G) becomes False, e.g., because the |
in immediate_olist(*,G), making JoinDesired(*,G) become False. downstream state for (*,G) has changed so no interface is in |
immediate_olist(*,G).
The upstream (*,G) state machine transitions to NotJoined The upstream (*,G) state machine transitions to NotJoined
state. Send Prune(*,G) to the appropriate upstream neighbor, state. Send Prune(*,G) to the appropriate upstream neighbor,
which is RPF'(*,G). Cancel the Join Timer (JT). which is RPF'(*,G). Cancel the Join Timer (JT).
Join Timer Expires Join Timer Expires
The Join Timer (JT) expires, indicating time to send a The Join Timer (JT) expires, indicating time to send a
Join(*,G) Join(*,G)
Send Join(*,G) to the appropriate upstream neighbor, which is Send Join(*,G) to the appropriate upstream neighbor, which is
RPF'(*,G). Restart the Join Timer (JT) to expire after RPF'(*,G). Restart the Join Timer (JT) to expire after
t_periodic seconds. t_periodic seconds.
See Join(*,G) to RPF'(*,G) See Join(*,G) to RPF'(*,G)
This event is only relevant if RPF_interface(RP(G)) is a This event is only relevant if RPF_interface(RP(G)) is a
shared medium. This router sees another router on shared medium. This router sees another router on
RPF_interface(RP(G)) send a Join(*,G) to RPF'(*,G). This RPF_interface(RP(G)) send a Join(*,G) to RPF'(*,G). This
causes this router to suppress its own Join. causes this router to suppress its own Join.
skipping to change at page 70, line 22 skipping to change at page 70, line 24
The Generation ID of the router that is RPF'(*,G) changes. The Generation ID of the router that is RPF'(*,G) changes.
This normally means that this neighbor has lost state, and so This normally means that this neighbor has lost state, and so
the state must be refreshed. the state must be refreshed.
The upstream (*,G) state machine remains in Joined state. If The upstream (*,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. seconds, reset it so that it expires after t_override seconds.
4.5.7. Sending (S,G) Join/Prune Messages 4.5.7. Sending (S,G) Join/Prune Messages
The per-interface state-machines for (S,G) hold join state from The per-interface state machines for (S,G) hold join state from
downstream PIM routers. This state then determines whether a router downstream PIM routers. This state then determines whether a router
needs to propagate a Join(S,G) upstream towards the source. needs to propagate a Join(S,G) upstream towards the source.
If a router wishes to propagate a Join(S,G) upstream, it must also watch If a router wishes to propagate a Join(S,G) upstream, it must also watch
for messages on its upstream interface from other routers on that for messages on its upstream interface from other routers on that
subnet, and these may modify its behavior. If it sees a Join(S,G) to subnet, and these may modify its behavior. If it sees a Join(S,G) to
the correct upstream neighbor, it should suppress its own Join(S,G). If the correct upstream neighbor, it should suppress its own Join(S,G). If
it sees a Prune(S,G), Prune(S,G,rpt), or Prune(*,G) to the correct it sees a Prune(S,G), Prune(S,G,rpt), or Prune(*,G) to the correct
upstream neighbor towards S, it should be prepared to override that upstream neighbor towards S, it should be prepared to override that
prune by scheduling a Join(S,G) to be sent almost immediately. Finally, prune by scheduling a Join(S,G) to be sent almost immediately. Finally,
skipping to change at page 70, line 47 skipping to change at page 70, line 49
If a (S,G) Assert occurs on the upstream interface, and this changes the If a (S,G) Assert occurs on the upstream interface, and this changes the
this router's idea of the upstream neighbor, it should be prepared to this router's idea of the upstream neighbor, it should be prepared to
ensure that the Assert winner is aware of downstream routers by ensure that the Assert winner is aware of downstream routers by
scheduling a Join(S,G) to be sent almost immediately. scheduling a Join(S,G) to be sent almost immediately.
In addition, if MRIB changes cause the next hop towards the source to In addition, if MRIB changes cause the next hop towards the source to
change, and either the upstream interface changes or there is no Assert change, and either the upstream interface changes or there is no Assert
winner on the upstream interface, the router should send a prune to the winner on the upstream interface, the router should send a prune to the
old next hop, and a join to the new next hop. old next hop, and a join to the new next hop.
The upstream (S,G) state-machine only contains two states: The upstream (S,G) state machine only contains two states:
Not Joined Not Joined
The downstream state machines and local membership information do The downstream state machines and local membership information do
not indicate that the router needs to join the shortest-path tree not indicate that the router needs to join the shortest-path tree
for this (S,G). for this (S,G).
Joined Joined
The downstream state machines and local membership information The downstream state machines and local membership information
indicate that the router should join the shortest-path tree for indicate that the router should join the shortest-path tree for
this (S,G). this (S,G).
In addition, one timer JT(S,G) is kept which is used to trigger the In addition, one timer JT(S,G) is kept which is used to trigger the
sending of a Join(S,G) to the upstream next hop towards S, RPF'(S,G). sending of a Join(S,G) to the upstream next hop towards S, RPF'(S,G).
Figure 8: Upstream (S,G) state-machine in tabular form Figure 8: Upstream (S,G) state machine in tabular form
+--------------------+--------------------------------------------------+ +--------------------+--------------------------------------------------+
| | Event | | | Event |
| Prev State +-------------------------+------------------------+ | Prev State +-------------------------+------------------------+
| | JoinDesired(S,G) | JoinDesired(S,G) | | | JoinDesired(S,G) | JoinDesired(S,G) |
| | ->True | ->False | | | ->True | ->False |
|
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
| NotJoined (NJ) | -> J state | - | | NotJoined (NJ) | -> J state | - |
| | Send Join(S,G); | | | | Send Join(S,G); | |
| | Set Join Timer to | | | | Set Join Timer to | |
| | t_periodic | | | | t_periodic | |
|
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
| Joined (J) | - | -> NJ state | | Joined (J) | - | -> NJ state |
| | | Send Prune(S,G); | | | | Send Prune(S,G); |
| | | Set SPTbit(S,G) to | | | | Set SPTbit(S,G) to |
| | | FALSE; Cancel Join | | | | FALSE; Cancel Join |
| | | Timer | | | | Timer |
|
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
In addition, we have the following transitions which occur within the In addition, we have the following transitions which occur within the
Joined state: Joined state:
+-----------------------------------------------------------------------+ i+-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
| Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune | | Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune |
| | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to | | | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to |
| | | | RPF'(S,G) | | | | | RPF'(S,G) |
|
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
| Send | Increase Join | Decrease Join | Decrease Join | | Send | Increase Join | Decrease Join | Decrease Join |
| Join(S,G); Set | Timer to | Timer to | Timer to | | Join(S,G); Set | Timer to | Timer to | Timer to |
| Join Timer to | t_joinsuppress | t_override | t_override | | Join Timer to | t_joinsuppress | t_override | t_override |
| t_periodic | | | | | t_periodic | | | |
|
+-----------------+-----------------+------------------+----------------+ +-----------------+-----------------+------------------+----------------+
+-----------------------------------------------------------------------+ -+-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
| See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) | | See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) |
| to RPF'(S,G) | changes not | GenID changes | changes due to | | to RPF'(S,G) | changes not | GenID changes | changes due to |
| | due to an | | an Assert | | | due to an | | an Assert |
| | Assert | | | | | Assert | | |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
| Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join | | Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join |
| Timer to | to new next | Timer to | Timer to | | Timer to | to new next | Timer to | Timer to |
| t_override | hop; Send | t_override | t_override | | t_override | hop; Send | t_override | t_override |
| | Prune(S,G) to | | | | | Prune(S,G) to | | |
| | old next hop; | | | | | old next hop; | | |
| | Set Join Timer | | | | | Set Join Timer | | |
| | to t_periodic | | | | | to t_periodic | | |
|
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(S,G) { bool JoinDesired(S,G) {
return( immediate_olist(S,G) != NULL return( immediate_olist(S,G) != NULL
OR ( KeepaliveTimer(S,G) is running OR ( KeepaliveTimer(S,G) is running
AND inherited_olist(S,G) != NULL ) ) AND inherited_olist(S,G) != NULL ) )
} }
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
cause it to forward traffic for G using source tree state. The source cause it to forward traffic for G using source tree state. The source
tree state can either be as a result of active source-specific join tree state can either be as a result of active source-specific join
state, or the (S,G) Keepalive Timer and active non-source-specific state, or the (S,G) Keepalive Timer and active non-source-specific
state. Note that although JoinDesired is true, the router's sending of a state. Note that although JoinDesired is true, the router's sending of a
Join(S,G) message may be suppressed by another router sending a Join(S,G) message may be suppressed by another router sending a
Join(S,G) onto the upstream interface. Join(S,G) onto the upstream interface.
Transitions from NotJoined State Transitions from NotJoined State
When the upstream (S,G) state-machine is in NotJoined state, the When the upstream (S,G) state machine is in NotJoined state, the
following event may trigger a state transition: following event may trigger a state transition:
JoinDesired(S,G) becomes True JoinDesired(S,G) becomes True
The downstream state for (S,G) has changed so that at least The macro JoinDesired(S,G) becomes True, e.g., because the |
one interface is in inherited_olist(S,G), making downstream state for (S,G) has changed so that at least one |
JoinDesired(S,G) become True. interface is in inherited_olist(S,G).
The upstream (S,G) state machine transitions to Joined state. The upstream (S,G) state machine transitions to Joined state.
Send Join(S,G) to the appropriate upstream neighbor, which is Send Join(S,G) to the appropriate upstream neighbor, which is
RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic
seconds. seconds.
Transitions from Joined State Transitions from Joined State
When the upstream (S,G) state-machine is in Joined state, the following When the upstream (S,G) state machine is in Joined state, the following
events may trigger state transitions: events may trigger state transitions:
JoinDesired(S,G) becomes False JoinDesired(S,G) becomes False
The downstream state for (S,G) has changed so no interface is The macro JoinDesired(S,G) becomes False, e.g., because the |
in inherited_olist(S,G), making JoinDesired(S,G) become False. downstream state for (S,G) has changed so no interface is in |
inherited_olist(S,G).
The upstream (S,G) state machine transitions to NotJoined The upstream (S,G) state machine transitions to NotJoined
state. Send Prune(S,G) to the appropriate upstream neighbor, state. Send Prune(S,G) to the appropriate upstream neighbor,
which is RPF'(S,G). Cancel the Join Timer (JT), and set which is RPF'(S,G). Cancel the Join Timer (JT), and set
SPTbit(S,G) to FALSE. SPTbit(S,G) to FALSE.
Join Timer Expires Join Timer Expires
The Join Timer (JT) expires, indicating time to send a The Join Timer (JT) expires, indicating time to send a
Join(S,G) Join(S,G)
skipping to change at page 76, line 29 skipping to change at page 76, line 29
Note that Join(S,G,rpt) is not normally sent as a periodic message, but Note that Join(S,G,rpt) is not normally sent as a periodic message, but
only as a triggered message. only as a triggered message.
4.5.9. State Machine for (S,G,rpt) Triggered Messages 4.5.9. State Machine for (S,G,rpt) Triggered Messages
The state machine for (S,G,rpt) triggered messages is required per-(S,G) The state machine for (S,G,rpt) triggered messages is required per-(S,G)
when there is (*,G) or (*,*,RP) join state at a router, and the router when there is (*,G) or (*,*,RP) join state at a router, and the router
or any of its upstream LAN peers wishes to prune S off the RP tree. or any of its upstream LAN peers wishes to prune S off the RP tree.
There are three states in the state-machine. One of the states is when There are three states in the state machine. One of the states is when
there is neither (*,G) nor (*,*,RP(G)) join state at this router. If there is neither (*,G) nor (*,*,RP(G)) join state at this router. If
there is (*,G) or (*,*,RP(G)) join state at the router, then the state there is (*,G) or (*,*,RP(G)) join state at the router, then the state
machine must be at one of the other two states. The three states are: machine must be at one of the other two states. The three states are:
Pruned(S,G,rpt) Pruned(S,G,rpt)
(*,G) or (*,*,RP(G)) Joined, but (S,G,rpt) pruned (*,G) or (*,*,RP(G)) Joined, but (S,G,rpt) pruned
NotPruned(S,G,rpt) NotPruned(S,G,rpt)
(*,G) or (*,*,RP(G)) Joined, and (S,G,rpt) not pruned (*,G) or (*,*,RP(G)) Joined, and (S,G,rpt) not pruned
RPTNotJoined(G) RPTNotJoined(G)
neither (*,G) nor (*,*,RP(G)) has been joined. neither (*,G) nor (*,*,RP(G)) has been joined.
In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which is In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which is
used to delay triggered Join(S,G,rpt) messages to prevent implosions of used to delay triggered Join(S,G,rpt) messages to prevent implosions of
triggered messages. triggered messages.
Figure 9: Upstream (S,G,rpt) state-machine for triggered messages in Figure 9: Upstream (S,G,rpt) state machine for triggered messages in
tabular form tabular form
+---------------++-------------------------------------------------------------+ +---------------++-------------------------------------------------------------+
| || Event | | || Event |
| ++---------------+---------------+--------------+--------------+ | ++---------------+---------------+--------------+--------------+
|Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ | |Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ |
| || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist | | || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist |
| || ->True | ->False | ->False | (S,G,rpt) | | || ->True | ->False | ->False | (S,G,rpt) |
| || | | | ->non-NULL | | || | | | ->non-NULL |
+---------------++---------------+---------------+--------------+--------------+ ->n+---------------++---------------+---------------+--------------+--------------+
|RPTNotJoined || -> P state | - | - | -> NP state | |RPTNotJoined || -> P state | - | - | -> NP state |
|(G) (NJ) || | | | | |(G) (NJ) || | | | |
+---------------++---------------+---------------+--------------+--------------+ +---------------++---------------+---------------+--------------+--------------+
|Pruned || - | -> NP state | -> NJ state | - | |Pruned || - | -> NP state | -> NJ state | - |
|(S,G,rpt) (P) || | Send Join | | | |(S,G,rpt) (P) || | Send Join | | |
| || | (S,G,rpt) | | | | || | (S,G,rpt) | | |
+---------------++---------------+---------------+--------------+--------------+ +---------------++---------------+---------------+--------------+--------------+
|NotPruned || -> P state | - | -> NJ state | - | |NotPruned || -> P state | - | -> NJ state | - |
|(S,G,rpt) || Send Prune | | Cancel OT | | |(S,G,rpt) || Send Prune | | Cancel OT | |
|(NP) || (S,G,rpt); | | | | |(NP) || (S,G,rpt); | | | |
| || Cancel OT | | | | | || Cancel OT | | | |
+---------------++---------------+---------------+--------------+--------------+ +---------------++---------------+---------------+--------------+--------------+
Additionally, we have the following transitions within the Additionally, we have the following transitions within the
NotPruned(S,G,rpt) state which are all used for prune override behavior. NotPruned(S,G,rpt) state which are all used for prune override behavior.
+-----------------------------------------------------------------------+ t+-----------------------------------------------------------------------+
| In NotPruned(S,G,rpt) State | | In NotPruned(S,G,rpt) State |
|
+-----------+--------------+--------------+--------------+--------------+ +-----------+--------------+--------------+--------------+--------------+
|Override | See Prune | See Join | See Prune | RPF' | |Override | See Prune | See Join | See Prune | RPF' |
|Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> | |Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> |
|expires | RPF' | RPF' | RPF' | RPF' (*,G) | |expires | RPF' | RPF' | RPF' | RPF' (*,G) |
| | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | | | | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | |
|
+-----------+--------------+--------------+--------------+--------------+ +-----------+--------------+--------------+--------------+--------------+
|Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, | |Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, |
|(S,G,rpt); | t_override) | | t_override) | t_override) | |(S,G,rpt); | t_override) | | t_override) | t_override) |
|Leave OT | | | | | |Leave OT | | | | |
|unset | | | | | |unset | | | | |
|
+-----------+--------------+--------------+--------------+--------------+ +-----------+--------------+--------------+--------------+--------------+
Note that the min function in the above state machine considers a non- Note that the min function in the above state machine considers a non-
running timer to have an infinite value (e.g. min(not-running, running timer to have an infinite value (e.g. min(not-running,
t_override) = t_override). t_override) = t_override).
This state machine uses the following macros: This state machine uses the following macros:
bool RPTJoinDesired(G) { bool RPTJoinDesired(G) {
return (JoinDesired(*,G) OR JoinDesired(*,*,RP(G))) return (JoinDesired(*,G) OR JoinDesired(*,*,RP(G)))
skipping to change at page 80, line 48 skipping to change at page 80, line 48
machine for (*,G) or (*,*,RP). machine for (*,G) or (*,*,RP).
inherited_olist(S,G,rpt) becomes non-NULL inherited_olist(S,G,rpt) becomes non-NULL
This transition is only relevant in the RPTNotJoined(G) state. This transition is only relevant in the RPTNotJoined(G) state.
The router has joined the RP tree (handled by the (*,G) or (*,*,RP) The router has joined the RP tree (handled by the (*,G) or (*,*,RP)
upstream state machine as appropriate), and wants to receive upstream state machine as appropriate), and wants to receive
traffic from S. This does not trigger any events in this state traffic from S. This does not trigger any events in this state
machine, but causes a transition to the NotPruned(S,G,rpt) state. machine, but causes a transition to the NotPruned(S,G,rpt) state.
4.5.10. Background: (*,*,RP) and (S,G,rpt) interaction 4.5.10. Background: (*,*,RP) and (S,G,rpt) Interaction
In sections 4.5.8 and 4.5.9 the mechanisms for sending periodic and In sections 4.5.8 and 4.5.9 the mechanisms for sending periodic and
triggered (S,G,rpt) messages are described. The astute reader will note triggered (S,G,rpt) messages are described. The astute reader will note
that periodic Prune(S,G,rpt) messages are only sent in PIM Join/Prune that periodic Prune(S,G,rpt) messages are only sent in PIM Join/Prune
messages containing a Join(*,G), whereas it is possible for a triggered messages containing a Join(*,G), whereas it is possible for a triggered
Prune(S,G,rpt) message to be sent when the router has no (*,G) join Prune(S,G,rpt) message to be sent when the router has no (*,G) join
state. This may seem like a contradiction, but in fact it is state. This may seem like a contradiction, but in fact it is
intentional, and is a side effect of not optimizing (*,*,RP) behavior. intentional, and is a side effect of not optimizing (*,*,RP) behavior.
skipping to change at page 82, line 26 skipping to change at page 82, line 26
election is performed using PIM Assert messages. Assert messages are election is performed using PIM Assert messages. Assert messages are
also received by downstream routers on the LAN, and these cause also received by downstream routers on the LAN, and these cause
subsequent Join/Prune messages to be sent to the upstream router that subsequent Join/Prune messages to be sent to the upstream router that
won the Assert. won the Assert.
In general, a PIM Assert message should only be accepted for processing In general, a PIM Assert message should only be accepted for processing
if it comes from a known PIM neighbor. A PIM router hears about PIM if it comes from a known PIM neighbor. A PIM router hears about PIM
neighbors through PIM Hello messages. If a router receives an Assert neighbors through PIM Hello messages. If a router receives an Assert
message from a particular IP source address and it has not seen a PIM message from a particular IP source address and it has not seen a PIM
Hello message from that source address, then the Assert message SHOULD Hello message from that source address, then the Assert message SHOULD
be discarded without further processing. In addition, if the Hello be discarded without further processing. In addition, if the Hello |
message from a neighbor was authenticated using IPsec AH (see Section message from a neighbor was authenticated using the IPsec Authentication |
6.3) then all Assert messages from that neighbor MUST also be Header (AH) (see Section 6.3) then all Assert messages from that
authenticated using IPsec AH. neighbor MUST also be authenticated using IPsec AH.
We note that some older PIM implementations incorrectly fail to send We note that some older PIM implementations incorrectly fail to send
Hello messages on point-to-point interfaces, so we also RECOMMEND that a Hello messages on point-to-point interfaces, so we also RECOMMEND that a
configuration option be provided to allow interoperation with such older configuration option be provided to allow interoperation with such older
routers, but that this configuration option SHOULD NOT be enabled by routers, but that this configuration option SHOULD NOT be enabled by
default. default.
4.6.1. (S,G) Assert Message State Machine 4.6.1. (S,G) Assert Message State Machine
The (S,G) Assert state machine for interface I is shown in Figure 10. The (S,G) Assert state machine for interface I is shown in Figure 10.
skipping to change at page 84, line 5 skipping to change at page 84, line 5
I am Assert Loser (L) I am Assert Loser (L)
This router has lost an (S,G) assert on interface I. It must not This router has lost an (S,G) assert on interface I. It must not
forward packets from S destined for G onto interface I. If it is forward packets from S destined for G onto interface I. If it is
the DR on I, it is no longer responsible for forwarding traffic the DR on I, it is no longer responsible for forwarding traffic
onto I to satisfy local hosts with membership requests that onto I to satisfy local hosts with membership requests that
specifically refer to S and G. specifically refer to S and G.
In addition, there is also an Assert Timer (AT) that is used to time out In addition, there is also an Assert Timer (AT) that is used to time out
asserts on the assert losers and to resend asserts on the assert winner. asserts on the assert losers and to resend asserts on the assert winner.
Figure 10: Per-interface (S,G) Assert State-machine in tabular form Figure 10: Per-interface (S,G) Assert State machine in tabular form
+-----------------------------------------------------------------------+ F+-----------------------------------------------------------------------+
| In NoInfo (NI) State | | In NoInfo (NI) State |
|
+---------------+-------------------+------------------+----------------+ +---------------+-------------------+------------------+----------------+
| Receive | Receive Assert | Data arrives | Receive | | Receive | Receive Assert | Data arrives | Receive |
| Inferior | with RPTbit | from S to G on | Preferred | | Inferior | with RPTbit | from S to G on | Acceptable |
| Assert with | set and | I and | Assert with | | Assert with | set and | I and | Assert with |
| RPTbit clear | CouldAssert | CouldAssert | RPTbit clear | | RPTbit clear | CouldAssert | CouldAssert | RPTbit clear |
| and | (S,G,I) | (S,G,I) | and AssTrDes | | and | (S,G,I) | (S,G,I) | and AssTrDes |
| CouldAssert | | | (S,G,I) | | CouldAssert | | | (S,G,I) |
| (S,G,I) | | | | | (S,G,I) | | | |
|
+---------------+-------------------+------------------+----------------+ +---------------+-------------------+------------------+----------------+
| -> W state | -> W state | -> W state | -> L state | | -> W state | -> W state | -> W state | -> L state |
| [Actions A1] | [Actions A1] | [Actions A1] | [Actions A6] | | [Actions A1] | [Actions A1] | [Actions A1] | [Actions A6] |
|
+---------------+-------------------+------------------+----------------+ +---------------+-------------------+------------------+----------------+
+-----------------------------------------------------------------------+ -+-----------------------------------------------------------------------+
| In I Am Assert Winner (W) State | | In I Am Assert Winner (W) State |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
| Assert Timer | Receive | Receive | CouldAssert | | Assert Timer | Receive | Receive | CouldAssert |
| Expires | Inferior | Preferred | (S,G,I) -> | | Expires | Inferior | Preferred | (S,G,I) -> |
| | Assert | Assert | FALSE | | | Assert | Assert | FALSE |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
| -> W state | -> W state | -> L state | -> NI state | | -> W state | -> W state | -> L state | -> NI state |
| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] | | [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
+-------------------------------------------------------------------------+ -+-------------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
|
+-------------+--------------+--------------+--------------+--------------+ +-------------+--------------+--------------+--------------+--------------+
|Receive | Receive | Receive | Assert Timer | Current | |Receive | Receive | Receive | Assert Timer | Current |
|Preferred | Acceptable | Inferior | Expires | Winner's | |Preferred | Acceptable | Inferior | Expires | Winner's |
|Assert | Assert from | Assert from | | GenID | |Assert | Assert from | Assert from | | GenID |
| | Current | Current | | Changes or | | | Current | Current | | Changes or |
| | Winner | Winner | | NLT Expires | | | Winner | Winner | | NLT Expires |
|
+-------------+--------------+--------------+--------------+--------------+ +-------------+--------------+--------------+--------------+--------------+
|-> L state | -> L state | -> NI state | -> NI state | -> NI state | |-> L state | -> L state | -> NI state | -> NI state | -> NI state |
|[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] | |[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] |
+-------------+--------------+--------------+--------------+--------------+ A5]+-------------+--------------+--------------+--------------+--------------+
+-----------------------------------------------------------------------+ T+-----------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
|
+----------------+-----------------+-------------------+----------------+ +----------------+-----------------+-------------------+----------------+
| AssTrDes | my_metric -> | RPF_interface | Receive | | AssTrDes | my_metric -> | RPF_interface | Receive |
| (S,G,I) -> | better than | (S) stops | Join(S,G) on | | (S,G,I) -> | better than | (S) stops | Join(S,G) on |
| FALSE | winner's | being I | interface I | | FALSE | winner's | being I | interface I |
| | metric | | | | | metric | | |
|
+----------------+-----------------+-------------------+----------------+ +----------------+-----------------+-------------------+----------------+
| -> NI state | -> NI state | -> NI state | -> NI State | | -> NI state | -> NI state | -> NI state | -> NI State |
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
|
+----------------+-----------------+-------------------+----------------+ +----------------+-----------------+-------------------+----------------+
Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in the Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in the
state-machine table to refer to AssertTrackingDesired(S,G,I). state machine table to refer to AssertTrackingDesired(S,G,I).
Terminology: Terminology:
A "preferred assert" is one with a better metric than the current A "preferred assert" is one with a better metric than the current
winner. winner.
An "acceptable assert" is one that has a better metric than An "acceptable assert" is one that has a better metric than
my_assert_metric(S,G,I). my_assert_metric(S,G,I).
An "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).
skipping to change at page 87, line 21 skipping to change at page 87, line 21
the assert winner. We transition to the "I am Assert Winner" the assert winner. We transition to the "I am Assert Winner"
state, and perform Actions A1 (below). state, and perform Actions A1 (below).
An (S,G) data packet arrives on interface I, AND An (S,G) data packet arrives on interface I, AND
CouldAssert(S,G,I)==TRUE CouldAssert(S,G,I)==TRUE
An (S,G) data packet arrived on an downstream interface which An (S,G) data packet arrived on an downstream interface which
is in our (S,G) outgoing interface list. We optimistically is in our (S,G) outgoing interface list. We optimistically
assume that we will be the assert winner for this (S,G), and assume that we will be the assert winner for this (S,G), and
so we transition to the "I am Assert Winner" state, and so we transition to the "I am Assert Winner" state, and
perform Actions A1 (below) which will initiate the assert perform Actions A1 (below) which will initiate the assert
negotiation for (S,G). negotiation for (S,G). |
Receive Preferred Assert with RPT bit clear AND Receive Acceptable Assert with RPT bit clear AND |
AssertTrackingDesired(S,G,I)==TRUE AssertTrackingDesired(S,G,I)==TRUE |
We're interested in (S,G) Asserts, either because I is a We're interested in (S,G) Asserts, either because I is a
downstream interface for which we have (S,G) or (*,G) downstream interface for which we have (S,G) or (*,G)
forwarding state, or because I is the upstream interface for S forwarding state, or because I is the upstream interface for S
and we have (S,G) forwarding state. The received assert has a and we have (S,G) forwarding state. The received assert has a
better metric than our own, so we do not win the Assert. We better metric than our own, so we do not win the Assert. We
transition to "I am Assert Loser" and perform actions A6 transition to "I am Assert Loser" and perform actions A6
(below). (below).
Transitions from "I am Assert Winner" State Transitions from "I am Assert Winner" State
skipping to change at page 89, line 44 skipping to change at page 89, line 44
We receive a Join(S,G) that has the Upstream Neighbor Address We receive a Join(S,G) that has the Upstream Neighbor Address
field set to one my IP address on interface I. The action is field set to one my IP address on interface I. The action is
to transition to NoInfo state, and delete this (S,G) assert to transition to NoInfo state, and delete this (S,G) assert
state (action A5 below), and allow the normal PIM Join/Prune state (action A5 below), and allow the normal PIM Join/Prune
mechanisms to operate. If whoever sent the Join was in error, mechanisms to operate. If whoever sent the Join was in error,
then the normal assert mechanism will eventually re-apply and then the normal assert mechanism will eventually re-apply and
we will lose the assert again. However whoever sent the we will lose the assert again. However whoever sent the
assert may know that the previous assert winner has died, and assert may know that the previous assert winner has died, and
so we may end up being the new forwarder. so we may end up being the new forwarder.
(S,G) Assert State-machine Actions (S,G) Assert State machine Actions
A1: Send Assert(S,G) A1: Send Assert(S,G)
Set Assert Timer to (Assert_Time - Assert_Override_Interval) Set Assert Timer to (Assert_Time - Assert_Override_Interval)
Store self as AssertWinner(S,G,I) Store self as AssertWinner(S,G,I)
Store spt_assert_metric(S,I) as AssertWinnerMetric(S,G,I) Store spt_assert_metric(S,I) as AssertWinnerMetric(S,G,I)
A2: Store new assert winner as AssertWinner(S,G,I) and assert A2: Store new assert winner as AssertWinner(S,G,I) and assert
winner metric as AssertWinnerMetric(S,G,I). winner metric as AssertWinnerMetric(S,G,I).
Set Assert Timer to Assert_Time Set Assert Timer to Assert_Time
A3: Send Assert(S,G) A3: Send Assert(S,G)
skipping to change at page 90, line 23 skipping to change at page 90, line 23
AssertWinnerMetric(S,G,I) will then return their default AssertWinnerMetric(S,G,I) will then return their default
values). values).
A5: Delete assert info (AssertWinner(S,G,I) and A5: Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return their default AssertWinnerMetric(S,G,I) will then return their default
values). values).
A6: Store new assert winner as AssertWinner(S,G,I) and assert A6: Store new assert winner as AssertWinner(S,G,I) and assert
winner metric as AssertWinnerMetric(S,G,I). winner metric as AssertWinnerMetric(S,G,I).
Set Assert Timer to Assert_Time Set Assert Timer to Assert_Time
If I is RPF_interface(S) set SPTbit(S,G) to TRUE. If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == true) |
set SPTbit(S,G) to TRUE.
Note that some of these actions may cause the value of JoinDesired(S,G), Note that some of these actions may cause the value of JoinDesired(S,G),
PruneDesired(S,G,rpt), or RPF'(S,G) to change, which could cause further PruneDesired(S,G,rpt), or RPF'(S,G) to change, which could cause further
transitions in other state machines. transitions in other state machines.
4.6.2. (*,G) Assert Message State Machine 4.6.2. (*,G) Assert Message State Machine
The (*,G) Assert state-machine for interface I is shown in Figure 11. The (*,G) Assert state machine for interface I is shown in Figure 11.
There are three states: There are three states:
NoInfo (NI) NoInfo (NI)
This router has no (*,G) assert state on interface I. This router has no (*,G) assert state on interface I.
I am Assert Winner (W) I am Assert Winner (W)
This router has won an (*,G) assert on interface I. It is now This router has won an (*,G) assert on interface I. It is now
responsible for forwarding traffic destined for G onto interface I responsible for forwarding traffic destined for G onto interface I
with the exception of traffic for which it has (S,G) "I am Assert with the exception of traffic for which it has (S,G) "I am Assert
Loser" state. Irrespective of whether it is the DR for I, it is Loser" state. Irrespective of whether it is the DR for I, it is
skipping to change at page 91, line 20 skipping to change at page 91, line 20
events in the (S,G) assert state machine and process any transitions and events in the (S,G) assert state machine and process any transitions and
actions, before considering whether the Assert message matches against actions, before considering whether the Assert message matches against
the (*,G) assert state machine. the (*,G) assert state machine.
It is important to note that NO TRANSITION CAN OCCUR in the (*,G) state It is important to note that NO TRANSITION CAN OCCUR in the (*,G) state
machine as a result of receiving an Assert message unless the (S,G) machine as a result of receiving an Assert message unless the (S,G)
assert state machine for the relevant S and G is in the "NoInfo" state assert state machine for the relevant S and G is in the "NoInfo" state
after the (S,G) state machine has processed the message. Also NO after the (S,G) state machine has processed the message. Also NO
TRANSITION CAN OCCUR in the (*,G) state machine as a result of receiving TRANSITION CAN OCCUR in the (*,G) state machine as a result of receiving
an assert message if that message triggers any change of state in the an assert message if that message triggers any change of state in the
(S,G) state machine. (S,G) state machine. Obviously when the source address in the received |
message is set to zero an (S,G) state machine for the S and G does not |
exist and can be assumed to be in the "NoInfo" state.
For example, if both the (S,G) and (*,G) assert state machines where in For example, if both the (S,G) and (*,G) assert state machines where in
the NoInfo state when an Assert message arrives, and the message causes the NoInfo state when an Assert message arrives, and the message causes
the (S,G) state machine to transition to either "W" or "L" state, then the (S,G) state machine to transition to either "W" or "L" state, then
the assert would not be processed by the (*,G) assert state machine. the assert would not be processed by the (*,G) assert state machine.
Another example: if the (S,G) assert state machine is in "L" state when Another example: if the (S,G) assert state machine is in "L" state when
an assert message is received, and the assert metric in the message is an assert message is received, and the assert metric in the message is
worse than my_assert_metric(S,G,I), then the (S,G) assert state machine worse than my_assert_metric(S,G,I), then the (S,G) assert state machine
will transition to NoInfo state. In such a case if the (*,G) assert will transition to NoInfo state. In such a case if the (*,G) assert
state machine were in NoInfo state, it might appear that it would state machine were in NoInfo state, it might appear that it would
transition to "W" state, but this is not the case because this message transition to "W" state, but this is not the case because this message
already triggered a transition in the (S,G) assert state machine. already triggered a transition in the (S,G) assert state machine.
Figure 11: Per-interface (*,G) Assert State-machine in tabular form Figure 11: Per-interface (*,G) Assert State machine in tabular form
+-----------------------------------------------------------------------+ F+-----------------------------------------------------------------------+
| In NoInfo (NI) State | | In NoInfo (NI) State |
|
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+
| Receive Inferior | Data arrives for G | Receive Preferred | | Receive Inferior | Data arrives for G | Receive Acceptable |
| Assert with RPTbit | on I and | Assert with RPTbit | | Assert with RPTbit | on I and | Assert with RPTbit |
| set and | CouldAssert | set and AssTrDes | | set and | CouldAssert | set and AssTrDes |
| CouldAssert(*,G,I) | (*,G,I) | (*,G,I) | | CouldAssert(*,G,I) | (*,G,I) | (*,G,I) |
|
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+
| -> W state | -> W state | -> L state | | -> W state | -> W state | -> L state |
| [Actions A1] | [Actions A1] | [Actions A2] | | [Actions A1] | [Actions A1] | [Actions A2] |
|
+-----------------------+-----------------------+-----------------------+ +-----------------------+-----------------------+-----------------------+
+-----------------------------------------------------------------------+ -+-----------------------------------------------------------------------+
| In I Am Assert Winner (W) State | | In I Am Assert Winner (W) State |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
| Assert Timer | Receive | Receive | CouldAssert | | Assert Timer | Receive | Receive | CouldAssert |
| Expires | Inferior | Preferred | (*,G,I) -> | | Expires | Inferior | Preferred | (*,G,I) -> |
| | Assert | Assert | FALSE | | | Assert | Assert | FALSE |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
| -> W state | -> W state | -> L state | -> NI state | | -> W state | -> W state | -> L state | -> NI state |
| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] | | [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
|
+----------------+------------------+-----------------+-----------------+ +----------------+------------------+-----------------+-----------------+
+-------------------------------------------------------------------------+ -+-------------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
|
+-------------+--------------+--------------+--------------+--------------+ +-------------+--------------+--------------+--------------+--------------+
|Receive | Receive | Receive | Assert Timer | Current | |Receive | Receive | Receive | Assert Timer | Current |
|Preferred | Acceptable | Inferior | Expires | Winner's | |Preferred | Acceptable | Inferior | Expires | Winner's |
|Assert | Assert from | Assert from | | GenID | |Assert | Assert from | Assert from | | GenID |
| | Current | Current | | Changes or | | | Current | Current | | Changes or |
| | Winner | Winner | | NLT Expires | | | Winner | Winner | | NLT Expires |
|
+-------------+--------------+--------------+--------------+--------------+ +-------------+--------------+--------------+--------------+--------------+
|-> L state | -> L state | -> NI state | -> NI state | -> NI state | |-> L state | -> L state | -> NI state | -> NI state | -> NI state |
|[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] | |[Actions A2] | [Actions A2] | [Actions A5] | [Actions A5] | [Actions A5] |
+-------------+--------------+--------------+--------------+--------------+ A5]+-------------+--------------+--------------+--------------+--------------+
+-----------------------------------------------------------------------+ T+-----------------------------------------------------------------------+
| In I Am Assert Loser (L) State | | In I Am Assert Loser (L) State |
|
+----------------+----------------+------------------+------------------+ +----------------+----------------+------------------+------------------+
| AssTrDes | my_metric -> | RPF_interface | Receive | | AssTrDes | my_metric -> | RPF_interface | Receive |
| (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) or | | (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) or |
| FALSE | Winner's | being I | Join | | FALSE | Winner's | being I | Join |
| | metric | | (*,*,RP(G)) on | | | metric | | (*,*,RP(G)) on |
| | | | Interface I | | | | | Interface I |
|
+----------------+----------------+------------------+------------------+ +----------------+----------------+------------------+------------------+
| -> NI state | -> NI state | -> NI state | -> NI State | | -> NI state | -> NI state | -> NI state | -> NI State |
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
|
+----------------+----------------+------------------+------------------+ +----------------+----------------+------------------+------------------+
The state machine uses the following macros: The state machine uses the following macros:
CouldAssert(*,G,I) = CouldAssert(*,G,I) =
( I in ( joins(*,*,RP(G)) (+) joins(*,G) ( I in ( joins(*,*,RP(G)) (+) joins(*,G)
(+) pim_include(*,G)) ) (+) pim_include(*,G)) )
AND (RPF_interface(RP(G)) != I) AND (RPF_interface(RP(G)) != I)
CouldAssert(*,G,I) is true on downstream interfaces for which we have CouldAssert(*,G,I) is true on downstream interfaces for which we have
skipping to change at page 93, line 39 skipping to change at page 93, line 42
AssertTrackingDesired(*,G,I) = AssertTrackingDesired(*,G,I) =
CouldAssert(*,G,I) CouldAssert(*,G,I)
OR (local_receiver_include(*,G,I)==TRUE OR (local_receiver_include(*,G,I)==TRUE
AND (I_am_DR(I) OR AssertWinner(*,G,I) == me)) AND (I_am_DR(I) OR AssertWinner(*,G,I) == me))
OR (RPF_interface(RP(G)) == I AND RPTJoinDesired(G)) OR (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 "acceptable assert" is one that has a better metric than An "acceptable assert" is one that has a better metric than
my_assert_metric(S,G,I). my_assert_metric(S,G,I).
An "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).
skipping to change at page 94, line 26 skipping to change at page 94, line 26
interface, so we should be the assert winner. We transition interface, so we should be the assert winner. We transition
to the "I am Assert Winner" state, and perform Actions A1 to the "I am Assert Winner" state, and perform Actions A1
(below). (below).
A data packet destined for G arrives on interface I, AND A data packet destined for G arrives on interface I, AND
CouldAssert(*,G,I)==TRUE CouldAssert(*,G,I)==TRUE
A data packet destined for G arrived on a downstream interface A data packet destined for G arrived on a downstream interface
which is in our (*,G) outgoing interface list. We therefore which is in our (*,G) outgoing interface list. We therefore
believe we should be the forwarder for this (*,G), and so we believe we should be the forwarder for this (*,G), and so we
transition to the "I am Assert Winner" state, and perform transition to the "I am Assert Winner" state, and perform
Actions A1 (below). Actions A1 (below). |
Receive Preferred Assert with RPT bit set AND Receive Acceptable Assert with RPT bit set AND |
AssertTrackingDesired(*,G,I)==TRUE AssertTrackingDesired(*,G,I)==TRUE |
We're interested in (*,G) Asserts, either because I is a We're interested in (*,G) Asserts, either because I is a
downstream interface for which we have (*,G) forwarding state, downstream interface for which we have (*,G) forwarding state,
or because I is the upstream interface for RP(G) and we have or because I is the upstream interface for RP(G) and we have
(*,G) forwarding state. We get a (*,G) Assert that has a (*,G) forwarding state. We get a (*,G) Assert that has a
better metric than our own, so we do not win the Assert. We better metric than our own, so we do not win the Assert. We
transition to "I am Assert Loser" and perform actions A2 transition to "I am Assert Loser" and perform actions A2
(below). (below).
Transitions from "I am Assert Winner" State Transitions from "I am Assert Winner" State
skipping to change at page 96, line 48 skipping to change at page 96, line 48
Upstream Neighbor Address field set to my IP address on Upstream Neighbor Address field set to my IP address on
interface I. The action is to transition to NoInfo state, and interface I. The action is to transition to NoInfo state, and
delete this (*,G) assert state (action A5), and allow the delete this (*,G) assert state (action A5), and allow the
normal PIM Join/Prune mechanisms to operate. If whoever sent normal PIM Join/Prune mechanisms to operate. If whoever sent
the Join was in error, then the normal assert mechanism will the Join was in error, then the normal assert mechanism will
eventually re-apply and we will lose the assert again. eventually re-apply and we will lose the assert again.
However whoever sent the assert may know that the previous However whoever sent the assert may know that the previous
assert winner has died, and so we may end up being the new assert winner has died, and so we may end up being the new
forwarder. forwarder.
(*,G) Assert State-machine Actions (*,G) Assert State machine Actions
A1: Send Assert(*,G) A1: Send Assert(*,G)
Set Assert Timer to (Assert_Time - Assert_Override_Interval) Set Assert Timer to (Assert_Time - Assert_Override_Interval)
Store self as AssertWinner(*,G,I). Store self as AssertWinner(*,G,I).
Store rpt_assert_metric(G,I) as AssertWinnerMetric(*,G,I). Store rpt_assert_metric(G,I) as AssertWinnerMetric(*,G,I).
A2: Store new assert winner as AssertWinner(*,G,I) and assert A2: Store new assert winner as AssertWinner(*,G,I) and assert
winner metric as AssertWinnerMetric(*,G,I). winner metric as AssertWinnerMetric(*,G,I).
Set Assert Timer to Assert_Time Set Assert Timer to Assert_Time
skipping to change at page 99, line 12 skipping to change at page 99, line 12
An AssertCancel message is simply an RPT Assert message but with An AssertCancel message is simply an RPT Assert message but with
infinite metric. It is sent by the assert winner when it deletes the infinite metric. It is sent by the assert winner when it deletes the
forwarding state that had caused the assert to occur. Other routers forwarding state that had caused the assert to occur. Other routers
will see this metric, and it will cause any other router that has will see this metric, and it will cause any other router that has
forwarding state to send its own assert, and to take over forwarding. forwarding state to send its own assert, and to take over forwarding.
An AssertCancel(S,G) is an infinite metric assert with the RPT bit set An AssertCancel(S,G) is an infinite metric assert with the RPT bit set
that names S as the source. that names S as the source.
An AssertCancel(*,G) is an infinite metric assert with the RPT bit set, An AssertCancel(*,G) is an infinite metric assert with the RPT bit set |
and typically will name RP(G) as the source as it cannot name an and the source set to zero.
appropriate S.
AssertCancel messages are simply an optimization. The original Assert AssertCancel messages are simply an optimization. The original Assert
timeout mechanism will allow a subnet to eventually become consistent; timeout mechanism will allow a subnet to eventually become consistent;
the AssertCancel mechanism simply causes faster convergence. No special the AssertCancel mechanism simply causes faster convergence. No special
processing is required for an AssertCancel message, since it is simply processing is required for an AssertCancel message, since it is simply
an Assert message from the current winner. an Assert message from the current winner.
4.6.5. Assert State Macros 4.6.5. Assert State Macros
The macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and The macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and
skipping to change at page 100, line 4 skipping to change at page 99, line 50
} else { } else {
return ( AssertWinner(S,G,I) != NULL AND return ( AssertWinner(S,G,I) != NULL AND
AssertWinner(S,G,I) != me AND AssertWinner(S,G,I) != me AND
(AssertWinnerMetric(S,G,I) is better (AssertWinnerMetric(S,G,I) is better
than spt_assert_metric(S,I) ) than spt_assert_metric(S,I) )
} }
} }
Note: the term "AssertWinnerMetric(S,G,I) is better than Note: the term "AssertWinnerMetric(S,G,I) is better than
spt_assert_metric(S,I)" is required to correctly handle the transition spt_assert_metric(S,I)" is required to correctly handle the transition
phase when a router has (S,G) join state, but has not yet set the SPT phase when a router has (S,G) join state, but has not yet set the SPT
bit. In this case it needs to ignore the assert state if it will win
bit. In this case it needs to ignore the assert state if it will win |
the assert once the SPT bit is set. the assert once the SPT bit is set.
bool lost_assert(*,G,I) { bool lost_assert(*,G,I) {
if ( RPF_interface(RP(G)) == I ) { if ( RPF_interface(RP(G)) == I ) {
return FALSE return FALSE
} else { } else {
return ( AssertWinner(*,G,I) != NULL AND return ( AssertWinner(*,G,I) != NULL AND
AssertWinner(*,G,I) != me ) AssertWinner(*,G,I) != me )
} }
} }
skipping to change at page 102, line 26 skipping to change at page 102, line 23
Rationale: This prevents the periodic duplicates that would Rationale: This prevents the periodic duplicates that would
otherwise occur each time that an assert times out and is then re- otherwise occur each time that an assert times out and is then re-
established. established.
10. Behavior: When RPF'(S,G,rpt) changes to be the same as RPF'(*,G) we 10. Behavior: When RPF'(S,G,rpt) changes to be the same as RPF'(*,G) we
need to trigger a Join(S,G,rpt) to RPF'(*,G). need to trigger a Join(S,G,rpt) to RPF'(*,G).
Rationale: This allows switching back to the RPT after the last SPT Rationale: This allows switching back to the RPT after the last SPT
member leaves. member leaves.
4.7. PIM Multicast Border Router Behavior 4.7. PIM Bootstrap and RP Discovery
In some cases PIM-SM domains will interconnect with non-PIM domains. In
these cases, the border routers of the PIM domain speak PIM-SM on some
interfaces and speak other multicast routing protocols on other
interfaces. Such routers are termed PIM Multicast Border Routers or
PMBRs. In general, RFC 2715 [11] provides rules for interoperability
between different multicast routing protocols. In this section we
specify how PMBRs differ from regular PIM-SM routers.
From the point of view of PIM-SM, a PMBR has two tasks:
o To ensure that traffic from sources outside the PIM-SM domain reaches
receivers inside the domain.
o To ensure that traffic from sources inside the PIM-SM domain reaches
receivers outside the domain.
We note that multiple PIM-SM domains are sometimes connected together
using protocols such as MSDP, which provides information about active
external sources, but does not follow RFC 2715. In such cases the
domains are not connected via PMBRs because Join(S,G) messages traverse
the border between domains. A PMBR is required when no PIM messages can
traverse the border; typically this is because the routing protocol in
the neighboring domain is not PIM-SM.
4.7.1. Sources External to the PIM-SM Domain
A PMBR needs to ensure that traffic from multicast sources external to
the PIM-SM domain reaches receivers inside the domain. The PMBR will
follow the rules in RFC 2715, such that traffic from external sources
reaches the PMBR itself.
According to RFC 2715, the PIM-SM component of the PMBR will receive an
(S,G) Creation event when data from an (S,G) data packet from an
external source first reaches the PMBR. If RPF_interface(S) is not an
interface in the PIM-SM domain, the packet cannot be originated into the
PIM domain at this router, and the PIM-SM component of the PMBR will not
process the packet. Otherwise the PMBR will then act exactly as if it
were the DR for this source (see Section 4.4.1), with the following
modifications:
o The Border-bit is set in all PIM Register message sent for these
sources.
o DirectlyConnected(S) is treated as being TRUE for these sources.
o The PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to be
TRUE if iif is any interface that is not part of the PIM-SM component
of the PMBR (see Section 4.2).
4.7.2. Sources Internal to the PIM-SM Domain
A PMBR needs to ensure that traffic from sources inside the PIM-SM
domain reaches receivers outside the domain. Using terminology from RFC
2715, there are two possible scenarios for this:
o Another component of the PMBR is a wildcard receiver. In this case
the PIM-SM component of the PMBR must ensure that traffic from all
internal sources reaches the PMBR until it is informed otherwise.
o No other component of the PMBR is a wildcard receiver. In this case
the PMBR will receive explicit information as to which groups or
(source,group) pairs the external domains wish to receive.
In the former case, the PMBR will need to send a Join(*,*,RP) to all the
RPs in the PIM-SM domain. This will cause all traffic in the domain to
reach the PMBR. The PMBR may then act as if it were a DR with directly
connected receivers, and trigger the transition to a shortest path tree
(see Section 4.2.1).
In the latter case, the PMBR will not need to send Join(*,*,RP)
messages. However the PMBR will still need to act as a DR with directly
connected receivers on behalf of the external receivers in terms of
being able to switch to the shortest-path tree for internally-reached
sources.
According to RFC 2715, the PIM-SM component of the PMBR may receive a
number of alerts generated by events in the external routing components.
To implement the above behavior, one reasonable way to map these alerts
into PIM-SM state as follows:
o When a PIM-SM component receives an (S,G) Prune alert, it sets
local_receiver_include(S,G,I) to FALSE for the discard interface.
o When a PIM-SM component receives a (*,G) Prune alert, it sets
local_receiver_include(*,G,I) to FALSE for the discard interface.
o When a PIM-SM component receives an (S,G) Join alert, it sets
local_receiver_include(S,G,I) to TRUE for the discard interface.
o When a PIM-SM component receives a (*,G) Join alert, it sets
local_receiver_include(*,G,I) to TRUE for the discard interface.
o When a PIM-SM component receives a (*,*) Join alert, it sets
DownstreamJPState(*,*,RP,I) to Join state on the discard interface for
all RPs in the PIM-SM domain.
o When a PIM-SM component receives a (*,*) Prune alert, then it sets
DownstreamJPState(*,*,RP,I) to NoInfo state on the discard interface
for all RPs in the PIM-SM domain.
We refer above to the discard interface because the macros and state-
machines are interface-specific, but we need to have PIM state that is
not associated with any actual PIM-SM interface. Implementors are free
to implement this in any reasonable manner.
Note that these state changes will then cause additional PIM-SM state
machine transitions in the normal way.
These rules are however not sufficient to allow pruning off the (*,*,RP)
tree. Some additional rules provide guidance as to one way this may be
done:
o If the PMBR has joined on the (*,*,RP) tree, then it should set
DownstreamJPState(*,G,I) to JOIN on the discard interface for all
active groups.
o If the router receives a (S,G) prune alert it will need to set
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.
o If the router receives a (*,G) prune alert, it will need to set
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface for all
active sources sending to G.
The rationale for this is that there is no way in PIM-SM to prune
traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and then
pruning each source individually.
4.8. 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.
(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 A notable exception to this is where a PIM domain is broken up into
multiple administrative scope regions - these are regions where a border multiple administrative scope regions - these are regions where a border
has been configured so that a range of multicast groups will not be has been configured so that a range of multicast groups will not be
forwarded across that border. For more information on Administratively forwarded across that border. For more information on Administratively
Scoped IP Multicast, see RFC 2365. The modified criteria for admin- Scoped IP Multicast, see RFC 2365. The modified criteria for admin-
scoped regions are that the region is convex with respect to forwarding scoped regions are that the region is convex with respect to forwarding
based on the MRIB, and that all PIM routers within the scope region map based on the MRIB, and that all PIM routers within the scope region map
scoped groups to the same RP within that region. scoped groups to the same RP within that region.
This specification does not mandate the use of a single mechanism to This specification does not mandate the use of a single mechanism to
provide routers with the information to perform the group-to-RP mapping. provide routers with the information to perform the group-to-RP mapping.
Currently three mechanisms are possible, and all three have associated Currently three mechanisms are possible, and all three have associated
problems: problems:
Static Configuration Static Configuration
A PIM router MUST support the static configuration of group-to-RP A PIM router MUST support the static configuration of group-to-RP
mappings. Such a mechanism is not robust to failures, but does at mappings. Such a mechanism is not robust to failures, but does at
least provide a basic interoperability mechanism. least provide a basic interoperability mechanism. |
Embeded-RP |
Embeded-RP defines an address allocation policy in which the |
address of the Rendezvous Point (RP) is encoded in an IPv6 |
multicast group address [15].
Cisco's Auto-RP Cisco's Auto-RP
Auto-RP uses a PIM Dense-Mode multicast group to announce group-to- Auto-RP uses a PIM Dense-Mode multicast group to announce group-to-
RP mappings from a central location. This mechanism is not useful RP mappings from a central location. This mechanism is not useful
if PIM Dense-Mode is not being run in parallel with PIM Sparse- if PIM Dense-Mode is not being run in parallel with PIM Sparse-
Mode, and was only intended for use with PIM Sparse-Mode Version 1. Mode, and was only intended for use with PIM Sparse-Mode Version 1.
No standard specification currently exists. No standard specification currently exists.
BootStrap Router (BSR) BootStrap Router (BSR)
RFC 2362 specifies a bootstrap mechanism based around the automatic RFC 2362 specifies a bootstrap mechanism based around the automatic
skipping to change at page 106, line 17 skipping to change at page 103, line 33
2362, BSR is flawed in its handling of admin-scoped regions that 2362, BSR is flawed in its handling of admin-scoped regions that
are smaller than a PIM domain, but the mechanism does work for are smaller than a PIM domain, but the mechanism does work for
global-scoped groups. global-scoped groups.
As far as PIM-SM is concerned, the only important requirement is that As far as PIM-SM is concerned, the only important requirement is that
all routers in the domain (or admin scope zone for scoped regions) all routers in the domain (or admin scope zone for scoped regions)
receive the same set of group-range-to-RP mappings. This may be receive the same set of group-range-to-RP mappings. This may be
achieved through the use of any of these mechanisms, or through achieved through the use of any of these mechanisms, or through
alternative mechanisms not currently specified. alternative mechanisms not currently specified.
Any RP address configured or learned MUST be a domain-wide reachable It must be operationally ensured that any RP address configured, learned |
address. or advertised is reachable from all routers in the PIM domain.
4.8.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:
skipping to change at page 106, line 46 skipping to change at page 104, line 15
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.8.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/MLD membership given group, e.g. upon reception of a packet or IGMP/MLD 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.
skipping to change at page 107, line 21 skipping to change at page 104, line 36
each router will need to check whether any existing groups are affected. each router will need to check whether any existing groups are affected.
This may, for example, cause a DR or acting DR to re-join a group, or This may, for example, cause a DR or acting DR to re-join a group, or
cause it to re-start register encapsulation to the new RP. cause it to re-start register encapsulation to the new RP.
Implementation note: the bootstrap mechanism described in RFC Implementation note: the bootstrap mechanism described in RFC
2362 omitted step (1) above. However of the implementations 2362 omitted step (1) above. However of the implementations
we are aware of, approximately half performed step (1) anyway. we are aware of, approximately half performed step (1) anyway.
It should be noted that implementations of BSR that omit step It should be noted that implementations of BSR that omit step
1 will not correctly interoperate with implementations of this 1 will not correctly interoperate with implementations of this
specification when used with the BSR mechanism described in specification when used with the BSR mechanism described in
[13]. [11].
4.8.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 addresses of the candidate RPs from the mappings, and gives as output
one RP address to be used. one RP address to be used.
The protocol requires that all routers hash to the same RP within a The protocol requires that all routers hash to the same RP within a
domain (except for transients). The following hash function must be used domain (except for transients). The following hash function must be used
skipping to change at page 108, line 21 skipping to change at page 105, line 37
exclusive-or of each 32-bit segment of the address for all other exclusive-or of each 32-bit segment of the address for all other
IPv6 addresses. For example, the digest of the IPv6 address IPv6 addresses. For example, the digest of the IPv6 address
3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^ 3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^
0x00000000 ^ 0x00000010, where ^ represents the exclusive-or 0x00000000 ^ 0x00000010, where ^ represents the exclusive-or
operation. operation.
2 The candidate RP with the highest resulting hash value is then the 2 The candidate RP with the highest resulting hash value is then the
RP chosen by this Hash Function. If more than one RP has the same RP chosen by this Hash Function. If more than one RP has the same
highest hash value, the RP with the highest IP address is chosen. highest hash value, the RP with the highest IP address is chosen.
4.9. Source-Specific Multicast 4.8. Source-Specific Multicast
The Source-Specific Multicast (SSM) service model [6] can be implemented The Source-Specific Multicast (SSM) service model [5] can be implemented
with a strict subset of the PIM-SM protocol mechanisms. Both regular IP with a strict subset of the PIM-SM protocol mechanisms. Both regular IP
Multicast and SSM semantics can coexist on a single router and both can Multicast and SSM semantics can coexist on a single router and both can
be implemented using the PIM-SM protocol. A range of multicast be implemented using the PIM-SM protocol. A range of multicast |
addresses, currently 232.0.0.0/8 in IPv4, is reserved for SSM, and the addresses, currently 232.0.0.0/8 in IPv4 and FF3x::/32 for IPv6, is |
choice of semantics is determined by the multicast group address in both reserved for SSM, and the choice of semantics is determined by the
data packets and PIM messages. multicast group address in both data packets and PIM messages.
4.9.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 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.
o A router MUST NOT send a Register message for any packet that is o A router MUST NOT send a Register message for any packet that is
destined to an SSM address. destined to an SSM address.
o A router MUST NOT forward packets based on (*,G) or (S,G,rpt) state. o A router MUST NOT forward packets based on (*,G) or (S,G,rpt) state.
The (*,G) and (S,G,rpt) -related state summarization macros are NULL The (*,G) and (S,G,rpt) -related state summarization macros are NULL
skipping to change at page 109, line 20 skipping to change at page 106, line 34
o A router MAY be configured to advertise itself as a Candidate RP for o A router MAY be configured to advertise itself as a Candidate RP for
an SSM address. If so, it SHOULD respond with a Register-Stop message an SSM address. If so, it SHOULD respond with a Register-Stop message
to any Register message containing a packet destined for an SSM to any Register message containing a packet destined for an SSM
address. address.
o A router MAY optimize out the creation and maintenance of (S,G,rpt) o A router MAY optimize out the creation and maintenance of (S,G,rpt)
and (*,G) state for SSM destination addresses -- this state is not and (*,G) state for SSM destination addresses -- this state is not
needed for SSM packets. needed for SSM packets.
4.9.2. PIM-SSM-only Routers 4.8.2. PIM-SSM-only Routers
An implementor may choose to implement only the subset of PIM Sparse- An implementor may choose to implement only the subset of PIM Sparse-
Mode that provides SSM forwarding semantics. Mode that provides SSM forwarding semantics.
A PIM-SSM-only router MUST implement the following portions of this A PIM-SSM-only router MUST implement the following portions of this
specification: specification:
o Upstream (S,G) state machine (Section 4.5.7) o Upstream (S,G) state machine (Section 4.5.7)
o Downstream (S,G) state machine (Section 4.5.3) o Downstream (S,G) state machine (Section 4.5.3)
skipping to change at page 110, line 5 skipping to change at page 107, line 18
o Register state machine (Section 4.4) o Register state machine (Section 4.4)
o (*,G), (S,G,rpt) and (*,*,RP) Downstream state machines (Sections o (*,G), (S,G,rpt) and (*,*,RP) Downstream state machines (Sections
4.5.2, 4.5.4, and 4.5.1) 4.5.2, 4.5.4, and 4.5.1)
o (*,G), (S,G,rpt), and (*,*,RP) Upstream state machines (Sections o (*,G), (S,G,rpt), and (*,*,RP) Upstream state machines (Sections
4.5.6, 4.5.8, and 4.5.5) 4.5.6, 4.5.8, and 4.5.5)
o (*,G) Assert state machine (Section 4.6.2) o (*,G) Assert state machine (Section 4.6.2)
o Bootstrap RP Election (Section 4.8) o Bootstrap RP Election (Section 4.7)
o Keepalive Timer o Keepalive Timer
o SptBit (Section 4.2.2) o SptBit (Section 4.2.2)
The Keepalive Timer should be treated as always running and SptBit The Keepalive Timer should be treated as always running and SptBit
should be treated as being always set for an SSM address. Additionally, should 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- the Packet forwarding rules of Section 4.2 can be simplified in a PIM-
SSM-only router: SSM-only router:
skipping to change at page 110, line 28 skipping to change at page 107, line 41
} 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
} }
oiflist = oiflist (-) iif oiflist = oiflist (-) iif
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.10. 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
skipping to change at page 110, line 39 skipping to change at page 108, line 4
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- The IPv4 `ALL-PIM-ROUTERS' group is `224.0.0.13'. The IPv6 `ALL-PIM-
ROUTERS' group is `ff02::d'. ROUTERS' group is `ff02::d'.
The PIM header common to all PIM messages is:
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:
Message Type Destination Message Type Destination
Mes---------------------------------------------------------------------------
0 = Hello Multicast to ALL-PIM-ROUTERS 0 = Hello Multicast to ALL-PIM-ROUTERS
1 = Register Unicast to RP 1 = Register Unicast to RP
2 = Register-Stop Unicast to source of Register packet 2 = Register-Stop Unicast to source of Register packet
3 = Join/Prune Multicast to ALL-PIM-ROUTERS 3 = Join/Prune Multicast to ALL-PIM-ROUTERS
4 = Bootstrap Multicast to ALL-PIM-ROUTERS 4 = Bootstrap Multicast to ALL-PIM-ROUTERS
5 = Assert Multicast to ALL-PIM-ROUTERS 5 = Assert Multicast to ALL-PIM-ROUTERS
6 = Graft (used in PIM-DM only) Multicast to ALL-PIM-ROUTERS 6 = Graft (used in PIM-DM only) Multicast to ALL-PIM-ROUTERS
7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft packet 7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft packet
8 = Candidate-RP-Advertisement Unicast to Domain's BSR 8 = Candidate-RP-Advertisement Unicast to Domain's BSR
Reserved Reserved
Set to zero on transmission. Ignored upon receipt. Set to zero on transmission. Ignored upon receipt.
Checksum Checksum
The checksum is a standard IP checksum, i.e. the 16-bit one's The checksum is a standard IP checksum, i.e. the 16-bit one's
complement of the one's complement sum of the entire PIM message, complement of the one's complement sum of the entire PIM message,
excluding the "Multicast data packet" section of the Register excluding the "Multicast data packet" section of the Register
message. For computing the checksum, the checksum field is zeroed. message. For computing the checksum, the checksum field is zeroed. |
If the packet's length is not an integral number of 16-bit words, |
the packet is padded with a trailing byte of zero before performing |
the checksum.
For IPv6, the checksum also includes the IPv6 "pseudo-header", as For IPv6, the checksum also includes the IPv6 "pseudo-header", as
specified in RFC 2460, Section 8.1 [4]. This "pseudo-header" is specified in RFC 2460, Section 8.1 [4]. This "pseudo-header" is
prepended to the PIM header for the purposes of calculating the prepended to the PIM header for the purposes of calculating the
checksum. The "Upper-Layer Packet Length" in the pseudo-header is checksum. The "Upper-Layer Packet Length" in the pseudo-header is
set to the length of the PIM message, except in Register messages set to the length of the PIM message, except in Register messages |
where it is set to the length of the PIM header. The Next Header where it is set to the length of the PIM register header (8). The
value used in the pseudo-header is 103. If the packet's length is Next Header value used in the pseudo-header is 103.
not an integral number of 16-bit words, the packet is padded with a
trailing byte of zero before performing the checksum.
If a message is received with an unrecognized PIM Ver or Type field, it If a message is received with an unrecognized PIM Ver or Type field or a |
MUST be discarded and an error message SHOULD be logged to the message's destination does not correspond to the table above, it MUST be
administrator in a rate limited manner. discarded and an error message SHOULD be logged to the administrator in
a rate limited manner.
4.10.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 [7]. Values 128-250 are reserved to be assigned by the Families in [6]. Values 128-250 are reserved to be assigned by the
IANA for PIM-specific Address Families. Values 251 though 255 are IANA for PIM-specific Address Families. Values 251 though 255 are
designated for private use. As there is no assignment authority designated for private use. As there is no assignment authority
for this space, collisions should be expected. for this space, collisions should be expected.
Encoding Type Encoding Type
The type of encoding used within a specific Address Family. The The type of encoding used within a specific Address Family. The
value `0' is reserved for this field, and represents the native value `0' is reserved for this field, and represents the native
encoding of the Address Family. encoding of the Address Family.
Unicast Address Unicast Address
skipping to change at page 113, line 12 skipping to change at page 110, line 24
| Group multicast Address | Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
described above. described above.
Encoding Type Encoding Type
described above. described above.
[B]idirectional PIM [B]idirectional PIM
indicates the group range should use Bidirectional PIM [14]. For indicates the group range should use Bidirectional PIM [12]. For
PIM-SM defined in this specification, this bit MUST be zero. PIM-SM defined in this specification, this bit MUST be zero.
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Admin Scope [Z]one Admin Scope [Z]one
indicates the group range is an admin scope zone. This is used in indicates the group range is an admin scope zone. This is used in
the Bootstrap Router Mechanism [13] only. For all other purposes, the Bootstrap Router Mechanism [11] only. For all other purposes,
this bit is set to zero and ignored on receipt. this bit is set to zero and ignored on receipt.
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
skipping to change at page 114, line 30 skipping to change at page 111, 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.10.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.10.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 equal to the mask length in bits for the given Address MUST be equal to the mask length in bits for the given Address
Family and Encoding Type (32 for IPv4 native and 128 for IPv6 Family and Encoding Type (32 for IPv4 native and 128 for IPv6
native). A router SHOULD ignore any messages received with any native). A router SHOULD ignore any messages received with any
other mask length. other mask length.
Source Address Source Address
The source address. The source address.
4.10.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum | |PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength | | OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 115, line 33 skipping to change at page 112, line 35
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength | | OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue | | OptionValue |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described in Section 4.10. Described in Section 4.9.
OptionType OptionType
The type of the option given in the following OptionValue field. The type of the option given in the following OptionValue field.
OptionLength OptionLength
The length of the OptionValue field in bytes. The length of the OptionValue field in bytes.
OptionValue OptionValue
A variable length field, carrying the value of the option. A variable length field, carrying the value of the option.
skipping to change at page 116, line 31 skipping to change at page 113, line 36
the receiving routers should immediately time out the neighbor the receiving routers should immediately time out the neighbor
information for the sender. information for the sender.
o OptionType 2: LAN Prune Delay o OptionType 2: LAN Prune Delay
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 4 | | Type = 2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| LAN Delay | Override_Interval | |T| Propagation_Delay | Override_Interval | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LAN_Prune_Delay option is used to tune the prune propagation The LAN Prune Delay option is used to tune the prune propagation
delay on multi-access LANs. delay on multi-access LANs. The T bit specifies the ability of
the sending router to disable joins suppression. |
The T bit specifies the ability of the sending router to disable Propagation_Delay and Override_Interval are time intervals in |
joins suppression. units of milliseconds. A router originating a LAN Prune Delay |
option on interface I sets the Propagation_Delay field to the |
LAN Delay and Override_Interval are time intervals in units of configured value of Propagation_Delay(I) and the value of the |
milliseconds are are used to tune the value of the Override_Interval field to the value of Override_Interval(I). On |
Override_Interval(I) and its derived timer values. Section 4.3.3 a receiving router the values of the fields are used to tune the |
describes how these values affect the behavior of a router. value of the Effective_Override_Interval(I) and its derived timer |
values. Section 4.3.3 describes how these values affect the
behavior of a router.
o OptionType 3 to 16: reserved to be defined in future versions of o OptionType 3 to 16: reserved to be defined in future versions of
this document. this document.
o OptionType 18: deprecated and should not be used. o OptionType 18: deprecated and should not be used.
o OptionType 19: DR Priority o OptionType 19: DR Priority
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 19 | Length = 4 | | Type = 19 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DR Priority | | DR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DR Priority is a 32-bit unsigned number and should be considered DR Priority is a 32-bit unsigned number and should be considered
in the DR election as described in Section 4.3.2. in the DR election as described in Section 4.3.2.
skipping to change at page 117, line 49 skipping to change at page 115, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Address N (Encoded-Unicast format) | | Secondary Address N (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the Address List Hello option are described in The contents of the Address List Hello option are described in
Section 4.3.4. All addresses within a single Address List must Section 4.3.4. All addresses within a single Address List must
belong to the same address family. belong to the same address family.
OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes
65001 through 65535 are reserved for Private Use, as defined in 65001 through 65535 are reserved for Private Use, as defined in
[10]. [8].
Unknown options may be ignored. The "Holdtime" option MUST be Unknown options may be ignored. The "Holdtime" option MUST be
implemented; the "DR Priority" and "Generation ID" options SHOULD implemented; the "DR Priority" and "Generation ID" options SHOULD |
be implemented. be implemented. The "Address List" option MUST be implemented for |
IPv6.
4.10.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 in Section 4.10. Note that in order to reduce Described in Section 4.9. Note that in order to reduce
encapsulation overhead, the checksum for Registers is done only on encapsulation overhead, the checksum for Registers is done only on
first 8 bytes of the packet, including the PIM header and the next first 8 bytes of the packet, including the PIM header and the next
4 bytes, excluding the data packet portion. For interoperability 4 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 also be accepted. When calculating the PIM Register message should also be accepted. When calculating the
checksum, the IPv6 pseudoheader "Upper-Layer Packet Length" is set checksum, the IPv6 pseudoheader "Upper-Layer Packet Length" is set
to 8. to 8.
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 119, line 6 skipping to change at page 116, line 13
to 1. to 1.
N The Null-Register bit. Set to 1 by a DR that is probing the RP N The Null-Register bit. Set to 1 by a DR that is probing the RP
before expiring its local Register-Suppression Timer. Set to 0 before expiring its local Register-Suppression Timer. Set to 0
otherwise. otherwise.
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 of the
the same address family as the encapsulating PIM packet, e.g. an same address family as the encapsulating PIM packet, e.g. an IPv6
IPv6 data packet must be encapsulated in an IPv6 PIM packet. Note data packet must be encapsulated in an IPv6 PIM packet. Note that
that the TTL of the original packet is decremented before the TTL of the original packet is decremented before encapsulation,
encapsulation, just like any other packet that is forwarded. In just like any other packet that is forwarded. In addition, the RP
addition, the RP decrements the TTL after decapsulating, before decrements the TTL after decapsulating, before forwarding the
forwarding the packet down the shared tree. 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 a dummy IP header with S as the source address, G as the contains a dummy IP header with S as the source address, G as the
destination address. When generating an IPv4 Null-Register destination address. When generating an IPv4 Null-Register
message, the fields in the dummy IPv4 header SHOULD be filled in message, the fields in the dummy IPv4 header SHOULD be filled in
according to the following table. Other IPv4 header fields may according to the following table. Other IPv4 header fields may
contain any value that is valid for that field. contain any value that is valid for that field.
Field Value Field Value
--------------------------------------- ---------------------------------------
skipping to change at page 120, line 6 skipping to change at page 117, line 15
Header Field Value Header Field Value
-------------------------------------- --------------------------------------
IP Version 6 IP Version 6
Next Header 103 (PIM) Next Header 103 (PIM)
Length 4 Length 4
PIM Version 0 PIM Version 0
PIM Type 0 PIM Type 0
PIM Reserved 0 PIM Reserved 0
PIM Checksum PIM checksum including PIM Checksum PIM checksum including
IPv6 "pseudo-header"; IPv6 "pseudo-header";
see Section 4.10 see Section 4.9
On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM header On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM header
is present, the recipient SHOULD check the checksum and discard is present, the recipient SHOULD check the checksum and discard |
null registers that have a bad checksum. Null-Registers that have a bad checksum.
4.10.4. Register-Stop Message Format 4.9.4. Register-Stop Message Format
A Register-Stop is unicast from the RP to the sender of the Register A Register-Stop is unicast from the RP to the sender of the Register
message. The IP source address is the address to which the register was message. The IP source address is the address to which the register was
addressed. The IP destination address is the source address of the addressed. The IP destination address is the source address of the
register message. register message.
0 1 2 3 0 1 2 3
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described in Section 4.10. Described in Section 4.9.
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.10.1. Note that for Register-Stops Format described in Section 4.9.1. Note that for Register-Stops the
the Mask Len field contains the full address length * 8 (e.g. 32 Mask Len field contains the full address length * 8 (e.g. 32 for
for IPv4 native encoding), if the message is sent for a single IPv4 native encoding), if the message is sent for a single group.
group.
Source Address Source Address
The host address of the source from the multicast data packet in The host address of the source from the multicast data packet in
the register. The format for this address is given in the Encoded- the register. The format for this address is given in the Encoded-
Unicast address in Section 4.10.1. A special wild card value Unicast address in Section 4.9.1. A special wild card value
consisting of an address field of all zeroes can be used to consisting of an address field of all zeroes can be used to
indicate any source. indicate any source.
4.10.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum | |PIM Ver| Type | Reserved | Checksum |
skipping to change at page 122, line 34 skipping to change at page 119, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) | | Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) | | Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address m (Encoded-Group format) | | Multicast Group Address m (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources | | Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) | | Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 123, line 4 skipping to change at page 119, line 52
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) | | Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) | | Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 in Section 4.10. Described in Section 4.9.
Unicast Upstream Neighbor Address Unicast Upstream Neighbor Address
The address of the upstream neighbor that is the target of the The address of the upstream neighbor that is the target of the
message. The format for this address is given in the Encoded- message. The format for this address is given in the Encoded-
Unicast address in Section 4.10.1. For IPv6 the source address used Unicast address in Section 4.9.1. For IPv6 the source address used
for multicast messages is the link-local address of the interface for multicast messages is the link-local address of the interface
on which the message is being sent. For IPv4, the source address on which the message is being sent. For IPv4, the source address
is the primary address associated with that interface. is the primary address associated with that interface.
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
skipping to change at page 123, line 36 skipping to change at page 120, line 34
local policy. This may be used with dial-on-demand links, to avoid local policy. This may be used with dial-on-demand links, to avoid
keeping the link up with periodic Join/Prune messages. keeping the link up with periodic Join/Prune messages.
Note that the HoldTime must be larger than the Note that the HoldTime must be larger than the
J/P_Override_Interval(I). J/P_Override_Interval(I).
Number of Groups Number of Groups
The number of multicast group sets contained in the message. The number of multicast group sets contained in the message.
Multicast group address Multicast group address
For format description see Section 4.10.1. For format description see Section 4.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.
Join Source Address 1 .. n Join Source Address 1 .. n
This list contains the sources that the sending router will forward This list contains the sources that the sending router will forward
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.10.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.
Within one PIM Join/Prune message, all the Multicast Group Addresses, Within one PIM Join/Prune message, all the Multicast Group Addresses,
Joined Source addresses and Pruned Source addresses MUST be of the same Joined Source addresses and Pruned Source addresses MUST be of the same
address family. It is NOT PERMITTED to mix IPv4 and IPv6 addresses address family. It is NOT PERMITTED to mix IPv4 and IPv6 addresses
within the same message. In addition, the address family of the fields within the same message. In addition, the address family of the fields
in the message SHOULD be the same as the IP source and destination in the message SHOULD be the same as the IP source and destination
addresses of the packet. This permits maximum implementation addresses of the packet. This permits maximum implementation
flexibility for dual-stack IPv4/IPv6 routers. If a router receives a flexibility for dual-stack IPv4/IPv6 routers. If a router receives a
message with mixed family addresses, it SHOULD only process the message with mixed family addresses, it SHOULD only process the
addresses which are of the same family as the unicast upstream neighbor addresses which are of the same family as the unicast upstream neighbor
address. address.
4.10.5.1. Group Set Source List Rules 4.9.5.1. Group Set Source List Rules
As described above, Join / Prune messages are composed of one or more As described above, Join / Prune messages are composed of one or more
group sets. Each set contains two source lists, the Join Sources and the group sets. Each set contains two source lists, the Join Sources and the
Prune Sources. This section describes the different types of group sets Prune Sources. This section describes the different types of group sets
and source list entries that can exist in a Join / Prune message. and source list entries that can exist in a Join / Prune message.
There are two valid group set types: There are two valid group set types:
Wildcard Group Set Wildcard Group Set
The wildcard group set is represented by the entire multicast range The wildcard group set is represented by the entire multicast range
skipping to change at page 126, line 32 skipping to change at page 123, line 29
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 would be meaningless. Join would be meaningless.
o As Join / Prune messages are targeted to a single PIM neighbor, o As Join / Prune messages are targeted to a single PIM neighbor,
including both a (S,G) Join and a (S,G,rpt) prune in the same message including both a (S,G) Join and a (S,G,rpt) Prune in the same message
is redundant. The (S,G) Join informs the neighbor that the sender is redundant. The (S,G) Join informs the neighbor that the sender
wishes to receive the particular source on the shortest path tree. It wishes to receive the particular source on the shortest path tree. It
is therefore unnecessary for the router to say that it no longer is therefore unnecessary for the router to say that it no longer
wishes to receive it on the shared tree. wishes to receive it on the shared tree.
o The combination of a (S,G) Prune and a (S,G,rpt) Join could possibly o The combination of a (S,G) Prune and a (S,G,rpt) Join could possibly
be used by a router to switch from receiving a particular source on be used by a router to switch from receiving a particular source on
the shortest-path tree back to receiving it on the shared tree the shortest-path tree back to receiving it on the shared tree
(provided that the RPF neighbor for the shortest-path and shared trees (provided that the RPF neighbor for the shortest-path and shared trees
is common). However Sparse-Mode PIM does not provide a mechanism for is common). However Sparse-Mode PIM does not provide a mechanism for
skipping to change at page 127, line 17 skipping to change at page 124, line 17
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
| ||Join | Prune | Join | Prune | Join | Prune | | ||Join | Prune | Join | Prune | Join | Prune |
| ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) | | ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Join ||- | no | ? | yes | yes | yes | |Join ||- | no | ? | yes | yes | yes |
|(*,G) || | | | | | | |(*,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Prune ||no | - | ? | ? | yes | yes | |Prune ||no | - | ? | ? | yes | yes |
|(*,G) || | | | | | | |(*,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Join ||? | ? | - | no | yes | yes | |Join ||? | ? | - | no | yes | ? |
|(S,G,rpt) || | | | | | | |(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | ? | no | - | ? | ? | |Prune ||yes | ? | no | - | ? | yes |
|(S,G,rpt) || | | | | | | |(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Join ||yes | yes | yes | ? | - | no | |Join ||yes | yes | yes | ? | - | no |
|(S,G) || | | | | | | |(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | yes | yes | ? | no | - | |Prune ||yes | yes | yes | ? | no | - |
|(S,G) || | | | | | | |(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
+---------------++--------------+----------------+------------+ +---------------++--------------+----------------+------------+
skipping to change at page 128, line 8 skipping to change at page 125, line 8
generated by a router. A router MAY accept these messages but the generated by a router. A router MAY accept these messages but the
result is undefined. An error message MAY be logged to the result is undefined. An error message MAY be logged to the
administrator in a rate limited manner. administrator in a rate limited manner.
? 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, except where limited by the packet format itself. important, except where limited by the packet format itself.
4.10.5.2. Group Set Fragmentation 4.9.5.2. Group Set Fragmentation
When building a Join / Prune for a particular neighbor, a router should When building a Join / Prune for a particular neighbor, a router should
try and include in the message as much of the information it needs to try and include in the message as much of the information it needs to
convey to the neighbor as possible. This implies adding one group set convey to the neighbor as possible. This implies adding one group set
for each multicast group that has information pending transmission and for each multicast group that has information pending transmission and
within each set including all relevant source list entries. within each set including all relevant source list entries.
On a router with a large amount of multicast state the number of entries On a router with a large amount of multicast state the number of entries
that must be included may result in packets that are larger than the that must be included may result in packets that are larger than 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
skipping to change at page 128, line 33 skipping to change at page 125, line 33
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 in the router MUST choose to include the first N (numerically smallest in
network byte order) IP addresses. network byte order) IP addresses.
4.10.6. Assert Message Format 4.9.6. Assert Message Format
The Assert message is used to resolve forwarder conflicts between The Assert message is used to resolve forwarder conflicts between
routers on a link. It is sent when a multicast data packet is received routers on a link. It is sent when a multicast data packet is received
on an interface that the router would normally forward that packet. on an interface that the router would normally forward that packet.
Assert messages may also be sent in response to an Assert message from Assert messages may also be sent in response to an Assert message from
another router. another router.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 129, line 20 skipping to change at page 126, line 20
| 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 in Section 4.10. Described in Section 4.9.
Group Address Group Address
The group address for which the router wishes to resolve the The group address for which the router wishes to resolve the
forwarding conflict. This is an Encoded-Group address, as forwarding conflict. This is an Encoded-Group address, as
specified in Section 4.10.1. specified in Section 4.9.1.
Source Address Source Address
Source address for which the router wishes to resolve the Source address for which the router wishes to resolve the
forwarding conflict. The source address MAY be set to zero for forwarding conflict. The source address MAY be set to zero for
(*,G) asserts (see below). The format for this address is given in (*,G) asserts (see below). The format for this address is given in
Encoded-Unicast-Address in Section 4.10.1. Encoded-Unicast-Address in Section 4.9.1.
R RPT-bit is a 1 bit value. The RPT-bit is set to 1 for Assert(*,G) R RPT-bit is a 1 bit value. The RPT-bit is set to 1 for Assert(*,G)
messages and 0 for Assert(S,G) messages. messages and 0 for Assert(S,G) messages.
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 the multicast source or Rendezvous-Point. provided the route to the multicast source or Rendezvous-Point.
Metric Metric
The unicast routing table metric associated with the route used to The unicast routing table metric associated with the route used to
reach the multicast source or Rendezvous-Point. The metric is in reach the multicast source or Rendezvous-Point. The metric is in
units applicable to the unicast routing protocol used. units applicable to the unicast routing protocol used.
Assert messages can be sent to resolve a forwarding conflict for all Assert messages can be sent to resolve a forwarding conflict for all
traffic to given group or for a specific source and group. traffic to given group or for a specific source and group.
Assert(S,G) Assert(S,G)
Source specific asserts are sent by routers forwarding a specific Source specific asserts are sent by routers forwarding a specific |
source on the shortest-path tree (SPT bit is TRUE). (S,G) Asserts source on the shortest-path tree (SPTbit is TRUE). (S,G) Asserts |
have the Group-Address field set to the group G and the Source- have the Group-Address field set to the group G and the Source-
Address field set to the source S. The RPT-bit is set to 0, the Address field set to the source S. The RPT-bit is set to 0, the
Metric-Preference is set to MRIB.pref(S) and the Metric is set to Metric-Preference is set to MRIB.pref(S) and the Metric is set to
MRIB.metric(S). MRIB.metric(S).
Assert(*,G) Assert(*,G)
Group specific asserts are sent by routers forwarding data for the Group specific asserts are sent by routers forwarding data for the
group and source(s) under contention on the shared tree. (*,G) group and source(s) under contention on the shared tree. (*,G)
asserts have the Group-Address field set to the group G. For data asserts have the Group-Address field set to the group G. For data
triggered Asserts the Source-Address field MAY be set to the IP triggered Asserts the Source-Address field MAY be set to the IP
source address of the data packet that triggered the Assert and is source address of the data packet that triggered the Assert and is
set to zero otherwise. The RPT-bit is set to 1, the Metric- set to zero otherwise. The RPT-bit is set to 1, the Metric-
Preference is set to MRIB.pref(RP(G)) and the Metric is set to Preference is set to MRIB.pref(RP(G)) and the Metric is set to
MRIB.metric(RP(G)). MRIB.metric(RP(G)).
4.11. 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
skipping to change at page 131, line 45 skipping to change at page 128, line 45
(S,G) Keepalive Timer: KAT(S,G) (S,G) Keepalive Timer: KAT(S,G)
(S,G,rpt) Upstream Override Timer: OT(S,G,rpt) (S,G,rpt) Upstream Override Timer: OT(S,G,rpt)
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.12. 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.
Note that protocol events or configuration may change the default value Note that protocol events or configuration may change the default value
of a timer on a specific interface. When timers are initialized in this of a timer on a specific interface. When timers are initialized in this
document the value specific to the interface in context must be used. document the value specific to the interface in context must be used.
Some of the timers listed below (Prune-Pending, Upstream Join, Upstream Some of the timers listed below (Prune-Pending, Upstream Join, Upstream
Override) can be set to values which depend on the settings of the Override) can be set to values which depend on the settings of the
Propagation Delay and Override_Interval of the corresponding interface. Propagation_Delay and Override_Interval of the corresponding interface.
The default values for these are given below. Note that the value of The default values for these are given below.
both the Propagation Delay and Override Interval of an interface can
change as a result of receiving Hello messages on that interface
(Section 4.3.3).
Variable Name: Propagation_Delay(I) Variable Name: Propagation_Delay(I)
+-------------------------+-------------------+-------------------------+ r+-------------------------------+---------------+-----------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+-------------------------+-------------------+-------------------------+ |
| LAN_delay_default | 0.5 secs | Expected | +-------------------------------+---------------+-----------------------+
| Propagation_delay_default | 0.5 secs | Expected |
| | | propagation delay | | | | propagation delay |
| | | over the local | | | | over the local |
| | | link. | | | | link. |
+-------------------------+-------------------+-------------------------+ |
+-------------------------------+---------------+-----------------------+
The default value of the LAN_delay_default is chosen to be relatively The default value of the Propagation_delay_default is chosen to be |
large to provide compatibility with older PIM implementations. relatively large to provide compatibility with older PIM |
implementations.
Variable Name: Override_Interval(I) Variable Name: Override_Interval(I)
+--------------------------+-----------------+--------------------------+ r+--------------------------+-----------------+--------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+--------------------------+-----------------+--------------------------+ +--------------------------+-----------------+--------------------------+
| t_override_default | 2.5 secs | Default delay | | t_override_default | 2.5 secs | Default delay |
| | | interval over | | | | interval over |
| | | which to randomize | | | | which to randomize |
| | | when scheduling a | | | | when scheduling a |
| | | delayed Join | | | | delayed Join |
| | | message. | | | | message. |
|
+--------------------------+-----------------+--------------------------+ +--------------------------+-----------------+--------------------------+
Timer Name: Hello Timer (HT(I)) Timer Name: Hello Timer (HT(I))
+----------------------+---------+---------------------------------------+ m+----------------------+---------+---------------------------------------+
|Value Name | Value | Explanation | |Value Name | Value | Explanation |
|
+----------------------+---------+---------------------------------------+ +----------------------+---------+---------------------------------------+
|Hello_Period | 30 secs | Periodic interval for Hello messages. | |Hello_Period | 30 secs | Periodic interval for Hello messages. |
|
+----------------------+---------+---------------------------------------+ +----------------------+---------+---------------------------------------+
|Triggered_Hello_Delay | 5 secs | Randomized interval for initial Hello | |Triggered_Hello_Delay | 5 secs | Randomized interval for initial Hello |
| | | message on bootup or triggered Hello | | | | message on bootup or triggered Hello |
| | | message to a rebooting neighbor. | | | | message to a rebooting neighbor. |
|
+----------------------+---------+---------------------------------------+ +----------------------+---------+---------------------------------------+
At system power-up, the timer is initialized to rand(0, At system power-up, the timer is initialized to rand(0,
Triggered_Hello_Delay) to prevent synchronization. When a new or Triggered_Hello_Delay) to prevent synchronization. When a new or
rebooting neighbor is detected, a responding Hello is sent within rebooting neighbor is detected, a responding Hello is sent within
rand(0, Triggered_Hello_Delay). rand(0, Triggered_Hello_Delay).
Timer Name: Neighbor Liveness Timer (NLT(N,I)) Timer Name: Neighbor Liveness Timer (NLT(N,I))
+--------------------------+-----------------------+--------------------+ m+--------------------------+-----------------------+--------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+--------------------------+-----------------------+--------------------+ +--------------------------+-----------------------+--------------------+
| Default_Hello_Holdtime | 3.5 * Hello_Period | Default holdtime | | Default_Hello_Holdtime | 3.5 * Hello_Period | Default holdtime |
| | | to keep neighbor | | | | to keep neighbor |
| | | state alive | | | | state alive |
|
+--------------------------+-----------------------+--------------------+ +--------------------------+-----------------------+--------------------+
| Hello_Holdtime | from message | Holdtime from | | Hello_Holdtime | from message | Holdtime from |
| | | Hello Message | | | | Hello Message |
| | | Holdtime option. | | | | Holdtime option. |
|
+--------------------------+-----------------------+--------------------+ +--------------------------+-----------------------+--------------------+
The Holdtime in a Hello Message should be set to (3.5 * Hello_Period), The Holdtime in a Hello Message should be set to (3.5 * Hello_Period),
giving a default value of 105 seconds. giving a default value of 105 seconds.
Timer Names: Expiry Timer (ET(*,*,RP,I), ET(*,G,I), ET(S,G,I), Timer Names: Expiry Timer (ET(*,*,RP,I), ET(*,G,I), ET(S,G,I),
ET(S,G,rpt,I)) ET(S,G,rpt,I))
+----------------+-----------------+------------------------------------+ (+----------------+-----------------+------------------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+----------------+-----------------+------------------------------------+ +----------------+-----------------+------------------------------------+
| J/P_HoldTime | from message | Holdtime from Join/Prune Message | | J/P_HoldTime | from message | Holdtime from Join/Prune Message |
|
+----------------+-----------------+------------------------------------+ +----------------+-----------------+------------------------------------+
See details of JT(*,G) for the Holdtime that is included in Join/Prune See details of JT(*,G) for the Holdtime that is included in Join/Prune
Messages. Messages.
Timer Names: Prune-Pending Timer (PPT(*,*,RP,I), PPT(*,G,I), PPT(S,G,I), Timer Names: Prune-Pending Timer (PPT(*,*,RP,I), PPT(*,G,I), PPT(S,G,I),
PPT(S,G,rpt,I)) PPT(S,G,rpt,I))
+-----------------------------+-----------------+-----------------------+ T+---------------------------+---------------------+---------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+-----------------------------+-----------------+-----------------------+ |
+---------------------------+---------------------+---------------------+
| J/P_Override_Interval(I) | Default: | Short period after | | J/P_Override_Interval(I) | Default: | Short period after |
| | Propagation_ | a join or prune to | | | Effective_ | a join or prune to |
| | Delay(I) + | allow other | | | Propagation_ | allow other |
| | Override_ | routers on the LAN | | | Delay(I) + | routers on the LAN |
| | Interval(I) | to override the | | | EffectiveOverride_ | to override the |
| | | join or prune | | | Interval(I) | join or prune |
+-----------------------------+-----------------+-----------------------+ |
+---------------------------+---------------------+---------------------+
Note that both the Propagation_Delay(I) and the Override_Interval(I) are Note that both the Effective_Propagation_Delay(I) and the
interface specific values that may change when Hello messages are Effective_Override_Interval(I) are interface specific values that may
received. change when Hello messages are received (see section 4.3.3).
Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I)) Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))
+---------------------------+----------------------+--------------------+ m+---------------------------+----------------------+--------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
| Assert_Override_Interval | Default: 3 secs | Short interval | | Assert_Override_Interval | Default: 3 secs | Short interval |
| | | before an assert | | | | before an assert |
| | | times out where | | | | times out where |
| | | the assert winner | | | | the assert winner |
| | | resends an Assert | | | | resends an Assert |
| | | message | | | | message |
|
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
| Assert_Time | Default: 180 secs | Period after last | | Assert_Time | Default: 180 secs | Period after last |
| | | assert before | | | | assert before |
| | | assert state is | | | | assert state is |
| | | timed out | | | | timed out |
|
+---------------------------+----------------------+--------------------+ +---------------------------+----------------------+--------------------+
Note that for historical reasons, the Assert message lacks a Holdtime Note that for historical reasons, the Assert message lacks a Holdtime
field. Thus changing the Assert Time from the default value is not field. Thus changing the Assert Time from the default value is not
recommended. recommended.
Timer Names: Upstream Join Timer (JT(*,*,RP), JT(*,G), JT(S,G)) Timer Names: Upstream Join Timer (JT(*,*,RP), JT(*,G), JT(S,G))
+-------------+-------------------+-------------------------------------+ m+-------------+--------------------+-------------------------------------+
|Value Name | Value | Explanation | |Value Name | Value | Explanation |
+-------------+-------------------+-------------------------------------+ |
+-------------+--------------------+-------------------------------------+
|t_periodic | Default: 60 secs | Period between Join/Prune Messages | |t_periodic | Default: 60 secs | Period between Join/Prune Messages |
+-------------+-------------------+-------------------------------------+ |
+-------------+--------------------+-------------------------------------+
|t_suppressed | rand(1.1 * | Suppression period when someone | |t_suppressed | rand(1.1 * | Suppression period when someone |
| | t_periodic, 1.4 * | else sends a J/P message so we | | | t_periodic, 1.4 * | else sends a J/P message so we |
| | t_periodic) when | don't need to do so. | | | t_periodic) when | don't need to do so. |
| | Suppression_ | | | | Suppression_ | |
| | Enabled(I) is | | | | Enabled(I) is | |
| | true, 0 otherwise | | | | true, 0 otherwise | |
+-------------+-------------------+-------------------------------------+ |
|t_override | rand(0, Override_ | Randomized delay to prevent | +-------------+--------------------+-------------------------------------+
| | Interval(I)) | response implosion when sending a | |t_override | rand(0, Effective_ | Randomized delay to prevent |
| | | join message to override someone | | | Override_ | response implosion when sending a |
| | Interval(I)) | join message to override someone |
| | | else's Prune message. | | | | else's Prune message. |
+-------------+-------------------+-------------------------------------+ |
+-------------+--------------------+-------------------------------------+
t_periodic may be set to take into account such things as the configured t_periodic may be set to take into account such things as the configured
bandwidth and expected average number of multicast route entries for the bandwidth and expected average number of multicast route entries for the
attached network or link (e.g., the period would be longer for lower- attached network or link (e.g., the period would be longer for lower-
speed links, or for routers in the center of the network that expect to speed links, or for routers in the center of the network that expect to
have a larger number of entries). If the Join/Prune-Period is modified have a larger number of entries). If the Join/Prune-Period is modified
during operation, these changes should be made relatively infrequently during operation, these changes should be made relatively infrequently
and the router should continue to refresh at its previous Join/Prune- and the router should continue to refresh at its previous Join/Prune-
Period for at least Join/Prune-Holdtime, in order to allow the upstream Period for at least Join/Prune-Holdtime, in order to allow the upstream
router to adapt. router to adapt.
The holdtime specified in a Join/Prune message should be set to (3.5 * The holdtime specified in a Join/Prune message should be set to (3.5 *
t_periodic). t_periodic).
t_override depends on the Override Interval of the upstream interface t_override depends on the Effective_Override_Interval of the upstream |
which may change when Hello messages are received. interface which may change when Hello messages are received.
t_suppressed depends on the Suppression State of the upstream interface t_suppressed depends on the Suppression State of the upstream interface
(Section 4.3.3) and becomes zero when suppression is disabled. (Section 4.3.3) and becomes zero when suppression is disabled.
Timer Name: Upstream Override Timer (OT(S,G,rpt)) Timer Name: Upstream Override Timer (OT(S,G,rpt))
+---------------+---------------------------+---------------------------+ m+---------------+---------------------------+---------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+---------------+---------------------------+---------------------------+ +---------------+---------------------------+---------------------------+
| t_override | see Upstream Join Timer | see Upstream Join Timer | | t_override | see Upstream Join Timer | see Upstream Join Timer |
|
+---------------+---------------------------+---------------------------+ +---------------+---------------------------+---------------------------+
The upstream Override Timer is only ever set to t_override; this value The upstream Override Timer is only ever set to t_override; this value
is defined in the section on Upstream Join Timers. is defined in the section on Upstream Join Timers.
Timer Name: Keepalive Timer (KAT(S,G)) Timer Name: Keepalive Timer (KAT(S,G))
+-----------------------+------------------------+----------------------+ m+-----------------------+------------------------+----------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
|
+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
| Keepalive_Period | Default: 210 secs | Period after last | | Keepalive_Period | Default: 210 secs | Period after last |
| | | (S,G) data packet | | | | (S,G) data packet |
| | | during which (S,G) | | | | during which (S,G) |
| | | Join state will be | | | | Join state will be |
| | | maintained even in | | | | maintained even in |
| | | the absence of | | | | the absence of |
| | | (S,G) Join | | | | (S,G) Join |
| | | messages. | | | | messages. |
|
+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
| RP_Keepalive_Period | ( 3 * Register_ | As | | RP_Keepalive_Period | ( 3 * Register_ | As |
| | Suppression_Time ) | Keepalive_Period, | | | Suppression_Time ) | Keepalive_Period, |
| | + Register_ | but at the RP when | | | + Register_ | but at the RP when |
| | Probe_Time | a Register-Stop is | | | Probe_Time | a Register-Stop is |
| | | sent. | | | | sent. |
|
+-----------------------+------------------------+----------------------+ +-----------------------+------------------------+----------------------+
The normal keepalive period for the KAT(S,G) defaults to 210 seconds. The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
However at the RP, the keepalive period must be at least the However at the RP, the keepalive period must be at least the
Register_Suppression_Time or the RP may time out the (S,G) state before Register_Suppression_Time or the RP may time out the (S,G) state before
the next Null-Register arrives. Thus the KAT(S,G) is set to the next Null-Register arrives. Thus the KAT(S,G) is set to
max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent. max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent.
Timer Name: Register-Stop Timer (RST(S,G)) Timer Name: Register-Stop Timer (RST(S,G))
+----------------------------+--------------------+---------------------+ m+----------------------------+--------------------+---------------------+
|Value Name | Value | Explanation | |Value Name | Value | Explanation |
|
+----------------------------+--------------------+---------------------+ +----------------------------+--------------------+---------------------+
|Register_Suppression_Time | Default: 60 secs | Period during | |Register_Suppression_Time | Default: 60 secs | Period during |
| | | which a DR stops | | | | which a DR stops |
| | | sending Register- | | | | sending Register- |
| | | encapsulated data | | | | encapsulated data |
| | | to the RP after | | | | to the RP after |
| | | receiving a | | | | receiving a |
| | | Register-Stop | | | | Register-Stop |
| | | message. | | | | message. |
|
+----------------------------+--------------------+---------------------+ +----------------------------+--------------------+---------------------+
|Register_Probe_Time | Default: 5 secs | Time before RST | |Register_Probe_Time | Default: 5 secs | Time before RST |
| | | expires when a DR | | | | expires when a DR |
| | | may send a Null- | | | | may send a Null- |
| | | Register to the RP | | | | Register to the RP |
| | | to cause it to | | | | to cause it to |
| | | resend a Register- | | | | resend a Register- |
| | | Stop message. | | | | Stop message. |
|
+----------------------------+--------------------+---------------------+ +----------------------------+--------------------+---------------------+
If the the Register_Suppression_Time or the Register_Probe_Time are |
configured to values other than the defaults it MUST be ensured that the |
value of the Register_Probe_Time is less than half the value of the |
Register_Suppression_Time to prevent a possible negative value in the |
setting of the Register-Stop Timer.
5. IANA Considerations 5. IANA Considerations
5.1. PIM Address Family 5.1. PIM Address Family
The PIM Address Family field was chosen to be 8 bits as a tradeoff The PIM Address Family field was chosen to be 8 bits as a tradeoff
between packet format and use of the IANA assigned numbers. Since when between packet format and use of the IANA assigned numbers. Since when
the PIM packet format was designed only 15 values were assigned for the PIM packet format was designed only 15 values were assigned for
Address Families, and large numbers of new Address Family values were Address Families, and large numbers of new Address Family values were
not envisioned, 8 bits seemed large enough. However, the IANA assigns not envisioned, 8 bits seemed large enough. However, the IANA assigns
Address Families in a 16-bit field. Therefore, the PIM Address Family Address Families in a 16-bit field. Therefore, the PIM Address Family
is allocated as follows: is allocated as follows:
Values 0 through 127 are designated to have the same meaning as Values 0 through 127 are designated to have the same meaning as
IANA-assigned Address Family Numbers [7]. IANA-assigned Address Family Numbers [6].
Values 128 through 250 are designated to be assigned by the IANA Values 128 through 250 are designated to be assigned for PIM by the |
based upon IESG Approval, as defined in [10]. IANA based upon IESG Approval, as defined in [8].
Values 251 through 255 are designated for Private Use, as defined Values 251 through 255 are designated for Private Use, as defined
in [10]. in [8].
5.2. PIM Hello Options 5.2. PIM Hello Options
Values 17 through 65000 are to be assigned by the IANA. Since the space Values 17 through 65000 are to be assigned by the IANA. Since the space
is large, they may be assigned as First Come First Served as defined in is large, they may be assigned as First Come First Served as defined in
[10]. Such assignments are valid for one year, and may be renewed. [8]. 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 [10].) Required" in [8].)
6. Security Considerations 6. Security Considerations
The IPsec authentication header [8] MAY be used to provide data The IPsec authentication header [7] MAY be used to provide data
integrity protection and groupwise data origin authentication of PIM integrity protection and groupwise data origin authentication of PIM
protocol messages. Authentication of PIM messages can protect against protocol messages. Authentication of PIM messages can protect against
unwanted behaviors caused by unauthorized or altered PIM messages. unwanted behaviors caused by unauthorized or altered PIM messages.
6.1. Attacks based on forged messages 6.1. Attacks based on forged messages
The extent of possible damage depends on the type of counterfeit The extent of possible damage depends on the type of counterfeit
messages accepted. We next consider the impact of possible forgeries, messages accepted. We next consider the impact of possible forgeries,
including forged link-local (Join/Prune, Hello, and Assert) and forged including forged link-local (Join/Prune, Hello, and Assert) and forged
unicast (Register and Register-Stop) messages. unicast (Register and Register-Stop) messages.
skipping to change at page 140, line 7 skipping to change at page 137, line 10
An implementation SHOULD provide a mechanism to allow an RP to restrict An implementation SHOULD provide a mechanism to allow an RP to restrict
the range of source addresses from which it accepts Register- the range of source addresses from which it accepts Register-
encapsulated packets. encapsulated packets.
All options that restrict the range of addresses from which packets are All options that restrict the range of addresses from which packets are
accepted MUST default to allowing all packets. accepted MUST default to allowing all packets.
6.3. Authentication using IPsec 6.3. Authentication using IPsec
The IPsec [8] transport mode using the Authentication Header (AH) is the The IPsec [7] transport mode using the Authentication Header (AH) is the
recommended method to prevent the above attacks against PIM. The recommended method to prevent the above attacks against PIM. The
specific AH authentication algorithm and parameters, including the specific AH authentication algorithm and parameters, including the
choice of authentication algorithm and the choice of key, are configured choice of authentication algorithm and the choice of key, are configured
by the network administrator. When IPsec authentication is used, a PIM by the network administrator. When IPsec authentication is used, a PIM
router should reject (drop without processing) any unauthorized PIM router should reject (drop without processing) any unauthorized PIM
protocol messages. protocol messages.
As of this writing, the IPsec anti-replay option does not handle the As of this writing, the IPsec anti-replay option does not handle the
case of a Security Association identified by a multicast destination case of a Security Association identified by a multicast destination
address. Thus, the anti-replay option currently must be disabled on address. Thus, the anti-replay option currently must be disabled on
these Security Associations. Until replay prevention for link-local these Security Associations. Until replay prevention for link-local
multicast messages is addressed (one such proposal is [9] ), the anti- multicast messages is addressed (one such proposal is [14]), the anti-
replay option SHOULD be enabled on all security associations having a replay option SHOULD be enabled on all security associations having a
unicast destination address. unicast destination address.
To use IPsec, the administrator of a PIM network configures each PIM To use IPsec, the administrator of a PIM network configures each PIM
router with one or more Security Associations and associated SPI(s) that router with one or more Security Associations and associated SPI(s) that
are used by senders to sign PIM protocol messages and are used by are used by senders to sign PIM protocol messages and are used by
receivers to authenticate received PIM protocol messages. This document receivers to authenticate received PIM protocol messages. This document
does not describe protocols for establishing Security Associations. It does not describe protocols for establishing Security Associations. It
assumes that manual configuration of Security Associations is performed, assumes that manual configuration of Security Associations is performed,
but it does not preclude the use of a negotiation protocol such as The but it does not preclude the use of a negotiation protocol such as The
Internet Key Exchange [15] to establish Security Associations. Internet Key Exchange [13] to establish Security Associations.
The following sections describe the Security Associations required to The following sections describe the Security Associations required to
protect PIM protocol messages. protect PIM protocol messages.
6.3.1. Protecting link-local multicast messages 6.3.1. Protecting link-local multicast messages
The network administrator defines a Security Association (SA) and The network administrator defines a Security Association (SA) and
Security Parameters Index (SPI) that is to be used to authenticate all Security Parameters Index (SPI) that is to be used to authenticate all
link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each
link in a PIM domain. All link-local PIM protocol messages use SPI 0. link in a PIM domain. All link-local PIM protocol messages use SPI 0.
The Security Policy Database at a PIM router should be configured to The Security Policy Database at a PIM router should be configured to
ensure that all incoming and outgoing Join/Prune, Assert, and Hello ensure that all incoming and outgoing Join/Prune, Assert, and Hello
packets use the SA associated with the interface to which the packet is packets use the SA associated with the interface to which the packet is
sent. sent.
Note that, according to [8] there is nominally a different Security Note that, according to [7] there is nominally a different Security
Association Database (SAD) for each router interface. Thus, the Association Database (SAD) for each router interface. Thus, the
selected Security Association for an inbound PIM packet can vary selected Security Association for an inbound PIM packet can vary
depending on the interface on which the packet arrived. This fact depending on the interface on which the packet arrived. This fact
allows the network administrator to use different authentication methods allows the network administrator to use different authentication methods
for each link, even though the destination address is the same for all for each link, even though the destination address is the same for all
link-local PIM packets, regardless of interface. link-local PIM packets, regardless of interface.
6.3.2. Protecting unicast messages 6.3.2. Protecting unicast messages
IPSec can also be used to provide data origin authentication and data IPSec can also be used to provide data origin authentication and data
integrity protection for the Register and Register-Stop unicast integrity protection for the Register and Register-Stop unicast
messages. messages.
6.3.2.1. Register messages 6.3.2.1. Register messages
skipping to change at page 142, line 38 skipping to change at page 139, line 40
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
ICIR/ICSI Department of Computer Science
1947 Center St, Suite 600 University College London
Berkeley, CA 94708 Gower Street
mjh@icir.org London WC1E 6BT
United Kingdom
M.Handley@cs.ucl.ac.uk
Hugh Holbrook Hugh Holbrook
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
holbrook@cisco.com holbrook@cisco.com
Isidor Kouvelas Isidor Kouvelas
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
kouvelas@cisco.com kouvelas@cisco.com
8. Acknowledgments 8. Acknowledgments
PIM-SM was designed over many years by a large group of people, PIM-SM was designed over many years by a large group of people,
including ideas, comments, and corrections from Deborah Estrin, Dino including ideas, comments, and corrections from Deborah Estrin, Dino
skipping to change at page 143, line 18 skipping to change at page 140, line 24
kouvelas@cisco.com kouvelas@cisco.com
8. Acknowledgments 8. Acknowledgments
PIM-SM was designed over many years by a large group of people, PIM-SM was designed over many years by a large group of people,
including ideas, comments, and corrections from Deborah Estrin, Dino including ideas, comments, and corrections from Deborah Estrin, Dino
Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C. Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C.
Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott
Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly
Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian
Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike |
Davison and James Lingard. Davison, James Huang, Christopher Thomas Brown, and James Lingard.
Thanks are due to the American Licorice Company, for its obscure but Thanks are due to the American Licorice Company, for its obscure but
possibly essential role in the creation of this document. possibly essential role in the creation of this document.
9. Normative References 9. Normative References
[1] D. Black, "Differentiated Services and Tunnels", RFC 2983. [1] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan,
"Internet Group Management Protocol, Version 3", RFC 3376.
[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] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery [3] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery
(MLD) for IPv6", RFC 2710. (MLD) for IPv6", RFC 2710.
[4] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) [4] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460. Specification", RFC 2460.
[5] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, [5] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft-
"Internet Group Management Protocol, Version 3", RFC 3376.
[6] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft-
ietf-ssm-arch-04.txt, work in progress. ietf-ssm-arch-04.txt, work in progress.
[7] IANA, "Address Family Numbers", linked from [6] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
[8] S. Kent, R. Atkinson, "Security Architecture for the Internet [7] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.", RFC 2401. Protocol.", RFC 2401.
[9] S. Kent, "IP Encapsulating Security Payload (ESP)", draft-ietf- [8] T. Narten , H. Alvestrand, "Guidelines for Writing an IANA
ipsec-esp-v3-06.txt, work in progress.
[10] T. Narten , H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434. Considerations Section in RFCs", RFC 2434.
[11] D. Thaler, "Interoperability Rules for Multicast Routing
Protocols", RFC 2715.
10. Informative References 10. Informative References
[12] T. Bates , R. Chandra , D. Katz , Y. Rekhter, "Multiprotocol [9] T. Bates , R. Chandra , D. Katz , Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2283 Extensions for BGP-4", RFC 2283
[13] W. Fenner, M. Handley, R. Kermode, D. Thaler, "Bootstrap Router [10] D. Black, "Differentiated Services and Tunnels", RFC 2983.
[11] W. Fenner, M. Handley, R. Kermode, D. Thaler, "Bootstrap Router
(BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, (BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt,
work in progress. work in progress.
[14] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional [12] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
Protocol Independent Multicast", draft-ietf-pim-bidir-05.txt, work Protocol Independent Multicast", draft-ietf-pim-bidir-05.txt, work
in progress. in progress.
[15] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)", RFC [13] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)", RFC
2409. 2409.
11. Index [14] S. Kent, "IP Encapsulating Security Payload (ESP)", draft-ietf-
Assert(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .27,130 ipsec-esp-v3-06.txt, work in progress.
Assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .27,130
[15] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP)
Address in an IPv6 Multicast Address" draft-ietf-mboned-
embeddedrp-04.txt, work in progress.
[16] D. Thaler, "Interoperability Rules for Multicast Routing
Protocols", RFC 2715.
11. Appendix A: PIM Multicast Border Router Behavior |
In some cases PIM-SM domains will interconnect with non-PIM multicast |
domains. In these cases, the border routers of the PIM domain speak |
PIM-SM on some interfaces and speak other multicast routing protocols on |
other interfaces. Such routers are termed PIM Multicast Border Routers |
or PMBRs. In general, RFC 2715 [16] provides rules for interoperability |
between different multicast routing protocols. In this section we |
specify how PMBRs differ from regular PIM-SM routers. |
From the point of view of PIM-SM, a PMBR has two tasks: |
o To ensure that traffic from sources outside the PIM-SM domain reaches |
receivers inside the domain. |
o To ensure that traffic from sources inside the PIM-SM domain reaches |
receivers outside the domain. |
We note that multiple PIM-SM domains are sometimes connected together |
using protocols such as MSDP, which provides information about active |
external sources, but does not follow RFC 2715. In such cases the |
domains are not connected via PMBRs because Join(S,G) messages traverse |
the border between domains. A PMBR is required when no PIM messages can |
traverse the border. |
11.1. Sources External to the PIM-SM Domain |
A PMBR needs to ensure that traffic from multicast sources external to |
the PIM-SM domain reaches receivers inside the domain. The PMBR will |
follow the rules in RFC 2715, such that traffic from external sources |
reaches the PMBR itself. |
According to RFC 2715, the PIM-SM component of the PMBR will receive an |
(S,G) Creation event when data from an (S,G) data packet from an |
external source first reaches the PMBR. If RPF_interface(S) is an |
interface in the PIM-SM domain, the packet cannot be originated into the |
PIM domain at this router, and the PIM-SM component of the PMBR will not |
process the packet. Otherwise the PMBR will then act exactly as if it |
were the DR for this source (see Section 4.4.1), with the following |
modifications: |
o The Border-bit is set in all PIM Register message sent for these |
sources. |
o DirectlyConnected(S) is treated as being TRUE for these sources. |
o The PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to be |
TRUE if iif is any interface that is not part of the PIM-SM component |
of the PMBR (see Section 4.2). |
11.2. Sources Internal to the PIM-SM Domain |
A PMBR needs to ensure that traffic from sources inside the PIM-SM |
domain reaches receivers outside the domain. Using terminology from RFC |
2715, there are two possible scenarios for this: |
o Another component of the PMBR is a wildcard receiver. In this case |
the PIM-SM component of the PMBR must ensure that traffic from all |
internal sources reaches the PMBR until it is informed otherwise. |
Note that certain profiles of PIM-SM, e.g., PIM-SSM, PIM-SM with |
Embedded RP, cannot interoperate with a neighboring wildcard receiver |
domain. |
o No other component of the PMBR is a wildcard receiver. In this case |
the PMBR will receive explicit information as to which groups or |
(source,group) pairs the external domains wish to receive. |
In the former case, the PMBR will need to send a Join(*,*,RP) to all the |
active RPs in the PIM-SM domain. It may also send a Join(*,*,RP) to all |
the candidate RPs in the PIM-SM domain. This will cause all traffic in |
the domain to reach the PMBR. The PMBR may then act as if it were a DR |
with directly connected receivers, and trigger the transition to a |
shortest path tree (see Section 4.2.1). |
In the latter case, the PMBR will not need to send Join(*,*,RP) |
messages. However the PMBR will still need to act as a DR with directly |
connected receivers on behalf of the external receivers in terms of |
being able to switch to the shortest-path tree for internally-reached |
sources. |
According to RFC 2715, the PIM-SM component of the PMBR may receive a |
number of alerts generated by events in the external routing components. |
To implement the above behavior, one reasonable way to map these alerts |
into PIM-SM state as follows: |
o When a PIM-SM component receives an (S,G) Prune alert, it sets |
local_receiver_include(S,G,I) to FALSE for the discard interface. |
o When a PIM-SM component receives a (*,G) Prune alert, it sets |
local_receiver_include(*,G,I) to FALSE for the discard interface. |
o When a PIM-SM component receives an (S,G) Join alert, it sets |
local_receiver_include(S,G,I) to TRUE for the discard interface. |
o When a PIM-SM component receives a (*,G) Join alert, it sets |
local_receiver_include(*,G,I) to TRUE for the discard interface. |
o When a PIM-SM component receives a (*,*) Join alert, it sets |
DownstreamJPState(*,*,RP,I) to Join state on the discard interface for |
all RPs in the PIM-SM domain. |
o When a PIM-SM component receives a (*,*) Prune alert, then it sets |
DownstreamJPState(*,*,RP,I) to NoInfo state on the discard interface |
for all RPs in the PIM-SM domain. |
We refer above to the discard interface because the macros and state |
machines are interface-specific, but we need to have PIM state that is |
not associated with any actual PIM-SM interface. Implementors are free |
to implement this in any reasonable manner. |
Note that these state changes will then cause additional PIM-SM state |
machine transitions in the normal way. |
These rules are however not sufficient to allow pruning off the (*,*,RP) |
tree. Some additional rules provide guidance as to one way this may be |
done: |
o If the PMBR has joined on the (*,*,RP) tree, then it should set |
DownstreamJPState(*,G,I) to JOIN on the discard interface for all |
active groups. |
o If the router receives a (S,G) prune alert it will need to set |
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface. |
o If the router receives a (*,G) prune alert, it will need to set |
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface for all |
active sources sending to G. |
The rationale for this is that there is no way in PIM-SM to prune |
traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and then |
pruning each source individually. |