summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7761.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7761.txt')
-rw-r--r--doc/rfc/rfc7761.txt7675
1 files changed, 7675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7761.txt b/doc/rfc/rfc7761.txt
new file mode 100644
index 0000000..21013b3
--- /dev/null
+++ b/doc/rfc/rfc7761.txt
@@ -0,0 +1,7675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Fenner
+Request for Comments: 7761 Arista Networks
+STD: 83 M. Handley
+Obsoletes: 4601 UCL
+Category: Standards Track H. Holbrook
+ISSN: 2070-1721 I. Kouvelas
+ Arista Networks
+ R. Parekh
+ Cisco Systems, Inc.
+ Z. Zhang
+ Juniper Networks
+ L. Zheng
+ Huawei Technologies
+ March 2016
+
+
+ Protocol Independent Multicast - Sparse Mode (PIM-SM):
+ Protocol Specification (Revised)
+
+Abstract
+
+ This document specifies Protocol Independent Multicast - Sparse Mode
+ (PIM-SM). PIM-SM is a multicast routing protocol that can use the
+ underlying unicast routing information base or a separate multicast-
+ capable routing information base. It builds unidirectional shared
+ trees rooted at a Rendezvous Point (RP) per group, and it optionally
+ creates shortest-path trees per source.
+
+ This document obsoletes RFC 4601 by replacing it, addresses the
+ errata filed against it, removes the optional (*,*,RP), PIM Multicast
+ Border Router features and authentication using IPsec that lack
+ sufficient deployment experience (see Appendix A), and moves the PIM
+ specification to Internet Standard.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7761.
+
+
+
+
+Fenner, et al. Standards Track [Page 1]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................5
+ 2. Terminology .....................................................5
+ 2.1. Definitions ................................................5
+ 2.2. Pseudocode Notation ........................................7
+ 3. PIM-SM Protocol Overview ........................................7
+ 3.1. Phase One: RP Tree .........................................8
+ 3.2. Phase Two: Register-Stop ...................................9
+ 3.3. Phase Three: Shortest-Path Tree ...........................10
+ 3.4. Source-Specific Joins .....................................10
+ 3.5. Source-Specific Prunes ....................................11
+ 3.6. Multi-Access Transit LANs .................................11
+ 3.7. RP Discovery ..............................................12
+ 4. Protocol Specification .........................................12
+ 4.1. PIM Protocol State ........................................13
+ 4.1.1. General-Purpose State ..............................14
+ 4.1.2. (*,G) State ........................................15
+ 4.1.3. (S,G) State ........................................17
+ 4.1.4. (S,G,rpt) State ....................................19
+ 4.1.5. State Summarization Macros .........................20
+ 4.2. Data Packet Forwarding Rules ..............................24
+ 4.2.1. Last-Hop Switchover to the SPT .....................27
+ 4.2.2. Setting and Clearing the (S,G) SPTbit ..............27
+ 4.3. Designated Routers (DRs) and Hello Messages ...............29
+ 4.3.1. Sending Hello Messages .............................29
+ 4.3.2. DR Election ........................................31
+ 4.3.3. Reducing Prune Propagation Delay on LANs ...........33
+ 4.3.4. Maintaining Secondary Address Lists ................36
+ 4.4. PIM Register Messages .....................................37
+ 4.4.1. Sending Register Messages from the DR ..............38
+ 4.4.2. Receiving Register Messages at the RP ..............43
+
+
+
+
+Fenner, et al. Standards Track [Page 2]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ 4.5. PIM Join/Prune Messages ...................................44
+ 4.5.1. Receiving (*,G) Join/Prune Messages ................45
+ 4.5.2. Receiving (S,G) Join/Prune Messages ................50
+ 4.5.3. Receiving (S,G,rpt) Join/Prune Messages ............54
+ 4.5.4. Sending (*,G) Join/Prune Messages ..................61
+ 4.5.5. Sending (S,G) Join/Prune Messages ..................65
+ 4.5.6. (S,G,rpt) Periodic Messages ........................71
+ 4.5.7. State Machine for (S,G,rpt) Triggered Messages .....72
+ 4.6. PIM Assert Messages .......................................76
+ 4.6.1. (S,G) Assert Message State Machine .................77
+ 4.6.2. (*,G) Assert Message State Machine .................85
+ 4.6.3. Assert Metrics .....................................93
+ 4.6.4. AssertCancel Messages ..............................94
+ 4.6.5. Assert State Macros ................................95
+ 4.7. PIM Bootstrap and RP Discovery ............................98
+ 4.7.1. Group-to-RP Mapping ................................99
+ 4.7.2. Hash Function .....................................100
+ 4.8. Source-Specific Multicast ................................101
+ 4.8.1. Protocol Modifications for SSM Destination
+ Addresses .........................................102
+ 4.8.2. PIM-SSM-Only Routers ..............................102
+ 4.9. PIM Packet Formats .......................................104
+ 4.9.1. Encoded Source and Group Address Formats ..........105
+ 4.9.2. Hello Message Format ..............................108
+ 4.9.3. Register Message Format ...........................111
+ 4.9.4. Register-Stop Message Format ......................113
+ 4.9.5. Join/Prune Message Format .........................114
+ 4.9.5.1. Group Set Source List Rules ..............117
+ 4.9.5.2. Group Set Fragmentation ..................120
+ 4.9.6. Assert Message Format .............................121
+ 4.10. PIM Timers ..............................................122
+ 4.11. Timer Values ............................................124
+ 5. IANA Considerations ...........................................130
+ 5.1. PIM Address Family .......................................130
+ 5.2. PIM Hello Options ........................................130
+ 6. Security Considerations .......................................131
+ 6.1. Attacks Based on Forged Messages .........................131
+ 6.1.1. Forged Link-Local Messages ........................131
+ 6.1.2. Forged Unicast Messages ...........................132
+ 6.2. Non-cryptographic Authentication Mechanisms ..............132
+ 6.3. Authentication ...........................................133
+ 6.4. Denial-of-Service Attacks ................................133
+ 7. References ....................................................133
+ 7.1. Normative References .....................................133
+ 7.2. Informative References ...................................134
+ Appendix A. Functionality Removed from RFC 4601 ..................136
+ Acknowledgements .................................................136
+ Authors' Addresses ...............................................136
+
+
+
+Fenner, et al. Standards Track [Page 3]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+List of Figures (Shown in Tabular Form)
+
+ Figure 1. Per-(S,G) Register State Machine at a DR ................39
+ Figure 2. Downstream Per-Interface (*,G) State Machine ............47
+ Figure 3. Downstream Per-Interface (S,G) State Machine ............51
+ Figure 4. Downstream Per-Interface (S,G,rpt) State Machine ........56
+ Figure 5. Upstream (*,G) State Machine ............................62
+ Figure 6. Upstream (S,G) State Machine ............................66
+ Figure 7. Upstream (S,G,rpt) State Machine for Triggered
+ Messages ................................................72
+ Figure 8. Per-Interface (S,G) Assert State Machine ................78
+ Figure 9. Per-interface (*,G) Assert State Machine ................87
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 4]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+1. Introduction
+
+ This document specifies a protocol for efficiently routing multicast
+ groups that may span wide-area (and inter-domain) internets. This
+ protocol is called Protocol Independent Multicast - Sparse Mode
+ (PIM-SM) because, although it may use the underlying unicast routing
+ to provide reverse-path information for multicast tree building, it
+ is not dependent on any particular unicast routing protocol.
+
+ PIM-SM Version 2 was specified in RFC 4601 as a Proposed Standard.
+ This document is intended to address the reported errata and to
+ remove the optional (*,*,RP), PIM Multicast Border Router features
+ and authentication using IPsec that lacks sufficient deployment
+ experience, to advance PIM-SM to Internet Standard.
+
+ This document specifies the same protocol as RFC 4601, and
+ implementations per the specification in this document will be able
+ to interoperate successfully with implementations per RFC 4601.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+2.1. Definitions
+
+ The following terms have special significance for PIM-SM:
+
+ Rendezvous Point (RP)
+ 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
+ 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
+ can discover who the senders are and start to receive traffic
+ destined for the group.
+
+ Designated Router (DR)
+ A shared-media LAN like Ethernet may have multiple PIM-SM routers
+ connected to it. A single one of these routers, the DR, will act
+ on behalf of directly connected hosts with respect to the PIM-SM
+ protocol. A single DR is elected per interface (LAN or otherwise)
+ using a simple election process.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 5]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ MRIB
+ Multicast Routing Information Base. This is the multicast
+ topology table, which is typically derived from the unicast
+ routing table, or routing protocols such as Multiprotocol BGP
+ (MBGP) that carry multicast-specific topology information. In
+ PIM-SM, the MRIB is used to decide where to send Join/Prune
+ messages. A secondary function of the MRIB is to provide routing
+ metrics for destination addresses; these metrics are used when
+ sending and processing Assert messages.
+
+ RPF Neighbor
+ RPF stands for "Reverse Path Forwarding". The RPF Neighbor of a
+ router with respect to an address is the neighbor that the MRIB
+ indicates should be used to forward packets to that address. In
+ the case of a PIM-SM multicast group, the RPF neighbor is the
+ router that a Join message for that group would be directed to, in
+ the absence of modifying Assert state.
+
+ TIB
+ Tree Information Base. This is the collection of state at a PIM
+ router that has been created by receiving PIM Join/Prune messages,
+ PIM Assert messages, and Internet Group Management Protocol (IGMP)
+ or Multicast Listener Discovery (MLD) information from local
+ hosts. It essentially stores the state of all multicast
+ distribution trees at that router.
+
+ MFIB
+ Multicast Forwarding Information Base. The TIB holds all the
+ state that is necessary to forward multicast packets at a router.
+ However, although this specification defines forwarding in terms
+ of the TIB, to actually forward packets using the TIB is very
+ inefficient. Instead, a real router implementation will normally
+ build an efficient MFIB from the TIB state to perform forwarding.
+ How this is done is implementation-specific and is not discussed
+ in this document.
+
+ Upstream
+ Towards the root of the tree. The root of the tree may be either
+ the source or the RP, depending on the context.
+
+ Downstream
+ Away from the root of the tree.
+
+ GenID
+ Generation Identifier, used to detect reboots.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 6]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+2.2. Pseudocode Notation
+
+ We use set notation in several places in this specification.
+
+ A (+) B is the union of two sets, A and B.
+
+ A (-) B is the elements of set A that are not in set B.
+
+ NULL is the empty set or list.
+
+ In addition, we use C-like syntax:
+
+ = denotes assignment of a variable.
+
+ == denotes a comparison for equality.
+
+ != denotes a comparison for inequality.
+
+ Braces { and } are used for grouping.
+
+ Unless otherwise noted, operations specified by statements having
+ multiple (+) and (-) operators should be evaluated from left to
+ right, i.e., A (+) B (-) C is the set resulting from union of sets A
+ and B minus elements in set C.
+
+3. PIM-SM Protocol Overview
+
+ This section provides an overview of PIM-SM behavior. It is intended
+ as an introduction to how PIM-SM works, and it is NOT definitive.
+ For the definitive specification, see Section 4.
+
+ PIM relies on an underlying topology-gathering protocol to populate a
+ routing table with routes. This routing table is called the
+ Multicast Routing Information Base (MRIB). The routes in this table
+ may be taken directly from the unicast routing table, or they may be
+ different and provided by a separate routing protocol such as MBGP
+ [10]. Regardless of how it is created, the primary role of the MRIB
+ in the PIM protocol is to provide the next-hop router along a
+ multicast-capable path to each destination subnet. The MRIB is used
+ to determine the next-hop neighbor to which any PIM Join/Prune
+ message is sent. Data flows along the reverse path of the Join
+ messages. Thus, in contrast to the unicast RIB, which specifies the
+ next hop that a data packet would take to get to some subnet, the
+ MRIB gives reverse-path information and indicates the path that a
+ multicast data packet would take from its origin subnet to the router
+ that has the MRIB.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 7]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Like all multicast routing protocols that implement the service model
+ from RFC 1112 [3], PIM-SM must be able to route data packets from
+ sources to receivers without either the sources or receivers knowing
+ a 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 time, all three phases may occur simultaneously.
+
+3.1. Phase One: RP Tree
+
+ In phase one, a multicast receiver expresses its interest in
+ receiving traffic destined for a multicast group. Typically, it does
+ this using IGMP [2] or MLD [4], but other mechanisms might also serve
+ this purpose. One of the receiver's local routers is elected as the
+ Designated Router (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 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 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, 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 group, their Join messages converge on
+ the RP and form a distribution tree for group G that is rooted at the
+ RP. This is known as the RP Tree (RPT), and is also known as the
+ shared tree because it is shared by all sources sending to that
+ group. Join messages are resent periodically so long as the receiver
+ remains in the group. When all receivers on a leaf-network leave the
+ group, the DR will send a PIM (*,G) Prune message towards the RP for
+ that multicast group. However, if the Prune message is not sent for
+ any reason, the state will eventually time out.
+
+ A multicast data sender just starts sending data destined for a
+ multicast group. The sender's local router (DR) takes those data
+ packets, unicast-encapsulates them, and sends them directly to the
+ RP. The RP receives these encapsulated data packets, decapsulates
+ them, and forwards them onto the shared tree. The packets then
+ follow the (*,G) multicast tree state in the routers on the RP Tree,
+ being replicated wherever the RP Tree branches, and eventually
+ reaching all the receivers for that multicast group. The process of
+ encapsulating data packets to the RP is called registering, and the
+ encapsulation packets are known as PIM Register packets.
+
+ At the end of phase one, multicast traffic is flowing encapsulated to
+ the RP, and then natively over the RP tree to the multicast
+ receivers.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 8]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+3.2. Phase Two: Register-Stop
+
+ Register-encapsulation of data packets is inefficient for two
+ reasons:
+
+ o Encapsulation and decapsulation may be relatively expensive
+ operations for a router to perform, depending on whether or not
+ the router has appropriate hardware for these tasks.
+
+ o Traveling all the way to the RP, and then back down the shared
+ tree may result in the packets traveling a relatively long
+ distance to reach receivers that are close to the sender. For
+ some applications, this increased latency or bandwidth consumption
+ is undesirable.
+
+ Although Register-encapsulation may continue indefinitely, for these
+ reasons, the RP will normally choose to switch to native forwarding.
+ To 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 Join towards S. This Join message travels hop-by-hop
+ towards S, 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 if those packets come from source S. Eventually
+ the Join message reaches S's subnet or a router that already has
+ (S,G) multicast tree state, and then packets from S start to flow
+ following the (S,G) tree state towards the RP. These data packets
+ may also reach routers with (*,G) state along the path towards the
+ RP; if they do, they can shortcut onto the RP tree at this point.
+
+ While the RP is in the process of joining the source-specific tree
+ for S, the data packets will continue being encapsulated to the RP.
+ When packets from S also start to arrive natively at the RP, the RP
+ will be receiving two copies of each of these packets. At this
+ point, the RP starts to discard the encapsulated copy of these
+ packets, and it sends a Register-Stop message back to S's DR to
+ prevent the DR from unnecessarily encapsulating the packets.
+
+ At the end of phase two, traffic will be flowing natively from S
+ along a source-specific tree to the RP, and from there along the
+ shared tree to the receivers. Where the two trees intersect, traffic
+ may transfer from the source-specific tree to the RP tree and thus
+ avoid taking a long detour via the RP.
+
+ Note that a sender may start sending before or after a receiver joins
+ the group, and thus phase two may happen before the shared tree to
+ the receiver is built.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 9]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+3.3. Phase Three: Shortest-Path Tree
+
+ Although having the RP join back towards the source removes the
+ encapsulation overhead, it does not completely optimize the
+ forwarding paths. For many receivers, the route via the RP may
+ involve a significant detour when compared with the shortest path
+ from the source to the receiver.
+
+ To obtain lower latencies or more efficient bandwidth utilization, a
+ router on the receiver's LAN, typically the DR, may optionally
+ initiate a transfer from the shared tree to a source-specific
+ shortest-path tree (SPT). To do this, it issues an (S,G) Join
+ towards S. This instantiates state in the routers along the path to
+ S. Eventually, this join either reaches S's subnet or reaches a
+ router that already has (S,G) state. When this happens, data packets
+ from S start to flow following the (S,G) state until they reach the
+ receiver.
+
+ 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 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 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 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. The prune is propagated until it
+ reaches the RP or a router that still needs the traffic from S for
+ other receivers.
+
+ By now, the receiver will be receiving traffic from S along the
+ shortest-path tree between the receiver and S. In addition, the RP
+ is receiving the traffic from S, but this traffic is no longer
+ reaching the receiver along the RP tree. As far as the receiver is
+ concerned, this is the final distribution tree.
+
+3.4. Source-Specific Joins
+
+ IGMPv3 permits a receiver to join a group and specify that it only
+ wants 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 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-specific (S,G) join only.
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 10]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ 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 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 range, it should ignore it.
+
+3.5. Source-Specific Prunes
+
+ IGMPv3 also permits a receiver to join a group and to specify that it
+ only 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) 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.
+
+3.6. Multi-Access Transit LANs
+
+ The overview so far has concerned itself with point-to-point transit
+ links. However, using multi-access LANs such as Ethernet for transit
+ is not uncommon. This can cause complications for three reasons:
+
+ o Two or more routers on the LAN may issue (*,G) Joins to different
+ upstream routers on the LAN because they have inconsistent MRIB
+ 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 on the LAN.
+
+ 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
+ entries regarding how to reach source S. Both paths on the
+ source-specific tree will be set up, causing two copies of all the
+ traffic from S to appear on the LAN.
+
+ o A router on the LAN may issue a (*,G) Join to one upstream router
+ on the LAN, and another router on the LAN may issue an (S,G) Join
+ to a different upstream router on the same LAN. Traffic from S
+ may reach the LAN over both the RPT and the SPT. If the receiver
+ behind the downstream (*,G) router doesn't issue an (S,G,rpt)
+ prune, then this condition would persist.
+
+ All of these problems are caused by there being more than one
+ upstream router with join state for the group or source-group pair.
+ PIM does not prevent such duplicate joins from occurring; instead,
+ when duplicate data packets appear on the LAN from different routers,
+ these routers notice this and then elect a single forwarder. This
+ election is performed using PIM Assert messages, which resolve the
+ problem in favor of the upstream router that has (S,G) state; or, if
+
+
+
+
+Fenner, et al. Standards Track [Page 11]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ neither router or both routers have (S,G) state, then the problem is
+ resolved in favor of the router with the best metric to the RP for RP
+ trees, or the best metric to the source for source-specific trees.
+
+ 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 router that won the Assert.
+
+3.7. RP Discovery
+
+ PIM-SM routers need to know the address of the RP for each group for
+ which they have (*,G) state. This address is obtained 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)
+ mechanism [11]. One router in each PIM domain is elected the BSR
+ through a simple election process. All the routers in the domain
+ that are configured to be candidates to be RPs periodically unicast
+ their candidacy to the BSR. From the candidates, the BSR picks an
+ RP-set, and periodically announces this set in a Bootstrap message.
+ Bootstrap messages are flooded hop-by-hop throughout the domain until
+ 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-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 RP for that group.
+
+4. Protocol Specification
+
+ The specification of PIM-SM is broken into several parts:
+
+ o Section 4.1 details the protocol state stored.
+
+ o Section 4.2 specifies the data packet forwarding rules.
+
+ o Section 4.3 specifies Designated Router (DR) election and the
+ rules for sending and processing Hello messages.
+
+ o Section 4.4 specifies the PIM Register generation and processing
+ rules.
+
+ o Section 4.5 specifies the PIM Join/Prune generation and processing
+ rules.
+
+ o Section 4.6 specifies the PIM Assert generation and processing
+ rules.
+
+
+
+Fenner, et al. Standards Track [Page 12]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ o Section 4.7 specifies the RP discovery mechanisms.
+
+ o Section 4.8 describes PIM-SSM, the subset of PIM required to
+ support Source-Specific Multicast.
+
+ o Section 4.9 specifies the PIM packet formats.
+
+ o Section 4.10 provides a summary of PIM-SM timers, and Section 4.11
+ provides their default values.
+
+4.1. PIM Protocol State
+
+ This section specifies all the protocol state that a PIM
+ implementation should maintain in order to function correctly. We
+ term this state the Tree Information Base (TIB), as it holds the
+ state of all the multicast distribution trees at this router. In
+ this specification, we define PIM mechanisms in terms of the TIB.
+ However, only a very simple implementation would actually implement
+ packet forwarding operations in terms of this state. Most
+ implementations will use this state to build a multicast forwarding
+ table, which would then be updated when the relevant state in the TIB
+ changes.
+
+ 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. 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 hold whatever internal state it requires and will still be
+ conformant with this specification so long as it results in the same
+ externally visible protocol behavior as an abstract router that holds
+ the following state.
+
+ We divide TIB state into three sections:
+
+ (*,G) state
+ State that maintains the RP tree for G.
+
+ (S,G) state
+ State that maintains a source-specific tree for source S and
+ group G.
+
+ (S,G,rpt) state
+ State that maintains source-specific information about source S
+ on the RP tree for G. For example, if a source is being
+ received on the source-specific tree, it will normally have been
+ pruned off the RP tree. This prune state is (S,G,rpt) state.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 13]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ The state that should be kept is described below. Of course,
+ implementations will only maintain state when it is relevant to
+ forwarding operations; for example, the "NoInfo" state might be
+ assumed from the lack of other state information rather than being
+ held explicitly.
+
+4.1.1. General-Purpose State
+
+ A router holds the following non-group-specific state:
+
+ For each interface:
+
+ o Effective Override Interval
+
+ o Effective Propagation Delay
+
+ o Suppression state: One of {"Enable", "Disable"}
+
+ Neighbor State:
+
+ For each neighbor:
+
+ o Information from neighbor's Hello
+
+ o Neighbor's GenID.
+
+ o Neighbor Liveness Timer (NLT)
+
+ Designated Router (DR) State:
+
+ o Designated Router's IP Address
+
+ o DR's DR Priority
+
+ The Effective Override Interval, the Effective Propagation Delay, and
+ the Interface suppression state are described in Section 4.3.3.
+ Designated Router state is described in Section 4.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 14]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.1.2. (*,G) State
+
+ For every group G, a router keeps the following state:
+
+ (*,G) state:
+ For each interface:
+
+ Local Membership:
+ State: One of {"NoInfo", "Include"}
+
+ PIM (*,G) Join/Prune State:
+
+ o State: One of {"NoInfo" (NI), "Join" (J),
+ "Prune-Pending" (PP)}
+
+ o Prune-Pending Timer (PPT)
+
+ o Join/Prune Expiry Timer (ET)
+
+ (*,G) Assert Winner State
+
+ o State: One of {"NoInfo" (NI), "I lost Assert" (L),
+ "I won Assert" (W)}
+
+ o Assert Timer (AT)
+
+ o Assert winner's IP Address (AssertWinner)
+
+ o Assert winner's Assert Metric (AssertWinnerMetric)
+
+ Not interface specific:
+
+ Upstream (*,G) Join/Prune State:
+
+ o State: One of {"NotJoined(*,G)", "Joined(*,G)"}
+
+ o Upstream Join/Prune Timer (JT)
+
+ o Last RP Used
+
+ o Last RPF Neighbor towards RP that was used
+
+ Local membership is the result of the local membership mechanism
+ (such as IGMP or MLD) running on that interface. It need not be kept
+ if this router is not the DR on that interface unless this router won
+ a (*,G) assert on this interface for this group, although
+ implementations may optionally keep this state in case they become
+ the DR or assert winner. It is RECOMMENDED to store this information
+
+
+
+Fenner, et al. Standards Track [Page 15]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ if possible, as it reduces latency converging to stable operating
+ conditions after a failure causing a change of DR. This information
+ is used by the pim_include(*,G) macro described in Section 4.1.5.
+
+ PIM (*,G) Join/Prune state is the result of receiving PIM (*,G)
+ Join/Prune messages on this interface and is specified in
+ Section 4.5.1. The state is used by the macros that calculate the
+ outgoing interface list in Section 4.1.5, and in the JoinDesired(*,G)
+ macro (defined in Section 4.5.4) that is used in deciding whether a
+ Join(*,G) should be sent upstream.
+
+ (*,G) Assert Winner state is the result of sending or receiving (*,G)
+ 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 (*,G) state machine described in Section 4.5.4.
+
+ 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 upstream LAN interface.
+
+ The last RP used must be stored because if the RP changes, then state
+ must be torn down and rebuilt for groups whose RP changes.
+
+ 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, 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 detects through a changed GenID in a Hello message that
+ the upstream neighbor towards the RP has rebooted, then it SHOULD
+ re-instantiate state by sending a Join(*,G). These mechanisms are
+ specified in Section 4.5.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 16]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.1.3. (S,G) State
+
+ For every source/group pair (S,G), a router keeps the following
+ state:
+
+ (S,G) state:
+
+ For each interface:
+
+ Local Membership:
+ State: One of {"NoInfo", "Include"}
+
+ PIM (S,G) Join/Prune State:
+
+ o State: One of {"NoInfo" (NI), "Join" (J),
+ "Prune-Pending" (PP)}
+
+ o Prune-Pending Timer (PPT)
+
+ o Join/Prune Expiry Timer (ET)
+
+ (S,G) Assert Winner State
+
+ o State: One of {"NoInfo" (NI), "I lost Assert" (L),
+ "I won Assert" (W)}
+
+ o Assert Timer (AT)
+
+ o Assert winner's IP Address (AssertWinner)
+
+ o Assert winner's Assert Metric (AssertWinnerMetric)
+
+ Not interface specific:
+
+ Upstream (S,G) Join/Prune State:
+
+ o State: One of {"NotJoined(S,G)", "Joined(S,G)"}
+
+ o Upstream (S,G) Join/Prune Timer (JT)
+
+ o Last RPF Neighbor towards S that was used
+
+ o SPTbit (indicates (S,G) state is active)
+
+ o (S,G) Keepalive Timer (KAT)
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 17]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Additional (S,G) state at the DR:
+
+ o Register state: One of {"Join" (J), "Prune" (P),
+ "Join-Pending" (JP), "NoInfo" (NI)}
+
+ o Register-Stop Timer (RST)
+
+ Local membership is the result of the local source-specific
+ membership mechanism (such as IGMP Version 3) running on that
+ interface and specifying that this particular source should be
+ included. As stored 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 that interface unless this router won
+ an (S,G) assert on this interface for this group. However, it is
+ RECOMMENDED to store this information if possible, as it reduces
+ latency converging to stable operating 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.5.
+
+ PIM (S,G) Join/Prune state is the result of receiving PIM (S,G)
+ Join/Prune messages on this interface and is specified in
+ Section 4.5.2. The state is used by the macros that calculate the
+ outgoing interface list in Section 4.1.5, and in the JoinDesired(S,G)
+ macro (defined in Section 4.5.5) that is used in deciding whether a
+ Join(S,G) should be sent upstream.
+
+ (S,G) Assert Winner state is the result of sending or receiving (S,G)
+ Assert messages on this interface. It is specified in Section 4.6.1.
+
+ The upstream (S,G) Join/Prune State reflects the state of the
+ upstream (S,G) state machine described in Section 4.5.5.
+
+ The upstream (S,G) Join/Prune Timer is used to send out periodic
+ Join(S,G) messages, and to override Prune(S,G) messages from peers on
+ an upstream LAN interface.
+
+ The last RPF neighbor towards S is stored because if the MRIB
+ changes, then the RPF neighbor towards S may change. If it does so,
+ then we need to trigger a new Join(S,G) to the new upstream neighbor
+ and a Prune(S,G) to the old upstream neighbor. Similarly, if the
+ router detects through a changed GenID in a Hello message that the
+ upstream neighbor towards S has rebooted, then it SHOULD
+ re-instantiate state by sending a Join(S,G). These mechanisms are
+ specified in Section 4.5.5.
+
+ The SPTbit is used to indicate whether forwarding is taking place on
+ the (S,G) Shortest Path Tree (SPT) or on the (*,G) tree. A router
+ can have (S,G) state and still be forwarding on (*,G) state during
+
+
+
+Fenner, et al. Standards Track [Page 18]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ the interval when the source-specific tree is being constructed.
+ When SPTbit is FALSE, only (*,G) forwarding state is used to forward
+ packets from S to G. When SPTbit is TRUE, both (*,G) and (S,G)
+ forwarding state are used.
+
+ The (S,G) Keepalive Timer is updated by data being forwarded using
+ this (S,G) forwarding state. It is used to keep (S,G) state alive in
+ the absence of explicit (S,G) Joins. Amongst other things, this is
+ 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 from unnecessarily reaching the RP.
+
+ 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-Stop Timer tracks how long before encapsulation begins again
+ for a given (S,G).
+
+4.1.4. (S,G,rpt) State
+
+ For every source/group pair (S,G) for which a router also has (*,G)
+ state, it also keeps the following state:
+
+ (S,G,rpt) state:
+
+ For each interface:
+
+ Local Membership:
+ State: One of {"NoInfo", "Exclude"}
+
+ PIM (S,G,rpt) Join/Prune State:
+
+ o State: One of {"NoInfo", "Pruned",
+ "Prune-Pending"}
+
+ o Prune-Pending Timer (PPT)
+
+ o Join/Prune Expiry Timer (ET)
+
+ Not interface specific:
+
+ Upstream (S,G,rpt) Join/Prune State:
+
+ o State: One of {"RPTNotJoined(G)",
+ "NotPruned(S,G,rpt)", "Pruned(S,G,rpt)"}
+
+ o Override Timer (OT)
+
+
+
+
+
+Fenner, et al. Standards Track [Page 19]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Local membership is the result of the local source-specific
+ membership mechanism (such as IGMPv3) running on that interface and
+ specifying that although there is (*,G) Include state, this
+ particular source should be excluded. As stored here, this state is
+ the resulting state after any IGMPv3 inconsistencies between LAN
+ members have been resolved. It need not be kept if this router is
+ not the DR on that interface unless this router won a (*,G) assert on
+ this interface for this group. However, we RECOMMEND storing this
+ information if possible, as it reduces latency converging to stable
+ operating conditions after a failure causing a change of DR. This
+ information is used by the pim_exclude(S,G) macro described in
+ Section 4.1.5.
+
+ PIM (S,G,rpt) Join/Prune state is the result of receiving PIM
+ (S,G,rpt) Join/Prune messages on this interface and is specified in
+ Section 4.5.3. The state is used by the macros that calculate the
+ outgoing interface list in Section 4.1.5, and in the rules for adding
+ Prune(S,G,rpt) messages to Join(*,G) messages specified in
+ Section 4.5.6.
+
+ The upstream (S,G,rpt) Join/Prune state is used along with the
+ Override Timer to send the correct override messages in response to
+ Join/Prune messages sent by upstream peers on a LAN. This state and
+ behavior are specified in Section 4.5.7.
+
+4.1.5. State Summarization Macros
+
+ Using this state, we define the following "macro" definitions, which
+ we will use in the descriptions of the state machines and pseudocode
+ in the following sections.
+
+ The most important macros are those that define the outgoing
+ interface list (or "olist") for the relevant state. An olist can be
+ "immediate" if it is built directly from the state of the relevant
+ type. For example, the immediate_olist(S,G) is the olist that would
+ be built if the router only had (S,G) state and no (*,G) or (S,G,rpt)
+ state. In contrast, the "inherited" olist inherits state from other
+ types. For example, the inherited_olist(S,G) is the olist that is
+ relevant for forwarding a packet from S to G using both source-
+ specific and group-specific state.
+
+ There is no immediate_olist(S,G,rpt), as (S,G,rpt) state is negative
+ state; it removes interfaces in the (*,G) olist from the olist that
+ is actually used to forward traffic. The inherited_olist(S,G,rpt) is
+ therefore the olist that would be used for a packet from S to G
+ forwarding on the RP tree. It is a strict subset of
+ immediate_olist(*,G).
+
+
+
+
+Fenner, et al. Standards Track [Page 20]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Generally speaking, the inherited_olists are used for forwarding, and
+ the immediate_olists are used to make decisions about state
+ maintenance.
+
+ immediate_olist(*,G) =
+ joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)
+
+ immediate_olist(S,G) =
+ joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
+
+ inherited_olist(S,G,rpt) =
+ ( joins(*,G) (-) prunes(S,G,rpt) )
+ (+) ( pim_include(*,G) (-) pim_exclude(S,G))
+ (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
+
+ inherited_olist(S,G) =
+ inherited_olist(S,G,rpt) (+)
+ joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
+
+ The macros pim_include(*,G) and pim_include(S,G) indicate the
+ interfaces to which traffic might be forwarded because of hosts that
+ are local members on that interface. Note that normally only the DR
+ cares about local membership, but when an assert happens, the assert
+ winner takes over responsibility for forwarding traffic to local
+ members that have requested traffic on a group or source/group pair.
+
+ pim_include(*,G) =
+ { all interfaces I such that:
+ ( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
+ OR AssertWinner(*,G,I) == me )
+ AND local_receiver_include(*,G,I) }
+
+ pim_include(S,G) =
+ { all interfaces I such that:
+ ( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE )
+ OR AssertWinner(S,G,I) == me )
+ AND local_receiver_include(S,G,I) }
+
+ pim_exclude(S,G) =
+ { all interfaces I such that:
+ ( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
+ OR AssertWinner(*,G,I) == me )
+ AND local_receiver_exclude(S,G,I) }
+
+ The clause "local_receiver_include(S,G,I)" is true if the IGMP/MLD
+ module or other local membership mechanism has determined that local
+ members on interface I desire to receive traffic sent specifically by
+ S to G. "local_receiver_include(*,G,I)" is true if the IGMP/MLD
+
+
+
+Fenner, et al. Standards Track [Page 21]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ module or other local membership mechanism has determined that local
+ members on interface I desire to receive all traffic sent to G
+ (possibly excluding traffic from a specific set of sources).
+ "local_receiver_exclude(S,G,I)" is true if
+ "local_receiver_include(*,G,I)" is true but none of the local members
+ desire to receive traffic from S.
+
+ The set "joins(*,G)" is the set of all interfaces on which the router
+ has received (*,G) Joins:
+
+ joins(*,G) =
+ { all interfaces I such that
+ DownstreamJPState(*,G,I) is either Join or Prune-Pending }
+
+ DownstreamJPState(*,G,I) is the state of the finite state machine in
+ Section 4.5.1.
+
+ The set "joins(S,G)" is the set of all interfaces on which the router
+ has received (S,G) Joins:
+
+ joins(S,G) =
+ { all interfaces I such that
+ DownstreamJPState(S,G,I) is either Join or Prune-Pending }
+
+ DownstreamJPState(S,G,I) is the state of the finite state machine in
+ Section 4.5.2.
+
+ The set "prunes(S,G,rpt)" is the set of all interfaces on which the
+ router has received (*,G) joins and (S,G,rpt) prunes:
+
+ prunes(S,G,rpt) =
+ { all interfaces I such that
+ DownstreamJPState(S,G,rpt,I) is Prune or PruneTmp }
+
+ DownstreamJPState(S,G,rpt,I) is the state of the finite state machine
+ in Section 4.5.3.
+
+ The set "lost_assert(*,G)" is the set of all interfaces on which the
+ router has received (*,G) joins but has lost a (*,G) assert. The
+ macro lost_assert(*,G,I) is defined in Section 4.6.5.
+
+ lost_assert(*,G) =
+ { all interfaces I such that
+ lost_assert(*,G,I) == TRUE }
+
+ The set "lost_assert(S,G,rpt)" is the set of all interfaces on which
+ the router has received (*,G) joins but has lost an (S,G) assert.
+ The macro lost_assert(S,G,rpt,I) is defined in Section 4.6.5.
+
+
+
+Fenner, et al. Standards Track [Page 22]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ lost_assert(S,G,rpt) =
+ { all interfaces I such that
+ lost_assert(S,G,rpt,I) == TRUE }
+
+ The set "lost_assert(S,G)" is the set of all interfaces on which the
+ router has received (S,G) joins but has lost an (S,G) assert. The
+ macro lost_assert(S,G,I) is defined in Section 4.6.5.
+
+ lost_assert(S,G) =
+ { all interfaces I such that
+ lost_assert(S,G,I) == TRUE }
+
+ The following pseudocode macro definitions are also used in many
+ places in the specification. Basically, RPF' is the RPF neighbor
+ towards an RP or source unless a PIM-Assert has overridden the normal
+ choice of neighbor.
+
+ neighbor RPF'(*,G) {
+ if ( I_Am_Assert_Loser(*, G, RPF_interface(RP(G))) ) {
+ return AssertWinner(*, G, RPF_interface(RP(G)) )
+ } else {
+ return NBR( RPF_interface(RP(G)), MRIB.next_hop( RP(G) ) )
+ }
+ }
+
+ neighbor RPF'(S,G,rpt) {
+ if( I_Am_Assert_Loser(S, G, RPF_interface(RP(G)) ) ) {
+ return AssertWinner(S, G, RPF_interface(RP(G)) )
+ } else {
+ return RPF'(*,G)
+ }
+ }
+
+ neighbor RPF'(S,G) {
+ if ( I_Am_Assert_Loser(S, G, RPF_interface(S) )) {
+ return AssertWinner(S, G, RPF_interface(S) )
+ } else {
+ return NBR( RPF_interface(S), MRIB.next_hop( S ) )
+ }
+ }
+
+ RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets
+ should be coming and to which joins should be sent on the RP tree and
+ SPT, respectively.
+
+ RPF'(S,G,rpt) is basically RPF'(*,G) modified by the result of an
+ Assert(S,G) on RPF_interface(RP(G)). In such a case, packets from S
+ will be originating from a different router than RPF'(*,G). If we
+
+
+
+Fenner, et al. Standards Track [Page 23]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ only have active (*,G) Join state, we need to accept packets from
+ RPF'(S,G,rpt) and add a Prune(S,G,rpt) to the periodic Join(*,G)
+ messages that we send to RPF'(*,G) (see Section 4.5.6).
+
+ 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 directly adjacent, then MRIB.next_hop( S ) returns NULL. At the
+ RP for G, MRIB.next_hop( RP(G)) returns NULL.
+
+ The function NBR( I, A ) uses information gathered through PIM Hello
+ 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
+ (Section 4.3.4). The primary IP address of a neighbor is the address
+ that it uses as the source of its PIM Hello messages. Note that a
+ 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.
+
+ 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.
+
+4.2. Data Packet Forwarding Rules
+
+ The PIM-SM packet forwarding rules are defined below in pseudocode.
+
+ iif is the incoming interface of the packet.
+
+ S is the source address of the packet.
+
+ G is the destination address of the packet (group address).
+
+ RP is the address of the Rendezvous Point for this group.
+
+ RPF_interface(S) is the interface the MRIB indicates would be used
+ to route packets to S.
+
+ RPF_interface(RP) is the interface the MRIB indicates would be
+ used to route packets to the RP, except at the RP when it is
+ the decapsulation interface (the "virtual" interface on which
+ Register packets are received).
+
+
+
+
+
+Fenner, et al. Standards Track [Page 24]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ First, we restart (or start) the Keepalive Timer if the source is on
+ a directly connected subnet.
+
+ Second, we check to see if the SPTbit should be set because we've now
+ switched from the RP tree to the SPT.
+
+ Next, we check to see whether the packet should be accepted based on
+ TIB state and the interface that the packet arrived on.
+
+ 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 we restart the (S,G) state Keepalive Timer.
+
+ If the packet should be forwarded using (*,G) state, then we just
+ build an outgoing interface list for the packet. We also check if we
+ should initiate a switch to start receiving this source on a shortest
+ path tree.
+
+ Finally, we remove the incoming interface from the outgoing interface
+ list we've created, and if the resulting outgoing interface list is
+ not empty, we forward the packet out of those interfaces.
+
+ On receipt of data from S to G on interface iif:
+ if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) {
+ set KeepaliveTimer(S,G) to Keepalive_Period
+ # Note: A register state transition or UpstreamJPState(S,G)
+ # transition may happen as a result of restarting
+ # KeepaliveTimer, and must be dealt with here.
+ }
+
+ if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND
+ inherited_olist(S,G) != NULL ) {
+ set KeepaliveTimer(S,G) to Keepalive_Period
+ }
+
+ Update_SPTbit(S,G,iif)
+ oiflist = NULL
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 25]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) {
+ oiflist = inherited_olist(S,G)
+ } else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE ) {
+ oiflist = inherited_olist(S,G,rpt)
+ CheckSwitchToSpt(S,G)
+ } else {
+ # Note: RPF check failed.
+ # A transition in an Assert finite state machine may cause an
+ # Assert(S,G) or Assert(*,G) message to be sent out interface iif.
+ # See Section 4.6 for details.
+ if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
+ send Assert(S,G) on iif
+ } else if ( SPTbit(S,G) == FALSE AND
+ iif is in inherited_olist(S,G,rpt) ) {
+ send Assert(*,G) on iif
+ }
+ }
+
+ oiflist = oiflist (-) iif
+ forward packet on all interfaces in oiflist
+
+ This pseudocode employs several "macro" definitions:
+
+ DirectlyConnected(S) is TRUE if the source S is on any subnet that is
+ directly connected to this router (or for packets originating on this
+ router).
+
+ inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in
+ Section 4.1.
+
+ Basically, inherited_olist(S,G) is the outgoing interface list for
+ packets forwarded on (S,G) state, taking into account (*,G) state,
+ asserts, etc.
+
+ inherited_olist(S,G,rpt) is the outgoing interface list for packets
+ forwarded on (*,G) state, taking into account (S,G,rpt) prune state,
+ asserts, etc.
+
+ Update_SPTbit(S,G,iif) is defined in Section 4.2.2.
+
+ CheckSwitchToSpt(S,G) is defined in Section 4.2.1.
+
+ UpstreamJPState(S,G) is the state of the finite state machine in
+ Section 4.5.5.
+
+ Keepalive_Period is defined in Section 4.11.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 26]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Data-triggered PIM-Assert messages sent from the above forwarding
+ code SHOULD be rate-limited in an implementation-dependent manner.
+
+4.2.1. Last-Hop Switchover to the SPT
+
+ In Sparse-Mode PIM, last-hop routers join the shared tree towards the
+ RP. Once traffic from sources to joined groups arrives at a last-hop
+ router, it has the option of switching to receive the traffic on a
+ shortest path tree (SPT).
+
+ The decision for a router to switch to the SPT is controlled as
+ follows:
+
+ void
+ CheckSwitchToSpt(S,G) {
+ if ( ( pim_include(*,G) (-) pim_exclude(S,G)
+ (+) pim_include(S,G) != NULL )
+ AND SwitchToSptDesired(S,G) ) {
+ # Note: Restarting the KAT will result in the SPT switch.
+ set KeepaliveTimer(S,G) to Keepalive_Period
+ }
+ }
+
+ SwitchToSptDesired(S,G) is a policy function that is implementation
+ defined. An "infinite threshold" policy can be implemented by making
+ SwitchToSptDesired(S,G) return false all the time. A "switch on
+ first packet" policy can be implemented by making
+ SwitchToSptDesired(S,G) return true once a single packet has been
+ received for the source and group.
+
+4.2.2. Setting and Clearing the (S,G) SPTbit
+
+ The (S,G) SPTbit is used to distinguish whether to forward on (*,G)
+ or on (S,G) state. When switching from the RP tree to the source
+ tree, there is a transition period when data is arriving due to
+ upstream (*,G) state while upstream (S,G) state is being established,
+ during which time a router should continue to forward only on (*,G)
+ state. This prevents temporary black holes that would be caused by
+ sending a Prune(S,G,rpt) before the upstream (S,G) state has finished
+ being established.
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 27]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:
+
+ void
+ Update_SPTbit(S,G,iif) {
+ if ( iif == RPF_interface(S)
+ AND JoinDesired(S,G) == TRUE
+ AND ( DirectlyConnected(S) == TRUE
+ OR RPF_interface(S) != RPF_interface(RP(G))
+ OR inherited_olist(S,G,rpt) == NULL
+ OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
+ ( RPF'(S,G) != NULL ) )
+ OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) {
+ Set SPTbit(S,G) to TRUE
+ }
+ }
+
+ 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 4.6.1).
+
+ JoinDesired(S,G) is defined in Section 4.5.5 and indicates whether we
+ have the appropriate (S,G) Join state to wish to send a Join(S,G)
+ upstream.
+
+ Basically, Update_SPTbit(S,G,iif) will set the SPTbit if we have the
+ appropriate (S,G) join state, and if the packet arrived on the
+ correct upstream interface for S, and if one or more of the following
+ conditions apply:
+
+ 1. The source is directly connected, in which case the switch to the
+ SPT is a no-op.
+
+ 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
+ have been completed.
+
+ 3. No one wants the packet on the RP tree.
+
+ 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 immediately. The RPF'(S,G) != NULL check ensures that the
+ SPTbit is set only if the RPF neighbor towards S is valid.
+
+ In the case where the RPF interface is the same for the RP and for S,
+ but RPF'(S,G) and RPF'(*,G) differ, we wait for an Assert(S,G), which
+ indicates that the upstream router with (S,G) state believes the 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.
+
+
+
+Fenner, et al. Standards Track [Page 28]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ The SPTbit is cleared in the (S,G) upstream state machine (see
+ Section 4.5.5) when JoinDesired(S,G) becomes FALSE.
+
+4.3. Designated Routers (DRs) and Hello Messages
+
+ A shared-media LAN like Ethernet may have multiple PIM-SM routers
+ connected to it. A single one of these routers, the DR, will act on
+ behalf of directly connected hosts with respect to the PIM-SM
+ protocol. Because the distinction between LANs and point-to-point
+ interfaces can sometimes be blurred, and because routers may also
+ have multicast host functionality, the PIM-SM specification makes no
+ distinction between the two. Thus, DR election will happen on all
+ interfaces, LAN or otherwise.
+
+ DR election is performed using Hello messages. Hello messages are
+ also the way that option negotiation takes place in PIM, so that
+ additional functionality can be enabled, or parameters tuned.
+
+4.3.1. Sending Hello Messages
+
+ PIM Hello messages are sent periodically on each PIM-enabled
+ interface. They allow a router to learn about the neighboring PIM
+ routers on each interface. Hello messages are also the mechanism
+ used to elect a DR, and to negotiate additional capabilities. A
+ router must record the Hello information received from each PIM
+ neighbor.
+
+ Hello messages MUST be sent on all active interfaces, including
+ physical point-to-point links, and are multicast to the
+ 'ALL-PIM-ROUTERS' group address ('224.0.0.13' for IPv4 and 'ff02::d'
+ for IPv6).
+
+ We note that some implementations do not send Hello messages on
+ point-to-point interfaces. This is non-compliant behavior. A
+ compliant PIM router MUST send Hello messages, even on point-to-point
+ interfaces.
+
+ A per-interface Hello Timer (HT(I)) is used to trigger sending Hello
+ messages on each active interface. When PIM is enabled on an
+ interface or a router first starts, the Hello Timer of that interface
+ is set to a random value between 0 and Triggered_Hello_Delay. This
+ prevents synchronization of Hello messages if multiple routers are
+ powered on simultaneously. After the initial randomized interval,
+ Hello messages MUST be sent every Hello_Period seconds. The
+ Hello Timer SHOULD NOT be reset except when it expires.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 29]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Note that neighbors will not accept Join/Prune or Assert messages
+ from a router unless they have first heard a Hello message from that
+ router. Thus, if a router needs to send a Join/Prune or Assert
+ message on an interface on which it has not yet sent a Hello message
+ with the currently configured IP address, then it MUST immediately
+ send the relevant Hello message without waiting for the Hello Timer
+ to expire, followed by the Join/Prune or Assert message.
+
+ The DR Priority option allows a network administrator to give
+ preference to a particular router in the DR election process by
+ giving it a numerically larger DR Priority. The DR Priority option
+ SHOULD be included in every Hello message, even if no DR Priority is
+ explicitly configured on that interface. This is necessary because
+ priority-based DR election is only enabled when all neighbors on an
+ interface advertise that they are capable of using the DR Priority
+ option. The default priority is 1.
+
+ The Generation Identifier (GenID) option SHOULD be included in all
+ Hello messages. The GenID option contains a randomly generated
+ 32-bit value that is regenerated each time PIM forwarding is started
+ or restarted on the interface, including when the router itself
+ restarts. When a Hello message with a new GenID is received from a
+ neighbor, any old Hello information about that neighbor SHOULD be
+ discarded and superseded by the information from the new Hello
+ message. This may cause a new DR to be chosen on that interface.
+
+ The LAN Prune Delay option SHOULD be included in all Hello messages
+ sent on multi-access LANs. This option advertises a router's
+ capability to use values other than the defaults for the
+ Propagation_Delay and Override_Interval, which affect the setting of
+ the Prune-Pending, Upstream Join, and Override Timers (defined in
+ Section 4.10).
+
+ The Address List option advertises all the secondary addresses
+ associated with the source interface of the router originating the
+ message. The option MUST be included in all Hello messages if there
+ are secondary addresses associated with the source interface and MAY
+ be omitted if no secondary addresses exist.
+
+ To allow new or rebooting routers to learn of PIM neighbors quickly,
+ when a Hello message is received from a new neighbor, or a Hello
+ message with a new GenID is received from an existing neighbor, a new
+ Hello message SHOULD be sent on this interface after a randomized
+ delay between 0 and Triggered_Hello_Delay. This triggered message
+ need not change the timing of the scheduled periodic message. If a
+ router needs to send a Join/Prune to the new neighbor or send an
+ Assert message in response to an Assert message from the new neighbor
+ before this randomized delay has expired, then it MUST immediately
+
+
+
+Fenner, et al. Standards Track [Page 30]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ send the relevant Hello message without waiting for the Hello Timer
+ to expire, followed by the Join/Prune or Assert message. If it does
+ not do this, then the new neighbor will discard the Join/Prune or
+ Assert message.
+
+ Before an interface goes down or changes primary IP address, a Hello
+ message with a zero HoldTime SHOULD be sent immediately (with the old
+ IP address if the IP address changed). This will cause PIM neighbors
+ to remove this neighbor (or its old IP address) immediately. After
+ an 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 addresses, a Hello message with an updated Address List
+ option and a non-zero HoldTime SHOULD be sent immediately. This will
+ cause PIM neighbors to update this neighbor's list of secondary
+ addresses immediately.
+
+4.3.2. DR Election
+
+ When a PIM Hello message is received on interface I, the following
+ information about the sending neighbor is recorded:
+
+ neighbor.interface
+ The interface on which the Hello message arrived.
+
+ neighbor.primary_ip_address
+ The IP address that the PIM neighbor used as the source
+ address of the Hello message.
+
+ neighbor.genid
+ The Generation ID of the PIM neighbor.
+
+ neighbor.dr_priority
+ The DR Priority field of the PIM neighbor, if it is present
+ in the Hello message.
+
+ neighbor.dr_priority_present
+ A flag indicating if the DR Priority field was present in
+ the Hello message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 31]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ neighbor.timeout
+ A timer value to time out the neighbor state when it becomes
+ stale, also known as the Neighbor Liveness Timer.
+
+ The Neighbor Liveness Timer (NLT(N,I)) is reset to
+ Hello_Holdtime (from the Hello Holdtime option) whenever a
+ Hello message is received containing a Holdtime option, or
+ to Default_Hello_Holdtime if the Hello message does not
+ contain the Holdtime option.
+
+ Neighbor state is deleted when the neighbor timeout expires.
+
+ The function for computing the DR on interface I is:
+
+ host
+ DR(I) {
+ dr = me
+ for each neighbor on interface I {
+ if ( dr_is_better( neighbor, dr, I ) == TRUE ) {
+ dr = neighbor
+ }
+ }
+ return dr
+ }
+
+ The function used for comparing DR "metrics" on interface I is:
+
+ bool
+ dr_is_better(a,b,I) {
+ if( there is a neighbor n on I for which n.dr_priority_present
+ is false ) {
+ return a.primary_ip_address > b.primary_ip_address
+ } else {
+ return ( a.dr_priority > b.dr_priority ) OR
+ ( a.dr_priority == b.dr_priority AND
+ a.primary_ip_address > b.primary_ip_address )
+ }
+ }
+
+ The trivial function I_am_DR(I) is defined to aid readability:
+
+ bool
+ I_am_DR(I) {
+ return DR(I) == me
+ }
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 32]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ 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 interface can change when a PIM Hello message is received,
+ when a neighbor times out, or when a router's own DR Priority
+ changes. If the router becomes the DR or ceases to be the DR, this
+ will normally cause the DR Register state machine to change state.
+ Subsequent actions are determined by that state machine.
+
+ We note that some PIM implementations do not send Hello messages
+ on point-to-point interfaces and thus cannot perform DR election
+ on such interfaces. This is non-compliant behavior. DR election
+ MUST be performed on ALL active PIM-SM interfaces.
+
+4.3.3. Reducing Prune Propagation Delay on LANs
+
+ In addition to the information recorded for the DR Election, the
+ following per-neighbor information is obtained from the LAN Prune
+ Delay Hello option:
+
+ neighbor.lan_prune_delay_present
+ A flag indicating if the LAN Prune Delay option was present
+ in the Hello message.
+
+ neighbor.tracking_support
+ A flag storing the value of the T bit in the LAN Prune Delay
+ option if it is present in the Hello message. This
+ indicates the neighbor's capability to disable Join message
+ suppression.
+
+ neighbor.propagation_delay
+ The Propagation Delay field of the LAN Prune Delay option
+ (if present) in the Hello message.
+
+ neighbor.override_interval
+ The Override_Interval field of the LAN Prune Delay option
+ (if present) in the Hello message.
+
+ The additional state described above is deleted along with the DR
+ neighbor state when the neighbor timeout expires.
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 33]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Just like the DR Priority option, the information provided in the LAN
+ Prune Delay option is not used unless all neighbors on a link
+ advertise the option. The function below computes this state:
+
+ bool
+ lan_delay_enabled(I) {
+ for each neighbor on interface I {
+ if ( neighbor.lan_prune_delay_present == false ) {
+ return false
+ }
+ }
+ return true
+ }
+
+ The Propagation Delay inserted by a router in the LAN Prune Delay
+ option expresses the expected message propagation delay on the link
+ and SHOULD be configurable by the system administrator. It is used
+ by upstream routers to figure out how long they should wait for a
+ Join override message before pruning an interface.
+
+ PIM implementers SHOULD enforce a lower bound on the permitted values
+ for this delay to allow for scheduling and processing delays within
+ their router. Such delays may cause received messages to be
+ processed later as well as triggered messages to be sent later than
+ intended. Setting this Propagation Delay to too low a value may
+ result in temporary forwarding outages because a downstream router
+ will not be able to override a neighbor's Prune message before the
+ upstream neighbor stops forwarding.
+
+ When all routers on a link are in a position to negotiate a
+ Propagation Delay different from the default, the largest value from
+ those advertised by each neighbor is chosen. The function for
+ computing the Effective Propagation Delay of interface I is:
+
+ time_interval
+ Effective_Propagation_Delay(I) {
+ if ( lan_delay_enabled(I) == false ) {
+ return Propagation_delay_default
+ }
+ delay = Propagation_Delay(I)
+ for each neighbor on interface I {
+ if ( neighbor.propagation_delay > delay ) {
+ delay = neighbor.propagation_delay
+ }
+ }
+ return delay
+ }
+
+
+
+
+Fenner, et al. Standards Track [Page 34]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ To avoid synchronization of override messages when multiple
+ downstream routers share a multi-access link, the sending of such
+ messages is delayed by a small random amount of time. The period of
+ randomization should represent the size of the PIM router population
+ on the link. Each router expresses its view of the amount of
+ randomization necessary in the Override Interval field of the LAN
+ Prune Delay option.
+
+ When all routers on a link are in a position to negotiate an Override
+ Interval different from the default, the largest value from those
+ advertised by each neighbor is chosen. The function for computing
+ the Effective Override Interval of interface I is:
+
+ time_interval
+ Effective_Override_Interval(I) {
+ if ( lan_delay_enabled(I) == false ) {
+ return t_override_default
+ }
+ delay = Override_Interval(I)
+ for each neighbor on interface I {
+ if ( neighbor.override_interval > delay ) {
+ delay = neighbor.override_interval
+ }
+ }
+ return delay
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 35]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Although the mechanisms are not specified in this document, it is
+ possible for upstream routers to explicitly track the join
+ membership of individual downstream routers if Join suppression is
+ disabled. A router can advertise its willingness to disable Join
+ suppression by using the T bit in the LAN Prune Delay Hello option.
+ Unless all PIM routers on a link negotiate this capability, explicit
+ tracking and the disabling of the Join suppression mechanism are not
+ possible. The function for computing the state of Suppression on
+ interface I is:
+
+ bool
+ Suppression_Enabled(I) {
+ if ( lan_delay_enabled(I) == false ) {
+ return true
+ }
+ for each neighbor on interface I {
+ if ( neighbor.tracking_support == false ) {
+ return true
+ }
+ }
+ return false
+ }
+
+ Note that the setting of Suppression_Enabled(I) affects the value of
+ t_suppressed (see Section 4.11).
+
+4.3.4. Maintaining Secondary Address Lists
+
+ Communication of a router's interface secondary addresses to its PIM
+ neighbors is necessary to provide the neighbors with a mechanism for
+ mapping next_hop information obtained through their MRIB to a primary
+ 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 PIM neighbor is obtained from the source IP address used in its
+ PIM Hello messages. Secondary addresses are carried within the Hello
+ message 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 option.
+
+ In addition to the information recorded for the DR Election, the
+ following per-neighbor information is obtained from the Address List
+ Hello option:
+
+ neighbor.secondary_address_list
+ The list of secondary addresses used by the PIM neighbor on
+ the interface through which the Hello message was
+ transmitted.
+
+
+
+
+Fenner, et al. Standards Track [Page 36]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ When processing a received PIM Hello message containing an Address
+ List Hello option, the list of secondary addresses in the message
+ completely replaces any previously associated secondary addresses for
+ that neighbor. If a received PIM Hello message does not contain an
+ Address List Hello option, then all secondary addresses associated
+ with the neighbor MUST be deleted. If a received PIM Hello message
+ contains an Address List Hello option that includes the primary
+ address of the sending router in the list of secondary addresses
+ (although this is not expected), then the addresses listed in the
+ message, excluding the primary address, are used to update the
+ associated secondary addresses for that neighbor.
+
+ All the advertised secondary addresses in received Hello messages
+ must be checked against those previously advertised by all other PIM
+ neighbors on that interface. If there is a conflict and the same
+ secondary address was previously advertised by another neighbor, then
+ only the most recently received mapping MUST be maintained, and an
+ error message SHOULD be logged to the administrator in a rate-limited
+ manner.
+
+ Within one Address List Hello option, all the addresses MUST be of
+ the same address family. It is not permitted to mix IPv4 and IPv6
+ addresses within the same message. In addition, the address family
+ of the fields in the message SHOULD be the same as the IP source and
+ destination addresses of the packet header.
+
+4.4. PIM Register Messages
+
+ The Designated Router (DR) on a LAN or point-to-point link
+ encapsulates multicast packets from local sources to the RP for the
+ relevant group unless it recently received a Register-Stop message
+ for that (S,G) or (*,G) from the RP. When the DR receives a
+ Register-Stop message from the RP, it starts a Register-Stop Timer to
+ maintain this state. Just before the Register-Stop Timer expires,
+ the DR sends a Null-Register message to the RP to allow the RP to
+ refresh the Register-Stop information at the DR. If the
+ Register-Stop Timer actually expires, the DR will resume
+ encapsulating packets from the source to the RP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 37]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.4.1. Sending Register Messages from the DR
+
+ 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 specification, we represent the mechanism to encapsulate packets
+ to 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 forwarding rules as specified in Section 4.2.
+
+ 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 per-(S,G) Register state machine:
+
+ Join (J)
+ 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 interface).
+
+ Prune (P)
+ The register tunnel is "pruned" (this occurs when a
+ Register-Stop is received).
+
+ Join-Pending (JP)
+ The register tunnel is pruned but the DR is contemplating
+ adding it back.
+
+ NoInfo (NI)
+ No information. This is the initial state, and the state
+ when the router is not the DR.
+
+ In addition, a Register-Stop Timer (RST) is kept if the state machine
+ is not in the NoInfo state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 38]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Figure 1: Per-(S,G) Register State Machine at a DR
+
++----------++----------------------------------------------------------+
+| || Event |
+| ++----------+-----------+-----------+-----------+-----------+
+|Prev State||Register- | Could | Could | Register- | RP changed|
+| ||Stop Timer| Register | Register | Stop | |
+| ||expires | ->True | ->False | received | |
++----------++----------+-----------+-----------+-----------+-----------+
+|NoInfo ||- | -> J state| - | - | - |
+|(NI) || | add reg | | | |
+| || | tunnel | | | |
++----------++----------+-----------+-----------+-----------+-----------+
+| ||- | - | -> NI | -> P state| -> J state|
+| || | | state | | |
+| || | | remove reg| remove reg| update reg|
+|Join (J) || | | tunnel | tunnel; | tunnel |
+| || | | | set | |
+| || | | | Register- | |
+| || | | | Stop | |
+| || | | | Timer(*) | |
++----------++----------+-----------+-----------+-----------+-----------+
+| ||-> J state| - | -> NI | -> P state| -> J state|
+| || | | state | | |
+|Join- ||add reg | | | set | add reg |
+|Pending ||tunnel | | | Register- | tunnel; |
+|(JP) || | | | Stop | cancel |
+| || | | | Timer(*) | Register- |
+| || | | | | Stop Timer|
++----------++----------+-----------+-----------+-----------+-----------+
+| ||-> JP | - | -> NI | - | -> J state|
+| ||state | | state | | |
+| ||set | | | | add reg |
+|Prune (P) ||Register- | | | | tunnel; |
+| ||Stop | | | | cancel |
+| ||Timer(**);| | | | Register- |
+| ||send Null-| | | | Stop Timer|
+| ||Register | | | | |
++----------++----------+-----------+-----------+-----------+-----------+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 39]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Notes:
+
+ (*) The Register-Stop Timer is set to a random value chosen
+ uniformly from the interval ( 0.5 * Register_Suppression_Time,
+ 1.5 * Register_Suppression_Time) minus Register_Probe_Time.
+
+ Subtracting off Register_Probe_Time is a bit unnecessary because
+ it is really small compared to Register_Suppression_Time, but
+ this was in the old specification and is kept for compatibility.
+
+ (**) The Register-Stop Timer is set to Register_Probe_Time.
+
+ The following three actions are defined:
+
+ Add Register Tunnel
+
+ A Register-Tunnel virtual interface, VI, is created (if it doesn't
+ already exist) with its encapsulation target being RP(G).
+ DownstreamJPState(S,G,VI) is set to Join state, causing the tunnel
+ interface to be added to immediate_olist(S,G) and
+ inherited_olist(S,G).
+
+ Remove Register Tunnel
+
+ VI is the Register-Tunnel virtual interface with encapsulation
+ target of RP(G). DownstreamJPState(S,G,VI) is set to NoInfo
+ state, causing the tunnel interface to be removed from
+ immediate_olist(S,G) and inherited_olist(S,G). If
+ DownstreamJPState(S,G,VI) is NoInfo for all (S,G), then VI can be
+ deleted.
+
+ Update Register Tunnel
+
+ This action occurs when RP(G) changes.
+
+ VI_old is the Register-Tunnel virtual interface with encapsulation
+ target old_RP(G). A Register-Tunnel virtual interface, VI_new, is
+ created (if it doesn't already exist) with its encapsulation
+ target being new_RP(G). DownstreamJPState(S,G,VI_old) is set to
+ NoInfo state, and DownstreamJPState(S,G,VI_new) is set to Join
+ state. If DownstreamJPState(S,G,VI_old) is NoInfo for all (S,G),
+ then VI_old can be deleted.
+
+ Note that we cannot simply change the encapsulation target of
+ VI_old because not all groups using that encapsulation tunnel will
+ have moved to the same new RP.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 40]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ CouldRegister(S,G)
+
+ The macro "CouldRegister" in the state machine is defined as:
+
+ bool CouldRegister(S,G) {
+ return ( I_am_DR( RPF_interface(S) ) AND
+ KeepaliveTimer(S,G) is running AND
+ DirectlyConnected(S) == TRUE )
+ }
+
+ 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 rules before computing CouldRegister(S,G) in the
+ register state machine, or the first packet from a source won't be
+ registered.
+
+ Encapsulating Data Packets in the Register Tunnel
+
+ Conceptually, the Register Tunnel is an interface with a smaller
+ MTU than the underlying IP interface towards the RP. IP
+ fragmentation on packets forwarded on the Register Tunnel is
+ performed based upon this smaller MTU. The encapsulating DR may
+ perform Path MTU Discovery to the RP to determine the effective
+ MTU of the tunnel. Fragmentation for the smaller MTU should take
+ both the outer IP header and the PIM register header overhead into
+ account. If a multicast packet is fragmented on the way into the
+ Register Tunnel, each fragment is encapsulated individually so it
+ contains IP, PIM, and inner IP headers.
+
+ In IPv6, the DR MUST perform Path MTU Discovery, and an ICMP
+ Packet Too Big message MUST be sent by the encapsulating DR if it
+ receives a packet that will not fit in the effective MTU of the
+ tunnel. If the MTU between the DR and the RP results in the
+ effective tunnel MTU being smaller than 1280 (the IPv6 minimum
+ MTU), the DR MUST send Fragmentation Required messages with an MTU
+ value of 1280 and MUST fragment its PIM register messages as
+ required, using an IPv6 fragmentation header between the outer
+ IPv6 header and the PIM Register header.
+
+ The TTL of a forwarded data packet is decremented before it is
+ encapsulated in the Register Tunnel. The encapsulating packet
+ uses the normal TTL that the router would use for any locally
+ generated IP packet.
+
+ The IP Explicit Congestion Notification (ECN) bits should be
+ copied from the original packet to the IP header of the
+ encapsulating packet. They SHOULD NOT be set independently by the
+ encapsulating router.
+
+
+
+Fenner, et al. Standards Track [Page 41]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ The Diffserv Code Point (DSCP) should be copied from the original
+ packet to the IP header of the encapsulating packet. It MAY be
+ set independently by the encapsulating router, based upon static
+ configuration or traffic classification. See [12] for more
+ discussion on setting the DSCP on tunnels.
+
+ Handling Register-Stop(*,G) Messages at the DR
+
+ 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 2362 when the Register message matched against (*,G) state at
+ the RP, and it was defined as meaning "stop encapsulating all
+ sources for this group". However, the behavior of such a
+ Register-Stop(*,G) is ambiguous or incorrect in some
+ circumstances.
+
+ 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.
+
+ 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 router should not apply a Register-Stop(*,G) to sources
+ that become active after the Register-Stop(*,G) was received.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 42]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.4.2. Receiving Register Messages at the RP
+
+ When an RP receives a Register message, the course of action is
+ decided according to the following pseudocode:
+
+ packet_arrives_on_rp_tunnel( pkt ) {
+ if( outer.dst is not one of my addresses ) {
+ drop the packet silently.
+ # Note: This may be a spoofing attempt.
+ }
+ if( I_am_RP(G) AND outer.dst == RP(G) ) {
+ sentRegisterStop = FALSE;
+ if ( SPTbit(S,G) OR
+ ( SwitchToSptDesired(S,G) AND
+ ( inherited_olist(S,G) == NULL ))) {
+ send Register-Stop(S,G) to outer.src
+ sentRegisterStop = TRUE;
+ }
+ if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) {
+ if ( sentRegisterStop == TRUE ) {
+ set KeepaliveTimer(S,G) to RP_Keepalive_Period;
+ } else {
+ set KeepaliveTimer(S,G) to Keepalive_Period;
+ }
+ }
+ if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) {
+ decapsulate and forward the inner packet to
+ inherited_olist(S,G,rpt) # Note (+)
+ }
+ } else {
+ send Register-Stop(S,G) to outer.src
+ # Note (*)
+ }
+ }
+
+ outer.dst is the IP destination address of the encapsulating header.
+
+ outer.src is the IP source address of the encapsulating header, i.e.,
+ the DR's address.
+
+ I_am_RP(G) is true if the group-to-RP mapping indicates that this
+ router is the RP for the group.
+
+ 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. However, this doesn't matter unless we figure
+ out some way for the RP also to accept (*,G) joins when it
+ doesn't yet realize that it is about to become the RP
+
+
+
+Fenner, et al. Standards Track [Page 43]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ for G. This will all get sorted out once 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
+ interrupted (*,G) connectivity following an RP change.
+
+ Note (+): Implementations SHOULD NOT make this a special case, but
+ SHOULD 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
+ 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 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
+ Register message for at least ( 3 * Register_Suppression_Time );
+ otherwise, the RP may stop joining (S,G) before the DR for S has
+ restarted sending registers. Traffic would then be interrupted until
+ the Register-Stop Timer expires at the DR.
+
+ Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 *
+ Register_Suppression_Time + Register_Probe_Time ).
+
+ When forwarding a packet from the Register Tunnel, the TTL of the
+ original data packet is decremented after it is decapsulated.
+
+ The IP ECN bits should be copied from the IP header of the Register
+ packet to the decapsulated packet.
+
+ The DSCP should be copied from the IP header of the Register packet
+ to the decapsulated packet. The RP MAY retain the DSCP of the inner
+ packet or re-classify the packet and apply a different DSCP.
+ Scenarios where each of these might be useful are discussed in [12].
+
+4.5. PIM Join/Prune Messages
+
+ 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
+ Join/Prune message, each Joined or Pruned source for a group is
+ effectively considered individually, and applies to one or more of
+ the following state machines. When considering a Join/Prune message
+ whose Upstream Neighbor Address field addresses this router, (*,G)
+ Joins and Prunes can affect both the (*,G) and (S,G,rpt) downstream
+ state machines, while (S,G), and (S,G,rpt) Joins and Prunes can only
+ affect their respective downstream state machines. When considering
+
+
+
+
+Fenner, et al. Standards Track [Page 44]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ a Join/Prune message whose Upstream Neighbor Address field addresses
+ another router, most Join or Prune messages could affect each
+ upstream state machine.
+
+ In general, a PIM Join/Prune message should only be accepted for
+ processing if it comes from a known PIM neighbor. A PIM router hears
+ about PIM neighbors through PIM Hello messages. If a router receives
+ a Join/Prune message from a particular IP source address and it has
+ not seen a PIM Hello message from that source address, then the
+ Join/Prune message SHOULD be discarded without further processing.
+ In addition, if the Hello message from a neighbor was authenticated
+ (see Section 6.3), then all Join/Prune messages from that neighbor
+ MUST also be authenticated.
+
+ We note that some older PIM implementations incorrectly fail to send
+ Hello messages on point-to-point interfaces, so we also RECOMMEND
+ that a configuration option be provided to allow interoperation with
+ such older routers, but that this configuration option SHOULD NOT be
+ enabled by default.
+
+4.5.1. Receiving (*,G) Join/Prune Messages
+
+ When a router receives a Join(*,G), it must first check to see
+ whether the RP in the message matches RP(G) (the router's idea of who
+ the RP is). If the RP in the message does not match RP(G), the
+ Join(*,G) should be silently dropped. (Note that other 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 information (e.g.,
+ has not recently received a BSR message), then it may choose to
+ accept Join(*,G) and treat the RP in the message as RP(G). Received
+ Prune(*,G) messages are processed even if the RP in the message does
+ not match RP(G).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 45]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ The per-interface state machine for receiving (*,G) Join/Prune
+ messages is given below. There are three states:
+
+ NoInfo (NI)
+ The interface has no (*,G) Join state and no timers running.
+
+ Join (J)
+ The interface has (*,G) Join state, which will cause the
+ router to forward packets destined for G from this interface
+ except if there is also (S,G,rpt) prune information (see
+ Section 4.5.3) or the router lost an assert on this
+ interface.
+
+ Prune-Pending (PP)
+ The router has received a Prune(*,G) on this interface from
+ a downstream neighbor and is waiting to see whether the
+ prune will be overridden by another downstream router. For
+ forwarding purposes, the Prune-Pending state functions
+ exactly like the Join state.
+
+ In addition, the state machine uses two timers:
+
+ Expiry Timer (ET)
+ This timer is restarted when a valid Join(*,G) is received.
+ Expiry of the Expiry Timer causes the interface state to
+ revert to NoInfo for this group.
+
+ Prune-Pending Timer (PPT)
+ This timer is set when a valid Prune(*,G) is received.
+ Expiry of the Prune-Pending Timer causes the interface state
+ to revert to NoInfo for this group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 46]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Figure 2: Downstream Per-Interface (*,G) State Machine
+
++------------++--------------------------------------------------------+
+| || Event |
+| ++-------------+--------------+-------------+-------------+
+|Prev State ||Receive | Receive | Prune- | Expiry Timer|
+| ||Join(*,G) | Prune(*,G) | Pending | Expires |
+| || | | Timer | |
+| || | | Expires | |
++------------++-------------+--------------+-------------+-------------+
+| ||-> J state | -> NI state | - | - |
+|NoInfo (NI) ||start Expiry | | | |
+| ||Timer | | | |
++------------++-------------+--------------+-------------+-------------+
+| ||-> J state | -> PP state | - | -> NI state |
+|Join (J) ||restart | start Prune- | | |
+| ||Expiry Timer | Pending | | |
+| || | Timer | | |
++------------++-------------+--------------+-------------+-------------+
+|Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
+|Pending (PP)||restart | | Send Prune- | |
+| ||Expiry Timer | | Echo(*,G) | |
++------------++-------------+--------------+-------------+-------------+
+
+ The transition events "Receive Join(*,G)" and "Receive Prune(*,G)"
+ imply receiving a Join or Prune targeted to this router's primary IP
+ address on the received interface. If the upstream neighbor address
+ field is not correct, these state transitions in this state machine
+ MUST NOT occur, although seeing such a packet may cause state
+ transitions in other state machines.
+
+ On unnumbered interfaces on point-to-point links, the router's
+ address 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 it is RECOMMENDED that for backwards compatibility PIM
+ Join/Prune messages with an upstream neighbor address field of all
+ zeros also be accepted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 47]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from NoInfo State
+
+ When in NoInfo state, the following event may trigger a transition:
+
+ Receive Join(*,G)
+ A Join(*,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (*,G) downstream state machine on interface I
+ transitions to the Join state. The Expiry Timer (ET) is
+ started and set to the HoldTime from the triggering
+ Join/Prune message.
+
+ Transitions from Join State
+
+ When in Join state, the following events may trigger a transition:
+
+ Receive Join(*,G)
+ A Join(*,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (*,G) downstream state machine on interface I remains in
+ Join state, and the Expiry Timer (ET) is restarted. The ET
+ is set to the maximum of its current value and the HoldTime
+ from the triggering Join/Prune message.
+
+ Receive Prune(*,G)
+ A Prune(*,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (*,G) downstream state machine on interface I
+ transitions to the Prune-Pending state. The
+ Prune-Pending Timer is started. It is set to the
+ J/P_Override_Interval(I) if the router has more than one
+ neighbor on that interface; otherwise, it is set to zero,
+ causing it to expire immediately.
+
+ Expiry Timer Expires
+ The Expiry Timer for the (*,G) downstream state machine on
+ interface I expires.
+
+ The (*,G) downstream state machine on interface I
+ transitions to the NoInfo state.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 48]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from Prune-Pending State
+
+ When in Prune-Pending state, the following events may trigger a
+ transition:
+
+ Receive Join(*,G)
+ A Join(*,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (*,G) downstream state machine on interface I
+ transitions to the Join state. The Prune-Pending Timer is
+ canceled (without triggering an expiry event). The
+ Expiry Timer (ET) is restarted and is then set to the
+ maximum of its current value and the HoldTime from the
+ triggering Join/Prune message.
+
+ Expiry Timer Expires
+ The Expiry Timer for the (*,G) downstream state machine on
+ interface I expires.
+
+ The (*,G) downstream state machine on interface I
+ transitions to the NoInfo state.
+
+ Prune-Pending Timer Expires
+ The Prune-Pending Timer for the (*,G) downstream state
+ machine on interface I expires.
+
+ The (*,G) downstream state machine on interface I
+ transitions to the NoInfo state. A PruneEcho(*,G) is sent
+ onto the subnet connected to interface I.
+
+ The action "Send PruneEcho(*,G)" is triggered when the
+ router stops forwarding on an interface as a result of a
+ prune. A PruneEcho(*,G) is simply a Prune(*,G) message sent
+ by the upstream router on a LAN with its own address in the
+ Upstream Neighbor Address field. Its purpose is to add
+ additional reliability so that if a Prune that should have
+ been overridden by another router is lost locally on the
+ LAN, then the PruneEcho may be received and cause the
+ override to happen. A PruneEcho(*,G) need not be sent on an
+ interface that contains only a single PIM neighbor during
+ the time this state machine was in Prune-Pending state.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 49]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.5.2. 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. There are three states:
+
+ NoInfo (NI)
+ The interface has no (S,G) Join state and no (S,G) timers
+ running.
+
+ Join (J)
+ The interface has (S,G) Join state, which will cause the
+ router to forward packets from S destined for G from this
+ interface if the (S,G) state is active (the SPTbit is set)
+ except if the router lost an assert on this interface.
+
+ Prune-Pending (PP)
+ The router has received a Prune(S,G) on this interface from
+ a downstream neighbor and is waiting to see whether the
+ prune will be overridden by another downstream router. For
+ forwarding purposes, the Prune-Pending state functions
+ exactly like the Join state.
+
+ In addition, there are two timers:
+
+ Expiry Timer (ET)
+ This timer is set when a valid Join(S,G) is received.
+ Expiry of the Expiry Timer causes this state machine to
+ revert to NoInfo state.
+
+ Prune-Pending Timer (PPT)
+ This timer is set when a valid Prune(S,G) is received.
+ Expiry of the Prune-Pending Timer causes this state machine
+ to revert to NoInfo state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 50]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Figure 3: Downstream Per-Interface (S,G) State Machine
+
++------------++--------------------------------------------------------+
+| || Event |
+| ++-------------+--------------+-------------+-------------+
+|Prev State ||Receive | Receive | Prune- | Expiry Timer|
+| ||Join(S,G) | Prune(S,G) | Pending | Expires |
+| || | | Timer | |
+| || | | Expires | |
++------------++-------------+--------------+-------------+-------------+
+| ||-> J state | -> NI state | - | - |
+|NoInfo (NI) ||start Expiry | | | |
+| ||Timer | | | |
++------------++-------------+--------------+-------------+-------------+
+| ||-> J state | -> PP state | - | -> NI state |
+|Join (J) ||restart | start Prune- | | |
+| ||Expiry Timer | Pending | | |
+| || | Timer | | |
++------------++-------------+--------------+-------------+-------------+
+|Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
+|Pending (PP)||restart | | Send Prune- | |
+| ||Expiry Timer | | Echo(S,G) | |
++------------++-------------+--------------+-------------+-------------+
+
+ The transition events "Receive Join(S,G)" and "Receive Prune(S,G)"
+ imply receiving a Join or Prune targeted to this router's primary IP
+ address on the received interface. If the upstream neighbor address
+ field is not correct, these state transitions in this state machine
+ MUST NOT occur, although seeing such a packet may cause state
+ transitions in other state machines.
+
+ On unnumbered interfaces on point-to-point links, the router's
+ address 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 it is RECOMMENDED that for backwards compatibility PIM
+ Join/Prune messages with an upstream neighbor address field of all
+ zeros also be accepted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 51]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from NoInfo State
+
+ When in NoInfo state, the following event may trigger a transition:
+
+ Receive Join(S,G)
+ A Join(S,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (S,G) downstream state machine on interface I
+ transitions to the Join state. The Expiry Timer (ET) is
+ started and set to the HoldTime from the triggering
+ Join/Prune message.
+
+ Transitions from Join State
+
+ When in Join state, the following events may trigger a transition:
+
+ Receive Join(S,G)
+ A Join(S,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (S,G) downstream state machine on interface I remains in
+ Join state. The Expiry Timer (ET) is restarted and is then
+ set to the maximum of its current value and the HoldTime
+ from the triggering Join/Prune message.
+
+ Receive Prune(S,G)
+ A Prune(S,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (S,G) downstream state machine on interface I
+ transitions to the Prune-Pending state. The
+ Prune-Pending Timer is started. It is set to the
+ J/P_Override_Interval(I) if the router has more than one
+ neighbor on that interface; otherwise, it is set to zero,
+ causing it to expire immediately.
+
+ Expiry Timer Expires
+ The Expiry Timer for the (S,G) downstream state machine on
+ interface I expires.
+
+ The (S,G) downstream state machine on interface I
+ transitions to the NoInfo state.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 52]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from Prune-Pending State
+
+ When in Prune-Pending state, the following events may trigger a
+ transition:
+
+ Receive Join(S,G)
+ A Join(S,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (S,G) downstream state machine on interface I
+ transitions to the Join state. The Prune-Pending Timer is
+ canceled (without triggering an expiry event). The
+ Expiry Timer (ET) is restarted and is then set to the
+ maximum of its current value and the HoldTime from the
+ triggering Join/Prune message.
+
+ Expiry Timer Expires
+ The Expiry Timer for the (S,G) downstream state machine on
+ interface I expires.
+
+ The (S,G) downstream state machine on interface I
+ transitions to the NoInfo state.
+
+ Prune-Pending Timer Expires
+ The Prune-Pending Timer for the (S,G) downstream state
+ machine on interface I expires.
+
+ The (S,G) downstream state machine on interface I
+ transitions to the NoInfo state. A PruneEcho(S,G) is sent
+ onto the subnet connected to interface I.
+
+ The action "Send PruneEcho(S,G)" is triggered when the
+ router stops forwarding on an interface as a result of a
+ prune. A PruneEcho(S,G) is simply a Prune(S,G) message sent
+ by the upstream router on a LAN with its own address in the
+ Upstream Neighbor Address field. Its purpose is to add
+ additional reliability so that if a Prune that should have
+ been overridden by another router is lost locally on the
+ LAN, then the PruneEcho may be received and cause the
+ override to happen. A PruneEcho(S,G) need not be sent on an
+ interface that contains only a single PIM neighbor during
+ the time this state machine was in Prune-Pending state.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 53]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.5.3. Receiving (S,G,rpt) Join/Prune Messages
+
+ The per-interface state machine for receiving (S,G,rpt) Join/Prune
+ messages is given below. There are five states:
+
+ NoInfo (NI)
+ The interface has no (S,G,rpt) Prune state and no (S,G,rpt)
+ timers running.
+
+ Prune (P)
+ The interface has (S,G,rpt) Prune state, which will cause
+ the router not to forward packets from S destined for G from
+ this interface even though the interface has active (*,G)
+ Join state.
+
+ Prune-Pending (PP)
+ The router has received a Prune(S,G,rpt) on this interface
+ from a downstream neighbor and is waiting to see whether the
+ prune will be overridden by another downstream router. For
+ forwarding purposes, the Prune-Pending state functions
+ exactly like the NoInfo state.
+
+ PruneTmp (P')
+ This state is a transient state that for forwarding purposes
+ behaves exactly like the Prune state. A (*,G) Join has been
+ received (which may cancel the (S,G,rpt) Prune). As we
+ parse the Join/Prune message from top to bottom, we first
+ enter this state if the message contains a (*,G) Join.
+ Later in the message, we will normally encounter an
+ (S,G,rpt) prune to reinstate the Prune state. However, if
+ we reach the end of the message without encountering such an
+ (S,G,rpt) prune, then we will revert to NoInfo state in this
+ state machine.
+
+ As no time is spent in this state, no timers can expire.
+
+ Prune-Pending-Tmp (PP')
+ This state is a transient state that is identical to P'
+ except that it is associated with the PP state rather than
+ the P state. For forwarding purposes, PP' behaves exactly
+ like the PP state.
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 54]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ In addition, there are two timers:
+
+ Expiry Timer (ET)
+ This timer is set when a valid Prune(S,G,rpt) is received.
+ Expiry of the Expiry Timer causes this state machine to
+ revert to NoInfo state.
+
+ Prune-Pending Timer (PPT)
+ This timer is set when a valid Prune(S,G,rpt) is received.
+ Expiry of the Prune-Pending Timer causes this state machine
+ to move on to Prune state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 55]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Figure 4: Downstream Per-Interface (S,G,rpt) State Machine
+
++----------++----------------------------------------------------------+
+| || Event |
+| ++---------+----------+----------+--------+--------+--------+
+|Prev ||Receive | Receive | Receive | End of | Prune- | Expiry |
+|State ||Join(*,G)| Join | Prune | Message| Pending| Timer |
+| || | (S,G,rpt)| (S,G,rpt)| | Timer | Expires|
+| || | | | | Expires| |
++----------++---------+----------+----------+--------+--------+--------+
+| ||- | - | -> PP | - | - | - |
+| || | | state | | | |
+| || | | start | | | |
+|NoInfo || | | Prune- | | | |
+|(NI) || | | Pending | | | |
+| || | | Timer; | | | |
+| || | | start | | | |
+| || | | Expiry | | | |
+| || | | Timer | | | |
++----------++---------+----------+----------+--------+--------+--------+
+| ||-> P' | -> NI | -> P | - | - | -> NI |
+| ||state | state | state | | | state |
+|Prune (P) || | | restart | | | |
+| || | | Expiry | | | |
+| || | | Timer | | | |
++----------++---------+----------+----------+--------+--------+--------+
+|Prune- ||-> PP' | -> NI | - | - | -> P | - |
+|Pending ||state | state | | | state | |
+|(PP) || | | | | | |
++----------++---------+----------+----------+--------+--------+--------+
+| ||- | - | -> P | -> NI | - | - |
+|PruneTmp || | | state | state | | |
+|(P') || | | restart | | | |
+| || | | Expiry | | | |
+| || | | Timer | | | |
++----------++---------+----------+----------+--------+--------+--------+
+| ||- | - | -> PP | -> NI | - | - |
+|Prune- || | | state | state | | |
+|Pending- || | | restart | | | |
+|Tmp (PP') || | | Expiry | | | |
+| || | | Timer | | | |
++----------++---------+----------+----------+--------+--------+--------+
+
+ 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 router's primary IP address on the received
+ interface. If the upstream neighbor address field is not correct,
+
+
+
+
+Fenner, et al. Standards Track [Page 56]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ these state transitions in this state machine MUST NOT occur,
+ although seeing such a packet may cause state transitions in other
+ state machines.
+
+ On unnumbered interfaces on point-to-point links, the router's
+ address 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 it is RECOMMENDED that PIM Join/Prune messages with an
+ upstream neighbor address field of all zeros also be accepted.
+
+ Transitions from NoInfo State
+
+ When in NoInfo (NI) state, the following event may trigger a
+ transition:
+
+ Receive Prune(S,G,rpt)
+ A Prune(S,G,rpt) is received on interface I with its
+ Upstream Neighbor Address set to the router's primary IP
+ address on I.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions to the Prune-Pending state. The Expiry Timer
+ (ET) is started and set to the HoldTime from the triggering
+ Join/Prune message. The Prune-Pending Timer is started. It
+ is set to the J/P_Override_Interval(I) if the router has
+ more than one neighbor on that interface; otherwise, it is
+ set to zero, causing it to expire immediately.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 57]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from Prune-Pending State
+
+ When in Prune-Pending (PP) state, the following events may trigger a
+ transition:
+
+ Receive Join(*,G)
+ A Join(*,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions to the Prune-Pending-Tmp state whilst the
+ remainder of the compound Join/Prune message containing the
+ Join(*,G) is processed.
+
+ Receive Join(S,G,rpt)
+ A Join(S,G,rpt) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions to the NoInfo state. The ET and PPT are
+ canceled.
+
+ Prune-Pending Timer Expires
+ The Prune-Pending Timer for the (S,G,rpt) downstream state
+ machine on interface I expires.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions to the Prune state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 58]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from Prune State
+
+ When in Prune (P) state, the following events may trigger a
+ transition:
+
+ Receive Join(*,G)
+ A Join(*,G) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions to the PruneTmp state whilst the remainder of
+ the compound Join/Prune message containing the Join(*,G) is
+ processed.
+
+ Receive Join(S,G,rpt)
+ A Join(S,G,rpt) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address
+ on I.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions to the NoInfo state. The ET and PPT are
+ canceled.
+
+ Receive Prune(S,G,rpt)
+ A Prune(S,G,rpt) is received on interface I with its
+ Upstream Neighbor Address set to the router's primary IP
+ address on I.
+
+ The (S,G,rpt) downstream state machine on interface I
+ remains in Prune state. The Expiry Timer (ET) is restarted
+ and is then set to the maximum of its current value and the
+ HoldTime from the triggering Join/Prune message.
+
+ Expiry Timer Expires
+ The Expiry Timer for the (S,G,rpt) downstream state machine
+ on interface I expires.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions to the NoInfo state.
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 59]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from Prune-Pending-Tmp State
+
+ When in Prune-Pending-Tmp (PP') state and processing a compound
+ Join/Prune message, the following events may trigger a transition:
+
+ Receive Prune(S,G,rpt)
+ The compound Join/Prune message contains a Prune(S,G,rpt)
+ that is received on interface I with its Upstream Neighbor
+ Address set to the router's primary IP address on I.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions back to the Prune-Pending state. The
+ Expiry Timer (ET) is restarted and is then set to the
+ maximum of its current value and the HoldTime from the
+ triggering Join/Prune message.
+
+ End of Message
+ The end of the compound Join/Prune message is reached.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions to the NoInfo state. The ET and PPT are
+ canceled.
+
+ Transitions from PruneTmp State
+
+ When in PruneTmp (P') state and processing a compound Join/Prune
+ message, the following events may trigger a transition:
+
+ Receive Prune(S,G,rpt)
+ The compound Join/Prune message contains a Prune(S,G,rpt).
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions back to the Prune state. The Expiry Timer (ET)
+ is restarted and is then set to the maximum of its current
+ value and the HoldTime from the triggering Join/Prune
+ message.
+
+ End of Message
+ The end of the compound Join/Prune message is reached.
+
+ The (S,G,rpt) downstream state machine on interface I
+ transitions to the NoInfo state. ET is canceled.
+
+ Note: Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream
+ state machine.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 60]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.5.4. Sending (*,G) Join/Prune Messages
+
+ The per-interface state machines for (*,G) hold join state from
+ downstream PIM routers. This state then determines whether a router
+ needs to propagate a Join(*,G) upstream towards the RP.
+
+ 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 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 it sees a Prune(*,G) to the correct upstream
+ neighbor, it should be prepared to override that prune by sending a
+ Join(*,G) almost immediately. Finally, if it sees the Generation ID
+ (see Section 4.3) of the correct upstream neighbor change, it knows
+ that the upstream neighbor has lost state, and it should be prepared
+ to refresh the state by sending a Join(*,G) almost immediately.
+
+ 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
+ ensure that the Assert winner is aware of downstream routers by
+ sending a Join(*,G) almost immediately.
+
+ 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 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.
+
+ The upstream (*,G) state machine only contains two states:
+
+ Not Joined
+ The downstream state machines indicate that the router does
+ not need to join the RP tree for this group.
+
+ Joined
+ The downstream state machines indicate that the router
+ should join the RP tree for this group.
+
+ In addition, one timer JT(*,G) is kept that is used to trigger the
+ sending of a Join(*,G) to the upstream next hop towards the RP,
+ RPF'(*,G).
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 61]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Figure 5: Upstream (*,G) State Machine
+
++-------------------++-------------------------------------------------+
+| || Event |
+| Prev State ++------------------------+------------------------+
+| || JoinDesired(*,G) | JoinDesired(*,G) |
+| || ->True | ->False |
++-------------------++------------------------+------------------------+
+| || -> J state | - |
+| NotJoined (NJ) || Send Join(*,G); | |
+| || set Join Timer to | |
+| || t_periodic | |
++-------------------++------------------------+------------------------+
+| Joined (J) || - | -> NJ state |
+| || | Send Prune(*,G); |
+| || | cancel Join Timer |
++-------------------++------------------------+------------------------+
+
+ In addition, we have the following transitions, which occur within
+ the Joined state:
+
++----------------------------------------------------------------------+
+| In Joined (J) State |
++----------------+-----------------+-----------------+-----------------+
+|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) |
+| | to RPF'(*,G) | to RPF'(*,G) | changes due to |
+| | | | an Assert |
++----------------+-----------------+-----------------+-----------------+
+|Send | Increase Join | Decrease Join | Decrease Join |
+|Join(*,G); set | Timer to | Timer to | Timer to |
+|Join Timer to | t_joinsuppress | t_override | t_override |
+|t_periodic | | | |
++----------------+-----------------+-----------------+-----------------+
+
++----------------------------------------------------------------------+
+| In Joined (J) State |
++----------------------------------+-----------------------------------+
+| RPF'(*,G) changes not | RPF'(*,G) GenID changes |
+| due to an Assert | |
++----------------------------------+-----------------------------------+
+| Send Join(*,G) to new | Decrease Join Timer to |
+| next hop; send | t_override |
+| Prune(*,G) to old next | |
+| hop; set Join Timer to | |
+| t_periodic | |
++----------------------------------+-----------------------------------+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 62]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ This state machine uses the following macro:
+
+ bool JoinDesired(*,G) {
+ if (immediate_olist(*,G) != NULL)
+ return TRUE
+ else
+ return FALSE
+ }
+
+ 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 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 upstream interface.
+
+ Transitions from NotJoined State
+
+ When the upstream (*,G) state machine is in NotJoined state, the
+ following event may trigger a state transition:
+
+ JoinDesired(*,G) becomes True
+ The macro JoinDesired(*,G) becomes True, e.g., because the
+ downstream state for (*,G) has changed so that at least one
+ interface is in immediate_olist(*,G).
+
+ The upstream (*,G) state machine transitions to the Joined
+ state. Send Join(*,G) to the appropriate upstream neighbor,
+ which is RPF'(*,G). Set the Join Timer (JT) to expire after
+ t_periodic seconds.
+
+ Transitions from Joined State
+
+ When the upstream (*,G) state machine is in Joined state, the
+ following events may trigger state transitions:
+
+ JoinDesired(*,G) becomes False
+ The macro JoinDesired(*,G) becomes False, e.g., because the
+ downstream state for (*,G) has changed so no interface is in
+ immediate_olist(*,G).
+
+ The upstream (*,G) state machine transitions to the
+ NotJoined state. Send Prune(*,G) to the appropriate
+ upstream neighbor, which is RPF'(*,G). Cancel the
+ Join Timer (JT).
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 63]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Join Timer Expires
+ The Join Timer (JT) expires, indicating time to send a
+ Join(*,G).
+
+ Send Join(*,G) to the appropriate upstream neighbor, which
+ is RPF'(*,G). Restart the Join Timer (JT) to expire after
+ t_periodic seconds.
+
+ See Join(*,G) to RPF'(*,G)
+ This event is only relevant if RPF_interface(RP(G)) is a
+ shared medium. This router sees another router on
+ RPF_interface(RP(G)) send a Join(*,G) to RPF'(*,G). This
+ causes this router to suppress its own Join.
+
+ The upstream (*,G) state machine remains in Joined state.
+
+ Let t_joinsuppress be the minimum of t_suppressed and the
+ HoldTime from the Join/Prune message triggering this event.
+ If the Join Timer is set to expire in less than
+ t_joinsuppress seconds, reset it so that it expires after
+ t_joinsuppress seconds. If the Join Timer is set to expire
+ in more than t_joinsuppress seconds, leave it unchanged.
+
+ See Prune(*,G) to RPF'(*,G)
+ This event is only relevant if RPF_interface(RP(G)) is a
+ shared medium. This router sees another router on
+ RPF_interface(RP(G)) send a Prune(*,G) to RPF'(*,G). As
+ this router is in Joined state, it must override the Prune
+ after a short random interval.
+
+ The upstream (*,G) state machine remains in Joined state.
+ If the Join Timer is set to expire in more than
+ t_override seconds, reset it so that it expires after
+ t_override seconds. If the Join Timer is set to expire in
+ less than t_override seconds, leave it unchanged.
+
+ RPF'(*,G) changes due to an Assert
+ The current next hop towards the RP changes due to an
+ Assert(*,G) on the RPF_interface(RP(G)).
+
+ The upstream (*,G) state machine remains in Joined state.
+ If the Join Timer is set to expire in more than
+ t_override seconds, reset it so that it expires after
+ t_override seconds. If the Join Timer is set to expire in
+ less than t_override seconds, leave it unchanged.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 64]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ RPF'(*,G) changes not due to an Assert
+ An event occurred that caused the next hop towards the RP
+ for G to change. This may be caused by a change in the MRIB
+ routing database or the group-to-RP mapping. Note that this
+ transition does not occur if an Assert is active and the
+ upstream interface does not change.
+
+ The upstream (*,G) state machine remains in Joined state.
+ Send Join(*,G) to the new upstream neighbor, which is the
+ new value of RPF'(*,G). Send Prune(*,G) to the old upstream
+ neighbor, which is the old value of RPF'(*,G). Use the new
+ value of RP(G) in the Prune(*,G) message or all zeros if
+ RP(G) becomes unknown (old value of RP(G) may be used
+ instead to improve behavior in routers implementing older
+ versions of this specification). Set the Join Timer (JT) to
+ expire after t_periodic seconds.
+
+ RPF'(*,G) GenID changes
+ The Generation ID of the router that is RPF'(*,G) changes.
+ This normally means that this neighbor has lost state, and
+ so the state must be refreshed.
+
+ The upstream (*,G) state machine remains in Joined state.
+ If the Join Timer is set to expire in more than
+ t_override seconds, reset it so that it expires after
+ t_override seconds.
+
+4.5.5. Sending (S,G) Join/Prune Messages
+
+ The per-interface state machines for (S,G) hold join state from
+ downstream PIM routers. This state then determines whether a router
+ 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 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 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 upstream neighbor towards S, it should be
+ prepared to override that prune by scheduling a Join(S,G) to be sent
+ almost immediately. Finally, if it sees the Generation ID of its
+ upstream neighbor change, it knows that the upstream neighbor has
+ lost state, and it should refresh the state by scheduling a Join(S,G)
+ to be sent almost immediately.
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 65]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ If an (S,G) Assert occurs on the upstream interface, and this changes
+ this router's idea of the upstream neighbor, it should be prepared to
+ ensure that the Assert winner is aware of downstream routers by
+ scheduling a Join(S,G) to be sent almost immediately.
+
+ 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 winner on the upstream interface, the router should send a
+ prune to the old next hop and a join to the new next hop.
+
+ The upstream (S,G) state machine only contains two states:
+
+ Not Joined
+ The downstream state machines and local membership
+ information do not indicate that the router needs to join
+ the shortest-path tree for this (S,G).
+
+ Joined
+ The downstream state machines and local membership
+ information indicate that the router should join the
+ shortest-path tree for this (S,G).
+
+ In addition, one timer JT(S,G) is kept that is used to trigger the
+ sending of a Join(S,G) to the upstream next hop towards S, RPF'(S,G).
+
+ Figure 6: Upstream (S,G) State Machine
+
++-------------------+--------------------------------------------------+
+| | Event |
+| Prev State +-------------------------+------------------------+
+| | JoinDesired(S,G) | JoinDesired(S,G) |
+| | ->True | ->False |
++-------------------+-------------------------+------------------------+
+| NotJoined (NJ) | -> J state | - |
+| | Send Join(S,G); | |
+| | set Join Timer to | |
+| | t_periodic | |
++-------------------+-------------------------+------------------------+
+| Joined (J) | - | -> NJ state |
+| | | Send Prune(S,G); |
+| | | set SPTbit(S,G) to |
+| | | FALSE; cancel Join |
+| | | Timer |
++-------------------+-------------------------+------------------------+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 66]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ In addition, we have the following transitions, which occur within
+ the Joined state:
+
++----------------------------------------------------------------------+
+| In Joined (J) State |
++-----------------+-----------------+-----------------+----------------+
+| Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune |
+| | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to |
+| | | | RPF'(S,G) |
++-----------------+-----------------+-----------------+----------------+
+| Send | Increase Join | Decrease Join | Decrease Join |
+| Join(S,G); set | Timer to | Timer to | Timer to |
+| Join Timer to | t_joinsuppress | t_override | t_override |
+| t_periodic | | | |
++-----------------+-----------------+-----------------+----------------+
+
++----------------------------------------------------------------------+
+| In Joined (J) State |
++-----------------+-----------------+----------------+-----------------+
+| See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) |
+| to RPF'(S,G) | changes not | GenID changes | changes due to |
+| | due to an | | an Assert |
+| | Assert | | |
++-----------------+-----------------+----------------+-----------------+
+| Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join |
+| Timer to | to new next | Timer to | Timer to |
+| t_override | hop; send | t_override | t_override |
+| | Prune(S,G) to | | |
+| | old next hop; | | |
+| | set Join Timer | | |
+| | to t_periodic | | |
++-----------------+-----------------+----------------+-----------------+
+
+ This state machine uses the following macro:
+
+ bool JoinDesired(S,G) {
+ return( immediate_olist(S,G) != NULL
+ OR ( KeepaliveTimer(S,G) is running
+ AND inherited_olist(S,G) != NULL ) )
+ }
+
+ 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 tree state can be as a result of either active source-specific
+ join 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 Join(S,G) message may be suppressed by another router
+ sending a Join(S,G) onto the upstream interface.
+
+
+
+Fenner, et al. Standards Track [Page 67]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from NotJoined State
+
+ When the upstream (S,G) state machine is in NotJoined state, the
+ following event may trigger a state transition:
+
+ JoinDesired(S,G) becomes True
+ The macro JoinDesired(S,G) becomes True, e.g., because the
+ downstream state for (S,G) has changed so that at least one
+ interface is in inherited_olist(S,G).
+
+ The upstream (S,G) state machine transitions to the Joined
+ state. Send Join(S,G) to the appropriate upstream neighbor,
+ which is RPF'(S,G). Set the Join Timer (JT) to expire after
+ t_periodic seconds.
+
+ Transitions from Joined State
+
+ When the upstream (S,G) state machine is in Joined state, the
+ following events may trigger state transitions:
+
+ JoinDesired(S,G) becomes False
+ The macro JoinDesired(S,G) becomes False, e.g., because the
+ downstream state for (S,G) has changed so no interface is in
+ inherited_olist(S,G).
+
+ The upstream (S,G) state machine transitions to the
+ NotJoined state. Send Prune(S,G) to the appropriate
+ upstream neighbor, which is RPF'(S,G). Cancel the
+ Join Timer (JT), and set SPTbit(S,G) to FALSE.
+
+ Join Timer Expires
+ The Join Timer (JT) expires, indicating time to send a
+ Join(S,G).
+
+ Send Join(S,G) to the appropriate upstream neighbor, which
+ is RPF'(S,G). Restart the Join Timer (JT) to expire after
+ t_periodic seconds.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 68]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ See Join(S,G) to RPF'(S,G)
+ This event is only relevant if RPF_interface(S) is a shared
+ medium. This router sees another router on RPF_interface(S)
+ send a Join(S,G) to RPF'(S,G). This causes this router to
+ suppress its own Join.
+
+ The upstream (S,G) state machine remains in Joined state.
+
+ Let t_joinsuppress be the minimum of t_suppressed and the
+ HoldTime from the Join/Prune message triggering this event.
+
+ If the Join Timer is set to expire in less than
+ t_joinsuppress seconds, reset it so that it expires after
+ t_joinsuppress seconds. If the Join Timer is set to expire
+ in more than t_joinsuppress seconds, leave it unchanged.
+
+ See Prune(S,G) to RPF'(S,G)
+ This event is only relevant if RPF_interface(S) is a shared
+ medium. This router sees another router on RPF_interface(S)
+ send a Prune(S,G) to RPF'(S,G). As this router is in Joined
+ state, it must override the Prune after a short random
+ interval.
+
+ The upstream (S,G) state machine remains in Joined state.
+ If the Join Timer is set to expire in more than
+ t_override seconds, reset it so that it expires after
+ t_override seconds.
+
+ See Prune(S,G,rpt) to RPF'(S,G)
+ This event is only relevant if RPF_interface(S) is a shared
+ medium. This router sees another router on RPF_interface(S)
+ send a Prune(S,G,rpt) to RPF'(S,G). If the upstream router
+ is an RFC-2362-compliant PIM router, then the Prune(S,G,rpt)
+ will cause it to stop forwarding. For backwards
+ compatibility, this router should override the prune so that
+ forwarding continues.
+
+ The upstream (S,G) state machine remains in Joined state.
+ If the Join Timer is set to expire in more than
+ t_override seconds, reset it so that it expires after
+ t_override seconds.
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 69]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ See Prune(*,G) to RPF'(S,G)
+ This event is only relevant if RPF_interface(S) is a shared
+ medium. This router sees another router on RPF_interface(S)
+ send a Prune(*,G) to RPF'(S,G). If the upstream router is
+ an RFC-2362-compliant PIM router, then the Prune(*,G) will
+ cause it to stop forwarding. For backwards compatibility,
+ this router should override the prune so that forwarding
+ continues.
+
+ The upstream (S,G) state machine remains in Joined state.
+ If the Join Timer is set to expire in more than
+ t_override seconds, reset it so that it expires after
+ t_override seconds.
+
+ RPF'(S,G) changes due to an Assert
+ The current next hop towards S changes due to an Assert(S,G)
+ on the RPF_interface(S).
+
+ The upstream (S,G) state machine remains in Joined state.
+ If the Join Timer is set to expire in more than
+ t_override seconds, reset it so that it expires after
+ t_override seconds. If the Join Timer is set to expire in
+ less than t_override seconds, leave it unchanged.
+
+ RPF'(S,G) changes not due to an Assert
+ An event occurred that caused the next hop towards S to
+ change. Note that this transition does not occur if an
+ Assert is active and the upstream interface does not change.
+
+ The upstream (S,G) state machine remains in Joined state.
+ Send Join(S,G) to the new upstream neighbor, which is the
+ new value of RPF'(S,G). Send Prune(S,G) to the old upstream
+ neighbor, which is the old value of RPF'(S,G). Set the
+ Join Timer (JT) to expire after t_periodic seconds.
+
+ RPF'(S,G) GenID changes
+ The Generation ID of the router that is RPF'(S,G) changes.
+ This normally means that this neighbor has lost state, and
+ so the state must be refreshed.
+
+ The upstream (S,G) state machine remains in Joined state.
+ If the Join Timer is set to expire in more than
+ t_override seconds, reset it so that it expires after
+ t_override seconds.
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 70]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.5.6. (S,G,rpt) Periodic Messages
+
+ (S,G,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP
+ tree with the RPT bit set, either to modify the results of (*,G)
+ Joins, or to override the behavior of other upstream LAN peers. The
+ next section describes the rules for sending triggered messages.
+ This section describes the rules for including a Prune(S,G,rpt)
+ message with a Join(*,G).
+
+ When a router is going to send a Join(*,G), it should use the
+ following pseudocode, for each (S,G) for which it has state, to
+ decide whether to include a Prune(S,G,rpt) in the compound Join/Prune
+ message:
+
+ if( SPTbit(S,G) == TRUE ) {
+ # Note: If receiving (S,G) on the SPT, we only prune off the
+ # shared tree if the RPF neighbors differ.
+ if( RPF'(*,G) != RPF'(S,G) ) {
+ add Prune(S,G,rpt) to compound message
+ }
+ } else if ( inherited_olist(S,G,rpt) == NULL ) {
+ # Note: All (*,G) olist interfaces received RPT prunes for (S,G).
+ add Prune(S,G,rpt) to compound message
+ } else if ( RPF'(*,G) != RPF'(S,G,rpt) {
+ # Note: We joined the shared tree, but there was an (S,G) assert
+ # and the source tree RPF neighbor is different.
+ add Prune(S,G,rpt) to compound message
+ }
+
+ Note that Join(S,G,rpt) is normally sent not as a periodic message,
+ but only as a triggered message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 71]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.5.7. State Machine for (S,G,rpt) Triggered Messages
+
+ The state machine for (S,G,rpt) triggered messages is required
+ per-(S,G) when there is (*,G) join state at a router, and the router
+ 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 is no (*,G) join state at this router. If there is (*,G)
+ join state at the router, then the state machine must be at one of
+ the other two states. The three states are:
+
+ Pruned(S,G,rpt)
+ (*,G) Joined, but (S,G,rpt) pruned.
+
+ NotPruned(S,G,rpt)
+ (*,G) Joined, and (S,G,rpt) not pruned.
+
+ RPTNotJoined(G)
+ (*,G) has not been joined.
+
+ 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 triggered messages.
+
+ Figure 7: Upstream (S,G,rpt) State Machine for Triggered Messages
+
++------------++--------------------------------------------------------+
+| || Event |
+| ++--------------+--------------+-------------+------------+
+|Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ |
+| || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist |
+| || ->True | ->False | ->False | (S,G,rpt) |
+| || | | | ->non-NULL |
++------------++--------------+--------------+-------------+------------+
+|RPTNotJoined|| -> P state | - | - | -> NP state|
+|(G) (NJ) || | | | |
++------------++--------------+--------------+-------------+------------+
+|Pruned || - | -> NP state | -> NJ state | - |
+|(S,G,rpt) || | Send Join | | |
+|(P) || | (S,G,rpt) | | |
++------------++--------------+--------------+-------------+------------+
+|NotPruned || -> P state | - | -> NJ state | - |
+|(S,G,rpt) || Send Prune | | Cancel OT | |
+|(NP) || (S,G,rpt); | | | |
+| || cancel OT | | | |
++------------++--------------+--------------+-------------+------------+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 72]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Additionally, we have the following transitions within the
+ NotPruned(S,G,rpt) state, which are all used for prune override
+ behavior.
+
++----------------------------------------------------------------------+
+| In NotPruned(S,G,rpt) State |
++----------+--------------+--------------+--------------+--------------+
+|Override | See Prune | See Join | See Prune | RPF' |
+|Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> |
+|expires | RPF' | RPF' | RPF' | RPF' (*,G) |
+| | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | |
++----------+--------------+--------------+--------------+--------------+
+|Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, |
+|(S,G,rpt);| t_override) | | t_override) | t_override) |
+|leave OT | | | | |
+|unset | | | | |
++----------+--------------+--------------+--------------+--------------+
+
+ Note that the min function in the above state machine considers a
+ non-running timer to have an infinite value (e.g., min(not-running,
+ t_override) = t_override).
+
+ This state machine uses the following macros:
+
+ bool RPTJoinDesired(G) {
+ return (JoinDesired(*,G))
+ }
+
+ RPTJoinDesired(G) is true when the router has forwarding state that
+ would cause it to forward traffic for G using (*,G) shared tree
+ state.
+
+ bool PruneDesired(S,G,rpt) {
+ return ( RPTJoinDesired(G) AND
+ ( inherited_olist(S,G,rpt) == NULL
+ OR (SPTbit(S,G)==TRUE
+ AND (RPF'(*,G) != RPF'(S,G)) )))
+ }
+
+ PruneDesired(S,G,rpt) can only be true if RPTJoinDesired(G) is true.
+ If RPTJoinDesired(G) is true, then PruneDesired(S,G,rpt) is true
+ either if there are no outgoing interfaces that S would be forwarded
+ on, or if the router has active (S,G) forwarding state but RPF'(*,G)
+ != RPF'(S,G).
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 73]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ The state machine contains the following transition events:
+
+ See Join(S,G,rpt) to RPF'(S,G,rpt)
+ This event is only relevant in the "Not Pruned" state.
+
+ The router sees a Join(S,G,rpt) from someone else to
+ RPF'(S,G,rpt), which is the correct upstream neighbor. If
+ we're in "NotPruned" state and the (S,G,rpt) Override Timer
+ is running, then this is because we have been triggered to
+ send our own Join(S,G,rpt) to RPF'(S,G,rpt). Someone else
+ beat us to it, so there's no need to send our own Join.
+
+ The action is to cancel the Override Timer.
+
+ See Prune(S,G,rpt) to RPF'(S,G,rpt)
+ This event is only relevant in the "NotPruned" state.
+
+ The router sees a Prune(S,G,rpt) from someone else to
+ RPF'(S,G,rpt), which is the correct upstream neighbor. If
+ we're in the "NotPruned" state, then we want to continue to
+ receive traffic from S destined for G, and that traffic is
+ being supplied by RPF'(S,G,rpt). Thus, we need to override
+ the Prune.
+
+ The action is to set the (S,G,rpt) Override Timer to the
+ randomized prune-override interval, t_override. However, if
+ the Override Timer is already running, we only set the timer
+ if doing so would set it to a lower value. At the end of
+ this interval, if no one else has sent a Join, then we will
+ do so.
+
+ See Prune(S,G) to RPF'(S,G,rpt)
+ This event is only relevant in the "NotPruned" state.
+
+ This transition and action are the same as the above
+ transition and action, except that the Prune does not have
+ the RPT bit set. This transition is necessary to be
+ compatible with routers implemented from RFC 2362 that don't
+ maintain separate (S,G) and (S,G,rpt) state.
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 74]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ The (S,G,rpt) prune Override Timer expires
+ This event is only relevant in the "NotPruned" state.
+
+ When the Override Timer expires, we must send a
+ Join(S,G,rpt) to RPF'(S,G,rpt) to override the Prune message
+ that caused the timer to be running. We only send this if
+ RPF'(S,G,rpt) equals RPF'(*,G); if this were not the case,
+ then the Join might be sent to a router that does not have
+ (*,G) Join state, and so the behavior would not be well
+ defined. If RPF'(S,G,rpt) is not the same as RPF'(*,G),
+ then it may stop forwarding S. However, if this happens,
+ then the router will send an AssertCancel(S,G), which would
+ then cause RPF'(S,G,rpt) to become equal to RPF'(*,G) (see
+ below).
+
+ RPF'(S,G,rpt) changes to become equal to RPF'(*,G)
+ This event is only relevant in the "NotPruned" state.
+
+ RPF'(S,G,rpt) can only be different from RPF'(*,G) if an
+ (S,G) Assert has happened, which means that traffic from S
+ is arriving on the SPT, and so Prune(S,G,rpt) will have been
+ sent to RPF'(*,G). When RPF'(S,G,rpt) changes to become
+ equal to RPF'(*,G), we need to trigger a Join(S,G,rpt) to
+ RPF'(*,G) to cause that router to start forwarding S again.
+
+ The action is to set the (S,G,rpt) Override Timer to the
+ randomized prune-override interval t_override. However, if
+ the timer is already running, we only set the timer if doing
+ so would set it to a lower value. At the end of this
+ interval, if no one else has sent a Join, then we will
+ do so.
+
+ PruneDesired(S,G,rpt)->TRUE
+ See macro above. This event is relevant in the "NotPruned"
+ and "RPTNotJoined(G)" states.
+
+ The router wishes to receive traffic for G but does not wish
+ to receive traffic from S destined for G. This causes the
+ router to transition into the Pruned state.
+
+ If the router was previously in NotPruned state, then the
+ action is to send a Prune(S,G,rpt) to RPF'(S,G,rpt), and to
+ cancel the Override Timer. If the router was previously in
+ RPTNotJoined(G) state, then there is no need to trigger an
+ action in this state machine because sending a
+ Prune(S,G,rpt) is handled by the rules for sending the
+ Join(*,G).
+
+
+
+
+Fenner, et al. Standards Track [Page 75]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ PruneDesired(S,G,rpt)->FALSE
+ See macro above. This transition is only relevant in the
+ "Pruned" state.
+
+ If the router is in the Pruned(S,G,rpt) state, and
+ PruneDesired(S,G,rpt) changes to FALSE, this could be
+ because the router no longer has RPTJoinDesired(G) true, or
+ it now wishes to receive traffic from S again. If it is the
+ former, then this transition should not happen, but instead
+ the "RPTJoinDesired(G)->FALSE" transition should happen.
+ Thus, this transition should be interpreted as
+ "PruneDesired(S,G,rpt)->FALSE AND RPTJoinDesired(G)==TRUE".
+
+ The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt).
+
+ RPTJoinDesired(G)->FALSE
+ This event is relevant in the "Pruned" and "NotPruned"
+ states.
+
+ The router no longer wishes to receive any traffic destined
+ for G on the RP Tree. This causes a transition to the
+ RPTNotJoined(G) state, and the Override Timer is canceled if
+ it was running. Any further actions are handled by the
+ appropriate upstream state machine for (*,G).
+
+ inherited_olist(S,G,rpt) becomes non-NULL
+ This transition is only relevant in the RPTNotJoined(G)
+ state.
+
+ The router has joined the RP tree (handled by the (*,G)
+ upstream state machine as appropriate) and wants to receive
+ traffic from S. This does not trigger any events in this
+ state machine, but causes a transition to the
+ NotPruned(S,G,rpt) state.
+
+4.6. PIM Assert Messages
+
+ Where multiple PIM routers peer over a shared LAN, it is possible for
+ more than one upstream router to have valid forwarding state for a
+ packet, which can lead to packet duplication (see Section 3.6). PIM
+ does not attempt to prevent this from occurring. Instead, it detects
+ when this has happened and elects a single forwarder amongst the
+ upstream routers to prevent further duplication. This election is
+ performed using PIM Assert messages. Assert messages are also
+ received by downstream routers on the LAN, and these cause subsequent
+ Join/Prune messages to be sent to the upstream router that won the
+ Assert.
+
+
+
+
+Fenner, et al. Standards Track [Page 76]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ In general, a PIM Assert message should only be accepted for
+ processing if it comes from a known PIM neighbor. A PIM router hears
+ about PIM neighbors through PIM Hello messages. If a router receives
+ an Assert message from a particular IP source address and it has not
+ seen a PIM Hello message from that source address, then the Assert
+ message SHOULD be discarded without further processing. In addition,
+ if the Hello message from a neighbor was authenticated (see
+ Section 6.3), then all Assert messages from that neighbor MUST also
+ be authenticated.
+
+ We note that some older PIM implementations incorrectly fail to send
+ Hello messages on point-to-point interfaces, so we also RECOMMEND
+ that a configuration option be provided to allow interoperation with
+ such older routers, but that this configuration option SHOULD NOT be
+ enabled by default.
+
+4.6.1. (S,G) Assert Message State Machine
+
+ The (S,G) Assert state machine for interface I is shown in Figure 8.
+ There are three states:
+
+ NoInfo (NI)
+ This router has no (S,G) assert state on interface I.
+
+ I am Assert Winner (W)
+ This router has won an (S,G) assert on interface I. It is
+ now responsible for forwarding traffic from S destined for G
+ out of interface I. Irrespective of whether it is the DR
+ for I, while a router is the assert winner, it is also
+ responsible for forwarding traffic onto I on behalf of local
+ hosts on I that have made membership requests that
+ specifically refer to S (and G).
+
+ I am Assert Loser (L)
+ 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 the DR on I, it is no longer
+ responsible for forwarding traffic onto I to satisfy local
+ hosts with membership requests that specifically refer to S
+ and G.
+
+ 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.
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 77]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Figure 8: Per-Interface (S,G) Assert State Machine
+
++----------------------------------------------------------------------+
+| In NoInfo (NI) State |
++---------------+-------------------+------------------+---------------+
+| Receive | Receive Assert | Data arrives | Receive |
+| Inferior | with RPTbit | from S to G on | Acceptable |
+| Assert with | set and | I and | Assert with |
+| RPTbit clear | CouldAssert | CouldAssert | RPTbit clear |
+| | (S,G,I) | (S,G,I) | and AssTrDes |
+| | | | (S,G,I) |
++---------------+-------------------+------------------+---------------+
+| -> W state | -> W state | -> W state | -> L state |
+| [Actions A1] | [Actions A1] | [Actions A1] | [Actions A6] |
++---------------+-------------------+------------------+---------------+
+
++----------------------------------------------------------------------+
+| In I Am Assert Winner (W) State |
++----------------+------------------+-----------------+----------------+
+| Assert Timer | Receive | Receive | CouldAssert |
+| Expires | Inferior | Preferred | (S,G,I) -> |
+| | Assert | Assert | FALSE |
++----------------+------------------+-----------------+----------------+
+| -> W state | -> W state | -> L state | -> NI state |
+| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
++----------------+------------------+-----------------+----------------+
+
++---------------------------------------------------------------------+
+| In I Am Assert Loser (L) State |
++-------------+-------------+-------------+-------------+-------------+
+|Receive |Receive |Receive |Assert Timer |Current |
+|Preferred |Acceptable |Inferior |Expires |Winner's |
+|Assert |Assert with |Assert or | |GenID |
+| |RPTbit clear |Assert | |Changes or |
+| |from Current |Cancel from | |NLT Expires |
+| |Winner |Current | | |
+| | |Winner | | |
++-------------+-------------+-------------+-------------+-------------+
+|-> L state |-> L state |-> NI state |-> NI state |-> NI state |
+|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
++-------------+-------------+-------------+-------------+-------------+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 78]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
++----------------------------------------------------------------------+
+| In I Am Assert Loser (L) State |
++----------------+-----------------+------------------+----------------+
+| AssTrDes | my_metric -> | RPF_interface | Receive |
+| (S,G,I) -> | better than | (S) stops | Join(S,G) on |
+| FALSE | winner's | being I | interface I |
+| | metric | | |
++----------------+-----------------+------------------+----------------+
+| -> NI state | -> NI state | -> NI state | -> NI State |
+| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
++----------------+-----------------+------------------+----------------+
+
+ Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in
+ the state machine table to refer to AssertTrackingDesired(S,G,I).
+
+ Terminology:
+
+ A "preferred assert" is one with a better metric than the current
+ winner.
+
+ An "acceptable assert" is one that has a better metric than
+ my_assert_metric(S,G,I). An assert is never considered acceptable
+ if its metric is infinite.
+
+ An "inferior assert" is one with a worse metric than
+ my_assert_metric(S,G,I). An assert is never considered inferior
+ if my_assert_metric(S,G,I) is infinite.
+
+ The state machine uses the following macros:
+
+ CouldAssert(S,G,I) =
+ SPTbit(S,G)==TRUE
+ AND (RPF_interface(S) != I)
+ AND (I in ( ( joins(*,G) (-) prunes(S,G,rpt) )
+ (+) ( pim_include(*,G) (-) pim_exclude(S,G) )
+ (-) lost_assert(*,G)
+ (+) joins(S,G) (+) pim_include(S,G) ) )
+
+ CouldAssert(S,G,I) is true for downstream interfaces that would be in
+ the inherited_olist(S,G) if (S,G) assert information was not taken
+ into account.
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 79]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ AssertTrackingDesired(S,G,I) =
+ (I in ( joins(*,G) (-) prunes(S,G,rpt)
+ (+) ( pim_include(*,G) (-) pim_exclude(S,G) )
+ (-) lost_assert(*,G)
+ (+) joins(S,G) ) )
+ OR (local_receiver_include(S,G,I) == TRUE
+ AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me)))
+ OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE))
+ OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE)
+ AND (SPTbit(S,G) == FALSE))
+
+ AssertTrackingDesired(S,G,I) is true on any interface in which an
+ (S,G) assert might affect the router's behavior on that interface.
+
+ The first three lines of AssertTrackingDesired account for (*,G) join
+ and local membership information received on I that might cause the
+ router to be interested in asserts on I.
+
+ The 4th line accounts for (S,G) join information received on I that
+ might cause the router to be interested in asserts on I.
+
+ The 5th and 6th lines account for (S,G) local membership information
+ on I. Note that we can't use the pim_include(S,G) macro, since it
+ uses lost_assert(S,G,I) and would result in the router forgetting
+ that it lost an assert if the only reason it was interested was local
+ membership. The AssertWinner(S,G,I) check forces an assert winner to
+ keep on being responsible for forwarding as long as local receivers
+ are present. Removing this check would make the assert winner
+ give up forwarding as soon as the information that originally caused
+ it to forward went away, and the task of forwarding for local
+ receivers would revert back to the DR.
+
+ The last three lines account for the fact that a router must keep
+ track of assert information on upstream interfaces in order to send
+ joins and prunes to the proper neighbor.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 80]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from NoInfo State
+
+ When in NoInfo state, the following events may trigger transitions:
+
+ Receive Inferior Assert with RPTbit cleared
+ An assert is received for (S,G) with the RPT bit cleared
+ that is inferior to our own assert metric. The RPT bit
+ cleared indicates that the sender of the assert had (S,G)
+ forwarding state on this interface. If the assert is
+ inferior to our metric, then we must also have (S,G)
+ forwarding state (i.e., CouldAssert(S,G,I)==TRUE) as (S,G)
+ asserts have priority over (*,G) asserts, and so we should
+ be the assert winner. We transition to the "I am Assert
+ Winner" state and perform Actions A1 (below).
+
+ Receive Assert with RPTbit set AND CouldAssert(S,G,I)==TRUE
+ An assert is received for (S,G) on I with the RPT bit set
+ (it is a (*,G) assert). CouldAssert(S,G,I) is TRUE only if
+ we have (S,G) forwarding state on this interface, so we
+ should be the assert winner. We transition to the "I am
+ Assert Winner" state and perform Actions A1 (below).
+
+ An (S,G) data packet arrives on interface I, AND
+ CouldAssert(S,G,I)==TRUE
+ An (S,G) data packet arrived on a downstream interface that
+ is in our (S,G) outgoing interface list. We optimistically
+ assume that we will be the assert winner for this (S,G), and
+ so we transition to the "I am Assert Winner" state and
+ perform Actions A1 (below), which will initiate the assert
+ negotiation for (S,G).
+
+ Receive Acceptable Assert with RPT bit clear AND
+ AssertTrackingDesired(S,G,I)==TRUE
+ We're interested in (S,G) Asserts, either because I is a
+ downstream interface for which we have (S,G) or (*,G)
+ forwarding state, or because I is the upstream interface for
+ S 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 transition to "I am Assert Loser" and perform
+ Actions A6 (below).
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 81]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from "I am Assert Winner" State
+
+ When in "I am Assert Winner" state, the following events trigger
+ transitions:
+
+ Assert Timer Expires
+ The (S,G) Assert Timer expires. As we're in the Winner
+ state, we must still have (S,G) forwarding state that is
+ actively being kept alive. We resend the (S,G) Assert and
+ restart the Assert Timer (Actions A3 below). Note that the
+ assert winner's Assert Timer is engineered to expire shortly
+ before timers on assert losers; this prevents unnecessary
+ thrashing of the forwarder and periodic flooding of
+ duplicate packets.
+
+ Receive Inferior Assert
+ We receive an (S,G) assert or (*,G) assert mentioning S that
+ has a worse metric than our own. Whoever sent the assert is
+ in error, and so we resend an (S,G) Assert and restart the
+ Assert Timer (Actions A3 below).
+
+ Receive Preferred Assert
+ We receive an (S,G) assert that has a better metric than our
+ own. We transition to "I am Assert Loser" state and perform
+ Actions A2 (below). Note that this may affect the value of
+ JoinDesired(S,G) and PruneDesired(S,G,rpt), which could
+ cause transitions in the upstream (S,G) or (S,G,rpt) state
+ machines.
+
+ CouldAssert(S,G,I) -> FALSE
+ Our (S,G) forwarding state or RPF interface changed so as to
+ make CouldAssert(S,G,I) become false. We can no longer
+ perform the actions of the assert winner, and so we
+ transition to NoInfo state and perform Actions A4 (below).
+ This includes sending a "canceling assert" with an infinite
+ metric.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 82]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from "I am Assert Loser" State
+
+ When in "I am Assert Loser" state, the following transitions can
+ occur:
+
+ Receive Preferred Assert
+ We receive an assert that is better than that of the current
+ assert winner. We stay in Loser state and perform
+ Actions A2 below.
+
+ Receive Acceptable Assert with RPTbit clear from Current Winner
+ We receive an assert from the current assert winner that is
+ better than our own metric for this (S,G) (although the
+ metric may be worse than the winner's previous metric). We
+ stay in Loser state and perform Actions A2 below.
+
+ Receive Inferior Assert or Assert Cancel from Current Winner
+ We receive an assert from the current assert winner that is
+ worse than our own metric for this group (typically, because
+ the winner's metric became worse or because it is an assert
+ cancel). We transition to NoInfo state, deleting the (S,G)
+ assert information and allowing the normal PIM Join/Prune
+ mechanisms to operate. Usually, we will eventually
+ re-assert and win when data packets from S have started
+ flowing again.
+
+ Assert Timer Expires
+ The (S,G) Assert Timer expires. We transition to NoInfo
+ state, deleting the (S,G) assert information (Actions A5
+ below).
+
+ Current Winner's GenID Changes or NLT Expires
+ The Neighbor Liveness Timer associated with the current
+ winner expires or we receive a Hello message from the
+ current winner reporting a different GenID from the one it
+ previously reported. This indicates that the current
+ winner's interface or router has gone down (and may have
+ come back up), and so we must assume that it no longer knows
+ it was the winner. We transition to the NoInfo state,
+ deleting this (S,G) assert information (Actions A5 below).
+
+ AssertTrackingDesired(S,G,I)->FALSE
+ AssertTrackingDesired(S,G,I) becomes FALSE. Our forwarding
+ state has changed so that (S,G) Asserts on interface I are
+ no longer of interest to us. We transition to the NoInfo
+ state, deleting the (S,G) assert information.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 83]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ My metric becomes better than the assert winner's metric
+ my_assert_metric(S,G,I) has changed so that now my assert
+ metric for (S,G) is better than the metric we have stored
+ for the current assert winner. This might happen when the
+ underlying routing metric changes, or when
+ CouldAssert(S,G,I) becomes true, for example, when
+ SPTbit(S,G) becomes true. We transition to NoInfo state,
+ delete this (S,G) assert state (Actions A5 below), and allow
+ the normal PIM Join/Prune mechanisms to operate. Usually,
+ we will eventually re-assert and win when data packets from
+ S have started flowing again.
+
+ RPF_interface(S) stops being interface I
+ Interface I used to be the RPF interface for S, and now it
+ is not. We transition to NoInfo state, deleting this (S,G)
+ assert state (Actions A5 below).
+
+ Receive Join(S,G) on Interface I
+ We receive a Join(S,G) that has the Upstream Neighbor
+ Address field set to my primary IP address on interface I.
+ The action is to transition to NoInfo state, delete this
+ (S,G) assert state (Actions A5 below), and allow the normal
+ PIM Join/Prune mechanisms to operate. If whoever sent the
+ Join was in error, then the normal assert mechanism will
+ eventually re-apply, and we will lose the assert again.
+ However, whoever sent the assert may know that the previous
+ assert winner has died, and so we may end up being the new
+ forwarder.
+
+ (S,G) Assert State Machine Actions
+
+ A1: Send Assert(S,G).
+ Set Assert Timer to (Assert_Time - Assert_Override_Interval).
+ Store self as AssertWinner(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
+ winner metric as AssertWinnerMetric(S,G,I).
+ Set Assert Timer to Assert_Time.
+
+ A3: Send Assert(S,G).
+ Set Assert Timer to (Assert_Time - Assert_Override_Interval).
+
+ A4: Send AssertCancel(S,G).
+ Delete assert information (AssertWinner(S,G,I) and
+ AssertWinnerMetric(S,G,I) will then return to their default
+ values).
+
+
+
+
+Fenner, et al. Standards Track [Page 84]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ A5: Delete assert information (AssertWinner(S,G,I) and
+ AssertWinnerMetric(S,G,I) will then return to their default
+ values).
+
+ A6: Store new assert winner as AssertWinner(S,G,I) and assert
+ winner metric as AssertWinnerMetric(S,G,I).
+ Set Assert Timer to Assert_Time.
+ If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) ==
+ Joined) set SPTbit(S,G) to TRUE.
+
+ 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 transitions in other state machines.
+
+4.6.2. (*,G) Assert Message State Machine
+
+ The (*,G) Assert state machine for interface I is shown in Figure 9.
+ There are three states:
+
+ NoInfo (NI)
+ This router has no (*,G) assert state on interface I.
+
+ I am Assert Winner (W)
+ This router has won a (*,G) assert on interface I. It is
+ now responsible for forwarding traffic destined for G onto
+ interface I 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 also responsible for handling the
+ membership requests for G from local hosts on I.
+
+ I am Assert Loser (L)
+ This router has lost a (*,G) assert on interface I. It must
+ not forward packets for G onto interface I with the
+ exception of traffic from sources for which it has (S,G) "I
+ am Assert Winner" state. If it is the DR, it is no longer
+ responsible for handling the membership requests for group G
+ from local hosts on I.
+
+ In addition, there is also an Assert Timer (AT) that is used to time
+ out asserts on the assert losers and to resend asserts on the assert
+ winner.
+
+ When an Assert message is received with a source address other than
+ zero, a PIM implementation must first match it against the possible
+ events in the (S,G) assert state machine and process any transitions
+ and actions, before considering whether the Assert message matches
+ against the (*,G) assert state machine.
+
+
+
+
+Fenner, et al. Standards Track [Page 85]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ 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) assert state machine for the relevant S and G is in the
+ "NoInfo" state after the (S,G) state machine has processed the
+ message. Also, NO TRANSITION CAN OCCUR in the (*,G) state machine as
+ a result of receiving an assert message if that message triggers any
+ change of state in the (S,G) state machine. 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 are in
+ the NoInfo state when an Assert message arrives, and the message
+ causes the (S,G) state machine to transition to either "W" or "L"
+ state, then the assert will not be processed by the (*,G) assert
+ state machine.
+
+ Another example: if the (S,G) assert state machine is in "L" state
+ when an assert message is received, and the assert metric in the
+ message is worse than my_assert_metric(S,G,I), then the (S,G) assert
+ state machine will transition to NoInfo state. In such a case, if
+ the (*,G) assert state machine were in NoInfo state, it might appear
+ that it would transition to "W" state, but this is not the case
+ because this message already triggered a transition in the (S,G)
+ assert state machine.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 86]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Figure 9: Per-Interface (*,G) Assert State Machine
+
++----------------------------------------------------------------------+
+| In NoInfo (NI) State |
++-----------------------+-----------------------+----------------------+
+| Receive Inferior | Data arrives for G | Receive Acceptable |
+| Assert with RPTbit | on I and | Assert with RPTbit |
+| set and | CouldAssert | set and AssTrDes |
+| CouldAssert(*,G,I) | (*,G,I) | (*,G,I) |
++-----------------------+-----------------------+----------------------+
+| -> W state | -> W state | -> L state |
+| [Actions A1] | [Actions A1] | [Actions A2] |
++-----------------------+-----------------------+----------------------+
+
++---------------------------------------------------------------------+
+| In I Am Assert Winner (W) State |
++----------------+-----------------+-----------------+----------------+
+| Assert Timer | Receive | Receive | CouldAssert |
+| Expires | Inferior | Preferred | (*,G,I) -> |
+| | Assert | Assert | FALSE |
++----------------+-----------------+-----------------+----------------+
+| -> W state | -> W state | -> L state | -> NI state |
+| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
++----------------+-----------------+-----------------+----------------+
+
++---------------------------------------------------------------------+
+| In I Am Assert Loser (L) State |
++-------------+-------------+-------------+-------------+-------------+
+|Receive |Receive |Receive |Assert Timer |Current |
+|Preferred |Acceptable |Inferior |Expires |Winner's |
+|Assert with |Assert from |Assert or | |GenID |
+|RPTbit set |Current |Assert | |Changes or |
+| |Winner with |Cancel from | |NLT Expires |
+| |RPTbit set |Current | | |
+| | |Winner | | |
++-------------+-------------+-------------+-------------+-------------+
+|-> L state |-> L state |-> NI state |-> NI state |-> NI state |
+|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
++-------------+-------------+-------------+-------------+-------------+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 87]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
++----------------------------------------------------------------------+
+| In I Am Assert Loser (L) State |
++----------------+----------------+-----------------+------------------+
+| AssTrDes | my_metric -> | RPF_interface | Receive |
+| (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) on |
+| FALSE | Winner's | being I | Interface I |
+| | metric | | |
++----------------+----------------+-----------------+------------------+
+| -> NI state | -> NI state | -> NI state | -> NI State |
+| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
++----------------+----------------+-----------------+------------------+
+
+ The state machine uses the following macros:
+
+ CouldAssert(*,G,I) =
+ ( I in ( joins(*,G) (+) pim_include(*,G)) )
+ AND (RPF_interface(RP(G)) != I)
+
+ CouldAssert(*,G,I) is true on downstream interfaces for which we have
+ (*,G) join state, or local members that requested any traffic
+ destined for G.
+
+ AssertTrackingDesired(*,G,I) =
+ CouldAssert(*,G,I)
+ OR (local_receiver_include(*,G,I)==TRUE
+ AND (I_am_DR(I) OR AssertWinner(*,G,I) == me))
+ OR (RPF_interface(RP(G)) == I AND RPTJoinDesired(G))
+
+ AssertTrackingDesired(*,G,I) is true on any interface on which a
+ (*,G) assert might affect the router's behavior on that interface.
+
+ Note that for reasons of compactness, "AssTrDes(*,G,I)" is used in
+ the state machine table to refer to AssertTrackingDesired(*,G,I).
+
+ Terminology:
+
+ A "preferred assert" is one with a better metric than the current
+ winner.
+
+ An "acceptable assert" is one that has a better metric than
+ my_assert_metric(*,G,I). An assert is never considered acceptable
+ if its metric is infinite.
+
+ An "inferior assert" is one with a worse metric than
+ my_assert_metric(*,G,I). An assert is never considered inferior
+ if my_assert_metric(*,G,I) is infinite.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 88]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from NoInfo State
+
+ When in NoInfo state, the following events trigger transitions, but
+ only if the (S,G) assert state machine is in NoInfo state before and
+ after consideration of the received message:
+
+ Receive Inferior Assert with RPTbit set AND
+ CouldAssert(*,G,I)==TRUE
+ An Inferior (*,G) assert is received for G on Interface I.
+ If CouldAssert(*,G,I) is TRUE, then I is our downstream
+ interface, and we have (*,G) forwarding state on this
+ interface, so we should be the assert winner. We transition
+ to the "I am Assert Winner" state and perform Actions A1
+ (below).
+
+ A data packet destined for G arrives on interface I, AND
+ CouldAssert(*,G,I)==TRUE
+ A data packet destined for G arrived on a downstream
+ interface that is in our (*,G) outgoing interface list. We
+ therefore believe we should be the forwarder for this (*,G),
+ and so we transition to the "I am Assert Winner" state and
+ perform Actions A1 (below).
+
+ Receive Acceptable Assert with RPT bit set AND
+ AssertTrackingDesired(*,G,I)==TRUE
+ We're interested in (*,G) Asserts, either because I is a
+ downstream interface for which we have (*,G) forwarding
+ state, or because I is the upstream interface for RP(G) and
+ we have (*,G) forwarding state. We get a (*,G) Assert that
+ has a better metric than our own, so we do not win the
+ Assert. We transition to "I am Assert Loser" and perform
+ Actions A2 (below).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 89]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from "I am Assert Winner" State
+
+ When in "I am Assert Winner" state, the following events trigger
+ transitions, but only if the (S,G) assert state machine is in NoInfo
+ state before and after consideration of the received message:
+
+ Receive Inferior Assert
+ We receive a (*,G) assert that has a worse metric than our
+ own. Whoever sent the assert has lost, and so we resend a
+ (*,G) Assert and restart the Assert Timer (Actions A3
+ below).
+
+ Receive Preferred Assert
+ We receive a (*,G) assert that has a better metric than our
+ own. We transition to "I am Assert Loser" state and perform
+ Actions A2 (below).
+
+ When in "I am Assert Winner" state, the following events trigger
+ transitions:
+
+ Assert Timer Expires
+ The (*,G) Assert Timer expires. As we're in the Winner
+ state, then we must still have (*,G) forwarding state that
+ is actively being kept alive. To prevent unnecessary
+ thrashing of the forwarder and periodic flooding of
+ duplicate packets, we resend the (*,G) Assert and restart
+ the Assert Timer (Actions A3 below).
+
+ CouldAssert(*,G,I) -> FALSE
+ Our (*,G) forwarding state or RPF interface changed so as to
+ make CouldAssert(*,G,I) become false. We can no longer
+ perform the actions of the assert winner, and so we
+ transition to NoInfo state and perform Actions A4 (below).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 90]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Transitions from "I am Assert Loser" State
+
+ When in "I am Assert Loser" state, the following events trigger
+ transitions, but only if the (S,G) assert state machine is in NoInfo
+ state before and after consideration of the received message:
+
+ Receive Preferred Assert with RPTbit set
+ We receive a (*,G) assert that is better than that of the
+ current assert winner. We stay in Loser state and perform
+ Actions A2 below.
+
+ Receive Acceptable Assert from Current Winner with RPTbit set
+ We receive a (*,G) assert from the current assert winner
+ that is better than our own metric for this group (although
+ the metric may be worse than the winner's previous metric).
+ We stay in Loser state and perform Actions A2 below.
+
+ Receive Inferior Assert or Assert Cancel from Current Winner
+ We receive an assert from the current assert winner that is
+ worse than our own metric for this group (typically because
+ the winner's metric became worse or is now an assert
+ cancel). We transition to NoInfo state, delete this (*,G)
+ assert state (Actions A5), and allow the normal PIM
+ Join/Prune mechanisms to operate. Usually, we will
+ eventually re-assert and win when data packets for G have
+ started flowing again.
+
+ When in "I am Assert Loser" state, the following events trigger
+ transitions:
+
+ Assert Timer Expires
+ The (*,G) Assert Timer expires. We transition to NoInfo
+ state and delete this (*,G) assert information (Actions A5).
+
+ Current Winner's GenID Changes or NLT Expires
+ The Neighbor Liveness Timer associated with the current
+ winner expires or we receive a Hello message from the
+ current winner reporting a different GenID from the one it
+ previously reported. This indicates that the current
+ winner's interface or router has gone down (and may have
+ come back up), and so we must assume that it no longer knows
+ it was the winner. We transition to the NoInfo state,
+ deleting the (*,G) assert information (Actions A5).
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 91]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ AssertTrackingDesired(*,G,I)->FALSE
+ AssertTrackingDesired(*,G,I) becomes FALSE. Our forwarding
+ state has changed so that (*,G) Asserts on interface I are
+ no longer of interest to us. We transition to NoInfo state
+ and delete this (*,G) assert information (Actions A5).
+
+ My metric becomes better than the assert winner's metric
+ My routing metric, rpt_assert_metric(G,I), has changed so
+ that now my assert metric for (*,G) is better than the
+ metric we have stored for the current assert winner. We
+ transition to NoInfo state, delete this (*,G) assert state
+ (Actions A5), and allow the normal PIM Join/Prune mechanisms
+ to operate. Usually, we will eventually re-assert and win
+ when data packets for G have started flowing again.
+
+ RPF_interface(RP(G)) stops being interface I
+ Interface I used to be the RPF interface for RP(G), and now
+ it is not. We transition to NoInfo state and delete this
+ (*,G) assert state (Actions A5).
+
+ Receive Join(*,G) on interface I
+ We receive a Join(*,G) that has the Upstream Neighbor
+ Address field set to my primary IP address on interface I.
+ The action is to transition to NoInfo state, delete this
+ (*,G) assert state (Actions A5), and allow the normal PIM
+ Join/Prune mechanisms to operate. If whoever sent the Join
+ was in error, then the normal assert mechanism will
+ eventually re-apply, and we will lose the assert again.
+ However, whoever sent the assert may know that the previous
+ assert winner has died, so we may end up being the new
+ forwarder.
+
+ (*,G) Assert State Machine Actions
+
+ A1: Send Assert(*,G).
+ Set Assert Timer to (Assert_Time - Assert_Override_Interval).
+ Store self as AssertWinner(*,G,I).
+ Store rpt_assert_metric(G,I) as AssertWinnerMetric(*,G,I).
+
+ A2: Store new assert winner as AssertWinner(*,G,I) and assert
+ winner metric as AssertWinnerMetric(*,G,I).
+ Set Assert Timer to Assert_Time.
+
+ A3: Send Assert(*,G).
+ Set Assert Timer to (Assert_Time - Assert_Override_Interval).
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 92]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ A4: Send AssertCancel(*,G).
+ Delete assert information (AssertWinner(*,G,I) and
+ AssertWinnerMetric(*,G,I) will then return to their default
+ values).
+
+ A5: Delete assert information (AssertWinner(*,G,I) and
+ AssertWinnerMetric(*,G,I) will then return to their default
+ values).
+
+ Note that some of these actions may cause the value of
+ JoinDesired(*,G) or RPF'(*,G) to change, which could cause further
+ transitions in other state machines.
+
+4.6.3. Assert Metrics
+
+ Assert metrics are defined as:
+
+ struct assert_metric {
+ rpt_bit_flag;
+ metric_preference;
+ route_metric;
+ ip_address;
+ };
+
+ When comparing assert_metrics, the rpt_bit_flag, metric_preference,
+ and route_metric fields are compared in order, where the first lower
+ value wins. If all fields are equal, the primary IP address of the
+ router that sourced the Assert message is used as a tie-breaker, with
+ the highest IP address winning.
+
+ An assert metric for (S,G) to include in (or compare against) an
+ Assert message sent on interface I should be computed using the
+ following pseudocode:
+
+ assert_metric
+ my_assert_metric(S,G,I) {
+ if( CouldAssert(S,G,I) == TRUE ) {
+ return spt_assert_metric(S,I)
+ } else if( CouldAssert(*,G,I) == TRUE ) {
+ return rpt_assert_metric(G,I)
+ } else {
+ return infinite_assert_metric()
+ }
+ }
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 93]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ spt_assert_metric(S,I) gives the assert metric we use if we're
+ sending an assert based on active (S,G) forwarding state:
+
+ assert_metric
+ spt_assert_metric(S,I) {
+ return {0,MRIB.pref(S),MRIB.metric(S),my_ip_address(I)}
+ }
+
+ rpt_assert_metric(G,I) gives the assert metric we use if we're
+ sending an assert based only on (*,G) forwarding state:
+
+ assert_metric
+ rpt_assert_metric(G,I) {
+ return {1,MRIB.pref(RP(G)),MRIB.metric(RP(G)),my_ip_address(I)}
+ }
+
+ MRIB.pref(X) and MRIB.metric(X) are the routing preference and
+ routing metrics associated with the route to a particular (unicast)
+ destination X, as determined by the MRIB. my_ip_address(I) is simply
+ the router's primary IP address that is associated with the local
+ interface I.
+
+ infinite_assert_metric() is an assert metric that the router uses for
+ an Assert that does not match either (S,G) or (*,G) forwarding state:
+
+ assert_metric
+ infinite_assert_metric() {
+ return {1,infinity,infinity,0}
+ }
+
+4.6.4. AssertCancel Messages
+
+ An AssertCancel message is simply an RPT Assert message but with an
+ infinite metric. It is sent by the assert winner when it deletes the
+ forwarding state that had caused the assert to occur. Other routers
+ 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.
+
+ An AssertCancel(S,G) is an infinite metric assert with the RPT bit
+ set that names S as the source.
+
+ An AssertCancel(*,G) is an infinite metric assert with the RPT bit
+ set and the source set to zero.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 94]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ AssertCancel messages are simply an optimization. The original
+ Assert timeout mechanism will allow a subnet to eventually become
+ consistent; the AssertCancel mechanism simply causes faster
+ convergence. No special processing is required for an AssertCancel
+ message, since it is simply an Assert message from the current
+ winner.
+
+4.6.5. Assert State Macros
+
+ The macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and
+ lost_assert(*,G,I) are used in the olist computations of Section 4.1
+ and are defined as:
+
+ bool lost_assert(S,G,rpt,I) {
+ if ( RPF_interface(RP(G)) == I OR
+ ( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) {
+ return FALSE
+ } else {
+ return ( AssertWinner(S,G,I) != NULL AND
+ AssertWinner(S,G,I) != me )
+ }
+ }
+
+ bool lost_assert(S,G,I) {
+ if ( RPF_interface(S) == I ) {
+ return FALSE
+ } else {
+ return ( AssertWinner(S,G,I) != NULL AND
+ AssertWinner(S,G,I) != me AND
+ (AssertWinnerMetric(S,G,I) is better
+ than spt_assert_metric(S,I) )
+ }
+ }
+
+ Note: The term "AssertWinnerMetric(S,G,I) is better than
+ 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 SPTbit. In this case, it needs to ignore the assert state if
+ it will win the assert once the SPTbit is set.
+
+ bool lost_assert(*,G,I) {
+ if ( RPF_interface(RP(G)) == I ) {
+ return FALSE
+ } else {
+ return ( AssertWinner(*,G,I) != NULL AND
+ AssertWinner(*,G,I) != me )
+ }
+ }
+
+
+
+Fenner, et al. Standards Track [Page 95]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ AssertWinner(S,G,I) is the IP source address of the Assert(S,G)
+ packet that won an Assert.
+
+ AssertWinner(*,G,I) is the IP source address of the Assert(*,G)
+ packet that won an Assert.
+
+ AssertWinnerMetric(S,G,I) is the Assert metric of the Assert(S,G)
+ packet that won an Assert.
+
+ AssertWinnerMetric(*,G,I) is the Assert metric of the Assert(*,G)
+ packet that won an Assert.
+
+ AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I)
+ defaults to Infinity when in the NoInfo state.
+
+ Summary of Assert Rules and Rationale
+
+ This section summarizes the key rules for sending and reacting to
+ asserts and the rationale for these rules. This section is not
+ intended to be and should not be treated as a definitive
+ specification of protocol behavior. The state machines and
+ pseudocode should be consulted for that purpose. Rather, this
+ section is intended to document important aspects of the Assert
+ protocol behavior and to provide information that may prove helpful
+ to the reader in understanding and implementing this part of the
+ protocol.
+
+ 1. Behavior: Downstream neighbors send Join(*,G) and Join(S,G)
+ periodic messages to the appropriate RPF' neighbor, i.e., the RPF
+ neighbor as modified by the assert process. They are not always
+ sent to the RPF neighbor as indicated by the MRIB. Normal
+ suppression and override rules apply.
+
+ Rationale: By sending the periodic and triggered Join messages to
+ the RPF' neighbor instead of the RPF neighbor, the downstream
+ router avoids re-triggering the Assert process with every Join.
+ A side effect of sending Joins to the Assert winner is that
+ traffic will not switch back to the "normal" RPF neighbor until
+ the Assert times out. This will not happen until data stops
+ flowing, if item 8, below, is implemented.
+
+ 2. Behavior: The assert winner for (*,G) acts as the local DR for
+ (*,G) on behalf of IGMP/MLD members.
+
+ Rationale: This is required to allow a single router to merge
+ PIM and IGMP/MLD joins and leaves. Without this, overrides
+ don't work.
+
+
+
+
+Fenner, et al. Standards Track [Page 96]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ 3. Behavior: The assert winner for (S,G) acts as the local DR for
+ (S,G) on behalf of IGMPv3 members.
+
+ Rationale: Same rationale as for item 2.
+
+ 4. Behavior: (S,G) and (*,G) prune overrides are sent to the RPF'
+ neighbor and not to the regular RPF neighbor.
+
+ Rationale: Same rationale as for item 1.
+
+ 5. Behavior: An (S,G,rpt) prune override is not sent (at all) if
+ RPF'(S,G,rpt) != RPF'(*,G).
+
+ Rationale: This avoids keeping state alive on the (S,G) tree when
+ only (*,G) downstream members are left. Also, it avoids sending
+ (S,G,rpt) joins to a router that is not on the (*,G) tree. This
+ behavior might be confusing, although this specification does
+ indicate that such a join SHOULD be dropped.
+
+ 6. Behavior: An assert loser that receives a Join(S,G) with an
+ Upstream Neighbor Address that is its primary IP address on that
+ interface expires the (S,G) Assert Timer.
+
+ Rationale: This is necessary in order to have rapid convergence
+ in the event that the downstream router that initially sent a
+ join to the prior Assert winner has undergone a topology change.
+
+ 7. Behavior: An assert loser that receives a Join(*,G) with an
+ Upstream Neighbor Address that is its primary IP address on that
+ interface expires the (*,G) Assert Timer and all (S,G) assert
+ timers that do not have corresponding Prune(S,G,rpt) messages in
+ the compound Join/Prune message.
+
+ Rationale: Same rationale as for item 6.
+
+ 8. Behavior: An assert winner for (*,G) or (S,G) sends a canceling
+ assert when it is about to stop forwarding on a (*,G) or an (S,G)
+ entry. This behavior does not apply to (S,G,rpt).
+
+ Rationale: This allows switching back to the shared tree after
+ the last SPT router on the LAN leaves. Doing this prevents
+ downstream routers on the shared tree from keeping SPT state
+ alive.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 97]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ 9. Behavior: Resend the assert messages before timing out an assert.
+ (This behavior is optional.)
+
+ Rationale: This prevents the periodic duplicates that would
+ otherwise occur each time that an assert times out and is then
+ re-established.
+
+ 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).
+
+ Rationale: This allows switching back to the RPT after the last
+ SPT member leaves.
+
+4.7. PIM Bootstrap and RP Discovery
+
+ 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 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 contiguous set of routers that all implement PIM and are
+ configured to operate within a common boundary.
+
+ A notable exception to this is where a PIM domain is broken up into
+ multiple administrative scope regions; these are regions where a
+ border has been configured so that a range of multicast groups will
+ not be forwarded across that border. For more information on
+ Administratively Scoped IP Multicast, see RFC 2365. The modified
+ criteria for admin-scoped regions are that the region is convex with
+ respect to forwarding based on the MRIB, and that all PIM routers
+ within the scope region map scoped groups to the same RP within that
+ region.
+
+ This specification does not mandate the use of a single mechanism to
+ provide routers with the information to perform the group-to-RP
+ mapping. Currently, four mechanisms are possible, and all four have
+ associated problems:
+
+ Static Configuration
+ A PIM router MUST support the static configuration of group-to-
+ RP mappings. Such a mechanism is not robust to failures but
+ does at least provide a basic interoperability mechanism.
+
+ Embedded-RP
+ Embedded-RP defines an address allocation policy in which the
+ address of the Rendezvous Point (RP) is encoded in an IPv6
+ multicast group address [16].
+
+
+
+
+
+Fenner, et al. Standards Track [Page 98]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Cisco's Auto-RP
+ Auto-RP uses a PIM Dense-Mode (PIM-DM) multicast group to
+ announce group-to-RP mappings from a central location. This
+ mechanism is not useful if PIM Dense Mode is not being run in
+ parallel with PIM Sparse Mode; it was only intended for use
+ with PIM Sparse Mode Version 1. No standard specification
+ currently exists.
+
+ Bootstrap Router (BSR)
+ RFC 2362 specifies a bootstrap mechanism based on the automatic
+ election of a BSR. Any router in the domain that is configured
+ to be a possible RP reports its candidacy to the BSR, and then
+ a domain-wide flooding mechanism distributes the BSR's chosen
+ set of RPs throughout the domain. As specified in RFC 2362,
+ the BSR mechanism is flawed in its handling of admin-scoped
+ regions that are smaller than a PIM domain, but the mechanism
+ does work for global-scoped groups.
+
+ As far as PIM-SM is concerned, the only important requirement is that
+ all routers in the domain (or admin scope zone for scoped regions)
+ receive the same set of group-range-to-RP mappings. This may be
+ achieved through the use of any of these mechanisms, or through
+ alternative mechanisms not currently specified.
+
+ It must be operationally ensured that any RP address configured,
+ learned, or advertised is reachable from all routers in the PIM
+ domain.
+
+4.7.1. Group-to-RP Mapping
+
+ Using one of the mechanisms described above, a PIM router receives
+ one 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 which such groups should be mapped. Each mapping may
+ also have an associated priority. It is possible to receive multiple
+ mappings, all of which might match the same multicast group; this is
+ the common case with the BSR mechanism. The algorithm for performing
+ the group-to-RP mapping is as follows:
+
+ 1. Perform longest match on group range to obtain a list of RPs.
+
+ 2. From this list of matching RPs, find the ones with highest
+ priority.
+
+ Eliminate any RPs from the list that have lower priorities.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 99]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ 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
+ choose one.
+
+ 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 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 mask and the priorities are identical, then a hash
+ function (see Section 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 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.
+
+ Furthermore, the mapping function is invoked by all routers upon
+ receiving a (*,G) Join/Prune message.
+
+ 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. This may, for example, cause a DR or acting DR to re-join
+ a group, or cause it to restart register encapsulation to the new RP.
+
+ Implementation note: The bootstrap mechanism described in RFC 2362
+ omitted step 1 above. However, of the implementations we are
+ aware of, approximately half performed step 1 anyway. Note that
+ implementations of BSR that omit step 1 will not correctly
+ interoperate with implementations of this specification when used
+ with the BSR mechanism described in [11].
+
+4.7.2. Hash Function
+
+ 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 (this set of mappings all have the same longest mask length
+ and same highest priority). The algorithm takes as input the group
+ address, and the addresses of the candidate RPs from the mappings,
+ and gives as output one RP address to be used.
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 100]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ The protocol requires that all routers hash to the same RP within a
+ domain (except for transients). The following hash function must be
+ used in each router:
+
+ 1. For RP addresses in the matching group-range-to-RP mappings,
+ compute a value:
+
+ Value(G,M,C(i))=
+ (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31
+
+ where C(i) is the RP address and M is a hash-mask. If BSR is
+ being used, the hash-mask is given in the Bootstrap messages. If
+ BSR is not being used, the alternative mechanism that supplies
+ the group-range-to-RP mappings may supply the value, or else it
+ defaults to a mask with the most significant 30 bits being one
+ for IPv4 and the most significant 126 bits being one for IPv6.
+ The hash-mask allows a small number of consecutive groups
+ (e.g., 4) to always hash to the same RP. For instance,
+ hierarchically encoded data can be sent on consecutive group
+ addresses to get the same delay and fate-sharing characteristics.
+
+ For address families other than IPv4, a 32-bit digest to be used
+ as C(i) and G must first be derived from the actual RP or group
+ address. Such a digest method must be used consistently
+ throughout the PIM domain. For IPv6 addresses, it is RECOMMENDED
+ to use the equivalent IPv4 address for an IPv4-compatible
+ address, and the exclusive-or of each 32-bit segment of the
+ address for all other IPv6 addresses. For example, the digest of
+ the IPv6 address 3ffe:b00:c18:1::10 would be computed as
+ 0x3ffe0b00 ^ 0x0c180001 ^ 0x00000000 ^ 0x00000010,
+ where the '^' symbol represents the exclusive-or operation.
+
+ 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 highest hash value, the RP with the highest IP address is
+ chosen.
+
+4.8. Source-Specific Multicast
+
+ The Source-Specific Multicast (SSM) service model [6] can be
+ implemented 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 be implemented using the PIM-SM protocol. A
+ range of multicast addresses, currently 232.0.0.0/8 in IPv4 and
+ ff3x::/32 for IPv6, is reserved for SSM, and the choice of semantics
+ is determined by the multicast group address in both data packets and
+ PIM messages.
+
+
+
+
+Fenner, et al. Standards Track [Page 101]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.8.1. Protocol Modifications for SSM Destination Addresses
+
+ The following rules override the normal PIM-SM behavior for a
+ multicast 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 an (S,G,rpt) Join/Prune message for any
+ reason.
+
+ o A router MUST NOT send a Register message for any packet that is
+ destined to an SSM address.
+
+ 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 for any SSM address, for the purposes of packet
+ forwarding.
+
+ o A router acting as an RP MUST NOT forward any Register-
+ encapsulated packet that has an SSM destination address and SHOULD
+ respond with a Register-Stop message to such a Register message.
+
+ 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 needed for SSM packets.
+
+ The last three rules are present to deal with SSM-unaware "legacy"
+ routers that may be sending (*,G) and (S,G,rpt) Join/Prunes, or
+ Register messages for SSM destination addresses. Note that this
+ specification does not attempt to aid an SSM-unaware "legacy" router
+ with SSM operations.
+
+4.8.2. PIM-SSM-Only Routers
+
+ An implementer may choose to implement only the subset of PIM
+ Sparse Mode that provides SSM forwarding semantics.
+
+ A PIM-SSM-only router MUST implement the following portions of this
+ specification:
+
+ o Upstream (S,G) state machine (Section 4.5.5)
+
+ o Downstream (S,G) state machine (Section 4.5.2)
+
+ o (S,G) Assert state machine (Section 4.6.1)
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 102]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ o Hello messages, neighbor discovery, and DR election (Section 4.3)
+
+ o Packet forwarding rules (Section 4.2)
+
+ A PIM-SSM-only router does not need to implement the following
+ protocol elements:
+
+ o Register state machine (Section 4.4)
+
+ o (*,G) and (S,G,rpt) downstream state machines (Sections 4.5.1 and
+ 4.5.3)
+
+ o (*,G) and (S,G,rpt) upstream state machines (Sections 4.5.4,
+ 4.5.6, and 4.5.7)
+
+ o (*,G) Assert state machine (Section 4.6.2)
+
+ o Bootstrap RP election (Section 4.7)
+
+ o Keepalive Timer
+
+ o SPTbit (Section 4.2.2)
+
+ The Keepalive Timer should be treated as always running, and the
+ SPTbit should be treated as always being set for an SSM address.
+ Additionally, the packet forwarding rules of Section 4.2 can be
+ simplified in a PIM-SSM-only router:
+
+ oiflist = NULL
+
+ if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
+ oiflist = inherited_olist(S,G)
+ } else if( iif is in inherited_olist(S,G) ) {
+ send Assert(S,G) on iif
+ }
+
+ oiflist = oiflist (-) iif
+ forward packet on all interfaces in oiflist
+
+ 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.
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 103]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.9. PIM Packet Formats
+
+ This section describes the details of the packet formats for PIM
+ control messages.
+
+ All PIM control messages have IP protocol number 103.
+
+ 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, Asserts). The source address used for unicast messages
+ is a domain-wide reachable address; the source address used for
+ multicast messages is the link-local address of the interface on
+ which the message is being sent.
+
+ The IPv4 'ALL-PIM-ROUTERS' group is '224.0.0.13'. The IPv6
+ 'ALL-PIM-ROUTERS' group is 'ff02::d'.
+
+ The PIM header common to all PIM messages is:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |PIM Ver| Type | Reserved | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ PIM Ver
+ PIM Version number is 2.
+
+ Type
+ Types for specific PIM messages. PIM Types are:
+
+ Message Type Destination
+ ---------------------------------------------------------------------
+ 0 = Hello Multicast to ALL-PIM-ROUTERS
+ 1 = Register Unicast to RP
+ 2 = Register-Stop Unicast to source of Register
+ packet
+ 3 = Join/Prune Multicast to ALL-PIM-ROUTERS
+ 4 = Bootstrap Multicast to ALL-PIM-ROUTERS
+ 5 = Assert Multicast to ALL-PIM-ROUTERS
+ 6 = Graft (used in PIM-DM only) Unicast to RPF'(S)
+ 7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft
+ packet
+ 8 = Candidate-RP-Advertisement Unicast to Domain's BSR
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 104]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Reserved
+ Set to zero on transmission. Ignored upon receipt.
+
+ Checksum
+ 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, excluding the "Multicast data packet" section of the
+ Register 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 specified in RFC 2460, Section 8.1 [5]. This
+ "pseudo-header" is prepended to the PIM header for the purposes
+ of calculating the checksum. The "Upper-Layer Packet Length"
+ in the pseudo-header is set to the length of the PIM message,
+ except in Register messages where it is set to the length of
+ the PIM register header (8). The Next Header value used in the
+ pseudo-header is 103.
+
+ If a message is received with an unrecognized PIM Ver or Type field,
+ or if a message's destination does not correspond to the table above,
+ the message MUST be discarded, and an error message SHOULD be logged
+ to the administrator in a rate-limited manner.
+
+4.9.1. Encoded Source and Group Address Formats
+
+ Encoded Unicast Address
+
+ An encoded unicast address takes the following format:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Addr Family | Encoding Type | Unicast Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
+
+ Addr Family
+ The PIM address family of the 'Unicast Address' field of this
+ address.
+
+ Values 0-127 are as assigned by the IANA for Internet Address
+ Families in [7]. Values 128-250 are reserved to be assigned by
+ the IANA for PIM-specific Address Families. Values 251 through
+ 255 are designated for Private Use. As there is no assignment
+ authority for this space, collisions should be expected.
+
+
+
+
+Fenner, et al. Standards Track [Page 105]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Encoding Type
+ The type of encoding used within a specific Address Family.
+ The value '0' is reserved for this field and represents the
+ native encoding of the Address Family.
+
+ Unicast Address
+ The unicast address as represented by the given Address Family
+ and Encoding Type.
+
+ Encoded Group Address
+
+ Encoded group addresses take the following format:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Addr Family | Encoding Type |B| Reserved |Z| Mask Len |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Group multicast Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
+
+ Addr Family
+ Described above.
+
+ Encoding Type
+ Described above.
+
+ [B]idirectional PIM
+ Indicates that the group range uses Bidirectional PIM [13].
+ For PIM-SM as defined in this specification, this bit MUST be
+ zero.
+
+ Reserved
+ Transmitted as zero. Ignored upon receipt.
+
+ Admin Scope [Z]one
+ Indicates that the group range is an admin scope zone. This is
+ used in the Bootstrap Router mechanism [11] only. For all
+ other purposes, this bit is set to zero and ignored on receipt.
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 106]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Mask Len
+ The Mask length field is 8 bits. The value is the number of
+ contiguous one bits that are left-justified and used as a mask;
+ when combined with the group address, it describes a range of
+ groups. It is less 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, 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 encoding, 128 for IPv6
+ native encoding).
+
+ Group multicast Address
+ Contains the group address.
+
+ Encoded Source Address
+
+ An encoded source address takes the following format:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
+
+ Addr Family
+ Described above.
+
+ Encoding Type
+ Described above.
+
+ Reserved
+ Transmitted as zero, ignored on receipt.
+
+ S The Sparse bit is a 1-bit value, set to 1 for PIM-SM. It is
+ used for PIM Version 1 compatibility.
+
+ W The WC (or WildCard) bit is a 1-bit value for use with PIM
+ Join/Prune messages (see Section 4.9.5.1).
+
+ R The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use
+ with PIM Join/Prune messages (see Section 4.9.5.1). If the
+ WC bit is 1, the RPT bit MUST be 1.
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 107]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Mask Len
+ The mask length field is 8 bits. The value is the number of
+ contiguous one bits that are left-justified and used as a mask;
+ when combined with the source address, it describes a source
+ subnet. The mask length 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 native). A router SHOULD ignore
+ any messages received with any other mask length.
+
+ Source Address
+ The source address.
+
+4.9.2. Hello Message Format
+
+ A Hello message is sent periodically by routers on all interfaces.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |PIM Ver| Type | Reserved | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OptionType | OptionLength |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OptionValue |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | . |
+ | . |
+ | . |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OptionType | OptionLength |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OptionValue |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ PIM Version, Type, Reserved, Checksum
+ Described in Section 4.9.
+
+ OptionType
+ The type of the option given in the following OptionValue
+ field.
+
+ OptionLength
+ The length of the OptionValue field in bytes.
+
+ OptionValue
+ A variable-length field, carrying the value of the option.
+
+
+
+Fenner, et al. Standards Track [Page 108]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ The Option fields may contain the following values:
+
+ o OptionType 1: Holdtime
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 1 | Length = 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Holdtime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Holdtime is the amount of time a receiver must keep the neighbor
+ reachable, in seconds. If the Holdtime is set to '0xffff', the
+ receiver of this message never times out the neighbor. This may
+ be used with dial-on-demand links, to avoid keeping the link up
+ with periodic Hello messages.
+
+ An implementation MAY provide a configuration mechanism to reject
+ a Hello message with holdtime 0xffff, and/or provide a mechanism
+ to remove a neighbor.
+
+ Hello messages with a Holdtime value set to '0' are also sent by a
+ router on an interface about to go down or changing IP address
+ (see Section 4.3.1). These are effectively goodbye messages, and
+ the receiving routers SHOULD immediately time out the neighbor
+ information for the sender.
+
+ o OptionType 2: LAN Prune Delay
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 2 | Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |T| Propagation_Delay | Override_Interval |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The LAN Prune Delay option is used to tune the prune propagation
+ delay on multi-access LANs. The T bit specifies the ability of
+ the sending router to disable Join suppression. Propagation_Delay
+ and Override_Interval are time intervals in units of milliseconds.
+ A router originating a LAN Prune Delay option on interface I sets
+ the Propagation_Delay field to the configured value of
+ Propagation_Delay(I) and the value of the Override_Interval field
+ to the value of Override_Interval(I). On a receiving router, the
+ values of the fields are used to tune the value of the
+ Effective_Override_Interval(I) and its derived timer values.
+
+
+
+Fenner, et al. Standards Track [Page 109]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Section 4.3.3 describes how these values affect the behavior of a
+ router.
+
+ o OptionTypes 3 through 16: Reserved; to be defined in future
+ versions of this document.
+
+ o OptionType 18: Deprecated and should not be used.
+
+ o OptionType 19: DR Priority
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 19 | Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DR Priority |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ DR Priority is a 32-bit unsigned number and should be considered
+ in the DR election as described in Section 4.3.2.
+
+ o OptionType 20: Generation ID
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 20 | Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Generation ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Generation ID is a random 32-bit value for the interface on which
+ the Hello message is sent. The Generation ID is regenerated
+ whenever PIM forwarding is started or restarted on the interface.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 110]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ o OptionType 24: Address List
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 24 | Length = <Variable> |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Secondary Address 1 (Encoded-Unicast format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Secondary Address N (Encoded-Unicast format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The contents of the Address List Hello option are described in
+ Section 4.3.4. All addresses within a single Address List must
+ belong to the same address family.
+
+ OptionTypes 17 through 65000 are assigned by the IANA.
+ OptionTypes 65001 through 65535 are reserved for Private Use,
+ as defined in [9].
+
+ Unknown options MUST be ignored and MUST NOT prevent a neighbor
+ relationship from being formed. The Holdtime option MUST be
+ implemented; the DR Priority and Generation ID options SHOULD be
+ implemented. The Address List option MUST be implemented for IPv6.
+
+4.9.3. Register Message Format
+
+ A Register message is sent by the DR to the RP when a 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 RP's
+ address. The IP TTL of the PIM packet is the system's normal
+ unicast TTL.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |PIM Ver| Type | Reserved | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |B|N| Reserved2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . Multicast data packet .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 111]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ PIM Version, Type, Reserved, Checksum
+ Described in Section 4.9. Note that in order to reduce
+ encapsulation overhead, the checksum for Registers is done only
+ on the first 8 bytes of the packet, including the PIM header
+ and the next 4 bytes, excluding the data packet portion. For
+ interoperability reasons, a message carrying a checksum
+ calculated over the entire PIM Register message should also be
+ accepted. When calculating the checksum, the IPv6
+ pseudo-header "Upper-Layer Packet Length" is set to 8.
+
+ B The Border bit. This specification deprecates the Border bit.
+ A router MUST set the B bit to 0 on transmission and MUST
+ ignore this bit on reception.
+
+ 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
+ otherwise.
+
+ Reserved2
+ Transmitted as zero, ignored on receipt.
+
+ Multicast data packet
+ The original packet sent by the source. This packet must be of
+ the same address family as the encapsulating PIM packet, e.g.,
+ an IPv6 data packet must be encapsulated in an IPv6 PIM packet.
+ Note that the TTL of the original packet is decremented before
+ encapsulation, just like any other packet that is forwarded.
+ In addition, the RP decrements the TTL after decapsulating,
+ before forwarding the packet down the shared tree.
+
+ For (S,G) Null-Registers, the Multicast data packet portion
+ contains a dummy IP header with S as the source address
+ and G as the destination address. When generating an IPv4
+ Null-Register message, the fields in the dummy IPv4 header
+ SHOULD be filled in according to the following table. Other
+ IPv4 header fields may contain any value that is valid for
+ that field.
+
+ Field Value
+ ---------------------------------------
+ IP Version 4
+ Header Length 5
+ Checksum Header checksum
+ Fragmentation offset 0
+ More Fragments 0
+ Total Length 20
+ IP Protocol 103 (PIM)
+
+
+
+
+Fenner, et al. Standards Track [Page 112]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ On receipt of an (S,G) Null-Register, if the Header Checksum
+ field is non-zero, the recipient SHOULD check the checksum and
+ discard Null-Registers that have a bad checksum. The recipient
+ SHOULD NOT check the value of any individual fields; a correct
+ IP header checksum is sufficient. If the Header Checksum field
+ is zero, the recipient MUST NOT check the checksum.
+
+ With IPv6, an implementation generates a dummy IP header
+ followed by a dummy PIM header with values according to the
+ following table in addition to the source and group. Other
+ IPv6 header fields may contain any value that is valid for that
+ field.
+
+ Header Field Value
+ --------------------------------------
+ IP Version 6
+ Next Header 103 (PIM)
+ Length 4
+ PIM Version 0
+ PIM Type 0
+ PIM Reserved 0
+ PIM Checksum PIM checksum, including
+ IPv6 "pseudo-header";
+ see Section 4.9
+
+ On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM
+ header is present, the recipient SHOULD check the checksum and
+ discard Null-Registers that have a bad checksum.
+
+4.9.4. Register-Stop Message Format
+
+ 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 addressed. The IP destination address is the source address of
+ the register message.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |PIM Ver| Type | Reserved | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Group Address (Encoded-Group format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Address (Encoded-Unicast format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 113]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ PIM Version, Type, Reserved, Checksum
+ Described in Section 4.9.
+
+ Group Address
+ The group address from the multicast data packet in the
+ Register. The format for this address is described in
+ Section 4.9.1. Note that for Register-Stops the Mask Len field
+ contains the full address length * 8 (e.g., 32 for IPv4 native
+ encoding), if the message is sent for a single group.
+
+ Source Address
+ The host address of the source from the multicast data packet
+ in the register. The format for this address is given in the
+ encoded unicast address in Section 4.9.1. A special wildcard
+ value consisting of an address field of all zeros can be used
+ to indicate any source.
+
+4.9.5. Join/Prune Message Format
+
+ 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
+ (SPT). Prunes are sent to prune source trees when members leave
+ groups as well as sources that do not use the shared tree.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 114]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |PIM Ver| Type | Reserved | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Upstream Neighbor Address (Encoded-Unicast format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | Num groups | Holdtime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Multicast Group Address 1 (Encoded-Group format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of Joined Sources | Number of Pruned Sources |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Joined Source Address 1 (Encoded-Source format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | . |
+ | . |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Joined Source Address n (Encoded-Source format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pruned Source Address 1 (Encoded-Source format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | . |
+ | . |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pruned Source Address n (Encoded-Source format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | . |
+ | . |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Multicast Group Address m (Encoded-Group format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of Joined Sources | Number of Pruned Sources |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Joined Source Address 1 (Encoded-Source format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | . |
+ | . |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Joined Source Address n (Encoded-Source format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pruned Source Address 1 (Encoded-Source format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | . |
+ | . |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pruned Source Address n (Encoded-Source format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Fenner, et al. Standards Track [Page 115]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ PIM Version, Type, Reserved, Checksum
+ Described in Section 4.9.
+
+ Unicast Upstream Neighbor Address
+ The primary address of the upstream neighbor that is the target
+ of the message. The format for this address is given in the
+ encoded unicast address in Section 4.9.1.
+
+ Reserved
+ Transmitted as zero, ignored on receipt.
+
+ Holdtime
+ 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 this message SHOULD hold the state until canceled
+ by the appropriate canceling Join/Prune message, or timed out
+ according to local policy. This may be used with dial-on-
+ demand links, to avoid keeping the link up with periodic
+ Join/Prune messages.
+
+ Note that the HoldTime MUST be larger than the
+ J/P_Override_Interval(I).
+
+ Number of Groups
+ The number of multicast group sets contained in the message.
+
+ Multicast group address
+ For format description, see Section 4.9.1.
+
+ Number of Joined Sources
+ Number of joined source addresses listed for a given group.
+
+ Joined Source Address 1 .. n
+ This list contains the sources for a given group that the
+ sending router will forward multicast datagrams from if
+ received on the interface on which the Join/Prune message
+ is sent.
+
+ See Section 4.9.1 for the format description for the
+ encoded source address.
+
+ Number of Pruned Sources
+ Number of pruned source addresses listed for a group.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 116]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Pruned Source Address 1 .. n
+ This list contains the sources for a given group that the
+ sending router does not want to forward multicast datagrams
+ from when received on the interface on which the Join/Prune
+ message is sent.
+
+ Within one PIM Join/Prune message, all the Multicast Group addresses,
+ Joined Source addresses, and Pruned Source addresses MUST be of the
+ same address family. It is NOT PERMITTED to mix IPv4 and IPv6
+ addresses within the same message. In addition, the address family
+ of the fields in the message SHOULD be the same as the IP source and
+ destination addresses of the packet. This permits maximum
+ implementation flexibility for dual-stack IPv4/IPv6 routers. If a
+ router receives a message with mixed family addresses, it SHOULD only
+ process the addresses that are of the same family as the unicast
+ upstream neighbor address.
+
+4.9.5.1. Group Set Source List Rules
+
+ As described above, Join/Prune messages are composed of one or more
+ group sets. Each set contains two source lists: the Joined Sources
+ and the Pruned Sources. This section describes the different types
+ of group sets and source list entries that can exist in a Join/Prune
+ message.
+
+ There is one valid group set type:
+
+ Group-Specific Set
+ A Group-Specific Set is represented by a valid IP multicast
+ address in the group address field and the full length of the
+ IP address in the mask length field of the Multicast Group
+ Address. Each Join/Prune message SHOULD NOT contain more than
+ one group-specific set for the same IP multicast address. Each
+ group-specific set may contain (*,G), (S,G,rpt), and (S,G)
+ source list entries in the Joined or Pruned lists.
+
+ (*,G)
+ The (*,G) source list entry is used in Join/Prune messages
+ sent towards the RP for the specified group. It expresses
+ interest (or lack thereof) in receiving traffic sent to the
+ group through the RP shared tree. There MUST only be one
+ such entry in both the Joined and Pruned lists of a group-
+ specific set.
+
+ (*,G) source list entries have the Source-Address set to the
+ address of the RP for group G, the Source-Address Mask-Len
+ set to the full length of the IP address, and both the WC
+ and RPT bits of the encoded-source-address set.
+
+
+
+Fenner, et al. Standards Track [Page 117]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ (S,G,rpt)
+ The (S,G,rpt) source list entry is used in Join/Prune
+ messages sent towards the RP for the specified group. It
+ expresses interest (or lack thereof) in receiving traffic
+ through the shared tree sent by the specified source to this
+ group. For each source address, the entry MUST exist in
+ only one of the Joined and Pruned source lists of a group-
+ specific set, but not both.
+
+ (S,G,rpt) source list entries have the Source-Address set to
+ the address of the source S, the Source-Address Mask-Len set
+ to the full length of the IP address, and the WC bit cleared
+ and the RPT bit set in the encoded source address.
+
+ (S,G)
+ The (S,G) source list entry is used in Join/Prune messages
+ sent towards the specified source. It expresses interest
+ (or lack thereof) in receiving traffic through the shortest
+ path tree sent by the source to the specified group. For
+ each source address, the entry MUST exist in only one of the
+ Joined and Pruned source lists of a group-specific set, but
+ not both.
+
+ (S,G) source list entries have the Source-Address set to the
+ address of the source S, the Source-Address Mask-Len set to
+ the full length of the IP address, and both the WC and RPT
+ bits of the encoded source address cleared.
+
+ The rules described above are sufficient to prevent invalid
+ combinations of source list entries in group-specific sets. There
+ are, however, a number of combinations that have a valid
+ interpretation but that are not generated by the protocol as
+ described in this specification:
+
+ o Combining a (*,G) Join and an (S,G,rpt) Join entry in the same
+ message is redundant, as the (*,G) entry covers the information
+ provided by the (S,G,rpt) entry.
+
+ o The same applies for a (*,G) Prune and an (S,G,rpt) Prune.
+
+ o The combination of a (*,G) Prune and an (S,G,rpt) Join is also not
+ 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 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) Join would be meaningless.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 118]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ o As Join/Prune messages are targeted to a single PIM neighbor,
+ including both an (S,G) Join and an (S,G,rpt) Prune in the same
+ message is usually redundant. The (S,G) Join informs the neighbor
+ that the sender wishes to receive the particular source on the
+ shortest path tree. It is therefore unnecessary for the router to
+ say that it no longer wishes to receive it on the shared tree.
+ However, there is a valid interpretation for this combination of
+ entries. A downstream router may have to instruct its upstream
+ only to start forwarding a specific source once it has started
+ receiving the source on the shortest-path tree.
+
+ o The combination of an (S,G) Prune and an (S,G,rpt) Join could
+ possibly 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 (provided that the RPF neighbor for the shortest-path
+ and shared trees is common). However, Sparse-Mode PIM does not
+ provide a mechanism for explicitly switching back to the shared
+ tree.
+
+ The rules are summarized in the table below.
+
+ +----------++------+-------+-----------+-----------+-------+-------+
+ | ||Join | Prune | Join | Prune | Join | Prune |
+ | ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
+ +----------++------+-------+-----------+-----------+-------+-------+
+ |Join ||- | no | ? | yes | yes | yes |
+ |(*,G) || | | | | | |
+ +----------++------+-------+-----------+-----------+-------+-------+
+ |Prune ||no | - | ? | ? | yes | yes |
+ |(*,G) || | | | | | |
+ +----------++------+-------+-----------+-----------+-------+-------+
+ |Join ||? | ? | - | no | yes | ? |
+ |(S,G,rpt) || | | | | | |
+ +----------++------+-------+-----------+-----------+-------+-------+
+ |Prune ||yes | ? | no | - | yes | ? |
+ |(S,G,rpt) || | | | | | |
+ +----------++------+-------+-----------+-----------+-------+-------+
+ |Join ||yes | yes | yes | yes | - | no |
+ |(S,G) || | | | | | |
+ +----------++------+-------+-----------+-----------+-------+-------+
+ |Prune ||yes | yes | ? | ? | no | - |
+ |(S,G) || | | | | | |
+ +----------++------+-------+-----------+-----------+-------+-------+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 119]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ yes Allowed and expected.
+
+ no Combination is not allowed by the protocol and MUST NOT be
+ generated by a router. A router MAY accept these messages, but
+ the result is undefined. An error message MAY be logged to the
+ administrator in a rate-limited manner.
+
+ ? Combination not expected by the protocol, but well defined. A
+ router MAY accept it but SHOULD NOT generate it.
+
+ The order of source list entries in a group set source list is not
+ important, except where limited by the packet format itself.
+
+4.9.5.2. Group Set Fragmentation
+
+ When building a Join/Prune for a particular neighbor, a router should
+ try to include in the message as much of the information it needs to
+ convey to the neighbor as possible. This implies adding one group
+ set for each multicast group that has information pending
+ transmission and within each set including all relevant source list
+ 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 maximum IP packet size. In most such cases, the information
+ may be split into multiple messages.
+
+ There is an exception with group sets that contain a (*,G) Joined
+ source list entry. The group set expresses the router's interest in
+ receiving all traffic for the specified group on the shared tree, and
+ it MUST include an (S,G,rpt) Pruned source list entry for every
+ source that the router does not wish to receive. This list of
+ (S,G,rpt) Pruned source list entries MUST NOT be split in multiple
+ messages.
+
+ 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
+ the router MUST choose to include the first N (numerically smallest
+ in network byte order) IP addresses, and the rest are ignored (not
+ included).
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 120]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.9.6. Assert Message Format
+
+ The Assert message is used to resolve forwarder conflicts between
+ routers on a link. It is sent when a router receives a multicast
+ data packet on an interface on which the router would normally have
+ forwarded that packet. Assert messages may also be sent in response
+ to an Assert message from another router.
+
+ 0 1 2 3
+ 0 1 2 3 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Group Address (Encoded-Group format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Address (Encoded-Unicast format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |R| Metric Preference |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Metric |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ PIM Version, Type, Reserved, Checksum
+ Described in Section 4.9.
+
+ Group Address
+ The group address for which the router wishes to resolve the
+ forwarding conflict. This is an encoded group address, as
+ specified in Section 4.9.1.
+
+ Source Address
+ Source address for which the router wishes to resolve the
+ forwarding conflict. The source address MAY be set to zero for
+ (*,G) asserts (see below). The format for this address is
+ given in the encoded unicast address in Section 4.9.1.
+
+ R RPTbit is a 1-bit value. The RPTbit is set to 1 for
+ Assert(*,G) messages and 0 for Assert(S,G) messages.
+
+ Metric Preference
+ Preference value assigned to the unicast routing protocol that
+ provided the route to the multicast source or Rendezvous Point.
+
+ Metric
+ The unicast routing table metric associated with the route used
+ to reach the multicast source or Rendezvous Point. The metric
+ is in units applicable to the unicast routing protocol used.
+
+
+
+
+Fenner, et al. Standards Track [Page 121]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Assert messages can be sent to resolve a forwarding conflict for all
+ traffic to a given group or for a specific source and group.
+
+ Assert(S,G)
+ Source-specific asserts are sent by routers forwarding a
+ specific 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-Address field set to the source S. The RPTbit
+ is set to 0, the Metric-Preference is set to MRIB.pref(S), and
+ the Metric is set to MRIB.metric(S).
+
+ Assert(*,G)
+ Group-specific asserts are sent by routers forwarding data for
+ the group and source(s) under contention on the shared tree.
+ (*,G) asserts have the Group-Address field set to the group G.
+ For data-triggered Asserts, the Source-Address field MAY be set
+ to the IP source address of the data packet that triggered the
+ Assert and is set to zero otherwise. The RPTbit is set to 1,
+ the Metric-Preference is set to MRIB.pref(RP(G)), and the
+ Metric is set to MRIB.metric(RP(G)).
+
+4.10. PIM Timers
+
+ PIM-SM maintains the following timers, as discussed in Section 4.11.
+ All 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 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 language in this specification assumes that
+ they count downwards to zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 122]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Global Timers
+
+ Per interface (I):
+
+ Hello Timer: HT(I)
+
+ Per neighbor (N):
+
+ Neighbor Liveness Timer: NLT(N,I)
+
+ Per Group (G):
+
+ (*,G) Join Expiry Timer: ET(*,G,I)
+
+ (*,G) Prune-Pending Timer: PPT(*,G,I)
+
+ (*,G) Assert Timer: AT(*,G,I)
+
+ Per Source (S):
+
+ (S,G) Join Expiry Timer: ET(S,G,I)
+
+ (S,G) Prune-Pending Timer: PPT(S,G,I)
+
+ (S,G) Assert Timer: AT(S,G,I)
+
+ (S,G,rpt) Prune Expiry Timer: ET(S,G,rpt,I)
+
+ (S,G,rpt) Prune-Pending Timer: PPT(S,G,rpt,I)
+
+ Per Group (G):
+
+ (*,G) Upstream Join Timer: JT(*,G)
+
+ Per Source (S):
+
+ (S,G) Upstream Join Timer: JT(S,G)
+
+ (S,G) Keepalive Timer: KAT(S,G)
+
+ (S,G,rpt) Upstream Override Timer: OT(S,G,rpt)
+
+ At the DRs or relevant Assert Winners only:
+
+ Per Source,Group pair (S,G):
+
+ Register-Stop Timer: RST(S,G)
+
+
+
+
+Fenner, et al. Standards Track [Page 123]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+4.11. Timer Values
+
+ When timers are started or restarted, they are set to default values.
+ This section summarizes those default values.
+
+ Note that protocol events or configuration may change the default
+ value 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.
+
+ Some of the timers listed below (Prune-Pending, Upstream Join,
+ Upstream Override) can be set to values that depend on the settings
+ of the Propagation_Delay and Override_Interval of the corresponding
+ interface. The default values for these are given below.
+
+ Variable Name: Propagation_Delay(I)
+
++-------------------------------+--------------+----------------------+
+| Value Name | Value | Explanation |
++-------------------------------+--------------+----------------------+
+| Propagation_delay_default | 0.5 secs | Expected |
+| | | propagation delay |
+| | | over the local |
+| | | link. |
++-------------------------------+--------------+----------------------+
+
+ The default value of the Propagation_delay_default is chosen to be
+ relatively large to provide compatibility with older PIM
+ implementations.
+
+ Variable Name: Override_Interval(I)
+
++--------------------------+-----------------+-------------------------+
+| Value Name | Value | Explanation |
++--------------------------+-----------------+-------------------------+
+| t_override_default | 2.5 secs | Default delay |
+| | | interval over |
+| | | which to randomize |
+| | | when scheduling a |
+| | | delayed Join |
+| | | message. |
++--------------------------+-----------------+-------------------------+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 124]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Timer Name: Hello Timer (HT(I))
+
++---------------------+--------+---------------------------------------+
+|Value Name | Value | Explanation |
++---------------------+--------+---------------------------------------+
+|Hello_Period | 30 secs| Periodic interval for Hello messages. |
++---------------------+--------+---------------------------------------+
+|Triggered_Hello_Delay| 5 secs | Randomized interval for initial Hello |
+| | | message on bootup or triggered Hello |
+| | | message to a rebooting neighbor. |
++---------------------+--------+---------------------------------------+
+
+ At system power-up, the timer is initialized to
+ rand(0, Triggered_Hello_Delay) to prevent synchronization. When a
+ new or rebooting neighbor is detected, a responding Hello is sent
+ within rand(0, Triggered_Hello_Delay).
+
+ Timer Name: Neighbor Liveness Timer (NLT(N,I))
+
++--------------------------+----------------------+--------------------+
+| Value Name | Value | Explanation |
++--------------------------+----------------------+--------------------+
+| Default_Hello_Holdtime | 3.5 * Hello_Period | Default holdtime |
+| | | to keep neighbor |
+| | | state alive |
++--------------------------+----------------------+--------------------+
+| Hello_Holdtime | from message | Holdtime from |
+| | | Hello message |
+| | | Holdtime option. |
++--------------------------+----------------------+--------------------+
+
+ The Holdtime in a Hello message should be set to
+ (3.5 * Hello_Period), giving a default value of 105 seconds.
+
+ Timer Names: Expiry Timer (ET(*,G,I), ET(S,G,I), ET(S,G,rpt,I))
+
++----------------+----------------+------------------------------------+
+| Value Name | Value | Explanation |
++----------------+----------------+------------------------------------+
+| J/P_HoldTime | from message | Holdtime from Join/Prune message |
++----------------+----------------+------------------------------------+
+
+ The value of J/P Holdtime that is included in Join/Prune messages is
+ specified below, in the description of "Upstream Join Timer (JT(*,G),
+ JT(S,G))".
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 125]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Timer Names: Prune-Pending Timer (PPT(*,G,I), PPT(S,G,I),
+ PPT(S,G,rpt,I))
+
++--------------------------+---------------------+---------------------+
+|Value Name | Value | Explanation |
++--------------------------+---------------------+---------------------+
+|J/P_Override_Interval(I) | Default: | Short period after |
+| | Effective_ | a join or prune to |
+| | Propagation_ | allow other |
+| | Delay(I) + | routers on the LAN |
+| | Effective_Override_ | to override the |
+| | Interval(I) | join or prune |
++--------------------------+---------------------+---------------------+
+
+ Note that both Effective_Propagation_Delay(I) and
+ Effective_Override_Interval(I) are interface-specific values that may
+ change when Hello messages are received (see Section 4.3.3).
+
+ Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))
+
++---------------------------+---------------------+--------------------+
+| Value Name | Value | Explanation |
++---------------------------+---------------------+--------------------+
+| Assert_Override_Interval | Default: 3 secs | Short interval |
+| | | before an assert |
+| | | times out where |
+| | | the assert winner |
+| | | resends an Assert |
+| | | message |
++---------------------------+---------------------+--------------------+
+| Assert_Time | Default: 180 secs | Period after last |
+| | | assert before |
+| | | assert state is |
+| | | timed out |
++---------------------------+---------------------+--------------------+
+
+ Note that for historical reasons, the Assert message lacks a Holdtime
+ field. Thus, changing the Assert Time from the default value is not
+ recommended.
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 126]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Timer Names: Upstream Join Timer (JT(*,G), JT(S,G))
+
++-------------+--------------------+-----------------------------------+
+|Value Name | Value | Explanation |
++-------------+--------------------+-----------------------------------+
+|t_periodic | Default: 60 secs | Period between Join/Prune messages|
++-------------+--------------------+-----------------------------------+
+|t_suppressed | rand(1.1 * | Suppression period when someone |
+| | t_periodic, 1.4 * | else sends a J/P message so we |
+| | t_periodic) when | don't need to do so. |
+| | Suppression_ | |
+| | Enabled(I) is | |
+| | true, 0 otherwise | |
++-------------+--------------------+-----------------------------------+
+|t_override | rand(0, Effective_ | Randomized delay to prevent |
+| | Override_ | response implosion when sending a |
+| | Interval(I)) | Join message to override someone |
+| | | else's Prune message. |
++-------------+--------------------+-----------------------------------+
+
+ 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 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 have a larger number of entries). If the
+ Join/Prune-Period is modified during operation, these changes should
+ be made relatively infrequently, 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 router to adapt.
+
+ The Holdtime specified in a Join/Prune message should be set to
+ (3.5 * t_periodic).
+
+ t_override depends on the Effective Override Interval of the upstream
+ interface, which may change when Hello messages are received.
+
+ t_suppressed depends on the Suppression State of the upstream
+ interface (Section 4.3.3) and becomes zero when suppression is
+ disabled.
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 127]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Timer Name: Upstream Override Timer (OT(S,G,rpt))
+
++---------------+--------------------------+---------------------------+
+| Value Name | Value | Explanation |
++---------------+--------------------------+---------------------------+
+| t_override | see Upstream Join Timer | see Upstream Join Timer |
++---------------+--------------------------+---------------------------+
+
+ The Upstream Override Timer is only ever set to the t_override value;
+ this value is defined earlier in this section, under "Timer Names:
+ Upstream Join Timer (JT(*,G), JT(S,G))".
+
+ Timer Name: Keepalive Timer (KAT(S,G))
+
++-----------------------+-----------------------+----------------------+
+| Value Name | Value | Explanation |
++-----------------------+-----------------------+----------------------+
+| Keepalive_Period | Default: 210 secs | Period after last |
+| | | (S,G) data packet |
+| | | during which (S,G) |
+| | | Join state will be |
+| | | maintained even in |
+| | | the absence of |
+| | | (S,G) Join |
+| | | messages. |
++-----------------------+-----------------------+----------------------+
+| RP_Keepalive_Period | ( 3 * Register_ | As |
+| | Suppression_Time ) | Keepalive_Period, |
+| | + Register_ | but at the RP when |
+| | Probe_Time | a Register-Stop is |
+| | | sent. |
++-----------------------+-----------------------+----------------------+
+
+ 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
+ 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
+ max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop
+ is sent.
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 128]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Timer Name: Register-Stop Timer (RST(S,G))
+
++---------------------------+--------------------+---------------------+
+|Value Name | Value | Explanation |
++---------------------------+--------------------+---------------------+
+|Register_Suppression_Time | Default: 60 secs | Period during |
+| | | which a DR stops |
+| | | sending Register- |
+| | | encapsulated data |
+| | | to the RP after |
+| | | receiving a |
+| | | Register-Stop |
+| | | message. |
++---------------------------+--------------------+---------------------+
+|Register_Probe_Time | Default: 5 secs | Time before RST |
+| | | expires when a DR |
+| | | may send a Null- |
+| | | Register to the RP |
+| | | to cause it to |
+| | | resend a Register- |
+| | | Stop message. |
++---------------------------+--------------------+---------------------+
+
+ If the Register_Suppression_Time or the Register_Probe_Time is
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 129]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+5. IANA Considerations
+
+5.1. PIM Address Family
+
+ The PIM Address Family field was chosen to be 8 bits as a tradeoff
+ between packet format and use of the IANA-assigned numbers. Because
+ when the PIM packet format was designed only 15 values were assigned
+ for Address Families, and large numbers of new Address Family values
+ were not envisioned, 8 bits seemed large enough. However, the IANA
+ assigns Address Families in a 16-bit field. Therefore, the PIM
+ Address Family is allocated as follows:
+
+ Values 0 through 127 are designated to have the same meaning as
+ IANA-assigned Address Family Numbers [7].
+
+ Values 128 through 250 are designated to be assigned for PIM by
+ the IANA based upon IESG Approval, as defined in [9].
+
+ Values 251 through 255 are designated for Private Use, as defined
+ in [9].
+
+5.2. PIM Hello Options
+
+ 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 [9]. Such assignments are valid for one year and may be
+ renewed. Permanent assignments require a specification (see
+ "Specification Required" in [9]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 130]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+6. Security Considerations
+
+ This section describes various possible security concerns related to
+ the PIM-SM protocol. The reader is referred to [8], [14], and [15]
+ for further discussion of PIM-SM and multicast security.
+
+ Note that PIM relies upon an MRIB populated outside of PIM;
+ therefore, securing the sources of change to the MRIB is RECOMMENDED.
+
+6.1. Attacks Based on Forged Messages
+
+ The extent of possible damage depends on the type of counterfeit
+ messages accepted. We next consider the impact of possible
+ forgeries, including forged link-local (Join/Prune, Hello, and
+ Assert) and forged unicast (Register and Register-Stop) messages.
+
+6.1.1. Forged Link-Local Messages
+
+ Join/Prune, Hello, and Assert messages are all sent to the link-local
+ ALL-PIM-ROUTERS multicast address and thus are not forwarded by a
+ compliant router. A forged message of this type can only reach a LAN
+ if it was sent by a local host or if it was allowed onto the LAN by a
+ compromised or non-compliant router.
+
+ 1. A forged Join/Prune message can cause multicast traffic to be
+ delivered to links where there are no legitimate requesters,
+ potentially wasting bandwidth on that link. A forged leave
+ message on a multi-access LAN is generally not a significant
+ attack in PIM, because any legitimately joined router on the LAN
+ would override the leave with a join before the upstream router
+ stops forwarding data to the LAN.
+
+ 2. By forging a Hello message, an unauthorized router can cause
+ itself to be elected as the Designated Router on a LAN. The
+ Designated Router on a LAN is (in the absence of asserts)
+ responsible for forwarding traffic to that LAN on behalf of any
+ local members. The Designated Router is also responsible for
+ register-encapsulating to the RP any packets that are originated
+ by hosts on the LAN. Thus, the ability of local hosts to send
+ and receive multicast traffic may be compromised by a forged
+ Hello message.
+
+ 3. By forging an Assert message on a multi-access LAN, an attacker
+ could cause the legitimate designated forwarder to stop
+ forwarding traffic to the LAN. Such a forgery would prevent any
+ hosts downstream of that LAN from receiving traffic.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 131]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+6.1.2. Forged Unicast Messages
+
+ Register messages and Register-Stop messages are forwarded by
+ intermediate routers to their destination using normal IP forwarding.
+ Without data origin authentication, an attacker who is located
+ anywhere in the network may be able to forge a Register or
+ Register-Stop message. We next consider the effect of a forgery of
+ each of these messages.
+
+ 1. By forging a Register message, an attacker can cause the RP to
+ inject forged traffic onto the shared multicast tree.
+
+ 2. By forging a Register-Stop message, an attacker can prevent a
+ legitimate DR from registering packets to the RP. This can
+ prevent local hosts on that LAN from sending multicast packets.
+
+ The above two PIM messages are not changed by intermediate routers
+ and need only be examined by the intended receiver. Thus, these
+ messages can be authenticated end-to-end. Attacks on Register and
+ Register-Stop messages do not apply to a PIM-SSM-only implementation,
+ as these messages are not required for PIM-SSM.
+
+6.2. Non-cryptographic Authentication Mechanisms
+
+ A PIM router SHOULD provide an option to limit the set of neighbors
+ from which it will accept Join/Prune, Assert, and Hello messages.
+ Either static configuration of IP addresses or an IPsec security
+ association MAY be used. Furthermore, a PIM router SHOULD NOT accept
+ protocol messages from a router from which it has not yet received a
+ valid Hello message.
+
+ A Designated Router MUST NOT register-encapsulate a packet and send
+ it to the RP unless the source address of the packet is a legal
+ address for the subnet on which the packet was received. Similarly,
+ a Designated Router SHOULD NOT accept a Register-Stop packet whose IP
+ source address is not a valid RP address for the local domain.
+
+ An implementation SHOULD provide a mechanism to allow an RP to
+ restrict the range of source addresses from which it accepts
+ Register-encapsulated packets.
+
+ All options that restrict the range of addresses from which packets
+ are accepted MUST default to allowing all packets.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 132]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+6.3. Authentication
+
+ This document refers to RFC 5796 [8], which specifies mechanisms to
+ authenticate PIM-SM link-local messages using the IPsec Encapsulating
+ Security Payload (ESP) or (optionally) the Authentication Header
+ (AH). It also points out that non-link-local PIM-SM messages (i.e.,
+ Register and Register-Stop messages) can be secured by a normal
+ unicast IPsec Security Association (SA) between two communicants.
+
+6.4. Denial-of-Service Attacks
+
+ There are a number of possible denial-of-service attacks against PIM
+ that can be caused by generating false PIM protocol messages or even
+ by generating false traffic. Authenticating PIM protocol traffic
+ prevents some, but not all, of these attacks. Two of the possible
+ attacks include the following:
+
+ o Sending packets to many different group addresses quickly can be a
+ denial-of-service attack in and of itself. This will cause many
+ register-encapsulated packets, loading the DR, the RP, and the
+ routers between the DR and the RP.
+
+ o Forging Join messages can cause a multicast tree to get set up.
+ A large number of forged joins can consume router resources and
+ result in denial of service.
+
+7. References
+
+7.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+ Thyagarajan, "Internet Group Management Protocol, Version 3",
+ RFC 3376, DOI 10.17487/RFC3376, October 2002,
+ <http://www.rfc-editor.org/info/rfc3376>.
+
+ [3] Deering, S., "Host extensions for IP multicasting", STD 5,
+ RFC 1112, DOI 10.17487/RFC1112, August 1989,
+ <http://www.rfc-editor.org/info/rfc1112>.
+
+ [4] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
+ Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710,
+ October 1999, <http://www.rfc-editor.org/info/rfc2710>.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 133]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+ Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,
+ <http://www.rfc-editor.org/info/rfc2460>.
+
+ [6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
+ RFC 4607, DOI 10.17487/RFC4607, August 2006,
+ <http://www.rfc-editor.org/info/rfc4607>.
+
+ [7] IANA, "Address Family Numbers",
+ <http://www.iana.org/assignments/address-family-numbers>.
+
+ [8] Atwood, W., Islam, S., and M. Siami, "Authentication and
+ Confidentiality in Protocol Independent Multicast Sparse Mode
+ (PIM-SM) Link-Local Messages", RFC 5796, DOI 10.17487/RFC5796,
+ March 2010, <http://www.rfc-editor.org/info/rfc5796>.
+
+ [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+7.2. Informative References
+
+ [10] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol
+ Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760,
+ January 2007, <http://www.rfc-editor.org/info/rfc4760>.
+
+ [11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap
+ Router (BSR) Mechanism for Protocol Independent Multicast
+ (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008,
+ <http://www.rfc-editor.org/info/rfc5059>.
+
+ [12] Black, D., "Differentiated Services and Tunnels", RFC 2983,
+ DOI 10.17487/RFC2983, October 2000,
+ <http://www.rfc-editor.org/info/rfc2983>.
+
+ [13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
+ "Bidirectional Protocol Independent Multicast (BIDIR-PIM)",
+ RFC 5015, DOI 10.17487/RFC5015, October 2007,
+ <http://www.rfc-editor.org/info/rfc5015>.
+
+ [14] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
+ Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
+ Issues and Enhancements", RFC 4609, DOI 10.17487/RFC4609,
+ October 2006, <http://www.rfc-editor.org/info/rfc4609>.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 134]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ [15] Savola, P. and J. Lingard, "Host Threats to Protocol Independent
+ Multicast (PIM)", RFC 5294, DOI 10.17487/RFC5294, August 2008,
+ <http://www.rfc-editor.org/info/rfc5294>.
+
+ [16] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
+ Address in an IPv6 Multicast Address", RFC 3956,
+ DOI 10.17487/RFC3956, November 2004,
+ <http://www.rfc-editor.org/info/rfc3956>.
+
+ [17] Zheng, L., Zhang, J., and R. Parekh, "Survey Report on Protocol
+ Independent Multicast - Sparse Mode (PIM-SM) Implementations and
+ Deployments", RFC 7063, DOI 10.17487/RFC7063, December 2013,
+ <http://www.rfc-editor.org/info/rfc7063>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 135]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+Appendix A. Functionality Removed from RFC 4601
+
+ Based on a survey of PIM implementations and deployments [17]
+ conducted by the IETF PIM working group, the following functionality
+ of RFC 4601 has been removed due to lack of sufficient implementation
+ and deployment experience:
+
+ o (*,*,RP) State
+
+ o PIM Multicast Border Router (PMBR)
+
+ o Authentication using IPsec
+
+Acknowledgements
+
+ PIM-SM was designed over many years by a large group of people,
+ including ideas, comments, and corrections from Deborah Estrin, Dino
+ Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C.
+ Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott
+ Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly
+ Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian
+ Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike
+ Davison, James Huang, Christopher Thomas Brown, and James Lingard.
+
+ Thanks are due to the American Licorice Company, for its obscure but
+ possibly essential role in the creation of this document.
+
+Authors' Addresses
+
+ Bill Fenner
+ Arista Networks
+
+ Email: fenner@arista.com
+
+
+ Mark Handley
+ Department of Computer Science
+ University College London
+ Gower Street
+ London WC1E 6BT
+ United Kingdom
+
+ Email: M.Handley@cs.ucl.ac.uk
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 136]
+
+RFC 7761 PIM-SM Specification (Revised) March 2016
+
+
+ Hugh Holbrook
+ Arista Networks
+ 5453 Great America Parkway
+ Santa Clara, CA 95054
+
+ Email: holbrook@arista.com
+
+
+ Isidor Kouvelas
+ Arista Networks
+ 5453 Great America Parkway
+ Santa Clara, CA 95054
+
+ Email: kouvelas@arista.com
+
+
+ Rishabh Parekh
+ Cisco Systems, Inc.
+ 170 W. Tasman Drive
+ San Jose, CA 95134
+
+ Email: riparekh@cisco.com
+
+
+ Zhaohui Zhang
+ Juniper Networks
+ 10 Technology Park Drive
+ Westford, MA 01886
+
+ Email: zzhang@juniper.net
+
+
+ Lianshu Zheng
+ Huawei Technologies Co., Ltd
+ Huawei Campus, 156 Beiqing Road, Hai-dian District
+ Beijing 100089
+ China
+
+ Email: vero.zheng@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 137]
+