summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4601.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4601.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4601.txt')
-rw-r--r--doc/rfc/rfc4601.txt8403
1 files changed, 8403 insertions, 0 deletions
diff --git a/doc/rfc/rfc4601.txt b/doc/rfc/rfc4601.txt
new file mode 100644
index 0000000..9a5bf43
--- /dev/null
+++ b/doc/rfc/rfc4601.txt
@@ -0,0 +1,8403 @@
+
+
+
+
+
+
+Network Working Group B. Fenner
+Request for Comments: 4601 AT&T Labs - Research
+Obsoletes: 2362 M. Handley
+Category: Standards Track UCL
+ H. Holbrook
+ Arastra
+ I. Kouvelas
+ Cisco
+ August 2006
+
+
+ Protocol Independent Multicast - Sparse Mode (PIM-SM):
+ Protocol Specification (Revised)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+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 optionally
+ creates shortest-path trees per source.
+
+ This document obsoletes RFC 2362, an Experimental version of PIM-SM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 1]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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 ...................................8
+ 3.3. Phase Three: Shortest-Path Tree ............................9
+ 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. (*,*,RP) State .....................................15
+ 4.1.3. (*,G) State ........................................16
+ 4.1.4. (S,G) State ........................................17
+ 4.1.5. (S,G,rpt) State ....................................20
+ 4.1.6. State Summarization Macros .........................21
+ 4.2. Data Packet Forwarding Rules ..............................26
+ 4.2.1. Last-Hop Switchover to the SPT .....................28
+ 4.2.2. Setting and Clearing the (S,G) SPTbit ..............29
+ 4.3. Designated Routers (DR) and Hello Messages ................30
+ 4.3.1. Sending Hello Messages .............................30
+ 4.3.2. DR Election ........................................32
+ 4.3.3. Reducing Prune Propagation Delay on LANs ...........34
+ 4.3.4. Maintaining Secondary Address Lists ................37
+ 4.4. PIM Register Messages .....................................38
+ 4.4.1. Sending Register Messages from the DR ..............38
+ 4.4.2. Receiving Register Messages at the RP ..............43
+ 4.5. PIM Join/Prune Messages ...................................45
+ 4.5.1. Receiving (*,*,RP) Join/Prune Messages .............45
+ 4.5.2. Receiving (*,G) Join/Prune Messages ................49
+ 4.5.3. Receiving (S,G) Join/Prune Messages ................53
+ 4.5.4. Receiving (S,G,rpt) Join/Prune Messages ............56
+ 4.5.5. Sending (*,*,RP) Join/Prune Messages ...............62
+ 4.5.6. Sending (*,G) Join/Prune Messages ..................66
+ 4.5.7. Sending (S,G) Join/Prune Messages ..................71
+ 4.5.8. (S,G,rpt) Periodic Messages ........................76
+ 4.5.9. State Machine for (S,G,rpt) Triggered Messages .....77
+ 4.5.10. Background: (*,*,RP) and (S,G,rpt) Interaction ....82
+ 4.6. PIM Assert Messages .......................................83
+ 4.6.1. (S,G) Assert Message State Machine .................83
+ 4.6.2. (*,G) Assert Message State Machine .................91
+ 4.6.3. Assert Metrics .....................................98
+
+
+
+Fenner, et al. Standards Track [Page 2]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 4.6.4. AssertCancel Messages ..............................99
+ 4.6.5. Assert State Macros ...............................100
+ 4.7. PIM Bootstrap and RP Discovery ...........................103
+ 4.7.1. Group-to-RP Mapping ...............................104
+ 4.7.2. Hash Function .....................................105
+ 4.8. Source-Specific Multicast ................................106
+ 4.8.1. Protocol Modifications for SSM Destination
+ Addresses .........................................106
+ 4.8.2. PIM-SSM-Only Routers ..............................107
+ 4.9. PIM Packet Formats .......................................108
+ 4.9.1. Encoded Source and Group Address Formats ..........110
+ 4.9.2. Hello Message Format ..............................113
+ 4.9.3. Register Message Format ...........................116
+ 4.9.4. Register-Stop Message Format ......................119
+ 4.9.5. Join/Prune Message Format .........................119
+ 4.9.5.1. Group Set Source List Rules ..............122
+ 4.9.5.2. Group Set Fragmentation ..................126
+ 4.9.6. Assert Message Format .............................126
+ 4.10. PIM Timers ..............................................128
+ 4.11. Timer Values ............................................129
+ 5. IANA Considerations ...........................................135
+ 5.1. PIM Address Family .......................................135
+ 5.2. PIM Hello Options ........................................136
+ 6. Security Considerations .......................................136
+ 6.1. Attacks Based on Forged Messages .........................136
+ 6.1.1. Forged Link-Local Messages ........................136
+ 6.1.2. Forged Unicast Messages ...........................137
+ 6.2. Non-Cryptographic Authentication Mechanisms ..............137
+ 6.3. Authentication Using IPsec ...............................138
+ 6.3.1. Protecting Link-Local Multicast Messages ..........138
+ 6.3.2. Protecting Unicast Messages .......................139
+ 6.3.2.1. Register Messages ........................139
+ 6.3.2.2. Register-Stop Messages ...................139
+ 6.4. Denial-of-Service Attacks ................................140
+ 7. Acknowledgements ..............................................140
+ 8. Normative References ..........................................141
+ 9. Informative References ........................................141
+ Appendix A. PIM Multicast Border Router Behavior .................143
+ A.1. Sources External to the PIM-SM Domain ....................143
+ A.2. Sources Internal to the PIM-SM Domain ...................144
+ Appendix B. Index ................................................146
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 3]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+List of Figures
+
+ Figure 1. Per-(S,G) register state machine at a DR ................38
+ Figure 2. Downstream per-interface (*,*,RP) state machine .........46
+ Figure 3. Downstream per-interface (*,G) state machine ............50
+ Figure 4. Downstream per-interface (S,G) state machine ............53
+ Figure 5. Downstream per-interface (S,G,rpt) state machine ........57
+ Figure 6. Upstream (*,*,RP) state machine .........................62
+ Figure 7. Upstream (*,G) state machine ............................67
+ Figure 8. Upstream (S,G) state machine ............................71
+ Figure 9. Upstream (S,G,rpt) state machine for triggered
+ messages ................................................77
+ Figure 10. Per-interface (S,G) Assert State machine ...............84
+ Figure 11. Per-interface (*,G) Assert State machine ...............92
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 4]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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 originally specified in RFC 2117 and was revised
+ in RFC 2362, both Experimental RFCs. This document is intended to
+ obsolete RFC 2362, to correct a number of deficiencies that have been
+ identified with the way PIM-SM was previously specified, and to bring
+ PIM-SM onto the IETF Standards Track. As far as possible, this
+ document specifies the same protocol as RFC 2362 and only diverges
+ from the behavior intended by RFC 2362 when the previously specified
+ behavior was clearly incorrect. Routers implemented according to the
+ specification in this document will be able to interoperate
+ successfully with routers implemented according to RFC 2362.
+
+2. Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
+ indicate requirement levels for compliant PIM-SM implementations.
+
+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 4601 PIM-SM Specification August 2006
+
+
+ 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 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.
+
+ PMBR PIM Multicast Border Router, joining a PIM domain with another
+ multicast domain.
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 6]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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.
+
+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.
+
+ 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.
+
+
+
+Fenner, et al. Standards Track [Page 7]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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.
+
+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.
+
+
+
+
+Fenner, et al. Standards Track [Page 8]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 2, 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.
+
+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.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 9]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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, as described in
+ Section 4.8.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 10]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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
+ neither or both router has (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 to 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.
+
+
+
+Fenner, et al. Standards Track [Page 11]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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
+ Bootstrap Router 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.
+
+ o Section 4.7 specifies the RP discovery mechanisms.
+
+ o The subset of PIM required to support Source-Specific Multicast,
+ PIM-SSM, is described in Section 4.8.
+
+ o PIM packet formats are specified in Section 4.9.
+
+
+
+Fenner, et al. Standards Track [Page 12]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ o A summary of PIM-SM timers and their default values is given in
+ Section 4.10.
+
+ o Appendix A specifies the PIM Multicast Border Router behavior.
+
+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 four sections:
+
+ (*,*,RP) state
+ State that maintains per-RP trees, for all groups served by a
+ given RP.
+
+ (*,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 4601 PIM-SM Specification August 2006
+
+
+ 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 4601 PIM-SM Specification August 2006
+
+
+4.1.2. (*,*,RP) State
+
+ For every RP, a router keeps the following state:
+
+ (*,*,RP) state:
+ For each interface:
+
+ PIM (*,*,RP) 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)
+
+ Not interface specific:
+
+ Upstream (*,*,RP) Join/Prune State:
+
+ o State: One of {"NotJoined(*,*,RP)",
+ "Joined(*,*,RP)"}
+
+ o Upstream Join/Prune Timer (JT)
+
+ o Last RPF Neighbor towards RP that was used
+
+ PIM (*,*,RP) Join/Prune state is the result of receiving PIM (*,*,RP)
+ Join/Prune messages on this interface and is specified in Section
+ 4.5.1.
+
+ The upstream (*,*,RP) Join/Prune State reflects the state of the
+ upstream (*,*,RP) state machine described in Section 4.5.5.
+
+ The upstream (*,*,RP) Join/Prune Timer is used to send out periodic
+ Join(*,*,RP) messages, and to override Prune(*,*,RP) messages from
+ peers on an upstream LAN interface.
+
+ 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(*,*,RP) to the new upstream
+ neighbor and a Prune(*,*,RP) 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(*,*,RP). These
+ mechanisms are specified in Section 4.5.5.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 15]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+4.1.3. (*,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. We recommend storing this information if
+
+
+
+Fenner, et al. Standards Track [Page 16]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.6.
+
+ 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.2. The state is used by the macros that calculate the outgoing
+ interface list in Section 4.1.6, and in the JoinDesired(*,G) macro
+ (defined in Section 4.5.6) 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.6.
+
+ 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-Set changes
+ (Section 4.7), 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.6.
+
+4.1.4. (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"}
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 17]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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)
+
+
+ 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
+
+ Additional (S,G) state at the RP:
+
+ o PMBR: the first PMBR to send a Register for this
+ source with the Border bit set.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 18]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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
+ a (S,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_include(S,G) macro
+ described in Section 4.1.6.
+
+ 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.6, and in the JoinDesired(S,G) macro
+ (defined in Section 4.5.7) 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.7.
+
+ 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.7.
+
+ 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
+ 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.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 19]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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).
+
+ On an RP, the PMBR value must be cleared when the Keepalive Timer
+ expires.
+
+4.1.5. (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)
+
+ 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
+
+
+
+Fenner, et al. Standards Track [Page 20]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.6.
+
+ 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.4. The state is used by the macros that calculate the
+ outgoing interface list in Section 4.1.6, and in the rules for adding
+ Prune(S,G,rpt) messages to Join(*,G) messages specified in Section
+ 4.5.8.
+
+ 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.9.
+
+4.1.6. 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(*,*,RP) (+) immediate_olist(*,G)).
+
+ Generally speaking, the inherited olists are used for forwarding, and
+ the immediate_olists are used to make decisions about state
+ maintenance.
+
+
+
+Fenner, et al. Standards Track [Page 21]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ immediate_olist(*,*,RP) =
+ joins(*,*,RP)
+
+ 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(*,*,RP(G)) (+) 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
+ module or other local membership mechanism has determined that local
+
+
+
+Fenner, et al. Standards Track [Page 22]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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(*,*,RP)" is the set of all interfaces on which the
+ router has received (*,*,RP) Joins:
+
+ joins(*,*,RP) =
+ { all interfaces I such that
+ DownstreamJPState(*,*,RP,I) is either Join or
+ Prune-Pending }
+
+ DownstreamJPState(*,*,RP,I) is the state of the finite state machine
+ in Section 4.5.1.
+
+ 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.2.
+
+ 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.3.
+
+ 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.4.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 23]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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)
+ }
+ }
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 24]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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
+ 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.8).
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 25]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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 RP, except at the RP when it is the
+ decapsulation interface (the "virtual" interface on which register
+ packets are received).
+
+ 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 (*,*,RP) or (*,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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 26]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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
+
+ 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 FSM may cause an Assert(S,G)
+ # or Assert(*,G) message to be sent out interface iif.
+ # See section 4.6 for details.
+ if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
+ 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.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 27]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Basically, inherited_olist(S,G) is the outgoing interface list for
+ packets forwarded on (S,G) state, taking into account (*,*,RP) state,
+ (*,G) state, asserts, etc.
+
+ inherited_olist(S,G,rpt) is the outgoing interface list for packets
+ forwarded on (*,*,RP) or (*,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.7.
+
+ Keepalive_Period is defined in Section 4.10.
+
+ Data-triggered PIM-Assert messages sent from the above forwarding
+ code should be rate-limited in a 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.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 28]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+4.2.2. Setting and Clearing the (S,G) SPTbit
+
+ The (S,G) SPTbit is used to distinguish whether to forward on
+ (*,*,RP)/(*,G) or on (S,G) state. When switching from the RP tree to
+ the source tree, there is a transition period when data is arriving
+ due to upstream (*,*,RP)/(*,G) state while upstream (S,G) state is
+ being established, during which time a router should continue to
+ forward only on (*,*,RP)/(*,G) state. This prevents temporary
+ black-holes that would be caused by sending a Prune(S,G,rpt) before
+ the upstream (S,G) state has finished being established.
+
+ 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.7 and indicates whether we
+ have the appropriate (S,G) Join state to wish to send a Join(S,G)
+ upstream.
+
+ Basically, Update_SPTbit 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 applies:
+
+ 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. Noone wants the packet on the RP tree.
+
+
+
+Fenner, et al. Standards Track [Page 29]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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.
+
+ The SPTbit is cleared in the (S,G) upstream state machine (see
+ Section 4.5.7) when JoinDesired(S,G) becomes FALSE.
+
+4.3. Designated Routers (DR) 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 Designated Router (DR), and to negotiate additional
+ capabilities. A router must record the Hello information received
+ from each PIM neighbor.
+
+ Hello messages MUST be sent on all active interfaces, including
+ physical point-to-point links, and are multicast to 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.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 30]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ A per-interface Hello Timer (HT(I)) is used to trigger sending Hello
+ messages on each active interface. When PIM is enabled on an
+ interface or a router first starts, the Hello Timer of that interface
+ is set to a random value between 0 and Triggered_Hello_Delay. This
+ prevents synchronization of Hello messages if multiple routers are
+ powered on simultaneously. After the initial randomized interval,
+ Hello messages must be sent every Hello_Period seconds. The Hello
+ Timer should not be reset except when it expires.
+
+ Note that neighbors will not accept Join/Prune or Assert messages
+ from a router unless they have first heard a Hello message from that
+ router. Thus, if a router needs to send a Join/Prune or Assert
+ message on an interface on which it has not yet sent a Hello message
+ 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.
+
+
+
+
+Fenner, et al. Standards Track [Page 31]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ To allow new or rebooting routers to learn of PIM neighbors quickly,
+ when a Hello message is received from a new neighbor, or a Hello
+ message with a new GenID is received from an existing neighbor, a new
+ Hello message should be sent on this interface after a randomized
+ delay between 0 and Triggered_Hello_Delay. This triggered message
+ need not change the timing of the scheduled periodic message. If a
+ router needs to send a Join/Prune to the new neighbor or send an
+ Assert message in response to an Assert message from the new neighbor
+ before this randomized delay has expired, then it MUST immediately
+ send the relevant 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 32]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 33]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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:
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 34]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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
+ }
+
+ To avoid synchronization of override messages when multiple
+ downstream routers share a multi-access link, sending of such
+ messages is delayed by a small random amount of time. The period of
+ randomization should represent the size of the PIM router population
+
+
+
+Fenner, et al. Standards Track [Page 35]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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
+ }
+
+ 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.10).
+
+
+
+Fenner, et al. Standards Track [Page 36]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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.
+
+ 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.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 37]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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.
+
+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 4601 PIM-SM Specification August 2006
+
+
+ Figure 1: Per-(S,G) register state machine at a DR in tabular form
+
++----------++----------------------------------------------------------+
+| || 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 | | | | |
++----------++----------+-----------+-----------+-----------+-----------+
+
+ 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.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 39]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 spec 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 4601 PIM-SM Specification August 2006
+
+
+ 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 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 4601 PIM-SM Specification August 2006
+
+
+ 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 4601 PIM-SM Specification August 2006
+
+
+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 ( register.borderbit == TRUE ) {
+ if ( PMBR(S,G) == unknown ) {
+ PMBR(S,G) = outer.src
+ } else if ( outer.src != PMBR(S,G) ) {
+ send Register-Stop(S,G) to outer.src
+ drop the packet silently.
+ }
+ }
+ if ( SPTbit(S,G) OR
+ ( 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.
+
+
+
+
+Fenner, et al. Standards Track [Page 43]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 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 are advised not to make this a special
+ case, but to arrange that this path rejoin the normal packet
+ forwarding path. All of the appropriate actions from the "On
+ receipt of data from S to G on interface iif" pseudocode in
+ Section 4.2 should be performed.
+
+ KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the
+ 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 Diffserv Code Point (DSCP) should be copied from the IP header of
+ the Register packet to the decapsulated packet. The RP MAY retain
+ the DSCP of the inner packet or re-classify the packet and apply a
+ different DSCP. Scenarios where each of these might be useful are
+ discussed in [12].
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 44]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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 (*,*,RP), (S,G), and (S,G,rpt) Joins and Prunes
+ can only affect their respective downstream state machines. When
+ considering 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
+ using IPsec AH (see Section 6.3), then all Join/Prune messages from
+ that neighbor MUST also be authenticated using IPsec AH.
+
+ We note that some older PIM implementations incorrectly fail to send
+ Hello messages on point-to-point interfaces, so we also RECOMMEND
+ that a configuration option be provided to allow interoperation with
+ such older routers, but that this configuration option SHOULD NOT be
+ enabled by default.
+
+4.5.1. Receiving (*,*,RP) Join/Prune Messages
+
+ The per-interface state machine for receiving (*,*,RP) Join/Prune
+ Messages is given below. There are three states:
+
+ NoInfo (NI)
+ The interface has no (*,*,RP) Join state and no timers
+ running.
+
+ Join (J)
+ The interface has (*,*,RP) Join state, which will cause the
+ router to forward packets destined for any group handled by RP
+ from this interface except if there is also (S,G,rpt) prune
+ information (see Section 4.5.4) or the router lost an assert
+ on this interface.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 45]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Prune-Pending (PP)
+ The router has received a Prune(*,*,RP) 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:
+
+ ExpiryTimer (ET)
+ This timer is restarted when a valid Join(*,*,RP) is received.
+ Expiry of the ExpiryTimer causes the interface state to revert
+ to NoInfo for this RP.
+
+ Prune-Pending Timer (PPT)
+ This timer is set when a valid Prune(*,*,RP) is received.
+ Expiry of the Prune-Pending Timer causes the interface state
+ to revert to NoInfo for this RP.
+
+ Figure 2: Downstream per-interface (*,*,RP) state machine
+ in tabular form
+
++------------++--------------------------------------------------------+
+| || Event |
+| ++-------------+-------------+--------------+-------------+
+|Prev State ||Receive | Receive | Prune- | Expiry Timer|
+| ||Join(*,*,RP) | Prune | Pending | Expires |
+| || | (*,*,RP) | 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(*,*,RP) | |
++------------++-------------+-------------+--------------+-------------+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 46]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ The transition events "Receive Join(*,*,RP)" and "Receive
+ Prune(*,*,RP)" 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 we also recommend that for backwards compatibility PIM
+ Join/Prune messages with an upstream neighbor address field of all
+ zeros are also accepted.
+
+ Transitions from NoInfo State
+
+ When in NoInfo state, the following event may trigger a transition:
+
+ Receive Join(*,*,RP)
+ A Join(*,*,RP) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address on I.
+
+ The (*,*,RP) 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.
+
+ Note that it is possible to receive a Join(*,*,RP) message for
+ an RP for which we do not have information telling us that it
+ is an RP. In the case of (*,*,RP) state, so long as we have a
+ route to the RP, this will not cause a problem, and the
+ transition should still take place.
+
+ Transitions from Join State
+
+ When in Join state, the following events may trigger a transition:
+
+ Receive Join(*,*,RP)
+ A Join(*,*,RP) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address on I.
+
+ The (*,*,RP) downstream state machine on interface I remains
+ in Join state, and the Expiry Timer (ET) is restarted, set to
+ maximum of its current value and the HoldTime from the
+ triggering Join/Prune message.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 47]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Receive Prune(*,*,RP)
+ A Prune(*,*,RP) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address on I.
+
+ The (*,*,RP) 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 (*,*,RP) downstream state machine on
+ interface I expires.
+
+ The (*,*,RP) downstream state machine on interface I
+ transitions to the NoInfo state.
+
+ Transitions from Prune-Pending State
+
+ When in Prune-Pending state, the following events may trigger a
+ transition:
+
+ Receive Join(*,*,RP)
+ A Join(*,*,RP) is received on interface I with its Upstream
+ Neighbor Address set to the router's primary IP address on I.
+
+ The (*,*,RP) 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 is restarted, set to maximum of its current value and
+ the HoldTime from the triggering Join/Prune message.
+
+ Expiry Timer Expires
+ The Expiry Timer for the (*,*,RP) downstream state machine on
+ interface I expires.
+
+ The (*,*,RP) downstream state machine on interface I
+ transitions to the NoInfo state.
+
+ Prune-Pending Timer Expires
+ The Prune-Pending Timer for the (*,*,RP) downstream state
+ machine on interface I expires.
+
+ The (*,*,RP) downstream state machine on interface I
+ transitions to the NoInfo state. A PruneEcho(*,*,RP) is sent
+ onto the subnet connected to interface I.
+
+
+
+
+Fenner, et al. Standards Track [Page 48]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ The action "Send PruneEcho(*,*,RP)" is triggered when the
+ router stops forwarding on an interface as a result of a
+ prune. A PruneEcho(*,*,RP) is simply a Prune(*,*,RP) 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(*,*,RP) 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.
+
+4.5.2. 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).
+
+ 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.4) 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 49]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ Figure 3: Downstream per-interface (*,G) state machine in tabular form
+
++------------++--------------------------------------------------------+
+| || 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-
+
+
+
+
+
+Fenner, et al. Standards Track [Page 50]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ point links we also recommend that for backwards compatibility PIM
+ Join/Prune messages with an upstream neighbor address field of all
+ zeros are also accepted.
+
+ 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, set to
+ 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 51]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 is
+ restarted, set to 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 52]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+4.5.3. 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 53]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Figure 4: Downstream per-interface (S,G) state machine in tabular form
+
++------------++--------------------------------------------------------+
+| || 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 we also recommend that for backwards compatibility PIM
+ Join/Prune messages with an upstream neighbor address field of all
+ zeros are also accepted.
+
+ 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.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 54]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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, and the Expiry Timer (ET) is restarted, set to
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 55]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 is
+ restarted, set to 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.
+
+4.5.4. 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.
+
+
+
+
+Fenner, et al. Standards Track [Page 56]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 a (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 PP
+ state.
+
+ 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 57]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Figure 5: Downstream per-interface (S,G,rpt) state machine
+ in tabular form
+
++----------++----------------------------------------------------------+
+| || 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 58]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 we also recommend that PIM Join/Prune messages with an
+ upstream neighbor address field of all zeros are also 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.
+
+ 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 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 NoInfo state. ET and PPT are canceled.
+
+
+
+
+Fenner, et al. Standards Track [Page 59]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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 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 NoInfo state. 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, set to
+ 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.
+
+ 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:
+
+
+
+Fenner, et al. Standards Track [Page 60]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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-Pending state. The Expiry Timer
+ (ET) is restarted, set to 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 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, set to 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.
+
+ Notes:
+
+ Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream state
+ machine.
+
+ Receiving a Join(*,*,RP) does not affect the (S,G,rpt) downstream
+ state machine. If a router has originated Join(*,*,RP) and pruned a
+ source off it using Prune(S,G,rpt), then to receive that source again
+ it should explicitly re-join using Join(S,G,rpt) or Join(*,G). In
+ some LAN topologies it is possible for a router sending a new
+ Join(*,*,RP) to have to wait as much as a Join/Prune Interval before
+ noticing that it needs to override a neighbor's preexisting
+ Prune(S,G,rpt). This is considered acceptable, as (*,*,RP) state is
+ intended to be used only in long-lived and persistent scenarios.
+
+
+
+
+Fenner, et al. Standards Track [Page 61]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+4.5.5. Sending (*,*,RP) Join/Prune Messages
+
+ The per-interface state machines for (*,*,RP) hold join state from
+ downstream PIM routers. This state then determines whether a router
+ needs to propagate a Join(*,*,RP) upstream towards the RP.
+
+ If a router wishes to propagate a Join(*,*,RP) upstream, it must also
+ watch for messages on its upstream interface from other routers on
+ that subnet, and these may modify its behavior. If it sees a
+ Join(*,*,RP) to the correct upstream neighbor, it should suppress its
+ own Join(*,*,RP). If it sees a Prune(*,*,RP) to the correct upstream
+ neighbor, it should be prepared to override that prune by sending a
+ Join(*,*,RP) almost 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(*,*,RP) almost
+ immediately.
+
+ In addition, if the MRIB changes to indicate that the next hop
+ towards the RP has changed, the router should prune off from the old
+ next hop and join towards the new next hop.
+
+ The upstream (*,*,RP) state machine contains only two states:
+
+ Not Joined
+ The downstream state machines and local membership information do
+ not indicate that the router needs to join the (*,*,RP) tree for
+ this RP.
+
+ Joined
+ The downstream state machines and local membership information
+ indicate that the router should join the (*,*,RP) tree for this
+ RP.
+
+ In addition, one timer JT(*,*,RP) is kept that is used to trigger the
+ sending of a Join(*,*,RP) to the upstream next hop towards the RP,
+ NBR(RPF_interface(RP), MRIB.next_hop(RP)).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 62]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Figure 6: Upstream (*,*,RP) state machine in tabular form
+
++-------------------++-------------------------------------------------+
+| || Event |
+| Prev State ++-------------------------+-----------------------+
+| || JoinDesired | JoinDesired |
+| || (*,*,RP) ->True | (*,*,RP) ->False |
++-------------------++-------------------------+-----------------------+
+| || -> J state | - |
+| NotJoined (NJ) || Send Join(*,*,RP); | |
+| || Set Join Timer to | |
+| || t_periodic | |
++-------------------++-------------------------+-----------------------+
+| Joined (J) || - | -> NJ state |
+| || | Send Prune |
+| || | (*,*,RP); Cancel |
+| || | Join Timer |
++-------------------++-------------------------+-----------------------+
+
+ In addition, we have the following transitions, which occur within
+ the Joined state:
+
++----------------------------------------------------------------------+
+| In Joined (J) State |
++-------------------+--------------------+-----------------------------+
+| Timer Expires | See | See |
+| | Join(*,*,RP) | Prune(*,*,RP) |
+| | to MRIB. | to MRIB. |
+| | next_hop(RP) | next_hop(RP) |
++-------------------+--------------------+-----------------------------+
+| Send | Increase Join | Decrease Join |
+| Join(*,*,RP); | Timer to | Timer to |
+| Set Join Timer | t_joinsuppress | t_override |
+| to t_periodic | | |
++-------------------+--------------------+-----------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 63]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
++----------------------------------------------------------------------+
+| In Joined (J) State |
++-----------------------------------+----------------------------------+
+| NBR(RPF_interface(RP), | MRIB.next_hop(RP) GenID |
+| MRIB.next_hop(RP)) | changes |
+| changes | |
++-----------------------------------+----------------------------------+
+| Send Join(*,*,RP) to new | Decrease Join Timer to |
+| next hop; Send | t_override |
+| Prune(*,*,RP) to old | |
+| next hop; set Join Timer | |
+| to t_periodic | |
++-----------------------------------+----------------------------------+
+
+ This state machine uses the following macro:
+
+ bool JoinDesired(*,*,RP) {
+ if immediate_olist(*,*,RP) != NULL
+ return TRUE
+ else
+ return FALSE
+ }
+
+ JoinDesired(*,*,RP) is true when the router has received (*,*,RP)
+ Joins from any downstream interface. Note that although JoinDesired
+ is true, the router's sending of a Join(*,*,RP) message may be
+ suppressed by another router sending a Join(*,*,RP) onto the upstream
+ interface.
+
+ Transitions from NotJoined State
+
+ When the upstream (*,*,RP) state machine is in NotJoined state, the
+ following event may trigger a state transition:
+
+ JoinDesired(*,*,RP) becomes True
+ The downstream state for (*,*,RP) has changed so that at least
+ one interface is in immediate_olist(*,*,RP), making
+ JoinDesired(*,*,RP) become True.
+
+ The upstream (*,*,RP) state machine transitions to Joined
+ state. Send Join(*,*,RP) to the appropriate upstream
+ neighbor, which is NBR(RPF_interface(RP), MRIB.next_hop(RP)).
+ Set the Join Timer (JT) to expire after t_periodic seconds.
+
+ Transitions from Joined State
+
+ When the upstream (*,*,RP) state machine is in Joined state, the
+ following events may trigger state transitions:
+
+
+
+Fenner, et al. Standards Track [Page 64]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ JoinDesired(*,*,RP) becomes False
+ The downstream state for (*,*,RP) has changed so no interface
+ is in immediate_olist(*,*,RP), making JoinDesired(*,*,RP)
+ become False.
+
+ The upstream (*,*,RP) state machine transitions to NotJoined
+ state. Send Prune(*,*,RP) to the appropriate upstream
+ neighbor, which is NBR(RPF_interface(RP), MRIB.next_hop(RP)).
+ Cancel the Join Timer (JT).
+
+ Join Timer Expires
+ The Join Timer (JT) expires, indicating time to send a
+ Join(*,*,RP)
+
+ Send Join(*,*,RP) to the appropriate upstream neighbor, which
+ is NBR(RPF_interface(RP), MRIB.next_hop(RP)). Restart the
+ Join Timer (JT) to expire after t_periodic seconds.
+
+ See Join(*,*,RP) to MRIB.next_hop(RP)
+ This event is only relevant if RPF_interface(RP) is a shared
+ medium. This router sees another router on RPF_interface(RP)
+ send a Join(*,*,RP) to NBR(RPF_interface(RP),
+ MRIB.next_hop(RP)). This causes this router to suppress its
+ own Join.
+
+ The upstream (*,*,RP) 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(*,*,RP) to MRIB.next_hop(RP)
+ This event is only relevant if RPF_interface(RP) is a shared
+ medium. This router sees another router on RPF_interface(RP)
+ send a Prune(*,*,RP) to NBR(RPF_interface(RP),
+ MRIB.next_hop(RP)). As this router is in Joined state, it
+ must override the Prune after a short random interval.
+
+ The upstream (*,*,RP) 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 65]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ NBR(RPF_interface(RP), MRIB.next_hop(RP)) changes
+ A change in the MRIB routing base causes the next hop towards
+ the RP to change.
+
+ The upstream (*,*,RP) state machine remains in Joined state.
+ Send Join(*,*,RP) to the new upstream neighbor, which is the
+ new value of NBR(RPF_interface(RP), MRIB.next_hop(RP)). Send
+ Prune(*,*,RP) to the old upstream neighbor, which is the old
+ value of NBR(RPF_interface(RP), MRIB.next_hop(RP)). Set the
+ Join Timer (JT) to expire after t_periodic seconds.
+
+ MRIB.next_hop(RP) GenID changes
+ The Generation ID of the router that is MRIB.next_hop(RP)
+ changes. This normally means that this neighbor has lost
+ state, and so the state must be refreshed.
+
+ The upstream (*,*,RP) 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.6. 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.
+
+
+
+
+Fenner, et al. Standards Track [Page 66]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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).
+
+ Figure 7: Upstream (*,G) state machine in tabular form
+
++-------------------++-------------------------------------------------+
+| || 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 | | | |
++----------------+-----------------+-----------------+-----------------+
+
+
+
+
+Fenner, et al. Standards Track [Page 67]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
++----------------------------------------------------------------------+
+| 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 | |
++----------------------------------+-----------------------------------+
+
+ This state machine uses the following macro:
+
+ bool JoinDesired(*,G) {
+ if (immediate_olist(*,G) != NULL OR
+ (JoinDesired(*,*,RP(G)) AND
+ AssertWinner(*, G, RPF_interface(RP(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 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.
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 68]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 NotJoined
+ state. Send Prune(*,G) to the appropriate upstream neighbor,
+ which is RPF'(*,G). Cancel the Join Timer (JT).
+
+ 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 69]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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 spec). 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.
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 70]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+4.5.7. 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.
+
+ If a (S,G) Assert occurs on the upstream interface, and this changes
+ the this router's idea of the upstream neighbor, it should be
+ prepared to 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).
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 71]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Figure 8: Upstream (S,G) state machine in tabular form
+
++-------------------+--------------------------------------------------+
+| | 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 |
++-------------------+-------------------------+------------------------+
+
+ 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 | | | |
++-----------------+-----------------+-----------------+----------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 72]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
++----------------------------------------------------------------------+
+| 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.
+
+ 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 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.
+
+
+
+
+Fenner, et al. Standards Track [Page 73]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 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.
+
+ 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.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 74]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 75]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+4.5.8. (S,G,rpt) Periodic Messages
+
+ (S,G,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP
+ tree 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 76]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+4.5.9. State Machine for (S,G,rpt) Triggered Messages
+
+ The state machine for (S,G,rpt) triggered messages is required per-
+ (S,G) when there is (*,G) or (*,*,RP) join state at a router, and the
+ router or any of its upstream LAN peers wishes to prune S off the RP
+ tree.
+
+ There are three states in the state machine. One of the states is
+ when there is neither (*,G) nor (*,*,RP(G)) join state at this
+ router. If there is (*,G) or (*,*,RP(G)) join state at the router,
+ then the state machine must be at one of the other two states. The
+ three states are:
+
+ Pruned(S,G,rpt)
+ (*,G) or (*,*,RP(G)) Joined, but (S,G,rpt) pruned
+
+ NotPruned(S,G,rpt)
+ (*,G) or (*,*,RP(G)) Joined, and (S,G,rpt) not pruned
+
+ RPTNotJoined(G)
+ neither (*,G) nor (*,*,RP(G)) has 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 77]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Figure 9: Upstream (S,G,rpt) state machine for triggered messages
+ in tabular form
+
++------------++--------------------------------------------------------+
+| || 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 | | | |
++------------++--------------+--------------+-------------+------------+
+
+ 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).
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 78]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ This state machine uses the following macros:
+
+ bool RPTJoinDesired(G) {
+ return (JoinDesired(*,G) OR JoinDesired(*,*,RP(G)))
+ }
+
+ RPTJoinDesired(G) is true when the router has forwarding state that
+ would cause it to forward traffic for G using either (*,G) or
+ (*,*,RP) 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).
+
+ 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.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 79]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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
+ noone 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 RFC2362 that don't maintain separate (S,G) and
+ (S,G,rpt) state.
+
+ 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) or (*,*,RP(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 noone
+ 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.
+
+
+
+Fenner, et al. Standards Track [Page 80]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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) or Join(*,*,RP).
+
+ 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) or (*,*,RP).
+
+ 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) or
+ (*,*,RP) 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 81]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+4.5.10. Background: (*,*,RP) and (S,G,rpt) Interaction
+
+ In Sections 4.5.8 and 4.5.9, the mechanisms for sending periodic and
+ triggered (S,G,rpt) messages are described. The astute reader will
+ note that periodic Prune(S,G,rpt) messages are only sent in PIM
+ Join/Prune messages containing a Join(*,G), whereas it is possible
+ for a triggered Prune(S,G,rpt) message to be sent when the router has
+ no (*,G) join state. This may seem like a contradiction, but in fact
+ it is intentional and is a side effect of not optimizing (*,*,RP)
+ behavior.
+
+ We first note that reception of a Join(*,*,RP) by itself does not
+ cancel (S,G,rpt) prune state on that interface, whereas receiving a
+ Join(*,G) by itself does cancel (S,G,rpt) prune state on that
+ interface. Similarly, reception of a Prune(*,G) on an interface with
+ (*,*,RP) join state does not by itself prevent forwarding of G using
+ the (*,*,RP) state; this is because a Prune(*,G) only serves to
+ cancel (*,G) join state. Conceptually (*,*,RP) state functions
+ "above" the normal (*,G) and (S,G) mechanisms, and so neither
+ Join(*,*,RP) nor Prune(*,*,RP) messages affect any other state.
+
+ The upshot of this is that to prevent forwarding (S,G) on (*,*,RP)
+ state, a Prune(S,G,rpt) must be used.
+
+ We also note that for historical reasons there is no Assert(*,*,RP)
+ message, so any forwarding contention is resolved using Assert(*,G)
+ messages.
+
+ We now need to consider the interaction between (*,*,RP) state and
+ (*,G) state. If there is a need for an assert between two upstream
+ routers on a LAN, we need to ensure that the correct thing happens
+ for all combinations of (*,*,RP) and (*,G) forwarding state. As
+ there is no Assert(*,*,RP) message, no router can tell whether the
+ assert winner has (*,*,RP) state or (*,G) state. Thus, a downstream
+ router has to treat the two the same and send its periodic
+ Prune(S,G,rpt) messages to RPF'(*,G).
+
+ To avoid needing to specify all the complex override rules between
+ (*,*,RP), (*,G), and (S,G,rpt), we simply require that to prune (S,G)
+ off the (*,*,RP) tree, a Join(*,G) must also be sent.
+
+ If a router is receiving on (*,*,RP) state and has not yet had (*,G)
+ state instantiated, it may still need to send a triggered
+ Join(S,G,rpt) to override a Prune(S,G,rpt) that it sees directed to
+ RPF'(*,G) on its upstream interface. Hence, triggered (S,G,rpt)
+ messages may be sent when JoinDesired(*,G) is false but
+ JoinDesired(*,*,RP) is true.
+
+
+
+
+Fenner, et al. Standards Track [Page 82]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Finally, we note that there is an unoptimized case when the upstream
+ router on a LAN already has (*,G) join and (S,G,rpt) prune state
+ caused by an existing downstream router. If at this time a new
+ Join(*,*,RP) is sent to the upstream router from a different
+ downstream router, this will not override the (S,G,rpt) prune state
+ at the upstream router. The override will not occur until the next
+ time the original downstream router resends its Prune(S,G,rpt). This
+ case was not considered worth optimizing, as (*,*,RP) state is
+ generally very long lived, and so any minor delays in getting traffic
+ to a new PMBR seem unimportant.
+
+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.
+
+ In general, a PIM Assert message should only be accepted for
+ processing if it comes from a known PIM neighbor. A PIM router hears
+ about PIM neighbors through PIM Hello messages. If a router receives
+ an Assert message from a particular IP source address and it has not
+ seen a PIM Hello message from that source address, then the Assert
+ message SHOULD be discarded without further processing. In addition,
+ if the Hello message from a neighbor was authenticated using the
+ IPsec Authentication Header (AH) (see Section 6.3), then all Assert
+ messages from that neighbor MUST also be authenticated using IPsec
+ AH.
+
+ We note that some older PIM implementations incorrectly fail to send
+ Hello messages on point-to-point interfaces, so we also RECOMMEND
+ that a configuration option be provided to allow interoperation with
+ such older routers, but that this configuration option SHOULD NOT be
+ enabled by default.
+
+4.6.1. (S,G) Assert Message State Machine
+
+ The (S,G) Assert state machine for interface I is shown in Figure 10.
+ There are three states:
+
+ NoInfo (NI)
+ This router has no (S,G) assert state on interface I.
+
+
+
+Fenner, et al. Standards Track [Page 83]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ Figure 10: Per-interface (S,G) Assert State machine in tabular form
+
++----------------------------------------------------------------------+
+| 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 |
+| and | (S,G,I) | (S,G,I) | and AssTrDes |
+| CouldAssert | | | (S,G,I) |
+| (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] |
++----------------+------------------+-----------------+----------------+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 84]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
++---------------------------------------------------------------------+
+| 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] |
++-------------+-------------+-------------+-------------+-------------+
+
++----------------------------------------------------------------------+
+| 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.
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 85]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ The state machine uses the following macros:
+
+CouldAssert(S,G,I) =
+ SPTbit(S,G)==TRUE
+ AND (RPF_interface(S) != I)
+ AND (I in ( ( joins(*,*,RP(G)) (+) 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.
+
+ AssertTrackingDesired(S,G,I) =
+ (I in ( ( joins(*,*,RP(G)) (+) 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 our behavior.
+
+ 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.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 86]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ Transitions from NoInfo State
+
+ When in NoInfo state, the following events may trigger transitions:
+
+ Receive Inferior Assert with RPTbit cleared AND
+ CouldAssert(S,G,I)==TRUE
+ 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 beat (*,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's 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 an 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 87]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 88]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 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.
+
+ 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
+ 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.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 89]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 info (AssertWinner(S,G,I) and
+ AssertWinnerMetric(S,G,I) will then return their default
+ values).
+
+ A5: Delete assert info (AssertWinner(S,G,I) and
+ AssertWinnerMetric(S,G,I) will then return 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) == true)
+ 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.
+
+
+
+Fenner, et al. Standards Track [Page 90]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+4.6.2. (*,G) Assert Message State Machine
+
+ The (*,G) Assert state machine for interface I is shown in Figure 11.
+ 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 an (*,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 an (*,G) assert on interface I. It must not
+ forward packets for G onto interface I with the exception of
+ traffic from sources for which is has (S,G) "I am Assert Winner"
+ state. If it is the DR, it is no longer responsible for handling
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 91]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ Figure 11: Per-interface (*,G) Assert State machine in tabular form
+
++----------------------------------------------------------------------+
+| 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] |
++----------------+-----------------+-----------------+----------------+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 92]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
++---------------------------------------------------------------------+
+| 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] |
++-------------+-------------+-------------+-------------+-------------+
+
++----------------------------------------------------------------------+
+| In I Am Assert Loser (L) State |
++----------------+----------------+-----------------+------------------+
+| AssTrDes | my_metric -> | RPF_interface | Receive |
+| (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) or |
+| FALSE | Winner's | being I | Join |
+| | metric | | (*,*,RP(G)) on |
+| | | | Interface I |
++----------------+----------------+-----------------+------------------+
+| -> 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(*,*,RP(G)) (+) joins(*,G)
+ (+) pim_include(*,G)) )
+ AND (RPF_interface(RP(G)) != I)
+
+ CouldAssert(*,G,I) is true on downstream interfaces for which we have
+ (*,*,RP(G)) or (*,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 an
+ (*,G) assert might affect our behavior.
+
+
+
+
+Fenner, et al. Standards Track [Page 93]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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 94]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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).
+
+ 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 95]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 info (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 it no longer knows it was the winner. We
+ transition to the NoInfo state, deleting the (*,G) assert
+ information (Actions A5).
+
+ 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 info (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 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.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 96]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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) or Join(*,*,RP(G)) on interface I
+ We receive a Join(*,G) or a Join(*,*,RP(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).
+
+ A4: Send AssertCancel(*,G).
+ Delete assert info (AssertWinner(*,G,I) and
+ AssertWinnerMetric(*,G,I) will then return their default
+ values).
+
+ A5: Delete assert info (AssertWinner(*,G,I) and
+ AssertWinnerMetric(*,G,I) will then return 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 97]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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 field 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()
+ }
+ }
+
+ 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)}
+ }
+
+
+
+
+Fenner, et al. Standards Track [Page 98]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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() gives the assert metric we need to send an
+ assert but don't 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
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 99]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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 SPT bit. 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 )
+ }
+ }
+
+ 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.
+
+
+
+
+Fenner, et al. Standards Track [Page 100]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 to 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.
+
+ 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.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 101]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 cancels 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) or a
+ Join(*,*,RP(G)) with an Upstream Neighbor Address that is its
+ primary IP address on that interface cancels 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.
+
+ 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).
+
+
+
+Fenner, et al. Standards Track [Page 102]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 [17].
+
+ Cisco's Auto-RP
+ Auto-RP uses a PIM Dense-Mode 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, and 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 bootstrap router (BSR). Any router in the domain
+ that is configured to be a possible RP reports its candidacy to
+
+
+
+Fenner, et al. Standards Track [Page 103]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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, BSR is flawed in its handling of admin-scoped
+ regions that are smaller than a PIM domain, but the mechanism
+ does work for global-scoped groups.
+
+ As far as PIM-SM is concerned, the only important requirement is that
+ 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 BSR. 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 one with highest
+ priority. Eliminate any RPs from the list that have lower
+ priorities.
+
+ 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
+
+
+
+Fenner, et al. Standards Track [Page 104]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ RP. It is invoked by any router that has (*,*,RP) state when a
+ packet is received for which there is no corresponding (S,G) or (*,G)
+ entry. Furthermore, the mapping function is invoked by all routers
+ upon receiving a (*,G) or (*,*,RP) 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 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.
+
+ 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.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 105]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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, we recommend
+ using 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 ^ 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.
+
+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.
+
+
+
+
+Fenner, et al. Standards Track [Page 106]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ The last two rules are present to deal with "legacy" routers unaware
+ of SSM that may be sending (*,G) and (S,G,rpt) Join/Prunes, or
+ Register messages for SSM destination addresses.
+
+ Additionally:
+
+ o A router MAY be configured to advertise itself as a Candidate RP
+ for an SSM address. If so, it SHOULD respond with a Register-Stop
+ message to any Register message containing a packet destined for an
+ SSM address.
+
+ 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.
+
+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.7)
+
+ o Downstream (S,G) state machine (Section 4.5.3)
+
+ o (S,G) Assert state machine (Section 4.6.1)
+
+ 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), (S,G,rpt), and (*,*,RP) Downstream state machines (Sections
+ 4.5.2, 4.5.4, and 4.5.1)
+
+ o (*,G), (S,G,rpt), and (*,*,RP) Upstream state machines (Sections
+ 4.5.6, 4.5.8, and 4.5.5)
+
+ o (*,G) Assert state machine (Section 4.6.2)
+
+ o Bootstrap RP Election (Section 4.7)
+
+
+
+
+Fenner, et al. Standards Track [Page 107]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ o Keepalive Timer
+
+ o SPTbit (Section 4.2.2)
+
+ The Keepalive Timer should be treated as always running, and 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:
+
+ 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.
+
+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, etc.). 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'.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 108]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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
+
+ 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.
+
+
+
+
+Fenner, et al. Standards Track [Page 109]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 though
+ 255 are designated for private use. As there is no assignment
+ authority for this space, collisions should be expected.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 110]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 the group range should use Bidirectional PIM [13].
+ For PIM-SM defined in this specification, this bit MUST be zero.
+
+ Reserved
+ Transmitted as zero. Ignored upon receipt.
+
+ Admin Scope [Z]one
+ indicates the group range is an admin scope zone. This is used
+ in the Bootstrap Router Mechanism [11] only. For all other
+ purposes, this bit is set to zero and ignored on receipt.
+
+ 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.
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 111]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Encoded-Source Address
+
+ 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.
+
+ Mask Len
+ The mask length field is 8 bits. The value is the number of
+ contiguous one bits left justified used as a mask which,
+ combined with the Source Address, 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.
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 112]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+4.9.2. Hello Message Format
+
+ It 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 113]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+ 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 joins 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.
+ Section 4.3.3 describes how these values affect the behavior of a
+ router.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 114]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ o OptionType 3 to 16: reserved to be defined in future versions of
+ this document.
+
+ o OptionType 18: deprecated and should not be used.
+
+ o OptionType 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 115]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 or a PMBR 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 116]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 pseudoheader
+ "Upper-Layer Packet Length" is set to 8.
+
+ B The Border bit. If the router is a DR for a source that it is
+ directly connected to, it sets the B bit to 0. If the router is
+ a PMBR for a source in a directly connected cloud, it sets the B
+ bit to 1.
+
+ 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, 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 117]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 118]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ PIM Version, Type, Reserved, Checksum
+ Described in Section 4.9.
+
+ Group Address
+ The group address from the multicast data packet in the
+ Register. Format described in Section 4.9.1. Note that for
+ Register-Stops the Mask Len field contains the full address
+ length * 8 (e.g., 32 for 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 wild card
+ 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 119]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 120]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ PIM Version, Type, Reserved, Checksum
+ Described in Section 4.9.
+
+ Unicast Upstream Neighbor Address
+ The 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. For IPv6 the source address
+ used for multicast messages is the link-local address of the
+ interface on which the message is being sent. For IPv4, the
+ source address is the primary address associated with that
+ interface.
+
+ 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 Encoded-Source-Address format in Section 4.9.1.
+
+ Number of Pruned Sources
+ Number of pruned source addresses listed for a group.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 121]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 are two valid group set types:
+
+ Wildcard Group Set
+ The wildcard group set is represented by the entire multicast
+ range: the beginning of the multicast address range in the
+ group address field and the prefix length of the multicast
+ address range in the mask length field of the Multicast Group
+ Address (i.e., '224.0.0.0/4' for IPv4 or 'ff00::/8' for IPv6).
+ Each Join/Prune message SHOULD contain at most one wildcard
+ group set. Each wildcard group set may contain one or more
+ (*,*,RP) source list entries in either the Joined or Pruned
+ lists.
+
+ A (*,*,RP) source list entry may only exist in a wildcard group
+ set. When added to a Joined source list, this type of source
+ entry expresses the router's interest in receiving traffic for
+ all groups mapping to the specified RP. When added to a Pruned
+ source list a (*,*,RP) entry expresses the router's interest to
+ stop receiving such traffic. Note that as indicated by the
+ Join/Prune state machines, such a Join or Prune will NOT
+ override Join/Prune state created using a Group-Specific Set
+ (see below).
+
+
+
+
+Fenner, et al. Standards Track [Page 122]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ (*,*,RP) source list entries have the Source-Address set to the
+ address of the RP, the Source-Address Mask-Len set to the full
+ length of the IP address, and both the WC and RPT bits of the
+ Source-Address set to 1.
+
+ 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 Rendezvous-Point shared tree. There may
+ 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.
+
+ (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 may 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 may exist in only one of the Joined
+ and Pruned source lists of a group-specific set, but not both.
+
+
+
+Fenner, et al. Standards Track [Page 123]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ (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 a (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) Prunes and (S,G,rpt) Prunes.
+
+ o The combination of a (*,G) Prune and a (S,G,rpt) Join is also not
+ generated. (S,G,rpt) Joins are only sent when the router is
+ receiving 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.
+
+ o As Join/Prune messages are targeted to a single PIM neighbor,
+ including both a (S,G) Join and a (S,G,rpt) Prune in the same
+ message 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 a (S,G) Prune and a (S,G,rpt) Join could
+ possibly be used by a router to switch from receiving a particular
+ source on 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.
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 124]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ The rules are summarized in the tables 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) || | | | | | |
+ +----------++------+-------+-----------+-----------+-------+-------+
+
+ +---------------++--------------+----------------+------------+
+ | ||Join (*,*,RP) | Prune (*,*,RP) | all others |
+ +---------------++--------------+----------------+------------+
+ |Join (*,*,RP) ||- | no | yes |
+ +---------------++--------------+----------------+------------+
+ |Prune (*,*,RP) ||no | - | yes |
+ +---------------++--------------+----------------+------------+
+ |all others ||yes | yes | see above |
+ +---------------++--------------+----------------+------------+
+
+ 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.
+
+
+
+
+Fenner, et al. Standards Track [Page 125]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 126]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 Encoded-Unicast-Address in Section 4.9.1.
+
+ R RPT-bit is a 1-bit value. The RPT-bit is set to 1 for
+ Assert(*,G) 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.
+
+ Assert messages can be sent to resolve a forwarding conflict for all
+ traffic to a given group or for a specific source and group.
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 127]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 RPT-bit
+ 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 RPT-bit is set to 1,
+ the Metric-Preference is set to MRIB.pref(RP(G)), and the Metric
+ is set to MRIB.metric(RP(G)).
+
+4.10. PIM Timers
+
+ PIM-SM maintains the following timers, as discussed in Section 4.1.
+ All timers are countdown timers; they are set to a value and count
+ down to 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.
+
+ Global Timers
+
+ Per interface (I):
+
+ Hello Timer: HT(I)
+
+ Per neighbor (N):
+
+ Neighbor Liveness Timer: NLT(N,I)
+
+ Per active RP (RP):
+
+ (*,*,RP) Join Expiry Timer: ET(*,*,RP,I)
+
+ (*,*,RP) Prune-Pending Timer: PPT(*,*,RP,I)
+
+ Per Group (G):
+
+ (*,G) Join Expiry Timer: ET(*,G,I)
+
+
+
+
+Fenner, et al. Standards Track [Page 128]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ (*,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 active RP (RP):
+
+ (*,*,RP) Upstream Join Timer: JT(*,*,RP)
+
+ 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)
+
+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.
+
+
+
+
+Fenner, et al. Standards Track [Page 129]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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. |
++--------------------------+-----------------+-------------------------+
+
+ 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. |
++---------------------+--------+---------------------------------------+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 130]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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(*,*,RP,I), 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 |
++----------------+----------------+------------------------------------+
+
+ See details of JT(*,G) for the Holdtime that is included in
+ Join/Prune Messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 131]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Timer Names: Prune-Pending Timer (PPT(*,*,RP,I), 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 |
+| | EffectiveOverride_ | to override the |
+| | Interval(I) | join or prune |
++--------------------------+---------------------+---------------------+
+
+ Note that both the Effective_Propagation_Delay(I) and the
+ 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 132]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Timer Names: Upstream Join Timer (JT(*,*,RP), 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 133]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ Timer Name: Upstream Override Timer (OT(S,G,rpt))
+
++---------------+--------------------------+---------------------------+
+| Value Name | Value | Explanation |
++---------------+--------------------------+---------------------------+
+| t_override | see Upstream Join Timer | see Upstream Join Timer |
++---------------+--------------------------+---------------------------+
+
+ The upstream Override Timer is only ever set to t_override; this
+ value is defined in the section on Upstream Join Timers.
+
+ Timer Name: Keepalive Timer (KAT(S,G))
+
++-----------------------+-----------------------+----------------------+
+| 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 134]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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 are
+ configured to values other than the defaults, it MUST be ensured that
+ the value of the Register_Probe_Time is less than half the value of
+ the Register_Suppression_Time to prevent a possible negative value in
+ the setting of the Register-Stop Timer.
+
+5. IANA Considerations
+
+5.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
+
+
+
+Fenner, et al. Standards Track [Page 135]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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].)
+
+6. Security Considerations
+
+ This section describes various possible security concerns related to
+ the PIM-SM protocol, including a description of how to use IPsec to
+ secure the protocol. The reader is referred to [15] and [16] for
+ further discussion of PIM-SM and multicast security. The IPsec
+ authentication header [8] MAY be used to provide data integrity
+ protection and groupwise data origin authentication of PIM protocol
+ messages. Authentication of PIM messages can protect against
+ unwanted behaviors caused by unauthorized or altered PIM messages.
+
+6.1. Attacks Based on Forged Messages
+
+ The extent of possible damage depends on the type of counterfeit
+ messages accepted. We next consider the impact of possible
+ forgeries, including forged link-local (Join/Prune, Hello, and
+ Assert) and forged unicast (Register and Register-Stop) messages.
+
+6.1.1. Forged Link-Local Messages
+
+ Join/Prune, Hello, and Assert messages are all sent to the link-local
+ ALL_PIM_ROUTERS multicast addresses and thus are not forwarded by a
+ compliant router. A forged message of this type can only reach a LAN
+ if it was sent by a local host or if it was allowed onto the LAN by a
+ compromised or non-compliant router.
+
+ 1. A forged Join/Prune message can cause multicast traffic to be
+ delivered to links where there are no legitimate 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
+
+
+
+Fenner, et al. Standards Track [Page 136]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ local members. The designated router is also responsible for
+ register-encapsulating to the RP any packets that are originated
+ by hosts on the LAN. Thus, the ability of local hosts to send
+ and receive multicast traffic may be compromised by a forged
+ Hello message.
+
+ 3. By forging an Assert message on a multi-access LAN, an attacker
+ could cause the legitimate designated forwarder to stop
+ forwarding traffic to the LAN. Such a forgery would prevent any
+ hosts downstream of that LAN from receiving traffic.
+
+6.1.2. Forged Unicast Messages
+
+ Register messages and Register-Stop messages are 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 consider the effect of a forgery of each of these
+ messages next.
+
+ 1. By forging a Register message, an attacker can cause the RP to
+ inject forged traffic onto the shared multicast tree.
+
+ 2. By forging a Register-stop message, an attacker can prevent a
+ legitimate DR from Registering packets to the RP. This can
+ prevent local hosts on that LAN from sending multicast packets.
+
+ The above two PIM messages are not changed by intermediate routers
+ and need only be examined by the intended receiver. Thus, these
+ messages can be authenticated end-to-end, using AH. 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.
+
+
+
+
+Fenner, et al. Standards Track [Page 137]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ 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.
+
+6.3. Authentication Using IPsec
+
+ The IPsec [8] transport mode using the Authentication Header (AH) is
+ the recommended method to prevent the above attacks against PIM. The
+ specific AH authentication algorithm and parameters, including the
+ choice of authentication algorithm and the choice of key, are
+ configured by the network administrator. When IPsec authentication
+ is used, a PIM router should reject (drop without processing) any
+ unauthorized PIM protocol messages.
+
+ To use IPsec, the administrator of a PIM network configures each PIM
+ router with one or more security associations (SAs) and associated
+ Security Parameter Indexes (SPIs) that are used by senders to
+ authenticate PIM protocol messages and are used by receivers to
+ authenticate received PIM protocol messages. This document does not
+ describe protocols for establishing SAs. It assumes that manual
+ configuration of SAs is performed, but it does not preclude the use
+ of a negotiation protocol such as the Internet Key Exchange [14] to
+ establish SAs.
+
+ IPsec [8] provides protection against replayed unicast and multicast
+ messages. The anti-replay option for IPsec SHOULD be enabled on all
+ SAs.
+
+ The following sections describe the SAs required to protect PIM
+ protocol messages.
+
+6.3.1. Protecting Link-Local Multicast Messages
+
+ The network administrator defines an SA and SPI that are to be used
+ to authenticate all link-local PIM protocol messages (Hello,
+ Join/Prune, and Assert) on each link in a PIM domain.
+
+ IPsec [8] allows (but does not require) different Security Policy
+ Databases (SPD) for each router interface. If available, it may be
+ desirable to configure the Security Policy Database at a PIM router
+ such that all incoming and outgoing Join/Prune, Assert, and Hello
+ packets use a different SA for each incoming or outgoing interface.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 138]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+6.3.2. Protecting Unicast Messages
+
+ IPsec can also be used to provide data origin authentication and data
+ integrity protection for the Register and Register-Stop unicast
+ messages.
+
+6.3.2.1. Register Messages
+
+ The Security Policy Database at every PIM router is configured to
+ select an SA to use when sending PIM Register packets to each
+ rendezvous point.
+
+ In the most general mode of operation, the Security Policy Database
+ at each DR is configured to select a unique SA and SPI for traffic
+ sent to each RP. This allows each DR to have a different
+ authentication algorithm and key to talk to the RP. However, this
+ creates a daunting key management and distribution problem for the
+ network administrator. Therefore, it may be preferable in PIM
+ domains where all Designated Routers are under a single
+ administrative control that the same authentication algorithm
+ parameters (including the key) be used for all Registered packets in
+ a domain, regardless of who are the RP and the DR.
+
+ In this "single shared key" mode of operation, the network
+ administrator must choose an SPI for each DR that will be used to
+ send it PIM protocol packets. The Security Policy Database at every
+ DR is configured to select an SA (including the authentication
+ algorithm, authentication parameters, and this SPI) when sending
+ Register messages to this RP.
+
+ By using a single authentication algorithm and associated parameters,
+ the key distribution problem is simplified. Note, however, that this
+ method has the property that, in order to change the authentication
+ method or authentication key used, all routers in the domain must be
+ updated.
+
+6.3.2.2. Register-Stop Messages
+
+ Similarly, the Security Policy Database at each Rendezvous Point
+ should be configured to choose an SA to use when sending Register-
+ Stop messages. Because Register-Stop messages are unicast to the
+ destination DR, a different SA and a potentially unique SPI are
+ required for each DR.
+
+ In order to simplify the management problem, it may be acceptable to
+ use the same authentication algorithm and authentication parameters,
+ regardless of the sending RP and regardless of the destination DR.
+ Although a unique SA is needed for each DR, the same authentication
+
+
+
+Fenner, et al. Standards Track [Page 139]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ algorithm and authentication algorithm parameters (secret key) can be
+ shared by all DRs and by all RPs.
+
+6.4. Denial-of-Service Attacks
+
+ There are a number of possible denial-of-service attacks against PIM
+ that can be caused by generating false PIM protocol messages or even
+ by generating data false traffic. Authenticating PIM protocol
+ traffic prevents some, but not all, of these attacks. Three of the
+ possible attacks include:
+
+ - Sending packets to many different group addresses quickly can be a
+ denial-of-service attack in and of itself. This will cause many
+ register-encapsulated packets, loading the DR, the RP, and the
+ routers between the DR and the RP.
+
+ - Forging Join messages can cause a multicast tree to get set up. A
+ large number of forged joins can consume router resources and
+ result in denial of service.
+
+ - Forging a (*,*,RP) join presents a possibility for a denial-of-
+ service attack by causing all traffic in the domain to flow to the
+ PMBR issuing the join. (*,*,RP) behavior is included here
+ primarily for backwards compatibility with prior revisions of the
+ spec. However, the implementation of (*,*,RP) and PMBR is
+ optional. When using (*,*,RP), the security concerns should be
+ carefully considered.
+
+7. 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.
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 140]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+8. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+ Thyagarajan, "Internet Group Management Protocol, Version 3",
+ RFC 3376, October 2002.
+
+ [3] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
+ 1112, August 1989.
+
+ [4] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
+ Discovery (MLD) for IPv6", RFC 2710, October 1999.
+
+ [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+ Specification", RFC 2460, December 1998.
+
+ [6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
+ RFC 4507, August 2006.
+
+ [7] IANA, "Address Family Numbers",
+ <http://www.iana.org/assignments/address-family-numbers>.
+
+ [8] Kent, S. and K. Seo, "Security Architecture for the Internet
+ Protocol", RFC 4301, December 2005.
+
+ [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+9. Informative References
+
+ [10] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol
+ Extensions for BGP-4", RFC 2858, June 2000.
+
+ [11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap
+ Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress,
+ May 2006.
+
+ [12] Black, D., "Differentiated Services and Tunnels", RFC 2983,
+ October 2000.
+
+ [13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-
+ directional Protocol Independent Multicast", Work in Progress,
+ October 2005.
+
+ [14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
+ December 2005.
+
+
+
+Fenner, et al. Standards Track [Page 141]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ [15] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
+ Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
+ Issues and Enhancements", RFC 4609, August 2006.
+
+ [16] Savola, P. and J. Lingard, "Last-hop Threats to Protocol
+ Independent Multicast (PIM)", Work in Progress, January 2005.
+
+ [17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
+ Address in an IPv6 Multicast Address", RFC 3956, November 2004.
+
+ [18] Thaler, D., "Interoperability Rules for Multicast Routing
+ Protocols", RFC 2715, October 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 142]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+Appendix A. PIM Multicast Border Router Behavior
+
+ In some cases, PIM-SM domains will interconnect with non-PIM
+ multicast domains. In these cases, the border routers of the PIM
+ domain speak PIM-SM on some interfaces and speak other multicast
+ routing protocols on other interfaces. Such routers are termed PIM
+ Multicast Border Routers (PMBRs). In general, RFC 2715 [18] provides
+ rules for interoperability between different multicast routing
+ protocols. In this appendix, we specify how PMBRs differ from
+ regular PIM-SM routers.
+
+ From the point of view of PIM-SM, a PMBR has two tasks:
+
+ o To ensure that traffic from sources outside the PIM-SM domain
+ reaches receivers inside the domain.
+
+ o To ensure that traffic from sources inside the PIM-SM domain
+ reaches receivers outside the domain.
+
+ We note that multiple PIM-SM domains are sometimes connected together
+ using protocols such as Multicast Source Discovery Protocol (MSDP),
+ which provides information about active external sources, but does
+ not follow RFC 2715. In such cases, the domains are not connected
+ via PMBRs because Join(S,G) messages traverse the border between
+ domains. A PMBR is required when no PIM messages can traverse the
+ border.
+
+A.1. Sources External to the PIM-SM Domain
+
+ A PMBR needs to ensure that traffic from multicast sources external
+ to the PIM-SM domain reaches receivers inside the domain. The PMBR
+ will follow the rules in RFC 2715, such that traffic from external
+ sources reaches the PMBR itself.
+
+ According to RFC 2715, the PIM-SM component of the PMBR will receive
+ an (S,G) Creation event when data from an (S,G) data packet from an
+ external source first reaches the PMBR. If RPF_interface(S) is an
+ interface in the PIM-SM domain, the packet cannot be originated into
+ the PIM domain at this router, and the PIM-SM component of the PMBR
+ will not process the packet. Otherwise, the PMBR will then act
+ exactly as if it were the DR for this source (see Section 4.4.1),
+ with the following modifications:
+
+ o The Border-bit is set in all PIM Register messages sent for these
+ sources.
+
+ o DirectlyConnected(S) is treated as being TRUE for these sources.
+
+
+
+
+Fenner, et al. Standards Track [Page 143]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ o The PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to
+ be TRUE if iif is any interface that is not part of the PIM-SM
+ component of the PMBR (see Section 4.2).
+
+A.2. Sources Internal to the PIM-SM Domain
+
+ A PMBR needs to ensure that traffic from sources inside the PIM-SM
+ domain reaches receivers outside the domain. Using terminology from
+ RFC 2715, there are two possible scenarios for this:
+
+ o Another component of the PMBR is a wildcard receiver. In this
+ case, the PIM-SM component of the PMBR must ensure that traffic
+ from all internal sources reaches the PMBR until it is informed
+ otherwise.
+
+ Note that certain profiles of PIM-SM (e.g., PIM-SSM, PIM-SM with
+ Embedded RP) cannot interoperate with a neighboring wildcard
+ receiver domain.
+
+ o No other component of the PMBR is a wildcard receiver. In this
+ case the PMBR will receive explicit information as to which groups
+ or (source,group) pairs the external domains wish to receive.
+
+ In the former case, the PMBR will need to send a Join(*,*,RP) to all
+ the active RPs in the PIM-SM domain. It may also send a Join(*,*,RP)
+ to all the candidate RPs in the PIM-SM domain. This will cause all
+ traffic in the domain to reach the PMBR. The PMBR may then act as if
+ it were a DR with directly connected receivers and trigger the
+ transition to a shortest path tree (see Section 4.2.1).
+
+ In the latter case, the PMBR will not need to send Join(*,*,RP)
+ messages. However, the PMBR will still need to act as a DR with
+ directly connected receivers on behalf of the external receivers in
+ terms of being able to switch to the shortest-path tree for
+ internally-reached sources.
+
+ According to RFC 2715, the PIM-SM component of the PMBR may receive a
+ number of alerts generated by events in the external routing
+ components. To implement the above behavior, one reasonable way to
+ map these alerts into PIM-SM state is as follows:
+
+ o When a PIM-SM component receives an (S,G) Prune alert, it sets
+ local_receiver_include(S,G,I) to FALSE for the discard interface.
+
+ o When a PIM-SM component receives a (*,G) Prune alert, it sets
+ local_receiver_include(*,G,I) to FALSE for the discard interface.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 144]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ o When a PIM-SM component receives an (S,G) Join alert, it sets
+ local_receiver_include(S,G,I) to TRUE for the discard interface.
+
+ o When a PIM-SM component receives a (*,G) Join alert, it sets
+ local_receiver_include(*,G,I) to TRUE for the discard interface.
+
+ o When a PIM-SM component receives a (*,*) Join alert, it sets
+ DownstreamJPState(*,*,RP,I) to Join state on the discard interface
+ for all RPs in the PIM-SM domain.
+
+ o When a PIM-SM component receives a (*,*) Prune alert, it sets
+ DownstreamJPState(*,*,RP,I) to NoInfo state on the discard
+ interface for all RPs in the PIM-SM domain.
+
+ We refer above to the discard interface because the macros and state
+ machines are interface specific, but we need to have PIM state that
+ is not associated with any actual PIM-SM interface. Implementers are
+ free to implement this in any reasonable manner.
+
+ Note that these state changes will then cause additional PIM-SM state
+ machine transitions in the normal way.
+
+ These rules are, however, not sufficient to allow pruning off the
+ (*,*,RP) tree. Some additional rules provide guidance as to one way
+ this may be done:
+
+ o If the PMBR has joined on the (*,*,RP) tree, then it should set
+ DownstreamJPState(*,G,I) to JOIN on the discard interface for all
+ active groups.
+
+ o If the router receives a (S,G) prune alert, it will need to set
+ DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.
+
+ o If the router receives a (*,G) prune alert, it will need to set
+ DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface for
+ all active sources sending to G.
+
+ The rationale for this is that there is no way in PIM-SM to prune
+ traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and
+ then pruning each source individually.
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 145]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+Appendix B. Index
+
+ Address_List. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ Assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . .27,128
+ Assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . .27,128
+ AssertCancel(*,G) . . . . . . . . . . . . . . . . . . . . . . . 97,99
+ AssertCancel(S,G) . . . . . . . . . . . . . . . . . . . . . .80,90,99
+ AssertTimer(*,G,I). . . . . . . . . . . . . . . . . . . .16,24,91,132
+ AssertTimer(S,G,I). . . . . . . . . . . . . . . . . . . .18,24,84,132
+ AssertTrackingDesired(*,G,I). . . . . . . . . . . . . . . . .93,94,96
+ AssertTrackingDesired(S,G,I). . . . . . . . . . . . . . . 85,86,87,89
+ AssertWinner(*,G,I) . . . . . . . . . . . . . . . .16,22,24,93,97,100
+ AssertWinner(S,G,I) . . . . . . . . . . . . . .18,22,24,86,90,100,100
+ AssertWinnerMetric(*,G,I) . . . . . . . . . . . . . . . . . 16,97,101
+ AssertWinnerMetric(S,G,I) . . . . . . . . . . . . . . . . . 18,90,101
+ assert_metric . . . . . . . . . . . . . . . . . . . . . . . . . . 98
+ Assert_Override_Interval. . . . . . . . . . . . . . . . . . 90,97,132
+ Assert_Time . . . . . . . . . . . . . . . . . . . . . . . . 90,97,132
+ AT(*,G,I) . . . . . . . . . . . . . . . . . . . . . .16,24,91,129,132
+ AT(S,G,I) . . . . . . . . . . . . . . . . . . . . . .18,24,84,129,132
+ CheckSwitchToSpt(S,G) . . . . . . . . . . . . . . . . . . . . . 27,28
+ CouldAssert(*,G,I). . . . . . . . . . . . . . . . . . .92,93,94,95,98
+ CouldAssert(S,G,I). . . . . . . . . . . . . . . . . 84,86,87,88,89,98
+ CouldRegister(S,G). . . . . . . . . . . . . . . . . . . . . . . 39,41
+ Default_Hello_Holdtime. . . . . . . . . . . . . . . . . . . . . . 33
+ DirectlyConnected(S). . . . . . . . . . . . . . . . . 27,27,29,41,143
+ DownstreamJPState(*,*,RP,I) . . . . . . . . . . . . . . . . . .23,145
+ DownstreamJPState(*,G,I). . . . . . . . . . . . . . . . . . . . . 23
+ DownstreamJPState(S,G,I). . . . . . . . . . . . . . . . . . . . 23,40
+ DownstreamJPState(S,G,rpt,I). . . . . . . . . . . . . . . . . . . 23
+ DR(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
+ dr_is_better(a,b,I) . . . . . . . . . . . . . . . . . . . . . . 33,33
+ DR_Priority . . . . . . . . . . . . . . . . . . . . . . . . .31,32,33
+ Effective_Override_Interval(I). . . . . . . . . . . . . . .36,114,132
+ Effective_Propagation_Delay(I). . . . . . . . . . . . . . . . .35,132
+ ET(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . 15,46,128,131
+ ET(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . 16,50,128,131
+ ET(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . 18,53,129,131
+ ET(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . .20,57,59,129,131
+ GenID . . . . . . . . . . . . . . . . . 15,17,19,31,64,68,70,73,85,93
+ Hash_Function . . . . . . . . . . . . . . . . . . . . . . . . .12,105
+ Hello_Holdtime. . . . . . . . . . . . . . . . . . . . . . . . .33,131
+ Hello_Period. . . . . . . . . . . . . . . . . . . . . . . . . .31,130
+ HT(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31,130
+ IGMP. . . . . . . . . . . . . . . . . . . . . . . . 6,8,17,23,101,105
+ immediate_olist(*,*,RP) . . . . . . . . . . . . . . . . . . . . 22,64
+ immediate_olist(*,G). . . . . . . . . . . . . . . . . . . . . . 22,68
+ immediate_olist(S,G). . . . . . . . . . . . . . . . . . . . .22,40,73
+
+
+
+Fenner, et al. Standards Track [Page 146]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ infinite_assert_metric(). . . . . . . . . . . . . . . . . . . . . 99
+ inherited_olist(S,G). . . . . . . . . . . . . . 22,27,40,43,73,86,108
+ inherited_olist(S,G,rpt). . . . . . . . . . . . . . 22,27,29,76,79,81
+ I_Am_Assert_Loser(*,G,I). . . . . . . . . . . . . . . . . . . . . 24
+ I_Am_Assert_Loser(S,G,I). . . . . . . . . . . . . . . . . . . . . 24
+ I_am_DR(I). . . . . . . . . . . . . . . . . . . . . . .22,33,41,86,93
+ I_am_RP(G). . . . . . . . . . . . . . . . . . . . . . . . . . . 43,44
+ J/P_Holdtime. . . . . . . . . . . . .47,51,55,59,65,69,74,121,131,133
+ J/P_Override_Interval(I). . . . . . . . . . . . . 48,51,55,59,121,132
+ JoinDesired(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . 64,79
+ JoinDesired(*,G). . . . . . . . . . . . . . . . . . . .17,68,79,86,97
+ JoinDesired(S,G). . . . . . . . . . . . . . . . . . 19,29,73,86,88,90
+ joins(*,*,RP(G)). . . . . . . . . . . . . . . . . . . . . . . . . 22
+ joins(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . 22,23,86,93
+ joins(*,G). . . . . . . . . . . . . . . . . . . . . . . . 22,23,86,93
+ joins(S,G). . . . . . . . . . . . . . . . . . . . . . . . . .22,23,86
+ JT(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . 15,62,129,133
+ JT(*,G) . . . . . . . . . . . . . . . . . . . . . . . . 16,67,129,133
+ JT(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 18,71,129,133
+ KAT(S,G). . . . . . . . . . . . . . .18,26,27,28,41,43,73,108,129,134
+ KeepaliveTimer(S,G) . . . . . . . 18,26,27,27,28,41,43,73,108,129,134
+ Keepalive_Period. . . . . . . . . . . . . . . . . . . . . . . .27,134
+ lan_delay_enabled(I). . . . . . . . . . . . . . . . . . . . . . 35,36
+ LAN_Prune_Delay . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ local_receiver_exclude(S,G,I) . . . . . . . . . . . . . . . . . . 23
+ local_receiver_include(*,G,I) . . . . . . . . . . . . . . . 23,93,144
+ local_receiver_include(S,G,I) . . . . . . . . . . . . . . . . . 23,86
+ local_receiver_include(S,G,I).. . . . . . . . . . . . . . . . . . 144
+ lost_assert(*,G). . . . . . . . . . . . . . . . . . . . . . .22,24,86
+ lost_assert(*,G,I). . . . . . . . . . . . . . . . . . . . . 22,24,100
+ lost_assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . 22,24
+ lost_assert(S,G,I). . . . . . . . . . . . . . . . . . . . . 22,24,100
+ lost_assert(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . 24
+ lost_assert(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . .24,100
+ MBGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6,7
+ MFIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6,13
+ MLD . . . . . . . . . . . . . . . . . . . . . . . . 6,8,17,23,101,105
+ MRIB. . . . . . . . . . . . . .6,7,11,15,19,25,62,66,66,75,98,103,128
+ MRIB.next_hop(host) . . . . . . . . . . . . . . . . . . . 24,25,62,64
+ my_assert_metric(*,G,I) . . . . . . . . . . . . . . . . . . . . . 94
+ my_assert_metric(S,G,I) . . . . . . . . . . . . . . . . . 85,89,92,98
+ NBR(Interface,IP_address) . . . . . . . . . . . . . . .25,37,62,64,66
+ NLT(N,I). . . . . . . . . . . . . . . . . . . . . . . . 14,33,128,131
+ OT(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . 20,77,129,134
+ Override_Interval(I). . . . . . . . . . . . . 14,31,34,36,114,130,132
+ packet_arrives_on_rp_tunnel(pkt). . . . . . . . . . . . . . . . . 43
+ pim_exclude(S,G). . . . . . . . . . . . . . . . . . . . . 22,22,28,86
+ pim_include(*,G). . . . . . . . . . . . . . . . . . 17,22,22,28,86,93
+
+
+
+Fenner, et al. Standards Track [Page 147]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+ pim_include(S,G). . . . . . . . . . . . . . . . . . . .19,22,22,28,86
+ PPT(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . 15,46,128,132
+ PPT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . 16,50,129,132
+ PPT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . 18,53,129,132
+ PPT(S,G,rpt,I). . . . . . . . . . . . . . . . . . . .20,57,59,129,132
+ Propagation_Delay(I). . . . . . . . . . . . . . . . . . 31,35,130,132
+ Propagation_delay_default . . . . . . . . . . . . . . . . . . .35,130
+ PruneDesired(S,G,rpt) . . . . . . . . . . . . . . . . . . 79,80,88,90
+ prunes(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . .22,23,86
+ Register-Stop(*,G). . . . . . . . . . . . . . . . . . . . . . . . 42
+ Register-Stop(S,G). . . . . . . . . . . . . . . . . . . . . . . . 43
+ Register-StopTimer(S,G) . . . . . . . . . . . . . . . . 38,39,129,135
+ Register_Probe_Time . . . . . . . . . . . . . . . . . . . . 39,44,135
+ Register_Suppression_Time . . . . . . . . . . . . . . . . . 39,44,135
+ RP(G) . . . . . . . . . . . . 5,22,24,40,43,49,68,77,86,93,99,102,128
+ RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ RPF'(*,G) . . . . . . . . . . . . . . . . 24,29,67,68,70,76,79,97,101
+ RPF'(S,G) . . . . . . . . . . . . . . . . . . . 25,29,71,76,79,90,101
+ RPF'(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . .24,76,79,102
+ RPF_interface . . . . . . . . . . . . . . . . . . . . . . . . . . 93
+ RPF_interface(host) . . . . . .24,27,29,41,68,69,74,86,93,100,108,143
+ RPTJoinDesired(G) . . . . . . . . . . . . . . . . . . . . . .79,81,93
+ rpt_assert_metric(G,I). . . . . . . . . . . . . . . . . . . .96,97,99
+ RST(S,G). . . . . . . . . . . . . . . . . . . . . . . . 38,39,129,135
+ SPTbit(S,G) . . . . . . . 19,27,29,43,53,74,76,79,86,86,89,90,100,108
+ spt_assert_metric(S,I). . . . . . . . . . . . . . . . . . . 90,98,100
+ SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10,106
+ Suppression_Enabled(I). . . . . . . . . . . . . . . . . . . . .36,133
+ SwitchToSptDesired(S,G) . . . . . . . . . . . . . . . . . . .28,28,43
+ TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6,13,26
+ Triggered_Hello_Delay . . . . . . . . . . . . . . . . . . . 31,32,130
+ t_joinsuppress. . . . . . . . . . . . . . . . . . . . .64,65,68,69,74
+ t_override. . . . . . . . . . . . . . . . . . . . 64,68,73,78,133,134
+ t_override_default. . . . . . . . . . . . . . . . . . . . . . .36,130
+ t_periodic. . . . . . . . . . . . . . . . . . . . . . . .64,68,73,133
+ t_suppressed. . . . . . . . . . . . . . . . . . . .36,65,69,73,74,133
+ Update_SPTbit(S,G,iif). . . . . . . . . . . . . . . . . . . . . 27,29
+ UpstreamJPState(S,G). . . . . . . . . . . . . . . . . . . . . .27,108
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 148]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+Authors' Addresses
+
+ Bill Fenner
+ AT&T Labs - Research
+ 1 River Oaks Place
+ San Jose, CA 95134
+
+ EMail: fenner@research.att.com
+
+
+ Mark Handley
+ Department of Computer Science
+ University College London
+ Gower Street
+ London WC1E 6BT
+ United Kingdom
+
+ EMail: M.Handley@cs.ucl.ac.uk
+
+
+ Hugh Holbrook
+ Arastra, Inc.
+ P.O. Box 10905
+ Palo Alto, CA 94303
+
+ EMail: holbrook@arastra.com
+
+
+ Isidor Kouvelas
+ Cisco Systems
+ 170 W. Tasman Drive
+ San Jose, CA 95134
+
+ EMail: kouvelas@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 149]
+
+RFC 4601 PIM-SM Specification August 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 150]
+