idnits 2.17.00 (12 Aug 2021) /tmp/idnits20269/draft-ietf-pim-dm-new-v2-00.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. == There are 6 instances of lines with non-ascii characters in the document. == 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 45 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 15 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 391: '...st, an RPF check MUST be performed to ...' RFC 2119 keyword, line 393: '...ts that fail the RPF check MUST NOT be...' RFC 2119 keyword, line 396: '...cannot be found MUST be discarded....' RFC 2119 keyword, line 429: '...(HT) MUST be set to a random value bet...' RFC 2119 keyword, line 433: '...ge, a Hello message MUST be sent every...' (127 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1621 has weird spacing: '...Ignored upon...' -- 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 (November 21, 2001) is 7485 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: '2' is defined on line 2286, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2291, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2293, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 2307, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2312, 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) -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-02) exists of draft-ietf-pim-simplekmp-01 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-04) exists of draft-holbrook-ssm-00 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: draft-ietf-idmr-igmp-v3 has been published as RFC 3376 ** Downref: Normative reference to an Informational RFC: RFC 2715 (ref. '13') ** Downref: Normative reference to an Experimental RFC: RFC 2934 (ref. '14') Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 8 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 Technologies) 3 draft-ietf-pim-dm-new-v2-00.txt Jonathan Nicholas (ITT A/CD) 4 William Siadak (NextHop Technologies) 5 November 21, 2001 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. . . . . . . . . . . . . . . . . 6 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. . . . . . . . . . . . . . . . . . 9 60 6.3.5. Reducing Prune Propagation Delay on LANs . . . . . . . . . 10 61 6.4. PIM-DM Prune, Join and Graft Messages. . . . . . . . . . . . . 10 62 6.4.1. Upstream Prune, Join and Graft Messages . . . . . . . . . . 11 63 6.4.2. Downstream Prune, Join and Graft Messages . . . . . . . . . 16 64 6.5. State Refresh. . . . . . . . . . . . . . . . . . . . . . . . . 20 65 6.5.1. Forwarding of State Refresh Messages. . . . . . . . . . . . 20 66 6.5.2. State Refresh Message Origination . . . . . . . . . . . . . 21 67 6.6. PIM Assert Messages. . . . . . . . . . . . . . . . . . . . . . 23 68 6.6.1. Assert Metrics. . . . . . . . . . . . . . . . . . . . . . . 23 69 6.6.2. AssertCancel Messages . . . . . . . . . . . . . . . . . . . 24 70 6.6.3. Assert State Macros . . . . . . . . . . . . . . . . . . . . 24 71 6.6.4. (S,G) Assert Message State Machine. . . . . . . . . . . . . 25 72 6.6.5. Rationale for Assert Rules. . . . . . . . . . . . . . . . . 29 73 6.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . . 30 74 6.7.1. PIM Header. . . . . . . . . . . . . . . . . . . . . . . . . 30 75 6.7.2. Encoded Unicast Address . . . . . . . . . . . . . . . . . . 31 76 6.7.3. Encoded Group Address . . . . . . . . . . . . . . . . . . . 31 77 6.7.4. Encoded Source Address. . . . . . . . . . . . . . . . . . . 32 78 6.7.5. Hello Message Format. . . . . . . . . . . . . . . . . . . . 33 79 6.7.6. Join/Prune Message Format . . . . . . . . . . . . . . . . . 35 80 6.7.7. Assert Message Format . . . . . . . . . . . . . . . . . . . 37 81 6.7.8. Graft Message Format. . . . . . . . . . . . . . . . . . . . 37 82 6.7.9. Graft Ack Message Format. . . . . . . . . . . . . . . . . . 37 83 6.6.10. State Refresh Message Format . . . . . . . . . . . . . . . 38 84 6.8. PIM-DM Timers. . . . . . . . . . . . . . . . . . . . . . . . . 39 85 6.8.1. Timer Values. . . . . . . . . . . . . . . . . . . . . . . . 40 86 7. Protocol Interaction Considerations . . . . . . . . . . . . . . . 43 87 7.1. PIM-SM Interactions. . . . . . . . . . . . . . . . . . . . . . 43 88 7.2. IGMP Interactions. . . . . . . . . . . . . . . . . . . . . . . 43 89 7.3. Source Specific Multicast (SSM) Interactions . . . . . . . . . 43 90 7.4. Multicast Group Scope Boundary Interactions. . . . . . . . . . 43 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 44 92 8.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . . 44 93 8.2. PIM Hello Options. . . . . . . . . . . . . . . . . . . . . . . 44 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 44 95 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 96 11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . 45 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 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 Join/Prune messages, PIM Assert messages, 127 and IGMP information from local hosts. It essentially stores the 128 state of all multicast distribution trees at 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 upstream interfaces, including the router 141 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. 174 PIM-DM assumes that when a source starts sending, all downstream systems 175 want to receive multicast datagrams. Initially, multicast datagrams are 176 flooded to all areas of the network. PIM-DM uses RPF to prevent looping 177 of multicast datagrams while flooding. If some areas of the network do 178 not have group members, PIM-DM will prune off the forwarding branch by 179 instantiating prune state. 181 Prune state has a finite lifetime. When that lifetime expires, data 182 will again be forwarded down the previously pruned branch. 184 Prune state is associated with an (S,G) pair. When a new member for a 185 group G appears in a pruned area, a router can "graft" toward the source 186 S for the group, thereby turning the pruned branch back into a 187 forwarding branch. 189 The broadcast of datagrams followed by pruning of unwanted branches is 190 often referred to as a flood and prune cycle and is typical of dense 191 mode protocols. 193 In order to minimize repeated flooding of datagrams and subsequent 194 pruning associated with a particular (S,G) pair, PIM-DM uses a state 195 refresh message. This message is sent by the router(s) directly 196 connected to the source and is propagated throughout the network. When 197 received by a router on its RPF interface, the state refresh message 198 causes an existing prune state to be refreshed. 200 Compared with multicast routing protocols with built in topology 201 discovery mechanisms (e.g. DVMRP) PIM-DM has a simplified design and is 202 not hard-wired into a specific topology discovery protocol. However, 203 such a simplification does incur more overhead by causing flooding and 204 pruning to occur on some links that could be avoided if sufficient 205 topology information were available, i.e. to decide whether an interface 206 leads to any downstream members of a particular group. Additional 207 overhead is chosen in favor of the simplification and flexibility gained 208 by not depending on a specific topology discovery protocol. 210 PIM-DM differs from PIM-SM in two essential ways: 1) There are no 211 periodic joins transmitted, only explicitly triggered prunes and grafts. 212 2) There is no Rendezvous Point (RP). This is particularly important in 213 networks that cannot tolerate a single point of failure. (An RP is the 214 root of a shared multicast distribution tree. For more details see [3]). 216 6. Protocol Specification 218 The specification of PIM-DM is broken into several parts: 220 Section 6.1 details the protocol state stored. 221 Section 6.2 specifies the data packet forwarding rules. 222 Section 6.3 specifies generation and processing of Hello messages. 223 Section 6.4 specifies the Join, Prune and Graft generation and 224 processing rules. 225 Section 6.5 specifies the State Refresh generation and forwarding 226 rules. 227 Section 6.6 specifies the Assert generation and processing rules. 228 Section 6.7 gives details on PIM-DM Packet Formats 229 Section 6.8 summarizes PIM-DM timers and their defaults 231 6.1. PIM Protocol State 233 This section specifies all the protocol states that a PIM-DM 234 implementation should maintain in order to function correctly. We term 235 this state the Tree Information Base or TIB, as it holds the state of 236 all the multicast distribution trees at this router. In this 237 specification, we define PIM-DM mechanisms in terms of the TIB. 238 However, only a very simple implementation would actually implement 239 packet forwarding operations in terms of this state. Most 240 implementations will use this state to build a multicast forwarding 241 table, which would then be updated when the relevant state in the TIB 242 changes. 244 Although we specify precisely the state to be kept, this does not mean 245 that an implementation of PIM-DM needs to hold the state in this form. 246 This is actually an abstract state definition, which is needed in order 247 to specify the router's behavior. A PIM-DM implementation is free to 248 hold whatever internal state it requires, and will still be conformant 249 with this specification so long as it results in the same externally 250 visible protocol behavior as an abstract router that holds the following 251 state. 253 6.1.1. General Purpose State 255 A router stores the following non-group-specific state: 256 For each interface: 257 Neighbor State: 258 For each neighbor: 259 Information from neighbor's Hello 260 Neighbor's Gen ID. 261 Neighbor's LAN Prune Delay 262 Neighbor's Override Interval 263 Neighbor's State Refresh Capability 264 Neighbor liveness timer (NLT) 265 State Refresh Capable 267 6.1.2. (S,G) State 269 For every source/group pair (S,G), a router stores the following state: 271 (S,G) state: 272 For each interface: 273 Local Membership: 274 State: One of {"NoInfo", "Include"} 276 PIM (S,G) Prune State: 277 State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending" (PP)} 278 Prune Pending Timer (PPT) 279 Prune Timer (PT) 281 (S,G) Assert Winner State: 282 State: One of {"NoInfo" (NI), "I lost Assert" (L), 283 "I won Assert" (W)} 284 Assert Timer (AT) 285 Assert winner's IP Address 286 Assert winner's Assert Metric 288 Upstream interface-specific: 289 Graft/Prune State: 290 State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F), 291 "AckPending" (AP) } 292 GraftRetry Timer (GRT) 293 Override Timer (OT) 294 Prune Limit Timer (PLT) 296 Originator State 297 Source Active Timer (SAT) 298 State Refresh Timer (SRT) 300 6.1.3. State Summarization Macros 302 Using the state defined above, the following "macros" are defined and 303 will be used in the descriptions of the state machines and pseudocode in 304 the following sections. 306 The most important macros are those defining the outgoing interface list 307 (or "olist") for the relevant state. 309 immediate_olist(S,G) = pim_nbrs (-) prunes(S,G) (+) 310 ( pim_include(*,G) (-) pim_exclude(S,G) ) (+) 311 pim_include(S,G) (-) lost_assert(S,G) (-) 312 boundary(G) 314 olist(S,G) = immediate_olist(S,G) (-) RPF_interface(S) 316 The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces 317 to which traffic might be forwarded or not forwarded because of hosts 318 that are local members on those interfaces. 320 pim_include(*,G) = {all interfaces I such that: 321 local_receiver_include(*,G,I)} 322 pim_include(S,G) = {all interfaces I such that: 323 local_receiver_include(S,G,I)} 324 pim_exclude(S,G) = {all interfaces I such that: 325 local_receiver_exclude(S,G,I) } 327 The macro RPF_interface(S) returns the RPF interface for source, S. 328 That is to say, it returns the interface used to reach S as indicated by 329 the MRIB. 331 The macro local_receiver_include(S,G,I) is true if the IGMP module or 332 other local membership mechanism has determined that there are local 333 members on interface I that desire to receive traffic sent specifically 334 by S to G. 336 The macro local_receiver_include(*,G,I) is true if the IGMP module or 337 other local membership mechanism has determined that there are local 338 members on interface I that desire to receive all traffic sent to G. 339 Note that this determination is expected to account for membership joins 340 initiated on or by the router. 342 The macro local_receiver_exclude(S,G,I) is true if 343 local_receiver_include(*,G,I) is true but none of the local members 344 desire to receive traffic from S. 346 The set pim_nbrs is the set of all interfaces on which the router has at 347 least one active PIM neighbor. 349 The set prunes(S,G) is the set of all interfaces on which the router has 350 received Prune(S,G) messages: 352 prunes(S,G) ={all interfaces I such that 353 DownstreamPState(S,G,I) is in Pruned state} 355 The set lost_assert(S,G) is the set of all interfaces on which the 356 router has lost an (S,G) Assert. 358 lost_assert(S,G) = {all interfaces I such that 359 lost_assert(S,G,I) == TRUE } 361 boundary(G) = {all interfaces I with an administratively scoped 362 boundary for group G} 364 The following pseudocode macro definitions are also used in many places 365 in the specification. Basically RPF' is the RPF neighbor towards a 366 source unless a PIM-DM Assert has overridden the normal choice of 367 neighbor. 369 neighbor RPF'(S,G) { 370 if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) { 371 return AssertWinner(S, G, RPF_interface(S) ) 372 } else { 373 return MRIB.next_hop( S ) 374 } 375 } 377 The macro I_Am_Assert_loser(S, G, I) is true if the Assert state machine 378 (in section 6.6) for (S,G) on interface I is in the "I am Assert Loser" 379 state. 381 6.2. Data Packet Forwarding Rules 383 The PIM-DM packet forwarding rules are defined below in pseudocode. 385 iif is the incoming interface of the packet. 386 S is the source address of the packet. 387 G is the destination address of the packet (group address). 388 RPF_interface(S) is the interface the MRIB indicates would be used to 389 route packets to S. 391 First, an RPF check MUST be performed to determine whether the packet 392 should be accepted based on TIB state and the interface on which that 393 the packet arrived. Packets that fail the RPF check MUST NOT be 394 forwarded and the router will conduct an assert process for the (S,G) 395 pair specified in the packet. Packets for which a route to the source 396 cannot be found MUST be discarded. 398 If the RPF check has been passed, an outgoing interface list is 399 constructed for the packet. If this list is not empty, then the packet 400 MUST be forwarded to all listed interfaces. If the list is empty, then 401 the router will conduct a prune process for the (S,G) pair specified in 402 the packet. 404 On receipt on a data packet from S addressed to G on interface iif: 406 if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned ) { 407 oiflist = olist(S,G) 408 } 409 else { 410 oiflist = NULL 411 } 412 forward packet on all interfaces in oiflist 414 This pseudocode employs the following "macro" definition: 416 UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in 417 6.4.1. Upstream Prune, Join and Graft Messages. 419 6.3. Hello Messages 421 This section describes the generation and processing of Hello messages. 423 6.3.1. Sending Hello Messages 425 PIM-DM uses Hello messages to detect other PIM routers. Hello messages 426 are sent periodically on each PIM enabled interface. Hello messages are 427 multicast to address 224.0.0.13 (the ALL PIM ROUTERS group). When PIM 428 is enabled on an interface or a router first starts, the Hello Timer 429 (HT) MUST be set to a random value between 0 and Hello_Period. This 430 prevents synchronization of Hello messages if multiple routers are 431 powered on simultaneously. 433 After the initial Hello message, a Hello message MUST be sent every 434 Hello_Period. A single Hello timer MAY be used to trigger sending Hello 435 messages on all active interfaces. The Hello Timer SHOULD NOT be reset 436 except when it expires. 438 6.3.2. Receiving Hello Messages 440 When a Hello message is received, the receiving router SHALL record the 441 receiving interface and the sender. This information is retained for a 442 number of seconds in the Hold Time field of the Hello Message. If a new 443 Hello message is received from a particular neighbor N, the Neighbor 444 Liveness Timer (NLT(N,I)) MUST be reset to the new value. 446 6.3.3. Hello Message Hold Time 448 The Hold Time in the Hello Message should be set to a value that can 449 reasonably be expected to keep the Hello active until a new Hello 450 message is received. On most links, this will be 3.5 times the value of 451 Hello_Period. 453 If the Hold Time is set to '0xffff', the receiving router MUST NOT time 454 out that Hello message. This feature might be used for on-demand links 455 to avoid keeping the link up with periodic Hello messages. 457 If a Hold Time of '0' is received, the corresponding neighbor state is 458 expired immediately. When an interface goes down or changes IP address, 459 a Hello message with a zero Hold Time SHOULD be sent immediately (with 460 the old IP address if the IP address is changed) to cause any PIM 461 neighbors to remove the old information immediately. 463 6.3.4. Handling Router Failures 465 If a Hello message is received from an active downstream neighbor with a 466 different Generation ID (GenID), the neighbor has restarted and may not 467 contain the correct (S,G) state. The router MAY replay the last State 468 Refresh message for any (S,G) pairs for which it is the Assert Winner 469 indicating Prune and Assert status to the downstream router. These 470 State Refresh messages SHOULD be sent out at t_override (see 6.8.1). 472 Upon startup, a router MAY use any State Refresh messages received 473 within J/P_Override_Interval of its first Hello message on an interface 474 to establish state information. The State Refresh source will be the 475 RPF'(S), and Prune status for all interfaces will be set according to 476 the Prune Indicator bit in the State Refresh message. If the Prune 477 Indicator is set, the router will set the PruneLimitTimer to 478 Prune_Holdtime and set the PruneTimer on all downstream interfaces to 479 the State Refresh's Interval times two. The router will then propagate 480 the State Refresh as described in section 6.5.1. 482 6.3.5. Reducing Prune Propagation Delay on LANs 484 If all routers on a LAN support the LAN Prune Delay option, then the PIM 485 routers on that LAN SHOULD use the values received to adjust its 486 J/P_Override_Interval on that interface. Briefly, to avoid 487 synchronization of Prune Override (Join) messages when multiple 488 downstream routers share a multi-access link, sending of such messages 489 is delayed by a small random amount of time. The period of randomization 490 is configurable and has a default value of 3 seconds. 492 Each router on the LAN expresses its view of the amount of randomization 493 necessary in the Override Interval field of the LAN Prune Delay option. 494 When all routers on a LAN use the LAN Prune Delay Option, all routers on 495 the LAN SHOULD set their Override_Interval to the largest Override value 496 on the LAN. 498 The LAN Delay inserted by a router in the LAN Prune Delay option 499 expresses the expected message propagation delay on the link and SHOULD 500 be configurable by the system administrator. When all routers on a link 501 use the LAN Prune Delay Option, all routers on the LAN SHOULD set 502 Propagation Delay to the largest LAN Delay on the LAN. PIM implementers 503 should enforce a lower bound on the permitted values for this delay to 504 allow for scheduling and processing delays within their router. Such 505 delays may cause received messages to be processed later as well as 506 triggered messages to be sent later than intended. Setting this LAN 507 Prune Delay to too low a value may result in temporary forwarding 508 outages because a downstream router will not be able to override a 509 neighbor's prune message before the upstream neighbor stops forwarding. 511 6.4. PIM-DM Prune, Join and Graft Messages 513 This section describes the generation and processing of PIM-DM Join, 514 Prune and Graft messages. Prune messages are sent towards an upstream 515 neighbor for S to indicate that traffic from S addressed to group G is 516 not desired. In the case of two downstream routers A and B, where A 517 wishes to continue receiving data and B does not, A will send a Join in 518 response to B's Prune to override the Prune. This is the only situation 519 in PIM-DM in which a Join message is used. Finally, a Graft message is 520 used to re-join a previously pruned branch to the delivery tree. 522 6.4.1. Upstream Prune, Join and Graft Messages 524 The Upstream(S,G) state machine for sending Prune, Graft and Join 525 messages is given below. There are three states. 527 Forwarding (F) 528 This is the starting state of the Upsteam(S,G) state machine. The 529 state machine is in this state if it just started or if 530 oiflist(S,G) != NULL. 532 Pruned(P) 533 The set, olist(S,G), is empty The router will not forward data 534 from S addressed to group G. 536 AckPending(AP) 537 The router was in the Pruned(P) state but a transition has occurred 538 in the Downstream(S,G) state machine for one of this (S,G) entry's 539 outgoing interfaces indicating that traffic from S addressed to G 540 should again be forwarded. A Graft message has been sent to RPF'(S) 541 but a Graft Ack message has not yet been received. 543 In addition there are three state-machine-specific timers: 545 GraftRetry Timer (GRT(S,G)) 546 This timer is set when a Graft is sent upstream. If a corresponding 547 GraftAck is not received before the timer expires, then another 548 Graft is sent and the GraftRetry Timer is reset. The timer is 549 stopped when a Graft Ack message is received. This timer is normally 550 set to Graft_Retry_Period (see 6.8.1). 552 Override Timer (OT(S,G)) 553 This timer is set when a Prune(S,G) is received on the upstream 554 interface where olist(S,G) != NULL. When the timer expires, a 555 Join(S,G) message is sent on the upstream interface. This timer is 556 normally set to t_override (see 6.8.1). 558 Prune Limit Timer (PLT(S,G)) 559 This timer is used to rate-limit Prunes on a LAN. It is only used 560 when the Upstream(S,G) state machine is in the Pruned state. A Prune 561 cannot be sent if this timer is running. This timer is normally set 562 to t_limit (see 6.8.1) 564 [For State Machine Figure refer to Postscript Version] 566 Figure 1 Upstream Interface State Machine 568 In tabular form, the state machine is defined as follows: 570 +-------------------------------+--------------------------------------+ 571 | | Previous State | 572 + +------------+------------+------------+ 573 | Event | Forwarding | Pruned | AckPending | 574 +-------------------------------+------------+------------+------------+ 575 | Data packet arrives on | ->P Send | ->P Send | N/A | 576 | RPF_Interface(S) AND | Prune(S,G) | Prune(S,G) | | 577 | olist(S,G) == NULL AND |Set PLT(S,G)|Set PLT(S,G)| | 578 | PLT(S,G) not running | | | | 579 +-------------------------------+------------+------------+------------+ 580 | State Refresh(S,G) received | ->F Set | ->P Reset |->AP Set | 581 | from RPF'(S) AND | OT(S,G) | PLT(S,G) | OT(S,G) | 582 | Prune Indicator == 1 | | | | 583 +-------------------------------+------------+------------+------------+ 584 | State Refresh(S,G) received | ->F | ->P Send |->F Cancel | 585 | from RPF'(S) AND | | Prune(S,G) | GRT(S,G) | 586 | Prune Indicator == 0 AND | |Set PLT(S,G)| | 587 | PLT(S,G) not running | | | | 588 +-------------------------------+------------+------------+------------+ 589 | See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel | 590 | | OT(S,G) | | OT(S,G) | 591 +-------------------------------+------------+------------+------------+ 592 | See Prune(S,G) | ->F Set | ->P |->AP Set | 593 | | OT(S,G) | | OT(S,G) | 594 +-------------------------------+------------+------------+------------+ 595 | OT(S,G) Expires | ->F Send | N/A |->AP Send | 596 | | Join(S,G) | | Join(S,G) | 597 +-------------------------------+------------+------------+------------+ 598 | olist(S,G)->NULL | ->P Send | N/A |->P Send | 599 | | Prune(S,G) | | Prune(S,G) | 600 | |Set PLT(S,G)| |Set PLT(S,G)| 601 +-------------------------------+------------+------------+------------+ 602 | olist(S,G)->non-NULL | N/A | ->AP Send | N/A | 603 | | | Graft(S,G) | | 604 | | |Set GRT(S,G)| | 605 +-------------------------------+------------+------------+------------+ 606 | RPF'(S) Changes AND | ->AP Send | ->AP Send |->AP Send | 607 | olist(S,G) != NULL | Graft(S,G) | Graft(S,G) | Graft(S,G) | 608 | |Set GRT(S,G)|Set GRT(S,G)|Set GRT(S,G)| 609 +-------------------------------+------------+------------+------------+ 610 | RPF'(S) Changes AND | ->P | ->P Cancel |->P Cancel | 611 | olist(S,G) == NULL | | PLT(S,G) | GRT(S,G) | 612 +-------------------------------+------------+------------+------------+ 613 | S becomes directly connected | ->F | ->P |->F Cancel | 614 | | | | GRT(S,G) | 615 +-------------------------------+------------+------------+------------+ 616 | GRT(S,G) Expires | N/A | N/A |->AP Send | 617 | | | | Graft(S,G) | 618 | | | |Set GRT(S,G)| 619 +-------------------------------+------------+------------+------------+ 620 | Receive GraftAck(S,G) from | ->F | ->P |->F Cancel | 621 | RPF'(S) | | | GRT(S,G) | 622 +-------------------------------+------------+------------+------------+ 624 The transition event 'Receive GraftAck(S,G)' implies receiving a Graft 625 Ack message targeted to this router's address on the incoming interface 626 for the (S,G) entry. If the destination address is not correct, the 627 state transitions in this state machine must not occur. 629 Transitions from the Forwarding (F) State 631 When the Upstream(S,G) state machine is in the Forwarding (F) 632 state, the following events may trigger a transition: 634 Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND S 635 NOT directly connected 636 The Upstream(S,G) state machine MUST transition to the Pruned (P) 637 state, send a Prune(S,G) to RPF’(S) and set PLT(S,G) to t_limit 638 seconds. 640 olist(S,G) -> NULL AND S NOT directly connected 641 The Upstream(S,G) state machine MUST transition to the Pruned (P) 642 state, send a Prune(S,G) to RPF’(S) and set PLT(S,G) to t_limit 643 seconds. 645 See Prune(S,G) AND S NOT directly connected 646 This event is only relevant if RPF_interface(S) is a shared medium. 647 This router sees another router on RPF_interface(S) send a 648 Prune(S,G). As this router is in Forwarding state, it must override 649 the Prune after a short random interval. If OT(S,G) is not running, 650 the router MUST set OT(S,G) to t_override seconds. The 651 Upstream(S,G) state machine remains in Forwarding (F) state. 653 See Join(S,G) to RPF'(S) 654 This event is only relevant if RPF_interface(S) is a shared medium. 655 This router sees another router on RPF_interface(S) send a Join(S,G) 656 to RPF'(S,G). If the OT(S,G) is running, then it means that the 657 router had scheduled a Join to override a previously received Prune. 658 Another router has responded more quickly with a Join and so the 659 local router SHOULD cancel its OT(S,G), if it is running. The 660 Upstream(S,G) state machine remains in the Forwarding (F) state. 662 OT(S,G) Expires AND S NOT directly connected 663 The OverrideTimer (OT(S,G)) expires. The router MUST send a 664 Join(S,G) to RPF'(S) to override a previously detected prune. The 665 Upstream(S,G) state machine remains in the Forwarding (F) state. 667 RPF'(S) Changes AND olist(S,G) is non-null AND S NOT directly 668 connected 669 Unicast routing or Assert state causes RPF'(S) to change, including 670 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 671 transition to the AckPending (AP) state, unicast a Graft to the new 672 RPF'(S) and set the GraftRetry Timer (GRT(S,G)) to 673 Graft_Retry_Period. 675 State Refresh(S,G) Received from RPF'(S) 676 The Upstream(S,G) state machine remains in a Forwarding state. If 677 the received State Refresh has the Prune Indicator bit set to one, 678 this router must override the upstream router's Prune state after a 679 short random interval. If OT(S,G) is not running and the Prune 680 Indicator bit equals one, the router MUST set OT(S,G) to t_override 681 seconds. 683 Transitions from the Pruned (P) State 685 When the Upstream(S,G) state machine is in the Pruned (P) state, the 686 following events may trigger a transition: 688 olist(S,G)->non-null AND S NOT directly connected 689 The set of interfaces defined by the olist(S,G) macro becomes non- 690 empty indicating traffic from S addressed to group G must be 691 forwarded. The Upstream(S,G) state machine MUST cancel PLT(S,G), 692 transition to the AckPending (AP) state and unicast a Graft message 693 to RPF'(S). The Graft Retry Timer (GRT(S,G)) MUST be set to 694 Graft_Retry_Period. 696 See Prune(S,G) to RPF'(S) 697 A Prune(S,G) is seen on RPF_interface(S) to RPF'(S). The 698 Upstream(S,G) state machine stays in the Pruned (P) state. The 699 router MAY reset its PLT(S,G) to the value in the Holdtime field of 700 the received message if greater than the current value of the 701 PLT(S,G). 703 RPF'(S) Changes AND olist(S,G) -> non-null AND S NOT directly 704 connected 705 Unicast routing or Assert state causes RPF'(S) to change, including 706 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 707 cancel PLT(S,G), transition to the AckPending (AP) state, send a 708 Graft unicast to the new RPF'(S) and set the GraftRetry Timer 709 (GRT(S,G)) to Graft_Retry_Period. 711 RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected 712 Unicast routing or Assert state causes RPF'(S) to change, including 713 changes to RPF_Interface(S). The Upstream(S,G) state machine stays 714 in the Pruned (P) state and MUST cancel the PLT(S,G) timer. 716 S becomes directly connected 717 Unicast routing changed so that S is directly connected. The 718 Upstream(S,G) state machine remains in the Pruned (P) state. 720 Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT 721 directly connected 722 Either another router on the LAN desires traffic from S addressed 723 to G or a previous Prune was lost. In order to prevent generating 724 a Prune(S,G) in response to every data packet, the PruneLimit 725 Timer (PLT(S,G)) is used. Once the PLT(S,G) expires, the router 726 needs to send another prune in response to a data packet not 727 received directly from the source. A Prune(S,G) MUST be sent to 728 RPF'(S) and the PLT(S,G) MUST be set to t_limit. 730 State Refresh(S,G) Received from RPF'(S) 731 The Upstream(S,G) state machine remains in a Pruned state. If the 732 State Refresh has its Prune Indicated bit set to zero and PLT(S,G) 733 is not running, a Prune(S,G) MUST be sent to RPF'(S) and the 734 PLT(S,G) MUST be set to t_limit. If the State Refresh has its 735 Prune Indicated bit set to one, the router MUST reset PLT(S,G) to 736 t_limit. 738 Transitions from the AckPending (AP) State 740 When the Upstream(S,G) state machine is in the AckPending (AP) state, 741 the following events may trigger a transition: 743 GRT(S,G) Expires 744 The GraftRetry Timer (GRT(S,G)) expires for this (S,G) entry. The 745 Upstream(S,G) state machine stays in the AckPending (AP) state. 746 Another Graft message for (S,G) SHOULD be unicasted to RPF'(S) and 747 the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period. Note 748 that RPF’(S) may have changed since the previous Graft. 750 RPF'(S) Changes AND olist(S,G) does not become NULL 751 Unicast routing or Assert state causes RPF'(S) to change, including 752 changes to RPF_Interface(S). The Upstream(S,G) state machine stays 753 in the AckPending (AP) state. A Graft MUST be unicast to the new 754 RPF’(S) and the GraftRetry Timer (GRT(S,G)) reset to 755 Graft_Retry_Period. 757 S becomes directly connected 758 Unicast routing has changed so that S is directly connected. The 759 GraftRetry Timer MUST be cancelled and the Upstream(S,G) state 760 machine MUST transition to the Forwarding(F) state. 762 See GraftAck(S,G) from RPF'(S) 763 A GraftAck is received from RPF'(S). The GraftRetry Timer MUST be 764 cancelled and the Upstream(S,G) state machine MUST transition to the 765 Forwarding(F) state. 767 olist(S,G) -> NULL 768 The set of interfaces defined by the olist(S,G) macro becomes null 769 indicating traffic from S addressed to group G should no longer be 770 forwarded. The Upstream(S,G) state machine MUST transition to the 771 Pruned (P) state. A Prune(S,G) MUST be multicast to the 772 RPF_interface(S) with RPF'(S) named in the upstream neighbor field. 773 The GraftRetry Timer (GRT(S,G)) MUST be cancelled. 775 See Prune(S,G) 776 This event is only relevant if RPF_interface(S) is a shared medium. 777 This router sees another router on RPF_interface(S) send a 778 Prune(S,G). As this router is in AckPending (AP) state, it must 779 override the Prune after a short random interval. If OT(S,G) is 780 not running, the router MUST set OT(S,G) to t_override seconds. 781 The Upstream(S,G) state machine remains in AckPending (AP) state. 783 See Join(S,G) to RPF'(S,G) 784 This event is only relevant if RPF_interface(S) is a shared medium. 785 This router sees another router on RPF_interface(S) send a Join(S,G) 786 to RPF'(S,G). If the OT(S,G) is running, then it means that the 787 router had scheduled a Join to override a previously received Prune. 788 Another router has responded more quickly with a Join and so the 789 local router SHOULD cancel its OT(S,G), if it is running. 790 The Upstream(S,G) state machine remains in the AckPending (AP) 791 state. 793 OT(S,G) Expires 794 The OverrideTimer (OT(S,G)) expires. The router MUST send a 795 Join(S,G) to RPF'(S). The Upstream(S,G) state machine remains in 796 the AckPending (AP) state. 798 State Refresh(S,G) Received from RPF’(S) with Prune Indicator == 1 799 The Upstream(S,G) state machine remains in an AckPending state. 800 The router must override the upstream router's Prune state after a 801 short random interval. If OT(S,G) is not running and the Prune 802 Indicator bit equals one, the router MUST set OT(S,G) to t_override 803 seconds. 805 State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 0 806 The router MUST cancel its GraftRetry Timer (GRT(S,G)) and 807 transition to the Forwarding (F) state. 809 6.4.2. Downstream Prune, Join and Graft Messages 811 The Prune(S,G) Downstream state machine for receiving Prune, Join and 812 Graft messages on interface I is given below. This state machine MUST 813 always be in the NoInfo state on the upstream interface. It contains 814 three states. 816 NoInfo(NI) 817 The interface has no (S,G) Prune state and neither the Prune timer 818 (PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is running. 820 PrunePending(PP) 821 The router has received a Prune(S,G) on this interface from a 822 downstream neighbor and is waiting to see whether the prune will be 823 overridden by another downstream router. For forwarding purposes, 824 the PrunePending state functions exactly like the NoInfo state. 826 Pruned(P) 827 The router has received a Prune(S,G) on this interface from a 828 downstream neighbor and the Prune was not overridden. Data from S 829 addressed to group G is no longer being forwarded on this interface. 831 In addition there are two timers: 833 PrunePending Timer (PPT(S,G,I)) 834 This timer is set when a valid Prune(S,G) is received. Expiry of 835 the PrunePending Timer (PPT(S,G,I)) causes the interface to 836 transition to the Pruned state. 838 Prune Timer (PT(S,G,I)) 839 This timer is set when the PrunePending Timer (PT(S,G,I)) expires. 840 Expiry of the Prune Timer (PT(S,G,I)) causes the interface to 841 transition to the NoInfo (NI) state, thereby allowing data from S 842 addressed to group G to be forwarded on the interface. 844 [For State Machine Figure refer to Postscript Version] 846 Figure 2: Prune(S,G) Downstream State Machine 848 In tabular form, the state machine is: 850 +-------------------------------+--------------------------------------+ 851 | | Previous State | 852 + +------------+------------+------------+ 853 | Event | No Info | PrunePend | Pruned | 854 +-------------------------------+------------+------------+------------+ 855 | Receive Prune(S,G) |->PP Set |->PP |->P Reset | 856 | | PPT(S,G,I) | | PT(S,G,I) | 857 +-------------------------------+--------------------------------------+ 858 | Receive Join(S,G) |->NI |->NI Cancel |->NI Cancel | 859 | | | PPT(S,G,I) | PT(S,G,I) | 860 +-------------------------------+--------------------------------------+ 861 | Receive Graft(S,G) |->NI Send |->NI Send |->NI Send | 862 | | GraftAck | GraftAck | GraftAck | 863 | | | Cancel | Cancel | 864 | | | PPT(S,G,I) | PT(S,G,I) | 865 +-------------------------------+--------------------------------------+ 866 | PPT(S,G) Expires | N/A |->P Set | N/A | 867 | | | PT(S,G,I) | | 868 +-------------------------------+--------------------------------------+ 869 | PT(S,G) Expires | N/A | N/A |->NI | 870 +-------------------------------+--------------------------------------+ 871 | RPF_Interface(S) becomes I |->NI |->NI Cancel |->NI Cancel | 872 | | | PPT(S,G,I) | PT(S,G,I) | 873 +-------------------------------+--------------------------------------+ 875 The transition events 'Receive Graft(S,G)', 'Receive Prune(S,G)' and 876 'Receive Join(S,G)' denote receiving a Graft, Prune or Join message in 877 which this router's address on I is contained in the message's upstream 878 neighbor field. If the upstream neighbor field does not match this 879 router's address on I, then these state transitions in this state 880 machine must not occur. 882 Transitions from the NoInfo State 884 When the Prune(S,G) Downstream state machine is in the NoInfo (NI) 885 state, the following events may trigger a transition: 887 Receive Prune(S,G) 888 A Prune(S,G) is received on interface I with the upstream neighbor 889 field set to the router's address on I. The Prune(S,G) Downstream 890 state machine on interface I MUST transition to the PrunePending(PP) 891 state. The PrunePending Timer (PPT(S,G,I)) MUST be set to 892 J/P_Override_Interval if the router has more than one neighbor on I. 893 If the router has only one neighbor on interface I, then it SHOULD 894 set the PPT(S,G,I) to zero, effectively transitioning immediately to 895 the Pruned (P) state. 897 Receive Graft(S,G) 898 A Graft(S,G) is received on the interface I with the upstream 899 neighbor field set to the router's address on I. The Prune(S,G) 900 Downstream state machine on interface I stays in the NoInfo (NI) 901 state. A GraftAck(S,G) MUST be unicasted to the originator of the 902 Graft(S,G) message. 904 Transitions from the PrunePending (PP) State 906 When the Prune(S,G) downstream state machine is in the PrunePending (PP) 907 state, the following events may trigger a transition. 909 Receive Graft(S,G) 910 A Graft(S,G) is received on interface I with the upstream neighbor 911 field set to the router's address on I. The Prune(S,G) Downstream 912 state machine on interface I MUST transition to the NoInfo (NI) 913 state and MUST unicast a Graft Ack message to the Graft originator. 914 The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. 916 Receive Join(S,G) 917 A Join(S,G) is received on interface I with the upstream neighbor 918 field set to the router's address on I. The Prune(S,G) Downstream 919 state machine on interface I MUST transition to the NoInfo (NI) 920 state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. 922 PPT(S,G,I) Expires 923 The PrunePending Timer (PPT(S,G,I)) expires indicating that no 924 neighbors have overridden the previous Prune(S,G) message. The 925 Prune(S,G) Downstream state machine on interface I MUST transition 926 to the Pruned (P) state.. The Prune Timer (PT(S,G,I)) is started 927 and MUST be initialized to the received Prune_Hold_Time minus 928 J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has 929 more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G) 930 message multicast by the upstream router to a LAN with itself as the 931 Upstream Neighbor. Its purpose is to add additional reliability so 932 that if a Join that should have overridden the Prune is lost locally 933 on the LAN, then the PruneEcho(S,G) may be received and trigger a 934 new Join message . A PruneEcho(S,G) is OPTIONAL on an interface 935 with only one PIM neighbor. 937 RPF_Interface(S) becomes interface I 938 The upstream interface for S has changed. The Prune(S,G) Downstream 939 state machine on interface I MUST transition to the NoInfo (NI) 940 state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. 942 Transitions from the Prune (P) State 944 When the Prune(S,G) Downstream state machine is in the Pruned (P) state, 945 the following events may trigger a transition. 947 Receive Graft(S,G) 948 A Graft(S,G) is received on interface I with the upstream neighbor 949 field set to the router's address on I. The Prune(S,G) Downstream 950 state machine on interface I MUST transition to the NoInfo (NI) 951 state. and send a Graft Ack back to the Graft's source. The Prune 952 Timer (PT(S,G,I)) MUST be cancelled. The router MUST evaluate any 953 possible transitions in the Upstream(S,G) state machine. 955 Receive Join(S,G) 956 A Join(S,G) is received on the interface I with the upstream 957 neighbor field set to the router's address on I. The Prune(S,G) 958 downstream state machine on interface I MUST transition to the 959 NoInfo (NI) state. The Prune Timer (PT(S,G,I)) MUST be cancelled. 960 The router MUST evaluate any possible transitions in the 961 Upstream(S,G) state machine. 963 Receive Prune(S,G) 964 A Prune(S,G) is received on the interface I with the upstream 965 neighbor field set to the router's address on I. The Prune(S,G) 966 Downstream state machine on interface I remains in the Pruned (P) 967 state. The Prune Timer (PT(S,G,I)) SHOULD be reset to the holdtime 968 contained in the Prune(S,G) message. 970 PT(S,G,I) Expires 971 The Prune Timer (PT(S,G,I)) expires indicating that it is again time 972 to flood data from S addressed to group G onto interface I. The 973 Prune(S,G) Downstream state machine on interface I MUST transition 974 to the NoInfo (NI) state. The router MUST evaluate any possible 975 transitions in the Upstream(S,G) state machine. 977 RPF_Interface(S) becomes interface I 978 The upstream interface for S has changed. The Prune(S,G) Downstream 979 state machine on interface I MUST transition to the NoInfo (NI) 980 state. The PruneTimer (PT(S,G,I)) MUST be cancelled. 982 6.5. State Refresh 984 This section describes the major portions of the state refresh 985 mechanism. 987 6.5.1. Forwarding of State Refresh Messages 989 When a State Refresh message, SRM, is received, it is forwarded 990 according to the following pseudo-code. 992 if (iif != RPF_interface(S)) 993 return; 994 if (RPF'(S) != srcaddr(SRM)) 995 return; 997 for each interface I in pim_nbrs { 998 if (TTL(SRM) == 0 OR TTL(SRM) - 1 < Threshold(I)) 999 continue; /* Out of TTL, skip this interface */ 1000 if (boundary(I,G)) 1001 continue; /* This interface is scope boundary, skip it */ 1002 if (I == iif) 1003 continue; /* This is the incoming interface, skip it */ 1005 Copy SRM to SRM'; /* Make a copy of SRM to forward */ 1007 if (I contained in Prunes(S,G)) { 1008 set Prune Indicator bit of SRM' to 1; 1010 if StateRefreshCapable(I) == TRUE 1011 set PT(S,G) to largest active holdtime read from a Prune message 1012 accepted on I; 1013 } 1014 else { 1015 set Prune Indicator bit of SRM' to 0; 1016 } 1018 set srcaddr(SRM') to my_addr(I); 1019 set TTL of SRM' to TTL(SRM) - 1; 1020 set metric of SRM' to metric of unicast route used to reach S; 1021 set pref of SRM' to prference of unicast route used to reach S; 1022 set mask of SRM' to mask of route used to reach S; 1023 if (AssertState == NoInfo) { 1024 set Assert Override of SRM' to 1; 1025 } else { 1026 set Assert Override of SRM' to 0; 1027 } 1029 transmit SRM' on I; 1030 } 1032 The pseudocode above employs the following macro definitions. 1034 Boundary(I,G) evaluates to TRUE if an administratively scoped boundary 1035 for group G is configured on interface I. 1037 StateRefreshCapable(I) evaluates to TRUE if all neighbors on an 1038 interface use the State Refresh option. 1040 TTL(SRM) returns the TTL contained in the State Refresh Message, SRM. 1041 This is different from the TTL contained in the IP header. 1043 Threshold(I) returns the minimum TTL that a packet must have before it 1044 can be transmitted on interface I. 1046 srcaddr(SRM) returns the source address contained in the network 1047 protocol (e.g. IPv4) header of the State Refresh Message, SRM. 1049 my_addr(I) returns this node's network (e.g. IPv4) address of interface 1050 I. 1052 6.5.2. State Refresh Message Origination 1054 This section describes the origination of State Refresh messages. These 1055 messages are generated periodically by the PIM-DM router that is 1056 directly connected to a source. One Origination(S,G) state machine 1057 exists per (S,G) entry in a PIM-DM router. 1059 The Origination(S,G) state machine has the following states. 1061 NotOriginator(NO) 1062 This is the starting state of the Origination(S,G) state machine. 1063 While in this state a router will not originate State Refresh 1064 messages for the (S,G) pair. 1066 Originator(O) 1067 When in this state the router will periodically originate State 1068 Refresh messages. Only routers which are directly connected to S 1069 may transition to this state. 1071 In addition there are two state-machine-specific timers: 1073 StateRefresh Timer (SRT(S,G)) 1074 This timer is controls when State Refresh messages are generated. 1075 The timer is initially set when that Origination(S,G) state 1076 machine transitions to the O state. It is cancelled when the 1077 Origination(S,G) state machine transitions to the NO state. This 1078 timer is normally set to StateRefreshInterval (see 6.8.1). 1080 SourceActive Timer (SAT(S,G)) 1081 This timer is first set when the Origination(S,G) state machine 1082 transitions to the O state and is reset on the receipt of every 1083 data packet from S addressed to group G. When it expires, the 1084 Origination(S,G) state machine transitions to the NO state. This 1085 timer is normally set to SourceLifetime (see 6.8.1). 1087 [For State Machine Figure refer to Postscript Version] 1089 Figure 3 Per-interface State Refresh State Diagram 1091 In tabular form, the state machine is defined as follows. 1093 +----------------------------------------------------------------------+ 1094 | | Previous State | 1095 | +---------------+-------------------+ 1096 | Event | NotOriginator | Originator | 1097 +----------------------------------+---------------+-------------------+ 1098 | Receive Data from S AND | ->O | ->O Reset | 1099 | S directly connected | Set SRT(S,G) | SAT(S,G) | 1100 | | Set SAT(S,G) | | 1101 +----------------------------------+---------------+-------------------+ 1102 | SRT(S,G) Expires | N/A | ->O Send | 1103 | | | StateRefresh(S,G) | 1104 | | | Reset SRT(S,G) | 1105 +----------------------------------+---------------+-------------------+ 1106 | SAT(S,G) Expires | N/A | ->NO Cancel | 1107 | | | SRT(S,G) | 1108 +----------------------------------+---------------+-------------------+ 1109 | S no longer directly connected | ->NO | ->NO | 1110 | | | Cancel SRT(S,G) | 1111 | | | Cancel SAT(S,G) | 1112 +----------------------------------+---------------+-------------------+ 1114 Transitions from the NotOriginator (NO) State 1116 When the Originating(S,G) state machine is in the NotOriginator 1117 (NO) state, the following event may trigger a transition: 1119 Data Packet received from directly connected Source S addressed to 1120 group G 1121 The router MUST transition to an Originator (O) state, set SAT(S,G) 1122 to SourceLifetime, and set SRT(S,G) to StateRefreshInterval. The 1123 router SHOULD record the TTL of the packet for use in State Refresh 1124 messages. 1126 Transitions from the Originator (O) State 1128 When the Originating(S,G) state machine is in the Originator (O) state, 1129 the following events may trigger a transition: 1131 SRT(S,G) Expires 1132 The router remains in the Originator (O) state and resets SRT(S,G) 1133 to StateRefreshInterval. The router also generates State Refresh 1134 messages for transmission over each interface on which there are 1135 PIM-DM neighbors except for the interface by which S is reached. If 1136 the TTL of data packets from S to G are being recorded, then the TTL 1137 of each State Refresh message is set to the highest recorded TTL. 1138 Otherwise, the TTL is set to the TTL of the interface over which the 1139 State Refresh message will be sent. Let I denote the interface over 1140 which a State Refresh message is being sent. If the Prune(S,G) 1141 Downstream state machine for I is in the NoInfo (NI) state, then the 1142 Prune-Indicator bit should be set to 0 in the State Refresh message 1143 being sent over I. Otherwise the Prune-Indicator bit should be set 1144 to 1. 1146 SAT(S,G) Expires 1147 The router cancels the SRT(S,G) timer and transitions to the 1148 NotOriginator (NO) state. 1150 Receive Data Packet from S addressed to G 1151 The router remains in the Originator (O) state and resets SAT(S,G) 1152 to SourceLifetime. The router SHOULD increase its recorded TTL to 1153 match the TTL of the packet, if the packet's TTL is larger than 1154 the previously recorded TTL. 1156 S is no longer directly connected 1157 The router remains transitions to the NotOriginator (NO) state and 1158 cancels both the SAT(S,G) and SRT(S,G). 1160 6.6. PIM Assert Messages 1162 6.6.1. Assert Metrics 1164 Assert metrics are defined as: 1166 struct assert_metric { 1167 metric_preference; 1168 route_metric; 1169 ip_address; 1170 }; 1172 When comparing assert_metrics, the metric_preference and route_metric 1173 field are compared in order, where the first lower value wins. If all 1174 fields are equal, the IP address of the router that sourced the Assert 1175 message is used as a tie-breaker, with the highest IP address winning. 1176 An Assert metric for (S,G) to include in (or compare against) an Assert 1177 message sent on interface I should be computed using the following 1178 pseudocode: 1180 assert_metric 1181 my_assert_metric(S,G,I) { 1183 if (CouldAssert(S,G,I) == TRUE ) { 1184 return spt_assert_metric(S,G,I) 1185 } else { 1186 return infinite_assert_metric() 1187 } 1188 } 1190 spt_assert_metric(S,I) gives the Assert metric we use if we're sending 1191 an Assert based on active (S,G) forwarding state: 1193 assert_metric 1194 spt_assert_metric(S,I) { 1195 return {0,MRIB.pref(S),MRIB.metric(S),my_ip_address(I)} 1196 } 1198 MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing 1199 metrics associated with the route to a particular (unicast) destination 1200 X, as determined by the MRIB. my_ip_address(I) is simply the router's 1201 IP address that is associated with the local interface I. 1203 infinite_assert_metric() gives the Assert metric we need to send an 1204 Assert but doesn't match (S,G) forwarding state: 1206 assert_metric 1207 infinite_assert_metric() { 1208 return {1,infinity,infinity,infinity} 1209 } 1211 6.6.2. AssertCancel Messages 1213 An AssertCancel(S,G) message is simply an Assert message for (S,G) with 1214 infinite metric. The Assert winner sends such a message when it changes 1215 its upstream interface to this interface. Other routers will see this 1216 metric, causing those with forwarding state to send their own Asserts 1217 and re-establish an Assert winner. 1219 AssertCancel messages are simply an optimization. The original Assert 1220 timeout mechanism will allow a subnet to eventually become consistent; 1221 the AssertCancel mechanism simply causes faster convergence. No special 1222 processing is required for an AssertCancel message, since it is simply 1223 an Assert message from the current winner. 1225 6.6.3. Assert State Macros 1227 The macro lost_assert(S,G,I), is used in the olist computations of 1228 section 6.1.3, and is defined as follows. 1230 bool lost_assert(S,G,I) { 1231 if ( RPF_interface(S) == I ) { 1232 return FALSE 1233 } else { 1234 return (AssertWinner(S,G,I) != me AND 1235 (AssertWinnerMetric(S,G,I) is better than 1236 spt_assert_metric(S,G,I) ) ) 1237 } 1238 } 1240 AssertWinner(S,G,I) defaults to Null and AssertWinnerMetric(S,G,I) 1241 defaults to Infinity when in the NoInfo state. 1243 6.6.4. (S,G) Assert Message State Machine 1245 The (S,G) Assert state machine for interface I is shown in Figure 4. 1247 There are three states: 1249 NoInfo (NI) 1250 This router has no (S,G) Assert state on interface I. 1252 I am Assert Winner (W) 1253 This router has won an (S,G) Assert on interface I. It is now 1254 responsible for forwarding traffic from S destined for G via 1255 interface I. 1257 I am Assert Loser (L) 1258 This router has lost an (S,G) Assert on interface I. It must not 1259 forward packets from S destined for G onto interface I. 1261 In addition there is also an Assert Timer (AT(S,G,I)) that is used to 1262 time out Assert state on the Assert losers and to resend Assert messages 1263 on the Assert winner. 1265 [For State Machine Figure refer to Postscript Version] 1267 Figure 4: Per-interface (S,G) Assert state machine 1269 In tabular form the state machine is defined as follows: 1271 +-------------------------------+--------------------------------------+ 1272 | | Previous State | 1273 + +------------+------------+------------+ 1274 | Event | No Info | Winner | Loser | 1275 +-------------------------------+------------+------------+------------+ 1276 | An (S,G) Data packet received | ->W Send | ->W Send | ->L | 1277 | on downstream interface | Assert(S,G)| Assert(S,G)| | 1278 | | Set | Set | | 1279 | | AT(S,G,I) | AT(S,G,I) | | 1280 +-------------------------------+--------------------------------------+ 1281 | Receive Inferior (Assert OR | N/A | N/A |->NI Cancel | 1282 | State Refresh) from Assert | | | AT(S,G,I) | 1283 | Winner | | | | 1284 +-------------------------------+--------------------------------------+ 1285 | Receive Inferior (Assert OR | ->W Send | ->W Send | ->L | 1286 | State Refresh) from non-Assert| Assert(S,G)| Assert(S,G)| | 1287 | Winner AND CouldAssert==TRUE | Set | Set | | 1288 | | AT(S,G,I) | AT(S,G,I) | | 1289 +-------------------------------+--------------------------------------+ 1290 | Receive Preferred Assert OR | ->L Send | ->L Send | ->L Set | 1291 | State Refresh | Prune(S,G) | Prune(S,G) | AT(S,G,I) | 1292 | | Set | Set | | 1293 | | AT(S,G,I) | AT(S,G,I) | | 1294 +-------------------------------+--------------------------------------+ 1295 | Send State Refresh | ->NI | ->W Reset | ->L | 1296 | | | AT(S,G,I) | | 1297 +-------------------------------+--------------------------------------+ 1298 | AT(S,G) Expires | N/A | ->NI | ->NI | 1299 +-------------------------------+--------------------------------------+ 1300 | CouldAssert -> FALSE | ->NI |->NI Cancel |->NI Cancel | 1301 | | | AT(S,G,I) | AT(S,G,I) | 1302 +-------------------------------+--------------------------------------+ 1303 | CouldAssert -> TRUE | ->NI | N/A |->NI Cancel | 1304 | | | | AT(S,G,I) | 1305 +-------------------------------+--------------------------------------+ 1306 | Winner's NLT(N,I) Expires | N/A | N/A |->NI Cancel | 1307 | | | | AT(S,G,I) | 1308 +-------------------------------+--------------------------------------+ 1309 | Receive Prune(S,G), Join(S,G) | ->NI | ->W | ->L Send | 1310 | or Graft(S,G) | | | Assert(S,G)| 1311 +-------------------------------+--------------------------------------+ 1313 Terminology: 1314 A "preferred assert" is one with a better metric than the current 1315 winner. An "inferior assert" is one with a worse metric than 1316 my_assert_metric(S,G,I). 1318 The state machine uses the following macros: 1320 CouldAssert(S,G,I) = (RPF_interface(S) != I) 1322 The first line accounts for (S,G) join information received on I that 1323 might cause the router to be interested in Asserts on I. 1324 The last line accounts for the fact that a router must keep track of 1325 Assert information on upstream interfaces in order to send Grafts and 1326 Prunes to the proper neighbor. 1328 Transitions from NoInfo State 1330 When in NoInfo state, the following events may trigger transitions: 1332 Receive Inferior (Assert OR State Refresh) AND 1333 CouldAssert(S,G,I)==TRUE 1334 An Assert or State Refresh is received for (S,G) that is inferior 1335 to our own assert metric on interface I. The Assert state machine 1336 MUST transition to the "I am Assert Winner" state, send an 1337 Assert(S,G) to interface I, store its own address and metric as 1338 the Assert Winner and set the Assert Timer (AT(S,G,I)) to 1339 (Assert_Time - Assert_Override_Interval). 1341 An (S,G) data packet arrives on downstream interface I 1342 An (S,G) data packet arrived on a downstream interface which is 1343 contained in immediate_olist(S,G). It is optimistically assumed 1344 that this router will be the Assert winner for this (S,G). The 1345 Assert state machine MUST transition to the "I am Assert Winner" 1346 state, send an Assert(S,G) to interface I, store its own address 1347 and metric as the Assert Winner and set the Assert_Timer 1348 (AT(S,G,I) to (Assert_Time - Assert_Override_Interval), thereby 1349 initiating the Assert negotiation for (S,G). 1351 Receive Preferred Assert or State Refresh 1352 The received Assert or State Refresh has a better metric than this 1353 router's and therefore the Assert state machine MUST transition to 1354 the "I am Assert Loser" state and store the Assert Winner's 1355 address and metric. If the metric was received in an Assert, the 1356 router MUST set the Assert Timer (AT(S,G,I)) to Assert_Time. If 1357 the metric was received in a State Refresh, the router MUST set 1358 the Assert Timer (AT(S,G,I)) to three times the received State 1359 Refresh Interval. The router MUST also multicast a Prune(S,G) to 1360 the Assert winner and evaluate any changes in its Upstream(S,G) 1361 state machine. 1363 Transitions from Winner State 1365 When in "I am Assert Winner" state, the following events trigger 1366 transitions: 1368 AT(S,G,I) Expires 1369 The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state machine 1370 MUST transition to the NoInfo (NI) state. 1372 Send State Refresh 1373 The router is sending a State Refresh(S,G) message on interface I. 1374 The router MUST set the Assert Timer (AT(S,G,I)) to three times 1375 the State Refresh Interval contained in the State Refresh(S,G) 1376 message. 1378 Receive Inferior Assert 1379 An (S,G) Assert is received containing a metric for S that is worse 1380 metric than this router's metric for S. Whoever sent the Assert is 1381 in error. The router MUST send an Assert(S,G) to interface I and 1382 reset the Assert Timer (AT(S,G,I)) to (Assert_Time - 1383 Assert_Override_Interval). 1385 Receive Preferred Assert or State Refresh 1386 An (S,G) Assert or State Refresh is received that has a better 1387 metric than this router's metric for S on interface I. The Assert 1388 state machine MUST transition to "I am Assert Loser" state and 1389 store the Assert Winner's address and metric. If the metric was 1390 received in an Assert, the router MUST set the Assert Timer 1391 (AT(S,G,I)) to Assert_Time. If the metric was received in a State 1392 Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three 1393 times the State Refresh Interval. The router MUST also multicast 1394 a Prune(S,G) to the Assert winner and evaluate any changes in its 1395 Upstream(S,G) state machine. 1397 CouldAssert(S,G,I) -> FALSE 1398 This router's RPF interface changed so as to make CouldAssert(S,G,I) 1399 become false. This router can no longer perform the actions of the 1400 Assert winner, and so the Assert state machine MUST transition to 1401 NoInfo (NI) state, send an AssertCancel(S,G) to interface I, and 1402 remove itself as the Assert Winner. 1404 Transitions from Loser State 1406 When in "I am Assert Loser" state, the following transitions can occur: 1408 Receive Preferred Assert or State Refresh 1409 An Assert or State Refresh is received that has a better metric 1410 than that of the current Assert winner. The Assert state machine 1411 remains in Loser (L) state and MUST store the address and metric 1412 of the new Assert Winner. If the metric was received in an Assert, 1413 the router MUST set the Assert Timer (AT(S,G,I)) to Assert_Time. 1414 If the metric was received in a State Refresh, the router MUST set 1415 the Assert Timer (AT(S,G,I)) to three times the received State 1416 Refresh Interval. If CouldAssert == TRUE, the router MUST multicast 1417 a Prune(S,G) to the new Assert winner. 1419 CouldAssert -> TRUE 1420 CouldAssert has become TRUE because interface I used to be the RPF 1421 interface for S, and now it is not. The Assert state machine MUST 1422 transition to NoInfo (NI) state, cancel AT(S,G,I) and delete 1423 information concerning the Assert Winner on I. 1425 Receive Inferior Assert or State Refresh from Current Winner 1426 An Assert or State Refresh is received from the current Assert 1427 winner that is worse than this router's metric for S (typically 1428 the winner's metric became worse). The Assert state machine MUST 1429 transition to NoInfo (NI) state and cancel AT(S,G,I). The router 1430 MUST delete the previous Assert Winner's address and metric and 1431 evaluate any possible transitions to its Upstream(S,G) state 1432 machine. Usually this router will eventually re-assert and win 1433 when data packets from S have started flowing again. 1435 AT(S,G,I) Expires 1436 The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state 1437 machine MUST transition to NoInfo (NI) state. The router MUST 1438 delete the Assert Winner's address and metric. If CouldAssert == 1439 TRUE, the router MUST evaluate any possible transitions to its 1440 Upstream(S,G) state machine. 1442 My metric becomes better than the assert winner's metric AND 1443 CouldAssert == TRUE 1444 my_assert_metric(S,G,I) has changed so that now this router's Assert 1445 metric for (S,G) is better than the metric it has stored for current 1446 Assert winner. This might happen when the underlying routing metric 1447 changes, or when CouldAssert(S,G,I) becomes true. The Assert state 1448 machine MUST transition to NoInfo (NI) state, delete the Assert 1449 Winner's address and metric, and evaluate any possible transitions 1450 to its Upstream(S,G) state machine. 1452 Current Assert Winner's NeighborLiveness Timer Expires 1453 The current Assert winner's NeighborLiveness Timer (NLT(N,I)) has 1454 expired. The Assert state machine MUST transition to the NoInfo 1455 (NI) state, delete the Assert Winner’s address and metric, and 1456 evaluate any possible transitions to its Upstream(S,G) state 1457 machine. 1459 Receive Prune(S,G), Join(S,G) or Graft(S,G) 1460 A Prune(S,G), Join(S,G) or Graft(S,G) message was received on 1461 interface I with its upstream neighbor address set to the router's 1462 address on I. The router MUST send an Assert(S,G) on the receiving 1463 interface I to initiate an Assert negotiation. The Assert state 1464 machine remains in the Assert Loser(L) state. 1466 6.6.5. Rationale for Assert Rules 1468 The following is a summary of the rules for generating and processing 1469 Assert messages. It is not intended to be definitive (the state 1470 machines and pseudocode provide the definitive behavior). Instead it 1471 provides some rationale for the behavior. 1473 1. The Assert winner for (S,G) must act as the local forwarder for (S,G) 1474 on behalf all downstream members. 1475 2. PIM messages are directed towards to the RPF' neighbor and not to the 1476 regular RPF neighbor. 1477 3. An Assert loser that receives a Prune(S,G), Join(S,G) or Graft(S,G) 1478 directed to it initiates a new Assert negotiation so the downstream 1479 router can correct its RPF'(S). 1481 4. An assert winner for (S,G) sends a canceling assert when it is about 1482 to stop forwarding on an (S,G) entry. Example: if a router is being 1483 taken down, then a canceling assert is sent. 1485 6.7. PIM Packet Formats 1487 All PIM-DM packets use the same format as PIM-SM packets. All PIM 1488 control messages have IP protocol number 103. All PIM-DM messages MUST 1489 be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack 1490 messages MUST be sent to the ALL-PIM-ROUTERS group (224.0.0.13). Graft 1491 messages SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be 1492 unicast to the sender of the Graft. 1494 6.7.1. PIM Header 1496 All PIM control messages have the following header: 1498 0 1 2 3 1499 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 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 |PIM Ver| Type | Reserved | Checksum | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 PIM Ver 1505 PIM version number is 2. 1507 Type 1508 Types for specific PIM messages. Available types are: 1509 0 = Hello 1510 1 = Register (PIM-SM only) 1511 2 = Register Stop (PIM-SM only) 1512 3 = Join/Prune 1513 4 = Bootstrap (PIM-SM only) 1514 5 = Assert 1515 6 = Graft 1516 7 = Graft Ack 1517 8 = Candidate RP Advertisement (PIM-SM only) 1518 9 = State Refresh 1520 Reserved 1521 Set to zero on transmission. Ignored upon receipt. 1523 Checksum 1524 The checksum is standard IP checksum, i.e. the 16 bit one's 1525 complement of the one's complement sum of the entire PIM message. 1526 For computing checksum, the checksum field is zeroed. 1528 6.7.2. Encoded Unicast Address 1530 An Encoded Unicast Address has the following format: 1532 0 1 2 3 1533 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 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Addr Family | Encoding Type | Unicast Address 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1538 Addr Family 1540 The PIM Address Family of the 'Unicast Address' field of this 1541 address. 1543 Values of 0-127 are as assigned by the IANA for Internet Address 1544 Families in [6]. Values 128-250 are reserved to be assigned by the 1545 IANA for PIM specific Address Families. Values 251-255 are 1546 designated for private use. As there is no assignment authority for 1547 this space, collisions should be expected. 1549 Encoding Type 1551 The type of encoding used with a specific Address Family. The value 1552 '0' is reserved for this field, and represents the native encoding of 1553 the Address Family 1555 Unicast Address 1557 The unicast address as represented by the given Address Family and 1558 Encoding Type. 1560 6.7.3. Encoded Group Address 1562 An Encoded Group address has the following format: 1564 0 1 2 3 1565 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 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | Addr Family | Encoding Type | Reserved | Mask Len | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | Group Multicast Address 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1572 Addr Family 1573 As described above. 1575 Encoding Type 1576 As described above. 1578 Reserved 1579 Transmitted as zero. Ignored upon receipt. 1581 Mask Len 1582 The mask length field is 8 bits. The value is the number of 1583 contiguous on bits left justified used as a mask, which combined 1584 with the address, describes a range of addresses. It is less than 1585 or equal to the address length in bits for the given Address 1586 Family and Encoding Type. If the message is sent for a single 1587 address then the mask length MUST equal the address length. PIM-DM 1588 routers MUST only send for a single address. 1590 Group Multicast Address 1591 The address of the multicast group. 1593 6.7.4. Encoded Source Address 1595 An Encoded Source address has the following format: 1597 0 1 2 3 1598 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 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Source Address 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1605 Addr Family 1606 As described above. 1608 Encoding Type 1609 As described above. 1611 Rsrvd 1612 Reserved. Transmitted as zero. Ignored upon receipt. 1614 S 1615 The Sparse Bit. Set to 0 for PIM-DM. Ignored upon receipt. 1617 W 1618 The Wild Card Bit. Set to 0 for PIM-DM. Ignored upon receipt. 1620 R 1621 The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon 1622 receipt. 1624 Mask Len 1625 As described above. PIM-DM routers MUST only send for a single 1626 source address. 1628 Source Address 1629 The source address. 1631 6.7.5. Hello Message Format 1633 The PIM Hello message has the following format: 1635 0 1 2 3 1636 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 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 |PIM Ver| Type | Reserved | Checksum | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Option Type | Option Length | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Option Value | 1643 | ... | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | . | 1646 | . | 1647 | . | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Option Type | Option Length | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Option Value | 1652 | ... | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 PIM Ver, Type, Reserved, Checksum 1656 Described above. 1658 Option Type 1659 The type of option given in the Option Value field. Available types 1660 are: 1661 0 Reserved 1662 1 Hello Hold Time 1663 2 LAN Prune Delay 1664 3-16 Reserved 1665 17 To be assigned by IANA 1666 18 Deprecated and SHOULD NOT be used 1667 19 DR Priority (PIM-SM Only) 1668 20 Generation ID 1669 21 State Refresh Capable 1670 22-65000 To be assigned by IANA 1671 65001-65535 Reserved for Private Use [7] 1673 Unknown options SHOULD be ignored. 1675 6.7.5.1. Hello Hold Time Option 1677 0 1 2 3 1678 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 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | Type = 1 | Length = 2 | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | Hold Time | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 Hold Time is the number of seconds a receiver MUST keep the neighbor 1686 reachable. If the Hold Time is set to '0xffff', the receiver of this 1687 message never times out the neighbor. This may be used with dial-on- 1688 demand links, to avoid keeping the link up with periodic Hello messages. 1689 Furthermore, if the Holdtime is set to '0', the information is timed out 1690 immediately. The Hello Hold Time option MUST be used by PIM-DM routers. 1692 6.7.5.2. LAN Prune Delay Option 1694 0 1 2 3 1695 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 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 | Type = 2 | Length = 4 | 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 |T| LAN Prune Delay | Override Interval | 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 The LAN_Prune_Delay option is used to tune the prune propagation delay 1703 on multi-access LANs. The T bit is used by PIM-SM and SHOULD be set to 0 1704 by PIM-DM routers and ignored upon receipt. The LAN Delay and Override 1705 Interval fields are time intervals in units of milliseconds and are used 1706 to tune the value of the J/P Override Interval and its derived timer 1707 values. Section 6.3.5 describes how these values affect the behavior of 1708 a router. The LAN Prune Delay SHOULD be used by PIM-DM routers. 1710 6.7.5.3. Generation ID Option 1712 0 1 2 3 1713 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 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | Type = 20 | Length = 4 | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | Generation ID | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 Generation ID is a random value for the interface on which the Hello 1721 message is sent. The Generation ID is regenerated whenever PIM 1722 forwarding is started or restarted on the interface. The Generation ID 1723 option MAY be used by PIM-DM routers. 1725 6.7.5.4. State Refresh Capable Option 1727 0 1 2 3 1728 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 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Type = 21 | Length = 4 | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | Version = 1 | Interval | Reserved | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 The Interval field is the router's configured State Refresh Interval in 1736 seconds. The Reserved field is set to zero and ignored upon reception. 1737 The State Refresh Capable option MUST be used by State Refresh capable 1738 PIM-DM routers. 1740 6.7.6. Join/Prune Message Format 1742 PIM Join/Prune messages have 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 | Upstream Neighbor Address (Encoded Unicast Format) | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Reserved | Num Groups | Hold Time | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Multicast Group Address 1 (Encoded Group Format) | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 | Number of Joined Sources | Number of Pruned Sources | 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 | Joined Source Address 1 (Encoded Source Format) | 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | . | 1760 | . | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | Joined Source Address n (Encoded Source Format) | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | Pruned Source Address 1 (Encoded Source Format) | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 | . | 1767 | . | 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | Pruned Source Address n (Encoded Source Format) | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | . | 1772 | . | 1773 | . | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | Multicast Group Address m (Encoded Group Format) | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | Number of Joined Sources | Number of Pruned Sources | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | Joined Source Address 1 (Encoded Source Format) | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | . | 1782 | . | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Joined Source Address n (Encoded Source Format) | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Pruned Source Address 1 (Encoded Source Format) | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | . | 1789 | . | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Pruned Source Address n (Encoded Source Format) | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 PIM Ver, Type, Reserved, Checksum 1795 Described above. 1797 Upstream Neighbor Address 1798 The address of the upstream neighbor. The format for this address is 1799 given in the Encoded Unicast address in section 6.7.2. PIM-DM routers 1800 MUST set this field to the RPF next hop. 1802 Reserved 1803 Transmitted as zero. Ignored upon receipt. 1805 Hold Time 1806 The number of seconds a receiving PIM-DM router MUST keep a Prune state 1807 alive, unless removed by a Join or Graft message. If the Hold Time is 1808 '0xffff', the receiver MUST NOT remove the Prune state unless a 1809 corresponding Join or Graft message is received. The Hold Time is 1810 ignored in Join messages. 1812 Number of Groups 1813 Number of multicast group sets contained in the message. 1815 Multicast Group Address 1816 The multicast group address in the Encoded Multicast address format 1817 given in section 6.7.3. 1819 Number of Joined Sources 1820 Number of Join source addresses listed for a given group. 1822 Number of Pruned Sources 1823 Number of Prune source addresses listed for a given group. 1825 Join Source Address 1..n 1826 This list contains the sources from which the sending router wishes to 1827 continue to receive multicast messages for the given group on this 1828 interface. The addresses use the Encoded Source address format given in 1829 section 6.7.4. 1831 Prune Source Address 1..n 1832 This list contains the sources from which the sending router does not 1833 wish to receive multicast messages for the given group on this 1834 interface. The addresses use the Encoded Source address format given in 1835 section 6.7.4. 1837 6.7.7. Assert Message Format 1839 PIM Assert Messages have the following format: 1841 0 1 2 3 1842 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 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 |PIM Ver| Type | Reserved | Checksum | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | Multicast Group Address (Encoded Group Format) | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | Source Address (Encoded Unicast Format) | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 |R| Metric Preference | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | Metric | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 PIM Ver, Type, Reserved, Checksum 1856 Described above. 1858 Multicast Group Address 1859 The multicast group address in the Encoded Multicast address format 1860 given in section 6.7.3. 1862 Source Address 1863 The source address in the Encoded Source address format given in section 1864 6.7.4. 1866 R 1867 The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon 1868 receipt. 1870 Metric Preference 1871 The preference value assigned to the unicast routing protocol that 1872 provided the route to the source. 1874 Metric 1875 The cost metric of the unicast route to the source. The metric is in 1876 units applicable to the unicast routing protocol used. 1878 6.7.8. Graft Message Format 1880 PIM Graft messages use the same format as Join/Prune messages except the 1881 Type field is set to 6. The source address MUST be in the Join section 1882 of the message. The Hold Time field SHOULD be zero and SHOULD be 1883 ignored when a Graft is received. 1885 6.7.9. Graft Ack Message Format 1887 PIM Graft Ack messages are identical in format to the received Graft 1888 message except the Type field is set to 7. The Upstream Neighbor 1889 Address field SHOULD be set to the sender of the Graft message and 1890 SHOULD be ignored upon receipt. 1892 6.7.10. State Refresh Message Format 1894 PIM State Refresh Messages have the following format: 1896 0 1 2 3 1897 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 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 |PIM Ver| Type | Reserved | Checksum | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | Multicast Group Address (Encoded Group Format) | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | Source Address (Encoded Unicast Format) | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Originator Address (Encoded Unicast Format) | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 |R| Metric Preference | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 | Metric | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 | Masklen | TTL |P|N|O|Reserved | Interval | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 PIM Ver, Type, Reserved, Checksum 1915 Described above. 1917 Multicast Group Address 1918 The multicast group address in the Encoded Multicast address format 1919 given in section 6.7.3. 1921 Source Address 1922 The address of the data source in the Encoded Source address format 1923 given in section 6.7.4. 1925 Originator Address 1926 The address of the first hop router in the Encoded Source address format 1927 given in section 6.7.4. 1929 R 1930 The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon 1931 receipt. 1933 Metric Preference 1934 The preference value assigned to the unicast routing protocol that 1935 provided the route to the source. 1937 Metric 1938 The cost metric of the unicast route to the source. The metric is in 1939 units applicable to the unicast routing protocol used. 1941 Masklen 1942 The length of the address mask of the unicast route to the source. 1944 TTL 1945 Time To Live of the State Refresh message. Decremented each time the 1946 message is forwarded. Note that this is different from the IP Header 1947 TTL, which is always set to 1. 1949 P 1950 Prune indicator flag. This MUST be set to 1 if the State Refresh is to 1951 be sent on a Pruned interface. Otherwise, it MUST be set to 0. 1953 N 1954 Prune Now flag. This SHOULD be set to 1 by the State Refresh originator 1955 on every third State Refresh message and SHOULD be ignored upon receipt. 1956 This is for compatibility with earlier versions of state refresh. 1958 O 1959 Assert Override flag. This SHOULD be set to 1 by upstream routers on a 1960 LAN if a State Refresh has not been heard from the assert winner over 1961 the period of three times RefreshInterval(S,G) and SHOULD be ignored 1962 upon receipt. This is for compatibility with earlier versions of state 1963 refresh. 1965 Reserved 1966 Set to zero and ignored upon receipt. 1968 Interval 1969 Set by the originating router to the interval (in seconds) between 1970 consecutive State Refresh messages for this (S,G) pair. 1972 6.8. PIM-DM Timers 1974 PIM-DM maintains the following timers. All timers are countdown timers 1975 - they are set to a value and count down to zero, at which point they 1976 typically trigger an action. Of course they can just as easily be 1977 implemented as count-up timers, where the absolute expiry time is store 1978 and compared against a real-time clock, but the language in this 1979 specification assumes that they count downwards towards zero. 1981 Global Timers 1982 Hello Timer: HT 1984 Per interface (I): 1985 Propagation Delay: PD(I) 1986 Override Interval: OI(I) 1988 Per neighbor (N): 1989 Neighbor Liveness Timer: NLT(N,I) 1991 Per (S,G) Pair: 1992 (S,G) Assert Timer: AT(S,G,I) 1993 (S,G) Prune Timer: PT(S,G,I) 1994 (S,G) PrunePending Timer: PPT(S,G,I) 1996 Per (S,G) Pair: 1997 (S,G) Graft Retry Timer: GT(S,G) 1998 (S,G) Upstream Override Timer: OT(S,G) 1999 (S,G) Prune Limit Timer: PLT(S,G) 2000 (S,G) Source Active Timer: SAT(S,G) 2001 (S,G) State Refresh Timer: SRT(S,G) 2003 6.8.1. Timer Values 2005 When timer values are started or restarted, they are set to default 2006 values. This section summarizes those default values. 2008 Timer Name: Hello Timer (HT) 2010 +----------------------+--------+--------------------------------------+ 2011 | Value Name | Value | Explanation | 2012 +----------------------+--------+--------------------------------------+ 2013 |Hello_Period | 30 sec | Periodic interval for hello messages | 2014 +----------------------+--------+--------------------------------------+ 2015 |Triggered_Hello_Delay | 5 sec | Random interval for initial Hello | 2016 | | | message on bootup or triggered Hello | 2017 | | | message to a rebooting neighbor | 2018 +----------------------+--------+--------------------------------------+ 2020 Hello message are sent on every active interface once every Hello_Period 2021 seconds. At system power-up, the timer is initialized to 2022 rand(0,Triggered_Hello_Delay) to prevent synchronization. When a new or 2023 rebooting neighbor is detected, a responding Hello is sent within 2024 rand(0,Triggered_Hello_Delay). Hello_Period corresponds to the PIM MIB 2025 object pimInterfaceHelloInterval. 2027 Timer Name: Propagation Delay (PD(I)) 2029 +-------------------------+----------------+---------------------------+ 2030 | Value Name | Value | Explanation | 2031 +-------------------------+----------------+---------------------------+ 2032 | LAN_delay_default | 0.5 sec | Expected propagation | 2033 | | | over the local link. | 2034 +-------------------------+----------------+---------------------------+ 2036 If all routers on a LAN are using the LAN Prune Delay option, PD(I) will 2037 be set to the largest LAN Delay on the LAN. Otherwise, PD(I) will be 2038 set to LAN_delay_default. 2040 Timer Name: Override Interval (OI(I)) 2042 +--------------------------+-----------------+-------------------------+ 2043 | Value Name | Value | Explanation | 2044 +--------------------------+-----------------+-------------------------+ 2045 | t_override_default | 2.5 sec | Default delay interval | 2046 | | | over which to randomize | 2047 | | | when scheduling a Join/ | 2048 | | | Prune Override message. | 2049 +--------------------------+-----------------+-------------------------+ 2051 If all routers on a LAN are using the LAN Prune Delay option, OI(I) will 2052 be set to the largest Override Interval on the LAN. Otherwise, OI(I) 2053 will be set to t_override_default. 2055 Timer Name: Neighbor Liveness Timer (NLT(N,I)) 2057 +-------------------+-----------------+--------------------------------+ 2058 | Value Name | Value | Explanation | 2059 +-------------------+-----------------+--------------------------------+ 2060 | Hello Holdtime | From message | Hold Time from Hello Message | 2061 +-------------------+-----------------+--------------------------------+ 2063 Timer Name: PrunePending Timer (PPT(S,G,I)) 2065 +-----------------------+---------------+------------------------------+ 2066 | Value Name | Value | Explanation | 2067 +-----------------------+---------------+------------------------------+ 2068 | J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to | 2069 | | | allow other routers to on | 2070 | | | the LAN to send a Join | 2071 +-----------------------+---------------+------------------------------+ 2073 Timer Name: Prune Timer (PT(S,G,I)) 2075 +----------------+----------------+------------------------------------+ 2076 | Value Name | Value | Explanation | 2077 +----------------+----------------+------------------------------------+ 2078 | Prune Holdtime | From message | Hold Time read from Prune Message | 2079 +----------------+----------------+------------------------------------+ 2081 Prune Holdtime corresponds to PIM MIB object 2082 pimInterfaceJoinPruneInterval 2084 Timer Name: Assert Timer (AT(S,G,I)) 2086 +--------------------------+---------+---------------------------------+ 2087 | Value Name | Value | Explanation | 2088 +--------------------------+---------+---------------------------------+ 2089 | Assert Override Interval | 3 sec | Short interval before an assert | 2090 | | | times out where the assert | 2091 | | | winner resends an assert | 2092 | | | message | 2093 +--------------------------+---------+---------------------------------+ 2094 | Assert Time | 180 sec | Period after last assert before | 2095 | | | assert state is timed out | 2096 +--------------------------+---------+---------------------------------+ 2098 Note that for historical reasons, the Assert message lacks a Holdtime 2099 field. Thus changing the Assert Time from the default value is not 2100 recommended. If all members of a LAN are state refresh enabled, the 2101 Assert Time will be three times RefreshInterval(S,G) and Assert Override 2102 Interval will not be needed. 2104 Timer Name: Graft Retry Timer (GRT(S,G)) 2106 +--------------------+-------+-----------------------------------------+ 2107 | Value Name | Value | Explanation | 2108 +--------------------+-------+-----------------------------------------+ 2109 | Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck | 2110 | | | message, the time before retransmission | 2111 | | | of a Graft message | 2112 +-----------------------+---------------+------------------------------+ 2114 Timer Name: Upstream Override Timer (OT(S,G)) 2116 +-----------+----------------+-----------------------------------------+ 2117 |Value Name | Value | Explanation | 2118 +-----------+----------------+-----------------------------------------| 2119 |t_override | rand(0, OI(I)) | Randomized delay to prevent response | 2120 | | | implosion when sending a join message | 2121 | | | to override someone else's prune | 2122 +-----------+----------------+-----------------------------------------| 2124 Timer Name: Prune Limit Timer (PLT(S,G)) 2126 +-----------+--------------------+-------------------------------------+ 2127 |Value Name | Value | Explanation | 2128 +-----------+--------------------+-------------------------------------| 2129 |t_limit | Equal to the Prune | Used to prevent Prune storms on a | 2130 | | Holdtime sent | LAN | 2131 +-----------+--------------------+-------------------------------------| 2133 Timer Name: Source Activity Timer (SAT(S,G)) 2135 +----------------+-------------------+---------------------------------+ 2136 | Value Name | Value | Explanation | 2137 +----------------+-------------------+---------------------------------+ 2138 | SourceLifetime | Default: 210 secs | Period of time after receiving | 2139 | | | a multicast message a directly | 2140 | | | attached router will continue | 2141 | | | to send State Refresh messages | 2142 +----------------+-------------------+---------------------------------+ 2144 Timer Name: State Refresh Timer (SRT(S,G)) 2146 +-----------------+------------------+---------------------------------+ 2147 | Value Name | Value | Explanation | 2148 +-----------------+------------------+---------------------------------+ 2149 | RefreshInterval | Default: 60 secs | Interval between successive | 2150 | | | state refresh messages | 2151 +-----------------+------------------+---------------------------------+ 2153 7. Protocol Interaction Considerations 2155 PIM-DM is designed to be independent of underlying unicast routing 2156 protocols and will interact only to the extent needed to perform RPF 2157 checks. It is generally assumed that multicast area and autonomous 2158 system boundaries will correspond to the same boundaries for unicast 2159 routing, though a deployment which does not follow this assumption is 2160 not precluded by this specification. 2162 In general, PIM-DM interactions with other multicast routing protocols 2163 should be in compliance with RFC 2715 [13]. Other specific interactions 2164 are noted below. 2166 7.1. PIM-SM Interactions 2168 PIM-DM is not intended to interact directly with PIM-SM, even though 2169 they share a common packet format. It is particularly important to note 2170 that a router cannot differentiate between a PIM-DM neighbor and a 2171 PIM-SM neighbor based on Hello messages. 2173 In the event that a PIM-DM router becomes a neighbor of a PIM-SM router 2174 they will effectively form a simplex link with the PIM-DM router sending 2175 all multicast messages to the PIM-SM router while the PIM-SM router 2176 sends no multicast messages to the PIM-DM router. 2178 The common packet format permits a hybrid PIM-SM/DM implementation that 2179 would use PIM-SM when a rendezvous point is known and PIM-DM when one is 2180 not. Such an implementation is outside the scope of this document. 2182 7.2. IGMP Interactions 2184 PIM-DM will forward received multicast data packets to neighboring host 2185 group members in all cases except when the PIM-DM router is in an Assert 2186 Loser state on that interface. Note that a PIM Prune message is not 2187 permitted to prevent the delivery of messages to a network with group 2188 members. 2190 A PIM-DM Router MAY use the DR Priority option described in [3] to elect 2191 an IGMP v1 querier. 2193 7.3. Source Specific Multicast (SSM) Interactions 2195 PIM-DM makes no special considerations for SSM [11]. All Prunes and 2196 Grafts within the protocol are for a specific source, so no additional 2197 checks need be made. 2199 7.4. Multicast Group Scope Boundary Interactions 2201 While multicast group scope boundaries are generally identical to 2202 routing area boundaries, it is conceivable that a routing area might be 2203 partitioned for a particular multicast group. PIM-DM routers MUST NOT 2204 send any messages concerning a particular group across that group's 2205 scope boundary. 2207 8. IANA Considerations 2209 8.1. PIM Address Family 2211 The PIM Address Family field was chosen to be 8 bits as a tradeoff 2212 between packet format and use of the IANA assigned numbers. When the 2213 PIM packet format was designed, only 15 values were assigned for Address 2214 Families and large numbers of new Address Families were not envisioned, 2215 8 bits seemed large enough. However, the IANA assigns Address Families 2216 in a 16 bit value. Therefore, the PIM Address Family is allocated as 2217 follows: 2219 Values 0 through 127 are designated to have the same meaning as IANA 2220 assigned Address Family Numbers [6]. 2222 Values 128 through 250 are designated to be assigned by the IANA based 2223 upon IESG approval as defined in [7]. 2225 Values 251 through 255 are designated for Private Use, as defined in 2226 [7]. 2228 8.2. PIM Hello Options 2230 Values 17 through 65000 are to be assigned by the IANA. Since the space 2231 is large, they may be assigned as First Come First Served as defined in 2232 [7]. Such assignments are valid for one year, and may be renewed. 2233 Permanent assignments require a specification as defined in [7]. 2235 9. Security Considerations 2237 All PIM control messages MAY use IPsec [8] to address security concerns. 2238 The authentication methods are addressed in a companion document [9]. 2239 Keys may be distributed as described in [10]. In any case, PIM router 2240 SHOULD NOT accept and process PIM messages from neighbors unless a valid 2241 Hello message has been received from that neighbor. 2243 We should note that PIM-DM has no rendezvous point, and therefore no 2244 single point of failure that may be vulnerable. However, since PIM-DM 2245 assumes that multicast messages are desired throughout the network, it 2246 may be particularly vulnerable to denial of service attacks. 2247 It is further worth noting that because PIM-DM uses unicast routes 2248 provided by an unknown routing protocol, it may suffer collateral 2249 effects if the unicast routing protocol is attacked. 2251 10. Authors' Addresses 2253 Andrew Adams 2254 NextHop Technologies 2255 825 Victors Way, Suite 100 2256 Ann Arbor, MI 48108-2738 2257 ala@nexthop.com 2259 Jonathan Nicholas 2260 ITT Aerospace/Communications Division 2261 100 Kingsland Rd 2262 Clifton, NJ 07014 2263 jonathan.nicholas@itt.com 2265 William Siadak 2266 NextHop Technologies 2267 825 Victors Way, Suite 100 2268 Ann Arbor, MI 48108-2738 2269 wfs@nexthop.com 2271 11. Acknowledgments 2273 The major features of PIM-DM were originally designed by Stephen 2274 Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy, 2275 David Meyer, and Liming Wei. Additional features for state refresh were 2276 designed by Dino Farinacci, Isidor Kouvelas and Kurt Windisch. This 2277 revision was undertaken to incorporate some of the lessons learned 2278 during the evolution of the PIM-SM specification and early deployments 2279 of PIM-DM. Thanks the PIM Working Group for their comments. 2281 12. References 2283 [1] S.E. Deering, "Multicast Routing in a Datagram Internetwork", 2284 Ph.D. Thesis, Electrical Engineering Dept., Stanford University, 2285 December 1991. 2286 [2] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast 2287 Routing Protocol", November 1988, RFC 1075 2288 [3] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol 2289 Independent Multicast - Sparse Mode (PIM-SM)", draft-ietf-pim-sm- 2290 v2-new-03.txt, work in progress. 2291 [4] S.E. Deering, "Host Extensions for IP Multicasting", August 1989, 2292 RFC 1112. 2293 [5] W.Fenner, "Internet Group Management Protocol, Version 2", 2294 November 1997, RFC 2236. 2295 [6] IANA, "Address Family Numbers", linked from 2296 http://www.iana.org/numbers.html. 2297 [7] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 2298 Considerations Section in RFCs", RFC 2434. 2299 [8] S. Kent, R. Atkinson, "Security Architecture for the Internet 2300 Protocol", RFC 2401. 2301 [9] L. Wei, "Authenticating PIM Version 2 Messages", draft-ietf-pim- 2302 v2-auth-01.txt, work in progress. 2303 [10] T. Hardjono, B. Cain, "Simple Key Management Protocol for PIM", 2304 draft-ietf-pim-simplekmp-01.txt, work in progress. 2305 [11] H.Holbrook, B. Cain, "Source Specific Multicast for IP", draft- 2306 holbrook-ssm-00.txt, work in progress. 2307 [12] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, 2308 "Internet Group Management Protocol, Version 3", draft-ietf-idmr- 2309 igmp-v3-07.txt, work in progress. 2310 [13] D. Thaler, "Interoperability Rules for Multicast Routing 2311 Protocols", October 1999, RFC 2715. 2312 [14] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol 2313 Independent Multicast MIB for IPv4", October 2000, RFC 2934