Internet Engineering Task Force PIM WG INTERNET-DRAFT Bill Fenner/AT&T draft-ietf-pim-sm-v2-new-04.txt Mark Handley/ACIRI Hugh Holbrook/Cisco Isidor Kouvelas/Cisco 21 November 2001 Expires: May 2002 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a product of the IETF PIM WG. Comments should be addressed to the authors, or the WG's mailing list at pim@catarina.usc.edu. 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 Fenner/Handley/Holbrook/Kouvelas [Page 1] INTERNET-DRAFT Expires: May 2002 November 2001 builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. Note on PIM-SM status PIM-SM v2 is currently widely implemented and deployed, but the existing specification in RFC 2362 is insufficient to implement from, and is incorrect in a number of aspects. This document is a complete re-write from RFC 2362, and is intended to obsolete RFC 2362. The authors have attempted to document current practice as far as possible, but a number of cases have arisen where current practice is clearly incorrect, typically leading to traffic being black-holed. In these cases we diverge from current practice, but always in a way that will interoperate successfully with the legacy PIM v2 implementations that we are aware of. Fenner/Handley/Holbrook/Kouvelas [Page 2] INTERNET-DRAFT Expires: May 2002 November 2001 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . . . . . . 6 3. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Specification. . . . . . . . . . . . . . . . . . . . . . 12 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. General Purpose State . . . . . . . . . . . . . . . . . . . 13 4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . . . . . . 14 4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . . . . . . 18 4.1.6. State Summarization Macros. . . . . . . . . . . . . . . . . 19 4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . . 24 4.2.1. Last hop switchover to the SPT. . . . . . . . . . . . . . . 26 4.2.2. Setting and Clearing the (S,G) SPT bit. . . . . . . . . . . 26 4.3. PIM Register Messages. . . . . . . . . . . . . . . . . . . . . 28 4.3.1. Sending Register Messages from the DR . . . . . . . . . . . 28 4.3.2. Receiving Register Messages at the RP . . . . . . . . . . . 32 4.4. PIM Join/Prune Messages. . . . . . . . . . . . . . . . . . . . 33 4.4.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . . . . . . 34 4.4.2. Receiving (*,G) Join/Prune Messages . . . . . . . . . . . . 37 4.4.3. Receiving (S,G) Join/Prune Messages . . . . . . . . . . . . 41 4.4.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . . . . 45 4.4.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . . . . . . 51 4.4.6. Sending (*,G) Join/Prune Messages . . . . . . . . . . . . . 55 4.4.7. Sending (S,G) Join/Prune Messages . . . . . . . . . . . . . 59 4.4.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . . . . . . 64 4.4.9. State Machine for (S,G,rpt) Triggered Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.5. PIM Assert Messages. . . . . . . . . . . . . . . . . . . . . . 69 4.5.1. (S,G) Assert Message State Machine. . . . . . . . . . . . . 69 4.5.2. (*,G) Assert Message State Machine. . . . . . . . . . . . . 77 4.5.3. Assert Metrics. . . . . . . . . . . . . . . . . . . . . . . 83 4.5.4. AssertCancel Messages . . . . . . . . . . . . . . . . . . . 84 4.5.5. Assert State Macros . . . . . . . . . . . . . . . . . . . . 84 4.6. Designated Routers (DR) and Hello Messages . . . . . . . . . . 87 4.6.1. Sending Hello Messages. . . . . . . . . . . . . . . . . . . 87 4.6.2. DR Election . . . . . . . . . . . . . . . . . . . . . . . . 89 4.6.3. Reducing Prune Propagation Delay on LANs. . . . . . . . . . 90 4.7. PIM Multicast Border Router Behavior . . . . . . . . . . . . . 93 4.7.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.7.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.8. PIM Bootstrap and RP Discovery . . . . . . . . . . . . . . . . 95 4.8.1. Group-to-RP Mapping . . . . . . . . . . . . . . . . . . . . 97 Fenner/Handley/Holbrook/Kouvelas [Page 3] INTERNET-DRAFT Expires: May 2002 November 2001 4.8.2. Hash Function . . . . . . . . . . . . . . . . . . . . . . . 97 4.9. Source-Specific Multicast. . . . . . . . . . . . . . . . . . . 98 4.9.1. Protocol Modifications for SSM destination addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.9.2. PIM-SSM-only Routers. . . . . . . . . . . . . . . . . . . . 99 4.10. PIM Packet Formats. . . . . . . . . . . . . . . . . . . . . . 101 4.10.1. Encoded Source and Group Address Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.10.2. Hello Message Format . . . . . . . . . . . . . . . . . . . 105 4.10.3. Register Message Format. . . . . . . . . . . . . . . . . . 107 4.10.4. RegisterStop Message Format. . . . . . . . . . . . . . . . 109 4.10.5. Join/Prune Message Format. . . . . . . . . . . . . . . . . 109 4.10.5.1. Group Set Source List Rules . . . . . . . . . . . . . . 112 4.10.5.2. Group Set Fragmentation . . . . . . . . . . . . . . . . 115 4.10.6. Assert Message Format. . . . . . . . . . . . . . . . . . . 116 4.11. PIM Timers. . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.12. Timer Values. . . . . . . . . . . . . . . . . . . . . . . . . 119 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 125 5.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . . 125 5.2. PIM Hello Options. . . . . . . . . . . . . . . . . . . . . . . 126 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 126 6.1. Attacks based on forged messages . . . . . . . . . . . . . . . 126 6.1.1. Forged link-local messages. . . . . . . . . . . . . . . . . 126 6.1.2. Forged unicast messages . . . . . . . . . . . . . . . . . . 127 6.2. Non-cryptographic Authentication Mechanisms. . . . . . . . . . 127 6.3. Authentication using IPsec . . . . . . . . . . . . . . . . . . 128 6.3.1. Protecting link-local multicast messages. . . . . . . . . . 128 6.3.2. Protecting unicast messages . . . . . . . . . . . . . . . . 129 6.3.2.1. Register messages. . . . . . . . . . . . . . . . . . . . 129 6.3.2.2. Register Stop messages . . . . . . . . . . . . . . . . . 129 6.4. Denial of Service Attacks. . . . . . . . . . . . . . . . . . . 130 7. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 130 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 131 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 10. Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Fenner/Handley/Holbrook/Kouvelas [Page 4] INTERNET-DRAFT Expires: May 2002 November 2001 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 revised in RFC 2362. This document is intended to obsolete RFC 2362, and to correct a number of deficiencies that have been identified with the way PIM-SM was previously specified. 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 successfully interoperate 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 and indicate requirement levels for compliant PIM-SM implementations. 2.1. Definitions This specification uses a number of terms to refer to the roles of routers participating in PIM-SM. 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. If the LAN has directly connected hosts, then a single one of these routers, the DR, will act on behalf of those hosts with respect to the PIM-SM protocol. A single DR is elected per LAN using a simple election process. Fenner/Handley/Holbrook/Kouvelas Section 2.1. [Page 5] INTERNET-DRAFT Expires: May 2002 November 2001 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 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 IGMP or 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 either be the source or the RP depending on the context. Downstream Away from the root of the tree. 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. Fenner/Handley/Holbrook/Kouvelas Section 2.2. [Page 6] INTERNET-DRAFT Expires: May 2002 November 2001 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 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 MRIB or Multicast Routing Information Base. The routes in this table may be taken directly from the unicast routing table, or it may be different and provided by a separate routing protocol such as MBGP [1]. 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 be occur simultaneously. 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 [6] or MLD [4], but other mechanisms might also serve this purpose. One of the receiver's local routers is elected as the Designated Router Fenner/Handley/Holbrook/Kouvelas Section 3. [Page 7] INTERNET-DRAFT Expires: May 2002 November 2001 (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. Phase Two: Register Stop Register-encapsulation of data packets is inefficient for two reasons: o Encapsulation and decapsulation may be relatively expensive operations for a router to perform, depending on whether or not the router has appropriate hardware for these tasks. o Traveling all the way to the RP, and then back down the shared tree may entail the packets traveling a relatively long distance to reach receivers that are close to the sender. For some applications, this increased latency 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 Fenner/Handley/Holbrook/Kouvelas Section 3. [Page 8] INTERNET-DRAFT Expires: May 2002 November 2001 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 so, they can short-cut 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 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 RegisterStop message back to S's DR to prevent the DR 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 so avoid taking a long detour via the RP. It should be noted 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. Phase 3: Shortest-Path Tree Although having the RP join back towards the source removes the encapsulation overhead, it does not completely optimize the forwarding paths. For many receivers the route via the RP may involve a significant detour when compared with the shortest path from the source to the receiver. To obtain lower latencies, 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 Fenner/Handley/Holbrook/Kouvelas Section 3. [Page 9] INTERNET-DRAFT Expires: May 2002 November 2001 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. 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.9. Source-specific Prunes IGMPv3 also permits a receiver to join a group and specify that it only wants to receive traffic for a group if that traffic does not come from 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. Multi-access Transit LANs The overview so far has concerned itself with point-to-point 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 Fenner/Handley/Holbrook/Kouvelas Section 3. [Page 10] INTERNET-DRAFT Expires: May 2002 November 2001 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 which has (S,G) state, or if neither or both router has (S,G) state, then in favor of the router with the best metric to the RP for RP trees, or the best metric to the source to source- 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. 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 either through a bootstrap mechanism or through static configuration. One dynamic way to do this is to use the Bootstrap Router (BSR) mechanism [7]. 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. Fenner/Handley/Holbrook/Kouvelas Section 3. [Page 11] INTERNET-DRAFT Expires: May 2002 November 2001 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 the PIM Register generation and processing rules. o Section 4.4 specifies the PIM Join/Prune generation and processing rules. o Section 4.5 specifies the PIM Assert generation and processing rules. o Designated Router (DR) election is specified in Section 4.6. o Section 4.8 specifies the RP discovery mechanisms. o The subset of PIM required to support Source-Specific Multicast, PIM- SSM, is described in Section 4.9. o PIM packet formats are specified in Section 4.10. o A summary of PIM-SM timers and their default values is given in Section 4.11. 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 or 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. Fenner/Handley/Holbrook/Kouvelas Section 4.1. [Page 12] INTERNET-DRAFT Expires: May 2002 November 2001 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. 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 Override Interval o Propagation Delay o Suppression state: One of {"Enable", "Disable"} Neighbor State: For each neighbor: Fenner/Handley/Holbrook/Kouvelas Section 4.1.1. [Page 13] INTERNET-DRAFT Expires: May 2002 November 2001 o Information from neighbor's Hello o Neighbor's Gen ID. o Neighbor liveness timer (NLT) Designated Router (DR) State: o Designated Router's IP Address o DR's DR Priority The Override Interval, the Propagation Delay and the Interface suppression state are described in section 4.6.3. Designated Router state is described in section 4.6. 4.1.2. (*,*,RP) State 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), "PrunePending" (PP)} o Prune Pending Timer (PPT) o Join/Prune Expiry Timer (ET) Not interface specific: 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.4.1. 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, Fenner/Handley/Holbrook/Kouvelas Section 4.1.2. [Page 14] INTERNET-DRAFT Expires: May 2002 November 2001 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.4.5. 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), "PrunePending" (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 o Assert winner's Assert Metric Not interface specific: 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) Fenner/Handley/Holbrook/Kouvelas Section 4.1.3. [Page 15] INTERNET-DRAFT Expires: May 2002 November 2001 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 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.4.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.4.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.5.2. 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.8) 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.4.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"} PIM (S,G) Join/Prune State: Fenner/Handley/Holbrook/Kouvelas Section 4.1.4. [Page 16] INTERNET-DRAFT Expires: May 2002 November 2001 o State: One of {"NoInfo" (NI), "Join" (J), "PrunePending" (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 o Assert winner's Assert Metric Not interface specific: o Upstream (S,G) Join/Prune Timer (JT) o Last RPF Neighbor towards S that was used o SPT bit (indicates (S,G) state is active) o (S,G) KeepAlive Timer (KAT) 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.4.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.4.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.5.1. Fenner/Handley/Holbrook/Kouvelas Section 4.1.4. [Page 17] INTERNET-DRAFT Expires: May 2002 November 2001 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.4.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. 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. 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", "PrunePending"} o Prune Pending Timer (PPT) o Join/Prune Expiry Timer (ET) Not interface specific: Fenner/Handley/Holbrook/Kouvelas Section 4.1.5. [Page 18] INTERNET-DRAFT Expires: May 2002 November 2001 Upstream (S,G,rpt) Join/Prune State: o State: One of {"NotJoined(*,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 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.4.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.4.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.4.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. Fenner/Handley/Holbrook/Kouvelas Section 4.1.6. [Page 19] INTERNET-DRAFT Expires: May 2002 November 2001 There is no immediate_olist(S,G,rpt) as (S,G,rpt) state is negative state - it removes interfaces in the (*,G) olist from the olist that is actually used to forward traffic. The inherited_olist(S,G,rpt) is therefore the olist that would be used for a packet from S to G forwarding on the RP tree. It is a strict subset of immediate_olist(*,G). Generally speaking, the inherited olists are used for forwarding, and the immediate_olists are used to make decisions about state maintenance. 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) (+) immediate_olist(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) = Fenner/Handley/Holbrook/Kouvelas Section 4.1.6. [Page 20] INTERNET-DRAFT Expires: May 2002 November 2001 { 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_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 there are local members on interface I that 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 there are local members on interface I that desire to receive all traffic sent to G. "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 PrunePending } DownstreamJPState(*,*,RP,I) is the state of the finite state machine in section 4.4.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 PrunePending } DownstreamJPState(*,G,I) is the state of the finite state machine in section 4.4.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 PrunePending } DownstreamJPState(S,G,I) is the state of the finite state machine in section 4.4.3. Fenner/Handley/Holbrook/Kouvelas Section 4.1.6. [Page 21] INTERNET-DRAFT Expires: May 2002 November 2001 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.4.4. 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.5.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.5.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.5.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. Fenner/Handley/Holbrook/Kouvelas Section 4.1.6. [Page 22] INTERNET-DRAFT Expires: May 2002 November 2001 neighbor RPF'(*,G) { if ( I_Am_Assert_Loser(*,G,RPF_interface(RP(G))) ) { return AssertWinner(*, G, RPF_interface(RP(G)) ) } else { return MRIB.next_hop( RP(G) ) } } neighbor RPF'(S,G,rpt) { if( I_Am_Assert_Loser(S, G, RPF_interface(RP(G)) ) ) { return AssertWinner(S, G, RPF_interface(RP(G)) ) } else { return RPF'(*,G) } } neighbor RPF'(S,G) { if ( I_Am_Assert_Loser(S, G, RPF_interface(S) )) { return AssertWinner(S, G, RPF_interface(S) ) } else { return 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.4.8). The function MRIB.next_hop( S ) returns the next-hop PIM neighbor toward the host S, as indicated by the current MRIB. If S is directly adjacent, then MRIB.next_hop( S ) returns NULL. At the RP for G, MRIB.next_hop( RP(G )) returns NULL. I_Am_Assert_Loser(S, G, I) is true if the Assert start machine (in section 4.5.1) for (S,G) on Interface I is in "I am Assert Loser" state. I_Am_Assert_Loser(*, G, I) is true if the Assert start machine (in section 4.5.2) for (*,G) on Interface I is in "I am Assert Loser" state. Fenner/Handley/Holbrook/Kouvelas Section 4.1.6. [Page 23] INTERNET-DRAFT Expires: May 2002 November 2001 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 SPT bit 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/Handley/Holbrook/Kouvelas Section 4.2. [Page 24] INTERNET-DRAFT Expires: May 2002 November 2001 On receipt on a data from S to G on interface iif: if( DirectlyConnected(S) == TRUE ) { set KeepaliveTimer(S,G) to Keepalive_Period # Note: register state transition may happen as a result # of restarting KeepaliveTimer, and must be dealt with here. } Update_SPTbit(S,G,iif) oiflist = NULL if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) { oiflist = inherited_olist(S,G) if( oiflist != NULL ) { restart KeepaliveTimer(S,G) } } else if( iif == RPF_interface(RP) AND SPTbit(S,G) == FALSE) { oiflist = inherited_olist(S,G,rpt) CheckSwitchToSpt(S,G) } else { # Note: RPF check failed if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) { send Assert(S,G) on iif } else if ( SPTbit(S,G) == FALSE AND iif is in inherited_olist(S,G,rpt) { send Assert(*,G) on iif } } oiflist = oiflist (-) iif forward packet on all interfaces in oiflist This pseudocode employs several "macro" definitions: DirectlyConnected(S) is TRUE if the source S is on any subnet that is directly connected to this router (or for packets originating on this router). inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section 4.1. Basically inherited_olist(S,G) is the outgoing interface list for packets forwarded on (S,G) state taking into account (*,*,RP) state, (*,G) state, asserts, etc. inherited_olist(S,G,rpt) is the outgoing interface for packets forwarded on (*,*,RP) or (*,G) state taking into account (S,G,rpt) prune state, and asserts, etc. Fenner/Handley/Holbrook/Kouvelas Section 4.2. [Page 25] INTERNET-DRAFT Expires: May 2002 November 2001 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.4.7. Keepalive_Period is defined in Section 4.11. 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) ) { restart KeepAliveTimer(S,G); } } SwitchToSptDesired(S,G) is a policy function that is implementation defined. An "infinite threshhold" policy can be implemented making SwitchToSptDesired(S,G) return false all the time. A "switch on first packet" policy can be implemented by making SwitchToSptDesired(S,G) return true once a single packet has been received for the source and group. 4.2.2. Setting and Clearing the (S,G) SPT bit The (S,G) SPTbit is used to distinguish whether to forward on (*,*,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 Fenner/Handley/Holbrook/Kouvelas Section 4.2.2. [Page 26] INTERNET-DRAFT Expires: May 2002 November 2001 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) OR inherited_olist(S,G,rpt) == NULL OR RPF'(S,G) == RPF'(*,G) ) ) { Set SPTbit(S,G) to TRUE } } Additionally a router sets SPTbit(S,G) to TRUE when it receives an Assert(S,G) on RPF_interface(S). JoinDesired(S,G) is defined in Section 4.4.7, and indicates whether we have the appropriate (S,G) Join state to wish to send a Join(S,G) upstream. Basically Update_SPTbit will set the SPT bit if we have the appropriate (S,G) join state and the packet arrived on the correct upstream interface for S, and one or more of the following conditions applies: 1. The source is directly connected, in which case the switch to the SPT is a no-op. 2. The RPF interface to S is different from the RPF interface to the RP. The packet arrived on RPF_interface(S), and so the SPT must have been completed. 3. No-one wants the packet on the RP tree. 4. RPF'(S,G) == RPF'(*,G). In this case the router will never be able to tell if the SPT has been completed, so it should just switch immediately. In the case where the RPF interface is the same for the RP and for S, but RPF'(S,G) and RPF'(*,G) differ, then we wait for an Assert(S,G) which indicates that the upstream router with (S,G) state believes the SPT has been completed. However item (3) above is needed because there may not be any (*,G) state to trigger an Assert(S,G) to happen. Fenner/Handley/Holbrook/Kouvelas Section 4.2.2. [Page 27] INTERNET-DRAFT Expires: May 2002 November 2001 The SPT bit is cleared in the (S,G) upstream state machine (see Section 4.4.7) when JoinDesired(S,G) becomes FALSE. 4.3. PIM Register Messages Overview 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.3.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 is 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. No Info (NI) No information. This is the initial state, and the state when the router is not the DR. Fenner/Handley/Holbrook/Kouvelas Section 4.3.1. [Page 28] INTERNET-DRAFT Expires: May 2002 November 2001 In addition, a RegisterStop timer (RST) is kept if the state machine in not in the No Info state. +-----------------------------------+ | Figures omitted from text version | +-----------------------------------+ Figure 1: Per-(S,G) register state-machine at a DR In tabular form, the state-machine is: +-----------++------------------------------------------------------------------------------------------+ | || Event | | ++------------------+------------------+----------------------+--------------+--------------+ |Prev State ||Register-Stop |Could-Register | Could-Register |Register- |RP changed | | ||Timer expires |->True | ->False |Stop | | | || | | |received | | +-----------++------------------+------------------+----------------------+--------------+--------------+ |No Info ||- |-> J state | - |- |- | |(NI) || |add reg tunnel | | | | +-----------++------------------+------------------+----------------------+--------------+--------------+ | ||- |- | -> NI state |-> P state |-> J state | | || | | remove reg tunnel |remove |update reg | | || | | |tunnel; |tunnel | |Join (J) || | | |set | | | || | | |Register- | | | || | | |Stop | | | || | | |timer(*) | | +-----------++------------------+------------------+----------------------+--------------+--------------+ | ||-> J state |- | -> NI state |-> P state |-> J state | |Join ||add reg tunnel | | remove reg tunnel |set |add reg | |Pending || | | |Register- |tunnel; | |(JP) || | | |Stop |cancel | | || | | |timer(*) |Register- | | || | | | |Stop timer | +-----------++------------------+------------------+----------------------+--------------+--------------+ | ||-> JP state |- | -> NI state |- |-> J state | | ||set Register- | | remove reg tunnel | |add reg | |Prune (P) ||Stop | | | |tunnel; | | ||timer(**); | | | |cancel | | ||send null | | | |Register- | | ||register | | | |Stop timer | +-----------++------------------+------------------+----------------------+--------------+--------------+ Notes: Fenner/Handley/Holbrook/Kouvelas Section 4.3.1. [Page 29] INTERNET-DRAFT Expires: May 2002 November 2001 (*) The RegisterStopTimer is set to a random value chosen uniformly from the interval ( 0.5 * Register_Suppression_Time, 1.5 * Register_Suppression_Time) minus Register_Probe_Time; Subtracting off Register_Probe_Time is a bit unnecessary because it is really small compared to Register_Suppression_Time, but was in the old spec and is kept for compatibility. (**) The RegisterStopTimer is set to Register_Probe_Time. The following 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). 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). 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 can not simply change the encapsulation target of VI_old because not all groups using that encapsulation tunnel will have moved to the same new RP. CouldRegister(S,G) The macro "CouldRegister" in the state machine is defined as: Fenner/Handley/Holbrook/Kouvelas Section 4.3.1. [Page 30] INTERNET-DRAFT Expires: May 2002 November 2001 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. This smaller MTU takes both the outer IP header and the PIM register header overhead into account. If a multicast packet is fragmented on the way into the Register Tunnel, each fragment is encapsulated individually so contains IP, PIM, and inner IP headers. In IPv6, an ICMP Fragmentation Required message may be sent by the encapsulating DR. Just like any forwarded packet, the TTL of the original data packet is decremented before it is encapsulated in the Register Tunnel. 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. 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 [2] for more discussion on setting the DSCP on tunnels. Handling RegisterStop(*,G) Messages at the DR An old RP might send a RegisterStop message with the source address set to all-zeros. This was the normal course of action in RFC 2326 when the Register message matched against (*,G) state at the RP, and was defined as meaning "stop encapsulating all sources for this group". However, the behavior of such a RegisterStop(*,G) is ambiguous or incorrect in Fenner/Handley/Holbrook/Kouvelas Section 4.3.1. [Page 31] INTERNET-DRAFT Expires: May 2002 November 2001 some circumstances. We specify that an RP should not send RegisterStop(*,G) messages, but for compatibility, a DR should be able to accept one if it is received. A RegisterStop(*,G) should be treated as a RegisterStop(S,G) for all existing (S,G) Register state machines. A router should not apply a RegisterStop(*,G) to sources that become active after the RegisterStop(*,G) was received. 4.3.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 that this should not happen if the lower layer is working } if( I_am_RP( G ) && outer.dst == RP(G) ) { restart KeepaliveTimer(S,G) if(( inherited_olist(S,G) == NULL ) OR SPTbit(S,G)) { send RegisterStop(S,G) to outer.src } else { if( ! pkt.NullRegisterBit ) { decapsulate and pass the inner packet to the normal forwarding path for forwarding on the (*,G) tree. } } } else { send RegisterStop(S,G) to outer.src # Note (*) } } outer.dst is the IP destination address of the encapsulating header. outer.src is the IP source address of the encapsulating header, i.e., the DR's address. I_am_RP(G) is true if the group-to-RP mapping indicates that this router is the RP for the group. Fenner/Handley/Holbrook/Kouvelas Section 4.3.2. [Page 32] INTERNET-DRAFT Expires: May 2002 November 2001 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 to also accept (*,G) joins when it doesn't yet realize that it is about to become the RP for G. This will all get sorted out once 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. KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the proper tunnel interface. This may cause the upstream (S,G) state machine to trigger a join if the inherited_olist(S,G) is not NULL; 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 RegisterStop timer expires at the DR. Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 * Register_Suppression_Time + Register_Probe_Time ). Just like any forwarded packet, the TTL of the original data packet is decremented after it is decapsulated from the Register Tunnel. The IP ECN bits should be copied from the IP header of the Register packet to the decapsulated packet. The Diffserv Code Point (DSCP) should be copied from the IP header of the Register packet to the decapsulated packet. The RP MAY retain the DSCP of the inner packet, or re-classify the packet and apply a different DSCP. Scenarios where each of these might be useful are discussed in [2]. 4.4. 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 PIM Destination 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 PIM Destination field addresses another router, most Join or Prune messages could affect each upstream state machine. Fenner/Handley/Holbrook/Kouvelas Section 4.4. [Page 33] INTERNET-DRAFT Expires: May 2002 November 2001 4.4.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 us 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.4.4) or the router lost an assert on this interface. PrunePending (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 PrunePending 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. PrunePendingTimer (PPT) This timer is set when a valid Prune(*,*,RP) is received. Expiry of the PrunePendingTimer causes the interface state to revert to NoInfo for this RP. +-----------------------------------+ | Figures omitted from text version | +-----------------------------------+ Figure 2: Downstream (*,*,RP) per-interface state-machine Fenner/Handley/Holbrook/Kouvelas Section 4.4.1. [Page 34] INTERNET-DRAFT Expires: May 2002 November 2001 In tabular form, the per-interface (*,*,RP) state-machine is: +-------------++---------------------------------------------------------+ | || 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 | | | +-------------++-------------+-------------+--------------+--------------+ | ||-> J state | -> PP state | -> NI state | -> NI state | | ||restart | | Send Prune- | | |Prune ||Expiry | | Echo(*,*,RP) | | |Pending (PP) ||Timer; | | | | | ||cancel Prune | | | | | ||Pending | | | | | ||Timer | | | | +-------------++-------------+-------------+--------------+--------------+ The transition events "Receive Join(*,*,RP)" and "Receive Prune(*,*,RP)" imply receiving a Join or Prune targeted to this router's address on the received interface. If the destination address 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 PIM messages with a destination address of all zeros is also accepted. Fenner/Handley/Holbrook/Kouvelas Section 4.4.1. [Page 35] INTERNET-DRAFT Expires: May 2002 November 2001 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 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 that 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 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. Receive Prune(*,*,RP) A Prune(*,*,RP) is received on interface I with its Upstream Neighbor Address set to the router's address on I. The (*,*,RP) downstream state machine on interface I transitions to the PrunePending state. The PrunePending 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. Fenner/Handley/Holbrook/Kouvelas Section 4.4.1. [Page 36] INTERNET-DRAFT Expires: May 2002 November 2001 Transitions from PrunePending State When in PrunePending 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 address on I. The (*,*,RP) downstream state machine on interface I transitions to the Join state. The PrunePending 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. PrunePending Timer Expires The PrunePending 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. 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 a point-to- point interface. 4.4.2. Receiving (*,G) Join/Prune Messages When a router receives a Join(*,G) or Prune(*,G) it must first check to see whether the RP in the message matches RP(G) (the router's idea of who the RP is). If the RP in the message does not match RP(G) the Join or Prune should be silently dropped. If a router has no RP information Fenner/Handley/Holbrook/Kouvelas Section 4.4.2. [Page 37] INTERNET-DRAFT Expires: May 2002 November 2001 (e.g. has not recently received a BSR message) then it may choose to accept Join(*,G) or Prune(*,G) and treat the RP in the message as RP(G). 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 us to forward packets destined for G from this interface except if there is also (S,G,rpt) prune information (see Section 4.4.4) or the router lost an assert on this interface. PrunePending (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 PrunePending 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(*,G) is received. Expiry of the ExpiryTimer causes the interface state to revert to NoInfo for this group. PrunePendingTimer (PPT) This timer is set when a valid Prune(*,G) is received. Expiry of the PrunePendingTimer causes the interface state to revert to NoInfo for this group. +-----------------------------------+ | Figures omitted from text version | +-----------------------------------+ Figure 3: Downstream (*,G) per-interface state-machine Fenner/Handley/Holbrook/Kouvelas Section 4.4.2. [Page 38] INTERNET-DRAFT Expires: May 2002 November 2001 In tabular form, the per-interface (*,G) state-machine is: +-------------++--------------------------------------------------------+ | || 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 | | | +-------------++-------------+-------------+-------------+--------------+ | ||-> J state | -> PP state | -> NI state | -> NI state | | ||restart | | Send Prune- | | |Prune ||Expiry | | Echo(*,G) | | |Pending (PP) ||Timer; | | | | | ||cancel Prune | | | | | ||Pending | | | | | ||Timer | | | | +-------------++-------------+-------------+-------------+--------------+ The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply receiving a Join or Prune targeted to this router's address on the received interface. If the destination address 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 PIM messages with a destination address 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 address on I. Fenner/Handley/Holbrook/Kouvelas Section 4.4.2. [Page 39] INTERNET-DRAFT Expires: May 2002 November 2001 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 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 address on I. The (*,G) downstream state machine on interface I transitions to the PrunePending state. The PrunePending 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. Transitions from PrunePending State When in PrunePending 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 address on I. The (*,G) downstream state machine on interface I transitions to the Join state. The PrunePending 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. Fenner/Handley/Holbrook/Kouvelas Section 4.4.2. [Page 40] INTERNET-DRAFT Expires: May 2002 November 2001 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. PrunePending Timer Expires The PrunePending 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 a point-to-point interface. 4.4.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 us 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. PrunePending (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 PrunePending state functions exactly like the Join state. Fenner/Handley/Holbrook/Kouvelas Section 4.4.3. [Page 41] INTERNET-DRAFT Expires: May 2002 November 2001 In addition there are two timers: ExpiryTimer (ET) This timer is set when a valid Join(S,G) is received. Expiry of the ExpiryTimer causes this state machine to revert to NoInfo state. PrunePendingTimer (PPT) This timer is set when a valid Prune(S,G) is received. Expiry of the PrunePendingTimer this state machine to revert to NoInfo state. +-----------------------------------+ | Figures omitted from text version | +-----------------------------------+ Figure 4: Downstream per-interface (S,G) state-machine In tabular form, the state machine is: +-------------++--------------------------------------------------------+ | || 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 | | | +-------------++-------------+-------------+-------------+--------------+ | ||-> J state | -> PP state | -> NI state | -> NI state | | ||restart | | Send Prune- | | |Prune ||Expiry | | Echo(S,G) | | |Pending (PP) ||Timer; | | | | | ||cancel Prune | | | | | ||Pending | | | | | ||Timer | | | | +-------------++-------------+-------------+-------------+--------------+ Fenner/Handley/Holbrook/Kouvelas Section 4.4.3. [Page 42] INTERNET-DRAFT Expires: May 2002 November 2001 The transition events "Receive Join(S,G)" and "Receive Prune(S,G)" imply receiving a Join or Prune targeted to this router's address on the received interface. If the destination address 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 PIM messages with a destination address 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 address on I. The (S,G) downstream state machine on interface I transitions to the Join state. The Expiry Timer (ET) is started, and set to the HoldTime from the triggering Join/Prune message. Transitions from Join State When in Join state, the following events may trigger a transition: Receive Join(S,G) A Join(S,G) is received on interface I with its Upstream Neighbor Address set to the router's 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 address on I. The (S,G) downstream state machine on interface I transitions to the PrunePending state. The PrunePending timer is started; it is set to the J/P_Override_Interval(I) if the router has more than one neighbor on that interface; otherwise it is set to zero causing it to expire immediately. Fenner/Handley/Holbrook/Kouvelas Section 4.4.3. [Page 43] INTERNET-DRAFT Expires: May 2002 November 2001 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 PrunePending State When in PrunePending 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 address on I. The (S,G) downstream state machine on interface I transitions to the Join state. The PrunePending 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. PrunePending Timer Expires The PrunePending 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 a point-to-point interface. Fenner/Handley/Holbrook/Kouvelas Section 4.4.3. [Page 44] INTERNET-DRAFT Expires: May 2002 November 2001 4.4.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 us not to forward packets from S destined for G from this interface even though the interface has active (*,G) Join state. When interface I is in this state, the macro prune(S,G,rpt,I) returns true. PrunePending (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 PrunePending state functions exactly like the NoInfo state. PruneTmp (P') This state is a transient state which 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 re- instate 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. PrunePendingTmp (PP') This state is a transient state which 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: ExpiryTimer (ET) This timer is set when a valid Prune(S,G,rpt) is received. Expiry of the ExpiryTimer causes this state machine to revert to NoInfo state. Fenner/Handley/Holbrook/Kouvelas Section 4.4.4. [Page 45] INTERNET-DRAFT Expires: May 2002 November 2001 PrunePendingTimer (PPT) This timer is set when a valid Prune(S,G,rpt) is received. Expiry of the PrunePendingTimer causes this state machine to move on to Prune state. +-----------------------------------+ | Figures omitted from text version | +-----------------------------------+ Figure 5: Downstream per-interface (S,G,rpt) state-machine Fenner/Handley/Holbrook/Kouvelas Section 4.4.4. [Page 46] INTERNET-DRAFT Expires: May 2002 November 2001 In tabular form, the state machine is: +----------++----------------------------------------------------------------+ | || 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 | - | n/a | n/a | | || | | state | | | | | || | | start | | | | | || | | Prune | | | | |No Info || | | Pending | | | | |(NI) || | | Timer; | | | | | || | | start | | | | | || | | Expiry | | | | | || | | Timer | | | | | || | | Timer | | | | +----------++----------+-----------+-----------+---------+---------+---------+ | ||-> P' | -> NI | -> P | - | n/a | -> NI | |Pruned ||state | state | state | | | state | |(P) || | | restart | | | | | || | | Expiry | | | | | || | | Timer | | | | +----------++----------+-----------+-----------+---------+---------+---------+ |Prune ||-> PP' | -> NI | - | - | -> P | n/a | |Pending ||state | state | | | state | | |(PP) || | | | | | | +----------++----------+-----------+-----------+---------+---------+---------+ | ||error | error | -> P | -> NI | n/a | n/a | |Prune Tmp || | | state | state | | | |(P') || | | restart | | | | | || | | Expiry | | | | | || | | Timer | | | | +----------++----------+-----------+-----------+---------+---------+---------+ | ||error | error | -> PP | -> NI | n/a | n/a | |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 address on the received interface. If the destination address is not correct, these state transitions in this state machine must not Fenner/Handley/Holbrook/Kouvelas Section 4.4.4. [Page 47] INTERNET-DRAFT Expires: May 2002 November 2001 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 messages with a destination address 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 address on I. The (S,G,rpt) downstream state machine on interface I transitions to the PrunePending state. The Expiry Timer (ET) is started, and set to the HoldTime from the triggering Join/Prune message. The PrunePending 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 PrunePending State When in PrunePending (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 address on I. The (S,G,rpt) downstream state machine on interface I transitions to PrunePendingTmp 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 address on I. The (S,G,rpt) downstream state machine on interface I transitions to NoInfo state. ET and PPT are canceled. PrunePending Timer Expires The PrunePending Timer for the (S,G,rpt) downstream state Fenner/Handley/Holbrook/Kouvelas Section 4.4.4. [Page 48] INTERNET-DRAFT Expires: May 2002 November 2001 machine on interface I expires. The (S,G,rpt) downstream state machine on interface I transitions to the Pruned state. Transitions from Pruned State When in Pruned (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 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 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 address on I. The (S,G,rpt) downstream state machine on interface I remains in Pruned 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. ET and PPT are canceled. Transitions from PrunePendingTmp State When in PrunePendingTmp (PP') state and processing a compound Join/Prune message, the following events may trigger a transition: Receive Prune(S,G,rpt) The compound Join/Prune message contains a Prune(S,G,rpt). Fenner/Handley/Holbrook/Kouvelas Section 4.4.4. [Page 49] INTERNET-DRAFT Expires: May 2002 November 2001 The (S,G,rpt) downstream state machine on interface I transitions back to the PrunePending 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 Pruned 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. 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 pre-existing Prune(S,G,rpt). This is considered acceptable, as (*,*,RP) state is intended to be used only in long-lived and persistent scenarios. Fenner/Handley/Holbrook/Kouvelas Section 4.4.4. [Page 50] INTERNET-DRAFT Expires: May 2002 November 2001 4.4.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.6) 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 indicate that the router does not need to join the (*,*,RP) tree for this RP. Joined The downstream state-machines indicate that the router would like to join the (*,*,RP) tree for this RP. In addition, one timer JT(*,*,RP) is kept which is used to trigger the sending of a Join(*,*,RP) to the upstream next hop towards the RP, MRIB.next_hop(RP). +-----------------------------------+ | Figures omitted from text version | +-----------------------------------+ Figure 6: Upstream (*,*,RP) state-machine Fenner/Handley/Holbrook/Kouvelas Section 4.4.5. [Page 51] INTERNET-DRAFT Expires: May 2002 November 2001 In tabular form, the state machine is: +-------------------+---------------------------------------------------+ | | Event | | Prev State +--------------------------+------------------------+ | | JoinDesired(*,*,RP) | JoinDesired(*,*,RP) | | | ->True | ->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 | to | | | MRIB.next_hop(RP) | MRIB.next_hop(RP) | +-----------------+----------------------+------------------------------+ | Send | Increase Join | Decrease Join | | Join(*,*,RP); | Timer to | Timer to | | Set Join Timer | t_joinsuppress | t_override | | to t_periodic | | | +-----------------+----------------------+------------------------------+ +-----------------------------------------------------------------------+ | In Joined (J) State | +-----------------------------------+-----------------------------------+ | MRIB.next_hop(RP) | MRIB.next_hop(RP) GenID | | 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 | | +-----------------------------------+-----------------------------------+ Fenner/Handley/Holbrook/Kouvelas Section 4.4.5. [Page 52] INTERNET-DRAFT Expires: May 2002 November 2001 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 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: 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 MRIB.next_hop(RP). Cancel the Join Timer (JT). Join Timer Expires The Join Timer (JT) expires, indicating time to send a Join(*,*,RP) Fenner/Handley/Holbrook/Kouvelas Section 4.4.5. [Page 53] INTERNET-DRAFT Expires: May 2002 November 2001 Send Join(*,*,RP) to the appropriate upstream neighbor, which is 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 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 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. 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 Prune(*,*,RP) to the old upstream neighbor, which is the old value of MRIB.next_hop(RP). Send Join(*,*,RP) to the new upstream neighbor which is the new value of MRIB.next_hop(RP). 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. Fenner/Handley/Holbrook/Kouvelas Section 4.4.5. [Page 54] INTERNET-DRAFT Expires: May 2002 November 2001 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.4.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.6) 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. 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 (*,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 would like to join the RP tree for this group. In addition, one timer JT(*,G) is kept which is used to trigger the sending of a Join(*,G) to the upstream next hop towards the RP, RPF'(*,G). +-----------------------------------+ | Figures omitted from text version | +-----------------------------------+ Figure 7: Upstream (*,G) state-machine Fenner/Handley/Holbrook/Kouvelas Section 4.4.6. [Page 55] INTERNET-DRAFT Expires: May 2002 November 2001 In tabular form, the state machine is: +--------------------++-------------------------------------------------+ | || 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 |See |See |RPF'(*,G) | RPF'(*,G) | |Expires |Join(*,G) to |Prune(*,G) |changes | changes due | | |RPF'(*,G) |to RPF'(*,G) | | to Assert | +------------+----------------+--------------+------------+-------------+ |Send |Increase |Decrease |Decrease | Send | |Join(*,G); |Join Timer |Join Timer |Join Timer | Join(*,G); | |Set Join |to |to |to | Set Join | |Timer to |t_joinsuppress |t_override |t_override | Timer to | |t_periodic | | | | t_periodic | +------------+----------------+--------------+------------+-------------+ +-----------------------------------------------------------------------+ | In Joined (J) State | +----------------------------------+------------------------------------+ | MRIB.next_hop(RP(G)) | RPF'(*,G) GenID changes | | changes | | +----------------------------------+------------------------------------+ | Send Join(*,G) to new | Decrease Join Timer to | | next hop; Send | t_override | | Prune(*,G) to old next | | | hop; Set Join Timer to | | | t_periodic | | +----------------------------------+------------------------------------+ Fenner/Handley/Holbrook/Kouvelas Section 4.4.6. [Page 56] INTERNET-DRAFT Expires: May 2002 November 2001 This state machine uses the following macro: bool JoinDesired(*,G) { if (immediate_olist(*,G) != NULL || (JoinDesired(*,*,RP(G)) && 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 downstream state for (*,G) has changed so that at least one interface is in immediate_olist(*,G), making JoinDesired(*,G) become True. 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. 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 downstream state for (*,G) has changed so no interface is in immediate_olist(*,G), making JoinDesired(*,G) become False. 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) Fenner/Handley/Holbrook/Kouvelas Section 4.4.6. [Page 57] INTERNET-DRAFT Expires: May 2002 November 2001 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