idnits 2.17.00 (12 Aug 2021) /tmp/idnits18469/draft-ietf-pim-dm-new-v2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 49 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of lines with control characters in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 398: '...st, an RPF check MUST be performed to ...' RFC 2119 keyword, line 400: '...ts that fail the RPF check MUST NOT be...' RFC 2119 keyword, line 403: '...cannot be found MUST be discarded....' RFC 2119 keyword, line 434: '...s, the Hello Timer (HT) MUST be set to...' RFC 2119 keyword, line 439: '...ge, a Hello message MUST be sent every...' (156 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2002) is 7399 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 2479, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2482, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2497, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 2504, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '2') == Outdated reference: draft-ietf-pim-sm-v2-new has been published as RFC 4601 -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2434 (ref. '7') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301) == Outdated reference: A later version (-04) exists of draft-holbrook-ssm-00 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: draft-ietf-idmr-igmp-v3 has been published as RFC 3376 ** Downref: Normative reference to an Informational RFC: RFC 2715 (ref. '11') ** Downref: Normative reference to an Experimental RFC: RFC 2934 (ref. '12') ** Obsolete normative reference: RFC 2460 (ref. '13') (Obsoleted by RFC 8200) == Outdated reference: draft-ietf-pim-bidir has been published as RFC 5015 == Outdated reference: draft-ietf-pim-sm-bsr has been published as RFC 5059 == Outdated reference: draft-ietf-msec-gdoi has been published as RFC 3547 Summary: 15 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force PIM WG 2 INTERNET DRAFT Andrew Adams (NextHop Technolgies) 3 draft-ietf-pim-dm-new-v2-01.txt Jonathan Nicholas (ITT A/CD) 4 William Siadak (NextHop Technologies) 5 February 15, 2002 7 Protocol Independent Multicast - Dense Mode (PIM-DM): 8 Protocol Specification (Revised) 10 Status of this Document 12 This document is an Internet Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. 15 Internet Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt. 27 The list of Internet Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is a product of the IETF PIM WG. Comments should be 31 addressed to the authors, or the WG's mailing list at 32 pim@catarina.usc.edu. 34 Abstract 36 This document specifies Protocol Independent Multicast - Dense Mode 37 (PIM-DM). PIM-DM is a multicast routing protocol that uses the 38 underlying unicast routing information base to flood multicast datagrams 39 to all multicast routers. Prune messages are used to prevent future 40 messages from propagating to routers with no group membership 41 information. 43 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 4. Pseudocode Notation . . . . . . . . . . . . . . . . . . . . . . . 3 48 5. PIM-DM Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 49 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . . . 5 50 6.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . . . 5 51 6.1.1. General Purpose State . . . . . . . . . . . . . . . . . . . . 6 52 6.1.2. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 6.1.3. State Summarization Macros . . . . . . . . . . . . . . . . . . 7 54 6.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . . . 8 55 6.3. Hello Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 6.3.1. Sending Hello Messages . . . . . . . . . . . . . . . . . . . . 9 57 6.3.2. Receiving Hello Messages . . . . . . . . . . . . . . . . . . . 9 58 6.3.3. Hello Message Hold Time . . . . . . . . . . . . . . . . . . . 9 59 6.3.4. Handling Router Failures . . . . . . . . . . . . . . . . . . . 10 60 6.3.5. Reducing Prune Propagation Delay on LANs . . . . . . . . . . 11 61 6.4. PIM-DM Prune, Join and Graft Messages . . . . . . . . . . . . . 11 62 6.4.1. Upstream Prune, Join and Graft Messages . . . . . . . . . . . 11 63 6.4.2. Downstream Prune, Join and Graft Messages . . . . . . . . . . 17 64 6.5. State Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 21 65 6.5.1. Forwarding of State Refresh Messages . . . . . . . . . . . . . 21 66 6.5.2. State Refresh Message Origination . . . . . . . . . . . . . . 22 67 6.6. PIM Assert Messages . . . . . . . . . . . . . . . . . . . . . . 25 68 6.6.1. Assert Metrics . . . . . . . . . . . . . . . . . . . . . . . . 25 69 6.6.2. AssertCancel Messages . . . . . . . . . . . . . . . . . . . . 26 70 6.6.3. Assert State Macros . . . . . . . . . . . . . . . . . . . . . 26 71 6.6.4. (S,G) Assert Message State Machine . . . . . . . . . . . . . . 26 72 6.6.5. Rationale for Assert Rules . . . . . . . . . . . . . . . . . . 31 73 6.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31 74 6.7.1. PIM Header . . . . . . . . . . . . . . . . . . . . . . . . . . 31 75 6.7.2. Encoded Unicast Address . . . . . . . . . . . . . . . . . . . 32 76 6.7.3. Encoded Group Address . . . . . . . . . . . . . . . . . . . . 32 77 6.7.4. Encoded Source Address . . . . . . . . . . . . . . . . . . . . 34 78 6.7.5. Hello Message Format . . . . . . . . . . . . . . . . . . . . . 35 79 6.7.6. Join/Prune Message Format . . . . . . . . . . . . . . . . . . 37 80 6.7.7. Assert Message Format . . . . . . . . . . . . . . . . . . . . 39 81 6.7.8. Graft Message Format . . . . . . . . . . . . . . . . . . . . . 39 82 6.7.9. Graft Ack Message Format . . . . . . . . . . . . . . . . . . . 39 83 6.6.10. State Refresh Message Format . . . . . . . . . . . . . . . . 40 84 6.8. PIM-DM Timers . . . . . . . . . . . . . . . . . . . . . . . . . 41 85 6.8.1. Timer Values . . . . . . . . . . . . . . . . . . . . . . . . . 42 86 7. Protocol Interaction Considerations . . . . . . . . . . . . . . . 43 87 7.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . . . . . 44 88 7.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . . . . . 44 89 7.3. Source Specific Multicast (SSM) Interactions . . . . . . . . . . 44 90 7.4. Multicast Group Scope Boundary Interactions . . . . . . . . . . 45 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 45 92 8.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . . . 45 93 8.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . . 45 94 9. Security Considerations. . . . . . . . . . . . . . . . . . . . . . 45 95 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 99 1. Introduction 101 This specification defines a multicast routing algorithm for multicast 102 groups that are densely distributed across a network. This protocol 103 does not have a topology discovery mechanism often used by a unicast 104 routing protocol. It employs the same packet formats sparse mode PIM 105 (PIM-SM) uses. This protocol is called PIM - Dense Mode. The 106 foundation of this design was largely built on Deering's early work on 107 IP multicast routing [1]. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be 113 interpreted as described in RFC 2119 and indicate requirement levels for 114 compliant PIM-DM implementations. 116 3. Definitions 118 Multicast Routing Information Base (MRIB) 119 This is the multicast topology table, which is typically derived from 120 the unicast routing table, or routing protocols such as MBGP that 121 carry multicast-specific topology information. PIM-DM uses the MRIB 122 to make decisions regarding RPF interfaces. 124 Tree Information Base (TIB) 125 This is the collection of state maintained by a PIM router and created 126 by receiving PIM messages and IGMP information from local hosts. It 127 essentially stores the state of all multicast distribution trees at 128 that router. 130 Reverse Path Forwarding (RPF) 131 RPF is a multicast forwarding mode where a data packet is accepted for 132 forwarding if it is received on an interface used to reach the source 133 in unicast. 135 Upstream Interface 136 Interface towards the source of the datagram. Also known as the RPF 137 Interface. 139 Downstream Interface 140 All interfaces that are not the upstream interface, including the 141 router itself. 143 (S,G) Pair 144 Source S and destination group G associated with an IP packet. 146 4. Pseudocode Notation 148 We use set notation in several places in this specification. 150 A (+) B 151 is the union of two sets A and B. 153 A (-) B 154 are the elements of set A that are not in set B. 156 NULL 157 is the empty set or list. 159 Note that (+) and (-) operators are NOT commutative, and must be 160 conducted in the order specified. 162 In addition we use C-like syntax: 163 = denotes assignment of a variable. 164 == denotes a comparison for equality. 165 != denotes a comparison for inequality. 167 Braces { and } are used for grouping. 169 5. PIM-DM Protocol Overview 171 This section provides an overview of PIM-DM behavior. It is intended as 172 an introduction to how PIM-DM works, and is NOT definitive. For the 173 definitive specification, see Section 6 - Protocol Specification. 175 PIM-DM assumes that when a source starts sending, all downstream systems 176 want to receive multicast datagrams. Initially, multicast datagrams are 177 flooded to all areas of the network. PIM-DM uses RPF to prevent looping 178 of multicast datagrams while flooding. If some areas of the network do 179 not have group members, PIM-DM will prune off the forwarding branch by 180 instantiating prune state. 182 Prune state has a finite lifetime. When that lifetime expires, data 183 will again be forwarded down the previously pruned branch. 185 Prune state is associated with an (S,G) pair. When a new member for a 186 group G appears in a pruned area, a router can "graft" toward the source 187 S for the group, thereby turning the pruned branch back into a 188 forwarding branch. 190 The broadcast of datagrams followed by pruning of unwanted branches is 191 often referred to as a flood and prune cycle and is typical of dense 192 mode protocols. 194 In order to minimize repeated flooding of datagrams and subsequent 195 pruning associated with a particular (S,G) pair, PIM-DM uses a state 196 refresh message. This message is sent by the router(s) directly 197 connected to the source and is propagated throughout the network. When 198 received by a router on its RPF interface, the state refresh message 199 causes an existing prune state to be refreshed. 201 Compared with multicast routing protocols with built in topology 202 discovery mechanisms (e.g. DVMRP [2]) PIM-DM has a simplified design and 203 is not hard-wired into a specific topology discovery protocol. However, 204 such a simplification does incur more overhead by causing flooding and 205 pruning to occur on some links that could be avoided if sufficient 206 topology information were available, i.e. to decide whether an interface 207 leads to any downstream members of a particular group. Additional 208 overhead is chosen in favor of the simplification and flexibility gained 209 by not depending on a specific topology discovery protocol. 211 PIM-DM differs from PIM-SM in two essential ways: 1) There are no 212 periodic joins transmitted, only explicitly triggered prunes and grafts. 213 2) There is no Rendezvous Point (RP). This is particularly important in 214 networks that cannot tolerate a single point of failure. (An RP is the 215 root of a shared multicast distribution tree. For more details see [3]). 217 6. Protocol Specification 219 The specification of PIM-DM is broken into several parts: 221 * Section 6.1 details the protocol state stored. 222 * Section 6.2 specifies the data packet forwarding rules. 223 * Section 6.3 specifies generation and processing of Hello messages. 224 * Section 6.4 specifies the Join, Prune and Graft generation and 225 processing rules. 226 * Section 6.5 specifies the State Refresh generation and forwarding 227 rules. 228 * Section 6.6 specifies the Assert generation and processing rules. 229 * Section 6.7 gives details on PIM-DM Packet Formats. 230 * Section 6.8 summarizes PIM-DM timers and their defaults. 232 6.1 PIM Protocol State 234 This section specifies all the protocol states that a PIM-DM 235 implementation should maintain in order to function correctly. We term 236 this state the Tree Information Base or TIB, as it holds the state of 237 all the multicast distribution trees at this router. In this 238 specification, we define PIM-DM mechanisms in terms of the TIB. 239 However, only a very simple implementation would actually implement 240 packet forwarding operations in terms of this state. Most 241 implementations will use this state to build a multicast forwarding 242 table, which would then be updated when the relevant state in the TIB 243 changes. 245 Although we specify precisely the state to be kept, this does not mean 246 that an implementation of PIM-DM needs to hold the state in this form. 247 This is actually an abstract state definition, which is needed in order 248 to specify the router's behavior. A PIM-DM implementation is free to 249 hold whatever internal state it requires, and will still be conformant 250 with this specification so long as it results in the same externally 251 visible protocol behavior as an abstract router that holds the following 252 state. 254 6.1.1 General Purpose State 256 A router stores the following non-group-specific state: 258 For each interface: 259 Hello Timer (HT) 260 State Refresh Capable 261 LAN Delay Enabled 262 Propagation Delay (PD) 263 Override Interval (OI) 265 Neighbor State: 266 For each neighbor: 267 Information from neighbor's Hello 268 Neighbor's Gen ID. 269 Neighbor's LAN Prune Delay 270 Neighbor's Override Interval 271 Neighbor's State Refresh Capability 272 Neighbor Liveness Timer (NLT) 274 6.1.2 (S,G) State 276 For every source/group pair (S,G), a router stores the following state: 278 (S,G) state: 279 For each interface: 280 Local Membership: 281 State: One of {"NoInfo", "Include"} 283 PIM (S,G) Prune State: 284 State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending" (PP)} 285 Prune Pending Timer (PPT) 286 Prune Timer (PT) 288 (S,G) Assert Winner State: 289 State: One of {"NoInfo" (NI), "I lost Assert" (L), 290 "I won Assert" (W)} 291 Assert Timer (AT) 292 Assert winner's IP Address 293 Assert winner's Assert Metric 295 Upstream interface-specific: 296 Graft/Prune State: 297 State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F), 298 "AckPending" (AP) } 299 GraftRetry Timer (GRT) 300 Override Timer (OT) 301 Prune Limit Timer (PLT) 303 Originator State: 304 Source Active Timer (SAT) 305 State Refresh Timer (SRT) 307 6.1.3 State Summarization Macros 309 Using the state defined above, the following "macros" are defined and 310 will be used in the descriptions of the state machines and pseudocode in 311 the following sections. 313 The most important macros are those defining the outgoing interface list 314 (or "olist") for the relevant state. 316 immediate_olist(S,G) = pim_nbrs (-) prunes(S,G) (+) 317 ( pim_include(*,G) (-) pim_exclude(S,G) ) (+) 318 pim_include(S,G) (-) lost_assert(S,G) (-) 319 boundary(G) 321 olist(S,G) = immediate_olist(S,G) (-) RPF_interface(S) 323 The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces 324 to which traffic might be forwarded or not forwarded because of hosts 325 that are local members on those interfaces. 327 pim_include(*,G) = {all interfaces I such that: 328 local_receiver_include(*,G,I)} 329 pim_include(S,G) = {all interfaces I such that: 330 local_receiver_include(S,G,I)} 331 pim_exclude(S,G) = {all interfaces I such that: 332 local_receiver_exclude(S,G,I)} 334 The macro RPF_interface(S) returns the RPF interface for source S. That 335 is to say, it returns the interface used to reach S as indicated by the 336 MRIB. 338 The macro local_receiver_include(S,G,I) is true if the IGMP module or 339 other local membership mechanism has determined that there are local 340 members on interface I that desire to receive traffic sent specifically 341 by S to G. 343 The macro local_receiver_include(*,G,I) is true if the IGMP module or 344 other local membership mechanism has determined that there are local 345 members on interface I that desire to receive all traffic sent to G. 346 Note that this determination is expected to account for membership joins 347 initiated on or by the router. 349 The macro local_receiver_exclude(S,G,I) is true if 350 local_receiver_include(*,G,I) is true but none of the local members 351 desire to receive traffic from S. 353 The set pim_nbrs is the set of all interfaces on which the router has at 354 least one active PIM neighbor. 356 The set prunes(S,G) is the set of all interfaces on which the router has 357 received Prune(S,G) messages: 359 prunes(S,G) = {all interfaces I such that 360 DownstreamPState(S,G,I) is in Pruned state} 362 The set lost_assert(S,G) is the set of all interfaces on which the 363 router has lost an (S,G) Assert. 365 lost_assert(S,G) = {all interfaces I such that 366 lost_assert(S,G,I) == TRUE} 368 boundary(G) = {all interfaces I with an administratively scoped 369 boundary for group G} 371 The following pseudocode macro definitions are also used in many places 372 in the specification. Basically RPF' is the RPF neighbor towards a 373 source unless a PIM-DM Assert has overridden the normal choice of 374 neighbor. 376 neighbor RPF'(S,G) { 377 if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) { 378 return AssertWinner(S, G, RPF_interface(S) ) 379 } else { 380 return MRIB.next_hop( S ) 381 } 382 } 384 The macro I_Am_Assert_loser(S, G, I) is true if the Assert state machine 385 (in section 6.6) for (S,G) on interface I is in the "I am Assert Loser" 386 state. 388 6.2 Data Packet Forwarding Rules 390 The PIM-DM packet forwarding rules are defined below in pseudocode. 392 iif is the incoming interface of the packet. 393 S is the source address of the packet. 394 G is the destination address of the packet (group address). 395 RPF_interface(S) is the interface the MRIB indicates would be used to 396 route packets to S. 398 First, an RPF check MUST be performed to determine whether the packet 399 should be accepted based on TIB state and the interface on which that 400 the packet arrived. Packets that fail the RPF check MUST NOT be 401 forwarded and the router will conduct an assert process for the (S,G) 402 pair specified in the packet. Packets for which a route to the source 403 cannot be found MUST be discarded. 405 If the RPF check has been passed, an outgoing interface list is 406 constructed for the packet. If this list is not empty, then the packet 407 MUST be forwarded to all listed interfaces. If the list is empty, then 408 the router will conduct a prune process for the (S,G) pair specified in 409 the packet. 411 On receipt on a data packet from S addressed to G on interface iif: 413 if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned) { 414 oiflist = olist(S,G) 415 } else { 416 oiflist = NULL 417 } 418 forward packet on all interfaces in oiflist 420 This pseudocode employs the following "macro" definition: 422 UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in 423 section 6.4.1. 425 6.3 Hello Messages 427 This section describes the generation and processing of Hello messages. 429 6.3.1 Sending Hello Messages 431 PIM-DM uses Hello messages to detect other PIM routers. Hello messages 432 are sent periodically on each PIM enabled interface. Hello messages are 433 multicast to the ALL-PIM-ROUTERS group. When PIM is enabled on an 434 interface or a router first starts, the Hello Timer (HT) MUST be set to 435 random value between 0 and Triggered_Hello_Delay. This prevents 436 synchronization of Hello messages if multiple routers are powered on 437 simultaneously. 439 After the initial Hello message, a Hello message MUST be sent every 440 Hello_Period. A single Hello timer MAY be used to trigger sending 441 Hello messages on all active interfaces. The Hello Timer SHOULD NOT be 442 reset except when it expires. 444 6.3.2 Receiving Hello Messages 446 When a Hello message is received, the receiving router SHALL record the 447 receiving interface, the sender and any information contained in 448 recognized options. This information is retained for a number of 449 seconds in the Hold Time field of the Hello Message. If a new Hello 450 message is received from a particular neighbor N, the Neighbor Liveness 451 Timer (NLT(N,I)) MUST be reset to the newly received Hello Holdtime. If 452 a Hello message is received from a new neighbor, the receiving router 453 SHOULD send its own Hello message after a random delay between 0 and 454 Triggered_Hello_Delay. 456 6.3.3 Hello Message Hold Time 458 The Hold Time in the Hello Message should be set to a value that can 459 reasonably be expected to keep the Hello active until a new Hello 460 message is received. On most links, this will be 3.5 times the value of 461 Hello_Period. 463 If the Hold Time is set to '0xffff', the receiving router MUST NOT time 464 out that Hello message. This feature might be used for on-demand links 465 to avoid keeping the link up with periodic Hello messages. 467 If a Hold Time of '0' is received, the corresponding neighbor state is 468 expired immediately. When a PIM router takes an interface down or 469 changes IP address, a Hello message with a zero Hold Time SHOULD be sent 470 immediately (with the old IP address if the IP address is changed) to 471 cause any PIM neighbors to remove the old information immediately. 473 6.3.4 Handling Router Failures 475 If a Hello message is received from an active downstream neighbor with 476 a different Generation ID (GenID), the neighbor has restarted and may 477 not contain the correct (S,G) state. A Hello message SHOULD be sent 478 after a random delay between 0 and Triggered_Hello_Delay (see 6.8.1) 479 before any other messages are sent. The router MAY replay the last 480 State Refresh message for any (S,G) pairs for which it is the Assert 481 Winner indicating Prune and Assert status to the downstream router. 482 These State Refresh messages SHOULD be sent out immediately after the 483 Hello message. 485 Upon startup, a router MAY use any State Refresh messages received 486 within Hello_Period of its first Hello message on an interface to 487 establish state information. The State Refresh source will be the 488 RPF'(S), and Prune status for all interfaces will be set according to 489 the Prune Indicator bit in the State Refresh message. If the Prune 490 Indicator is set, the router SHOULD set the PruneLimitTimer to 491 Prune_Holdtime and set the PruneTimer on all downstream interfaces to 492 the State Refresh's Interval times two. The router SHOULD then 493 propagate the State Refresh as described in section 6.5.1. 495 6.3.5 Reducing Prune Propagation Delay on LANs 497 If all routers on a LAN support the LAN Prune Delay option, then the PIM 498 routers on that LAN will use the values received to adjust its 499 J/P_Override_Interval on that interface and the interface is LAN Delay 500 Enabled. Briefly, to avoid synchronization of Prune Override (Join) 501 messages when multiple downstream routers share a multi-access link, 502 sending of such messages is delayed by a small random amount of time. 503 The period of randomization is configurable and has a default value of 3 504 seconds. 506 Each router on the LAN expresses its view of the amount of randomization 507 necessary in the Override Interval field of the LAN Prune Delay option. 508 When all routers on a LAN use the LAN Prune Delay Option, all routers on 509 the LAN MUST set their Override_Interval to the largest Override value 510 on the LAN. 512 The LAN Delay inserted by a router in the LAN Prune Delay option 513 expresses the expected message propagation delay on the link and SHOULD 514 be configurable by the system administrator. When all routers on a link 515 use the LAN Prune Delay Option, all routers on the LAN MUST set 516 Propagation Delay to the largest LAN Delay on the LAN. 518 PIM implementers should enforce a lower bound on the permitted values 519 for this delay to allow for scheduling and processing delays within 520 their router. Such delays may cause received messages to be processed 521 later as well as triggered messages to be sent later than intended. 522 Setting this LAN Prune Delay to too low a value may result in temporary 523 forwarding outages because a downstream router will not be able to 524 override a neighbor's prune message before the upstream neighbor stops 525 forwarding. 527 6.4 PIM-DM Prune, Join and Graft Messages 529 This section describes the generation and processing of PIM-DM Join, 530 Prune and Graft messages. Prune messages are sent towards the upstream 531 neighbor for S to indicate that traffic from S addressed to group G is 532 not desired. In the case of two downstream routers A and B, where A 533 wishes to continue receiving data and B does not, A will send a Join in 534 response to B's Prune to override the Prune. This is the only situation 535 in PIM-DM in which a Join message is used. Finally, a Graft message is 536 used to re-join a previously pruned branch to the delivery tree. 538 6.4.1 Upstream Prune, Join and Graft Messages 540 The Upstream(S,G) state machine for sending Prune, Graft and Join 541 messages is given below. There are three states. 543 Forwarding (F) 544 This is the starting state of the Upsteam(S,G) state machine. The 545 state machine is in this state if it just started or if 546 oiflist(S,G) != NULL. 548 Pruned(P) 549 The set, olist(S,G), is empty. The router will not forward data 550 from S addressed to group G. 552 AckPending(AP) 553 The router was in the Pruned(P) state but a transition has occurred 554 in the Downstream(S,G) state machine for one of this (S,G) entry's 555 outgoing interfaces indicating that traffic from S addressed to G 556 should again be forwarded. A Graft message has been sent to RPF'(S) 557 but a Graft Ack message has not yet been received. 559 In addition there are three state-machine-specific timers: 561 GraftRetry Timer (GRT(S,G)) 562 This timer is set when a Graft is sent upstream. If a corresponding 563 GraftAck is not received before the timer expires, then another 564 Graft is sent and the GraftRetry Timer is reset. The timer is 565 stopped when a Graft Ack message is received. This timer is normally 566 set to Graft_Retry_Period (see 6.8.1). 568 Override Timer (OT(S,G)) 569 This timer is set when a Prune(S,G) is received on the upstream 570 interface where olist(S,G) != NULL. When the timer expires, a 571 Join(S,G) message is sent on the upstream interface. This timer is 572 normally set to t_override (see 6.8.1). 574 Prune Limit Timer (PLT(S,G)) 575 This timer is used to rate-limit Prunes on a LAN. It is only used 576 when the Upstream(S,G) state machine is in the Pruned state. A Prune 577 cannot be sent if this timer is running. This timer is normally set 578 to t_limit (see 6.8.1) 580 +-------------+ +-------------+ 581 | | olist == NULL | | 582 | Forward |----------------------->| Pruned | 583 | | | | 584 +-------------+ +-------------+ 585 ^ | ^ | 586 | | | | 587 | |RPF`(S) Changes olist == NULL| | 588 | | | | 589 | | +-------------+ | | 590 | +-------->| |----------+ | 591 | | AckPending | | 592 +-------------| |<-------------+ 593 Rcv GraftAck OR +-------------+ olist != NULL 594 Rcv State Refresh 595 With (P==0) OR 596 S Directly Connect 598 Figure 1: Upstream Interface State Machine 600 In tabular form, the state machine is defined as follows: 602 +-------------------------------+--------------------------------------+ 603 | | Previous State | 604 | +------------+------------+------------+ 605 | Event | Forwarding | Pruned | AckPending | 606 +-------------------------------+------------+------------+------------+ 607 | Data packet arrives on | ->P Send | ->P Send | N/A | 608 | RPF_Interface(S) AND | Prune(S,G) | Prune(S,G) | | 609 | olist(S,G) == NULL AND |Set PLT(S,G)|Set PLT(S,G)| | 610 | PLT(S,G) not running | | | | 611 +-------------------------------+------------+------------+------------+ 612 | State Refresh(S,G) received | ->F Set | ->P Reset |->AP Set | 613 | from RPF`(S) AND | OT(S,G) | PLT(S,G) | OT(S,G) | 614 | Prune Indicator == 1 | | | | 615 +-------------------------------+------------+------------+------------+ 616 | State Refresh(S,G) received | ->F | ->P Send |->F Cancel | 617 | from RPF`(S) AND | | Prune(S,G) | GRT(S,G) | 618 | Prune Indicator == 0 AND | |Set PLT(S,G)| | 619 | PLT(S,G) not running | | | | 620 +-------------------------------+------------+------------+------------+ 621 | See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel | 622 | | OT(S,G) | | OT(S,G) | 623 +-------------------------------+------------+------------+------------+ 624 | See Prune(S,G) | ->F Set | ->P |->AP Set | 625 | | OT(S,G) | | OT(S,G) | 626 +-------------------------------+------------+------------+------------+ 628 +-------------------------------+--------------------------------------+ 629 | | Previous State | 630 | +------------+------------+------------+ 631 | Event | Forwarding | Pruned | AckPending | 632 +-------------------------------+------------+------------+------------+ 633 | OT(S,G) Expires | ->F Send | N/A |->AP Send | 634 | | Join(S,G) | | Join(S,G) | 635 +-------------------------------+------------+------------+------------+ 636 | olist(S,G)->NULL | ->P Send | N/A |->P Send | 637 | | Prune(S,G) | | Prune(S,G) | 638 | |Set PLT(S,G)| |Set PLT(S,G)| 639 | | | | Cancel | 640 | | | | GRT(S,G) | 641 +-------------------------------+------------+------------+------------+ 642 | olist(S,G)->non-NULL | N/A | ->AP Send | N/A | 643 | | | Graft(S,G) | | 644 | | |Set GRT(S,G)| | 645 +-------------------------------+------------+------------+------------+ 646 | RPF'(S) Changes AND | ->AP Send | ->AP Send |->AP Send | 647 | olist(S,G) != NULL | Graft(S,G) | Graft(S,G) | Graft(S,G) | 648 | |Set GRT(S,G)|Set GRT(S,G)|Set GRT(S,G)| 649 +-------------------------------+------------+------------+------------+ 650 | RPF'(S) Changes AND | ->P | ->P Cancel |->P Cancel | 651 | olist(S,G) == NULL | | PLT(S,G) | GRT(S,G) | 652 +-------------------------------+------------+------------+------------+ 653 | S becomes directly connected | ->F | ->P |->F Cancel | 654 | | | | GRT(S,G) | 655 +-------------------------------+------------+------------+------------+ 656 | GRT(S,G) Expires | N/A | N/A |->AP Send | 657 | | | | Graft(S,G) | 658 | | | |Set GRT(S,G)| 659 +-------------------------------+------------+------------+------------+ 660 | Receive GraftAck(S,G) from | ->F | ->P |->F Cancel | 661 | RPF'(S) | | | GRT(S,G) | 662 +-------------------------------+------------+------------+------------+ 664 The transition event "RcvGraftAck(S,G)" implies receiving a Graft Ack 665 message targeted to this router's address on the incoming interface for 666 the (S,G) entry. If the destination address is not correct, the state 667 transitions in this state machine must not occur. 669 Transitions from the Forwarding (F) State 671 When the Upstream(S,G) state machine is in the Forwarding (F) state, the 672 following events may trigger a transition: 674 Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND S 675 NOT directly connected 676 The Upstream(S,G) state machine MUST transition to the Pruned (P) 677 state, send a Prune(S,G) to RPF'(S) and set PLT(S,G) to t_limit 678 seconds. 680 State Refresh(S,G) Received from RPF'(S) 681 The Upstream(S,G) state machine remains in a Forwarding state. If 682 the received State Refresh has the Prune Indicator bit set to one, 683 this router must override the upstream router's Prune state after a 684 short random interval. If OT(S,G) is not running and the Prune 685 Indicator bit equals one, the router MUST set OT(S,G) to t_override 686 seconds. 688 See Join(S,G) to RPF'(S) 689 This event is only relevant if RPF_interface(S) is a shared medium. 690 This router sees another router on RPF_interface(S) send a Join(S,G) 691 to RPF'(S,G). If the OT(S,G) is running, then it means that the 692 router had scheduled a Join to override a previously received Prune. 693 Another router has responded more quickly with a Join and so the 694 local router SHOULD cancel its OT(S,G), if it is running. The 695 Upstream(S,G) state machine remains in the Forwarding (F) state. 697 See Prune(S,G) AND S NOT directly connected 698 This event is only relevant if RPF_interface(S) is a shared medium. 699 This router sees another router on RPF_interface(S) send a 700 Prune(S,G). As this router is in Forwarding state, it must 701 override the Prune after a short random interval. If OT(S,G) is not 702 running, the router MUST set OT(S,G) to t_override seconds. The 703 Upstream(S,G) state machine remains in Forwarding (F) state. 705 OT(S,G) Expires AND S NOT directly connected 706 The OverrideTimer (OT(S,G)) expires. The router MUST send a 707 Join(S,G) to RPF'(S) to override a previously detected prune. The 708 Upstream(S,G) state machine remains in the Forwarding (F) state. 710 olist(S,G) -> NULL AND S NOT directly connected 711 The Upstream(S,G) state machine MUST transition to the Pruned (P) 712 state, send a Prune(S,G) to RPF'(S) and set PLT(S,G) to t_limit 713 seconds. 715 RPF'(S) Changes AND olist(S,G) is non-NULL AND S NOT directly 716 connected 717 Unicast routing or Assert state causes RPF'(S) to change, including 718 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 719 transition to the AckPending (AP) state, unicast a Graft to the new 720 RPF'(S) and set the GraftRetry Timer (GRT(S,G)) to 721 Graft_Retry_Period. 723 RPF'(S) Changes AND olist(S,G) is NULL 724 Unicast routing or Assert state causes RPF'(S) to change, including 725 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 726 transition to the Pruned (P) state. 728 Transitions from the Pruned (P) State 730 When the Upstream(S,G) state machine is in the Pruned (P) state, the 731 following events may trigger a transition: 733 Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT 734 directly connected 735 Either another router on the LAN desires traffic from S addressed to 736 G or a previous Prune was lost. In order to prevent generating a 737 Prune(S,G) in response to every data packet, the PruneLimit Timer 738 (PLT(S,G)) is used. Once the PLT(S,G) expires, the router needs to 739 send another prune in response to a data packet not received 740 directly from the source. A Prune(S,G) MUST be sent to RPF'(S) and 741 the PLT(S,G) MUST be set to t_limit. 743 State Refresh(S,G) Received from RPF'(S) 744 The Upstream(S,G) state machine remains in a Pruned state. If the 745 State Refresh has its Prune Indicator bit set to zero and PLT(S,G) 746 is not running, a Prune(S,G) MUST be sent to RPF'(S) and the 747 PLT(S,G) MUST be set to t_limit. If the State Refresh has its Prune 748 Indicator bit set to one, the router MUST reset PLT(S,G) to t_limit. 750 See Prune(S,G) to RPF'(S) 751 A Prune(S,G) is seen on RPF_interface(S) to RPF'(S). The 752 Upstream(S,G) state machine stays in the Pruned (P) state. The 753 router MAY reset its PLT(S,G) to the value in the Holdtime field of 754 the received message if greater than the current value of the 755 PLT(S,G). 757 olist(S,G)->non-NULL AND S NOT directly connected 758 The set of interfaces defined by the olist(S,G) macro becomes 759 non-empty indicating traffic from S addressed to group G must be 760 forwarded. The Upstream(S,G) state machine MUST cancel PLT(S,G), 761 transition to the AckPending (AP) state and unicast a Graft message 762 to RPF'(S). The Graft Retry Timer (GRT(S,G)) MUST be set to 763 Graft_Retry_Period. 765 RPF'(S) Changes AND olist(S,G) == non-NULL AND S NOT directly 766 connected 767 Unicast routing or Assert state causes RPF'(S) to change, including 768 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 769 cancel PLT(S,G), transition to the AckPending (AP) state, send a 770 Graft unicast to the new RPF'(S) and set the GraftRetry Timer 771 (GRT(S,G)) to Graft_Retry_Period. 773 RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected 774 Unicast routing or Assert state causes RPF'(S) to change, including 775 changes to RPF_Interface(S). The Upstream(S,G) state machine stays 776 in the Pruned (P) state and MUST cancel the PLT(S,G) timer. 778 S becomes directly connected 779 Unicast routing changed so that S is directly connected. The 780 Upstream(S,G) state machine remains in the Pruned (P) state. 782 Transitions from the AckPending (AP) State 784 When the Upstream(S,G) state machine is in the AckPending (AP) state, 785 the following events may trigger a transition: 787 State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 1 788 The Upstream(S,G) state machine remains in an AckPending state. The 789 router must override the upstream router's Prune state after a short 790 random interval. If OT(S,G) is not running and the Prune Indicator 791 bit equals one, the router MUST set OT(S,G) to t_override seconds. 793 State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 0 794 The router MUST cancel its GraftRetry Timer (GRT(S,G)) and 795 transition to the Forwarding (F) state. 797 See Join(S,G) to RPF'(S,G) 798 This event is only relevant if RPF_interface(S) is a shared medium. 799 This router sees another router on RPF_interface(S) send a Join(S,G) 800 to RPF'(S,G). If the OT(S,G) is running, then it means that the 801 router had scheduled a Join to override a previously received Prune. 802 Another router has responded more quickly with a Join and so the 803 local router SHOULD cancel its OT(S,G), if it is running. The 804 Upstream(S,G) state machine remains in the AckPending (AP) state. 806 See Prune(S,G) 807 This event is only relevant if RPF_interface(S) is a shared medium. 808 This router sees another router on RPF_interface(S) send a 809 Prune(S,G). As this router is in AckPending (AP) state, it must 810 override the Prune after a short random interval. If OT(S,G) is not 811 running, the router MUST set OT(S,G) to t_override seconds. The 812 Upstream(S,G) state machine remains in AckPending (AP) state. 814 OT(S,G) Expires 815 The OverrideTimer (OT(S,G)) expires. The router MUST send a 816 Join(S,G) to RPF'(S). The Upstream(S,G) state machine remains in 817 the AckPending (AP) state. 819 olist(S,G) -> NULL 820 The set of interfaces defined by the olist(S,G) macro becomes null 821 indicating traffic from S addressed to group G should no longer be 822 forwarded. The Upstream(S,G) state machine MUST transition to the 823 Pruned (P) state. A Prune(S,G) MUST be multicast to the 824 RPF_interface(S) with RPF'(S) named in the upstream neighbor field. 825 The GraftRetry Timer (GRT(S,G)) MUST be cancelled and PLT(S,G) MUST 826 be set to t_limit seconds. 828 RPF'(S) Changes AND olist(S,G) does not become NULL AND S NOT directly 829 connected 830 Unicast routing or Assert state causes RPF'(S) to change, including 831 changes to RPF_Interface(S). The Upstream(S,G) state machine stays 832 in the AckPending (AP) state. A Graft MUST be unicast to the new 833 RPF'(S) and the GraftRetry Timer (GRT(S,G)) reset to 834 Graft_Retry_Period. 836 RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected 837 Unicast routing or Assert state causes RPF'(S) to change, including 838 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 839 transition to the Pruned (P) state. The GraftRetry Timer (GRT(S,G)) 840 MUST be cancelled. 842 S becomes directly connected 843 Unicast routing has changed so that S is directly connected. The 844 GraftRetry Timer MUST be cancelled and the Upstream(S,G) state 845 machine MUST transition to the Forwarding(F) state. 847 GRT(S,G) Expires 848 The GraftRetry Timer (GRT(S,G)) expires for this (S,G) entry. The 849 Upstream(S,G) state machine stays in the AckPending (AP) state. 850 Another Graft message for (S,G) SHOULD be unicasted to RPF'(S) and 851 the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period. It is 852 RECOMMENDED that the router retry a configured number of times 853 before ceasing retries. 855 See GraftAck(S,G) from RPF'(S) 856 A GraftAck is received from RPF'(S). The GraftRetry Timer MUST be 857 cancelled and the Upstream(S,G) state machine MUST transition to the 858 Forwarding(F) state. 860 6.4.2 Downstream Prune, Join and Graft Messages 862 The Prune(S,G) Downstream state machine for receiving Prune, Join and 863 Graft messages on interface I is given below. This state machine MUST 864 always be in the NoInfo state on the upstream interface. It contains 865 three states. 867 NoInfo(NI) 868 The interface has no (S,G) Prune state and neither the Prune timer 869 (PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is running. 871 PrunePending(PP) 872 The router has received a Prune(S,G) on this interface from a 873 downstream neighbor and is waiting to see whether the prune will be 874 overridden by another downstream router. For forwarding purposes, 875 the PrunePending state functions exactly like the NoInfo state. 877 Pruned(P) 878 The router has received a Prune(S,G) on this interface from a 879 downstream neighbor and the Prune was not overridden. Data from S 880 addressed to group G is no longer being forwarded on this interface. 882 In addition there are two timers: 884 PrunePending Timer (PPT(S,G,I)) 885 This timer is set when a valid Prune(S,G) is received. Expiry of 886 the PrunePending Timer (PPT(S,G,I)) causes the interface to 887 transition to the Pruned state. 889 Prune Timer (PT(S,G,I)) 890 This timer is set when the PrunePending Timer (PT(S,G,I)) expires. 891 Expiry of the Prune Timer (PT(S,G,I)) causes the interface to 892 transition to the NoInfo (NI) state, thereby allowing data from S 893 addressed to group G to be forwarded on the interface. 895 +-------------+ +-------------+ 896 | | PPT Expires | | 897 |PrunePending |----------------------->| Pruned | 898 | | | | 899 +-------------+ +-------------+ 900 | ^ | 901 | | | 902 | |Rcv Prune | 903 | | | 904 | | +-------------+ | 905 | +---------| | | 906 | | NoInfo |<-------------+ 907 +------------>| | Rcv Join/Graft OR 908 Rcv Join/Graft OR +-------------+ PT Expires OR 909 RPF_Interface(S)->I RPF_Interface(S)->I 911 Figure 2: Prune(S,G) Downstream State Machine 913 In tabular form, the state machine is: 915 +-------------------------------+--------------------------------------+ 916 | | Previous State | 917 + +------------+------------+------------+ 918 | Event | No Info | PrunePend | Pruned | 919 +-------------------------------+------------+------------+------------+ 920 | Receive Prune(S,G) |->PP Set |->PP |->P Reset | 921 | | PPT(S,G,I) | | PT(S,G,I) | 922 +-------------------------------+------------+------------+------------+ 923 | Receive Join(S,G) |->NI |->NI Cancel |->NI Cancel | 924 | | | PPT(S,G,I) | PT(S,G,I) | 925 +-------------------------------+------------+------------+------------+ 926 | Receive Graft(S,G) |->NI Send |->NI Send |->NI Send | 927 | | GraftAck | GraftAck | GraftAck | 928 | | | Cancel | Cancel | 929 | | | PPT(S,G,I) | PT(S,G,I) | 930 +-------------------------------+------------+------------+------------+ 931 | PPT(S,G) Expires | N/A |->P Set | N/A | 932 | | | PT(S,G,I) | | 933 +-------------------------------+------------+------------+------------+ 934 | PT(S,G) Expires | N/A | N/A |->NI | 935 +-------------------------------+------------+------------+------------+ 936 | RPF_Interface(S) becomes I |->NI |->NI Cancel |->NI Cancel | 937 | | | PPT(S,G,I) | PT(S,G,I) | 938 +-------------------------------+------------+------------+------------+ 940 The transition events "Receive Graft(S,G)", "Receive Prune(S,G)" and 941 "Receive Join(S,G)" denote receiving a Graft, Prune or Join message in 942 which this router's address on I is contained in the message's upstream 943 neighbor field. If the upstream neighbor field does not match this 944 router's address on I, then these state transitions in this state 945 machine must not occur. 947 Transitions from the NoInfo State 949 When the Prune(S,G) Downstream state machine is in the NoInfo (NI) 950 state, the following events may trigger a transition: 952 Receive Prune(S,G) 953 A Prune(S,G) is received on interface I with the upstream neighbor 954 field set to the router's address on I. The Prune(S,G) Downstream 955 state machine on interface I MUST transition to the PrunePending 956 (PP) state. The PrunePending Timer (PPT(S,G,I)) MUST be set to 957 J/P_Override_Interval if the router has more than one neighbor on I. 958 If the router has only one neighbor on interface I, then it SHOULD 959 set the PPT(S,G,I) to zero, effectively transitioning immediately to 960 the Pruned (P) state. 962 Receive Graft(S,G) 963 A Graft(S,G) is received on the interface I with the upstream 964 neighbor field set to the router's address on I. The Prune(S,G) 965 Downstream state machine on interface I stays in the NoInfo (NI) 966 state. A GraftAck(S,G) MUST be unicasted to the originator of the 967 Graft(S,G) message. 969 Transitions from the PrunePending (PP) State 971 When the Prune(S,G) downstream state machine is in the PrunePending (PP) 972 state, the following events may trigger a transition. 974 Receive Join(S,G) 975 A Join(S,G) is received on interface I with the upstream neighbor 976 field set to the router's address on I. The Prune(S,G) Downstream 977 state machine on interface I MUST transition to the NoInfo (NI) 978 state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. 980 Receive Graft(S,G) 981 A Graft(S,G) is received on interface I with the upstream neighbor 982 field set to the router's address on I. The Prune(S,G) Downstream 983 state machine on interface I MUST transition to the NoInfo (NI) 984 state and MUST unicast a Graft Ack message to the Graft originator. 985 The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. 987 PPT(S,G,I) Expires 988 The PrunePending Timer (PPT(S,G,I)) expires indicating that no 989 neighbors have overridden the previous Prune(S,G) message. The 990 Prune(S,G) Downstream state machine on interface I MUST transition 991 to the Pruned (P) state. The Prune Timer (PT(S,G,I)) is started and 992 MUST be initialized to the received Prune_Hold_Time minus 993 J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has 994 more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G) 995 message multicast by the upstream router to a LAN with itself as the 996 Upstream Neighbor. Its purpose is to add additional reliability so 997 that if a Join that should have overridden the Prune is lost locally 998 on the LAN, then the PruneEcho(S,G) may be received and trigger a 999 new Join message . A PruneEcho(S,G) is OPTIONAL on an interface 1000 with only one PIM neighbor. 1002 RPF_Interface(S) becomes interface I 1003 The upstream interface for S has changed. The Prune(S,G) Downstream 1004 state machine on interface I MUST transition to the NoInfo (NI) 1005 state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. 1007 Transitions from the Prune (P) State 1009 When the Prune(S,G) Downstream state machine is in the Pruned (P) state, 1010 the following events may trigger a transition. 1012 Receive Prune(S,G) 1013 A Prune(S,G) is received on the interface I with the upstream 1014 neighbor field set to the router's address on I. The Prune(S,G) 1015 Downstream state machine on interface I remains in the Pruned (P) 1016 state. The Prune Timer (PT(S,G,I)) SHOULD be reset to the holdtime 1017 contained in the Prune(S,G) message if it is greater than the 1018 current value. 1020 Receive Join(S,G) 1021 A Join(S,G) is received on the interface I with the upstream 1022 neighbor field set to the router's address on I. The Prune(S,G) 1023 downstream state machine on interface I MUST transition to the 1024 NoInfo (NI) state. The Prune Timer (PT(S,G,I)) MUST be cancelled. 1025 The router MUST evaluate any possible transitions in the 1026 Upstream(S,G) state machine. 1028 Receive Graft(S,G) 1029 A Graft(S,G) is received on interface I with the upstream neighbor 1030 field set to the router's address on I. The Prune(S,G) Downstream 1031 state machine on interface I MUST transition to the NoInfo (NI) 1032 state and send a Graft Ack back to the Graft's source. The Prune 1033 Timer (PT(S,G,I)) MUST be cancelled. The router MUST evaluate any 1034 possible transitions in the Upstream(S,G) state machine. 1036 PT(S,G,I) Expires 1037 The Prune Timer (PT(S,G,I)) expires indicating that it is again time 1038 to flood data from S addressed to group G onto interface I. The 1039 Prune(S,G) Downstream state machine on interface I MUST transition 1040 to the NoInfo (NI) state. The router MUST evaluate any possible 1041 transitions in the Upstream(S,G) state machine. 1043 RPF_Interface(S) becomes interface I 1044 The upstream interface for S has changed. The Prune(S,G) Downstream 1045 state machine on interface I MUST transition to the NoInfo (NI) 1046 state. The PruneTimer (PT(S,G,I)) MUST be cancelled. 1048 6.5 State Refresh 1050 This section describes the major portions of the state refresh 1051 mechanism. 1053 6.5.1 Forwarding of State Refresh Messages 1055 When a State Refresh message, SRM, is received, it is forwarded 1056 according to the following pseudo-code. 1058 if (iif != RPF_interface(S)) 1059 return; 1060 if (RPF'(S) != srcaddr(SRM)) 1061 return; 1062 if (StateRefreshRateLimit(S,G) == TRUE) 1063 return; 1065 for each interface I in pim_nbrs { 1066 if (TTL(SRM) == 0 OR (TTL(SRM) - 1) < Threshold(I)) 1067 continue; /* Out of TTL, skip this interface */ 1068 if (boundary(I,G)) 1069 continue; /* This interface is scope boundary, skip it */ 1070 if (I == iif) 1071 continue; /* This is the incoming interface, skip it */ 1072 if (lost_assert(S,G,I) == TRUE) 1073 continue; /* Let the Assert Winner do State Refresh */ 1075 Copy SRM to SRM'; /* Make a copy of SRM to forward */ 1077 if (I contained in prunes(S,G)) { 1078 set Prune Indicator bit of SRM' to 1; 1080 if StateRefreshCapable(I) == TRUE 1081 set PT(S,G) to largest active holdtime read from a Prune message 1082 accepted on I; 1084 } else { 1085 set Prune Indicator bit of SRM' to 0; 1086 } 1088 set srcaddr(SRM') to my_addr(I); 1089 set TTL of SRM' to TTL(SRM) - 1; 1090 set metric of SRM' to metric of unicast route used to reach S; 1091 set pref of SRM' to preference of unicast route used to reach S; 1092 set mask of SRM' to mask of route used to reach S; 1094 if (AssertState == NoInfo) { 1095 set Assert Override of SRM' to 1; 1096 } else { 1097 set Assert Override of SRM' to 0; 1098 } 1100 transmit SRM' on I; 1101 } 1103 The pseudocode above employs the following macro definitions. 1105 Boundary(I,G) evaluates to TRUE if an administratively scoped boundary 1106 for group G is configured on interface I. 1108 StateRefreshCapable(I) evaluates to TRUE if all neighbors on an 1109 interface use the State Refresh option. 1111 StateRefreshRateLimit(S,G) evaluates to TRUE if the time elapsed since 1112 the last received StateRefresh(S,G) is less than the configured 1113 RefreshLimitInterval. 1115 TTL(SRM) returns the TTL contained in the State Refresh Message, SRM. 1116 This is different from the TTL contained in the IP header. 1118 Threshold(I) returns the minimum TTL that a packet must have before it 1119 can be transmitted on interface I. 1121 srcaddr(SRM) returns the source address contained in the network 1122 protocol (e.g. IPv4) header of the State Refresh Message, SRM. 1124 my_addr(I) returns this node's network (e.g. IPv4) address on interface 1125 I. 1127 6.5.2 State Refresh Message Origination 1129 This section describes the origination of State Refresh messages. These 1130 messages are generated periodically by the PIM-DM router that is 1131 directly connected to a source. One Origination(S,G) state machine 1132 exists per (S,G) entry in a PIM-DM router. 1134 The Origination(S,G) state machine has the following states: 1136 NotOriginator(NO) 1137 This is the starting state of the Origination(S,G) state machine. 1138 While in this state a router will not originate State Refresh 1139 messages for the (S,G) pair. 1141 Originator(O) 1142 When in this state the router will periodically originate State 1143 Refresh messages. Only routers which are directly connected to S 1144 may transition to this state. 1146 In addition there are two state-machine-specific timers: 1148 StateRefresh Timer (SRT(S,G)) 1149 This timer is controls when State Refresh messages are generated. 1150 The timer is initially set when that Origination(S,G) state machine 1151 transitions to the O state. It is cancelled when the 1152 Origination(S,G) state machine transitions to the NO state. This 1153 timer is normally set to StateRefreshInterval (see 6.8.1). 1155 SourceActive Timer (SAT(S,G)) 1156 This timer is first set when the Origination(S,G) state machine 1157 transitions to the O state and is reset on the receipt of every 1158 data packet from S addressed to group G. When it expires, the 1159 Origination(S,G) state machine transitions to the NO state. This 1160 timer is normally set to SourceLifetime (see 6.8.1). 1162 +-------------+ Rcv Directly From S +-------------+ 1163 | |----------------------->| | 1164 |NotOriginator| | Originator | 1165 | |<-----------------------| | 1166 +-------------+ SAT Expires OR +-------------+ 1167 S NOT Direct Connect 1169 Figure 3: Per-interface State Refresh State Diagram 1171 In tabular form, the state machine is defined as follows: 1173 +----------------------------------------------------------------------+ 1174 | | Previous State | 1175 | +---------------+-------------------+ 1176 | Event | NotOriginator | Originator | 1177 +----------------------------------+---------------+-------------------+ 1178 | Receive Data from S AND | ->O | ->O Reset | 1179 | S directly connected | Set SRT(S,G) | SAT(S,G) | 1180 | | Set SAT(S,G) | | 1181 +----------------------------------+---------------+-------------------+ 1182 | SRT(S,G) Expires | N/A | ->O Send | 1183 | | | StateRefresh(S,G) | 1184 | | | Reset SRT(S,G) | 1185 +----------------------------------+---------------+-------------------+ 1186 | SAT(S,G) Expires | N/A | ->NO Cancel | 1187 | | | SRT(S,G) | 1188 +----------------------------------+---------------+-------------------+ 1189 | S no longer directly connected | ->NO | ->NO | 1190 | | | Cancel SRT(S,G) | 1191 | | | Cancel SAT(S,G) | 1192 +----------------------------------+---------------+-------------------+ 1194 Transitions from the NotOriginator (NO) State 1196 When the Originating(S,G) state machine is in the NotOriginator (NO) 1197 state, the following event may trigger a transition: 1199 Data Packet received from directly connected Source S addressed to 1200 group G 1201 The router MUST transition to an Originator (O) state, set SAT(S,G) 1202 to SourceLifetime, and set SRT(S,G) to StateRefreshInterval. The 1203 router SHOULD record the TTL of the packet for use in State Refresh 1204 messages. 1206 Transitions from the Originator (O) State 1208 When the Originating(S,G) state machine is in the Originator (O) state, 1209 the following events may trigger a transition: 1211 Receive Data Packet from S addressed to G 1212 The router remains in the Originator (O) state and MUST reset 1213 SAT(S,G) to SourceLifetime. The router SHOULD increase its recorded 1214 TTL to match the TTL of the packet, if the packet's TTL is larger 1215 than the previously recorded TTL. 1217 SRT(S,G) Expires 1218 The router remains in the Originator (O) state and MUST reset 1219 SRT(S,G) to StateRefreshInterval. The router MUST also generate 1220 State Refresh messages for transmission as described in the State 1221 Refresh Forwarding rules (section 6.5.1) except for the TTL. If the 1222 TTL of data packets from S to G are being recorded, then the TTL of 1223 each State Refresh message is set to the highest recorded TTL. 1224 Otherwise, the TTL is set to the configured State Refresh TTL. Let 1225 I denote the interface over which a State Refresh message is being 1226 sent. If the Prune(S,G) Downstream state machine for I is in the 1227 NoInfo (NI) state, then the Prune-Indicator bit MUST be set to 0 in 1228 the State Refresh message being sent over I. Otherwise the 1229 Prune-Indicator bit MUST be set to 1. 1231 SAT(S,G) Expires 1232 The router MUST cancel the SRT(S,G) timer and transition to the 1233 NotOriginator (NO) state. 1235 S is no longer directly connected 1236 The router MUST transition to the NotOriginator (NO) state and 1237 cancel both the SAT(S,G) and SRT(S,G). 1239 6.6 PIM Assert Messages 1241 6.6.1 Assert Metrics 1243 Assert metrics are defined as: 1245 struct assert_metric { 1246 metric_preference; 1247 route_metric; 1248 ip_address; 1249 }; 1251 When comparing assert_metrics, the metric_preference and route_metric 1252 field are compared in order, where the first lower value wins. If all 1253 fields are equal, the IP address of the router that sourced the Assert 1254 message is used as a tie-breaker, with the highest IP address winning. 1256 An Assert metric for (S,G) to include in (or compare against) an Assert 1257 message sent on interface I should be computed using the following 1258 pseudocode: 1260 assert_metric 1261 my_assert_metric(S,G,I) { 1262 if (CouldAssert(S,G,I) == TRUE) { 1263 return spt_assert_metric(S,G,I) 1264 } else { 1265 return infinite_assert_metric() 1266 } 1267 } 1269 spt_assert_metric(S,I) gives the Assert metric we use if we're sending 1270 an Assert based on active (S,G) forwarding state: 1272 assert_metric 1273 spt_assert_metric(S,I) { 1274 return {0,MRIB.pref(S),MRIB.metric(S),my_addr(I)} 1275 } 1277 MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing 1278 metrics associated with the route to a particular (unicast) destination 1279 X, as determined by the MRIB. my_addr(I) is simply the router's network 1280 (e.g. IP) address that is associated with the local interface I. 1282 infinite_assert_metric() gives the Assert metric we need to send an 1283 Assert but doesn't match (S,G) forwarding state: 1285 assert_metric 1286 infinite_assert_metric() { 1287 return {1,infinity,infinity,0} 1288 } 1290 6.6.2 AssertCancel Messages 1292 An AssertCancel(S,G) message is simply an Assert message for (S,G) with 1293 infinite metric. The Assert winner sends such a message when it changes 1294 its upstream interface to this interface. Other routers will see this 1295 metric, causing those with forwarding state to send their own Asserts 1296 and re-establish an Assert winner. 1298 AssertCancel messages are simply an optimization. The original Assert 1299 timeout mechanism will allow a subnet to eventually become consistent; 1300 the AssertCancel mechanism simply causes faster convergence. No special 1301 processing is required for an AssertCancel message, since it is simply 1302 an Assert message from the current winner. 1304 6.6.3 Assert State Macros 1306 The macro lost_assert(S,G,I), is used in the olist computations of 1307 section 6.1.3, and is defined as follows: 1309 bool lost_assert(S,G,I) { 1310 if ( RPF_interface(S) == I ) { 1311 return FALSE 1312 } else { 1313 return (AssertWinner(S,G,I) != me AND 1314 (AssertWinnerMetric(S,G,I) is better than 1315 spt_assert_metric(S,G,I))) 1316 } 1317 } 1319 AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I) 1320 defaults to Infinity when in the NoInfo state. 1322 6.6.4 (S,G) Assert Message State Machine 1324 The (S,G) Assert state machine for interface I is shown in Figure 4. 1325 There are three states: 1327 NoInfo (NI) 1328 This router has no (S,G) Assert state on interface I. 1330 I am Assert Winner (W) 1331 This router has won an (S,G) Assert on interface I. It is now 1332 responsible for forwarding traffic from S destined for G via 1333 interface I. 1335 I am Assert Loser (L) 1336 This router has lost an (S,G) Assert on interface I. It must not 1337 forward packets from S destined for G onto interface I. 1339 In addition there is also an Assert Timer (AT(S,G,I)) that is used to 1340 time out Assert state. 1342 +-------------+ +-------------+ 1343 | | Rcv Pref Assert or SR | | 1344 | Winner |----------------------->| Loser | 1345 | | | | 1346 +-------------+ +-------------+ 1347 ^ | ^ | 1348 | | Rcv Pref Assert or| | 1349 | |AT Expires OR State Refresh| | 1350 | |CouldAssert->FALSE | | 1351 | | | | 1352 | | +-------------+ | | 1353 | +-------->| |----------+ | 1354 | | No Info | | 1355 +-------------| |<-------------+ 1356 Rcv Data from dnstrm +-------------+ Rcv Inf Assert from Win OR 1357 OR Rcv Inferior Assert Rcv Inf SR from Winner OR 1358 OR Rcv Inferior SR AT Expires OR 1359 CouldAssert Changes OR 1360 Winner's NLT Expires 1362 Figure 4: Per-interface (S,G) Assert state machine 1364 In tabular form the state machine is defined as follows: 1366 +-------------------------------+--------------------------------------+ 1367 | | Previous State | 1368 | +------------+------------+------------+ 1369 | Event | No Info | Winner | Loser | 1370 +-------------------------------+------------+------------+------------+ 1371 | An (S,G) Data packet received | ->W Send | ->W Send | ->L | 1372 | on downstream interface | Assert(S,G)| Assert(S,G)| | 1373 | | Set | Set | | 1374 | | AT(S,G,I) | AT(S,G,I) | | 1375 +-------------------------------+--------------------------------------+ 1376 | Receive Inferior (Assert OR | N/A | N/A |->NI Cancel | 1377 | State Refresh) from Assert | | | AT(S,G,I) | 1378 | Winner | | | | 1379 +-------------------------------+--------------------------------------+ 1380 | Receive Inferior (Assert OR | ->W Send | ->W Send | ->L | 1381 | State Refresh) from non-Assert| Assert(S,G)| Assert(S,G)| | 1382 | Winner AND CouldAssert==TRUE | Set | Set | | 1383 | | AT(S,G,I) | AT(S,G,I) | | 1384 +-------------------------------+--------------------------------------+ 1385 | Receive Preferred Assert OR | ->L Send | ->L Send | ->L Set | 1386 | State Refresh | Prune(S,G) | Prune(S,G) | AT(S,G,I) | 1387 | | Set | Set | | 1388 | | AT(S,G,I) | AT(S,G,I) | | 1389 +-------------------------------+--------------------------------------+ 1390 | Send State Refresh | ->NI | ->W Reset | N/A | 1391 | | | AT(S,G,I) | | 1392 +-------------------------------+--------------------------------------+ 1393 | AT(S,G) Expires | N/A | ->NI | ->NI | 1394 +-------------------------------+--------------------------------------+ 1396 +-------------------------------+--------------------------------------+ 1397 | | Previous State | 1398 | +------------+------------+------------+ 1399 | Event | No Info | Winner | Loser | 1400 +-------------------------------+------------+------------+------------+ 1401 | CouldAssert -> FALSE | ->NI |->NI Cancel |->NI Cancel | 1402 | | | AT(S,G,I) | AT(S,G,I) | 1403 +-------------------------------+--------------------------------------+ 1404 | CouldAssert -> TRUE | ->NI | N/A |->NI Cancel | 1405 | | | | AT(S,G,I) | 1406 +-------------------------------+--------------------------------------+ 1407 | Winner's NLT(N,I) Expires | N/A | N/A |->NI Cancel | 1408 | | | | AT(S,G,I) | 1409 +-------------------------------+--------------------------------------+ 1410 | Receive Prune(S,G), Join(S,G) | ->NI | ->W | ->L Send | 1411 | or Graft(S,G) | | | Assert(S,G)| 1412 +-------------------------------+--------------------------------------+ 1414 Terminology: 1415 A "preferred assert" is one with a better metric than the current 1416 winner. An "inferior assert" is one with a worse metric than 1417 my_assert_metric(S,G,I). 1419 The state machine uses the following macro: 1421 CouldAssert(S,G,I) = (RPF_interface(S) != I) 1423 Transitions from NoInfo State 1425 When in NoInfo state, the following events may trigger transitions: 1427 An (S,G) data packet arrives on downstream interface I 1428 An (S,G) data packet arrived on a downstream interface. It is 1429 optimistically assumed that this router will be the Assert winner 1430 for this (S,G). The Assert state machine MUST transition to the "I 1431 am Assert Winner" state, send an Assert(S,G) to interface I, store 1432 its own address and metric as the Assert Winner and set the 1433 Assert_Timer (AT(S,G,I) to Assert_Time, thereby initiating the 1434 Assert negotiation for (S,G). 1436 Receive Inferior (Assert OR State Refresh) AND 1437 CouldAssert(S,G,I)==TRUE 1438 An Assert or State Refresh is received for (S,G) that is inferior 1439 to our own assert metric on interface I. The Assert state machine 1440 MUST transition to the "I am Assert Winner" state, send an 1441 Assert(S,G) to interface I, store its own address and metric as the 1442 Assert Winner and set the Assert Timer (AT(S,G,I)) to Assert_Time. 1444 Receive Preferred Assert or State Refresh 1445 The received Assert or State Refresh has a better metric than this 1446 router's and therefore the Assert state machine MUST transition to 1447 the "I am Assert Loser" state and store the Assert Winner's address 1448 and metric. If the metric was received in an Assert, the router MUST 1449 set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was 1450 received in a State Refresh, the router MUST set the Assert Timer 1451 (AT(S,G,I)) to three times the received State Refresh Interval. The 1452 router MUST also multicast a Prune(S,G) to the Assert winner and 1453 evaluate any changes in its Upstream(S,G) state machine. 1455 Transitions from Winner State 1457 When in "I am Assert Winner" state, the following events trigger 1458 transitions: 1460 An (S,G) data packet arrives on downstream interface I 1461 An (S,G) data packet arrived on a downstream interface. The Assert 1462 state machine remains in the "I am Assert Winner" state. The router 1463 MUST send an Assert(S,G) to interface I and set the Assert Timer 1464 (AT(S,G,I) to Assert_Time. 1466 Receive Inferior Assert or State Refresh 1467 An (S,G) Assert is received containing a metric for S that is worse 1468 metric than this router's metric for S. Whoever sent the Assert is 1469 in error. The router MUST send an Assert(S,G) to interface I and 1470 reset the Assert Timer (AT(S,G,I)) to Assert_Time. 1472 Receive Preferred Assert or State Refresh 1473 An (S,G) Assert or State Refresh is received that has a better 1474 metric than this router's metric for S on interface I. The Assert 1475 state machine MUST transition to "I am Assert Loser" state and 1476 store the new Assert Winner's address and metric. If the metric was 1477 received in an Assert, the router MUST set the Assert Timer 1478 (AT(S,G,I)) to Assert_Time. If the metric was received in a State 1479 Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three 1480 times the State Refresh Interval. The router MUST also multicast a 1481 Prune(S,G) to the Assert winner and evaluate any changes in its 1482 Upstream(S,G) state machine. 1484 Send State Refresh 1485 The router is sending a State Refresh(S,G) message on interface I. 1486 The router MUST set the Assert Timer (AT(S,G,I)) to three times the 1487 State Refresh Interval contained in the State Refresh(S,G) message. 1489 AT(S,G,I) Expires 1490 The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state machine 1491 MUST transition to the NoInfo (NI) state. 1493 CouldAssert(S,G,I) -> FALSE 1494 This router's RPF interface changed so as to make CouldAssert(S,G,I) 1495 become false. This router can no longer perform the actions of the 1496 Assert winner, and so the Assert state machine MUST transition to 1497 NoInfo (NI) state, send an AssertCancel(S,G) to interface I, cancel 1498 the Assert Timer (AT(S,G,I)) and remove itself as the Assert Winner. 1500 Transitions from Loser State 1502 When in "I am Assert Loser" state, the following transitions can occur: 1504 Receive Inferior Assert or State Refresh from Current Winner 1505 An Assert or State Refresh is received from the current Assert 1506 winner that is worse than this router's metric for S (typically the 1507 winner's metric became worse). The Assert state machine MUST 1508 transition to NoInfo (NI) state and cancel AT(S,G,I). The router 1509 MUST delete the previous Assert Winner's address and metric and 1510 evaluate any possible transitions to its Upstream(S,G) state 1511 machine. Usually this router will eventually re-assert and win when 1512 data packets from S have started flowing again. 1514 Receive Preferred Assert or State Refresh 1515 An Assert or State Refresh is received that has a metric better than 1516 or equal to that of the current Assert winner. The Assert state 1517 machine remains in Loser (L) state. If the metric was received in 1518 an Assert, the router MUST set the Assert Timer (AT(S,G,I)) to 1519 Assert_Time. If the metric was received in a State Refresh, the 1520 router MUST set the Assert Timer (AT(S,G,I)) to three times the 1521 received State Refresh Interval. If the metric is better than the 1522 current Assert Winner, the router MUST store the address and metric 1523 of the new Assert Winner and if CouldAssert == TRUE, the router 1524 MUST multicast a Prune(S,G) to the new Assert winner. 1526 AT(S,G,I) Expires 1527 The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state 1528 machine MUST transition to NoInfo (NI) state. The router MUST 1529 delete the Assert Winner's address and metric. If CouldAssert == 1530 TRUE, the router MUST evaluate any possible transitions to its 1531 Upstream(S,G) state machine. 1533 CouldAssert -> FALSE 1534 CouldAssert has become FALSE because interface I has become the RPF 1535 interface for S. The Assert state machine MUST transition to NoInfo 1536 (NI) state, cancel AT(S,G,I) and delete information concerning the 1537 Assert Winner on I. 1539 CouldAssert -> TRUE 1540 CouldAssert has become TRUE because interface I used to be the RPF 1541 interface for S, and now it is not. The Assert state machine MUST 1542 transition to NoInfo (NI) state, cancel AT(S,G,I) and delete 1543 information concerning the Assert Winner on I. 1545 Current Assert Winner's NeighborLiveness Timer Expires 1546 The current Assert winner's NeighborLiveness Timer (NLT(N,I)) has 1547 expired. The Assert state machine MUST transition to the NoInfo 1548 (NI) state, delete the Assert Winner's address and metric, and 1549 evaluate any possible transitions to its Upstream(S,G) state 1550 machine. 1552 Receive Prune(S,G), Join(S,G) or Graft(S,G) 1553 A Prune(S,G), Join(S,G) or Graft(S,G) message was received on 1554 interface I with its upstream neighbor address set to the router's 1555 address on I. The router MUST send an Assert(S,G) on the receiving 1556 interface I to initiate an Assert negotiation. The Assert state 1557 machine remains in the Assert Loser(L) state. If a Graft(S,G) was 1558 received, the router MUST respond with a GraftAck(S,G). 1560 6.6.5 Rationale for Assert Rules 1562 The following is a summary of the rules for generating and processing 1563 Assert messages. It is not intended to be definitive (the state 1564 machines and pseudocode provide the definitive behavior). Instead it 1565 provides some rationale for the behavior. 1567 1. The Assert winner for (S,G) must act as the local forwarder for (S,G) 1568 on behalf all downstream members. 1569 2. PIM messages are directed towards to the RPF' neighbor and not to the 1570 regular RPF neighbor. 1571 3. An Assert loser that receives a Prune(S,G), Join(S,G) or Graft(S,G) 1572 directed to it initiates a new Assert negotiation so the downstream 1573 router can correct its RPF'(S). 1574 4. An assert winner for (S,G) sends a canceling assert when it is about 1575 to stop forwarding on an (S,G) entry. Example : if a router is being 1576 taken down, then a canceling assert is sent. 1578 6.7 PIM Packet Formats 1580 All PIM-DM packets use the same format as PIM-SM packets. All PIM 1581 control messages have IP protocol number 103. All PIM-DM messages MUST 1582 be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack 1583 messages MUST be sent to the ALL-PIM-ROUTERS group. Graft messages 1584 SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be unicast to 1585 the sender of the Graft. 1587 The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM- ROUTERS 1588 group is 'ff02::d'. 1590 6.7.1 PIM Header 1592 All PIM control messages have the following header: 1594 0 1 2 3 1595 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 |PIM Ver| Type | Reserved | Checksum | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 PIM Ver 1601 PIM version number is 2. 1603 Type 1604 Types for specific PIM messages. Available types are: 1605 0 = Hello 1606 1 = Register (PIM-SM only) 1607 2 = Register Stop (PIM-SM only) 1608 3 = Join/Prune 1609 4 = Bootstrap (PIM-SM only) 1610 5 = Assert 1611 6 = Graft 1612 7 = Graft Ack 1613 8 = Candidate RP Advertisement (PIM-SM only) 1614 9 = State Refresh 1616 Reserved 1617 Set to zero on transmission. Ignored upon receipt. 1619 Checksum 1620 The checksum is standard IP checksum, i.e. the 16 bit one's complement 1621 of the one's complement sum of the entire PIM message. For computing 1622 checksum, the checksum field is zeroed. 1624 For IPv6, the checksum also includes the IPv6 "pseudo-header", as 1625 specified in RFC 2460, section 8.1 [13]. This "pseudo-header" is 1626 prepended to the PIM header for the purposes of calculating the 1627 checksum. The "Upper-Layer Packet Length" in the pseudo-header is set 1628 to the length of the PIM message. The Next Header value used in the 1629 pseudo-header is 103. If the packet's length is not an integral number 1630 of 16-bit words, the packet is padded with a byte of zero before 1631 performing the checksum. 1633 6.7.2 Encoded Unicast Address 1635 An Encoded Unicast Address has the following format: 1637 0 1 2 3 1638 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Addr Family | Encoding Type | Unicast Address 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1643 Addr Family 1644 The PIM Address Family of the 'Unicast Address' field of this address. 1645 Values of 0-127 are as assigned by the IANA for Internet Address 1646 Families in [6]. Values 128-250 are reserved to be assigned by the 1647 IANA for PIM specific Address Families. Values 251-255 are designated 1648 for private use. As there is no assignment authority for this space, 1649 collisions should be expected. 1651 Encoding Type 1652 The type of encoding used with a specific Address Family. The value 1653 '0' is reserved for this field, and represents the native encoding of 1654 the Address Family 1656 Unicast Address 1657 The unicast address as represented by the given Address Family and 1658 Encoding Type. 1660 6.7.3 Encoded Group Address 1662 An Encoded Group address has the following format: 1664 0 1 2 3 1665 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | Group Multicast Address 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1672 Addr Family 1673 As described above. 1675 Encoding Type 1676 As described above. 1678 B 1679 Indicates the group range should use Bidirectional PIM [14]. 1680 Transmitted as zero, ignored upon receipt. 1682 Reserved 1683 Transmitted as zero. Ignored upon receipt. 1685 Z 1686 Indicates the group range is an admin scope zone. This is used in the 1687 Bootstrap Router Mechanism [15] only. For all other purposes, this bit 1688 is set to zero and ignored on receipt. 1690 Mask Len 1691 The mask length field is 8 bits. The value is the number of 1692 contiguous on bits left justified used as a mask, which combined with 1693 the address, describes a range of addresses. It is less than or equal 1694 to the address length in bits for the given Address Family and 1695 Encoding Type. If the message is sent for a single address then the 1696 mask length MUST equal the address length. PIM-DM routers MUST only 1697 send for a single address. 1699 Group Multicast Address 1700 The address of the multicast group. 1702 6.7.4 Encoded Source Address 1704 An Encoded Source address has the following format: 1706 0 1 2 3 1707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Source Address 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1714 Addr Family 1715 As described above. 1717 Encoding Type 1718 As described above. 1720 Rsrvd 1721 Reserved. Transmitted as zero. Ignored upon receipt. 1723 S 1724 The Sparse Bit. Set to 0 for PIM-DM. Ignored upon receipt. 1726 W 1727 The Wild Card Bit. Set to 0 for PIM-DM. Ignored upon receipt. 1729 R 1730 The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon 1731 receipt. 1733 Mask Len 1734 As described above. PIM-DM routers MUST only send for a single 1735 source address. 1737 Source Address 1738 The source address. 1740 6.7.5 Hello Message Format 1742 The PIM Hello message has the following format: 1744 0 1 2 3 1745 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 |PIM Ver| Type | Reserved | Checksum | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | Option Type | Option Length | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Option Value | 1752 | ... | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | . | 1755 | . | 1756 | . | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | Option Type | Option Length | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | Option Value | 1761 | ... | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 PIM Ver, Type, Reserved, Checksum 1765 Described above. 1767 Option Type 1768 The type of option given in the Option Value field. Available types 1769 are: 1770 0 Reserved 1771 1 Hello Hold Time 1772 2 LAN Prune Delay 1773 3-16 Reserved 1774 17 To be assigned by IANA 1775 18 Deprecated and SHOULD NOT be used 1776 19 DR Priority (PIM-SM Only) 1777 20 Generation ID 1778 21 State Refresh Capable 1779 22-65000 To be assigned by IANA 1780 65001-65535 Reserved for Private Use [7] 1781 Unknown options SHOULD be ignored. 1783 6.7.5.1 Hello Hold Time Option 1785 0 1 2 3 1786 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Type = 1 | Length = 2 | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Hold Time | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 Hold Time is the number of seconds a receiver MUST keep the neighbor 1794 reachable. If the Hold Time is set to '0xffff', the receiver of this 1795 message never times out the neighbor. This may be used with dial-on- 1796 demand links, to avoid keeping the link up with periodic Hello messages. 1797 Furthermore, if the Holdtime is set to '0', the information is timed out 1798 immediately. The Hello Hold Time option MUST be used by PIM-DM routers. 1800 6.7.5.2 LAN Prune Delay Option 1802 0 1 2 3 1803 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | Type = 2 | Length = 4 | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 |T| LAN Prune Delay | Override Interval | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 The LAN_Prune_Delay option is used to tune the prune propagation delay 1811 on multi-access LANs. The T bit is used by PIM-SM and SHOULD be set to 0 1812 by PIM-DM routers and ignored upon receipt. The LAN Delay and Override 1813 Interval fields are time intervals in units of milliseconds and are used 1814 to tune the value of the J/P Override Interval and its derived timer 1815 values. Section 6.3.5 describes how these values affect the behavior of 1816 a router. The LAN Prune Delay SHOULD be used by PIM-DM routers. 1818 6.7.5.3 Generation ID Option 1820 0 1 2 3 1821 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | Type = 20 | Length = 4 | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | Generation ID | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 Generation ID is a random value for the interface on which the Hello 1829 message is sent. The Generation ID is regenerated whenever PIM 1830 forwarding is started or restarted on the interface. The Generation ID 1831 option MAY be used by PIM-DM routers. 1833 6.7.5.4 State Refresh Capable Option 1835 0 1 2 3 1836 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | Type = 21 | Length = 4 | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | Version = 1 | Interval | Reserved | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 The Interval field is the router's configured State Refresh Interval in 1844 seconds. The Reserved field is set to zero and ignored upon reception. 1845 The State Refresh Capable option MUST be used by State Refresh capable 1846 PIM-DM routers. 1848 6.7.6 Join/Prune Message Format 1850 PIM Join/Prune messages have the following format: 1852 0 1 2 3 1853 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 |PIM Ver| Type | Reserved | Checksum | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Upstream Neighbor Address (Encoded Unicast Format) | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | Reserved | Num Groups | Hold Time | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | Multicast Group Address 1 (Encoded Group Format) | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Number of Joined Sources | Number of Pruned Sources | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Joined Source Address 1 (Encoded Source Format) | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | . | 1868 | . | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | Joined Source Address n (Encoded Source Format) | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | Pruned Source Address 1 (Encoded Source Format) | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | . | 1875 | . | 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | Pruned Source Address n (Encoded Source Format) | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | . | 1880 | . | 1881 | . | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | Multicast Group Address m (Encoded Group Format) | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Number of Joined Sources | Number of Pruned Sources | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | Joined Source Address 1 (Encoded Source Format) | 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 | . | 1890 | . | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Joined Source Address n (Encoded Source Format) | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | Pruned Source Address 1 (Encoded Source Format) | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | . | 1897 | . | 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Pruned Source Address n (Encoded Source Format) | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 PIM Ver, Type, Reserved, Checksum 1903 Described above. 1905 Upstream Neighbor Address 1906 The address of the upstream neighbor. The format for this address is 1907 given in the Encoded Unicast address in section 6.7.2. PIM-DM routers 1908 MUST set this field to the RPF next hop. 1910 Reserved 1911 Transmitted as zero. Ignored upon receipt. 1913 Hold Time 1914 The number of seconds a receiving PIM-DM router MUST keep a Prune 1915 state alive, unless removed by a Join or Graft message. If the Hold 1916 Time is '0xffff', the receiver MUST NOT remove the Prune state unless 1917 a corresponding Join or Graft message is received. The Hold Time is 1918 ignored in Join messages. 1920 Number of Groups 1921 Number of multicast group sets contained in the message. 1923 Multicast Group Address 1924 The multicast group address in the Encoded Multicast address format 1925 given in section 6.7.3. 1927 Number of Joined Sources 1928 Number of Join source addresses listed for a given group. 1930 Number of Pruned Sources 1931 Number of Prune source addresses listed for a given group. 1933 Join Source Address 1..n 1934 This list contains the sources from which the sending router wishes to 1935 continue to receive multicast messages for the given group on this 1936 interface. The addresses use the Encoded Source address format given 1937 in section 6.7.4. 1939 Prune Source Address 1..n 1940 This list contains the sources from which the sending router does not 1941 wish to receive multicast messages for the given group on this 1942 interface. The addresses use the Encoded Source address format given 1943 in section 6.7.4. 1945 6.7.7 Assert Message Format 1947 PIM Assert Messages have the following format: 1949 0 1 2 3 1950 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 |PIM Ver| Type | Reserved | Checksum | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | Multicast Group Address (Encoded Group Format) | 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | Source Address (Encoded Unicast Format) | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 |R| Metric Preference | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | Metric | 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 PIM Ver, Type, Reserved, Checksum 1964 Described above. 1966 Multicast Group Address 1967 The multicast group address in the Encoded Multicast address format 1968 given in section 6.7.3. 1970 Source Address 1971 The source address in the Encoded Source address format given in 1972 section 6.7.4. 1974 R 1975 The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon 1976 receipt. 1978 Metric Preference 1979 The preference value assigned to the unicast routing protocol that 1980 provided the route to the source. 1982 Metric 1983 The cost metric of the unicast route to the source. The metric is in 1984 units applicable to the unicast routing protocol used. 1986 6.7.8 Graft Message Format 1988 PIM Graft messages use the same format as Join/Prune messages except the 1989 Type field is set to 6. The source address MUST be in the Join section 1990 of the message. The Hold Time field SHOULD be zero and SHOULD be 1991 ignored when a Graft is received. 1993 6.7.9 Graft Ack Message Format 1994 PIM Graft Ack messages are identical in format to the received Graft 1995 message except the Type field is set to 7. The Upstream Neighbor 1996 Address field SHOULD be set to the sender of the Graft message and 1997 SHOULD be ignored upon receipt. 1999 6.7.10 State Refresh Message Format 2001 PIM State Refresh Messages have the following format: 2003 0 1 2 3 2004 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 |PIM Ver| Type | Reserved | Checksum | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | Multicast Group Address (Encoded Group Format) | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | Source Address (Encoded Unicast Format) | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | Originator Address (Encoded Unicast Format) | 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 |R| Metric Preference | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | Metric | 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | Masklen | TTL |P|N|O|Reserved | Interval | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 PIM Ver, Type, Reserved, Checksum 2022 Described above. 2024 Multicast Group Address 2025 The multicast group address in the Encoded Multicast address format 2026 given in section 6.7.3. 2028 Source Address 2029 The address of the data source in the Encoded Source address format 2030 given in section 6.7.4. 2032 Originator Address 2033 The address of the first hop router in the Encoded Source address 2034 format given in section 6.7.4. 2036 R 2037 The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon 2038 receipt. 2040 Metric Preference 2041 The preference value assigned to the unicast routing protocol that 2042 provided the route to the source. 2044 Metric 2045 The cost metric of the unicast route to the source. The metric is in 2046 units applicable to the unicast routing protocol used. 2048 Masklen 2049 The length of the address mask of the unicast route to the source. 2051 TTL 2052 Time To Live of the State Refresh message. Decremented each time the 2053 message is forwarded. Note that this is different from the IP Header 2054 TTL, which is always set to 1. 2056 P 2057 Prune indicator flag. This MUST be set to 1 if the State Refresh is 2058 to be sent on a Pruned interface. Otherwise, it MUST be set to 0. 2060 N 2061 Prune Now flag. This SHOULD be set to 1 by the State Refresh 2062 originator on every third State Refresh message and SHOULD be ignored 2063 upon receipt. This is for compatibility with earlier versions of 2064 state refresh. 2066 O 2067 Assert Override flag. This SHOULD be set to 1 by upstream routers on 2068 a LAN if the Assert Timer (AT(S,G)) is not running and SHOULD be 2069 ignored upon receipt. This is for compatibility with earlier versions 2070 of state refresh. 2072 Reserved 2073 Set to zero and ignored upon receipt. 2075 Interval 2076 Set by the originating router to the interval (in seconds) between 2077 consecutive State Refresh messages for this (S,G) pair. 2079 6.8 PIM-DM Timers 2081 PIM-DM maintains the following timers. All timers are countdown timers 2082 - they are set to a value and count down to zero, at which point they 2083 typically trigger an action. Of course they can just as easily be 2084 implemented as count-up timers, where the absolute expiry time is stored 2085 and compared against a real-time clock, but the language in this 2086 specification assumes that they count downwards towards zero. 2088 Global Timers 2089 Hello Timer: HT 2091 Per interface (I): 2092 Per neighbor (N): 2093 Neighbor Liveness Timer: NLT(N,I) 2095 Per (S,G) Pair: 2096 (S,G) Assert Timer: AT(S,G,I) 2097 (S,G) Prune Timer: PT(S,G,I) 2098 (S,G) PrunePending Timer: PPT(S,G,I) 2100 Per (S,G) Pair: 2101 (S,G) Graft Retry Timer: GT(S,G) 2102 (S,G) Upstream Override Timer: OT(S,G) 2103 (S,G) Prune Limit Timer: PLT(S,G) 2104 (S,G) Source Active Timer: SAT(S,G) 2105 (S,G) State Refresh Timer: SRT(S,G) 2107 6.8.1 Timer Values 2109 When timer values are started or restarted, they are set to default 2110 values. This section summarizes those default values. 2112 Timer Name: Hello Timer (HT) 2113 +----------------------+--------+--------------------------------------+ 2114 | Value Name | Value | Explanation | 2115 +----------------------+--------+--------------------------------------+ 2116 |Hello_Period | 30 sec | Periodic interval for hello messages | 2117 +----------------------+--------+--------------------------------------+ 2118 |Triggered_Hello_Delay | 5 sec | Random interval for initial Hello | 2119 | | | message on bootup or triggered Hello | 2120 | | | message to a rebooting neighbor | 2121 +----------------------+--------+--------------------------------------+ 2123 Hello message are sent on every active interface once every Hello_Period 2124 seconds. At system power-up, the timer is initialized to 2125 rand(0,Triggered_Hello_Delay) to prevent synchronization. When a new or 2126 rebooting neighbor is detected, a responding Hello is sent within 2127 rand(0,Triggered_Hello_Delay). 2129 Timer Name: Neighbor Liveness Timer (NLT(N,I)) 2130 +-------------------+-----------------+--------------------------------+ 2131 | Value Name | Value | Explanation | 2132 +-------------------+-----------------+--------------------------------+ 2133 | Hello Holdtime | From message | Hold Time from Hello Message | 2134 +-------------------+-----------------+--------------------------------+ 2136 Timer Name: PrunePending Timer (PPT(S,G,I)) 2137 +-----------------------+---------------+------------------------------+ 2138 | Value Name | Value | Explanation | 2139 +-----------------------+---------------+------------------------------+ 2140 | J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to | 2141 | | | allow other routers to on | 2142 | | | the LAN to send a Join | 2143 +-----------------------+---------------+------------------------------+ 2145 The J/P_Override_Interval is the sum of the interface's 2146 Override_Interval (OI(I)) and Propagation_Delay (PD(I)). If all routers 2147 on a LAN are using the LAN Prune Delay option, both parameters MUST be 2148 set to the largest value on the LAN. Otherwise, the Override_Interval 2149 (OI(I)) MUST be set to 2.5 seconds and the Propagation_Delay (PD(I)) 2150 MUST be set to 0.5 seconds. 2152 Timer Name: Prune Timer (PT(S,G,I)) 2153 +----------------+----------------+------------------------------------+ 2154 | Value Name | Value | Explanation | 2155 +----------------+----------------+------------------------------------+ 2156 | Prune Holdtime | From message | Hold Time read from Prune Message | 2157 +----------------+----------------+------------------------------------+ 2159 Timer Name: Assert Timer (AT(S,G,I)) 2160 +--------------------------+---------+---------------------------------+ 2161 | Value Name | Value | Explanation | 2162 +--------------------------+---------+---------------------------------+ 2163 | Assert Time | 180 sec | Period after last assert before | 2164 | | | assert state is timed out | 2165 +--------------------------+---------+---------------------------------+ 2167 Note that for historical reasons, the Assert message lacks a Holdtime 2168 field. Thus changing the Assert Time from the default value is not 2169 recommended. If all members of a LAN are state refresh enabled, the 2170 Assert Time will be three times the received RefreshInterval(S,G). 2172 Timer Name: Graft Retry Timer (GRT(S,G)) 2173 +--------------------+-------+-----------------------------------------+ 2174 | Value Name | Value | Explanation | 2175 +--------------------+-------+-----------------------------------------+ 2176 | Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck | 2177 | | | message, the time before retransmission | 2178 | | | of a Graft message | 2179 +--------------------+-------+-----------------------------------------+ 2181 Timer Name: Upstream Override Timer (OT(S,G)) 2182 +-----------+----------------+-----------------------------------------+ 2183 |Value Name | Value | Explanation | 2184 +-----------+----------------+-----------------------------------------| 2185 |t_override | rand(0, OI(I)) | Randomized delay to prevent response | 2186 | | | implosion when sending a join message | 2187 | | | to override someone else's prune | 2188 +-----------+----------------+-----------------------------------------+ 2190 t_override is a random value between 0 and the interface's 2191 Override_Interval (OI(I)). If all routers on a LAN are using the LAN 2192 Prune Delay option, the Override_Interval (OI(I)) MUST be set to the 2193 largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST 2194 be set to 2.5 seconds. 2196 Timer Name: Prune Limit Timer (PLT(S,G)) 2197 +-----------+--------------------+-------------------------------------+ 2198 |Value Name | Value | Explanation | 2199 +-----------+--------------------+-------------------------------------| 2200 |t_limit | Equal to the Prune | Used to prevent Prune storms on a | 2201 | | Holdtime sent | LAN | 2202 +-----------+--------------------+-------------------------------------+ 2204 Timer Name: Source Activity Timer (SAT(S,G)) 2205 +----------------+-------------------+---------------------------------+ 2206 | Value Name | Value | Explanation | 2207 +----------------+-------------------+---------------------------------+ 2208 | SourceLifetime | Default: 210 secs | Period of time after receiving | 2209 | | | a multicast message a directly | 2210 | | | attached router will continue | 2211 | | | to send State Refresh messages | 2212 +----------------+-------------------+---------------------------------+ 2214 Timer Name: State Refresh Timer (SRT(S,G)) 2215 +-----------------+------------------+---------------------------------+ 2216 | Value Name | Value | Explanation | 2217 +-----------------+------------------+---------------------------------+ 2218 | RefreshInterval | Default: 60 secs | Interval between successive | 2219 | | | state refresh messages | 2220 +-----------------+------------------+---------------------------------+ 2222 7. Protocol Interaction Considerations 2224 PIM-DM is designed to be independent of underlying unicast routing 2225 protocols and will interact only to the extent needed to perform RPF 2226 checks. It is generally assumed that multicast area and autonomous 2227 system boundaries will correspond to the same boundaries for unicast 2228 routing, though a deployment which does not follow this assumption is 2229 not precluded by this specification. 2231 In general, PIM-DM interactions with other multicast routing protocols 2232 should be in compliance with RFC 2715 [11]. Other specific 2233 interactions are noted below. 2235 7.1 PIM-SM Interactions 2237 PIM-DM is not intended to interact directly with PIM-SM, even though 2238 they share a common packet format. It is particularly important to note 2239 that a router cannot differentiate between a PIM-DM neighbor and a 2240 PIM-SM neighbor based on Hello messages. 2242 In the event that a PIM-DM router becomes a neighbor of a PIM-SM router 2243 they will effectively form a simplex link with the PIM-DM router sending 2244 all multicast messages to the PIM-SM router while the PIM-SM router 2245 sends no multicast messages to the PIM-DM router. 2247 The common packet format permits a hybrid PIM-SM/DM implementation that 2248 would use PIM-SM when a rendezvous point is known and PIM-DM when one is 2249 not. Such an implementation is outside the scope of this document. 2251 7.2 IGMP Interactions 2253 PIM-DM will forward received multicast data packets to neighboring host 2254 group members in all cases except when the PIM-DM router is in an Assert 2255 Loser state on that interface. Note that a PIM Prune message is not 2256 permitted to prevent the delivery of messages to a network with group 2257 members. 2259 A PIM-DM Router MAY use the DR Priority option described in PIM-SM [3] 2260 to elect an IGMP v1 querier. 2262 7.3 Source Specific Multicast (SSM) Interactions 2264 PIM-DM makes no special considerations for SSM [9]. All Prunes and 2265 Grafts within the protocol are for a specific source, so no additional 2266 checks need be made. 2268 7.4 Multicast Group Scope Boundary Interactions 2270 While multicast group scope boundaries are generally identical to 2271 routing area boundaries, it is conceivable that a routing area might be 2272 partitioned for a particular multicast group. PIM-DM routers MUST NOT 2273 send any messages concerning a particular group across that group's 2274 scope boundary. 2276 8. IANA Considerations 2278 8.1 PIM Address Family 2280 The PIM Address Family field was chosen to be 8 bits as a tradeoff 2281 between packet format and use of the IANA assigned numbers. When the 2282 PIM packet format was designed, only 15 values were assigned for Address 2283 Families and large numbers of new Address Families were not envisioned, 2284 8 bits seemed large enough. However, the IANA assigns Address Families 2285 in a 16 bit value. Therefore, the PIM Address Family is allocated as 2286 follows: 2288 Values 0 through 127 are designated to have the same meaning as IANA 2289 assigned Address Family Numbers [6]. 2291 Values 128 through 250 are designated to be assigned by the IANA based 2292 upon IESG approval as defined in [7]. 2294 Values 251 through 255 are designated for Private Use, as defined in 2295 [7]. 2297 8.2 PIM Hello Options 2299 Values 17 through 65000 are to be assigned by the IANA. Since the space 2300 is large, they may be assigned as First Come First Served as defined in 2301 [7]. Such assignments are valid for one year, and may be renewed. 2302 Permanent assignments require a specification as defined in [7]. 2304 9. Security Considerations 2306 The IPsec authentication header [8] MAY be used to provide data 2307 integrity protection and groupwise data origin authentication of PIM 2308 protocol messages. Authentication of PIM messages can protect against 2309 unwanted behaviors caused by unauthorized or altered PIM messages. In 2310 any case, PIM router SHOULD NOT accept and process PIM messages from 2311 neighbors unless a valid Hello message has been received from that 2312 neighbor. 2314 We should note that PIM-DM has no rendezvous point, and therefore no 2315 single point of failure that may be vulnerable. It is further worth 2316 noting that because PIM-DM uses unicast routes provided by an unknown 2317 routing protocol, it may suffer collateral effects if the unicast 2318 routing protocol is attacked. 2320 9.1 Attacks Based on Forged Messages 2322 The extent of possible damage depends on the type of counterfeit 2323 messages accepted. We next consider the impact of possible forgeries. A 2324 forged PIM-DM message is link local, and can only reach a LAN if it was 2325 sent by a local host or if it was allowed onto the LAN by a compromised 2326 or non-compliant router. 2328 1. A forged a Hello message can cause multicast traffic to be delivered 2329 to links where there are no legitimate requestors, potentially 2330 wasting bandwidth on that link. On a multi-access LAN, the effects 2331 are limited without the capability to forge a Join message since 2332 other routers will Prune the link if the traffic is not desired. 2334 2. A forged Join/Prune message can cause multicast traffic to be 2335 delivered to links where there are no legitimate requestors, 2336 potentially wasting bandwidth on that link. A forged Prune message 2337 on a multi-access LAN is generally not a significant attack in PIM, 2338 because any legitimately joined router on the LAN would override the 2339 Prune with a Join before the upstream router stops forwarding data 2340 to the LAN. 2342 3. A forged Graft message can cause multicast traffic to be delivered to 2343 links where there are no legitimate requestors, potentially wasting 2344 bandwidth on that link. In principle, Graft messages could be sent 2345 multiple hops since they are unicast to the upstream router. This 2346 should not be a problem since the remote forger should have no way 2347 to get a Hello message to the target of the attack. Without a valid 2348 Hello message, the receiving router SHOULD NOT accept the Graft. 2350 4. A forged GraftAck message has no impact since it will be ignored 2351 unless the router has recently sent a Graft to its upstream router. 2353 5. By forging an Assert message on a multi-access LAN, an attacker could 2354 cause the legitimate forwarder to stop forwarding traffic to the LAN. 2355 Such a forgery would prevent any hosts downstream of that LAN from 2356 receiving traffic. 2358 6. A forged State Refresh message on a multi-access LAN would have the 2359 same impact as a forged Assert message, having the same general 2360 functions. In addition, forged State Refresh messages would be 2361 propagated downstream and might be used in a denial of service 2362 attack. Therefore, a PIM-DM router SHOULD rate limit State Refresh 2363 messages propagated. 2365 9.2 Non-cryptographic Authentication Mechanisms 2367 A PIM-DM router SHOULD provide an option to limit the set of neighbors 2368 from which it will accept PIM-DM messages. Either static configuration 2369 of IP addresses or an IPsec security association may be used. All 2370 options that restrict the range of addresses from which packets are 2371 accepted MUST default to allowing all packets. 2373 Furthermore, a PIM router SHOULD NOT accept protocol messages from a 2374 router from which it has not yet received a valid Hello message. 2376 9.3 Authentication Using IPsec 2378 The IPsec [8] transport mode using the Authentication Header (AH) is the 2379 recommended method to prevent the above attacks in PIM. The anti-replay 2380 option provided by IPsec SHOULD also be enabled. The specific AH 2381 authentication algorithm and parameters, including the choice of 2382 authentication algorithm and the choice of key, are configured by the 2383 network administrator. The Encapsulating Security Payload (ESP) MAY also 2384 be used to provide both encryption and authentication of PIM protocol 2385 messages. When IPsec authentication is used, a PIM router SHOULD reject 2386 (drop without processing) any unauthorized PIM protocol messages. 2388 To use IPsec, the administrator of a PIM network configures each PIM 2389 router with one or more Security Associations and associated SPI(s) that 2390 are used by senders to sign PIM protocol messages and are used by 2391 receivers to authenticate received PIM protocol messages. This document 2392 does not describe protocols for establishing Security Associations. It 2393 assumes that manual configuration of Security Associations is performed, 2394 but it does not preclude the use of some future negotiation protocol 2395 such as GDOI [16] to establish Security Associations. 2397 The network administrator defines a Security Association (SA) and 2398 Security Parameters Index (SPI) that is to be used to authenticate all 2399 PIM-DM protocol messages from each router on each link in a PIM-DM 2400 domain. Note that if the same SA is used by different sending routers on 2401 the same link, anti-replay mechanisms could prevent the acceptance of 2402 legitimate PIM-DM messages. All PIM-DM protocol messages use SPI 0. 2404 The Security Policy Database at a PIM-DM router should be configured to 2405 ensure that all incoming and outgoing PIM-DM packets use the SA 2406 associated with the interface to which the packet is sent. Note that, 2407 according to [8], there is nominally a different Security Association 2408 Database (SAD) for each router interface. Thus, the selected Security 2409 Association for an inbound PIM-DM packet can vary depending on the 2410 interface on which the packet arrived. This fact allows the network 2411 administrator to use different authentication methods for each link, 2412 even though the destination address is the same for most PIM-DM packets, 2413 regardless of interface. 2415 9.4 Denial of Service Attacks 2417 There are a number of possible denial of service attacks against PIM 2418 that can be caused by generating false PIM protocol messages or even by 2419 generating false data traffic. Authenticating PIM protocol traffic 2420 prevents some, but not all of these attacks. The possible attacks 2421 include: 2423 * Sending packets to many different group addresses quickly can be a 2424 denial of service attack in and of itself. These messages will 2425 initially be flooded throughout the network before they are pruned 2426 back. The maintenance of state machines and State Refresh messages 2427 will be a continual drain on network resources. 2429 * Forged State Refresh messages sent quickly could be propagated by 2430 downstream routers, creating a potential denial of service attack. 2431 Therefore, a PIM-DM router SHOULD rate limit State Refresh messages 2432 propagated. 2434 10. Authors' Addresses 2436 Andrew Adams 2437 NextHop Technologies 2438 825 Victors Way, Suite 100 2439 Ann Arbor, MI 48108-2738 2440 ala@nexthop.com 2442 Jonathan Nicholas 2443 ITT Industries 2444 Aerospace/Communications Division 2445 100 Kingsland Rd 2446 Clifton, NJ 07014 2447 jonathan.nicholas@itt.com 2449 William Siadak 2450 NextHop Technologies 2451 825 Victors Way, Suite 100 2452 Ann Arbor, MI 48108-2738 2453 wfs@nexthop.com 2455 11. Acknowledgments 2456 The major features of PIM-DM were originally designed by Stephen 2457 Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy, 2458 David Meyer, and Liming Wei. Additional features for state refresh 2459 were designed by Dino Farinacci, Isidor Kouvelas and Kurt Windisch. 2460 This revision was undertaken to incorporate some of the lessons learned 2461 during the evolution of the PIM-SM specification and early deployments 2462 of PIM-DM. 2464 Thanks the PIM Working Group for their comments. 2466 12. References 2468 [1] S.E. Deering, "Multicast Routing in a Datagram Internetwork", 2469 Ph.D. Thesis, Electrical Engineering Dept., Stanford University, 2470 December 1991. 2472 [2] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast 2473 Routing Protocol", November 1988, RFC 1075 2475 [3] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol 2476 Independent Multicast - Sparse Mode (PIM-SM)", 2477 draft-ietf-pim-sm-v2-new-04.txt, work in progress. 2479 [4] S.E. Deering, "Host Extensions for IP Multicasting", August 1989, 2480 RFC 1112. 2482 [5] W.Fenner, "Internet Group Management Protocol, Version 2", 2483 November 1997, RFC 2236. 2485 [6] IANA, "Address Family Numbers", linked from 2486 http://www.iana.org/numbers.html. 2488 [7] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 2489 Considerations Section in RFCs", October 1998, RFC 2434. 2491 [8] S. Kent, R. Atkinson, "Security Architecture for the Internet 2492 Protocol", November 1998, RFC 2401. 2494 [9] H.Holbrook, B. Cain, "Source Specific Multicast for IP", 2495 draft-holbrook-ssm-00.txt, work in progress. 2497 [10] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, 2498 "Internet Group Management Protocol, Version 3", 2499 draft-ietf-idmr-igmp-v3-09.txt, work in progress. 2501 [11] D. Thaler, "Interoperability Rules for Multicast Routing 2502 Protocols", October 1999, RFC 2715 2504 [12] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol 2505 Independent Multicast MIB for IPv4", October 2000, RFC 2934 2507 [13] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 2508 Specification", December 1998, RFC 2460. 2510 [14] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional 2511 Protocol Independent Multicast", draft-ietf-pim-bidir-03.txt, 2512 work in progress. 2514 [15] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Bootstrap Router 2515 (BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-02.txt, 2516 work in progress. 2518 [16] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group Domain of 2519 Interpretation", draft-ietf-msec-gdoi-03.txt, work in progress.