idnits 2.17.00 (12 Aug 2021) /tmp/idnits21463/draft-ietf-pim-dm-new-v2-03.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 28) being 61 lines 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 4 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 266: '...h an (S,G) entry MUST be maintained as...' RFC 2119 keyword, line 424: '...st, an RPF check MUST be performed to ...' RFC 2119 keyword, line 426: '...ts that fail the RPF check MUST NOT be...' RFC 2119 keyword, line 429: '...cannot be found MUST be discarded....' RFC 2119 keyword, line 460: '...s, the Hello Timer (HT) MUST be set to...' (161 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2003) is 6853 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 2513, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2516, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2531, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 2538, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '2') == Outdated reference: draft-ietf-pim-sm-v2-new has been published as RFC 4601 -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2434 (ref. '7') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301) == Outdated reference: draft-ietf-ssm-arch has been published as RFC 4607 ** Downref: Normative reference to an Informational RFC: RFC 2715 (ref. '11') ** Downref: Normative reference to an Experimental RFC: RFC 2934 (ref. '12') ** Obsolete normative reference: RFC 2460 (ref. '13') (Obsoleted by RFC 8200) == Outdated reference: draft-ietf-pim-bidir has been published as RFC 5015 == Outdated reference: draft-ietf-msec-gdoi has been published as RFC 3547 Summary: 15 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force PIM WG 2 INTERNET DRAFT Andrew Adams (NextHop Technolgies) 3 draft-ietf-pim-dm-new-v2-03.txt Jonathan Nicholas (ITT A/CD) 4 William Siadak (NextHop Technologies) 5 February 2003 6 Expires August 2003 8 Protocol Independent Multicast - Dense Mode (PIM-DM): 9 Protocol Specification (Revised) 11 Status of this Document 13 This document is an Internet Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026. 16 Internet Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt. 28 The list of Internet Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is a product of the IETF PIM WG. Comments should be 32 addressed to the authors, or the WG's mailing list at 33 pim@catarina.usc.edu. 35 Abstract 37 This document specifies Protocol Independent Multicast - Dense Mode 38 (PIM-DM). PIM-DM is a multicast routing protocol that uses the 39 underlying unicast routing information base to flood multicast datagrams 40 to all multicast routers. Prune messages are used to prevent future 41 messages from propagating to routers with no group membership 42 information. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 48 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . . . . 5 50 3. PIM-DM Protocol Overview . . . . . . . . . . . . . . . . . . 5 51 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6 52 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . 6 53 4.1.1. General Purpose State . . . . . . . . . . . . . . . . . . . 7 54 4.1.2. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . . 7 55 4.1.3. State Summarization Macros . . . . . . . . . . . . . . . . . 8 56 4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . 10 57 4.3. Hello Messages . . . . . . . . . . . . . . . . . . . . . . . 10 58 4.3.1. Sending Hello Messages . . . . . . . . . . . . . . . . . . . 10 59 4.3.2. Receiving Hello Messages . . . . . . . . . . . . . . . . . . 11 60 4.3.3. Hello Message Hold Time . . . . . . . . . . . . . . . . . . 11 61 4.3.4. Handling Router Failures . . . . . . . . . . . . . . . . . . 11 62 4.3.5. Reducing Prune Propagation Delay on LANs . . . . . . . . . . 12 63 4.4. PIM-DM Prune, Join and Graft Messages . . . . . . . . . . . 13 64 4.4.1. Upstream Prune, Join and Graft Messages . . . . . . . . . . 13 65 4.4.1.1. Transitions from the Forwarding (F) State . . . . . . . . . 16 66 4.4.1.2. Transitions from the Pruned (P) State . . . . . . . . . . . 17 67 4.4.1.3. Transitions from the AckPending (AP) State . . . . . . . . . 18 68 4.4.2. Downstream Prune, Join and Graft Messages . . . . . . . . . 19 69 4.4.2.1. Transitions from the NoInfo State . . . . . . . . . . . . . 21 70 4.4.2.2. Transitions from the PrunePending (PP) State . . . . . . . . 22 71 4.4.2.3. Transitions from the Prune (P) State . . . . . . . . . . . . 23 72 4.5. State Refresh . . . . . . . . . . . . . . . . . . . . . . . 24 73 4.5.1. Forwarding of State Refresh Messages . . . . . . . . . . . . 24 74 4.5.2. State Refresh Message Origination . . . . . . . . . . . . . 25 75 4.5.2.1. Transitions from the NotOriginator (NO) State . . . . . . . 27 76 4.5.2.2. Transitions from the Originator (O) State . . . . . . . . . 27 77 4.6. PIM Assert Messages . . . . . . . . . . . . . . . . . . . . 28 78 4.6.1. Assert Metrics . . . . . . . . . . . . . . . . . . . . . . . 28 79 4.6.2. AssertCancel Messages . . . . . . . . . . . . . . . . . . . 29 80 4.6.3. Assert State Macros . . . . . . . . . . . . . . . . . . . . 29 81 4.6.4. (S,G) Assert Message State Machine . . . . . . . . . . . . . 29 82 4.6.4.1. Transitions from NoInfo State . . . . . . . . . . . . . . . 31 83 4.6.4.2. Transitions from Winner State . . . . . . . . . . . . . . . 32 84 4.6.4.3. Transitions from Loser State . . . . . . . . . . . . . . . . 33 85 4.6.5. Rationale for Assert Rules . . . . . . . . . . . . . . . . . 34 86 4.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . 35 87 4.7.1. PIM Header . . . . . . . . . . . . . . . . . . . . . . . . . 35 88 4.7.2. Encoded Unicast Address . . . . . . . . . . . . . . . . . . 36 89 4.7.3. Encoded Group Address . . . . . . . . . . . . . . . . . . . 36 90 4.7.4. Encoded Source Address . . . . . . . . . . . . . . . . . . . 37 91 4.7.5. Hello Message Format . . . . . . . . . . . . . . . . . . . . 38 92 4.7.5.1. Hello Hold Time Option . . . . . . . . . . . . . . . . . . . 39 93 4.7.5.2. LAN Prune Delay Option . . . . . . . . . . . . . . . . . . . 39 94 4.7.5.3. Generation ID Option . . . . . . . . . . . . . . . . . . . . 40 95 4.7.5.4. State Refresh Capable Option . . . . . . . . . . . . . . . . 40 96 4.7.6. Join/Prune Message Format . . . . . . . . . . . . . . . . . 40 97 4.7.7. Assert Message Format . . . . . . . . . . . . . . . . . . . 42 98 4.7.8. Graft Message Format . . . . . . . . . . . . . . . . . . . . 43 99 4.7.9. Graft Ack Message Format . . . . . . . . . . . . . . . . . . 43 100 4.7.10. State Refresh Message Format . . . . . . . . . . . . . . . . 44 101 4.8. PIM-DM Timers . . . . . . . . . . . . . . . . . . . . . . . 45 102 5. Protocol Interaction Considerations . . . . . . . . . . . . 48 103 5.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . . . 48 104 5.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . . . 49 105 5.3. Source Specific Multicast (SSM) Interactions . . . . . . . . 49 106 5.4. Multicast Group Scope Boundary Interactions . . . . . . . . 49 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 108 6.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . 49 109 6.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . 50 110 7. Security Considerations. . . . . . . . . . . . . . . . . . . 50 111 7.1. Attacks Based on Forged Messages . . . . . . . . . . . . . . 50 112 7.2. Non-cryptographic Authentication Mechanisms . . . . . . . . 51 113 7.3. Authentication Using IPsec . . . . . . . . . . . . . . . . . 51 114 7.4. Denial of Service Attacks . . . . . . . . . . . . . . . . . 52 115 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 116 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 53 117 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 118 1. Introduction 120 This specification defines a multicast routing algorithm for multicast 121 groups that are densely distributed across a network. This protocol 122 does not have a topology discovery mechanism often used by a unicast 123 routing protocol. It employs the same packet formats sparse mode PIM 124 (PIM-SM) uses. This protocol is called PIM - Dense Mode. The 125 foundation of this design was largely built on Deering's early work on 126 IP multicast routing [1]. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be 132 interpreted as described in RFC 2119 and indicate requirement levels for 133 compliant PIM-DM implementations. 135 2.1. Definitions 137 Multicast Routing Information Base (MRIB) 138 This is the multicast topology table, which is typically derived from 139 the unicast routing table, or routing protocols such as MBGP that 140 carry multicast-specific topology information. PIM-DM uses the MRIB 141 to make decisions regarding RPF interfaces. 143 Tree Information Base (TIB) 144 This is the collection of state maintained by a PIM router and created 145 by receiving PIM messages and IGMP information from local hosts. It 146 essentially stores the state of all multicast distribution trees at 147 that router. 149 Reverse Path Forwarding (RPF) 150 RPF is a multicast forwarding mode where a data packet is accepted for 151 forwarding only if it is received on an interface used to reach the 152 source in unicast. 154 Upstream Interface 155 Interface towards the source of the datagram. Also known as the RPF 156 Interface. 158 Downstream Interface 159 All interfaces that are not the upstream interface, including the 160 router itself. 162 (S,G) Pair 163 Source S and destination group G associated with an IP packet. 165 2.2. Pseudocode Notation 167 We use set notation in several places in this specification. 169 A (+) B 170 is the union of two sets A and B. 172 A (-) B 173 are the elements of set A that are not in set B. 175 NULL 176 is the empty set or list. 178 Note that (+) and (-) operators are NOT commutative, and must be 179 conducted in the order specified. 181 In addition we use C-like syntax: 182 = denotes assignment of a variable. 183 == denotes a comparison for equality. 184 != denotes a comparison for inequality. 186 Braces { and } are used for grouping. 188 3. PIM-DM Protocol Overview 190 This section provides an overview of PIM-DM behavior. It is intended as 191 an introduction to how PIM-DM works, and is NOT definitive. For the 192 definitive specification, see Section 4 - Protocol Specification. 194 PIM-DM assumes that when a source starts sending, all downstream systems 195 want to receive multicast datagrams. Initially, multicast datagrams are 196 flooded to all areas of the network. PIM-DM uses RPF to prevent looping 197 of multicast datagrams while flooding. If some areas of the network do 198 not have group members, PIM-DM will prune off the forwarding branch by 199 instantiating prune state. 201 Prune state has a finite lifetime. When that lifetime expires, data 202 will again be forwarded down the previously pruned branch. 204 Prune state is associated with an (S,G) pair. When a new member for a 205 group G appears in a pruned area, a router can "graft" toward the source 206 S for the group, thereby turning the pruned branch back into a 207 forwarding branch. 209 The broadcast of datagrams followed by pruning of unwanted branches is 210 often referred to as a flood and prune cycle and is typical of dense 211 mode protocols. 213 In order to minimize repeated flooding of datagrams and subsequent 214 pruning associated with a particular (S,G) pair, PIM-DM uses a state 215 refresh message. This message is sent by the router(s) directly 216 connected to the source and is propagated throughout the network. When 217 received by a router on its RPF interface, the state refresh message 218 causes an existing prune state to be refreshed. 220 Compared with multicast routing protocols with built in topology 221 discovery mechanisms (e.g. DVMRP [2]) PIM-DM has a simplified design and 222 is not hard-wired into a specific topology discovery protocol. However, 223 such a simplification does incur more overhead by causing flooding and 224 pruning to occur on some links that could be avoided if sufficient 225 topology information were available, i.e. to decide whether an interface 226 leads to any downstream members of a particular group. Additional 227 overhead is chosen in favor of the simplification and flexibility gained 228 by not depending on a specific topology discovery protocol. 230 PIM-DM differs from PIM-SM in two essential ways: 1) There are no 231 periodic joins transmitted, only explicitly triggered prunes and grafts. 232 2) There is no Rendezvous Point (RP). This is particularly important in 233 networks that cannot tolerate a single point of failure. (An RP is the 234 root of a shared multicast distribution tree. For more details see [3]). 236 4. Protocol Specification 238 The specification of PIM-DM is broken into several parts: 240 * Section 4.1 details the protocol state stored. 241 * Section 4.2 specifies the data packet forwarding rules. 242 * Section 4.3 specifies generation and processing of Hello messages. 243 * Section 4.4 specifies the Join, Prune and Graft generation and 244 processing rules. 245 * Section 4.5 specifies the State Refresh generation and forwarding 246 rules. 247 * Section 4.6 specifies the Assert generation and processing rules. 248 * Section 4.7 gives details on PIM-DM Packet Formats. 249 * Section 4.8 summarizes PIM-DM timers and their defaults. 251 4.1. PIM Protocol State 253 This section specifies all the protocol states that a PIM-DM 254 implementation should maintain in order to function correctly. We term 255 this state the Tree Information Base or TIB, as it holds the state of 256 all the multicast distribution trees at this router. In this 257 specification, we define PIM-DM mechanisms in terms of the TIB. 258 However, only a very simple implementation would actually implement 259 packet forwarding operations in terms of this state. Most 260 implementations will use this state to build a multicast forwarding 261 table, which would then be updated when the relevant state in the TIB 262 changes. 264 Unlike PIM-SM, PIM-DM does not maintain a keepalive timer associated 265 with each (S,G) route. Within PIM-DM, route and state information 266 associated with an (S,G) entry MUST be maintained as long as any timer 267 associated with that (S,G) entry is active. When no timer associated 268 with an (S,G) entry is active, all information concerning that (S,G) 269 route may be discarded. 271 Although we specify precisely the state to be kept, this does not mean 272 that an implementation of PIM-DM needs to hold the state in this form. 273 This is actually an abstract state definition, which is needed in order 274 to specify the router's behavior. A PIM-DM implementation is free to 275 hold whatever internal state it requires, and will still be conformant 276 with this specification so long as it results in the same externally 277 visible protocol behavior as an abstract router that holds the following 278 state. 280 4.1.1. General Purpose State 282 A router stores the following non-group-specific state: 284 For each interface: 285 Hello Timer (HT) 286 State Refresh Capable 287 LAN Delay Enabled 288 Propagation Delay (PD) 289 Override Interval (OI) 291 Neighbor State: 292 For each neighbor: 293 Information from neighbor's Hello 294 Neighbor's Gen ID. 295 Neighbor's LAN Prune Delay 296 Neighbor's Override Interval 297 Neighbor's State Refresh Capability 298 Neighbor Liveness Timer (NLT) 300 4.1.2. (S,G) State 302 For every source/group pair (S,G), a router stores the following state: 304 (S,G) state: 305 For each interface: 306 Local Membership: 307 State: One of {"NoInfo", "Include"} 309 PIM (S,G) Prune State: 310 State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending" (PP)} 311 Prune Pending Timer (PPT) 312 Prune Timer (PT) 314 (S,G) Assert Winner State: 315 State: One of {"NoInfo" (NI), "I lost Assert" (L), 316 "I won Assert" (W)} 317 Assert Timer (AT) 318 Assert winner's IP Address 319 Assert winner's Assert Metric 321 Upstream interface-specific: 322 Graft/Prune State: 323 State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F), 324 "AckPending" (AP) } 325 GraftRetry Timer (GRT) 326 Override Timer (OT) 327 Prune Limit Timer (PLT) 329 Originator State: 330 Source Active Timer (SAT) 331 State Refresh Timer (SRT) 333 4.1.3. State Summarization Macros 335 Using the state defined above, the following "macros" are defined and 336 will be used in the descriptions of the state machines and pseudocode in 337 the following sections. 339 The most important macros are those defining the outgoing interface list 340 (or "olist") for the relevant state. 342 immediate_olist(S,G) = pim_nbrs (-) prunes(S,G) (+) 343 ( pim_include(*,G) (-) pim_exclude(S,G) ) (+) 344 pim_include(S,G) (-) lost_assert(S,G) (-) 345 boundary(G) 347 olist(S,G) = immediate_olist(S,G) (-) RPF_interface(S) 349 The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces 350 to which traffic might be forwarded or not forwarded because of hosts 351 that are local members on those interfaces. 353 pim_include(*,G) = {all interfaces I such that: 354 local_receiver_include(*,G,I)} 355 pim_include(S,G) = {all interfaces I such that: 356 local_receiver_include(S,G,I)} 357 pim_exclude(S,G) = {all interfaces I such that: 358 local_receiver_exclude(S,G,I)} 360 The macro RPF_interface(S) returns the RPF interface for source S. That 361 is to say, it returns the interface used to reach S as indicated by the 362 MRIB. 364 The macro local_receiver_include(S,G,I) is true if the IGMP module or 365 other local membership mechanism has determined that there are local 366 members on interface I that desire to receive traffic sent specifically 367 by S to G. 369 The macro local_receiver_include(*,G,I) is true if the IGMP module or 370 other local membership mechanism has determined that there are local 371 members on interface I that desire to receive all traffic sent to G. 372 Note that this determination is expected to account for membership joins 373 initiated on or by the router. 375 The macro local_receiver_exclude(S,G,I) is true if 376 local_receiver_include(*,G,I) is true but none of the local members 377 desire to receive traffic from S. 379 The set pim_nbrs is the set of all interfaces on which the router has at 380 least one active PIM neighbor. 382 The set prunes(S,G) is the set of all interfaces on which the router has 383 received Prune(S,G) messages: 385 prunes(S,G) = {all interfaces I such that 386 DownstreamPState(S,G,I) is in Pruned state} 388 The set lost_assert(S,G) is the set of all interfaces on which the 389 router has lost an (S,G) Assert. 391 lost_assert(S,G) = {all interfaces I such that 392 lost_assert(S,G,I) == TRUE} 394 boundary(G) = {all interfaces I with an administratively scoped 395 boundary for group G} 397 The following pseudocode macro definitions are also used in many places 398 in the specification. Basically RPF' is the RPF neighbor towards a 399 source unless a PIM-DM Assert has overridden the normal choice of 400 neighbor. 402 neighbor RPF'(S,G) { 403 if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) { 404 return AssertWinner(S, G, RPF_interface(S) ) 405 } else { 406 return MRIB.next_hop( S ) 407 } 408 } 410 The macro I_Am_Assert_loser(S, G, I) is true if the Assert state machine 411 (in section 4.6) for (S,G) on interface I is in the "I am Assert Loser" 412 state. 414 4.2. Data Packet Forwarding Rules 416 The PIM-DM packet forwarding rules are defined below in pseudocode. 418 iif is the incoming interface of the packet. 419 S is the source address of the packet. 420 G is the destination address of the packet (group address). 421 RPF_interface(S) is the interface the MRIB indicates would be used to 422 route packets to S. 424 First, an RPF check MUST be performed to determine whether the packet 425 should be accepted based on TIB state and the interface on which that 426 the packet arrived. Packets that fail the RPF check MUST NOT be 427 forwarded and the router will conduct an assert process for the (S,G) 428 pair specified in the packet. Packets for which a route to the source 429 cannot be found MUST be discarded. 431 If the RPF check has been passed, an outgoing interface list is 432 constructed for the packet. If this list is not empty, then the packet 433 MUST be forwarded to all listed interfaces. If the list is empty, then 434 the router will conduct a prune process for the (S,G) pair specified in 435 the packet. 437 On receipt on a data packet from S addressed to G on interface iif: 439 if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned) { 440 oiflist = olist(S,G) 441 } else { 442 oiflist = NULL 443 } 444 forward packet on all interfaces in oiflist 446 This pseudocode employs the following "macro" definition: 448 UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in 449 section 4.4.1. 451 4.3. Hello Messages 453 This section describes the generation and processing of Hello messages. 455 4.3.1. Sending Hello Messages 457 PIM-DM uses Hello messages to detect other PIM routers. Hello messages 458 are sent periodically on each PIM enabled interface. Hello messages are 459 multicast to the ALL-PIM-ROUTERS group. When PIM is enabled on an 460 interface or a router first starts, the Hello Timer (HT) MUST be set to 461 random value between 0 and Triggered_Hello_Delay. This prevents 462 synchronization of Hello messages if multiple routers are powered on 463 simultaneously. 465 After the initial Hello message, a Hello message MUST be sent every 466 Hello_Period. A single Hello timer MAY be used to trigger sending 467 Hello messages on all active interfaces. The Hello Timer SHOULD NOT be 468 reset except when it expires. 470 4.3.2. Receiving Hello Messages 472 When a Hello message is received, the receiving router SHALL record the 473 receiving interface, the sender and any information contained in 474 recognized options. This information is retained for a number of 475 seconds in the Hold Time field of the Hello Message. If a new Hello 476 message is received from a particular neighbor N, the Neighbor Liveness 477 Timer (NLT(N,I)) MUST be reset to the newly received Hello Holdtime. If 478 a Hello message is received from a new neighbor, the receiving router 479 SHOULD send its own Hello message after a random delay between 0 and 480 Triggered_Hello_Delay. 482 4.3.3. Hello Message Hold Time 484 The Hold Time in the Hello Message should be set to a value that can 485 reasonably be expected to keep the Hello active until a new Hello 486 message is received. On most links, this will be 3.5 times the value of 487 Hello_Period. 489 If the Hold Time is set to '0xffff', the receiving router MUST NOT time 490 out that Hello message. This feature might be used for on-demand links 491 to avoid keeping the link up with periodic Hello messages. 493 If a Hold Time of '0' is received, the corresponding neighbor state is 494 expired immediately. When a PIM router takes an interface down or 495 changes IP address, a Hello message with a zero Hold Time SHOULD be sent 496 immediately (with the old IP address if the IP address is changed) to 497 cause any PIM neighbors to remove the old information immediately. 499 4.3.4. Handling Router Failures 501 If a Hello message is received from an active neighbor with a different 502 Generation ID (GenID), the neighbor has restarted and may not contain 503 the correct (S,G) state. A Hello message SHOULD be sent after a random 504 delay between 0 and Triggered_Hello_Delay (see 4.8) before any other 505 messages are sent. If the neighbor is downstream, the router MAY 506 replay the last State Refresh message for any (S,G) pairs for which it 507 is the Assert Winner indicating Prune and Assert status to the 508 downstream router. These State Refresh messages SHOULD be sent out 509 immediately after the Hello message. If the neighbor is the upstream 510 neighbor for an (S,G) entry, the router MAY cancel its Prune Limit 511 Timer to permit sending a prune and reestablishing a Pruned state in the 512 upstream router. 514 Upon startup, a router MAY use any State Refresh messages received 515 within Hello_Period of its first Hello message on an interface to 516 establish state information. The State Refresh source will be the 517 RPF'(S), and Prune status for all interfaces will be set according to 518 the Prune Indicator bit in the State Refresh message. If the Prune 519 Indicator is set, the router SHOULD set the PruneLimitTimer to 520 Prune_Holdtime and set the PruneTimer on all downstream interfaces to 521 the State Refresh's Interval times two. The router SHOULD then 522 propagate the State Refresh as described in section 4.5.1. 524 4.3.5. Reducing Prune Propagation Delay on LANs 526 If all routers on a LAN support the LAN Prune Delay option, then the PIM 527 routers on that LAN will use the values received to adjust their 528 J/P_Override_Interval on that interface and the interface is LAN Delay 529 Enabled. Briefly, to avoid synchronization of Prune Override (Join) 530 messages when multiple downstream routers share a multi-access link, 531 sending of such messages is delayed by a small random amount of time. 532 The period of randomization is configurable and has a default value of 3 533 seconds. 535 Each router on the LAN expresses its view of the amount of randomization 536 necessary in the Override Interval field of the LAN Prune Delay option. 537 When all routers on a LAN use the LAN Prune Delay Option, all routers on 538 the LAN MUST set their Override_Interval to the largest Override value 539 on the LAN. 541 The LAN Delay inserted by a router in the LAN Prune Delay option 542 expresses the expected message propagation delay on the link and SHOULD 543 be configurable by the system administrator. When all routers on a link 544 use the LAN Prune Delay Option, all routers on the LAN MUST set 545 Propagation Delay to the largest LAN Delay on the LAN. 547 PIM implementers should enforce a lower bound on the permitted values 548 for this delay to allow for scheduling and processing delays within 549 their router. Such delays may cause received messages to be processed 550 later as well as triggered messages to be sent later than intended. 551 Setting this LAN Prune Delay to too low a value may result in temporary 552 forwarding outages because a downstream router will not be able to 553 override a neighbor's prune message before the upstream neighbor stops 554 forwarding. 556 4.4. PIM-DM Prune, Join and Graft Messages 558 This section describes the generation and processing of PIM-DM Join, 559 Prune and Graft messages. Prune messages are sent towards the upstream 560 neighbor for S to indicate that traffic from S addressed to group G is 561 not desired. In the case of two downstream routers A and B, where A 562 wishes to continue receiving data and B does not, A will send a Join in 563 response to B's Prune to override the Prune. This is the only situation 564 in PIM-DM in which a Join message is used. Finally, a Graft message is 565 used to re-join a previously pruned branch to the delivery tree. 567 4.4.1. Upstream Prune, Join and Graft Messages 569 The Upstream(S,G) state machine for sending Prune, Graft and Join 570 messages is given below. There are three states. 572 Forwarding (F) 573 This is the starting state of the Upsteam(S,G) state machine. The 574 state machine is in this state if it just started or if 575 oiflist(S,G) != NULL. 577 Pruned(P) 578 The set, olist(S,G), is empty. The router will not forward data 579 from S addressed to group G. 581 AckPending(AP) 582 The router was in the Pruned(P) state but a transition has occurred 583 in the Downstream(S,G) state machine for one of this (S,G) entry's 584 outgoing interfaces indicating that traffic from S addressed to G 585 should again be forwarded. A Graft message has been sent to RPF'(S) 586 but a Graft Ack message has not yet been received. 588 In addition there are three state-machine-specific timers: 590 GraftRetry Timer (GRT(S,G)) 591 This timer is set when a Graft is sent upstream. If a corresponding 592 GraftAck is not received before the timer expires, then another 593 Graft is sent and the GraftRetry Timer is reset. The timer is 594 stopped when a Graft Ack message is received. This timer is normally 595 set to Graft_Retry_Period (see 4.8). 597 Override Timer (OT(S,G)) 598 This timer is set when a Prune(S,G) is received on the upstream 599 interface where olist(S,G) != NULL. When the timer expires, a 600 Join(S,G) message is sent on the upstream interface. This timer is 601 normally set to t_override (see 4.8). 603 Prune Limit Timer (PLT(S,G)) 604 This timer is used to rate-limit Prunes on a LAN. It is only used 605 when the Upstream(S,G) state machine is in the Pruned state. A Prune 606 cannot be sent if this timer is running. This timer is normally set 607 to t_limit (see 4.8). 609 +-------------+ +-------------+ 610 | | olist == NULL | | 611 | Forward |----------------------->| Pruned | 612 | | | | 613 +-------------+ +-------------+ 614 ^ | ^ | 615 | | | | 616 | |RPF`(S) Changes olist == NULL| | 617 | | | | 618 | | +-------------+ | | 619 | +-------->| |----------+ | 620 | | AckPending | | 621 +-------------| |<-------------+ 622 Rcv GraftAck OR +-------------+ olist != NULL 623 Rcv State Refresh 624 With (P==0) OR 625 S Directly Connect 627 Figure 1: Upstream Interface State Machine 629 In tabular form, the state machine is defined as follows: 631 +-------------------------------+--------------------------------------+ 632 | | Previous State | 633 | +------------+------------+------------+ 634 | Event | Forwarding | Pruned | AckPending | 635 +-------------------------------+------------+------------+------------+ 636 | Data packet arrives on | ->P Send | ->P Send | N/A | 637 | RPF_Interface(S) AND | Prune(S,G) | Prune(S,G) | | 638 | olist(S,G) == NULL AND |Set PLT(S,G)|Set PLT(S,G)| | 639 | PLT(S,G) not running | | | | 640 +-------------------------------+------------+------------+------------+ 641 | State Refresh(S,G) received | ->F Set | ->P Reset |->AP Set | 642 | from RPF`(S) AND | OT(S,G) | PLT(S,G) | OT(S,G) | 643 | Prune Indicator == 1 | | | | 644 +-------------------------------+------------+------------+------------+ 645 | State Refresh(S,G) received | ->F | ->P Send |->F Cancel | 646 | from RPF`(S) AND | | Prune(S,G) | GRT(S,G) | 647 | Prune Indicator == 0 AND | |Set PLT(S,G)| | 648 | PLT(S,G) not running | | | | 649 +-------------------------------+------------+------------+------------+ 650 | See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel | 651 | | OT(S,G) | | OT(S,G) | 652 +-------------------------------+------------+------------+------------+ 653 | See Prune(S,G) | ->F Set | ->P |->AP Set | 654 | | OT(S,G) | | OT(S,G) | 655 +-------------------------------+------------+------------+------------+ 656 | OT(S,G) Expires | ->F Send | N/A |->AP Send | 657 | | Join(S,G) | | Join(S,G) | 658 +-------------------------------+------------+------------+------------+ 659 +-------------------------------+--------------------------------------+ 660 | | Previous State | 661 | +------------+------------+------------+ 662 | Event | Forwarding | Pruned | AckPending | 663 +-------------------------------+------------+------------+------------+ 664 | olist(S,G)->NULL | ->P Send | N/A |->P Send | 665 | | Prune(S,G) | | Prune(S,G) | 666 | |Set PLT(S,G)| |Set PLT(S,G)| 667 | | | | Cancel | 668 | | | | GRT(S,G) | 669 +-------------------------------+------------+------------+------------+ 670 | olist(S,G)->non-NULL | N/A | ->AP Send | N/A | 671 | | | Graft(S,G) | | 672 | | |Set GRT(S,G)| | 673 +-------------------------------+------------+------------+------------+ 674 | RPF'(S) Changes AND | ->AP Send | ->AP Send |->AP Send | 675 | olist(S,G) != NULL | Graft(S,G) | Graft(S,G) | Graft(S,G) | 676 | |Set GRT(S,G)|Set GRT(S,G)|Set GRT(S,G)| 677 +-------------------------------+------------+------------+------------+ 678 | RPF'(S) Changes AND | ->P | ->P Cancel |->P Cancel | 679 | olist(S,G) == NULL | | PLT(S,G) | GRT(S,G) | 680 +-------------------------------+------------+------------+------------+ 681 | S becomes directly connected | ->F | ->P |->F Cancel | 682 | | | | GRT(S,G) | 683 +-------------------------------+------------+------------+------------+ 684 | GRT(S,G) Expires | N/A | N/A |->AP Send | 685 | | | | Graft(S,G) | 686 | | | |Set GRT(S,G)| 687 +-------------------------------+------------+------------+------------+ 688 | Receive GraftAck(S,G) from | ->F | ->P |->F Cancel | 689 | RPF'(S) | | | GRT(S,G) | 690 +-------------------------------+------------+------------+------------+ 692 The transition event "RcvGraftAck(S,G)" implies receiving a Graft Ack 693 message targeted to this router's address on the incoming interface for 694 the (S,G) entry. If the destination address is not correct, the state 695 transitions in this state machine must not occur. 697 4.4.1.1. Transitions from the Forwarding (F) State 699 When the Upstream(S,G) state machine is in the Forwarding (F) state, the 700 following events may trigger a transition: 702 Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND S 703 NOT directly connected 704 The Upstream(S,G) state machine MUST transition to the Pruned (P) 705 state, send a Prune(S,G) to RPF'(S) and set PLT(S,G) to t_limit 706 seconds. 708 State Refresh(S,G) Received from RPF'(S) 709 The Upstream(S,G) state machine remains in a Forwarding state. If 710 the received State Refresh has the Prune Indicator bit set to one, 711 this router must override the upstream router's Prune state after a 712 short random interval. If OT(S,G) is not running and the Prune 713 Indicator bit equals one, the router MUST set OT(S,G) to t_override 714 seconds. 716 See Join(S,G) to RPF'(S) 717 This event is only relevant if RPF_interface(S) is a shared medium. 718 This router sees another router on RPF_interface(S) send a Join(S,G) 719 to RPF'(S,G). If the OT(S,G) is running, then it means that the 720 router had scheduled a Join to override a previously received Prune. 721 Another router has responded more quickly with a Join and so the 722 local router SHOULD cancel its OT(S,G), if it is running. The 723 Upstream(S,G) state machine remains in the Forwarding (F) state. 725 See Prune(S,G) AND S NOT directly connected 726 This event is only relevant if RPF_interface(S) is a shared medium. 727 This router sees another router on RPF_interface(S) send a 728 Prune(S,G). As this router is in Forwarding state, it must 729 override the Prune after a short random interval. If OT(S,G) is not 730 running, the router MUST set OT(S,G) to t_override seconds. The 731 Upstream(S,G) state machine remains in Forwarding (F) state. 733 OT(S,G) Expires AND S NOT directly connected 734 The OverrideTimer (OT(S,G)) expires. The router MUST send a 735 Join(S,G) to RPF'(S) to override a previously detected prune. The 736 Upstream(S,G) state machine remains in the Forwarding (F) state. 738 olist(S,G) -> NULL AND S NOT directly connected 739 The Upstream(S,G) state machine MUST transition to the Pruned (P) 740 state, send a Prune(S,G) to RPF'(S) and set PLT(S,G) to t_limit 741 seconds. 743 RPF'(S) Changes AND olist(S,G) is non-NULL AND S NOT directly 744 connected 745 Unicast routing or Assert state causes RPF'(S) to change, including 746 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 747 transition to the AckPending (AP) state, unicast a Graft to the new 748 RPF'(S) and set the GraftRetry Timer (GRT(S,G)) to 749 Graft_Retry_Period. 751 RPF'(S) Changes AND olist(S,G) is NULL 752 Unicast routing or Assert state causes RPF'(S) to change, including 753 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 754 transition to the Pruned (P) state. 756 4.4.1.2. Transitions from the Pruned (P) State 758 When the Upstream(S,G) state machine is in the Pruned (P) state, the 759 following events may trigger a transition: 761 Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT 762 directly connected 763 Either another router on the LAN desires traffic from S addressed to 764 G or a previous Prune was lost. In order to prevent generating a 765 Prune(S,G) in response to every data packet, the PruneLimit Timer 766 (PLT(S,G)) is used. Once the PLT(S,G) expires, the router needs to 767 send another prune in response to a data packet not received 768 directly from the source. A Prune(S,G) MUST be sent to RPF'(S) and 769 the PLT(S,G) MUST be set to t_limit. 771 State Refresh(S,G) Received from RPF'(S) 772 The Upstream(S,G) state machine remains in a Pruned state. If the 773 State Refresh has its Prune Indicator bit set to zero and PLT(S,G) 774 is not running, a Prune(S,G) MUST be sent to RPF'(S) and the 775 PLT(S,G) MUST be set to t_limit. If the State Refresh has its Prune 776 Indicator bit set to one, the router MUST reset PLT(S,G) to t_limit. 778 See Prune(S,G) to RPF'(S) 779 A Prune(S,G) is seen on RPF_interface(S) to RPF'(S). The 780 Upstream(S,G) state machine stays in the Pruned (P) state. The 781 router MAY reset its PLT(S,G) to the value in the Holdtime field of 782 the received message if greater than the current value of the 783 PLT(S,G). 785 olist(S,G)->non-NULL AND S NOT directly connected 786 The set of interfaces defined by the olist(S,G) macro becomes 787 non-empty indicating traffic from S addressed to group G must be 788 forwarded. The Upstream(S,G) state machine MUST cancel PLT(S,G), 789 transition to the AckPending (AP) state and unicast a Graft message 790 to RPF'(S). The Graft Retry Timer (GRT(S,G)) MUST be set to 791 Graft_Retry_Period. 793 RPF'(S) Changes AND olist(S,G) == non-NULL AND S NOT directly 794 connected 795 Unicast routing or Assert state causes RPF'(S) to change, including 796 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 797 cancel PLT(S,G), transition to the AckPending (AP) state, send a 798 Graft unicast to the new RPF'(S) and set the GraftRetry Timer 799 (GRT(S,G)) to Graft_Retry_Period. 801 RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected 802 Unicast routing or Assert state causes RPF'(S) to change, including 803 changes to RPF_Interface(S). The Upstream(S,G) state machine stays 804 in the Pruned (P) state and MUST cancel the PLT(S,G) timer. 806 S becomes directly connected 807 Unicast routing changed so that S is directly connected. The 808 Upstream(S,G) state machine remains in the Pruned (P) state. 810 4.4.1.3. Transitions from the AckPending (AP) State 812 When the Upstream(S,G) state machine is in the AckPending (AP) state, 813 the following events may trigger a transition: 815 State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 1 816 The Upstream(S,G) state machine remains in an AckPending state. The 817 router must override the upstream router's Prune state after a short 818 random interval. If OT(S,G) is not running and the Prune Indicator 819 bit equals one, the router MUST set OT(S,G) to t_override seconds. 821 State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 0 822 The router MUST cancel its GraftRetry Timer (GRT(S,G)) and 823 transition to the Forwarding (F) state. 825 See Join(S,G) to RPF'(S,G) 826 This event is only relevant if RPF_interface(S) is a shared medium. 827 This router sees another router on RPF_interface(S) send a Join(S,G) 828 to RPF'(S,G). If the OT(S,G) is running, then it means that the 829 router had scheduled a Join to override a previously received Prune. 830 Another router has responded more quickly with a Join and so the 831 local router SHOULD cancel its OT(S,G), if it is running. The 832 Upstream(S,G) state machine remains in the AckPending (AP) state. 834 See Prune(S,G) 835 This event is only relevant if RPF_interface(S) is a shared medium. 836 This router sees another router on RPF_interface(S) send a 837 Prune(S,G). As this router is in AckPending (AP) state, it must 838 override the Prune after a short random interval. If OT(S,G) is not 839 running, the router MUST set OT(S,G) to t_override seconds. The 840 Upstream(S,G) state machine remains in AckPending (AP) state. 842 OT(S,G) Expires 843 The OverrideTimer (OT(S,G)) expires. The router MUST send a 844 Join(S,G) to RPF'(S). The Upstream(S,G) state machine remains in 845 the AckPending (AP) state. 847 olist(S,G) -> NULL 848 The set of interfaces defined by the olist(S,G) macro becomes null 849 indicating traffic from S addressed to group G should no longer be 850 forwarded. The Upstream(S,G) state machine MUST transition to the 851 Pruned (P) state. A Prune(S,G) MUST be multicast to the 852 RPF_interface(S) with RPF'(S) named in the upstream neighbor field. 853 The GraftRetry Timer (GRT(S,G)) MUST be cancelled and PLT(S,G) MUST 854 be set to t_limit seconds. 856 RPF'(S) Changes AND olist(S,G) does not become NULL AND S NOT directly 857 connected 858 Unicast routing or Assert state causes RPF'(S) to change, including 859 changes to RPF_Interface(S). The Upstream(S,G) state machine stays 860 in the AckPending (AP) state. A Graft MUST be unicast to the new 861 RPF'(S) and the GraftRetry Timer (GRT(S,G)) reset to 862 Graft_Retry_Period. 864 RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected 865 Unicast routing or Assert state causes RPF'(S) to change, including 866 changes to RPF_Interface(S). The Upstream(S,G) state machine MUST 867 transition to the Pruned (P) state. The GraftRetry Timer (GRT(S,G)) 868 MUST be cancelled. 870 S becomes directly connected 871 Unicast routing has changed so that S is directly connected. The 872 GraftRetry Timer MUST be cancelled and the Upstream(S,G) state 873 machine MUST transition to the Forwarding(F) state. 875 GRT(S,G) Expires 876 The GraftRetry Timer (GRT(S,G)) expires for this (S,G) entry. The 877 Upstream(S,G) state machine stays in the AckPending (AP) state. 878 Another Graft message for (S,G) SHOULD be unicasted to RPF'(S) and 879 the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period. It is 880 RECOMMENDED that the router retry a configured number of times 881 before ceasing retries. 883 See GraftAck(S,G) from RPF'(S) 884 A GraftAck is received from RPF'(S). The GraftRetry Timer MUST be 885 cancelled and the Upstream(S,G) state machine MUST transition to the 886 Forwarding(F) state. 888 4.4.2 Downstream Prune, Join and Graft Messages 890 The Prune(S,G) Downstream state machine for receiving Prune, Join and 891 Graft messages on interface I is given below. This state machine MUST 892 always be in the NoInfo state on the upstream interface. It contains 893 three states. 895 NoInfo(NI) 896 The interface has no (S,G) Prune state and neither the Prune timer 897 (PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is running. 899 PrunePending(PP) 900 The router has received a Prune(S,G) on this interface from a 901 downstream neighbor and is waiting to see whether the prune will be 902 overridden by another downstream router. For forwarding purposes, 903 the PrunePending state functions exactly like the NoInfo state. 905 Pruned(P) 906 The router has received a Prune(S,G) on this interface from a 907 downstream neighbor and the Prune was not overridden. Data from S 908 addressed to group G is no longer being forwarded on this interface. 910 In addition there are two timers: 912 PrunePending Timer (PPT(S,G,I)) 913 This timer is set when a valid Prune(S,G) is received. Expiry of 914 the PrunePending Timer (PPT(S,G,I)) causes the interface to 915 transition to the Pruned state. 917 Prune Timer (PT(S,G,I)) 918 This timer is set when the PrunePending Timer (PT(S,G,I)) expires. 919 Expiry of the Prune Timer (PT(S,G,I)) causes the interface to 920 transition to the NoInfo (NI) state, thereby allowing data from S 921 addressed to group G to be forwarded on the interface. 923 +-------------+ +-------------+ 924 | | PPT Expires | | 925 |PrunePending |----------------------->| Pruned | 926 | | | | 927 +-------------+ +-------------+ 928 | ^ | 929 | | | 930 | |Rcv Prune | 931 | | | 932 | | +-------------+ | 933 | +---------| | | 934 | | NoInfo |<-------------+ 935 +------------>| | Rcv Join/Graft OR 936 Rcv Join/Graft OR +-------------+ PT Expires OR 937 RPF_Interface(S)->I RPF_Interface(S)->I 939 Figure 2: Downstream Interface State Machine 941 In tabular form, the state machine is: 943 +-------------------------------+--------------------------------------+ 944 | | Previous State | 945 + +------------+------------+------------+ 946 | Event | No Info | PrunePend | Pruned | 947 +-------------------------------+------------+------------+------------+ 948 | Receive Prune(S,G) |->PP Set |->PP |->P Reset | 949 | | PPT(S,G,I) | | PT(S,G,I) | 950 +-------------------------------+------------+------------+------------+ 951 | Receive Join(S,G) |->NI |->NI Cancel |->NI Cancel | 952 | | | PPT(S,G,I) | PT(S,G,I) | 953 +-------------------------------+------------+------------+------------+ 954 | Receive Graft(S,G) |->NI Send |->NI Send |->NI Send | 955 | | GraftAck | GraftAck | GraftAck | 956 | | | Cancel | Cancel | 957 | | | PPT(S,G,I) | PT(S,G,I) | 958 +-------------------------------+------------+------------+------------+ 959 | PPT(S,G) Expires | N/A |->P Set | N/A | 960 | | | PT(S,G,I) | | 961 +-------------------------------+------------+------------+------------+ 962 | PT(S,G) Expires | N/A | N/A |->NI | 963 +-------------------------------+------------+------------+------------+ 964 | RPF_Interface(S) becomes I |->NI |->NI Cancel |->NI Cancel | 965 | | | PPT(S,G,I) | PT(S,G,I) | 966 +-------------------------------+------------+------------+------------+ 967 | Send State Refresh(S,G) out I |->NI |->PP |->P Reset | 968 | | | | PT(S,G,I) | 969 +-------------------------------+------------+------------+------------+ 971 The transition events "Receive Graft(S,G)", "Receive Prune(S,G)" and 972 "Receive Join(S,G)" denote receiving a Graft, Prune or Join message in 973 which this router's address on I is contained in the message's upstream 974 neighbor field. If the upstream neighbor field does not match this 975 router's address on I, then these state transitions in this state 976 machine must not occur. 978 4.4.2.1. Transitions from the NoInfo State 980 When the Prune(S,G) Downstream state machine is in the NoInfo (NI) 981 state, the following events may trigger a transition: 983 Receive Prune(S,G) 984 A Prune(S,G) is received on interface I with the upstream neighbor 985 field set to the router's address on I. The Prune(S,G) Downstream 986 state machine on interface I MUST transition to the PrunePending 987 (PP) state. The PrunePending Timer (PPT(S,G,I)) MUST be set to 988 J/P_Override_Interval if the router has more than one neighbor on I. 989 If the router has only one neighbor on interface I, then it SHOULD 990 set the PPT(S,G,I) to zero, effectively transitioning immediately to 991 the Pruned (P) state. 993 Receive Graft(S,G) 994 A Graft(S,G) is received on the interface I with the upstream 995 neighbor field set to the router's address on I. The Prune(S,G) 996 Downstream state machine on interface I stays in the NoInfo (NI) 997 state. A GraftAck(S,G) MUST be unicasted to the originator of the 998 Graft(S,G) message. 1000 4.4.2.2. Transitions from the PrunePending (PP) State 1002 When the Prune(S,G) downstream state machine is in the PrunePending (PP) 1003 state, the following events may trigger a transition. 1005 Receive Join(S,G) 1006 A Join(S,G) is received on interface I with the upstream neighbor 1007 field set to the router's address on I. The Prune(S,G) Downstream 1008 state machine on interface I MUST transition to the NoInfo (NI) 1009 state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. 1011 Receive Graft(S,G) 1012 A Graft(S,G) is received on interface I with the upstream neighbor 1013 field set to the router's address on I. The Prune(S,G) Downstream 1014 state machine on interface I MUST transition to the NoInfo (NI) 1015 state and MUST unicast a Graft Ack message to the Graft originator. 1016 The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. 1018 PPT(S,G,I) Expires 1019 The PrunePending Timer (PPT(S,G,I)) expires indicating that no 1020 neighbors have overridden the previous Prune(S,G) message. The 1021 Prune(S,G) Downstream state machine on interface I MUST transition 1022 to the Pruned (P) state. The Prune Timer (PT(S,G,I)) is started and 1023 MUST be initialized to the received Prune_Hold_Time minus 1024 J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has 1025 more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G) 1026 message multicast by the upstream router to a LAN with itself as the 1027 Upstream Neighbor. Its purpose is to add additional reliability so 1028 that if a Join that should have overridden the Prune is lost locally 1029 on the LAN, then the PruneEcho(S,G) may be received and trigger a 1030 new Join message . A PruneEcho(S,G) is OPTIONAL on an interface 1031 with only one PIM neighbor. In addition, the router MUST evaluate any 1032 possible transitions in the Upstream(S,G) state machine. 1034 RPF_Interface(S) becomes interface I 1035 The upstream interface for S has changed. The Prune(S,G) Downstream 1036 state machine on interface I MUST transition to the NoInfo (NI) 1037 state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. 1039 4.4.2.3. Transitions from the Prune (P) State 1041 When the Prune(S,G) Downstream state machine is in the Pruned (P) state, 1042 the following events may trigger a transition. 1044 Receive Prune(S,G) 1045 A Prune(S,G) is received on the interface I with the upstream 1046 neighbor field set to the router's address on I. The Prune(S,G) 1047 Downstream state machine on interface I remains in the Pruned (P) 1048 state. The Prune Timer (PT(S,G,I)) SHOULD be reset to the holdtime 1049 contained in the Prune(S,G) message if it is greater than the 1050 current value. 1052 Receive Join(S,G) 1053 A Join(S,G) is received on the interface I with the upstream 1054 neighbor field set to the router's address on I. The Prune(S,G) 1055 downstream state machine on interface I MUST transition to the 1056 NoInfo (NI) state. The Prune Timer (PT(S,G,I)) MUST be cancelled. 1057 The router MUST evaluate any possible transitions in the 1058 Upstream(S,G) state machine. 1060 Receive Graft(S,G) 1061 A Graft(S,G) is received on interface I with the upstream neighbor 1062 field set to the router's address on I. The Prune(S,G) Downstream 1063 state machine on interface I MUST transition to the NoInfo (NI) 1064 state and send a Graft Ack back to the Graft's source. The Prune 1065 Timer (PT(S,G,I)) MUST be cancelled. The router MUST evaluate any 1066 possible transitions in the Upstream(S,G) state machine. 1068 PT(S,G,I) Expires 1069 The Prune Timer (PT(S,G,I)) expires indicating that it is again time 1070 to flood data from S addressed to group G onto interface I. The 1071 Prune(S,G) Downstream state machine on interface I MUST transition 1072 to the NoInfo (NI) state. The router MUST evaluate any possible 1073 transitions in the Upstream(S,G) state machine. 1075 RPF_Interface(S) becomes interface I 1076 The upstream interface for S has changed. The Prune(S,G) Downstream 1077 state machine on interface I MUST transition to the NoInfo (NI) 1078 state. The PruneTimer (PT(S,G,I)) MUST be cancelled. 1080 Send State Refresh(S,G) out interface I 1081 The router has refreshed the Prune(S,G) state on interface I. The 1082 router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime from 1083 an active Prune received on interface I. The Holdtime used SHOULD 1084 be the largest active one, but MAY be the most recently received 1085 active Prune Holdtime. 1087 4.5. State Refresh 1089 This section describes the major portions of the state refresh 1090 mechanism. 1092 4.5.1. Forwarding of State Refresh Messages 1094 When a State Refresh message, SRM, is received, it is forwarded 1095 according to the following pseudo-code. 1097 if (iif != RPF_interface(S)) 1098 return; 1099 if (RPF'(S) != srcaddr(SRM)) 1100 return; 1101 if (StateRefreshRateLimit(S,G) == TRUE) 1102 return; 1104 for each interface I in pim_nbrs { 1105 if (TTL(SRM) == 0 OR (TTL(SRM) - 1) < Threshold(I)) 1106 continue; /* Out of TTL, skip this interface */ 1107 if (boundary(I,G)) 1108 continue; /* This interface is scope boundary, skip it */ 1109 if (I == iif) 1110 continue; /* This is the incoming interface, skip it */ 1111 if (lost_assert(S,G,I) == TRUE) 1112 continue; /* Let the Assert Winner do State Refresh */ 1114 Copy SRM to SRM'; /* Make a copy of SRM to forward */ 1116 if (I contained in prunes(S,G)) { 1117 set Prune Indicator bit of SRM' to 1; 1119 if StateRefreshCapable(I) == TRUE 1120 set PT(S,G) to largest active holdtime read from a Prune message 1121 accepted on I; 1123 } else { 1124 set Prune Indicator bit of SRM' to 0; 1125 } 1127 set srcaddr(SRM') to my_addr(I); 1128 set TTL of SRM' to TTL(SRM) - 1; 1129 set metric of SRM' to metric of unicast route used to reach S; 1130 set pref of SRM' to preference of unicast route used to reach S; 1131 set mask of SRM' to mask of route used to reach S; 1132 if (AssertState == NoInfo) { 1133 set Assert Override of SRM' to 1; 1134 } else { 1135 set Assert Override of SRM' to 0; 1136 } 1138 transmit SRM' on I; 1139 } 1141 The pseudocode above employs the following macro definitions. 1143 Boundary(I,G) evaluates to TRUE if an administratively scoped boundary 1144 for group G is configured on interface I. 1146 StateRefreshCapable(I) evaluates to TRUE if all neighbors on an 1147 interface use the State Refresh option. 1149 StateRefreshRateLimit(S,G) evaluates to TRUE if the time elapsed since 1150 the last received StateRefresh(S,G) is less than the configured 1151 RefreshLimitInterval. 1153 TTL(SRM) returns the TTL contained in the State Refresh Message, SRM. 1154 This is different from the TTL contained in the IP header. 1156 Threshold(I) returns the minimum TTL that a packet must have before it 1157 can be transmitted on interface I. 1159 srcaddr(SRM) returns the source address contained in the network 1160 protocol (e.g. IPv4) header of the State Refresh Message, SRM. 1162 my_addr(I) returns this node's network (e.g. IPv4) address on interface 1163 I. 1165 4.5.2 State Refresh Message Origination 1167 This section describes the origination of State Refresh messages. These 1168 messages are generated periodically by the PIM-DM router that is 1169 directly connected to a source. One Origination(S,G) state machine 1170 exists per (S,G) entry in a PIM-DM router. 1172 The Origination(S,G) state machine has the following states: 1174 NotOriginator(NO) 1175 This is the starting state of the Origination(S,G) state machine. 1176 While in this state a router will not originate State Refresh 1177 messages for the (S,G) pair. 1179 Originator(O) 1180 When in this state the router will periodically originate State 1181 Refresh messages. Only routers which are directly connected to S 1182 may transition to this state. 1184 In addition there are two state-machine-specific timers: 1186 State Refresh Timer (SRT(S,G)) 1187 This timer is controls when State Refresh messages are generated. 1188 The timer is initially set when that Origination(S,G) state machine 1189 transitions to the O state. It is cancelled when the 1190 Origination(S,G) state machine transitions to the NO state. This 1191 timer is normally set to StateRefreshInterval (see 4.8). 1193 Source Active Timer (SAT(S,G)) 1194 This timer is first set when the Origination(S,G) state machine 1195 transitions to the O state and is reset on the receipt of every 1196 data packet from S addressed to group G. When it expires, the 1197 Origination(S,G) state machine transitions to the NO state. This 1198 timer is normally set to SourceLifetime (see 4.8). 1200 +-------------+ Rcv Directly From S +-------------+ 1201 | |----------------------->| | 1202 |NotOriginator| | Originator | 1203 | |<-----------------------| | 1204 +-------------+ SAT Expires OR +-------------+ 1205 S NOT Direct Connect 1207 Figure 3: State Refresh State Machine 1209 In tabular form, the state machine is defined as follows: 1211 +----------------------------------------------------------------------+ 1212 | | Previous State | 1213 | +---------------+-------------------+ 1214 | Event | NotOriginator | Originator | 1215 +----------------------------------+---------------+-------------------+ 1216 | Receive Data from S AND | ->O | ->O Reset | 1217 | S directly connected | Set SRT(S,G) | SAT(S,G) | 1218 | | Set SAT(S,G) | | 1219 +----------------------------------+---------------+-------------------+ 1220 | SRT(S,G) Expires | N/A | ->O Send | 1221 | | | StateRefresh(S,G) | 1222 | | | Reset SRT(S,G) | 1223 +----------------------------------+---------------+-------------------+ 1224 | SAT(S,G) Expires | N/A | ->NO Cancel | 1225 | | | SRT(S,G) | 1226 +----------------------------------+---------------+-------------------+ 1227 | S no longer directly connected | ->NO | ->NO | 1228 | | | Cancel SRT(S,G) | 1229 | | | Cancel SAT(S,G) | 1230 +----------------------------------+---------------+-------------------+ 1231 4.5.2.1. Transitions from the NotOriginator (NO) State 1233 When the Originating(S,G) state machine is in the NotOriginator (NO) 1234 state, the following event may trigger a transition: 1236 Data Packet received from directly connected Source S addressed to 1237 group G 1238 The router MUST transition to an Originator (O) state, set SAT(S,G) 1239 to SourceLifetime, and set SRT(S,G) to StateRefreshInterval. The 1240 router SHOULD record the TTL of the packet for use in State Refresh 1241 messages. 1243 4.5.2.2. Transitions from the Originator (O) State 1245 When the Originating(S,G) state machine is in the Originator (O) state, 1246 the following events may trigger a transition: 1248 Receive Data Packet from S addressed to G 1249 The router remains in the Originator (O) state and MUST reset 1250 SAT(S,G) to SourceLifetime. The router SHOULD increase its recorded 1251 TTL to match the TTL of the packet, if the packet's TTL is larger 1252 than the previously recorded TTL. 1254 SRT(S,G) Expires 1255 The router remains in the Originator (O) state and MUST reset 1256 SRT(S,G) to StateRefreshInterval. The router MUST also generate 1257 State Refresh messages for transmission as described in the State 1258 Refresh Forwarding rules (section 4.5.1) except for the TTL. If the 1259 TTL of data packets from S to G are being recorded, then the TTL of 1260 each State Refresh message is set to the highest recorded TTL. 1261 Otherwise, the TTL is set to the configured State Refresh TTL. Let 1262 I denote the interface over which a State Refresh message is being 1263 sent. If the Prune(S,G) Downstream state machine for I is in the 1264 NoInfo (NI) state, then the Prune-Indicator bit MUST be set to 0 in 1265 the State Refresh message being sent over I. Otherwise the 1266 Prune-Indicator bit MUST be set to 1. 1268 SAT(S,G) Expires 1269 The router MUST cancel the SRT(S,G) timer and transition to the 1270 NotOriginator (NO) state. 1272 S is no longer directly connected 1273 The router MUST transition to the NotOriginator (NO) state and 1274 cancel both the SAT(S,G) and SRT(S,G). 1276 4.6. PIM Assert Messages 1278 4.6.1. Assert Metrics 1280 Assert metrics are defined as: 1282 struct assert_metric { 1283 metric_preference; 1284 route_metric; 1285 ip_address; 1286 }; 1288 When comparing assert_metrics, the metric_preference and route_metric 1289 field are compared in order, where the first lower value wins. If all 1290 fields are equal, the IP address of the router that sourced the Assert 1291 message is used as a tie-breaker, with the highest IP address winning. 1293 An Assert metric for (S,G) to include in (or compare against) an Assert 1294 message sent on interface I should be computed using the following 1295 pseudocode: 1297 assert_metric 1298 my_assert_metric(S,G,I) { 1299 if (CouldAssert(S,G,I) == TRUE) { 1300 return spt_assert_metric(S,G,I) 1301 } else { 1302 return infinite_assert_metric() 1303 } 1304 } 1306 spt_assert_metric(S,I) gives the Assert metric we use if we're sending 1307 an Assert based on active (S,G) forwarding state: 1309 assert_metric 1310 spt_assert_metric(S,I) { 1311 return {0,MRIB.pref(S),MRIB.metric(S),my_addr(I)} 1312 } 1314 MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing 1315 metrics associated with the route to a particular (unicast) destination 1316 X, as determined by the MRIB. my_addr(I) is simply the router's network 1317 (e.g. IP) address that is associated with the local interface I. 1319 infinite_assert_metric() gives the Assert metric we need to send an 1320 Assert but doesn't match (S,G) forwarding state: 1322 assert_metric 1323 infinite_assert_metric() { 1324 return {1,infinity,infinity,0} 1325 } 1326 4.6.2. AssertCancel Messages 1328 An AssertCancel(S,G) message is simply an Assert message for (S,G) with 1329 infinite metric. The Assert winner sends such a message when it changes 1330 its upstream interface to this interface. Other routers will see this 1331 metric, causing those with forwarding state to send their own Asserts 1332 and re-establish an Assert winner. 1334 AssertCancel messages are simply an optimization. The original Assert 1335 timeout mechanism will allow a subnet to eventually become consistent; 1336 the AssertCancel mechanism simply causes faster convergence. No special 1337 processing is required for an AssertCancel message, since it is simply 1338 an Assert message from the current winner. 1340 4.6.3. Assert State Macros 1342 The macro lost_assert(S,G,I), is used in the olist computations of 1343 section 4.1.3, and is defined as follows: 1345 bool lost_assert(S,G,I) { 1346 if ( RPF_interface(S) == I ) { 1347 return FALSE 1348 } else { 1349 return (AssertWinner(S,G,I) != me AND 1350 (AssertWinnerMetric(S,G,I) is better than 1351 spt_assert_metric(S,G,I))) 1352 } 1353 } 1355 AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I) 1356 defaults to Infinity when in the NoInfo state. 1358 4.6.4. (S,G) Assert Message State Machine 1360 The (S,G) Assert state machine for interface I is shown in Figure 4. 1361 There are three states: 1363 NoInfo (NI) 1364 This router has no (S,G) Assert state on interface I. 1366 I am Assert Winner (W) 1367 This router has won an (S,G) Assert on interface I. It is now 1368 responsible for forwarding traffic from S destined for G via 1369 interface I. 1371 I am Assert Loser (L) 1372 This router has lost an (S,G) Assert on interface I. It must not 1373 forward packets from S destined for G onto interface I. 1375 In addition there is also an Assert Timer (AT(S,G,I)) that is used to 1376 time out Assert state. 1378 +-------------+ +-------------+ 1379 | | Rcv Pref Assert or SR | | 1380 | Winner |----------------------->| Loser | 1381 | | | | 1382 +-------------+ +-------------+ 1383 ^ | ^ | 1384 | | Rcv Pref Assert or| | 1385 | |AT Expires OR State Refresh| | 1386 | |CouldAssert->FALSE | | 1387 | | | | 1388 | | +-------------+ | | 1389 | +-------->| |----------+ | 1390 | | No Info | | 1391 +-------------| |<-------------+ 1392 Rcv Data from dnstrm +-------------+ Rcv Inf Assert from Win OR 1393 OR Rcv Inferior Assert Rcv Inf SR from Winner OR 1394 OR Rcv Inferior SR AT Expires OR 1395 CouldAssert Changes OR 1396 Winner's NLT Expires 1398 Figure 4: Assert State Machine 1400 In tabular form the state machine is defined as follows: 1402 +-------------------------------+--------------------------------------+ 1403 | | Previous State | 1404 | +------------+------------+------------+ 1405 | Event | No Info | Winner | Loser | 1406 +-------------------------------+------------+------------+------------+ 1407 | An (S,G) Data packet received | ->W Send | ->W Send | ->L | 1408 | on downstream interface | Assert(S,G)| Assert(S,G)| | 1409 | | Set | Set | | 1410 | | AT(S,G,I) | AT(S,G,I) | | 1411 +-------------------------------+--------------------------------------+ 1412 | Receive Inferior (Assert OR | N/A | N/A |->NI Cancel | 1413 | State Refresh) from Assert | | | AT(S,G,I) | 1414 | Winner | | | | 1415 +-------------------------------+--------------------------------------+ 1416 | Receive Inferior (Assert OR | ->W Send | ->W Send | ->L | 1417 | State Refresh) from non-Assert| Assert(S,G)| Assert(S,G)| | 1418 | Winner AND CouldAssert==TRUE | Set | Set | | 1419 | | AT(S,G,I) | AT(S,G,I) | | 1420 +-------------------------------+--------------------------------------+ 1421 +-------------------------------+--------------------------------------+ 1422 | | Previous State | 1423 | +------------+------------+------------+ 1424 | Event | No Info | Winner | Loser | 1425 +-------------------------------+------------+------------+------------+ 1426 | Receive Preferred Assert OR | ->L Send | ->L Send | ->L Set | 1427 | State Refresh | Prune(S,G) | Prune(S,G) | AT(S,G,I) | 1428 | | Set | Set | | 1429 | | AT(S,G,I) | AT(S,G,I) | | 1430 +-------------------------------+--------------------------------------+ 1431 | Send State Refresh | ->NI | ->W Reset | N/A | 1432 | | | AT(S,G,I) | | 1433 +-------------------------------+--------------------------------------+ 1434 | AT(S,G) Expires | N/A | ->NI | ->NI | 1435 +-------------------------------+--------------------------------------+ 1436 | CouldAssert -> FALSE | ->NI |->NI Cancel |->NI Cancel | 1437 | | | AT(S,G,I) | AT(S,G,I) | 1438 +-------------------------------+--------------------------------------+ 1439 | CouldAssert -> TRUE | ->NI | N/A |->NI Cancel | 1440 | | | | AT(S,G,I) | 1441 +-------------------------------+--------------------------------------+ 1442 | Winner's NLT(N,I) Expires | N/A | N/A |->NI Cancel | 1443 | | | | AT(S,G,I) | 1444 +-------------------------------+--------------------------------------+ 1445 | Receive Prune(S,G), Join(S,G) | ->NI | ->W | ->L Send | 1446 | or Graft(S,G) | | | Assert(S,G)| 1447 +-------------------------------+--------------------------------------+ 1449 Terminology: 1450 A "preferred assert" is one with a better metric than the current 1451 winner. An "inferior assert" is one with a worse metric than 1452 my_assert_metric(S,G,I). 1454 The state machine uses the following macro: 1456 CouldAssert(S,G,I) = (RPF_interface(S) != I) 1458 4.6.4.1. Transitions from NoInfo State 1460 When in NoInfo state, the following events may trigger transitions: 1462 An (S,G) data packet arrives on downstream interface I 1463 An (S,G) data packet arrived on a downstream interface. It is 1464 optimistically assumed that this router will be the Assert winner 1465 for this (S,G). The Assert state machine MUST transition to the "I 1466 am Assert Winner" state, send an Assert(S,G) to interface I, store 1467 its own address and metric as the Assert Winner and set the 1468 Assert_Timer (AT(S,G,I) to Assert_Time, thereby initiating the 1469 Assert negotiation for (S,G). 1471 Receive Inferior (Assert OR State Refresh) AND 1472 CouldAssert(S,G,I)==TRUE 1473 An Assert or State Refresh is received for (S,G) that is inferior 1474 to our own assert metric on interface I. The Assert state machine 1475 MUST transition to the "I am Assert Winner" state, send an 1476 Assert(S,G) to interface I, store its own address and metric as the 1477 Assert Winner and set the Assert Timer (AT(S,G,I)) to Assert_Time. 1479 Receive Preferred Assert or State Refresh 1480 The received Assert or State Refresh has a better metric than this 1481 router's and therefore the Assert state machine MUST transition to 1482 the "I am Assert Loser" state and store the Assert Winner's address 1483 and metric. If the metric was received in an Assert, the router MUST 1484 set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was 1485 received in a State Refresh, the router MUST set the Assert Timer 1486 (AT(S,G,I)) to three times the received State Refresh Interval. The 1487 router MUST also multicast a Prune(S,G) to the Assert winner with a 1488 Prune Hold Time equal to the Assert Timer and evaluate any changes 1489 in its Upstream(S,G) state machine. 1491 4.6.4.2. Transitions from Winner State 1493 When in "I am Assert Winner" state, the following events trigger 1494 transitions: 1496 An (S,G) data packet arrives on downstream interface I 1497 An (S,G) data packet arrived on a downstream interface. The Assert 1498 state machine remains in the "I am Assert Winner" state. The router 1499 MUST send an Assert(S,G) to interface I and set the Assert Timer 1500 (AT(S,G,I) to Assert_Time. 1502 Receive Inferior Assert or State Refresh 1503 An (S,G) Assert is received containing a metric for S that is worse 1504 metric than this router's metric for S. Whoever sent the Assert is 1505 in error. The router MUST send an Assert(S,G) to interface I and 1506 reset the Assert Timer (AT(S,G,I)) to Assert_Time. 1508 Receive Preferred Assert or State Refresh 1509 An (S,G) Assert or State Refresh is received that has a better 1510 metric than this router's metric for S on interface I. The Assert 1511 state machine MUST transition to "I am Assert Loser" state and 1512 store the new Assert Winner's address and metric. If the metric was 1513 received in an Assert, the router MUST set the Assert Timer 1514 (AT(S,G,I)) to Assert_Time. If the metric was received in a State 1515 Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three 1516 times the State Refresh Interval. The router MUST also multicast a 1517 Prune(S,G) to the Assert winner with a Prune Hold Time equal to the 1518 Assert Timer and evaluate any changes in its Upstream(S,G) state 1519 machine. 1521 Send State Refresh 1522 The router is sending a State Refresh(S,G) message on interface I. 1523 The router MUST set the Assert Timer (AT(S,G,I)) to three times the 1524 State Refresh Interval contained in the State Refresh(S,G) message. 1526 AT(S,G,I) Expires 1527 The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state machine 1528 MUST transition to the NoInfo (NI) state. 1530 CouldAssert(S,G,I) -> FALSE 1531 This router's RPF interface changed so as to make CouldAssert(S,G,I) 1532 become false. This router can no longer perform the actions of the 1533 Assert winner, and so the Assert state machine MUST transition to 1534 NoInfo (NI) state, send an AssertCancel(S,G) to interface I, cancel 1535 the Assert Timer (AT(S,G,I)) and remove itself as the Assert Winner. 1537 4.6.4.3. Transitions from Loser State 1539 When in "I am Assert Loser" state, the following transitions can occur: 1541 Receive Inferior Assert or State Refresh from Current Winner 1542 An Assert or State Refresh is received from the current Assert 1543 winner that is worse than this router's metric for S (typically the 1544 winner's metric became worse). The Assert state machine MUST 1545 transition to NoInfo (NI) state and cancel AT(S,G,I). The router 1546 MUST delete the previous Assert Winner's address and metric and 1547 evaluate any possible transitions to its Upstream(S,G) state 1548 machine. Usually this router will eventually re-assert and win when 1549 data packets from S have started flowing again. 1551 Receive Preferred Assert or State Refresh 1552 An Assert or State Refresh is received that has a metric better than 1553 or equal to that of the current Assert winner. The Assert state 1554 machine remains in Loser (L) state. If the metric was received in 1555 an Assert, the router MUST set the Assert Timer (AT(S,G,I)) to 1556 Assert_Time. If the metric was received in a State Refresh, the 1557 router MUST set the Assert Timer (AT(S,G,I)) to three times the 1558 received State Refresh Interval. If the metric is better than the 1559 current Assert Winner, the router MUST store the address and metric 1560 of the new Assert Winner and if CouldAssert == TRUE, the router 1561 MUST multicast a Prune(S,G) to the new Assert winner. 1563 AT(S,G,I) Expires 1564 The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state 1565 machine MUST transition to NoInfo (NI) state. The router MUST 1566 delete the Assert Winner's address and metric. If CouldAssert == 1567 TRUE, the router MUST evaluate any possible transitions to its 1568 Upstream(S,G) state machine. 1570 CouldAssert -> FALSE 1571 CouldAssert has become FALSE because interface I has become the RPF 1572 interface for S. The Assert state machine MUST transition to NoInfo 1573 (NI) state, cancel AT(S,G,I) and delete information concerning the 1574 Assert Winner on I. 1576 CouldAssert -> TRUE 1577 CouldAssert has become TRUE because interface I used to be the RPF 1578 interface for S, and now it is not. The Assert state machine MUST 1579 transition to NoInfo (NI) state, cancel AT(S,G,I) and delete 1580 information concerning the Assert Winner on I. 1582 Current Assert Winner's NeighborLiveness Timer Expires 1583 The current Assert winner's NeighborLiveness Timer (NLT(N,I)) has 1584 expired. The Assert state machine MUST transition to the NoInfo 1585 (NI) state, delete the Assert Winner's address and metric, and 1586 evaluate any possible transitions to its Upstream(S,G) state 1587 machine. 1589 Receive Prune(S,G), Join(S,G) or Graft(S,G) 1590 A Prune(S,G), Join(S,G) or Graft(S,G) message was received on 1591 interface I with its upstream neighbor address set to the router's 1592 address on I. The router MUST send an Assert(S,G) on the receiving 1593 interface I to initiate an Assert negotiation. The Assert state 1594 machine remains in the Assert Loser(L) state. If a Graft(S,G) was 1595 received, the router MUST respond with a GraftAck(S,G). 1597 4.6.5. Rationale for Assert Rules 1599 The following is a summary of the rules for generating and processing 1600 Assert messages. It is not intended to be definitive (the state 1601 machines and pseudocode provide the definitive behavior). Instead it 1602 provides some rationale for the behavior. 1604 1. The Assert winner for (S,G) must act as the local forwarder for (S,G) 1605 on behalf all downstream members. 1606 2. PIM messages are directed towards to the RPF' neighbor and not to the 1607 regular RPF neighbor. 1608 3. An Assert loser that receives a Prune(S,G), Join(S,G) or Graft(S,G) 1609 directed to it initiates a new Assert negotiation so the downstream 1610 router can correct its RPF'(S). 1611 4. An Assert winner for (S,G) sends a cancelling assert when it is about 1612 to stop forwarding on an (S,G) entry. Example: if a router is being 1613 taken down, then a canceling assert is sent. 1615 4.7. PIM Packet Formats 1617 All PIM-DM packets use the same format as PIM-SM packets. All PIM 1618 control messages have IP protocol number 103. All PIM-DM messages MUST 1619 be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack 1620 messages MUST be sent to the ALL-PIM-ROUTERS group. Graft messages 1621 SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be unicast to 1622 the sender of the Graft. 1624 The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS 1625 group is 'ff02::d'. 1627 4.7.1. PIM Header 1629 All PIM control messages have the following header: 1631 0 1 2 3 1632 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 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 |PIM Ver| Type | Reserved | Checksum | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 PIM Ver 1638 PIM version number is 2. 1640 Type 1641 Types for specific PIM messages. Available types are: 1642 0 = Hello 1643 1 = Register (PIM-SM only) 1644 2 = Register Stop (PIM-SM only) 1645 3 = Join/Prune 1646 4 = Bootstrap (PIM-SM only) 1647 5 = Assert 1648 6 = Graft 1649 7 = Graft Ack 1650 8 = Candidate RP Advertisement (PIM-SM only) 1651 9 = State Refresh 1653 Reserved 1654 Set to zero on transmission. Ignored upon receipt. 1656 Checksum 1657 The checksum is standard IP checksum, i.e. the 16 bit one's complement 1658 of the one's complement sum of the entire PIM message. For computing 1659 checksum, the checksum field is zeroed. 1661 For IPv6, the checksum also includes the IPv6 "pseudo-header", as 1662 specified in RFC 2460, section 8.1 [13]. 1664 4.7.2. Encoded Unicast Address 1666 An Encoded Unicast Address has the following format: 1668 0 1 2 3 1669 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 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 | Addr Family | Encoding Type | Unicast Address 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1674 Addr Family 1675 The PIM Address Family of the 'Unicast Address' field of this address. 1676 Values of 0-127 are as assigned by the IANA for Internet Address 1677 Families in [6]. Values 128-250 are reserved to be assigned by the 1678 IANA for PIM specific Address Families. Values 251-255 are designated 1679 for private use. As there is no assignment authority for this space, 1680 collisions should be expected. 1682 Encoding Type 1683 The type of encoding used with a specific Address Family. The value 1684 '0' is reserved for this field, and represents the native encoding of 1685 the Address Family 1687 Unicast Address 1688 The unicast address as represented by the given Address Family and 1689 Encoding Type. 1691 4.7.3. Encoded Group Address 1693 An Encoded Group address has the following format: 1695 0 1 2 3 1696 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 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Group Multicast Address 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1703 Addr Family 1704 As described above. 1706 Encoding Type 1707 As described above. 1709 B 1710 Indicates the group range should use Bidirectional PIM [14]. 1711 Transmitted as zero, ignored upon receipt. 1713 Reserved 1714 Transmitted as zero. Ignored upon receipt. 1716 Z 1717 Indicates the group range is an admin scope zone. This is used in the 1718 Bootstrap Router Mechanism [15] only. For all other purposes, this bit 1719 is set to zero and ignored on receipt. 1721 Mask Len 1722 The mask length field is 8 bits. The value is the number of 1723 contiguous on bits left justified used as a mask, which combined with 1724 the address, describes a range of addresses. It is less than or equal 1725 to the address length in bits for the given Address Family and 1726 Encoding Type. If the message is sent for a single address then the 1727 mask length MUST equal the address length. PIM-DM routers MUST only 1728 send for a single address. 1730 Group Multicast Address 1731 The address of the multicast group. 1733 4.7.4. Encoded Source Address 1735 An Encoded Source address has the following format: 1737 0 1 2 3 1738 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 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | Source Address 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1745 Addr Family 1746 As described above. 1748 Encoding Type 1749 As described above. 1751 Rsrvd 1752 Reserved. Transmitted as zero. Ignored upon receipt. 1754 S 1755 The Sparse Bit. Set to 0 for PIM-DM. Ignored upon receipt. 1757 W 1758 The Wild Card Bit. Set to 0 for PIM-DM. Ignored upon receipt. 1760 R 1761 The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon 1762 receipt. 1764 Mask Len 1765 As described above. PIM-DM routers MUST only send for a single 1766 source address. 1768 Source Address 1769 The source address. 1771 4.7.5. Hello Message Format 1773 The PIM Hello message has the following format: 1775 0 1 2 3 1776 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 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 |PIM Ver| Type | Reserved | Checksum | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Option Type | Option Length | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Option Value | 1783 | ... | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 | . | 1786 | . | 1787 | . | 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | Option Type | Option Length | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Option Value | 1792 | ... | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 PIM Ver, Type, Reserved, Checksum 1796 Described above. 1798 Option Type 1799 The type of option given in the Option Value field. Available types 1800 are: 1801 0 Reserved 1802 1 Hello Hold Time 1803 2 LAN Prune Delay 1804 3-16 Reserved 1805 17 To be assigned by IANA 1806 18 Deprecated and SHOULD NOT be used 1807 19 DR Priority (PIM-SM Only) 1808 20 Generation ID 1809 21 State Refresh Capable 1810 22 Bidir Capable 1811 23-65000 To be assigned by IANA 1812 65001-65535 Reserved for Private Use [7] 1813 Unknown options SHOULD be ignored. 1815 4.7.5.1. Hello Hold Time Option 1817 0 1 2 3 1818 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 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 | Type = 1 | Length = 2 | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | Hold Time | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 Hold Time is the number of seconds a receiver MUST keep the neighbor 1826 reachable. If the Hold Time is set to '0xffff', the receiver of this 1827 message never times out the neighbor. This may be used with dial-on- 1828 demand links, to avoid keeping the link up with periodic Hello messages. 1829 Furthermore, if the Holdtime is set to '0', the information is timed out 1830 immediately. The Hello Hold Time option MUST be used by PIM-DM routers. 1832 4.7.5.2. LAN Prune Delay Option 1834 0 1 2 3 1835 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 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | Type = 2 | Length = 4 | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 |T| LAN Prune Delay | Override Interval | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 The LAN_Prune_Delay option is used to tune the prune propagation delay 1843 on multi-access LANs. The T bit is used by PIM-SM and SHOULD be set to 0 1844 by PIM-DM routers and ignored upon receipt. The LAN Delay and Override 1845 Interval fields are time intervals in units of milliseconds and are used 1846 to tune the value of the J/P Override Interval and its derived timer 1847 values. Section 4.3.5 describes how these values affect the behavior of 1848 a router. The LAN Prune Delay SHOULD be used by PIM-DM routers. 1850 4.7.5.3. Generation ID Option 1852 0 1 2 3 1853 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | Type = 20 | Length = 4 | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Generation ID | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 Generation ID is a random value for the interface on which the Hello 1861 message is sent. The Generation ID is regenerated whenever PIM 1862 forwarding is started or restarted on the interface. The Generation ID 1863 option MAY be used by PIM-DM routers. 1865 4.7.5.4. State Refresh Capable Option 1867 0 1 2 3 1868 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 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | Type = 21 | Length = 4 | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | Version = 1 | Interval | Reserved | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 The Interval field is the router's configured State Refresh Interval in 1876 seconds. The Reserved field is set to zero and ignored upon reception. 1877 The State Refresh Capable option MUST be used by State Refresh capable 1878 PIM-DM routers. 1880 4.7.6. Join/Prune Message Format 1882 PIM Join/Prune messages have the following format: 1884 0 1 2 3 1885 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 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 |PIM Ver| Type | Reserved | Checksum | 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 | Upstream Neighbor Address (Encoded Unicast Format) | 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | Reserved | Num Groups | Hold Time | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | Multicast Group Address 1 (Encoded Group Format) | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | Number of Joined Sources | Number of Pruned Sources | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | Joined Source Address 1 (Encoded Source Format) | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | . | 1901 | . | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | Joined Source Address n (Encoded Source Format) | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Pruned Source Address 1 (Encoded Source Format) | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | . | 1908 | . | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Pruned Source Address n (Encoded Source Format) | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | . | 1913 | . | 1914 | . | 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 | Multicast Group Address m (Encoded Group Format) | 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 | Number of Joined Sources | Number of Pruned Sources | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Joined Source Address 1 (Encoded Source Format) | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | . | 1923 | . | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 | Joined Source Address n (Encoded Source Format) | 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | Pruned Source Address 1 (Encoded Source Format) | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | . | 1930 | . | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Pruned Source Address n (Encoded Source Format) | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 PIM Ver, Type, Reserved, Checksum 1936 Described above. 1938 Upstream Neighbor Address 1939 The address of the upstream neighbor. The format for this address is 1940 given in the Encoded Unicast address in section 4.7.2. PIM-DM routers 1941 MUST set this field to the RPF next hop. 1943 Reserved 1944 Transmitted as zero. Ignored upon receipt. 1946 Hold Time 1947 The number of seconds a receiving PIM-DM router MUST keep a Prune 1948 state alive, unless removed by a Join or Graft message. If the Hold 1949 Time is '0xffff', the receiver MUST NOT remove the Prune state unless 1950 a corresponding Join or Graft message is received. The Hold Time is 1951 ignored in Join messages. 1953 Number of Groups 1954 Number of multicast group sets contained in the message. 1956 Multicast Group Address 1957 The multicast group address in the Encoded Multicast address format 1958 given in section 4.7.3. 1960 Number of Joined Sources 1961 Number of Join source addresses listed for a given group. 1963 Number of Pruned Sources 1964 Number of Prune source addresses listed for a given group. 1966 Join Source Address 1..n 1967 This list contains the sources from which the sending router wishes to 1968 continue to receive multicast messages for the given group on this 1969 interface. The addresses use the Encoded Source address format given 1970 in section 4.7.4. 1972 Prune Source Address 1..n 1973 This list contains the sources from which the sending router does not 1974 wish to receive multicast messages for the given group on this 1975 interface. The addresses use the Encoded Source address format given 1976 in section 4.7.4. 1978 4.7.7. Assert Message Format 1980 PIM Assert Messages have the following format: 1982 0 1 2 3 1983 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 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 |PIM Ver| Type | Reserved | Checksum | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | Multicast Group Address (Encoded Group Format) | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | Source Address (Encoded Unicast Format) | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 |R| Metric Preference | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Metric | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 PIM Ver, Type, Reserved, Checksum 1996 Described above. 1998 Multicast Group Address 1999 The multicast group address in the Encoded Multicast address format 2000 given in section 4.7.3. 2002 Source Address 2003 The source address in the Encoded Source address format given in 2004 section 4.7.4. 2006 R 2007 The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon 2008 receipt. 2010 Metric Preference 2011 The preference value assigned to the unicast routing protocol that 2012 provided the route to the source. 2014 Metric 2015 The cost metric of the unicast route to the source. The metric is in 2016 units applicable to the unicast routing protocol used. 2018 4.7.8. Graft Message Format 2020 PIM Graft messages use the same format as Join/Prune messages except the 2021 Type field is set to 6. The source address MUST be in the Join section 2022 of the message. The Hold Time field SHOULD be zero and SHOULD be 2023 ignored when a Graft is received. 2025 4.7.9. Graft Ack Message Format 2027 PIM Graft Ack messages are identical in format to the received Graft 2028 message except the Type field is set to 7. The Upstream Neighbor 2029 Address field SHOULD be set to the sender of the Graft message and 2030 SHOULD be ignored upon receipt. 2032 4.7.10. State Refresh Message Format 2034 PIM State Refresh Messages have the following format: 2036 0 1 2 3 2037 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 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 |PIM Ver| Type | Reserved | Checksum | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Multicast Group Address (Encoded Group Format) | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | Source Address (Encoded Unicast Format) | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | Originator Address (Encoded Unicast Format) | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 |R| Metric Preference | 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | Metric | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | Masklen | TTL |P|N|O|Reserved | Interval | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 PIM Ver, Type, Reserved, Checksum 2055 Described above. 2057 Multicast Group Address 2058 The multicast group address in the Encoded Multicast address format 2059 given in section 4.7.3. 2061 Source Address 2062 The address of the data source in the Encoded Source address format 2063 given in section 4.7.4. 2065 Originator Address 2066 The address of the first hop router in the Encoded Source address 2067 format given in section 4.7.4. 2069 R 2070 The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon 2071 receipt. 2073 Metric Preference 2074 The preference value assigned to the unicast routing protocol that 2075 provided the route to the source. 2077 Metric 2078 The cost metric of the unicast route to the source. The metric is in 2079 units applicable to the unicast routing protocol used. 2081 Masklen 2082 The length of the address mask of the unicast route to the source. 2084 TTL 2085 Time To Live of the State Refresh message. Decremented each time the 2086 message is forwarded. Note that this is different from the IP Header 2087 TTL, which is always set to 1. 2089 P 2090 Prune indicator flag. This MUST be set to 1 if the State Refresh is 2091 to be sent on a Pruned interface. Otherwise, it MUST be set to 0. 2093 N 2094 Prune Now flag. This SHOULD be set to 1 by the State Refresh 2095 originator on every third State Refresh message and SHOULD be ignored 2096 upon receipt. This is for compatibility with earlier versions of 2097 state refresh. 2099 O 2100 Assert Override flag. This SHOULD be set to 1 by upstream routers on 2101 a LAN if the Assert Timer (AT(S,G)) is not running and SHOULD be 2102 ignored upon receipt. This is for compatibility with earlier versions 2103 of state refresh. 2105 Reserved 2106 Set to zero and ignored upon receipt. 2108 Interval 2109 Set by the originating router to the interval (in seconds) between 2110 consecutive State Refresh messages for this (S,G) pair. 2112 4.8. PIM-DM Timers 2114 PIM-DM maintains the following timers. All timers are countdown timers 2115 - they are set to a value and count down to zero, at which point they 2116 typically trigger an action. Of course they can just as easily be 2117 implemented as count-up timers, where the absolute expiry time is stored 2118 and compared against a real-time clock, but the language in this 2119 specification assumes that they count downwards towards zero. 2121 Global Timers 2122 Hello Timer: HT 2124 Per interface (I): 2125 Per neighbor (N): 2126 Neighbor Liveness Timer: NLT(N,I) 2128 Per (S,G) Pair: 2129 (S,G) Assert Timer: AT(S,G,I) 2130 (S,G) Prune Timer: PT(S,G,I) 2131 (S,G) PrunePending Timer: PPT(S,G,I) 2133 Per (S,G) Pair: 2134 (S,G) Graft Retry Timer: GRT(S,G) 2135 (S,G) Upstream Override Timer: OT(S,G) 2136 (S,G) Prune Limit Timer: PLT(S,G) 2137 (S,G) Source Active Timer: SAT(S,G) 2138 (S,G) State Refresh Timer: SRT(S,G) 2140 When timer values are started or restarted, they are set to default 2141 values. The following tables summarize those default values. 2143 Timer Name: Hello Timer (HT) 2144 +----------------------+--------+--------------------------------------+ 2145 | Value Name | Value | Explanation | 2146 +----------------------+--------+--------------------------------------+ 2147 |Hello_Period | 30 sec | Periodic interval for hello messages | 2148 +----------------------+--------+--------------------------------------+ 2149 |Triggered_Hello_Delay | 5 sec | Random interval for initial Hello | 2150 | | | message on bootup or triggered Hello | 2151 | | | message to a rebooting neighbor | 2152 +----------------------+--------+--------------------------------------+ 2154 Hello message are sent on every active interface once every Hello_Period 2155 seconds. At system power-up, the timer is initialized to 2156 rand(0,Triggered_Hello_Delay) to prevent synchronization. When a new or 2157 rebooting neighbor is detected, a responding Hello is sent within 2158 rand(0,Triggered_Hello_Delay). 2160 Timer Name: Neighbor Liveness Timer (NLT(N,I)) 2161 +-------------------+-----------------+--------------------------------+ 2162 | Value Name | Value | Explanation | 2163 +-------------------+-----------------+--------------------------------+ 2164 | Hello Holdtime | From message | Hold Time from Hello Message | 2165 +-------------------+-----------------+--------------------------------+ 2167 Timer Name: PrunePending Timer (PPT(S,G,I)) 2168 +-----------------------+---------------+------------------------------+ 2169 | Value Name | Value | Explanation | 2170 +-----------------------+---------------+------------------------------+ 2171 | J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to | 2172 | | | allow other routers on the | 2173 | | | LAN to send a Join | 2174 +-----------------------+---------------+------------------------------+ 2176 The J/P_Override_Interval is the sum of the interface's 2177 Override_Interval (OI(I)) and Propagation_Delay (PD(I)). If all routers 2178 on a LAN are using the LAN Prune Delay option, both parameters MUST be 2179 set to the largest value on the LAN. Otherwise, the Override_Interval 2180 (OI(I)) MUST be set to 2.5 seconds and the Propagation_Delay (PD(I)) 2181 MUST be set to 0.5 seconds. 2183 Timer Name: Prune Timer (PT(S,G,I)) 2184 +----------------+----------------+------------------------------------+ 2185 | Value Name | Value | Explanation | 2186 +----------------+----------------+------------------------------------+ 2187 | Prune Holdtime | From message | Hold Time read from Prune Message | 2188 +----------------+----------------+------------------------------------+ 2190 Timer Name: Assert Timer (AT(S,G,I)) 2191 +--------------------------+---------+---------------------------------+ 2192 | Value Name | Value | Explanation | 2193 +--------------------------+---------+---------------------------------+ 2194 | Assert Time | 180 sec | Period after last assert before | 2195 | | | assert state is timed out | 2196 +--------------------------+---------+---------------------------------+ 2198 Note that for historical reasons, the Assert message lacks a Holdtime 2199 field. Thus changing the Assert Time from the default value is not 2200 recommended. If all members of a LAN are state refresh enabled, the 2201 Assert Time will be three times the received RefreshInterval(S,G). 2203 Timer Name: Graft Retry Timer (GRT(S,G)) 2204 +--------------------+-------+-----------------------------------------+ 2205 | Value Name | Value | Explanation | 2206 +--------------------+-------+-----------------------------------------+ 2207 | Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck | 2208 | | | message, the time before retransmission | 2209 | | | of a Graft message | 2210 +--------------------+-------+-----------------------------------------+ 2212 Timer Name: Upstream Override Timer (OT(S,G)) 2213 +------------+----------------+----------------------------------------+ 2214 | Value Name | Value | Explanation | 2215 +------------+----------------+----------------------------------------| 2216 | t_override | rand(0, OI(I)) | Randomized delay to prevent response | 2217 | | | implosion when sending a join message | 2218 | | | to override someone else's prune | 2219 +------------+----------------+----------------------------------------+ 2221 t_override is a random value between 0 and the interface's 2222 Override_Interval (OI(I)). If all routers on a LAN are using the LAN 2223 Prune Delay option, the Override_Interval (OI(I)) MUST be set to the 2224 largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST 2225 be set to 2.5 seconds. 2227 Timer Name: Prune Limit Timer (PLT(S,G)) 2228 +------------+--------------------+------------------------------------+ 2229 | Value Name | Value | Explanation | 2230 +------------+--------------------+------------------------------------| 2231 | t_limit | Equal to the Prune | Used to prevent Prune storms on a | 2232 | | Holdtime sent | LAN | 2233 +------------+--------------------+------------------------------------+ 2234 Timer Name: Source Active Timer (SAT(S,G)) 2235 +----------------+-------------------+---------------------------------+ 2236 | Value Name | Value | Explanation | 2237 +----------------+-------------------+---------------------------------+ 2238 | SourceLifetime | Default: 210 secs | Period of time after receiving | 2239 | | | a multicast message a directly | 2240 | | | attached router will continue | 2241 | | | to send State Refresh messages | 2242 +----------------+-------------------+---------------------------------+ 2244 Timer Name: State Refresh Timer (SRT(S,G)) 2245 +-----------------+------------------+---------------------------------+ 2246 | Value Name | Value | Explanation | 2247 +-----------------+------------------+---------------------------------+ 2248 | RefreshInterval | Default: 60 secs | Interval between successive | 2249 | | | state refresh messages | 2250 +-----------------+------------------+---------------------------------+ 2252 5. Protocol Interaction Considerations 2254 PIM-DM is designed to be independent of underlying unicast routing 2255 protocols and will interact only to the extent needed to perform RPF 2256 checks. It is generally assumed that multicast area and autonomous 2257 system boundaries will correspond to the same boundaries for unicast 2258 routing, though a deployment which does not follow this assumption is 2259 not precluded by this specification. 2261 In general, PIM-DM interactions with other multicast routing protocols 2262 should be in compliance with RFC 2715 [11]. Other specific 2263 interactions are noted below. 2265 5.1. PIM-SM Interactions 2267 PIM-DM is not intended to interact directly with PIM-SM, even though 2268 they share a common packet format. It is particularly important to note 2269 that a router cannot differentiate between a PIM-DM neighbor and a 2270 PIM-SM neighbor based on Hello messages. 2272 In the event that a PIM-DM router becomes a neighbor of a PIM-SM router 2273 they will effectively form a simplex link with the PIM-DM router sending 2274 all multicast messages to the PIM-SM router while the PIM-SM router 2275 sends no multicast messages to the PIM-DM router. 2277 The common packet format permits a hybrid PIM-SM/DM implementation that 2278 would use PIM-SM when a rendezvous point is known and PIM-DM when one is 2279 not. Such an implementation is outside the scope of this document. 2281 5.2. IGMP Interactions 2283 PIM-DM will forward received multicast data packets to neighboring host 2284 group members in all cases except when the PIM-DM router is in an Assert 2285 Loser state on that interface. Note that a PIM Prune message is not 2286 permitted to prevent the delivery of messages to a network with group 2287 members. 2289 A PIM-DM Router MAY use the DR Priority option described in PIM-SM [3] 2290 to elect an IGMP v1 querier. 2292 5.3. Source Specific Multicast (SSM) Interactions 2294 PIM-DM makes no special considerations for SSM [9]. All Prunes and 2295 Grafts within the protocol are for a specific source, so no additional 2296 checks need be made. 2298 5.4. Multicast Group Scope Boundary Interactions 2300 While multicast group scope boundaries are generally identical to 2301 routing area boundaries, it is conceivable that a routing area might be 2302 partitioned for a particular multicast group. PIM-DM routers MUST NOT 2303 send any messages concerning a particular group across that group's 2304 scope boundary. 2306 6. IANA Considerations 2308 6.1. PIM Address Family 2310 The PIM Address Family field was chosen to be 8 bits as a tradeoff 2311 between packet format and use of the IANA assigned numbers. When the 2312 PIM packet format was designed, only 15 values were assigned for Address 2313 Families and large numbers of new Address Families were not envisioned, 2314 8 bits seemed large enough. However, the IANA assigns Address Families 2315 in a 16 bit value. Therefore, the PIM Address Family is allocated as 2316 follows: 2318 Values 0 through 127 are designated to have the same meaning as IANA 2319 assigned Address Family Numbers [6]. 2321 Values 128 through 250 are designated to be assigned by the IANA based 2322 upon IESG approval as defined in [7]. 2324 Values 251 through 255 are designated for Private Use, as defined in 2325 [7]. 2327 6.2. PIM Hello Options 2329 Values 17 through 65000 are to be assigned by the IANA. Since the space 2330 is large, they may be assigned as First Come First Served as defined in 2331 [7]. Such assignments are valid for one year, and may be renewed. 2332 Permanent assignments require a specification as defined in [7]. 2334 7. Security Considerations 2336 The IPsec authentication header [8] MAY be used to provide data 2337 integrity protection and groupwise data origin authentication of PIM 2338 protocol messages. Authentication of PIM messages can protect against 2339 unwanted behaviors caused by unauthorized or altered PIM messages. In 2340 any case, a PIM router SHOULD NOT accept and process PIM messages from 2341 neighbors unless a valid Hello message has been received from that 2342 neighbor. 2344 We should note that PIM-DM has no rendezvous point, and therefore no 2345 single point of failure that may be vulnerable. It is further worth 2346 noting that because PIM-DM uses unicast routes provided by an unknown 2347 routing protocol, it may suffer collateral effects if the unicast 2348 routing protocol is attacked. 2350 7.1. Attacks Based on Forged Messages 2352 The extent of possible damage depends on the type of counterfeit 2353 messages accepted. We next consider the impact of possible forgeries. A 2354 forged PIM-DM message is link local, and can only reach a LAN if it was 2355 sent by a local host or if it was allowed onto the LAN by a compromised 2356 or non-compliant router. 2358 1. A forged a Hello message can cause multicast traffic to be delivered 2359 to links where there are no legitimate requestors, potentially 2360 wasting bandwidth on that link. On a multi-access LAN, the effects 2361 are limited without the capability to forge a Join message since 2362 other routers will Prune the link if the traffic is not desired. 2364 2. A forged Join/Prune message can cause multicast traffic to be 2365 delivered to links where there are no legitimate requestors, 2366 potentially wasting bandwidth on that link. A forged Prune message 2367 on a multi-access LAN is generally not a significant attack in PIM, 2368 because any legitimately joined router on the LAN would override the 2369 Prune with a Join before the upstream router stops forwarding data 2370 to the LAN. 2372 3. A forged Graft message can cause multicast traffic to be delivered to 2373 links where there are no legitimate requestors, potentially wasting 2374 bandwidth on that link. In principle, Graft messages could be sent 2375 multiple hops since they are unicast to the upstream router. This 2376 should not be a problem since the remote forger should have no way 2377 to get a Hello message to the target of the attack. Without a valid 2378 Hello message, the receiving router SHOULD NOT accept the Graft. 2380 4. A forged GraftAck message has no impact since it will be ignored 2381 unless the router has recently sent a Graft to its upstream router. 2383 5. By forging an Assert message on a multi-access LAN, an attacker could 2384 cause the legitimate forwarder to stop forwarding traffic to the LAN. 2385 Such a forgery would prevent any hosts downstream of that LAN from 2386 receiving traffic. 2388 6. A forged State Refresh message on a multi-access LAN would have the 2389 same impact as a forged Assert message, having the same general 2390 functions. In addition, forged State Refresh messages would be 2391 propagated downstream and might be used in a denial of service 2392 attack. Therefore, a PIM-DM router SHOULD rate limit State Refresh 2393 messages propagated. 2395 7.2. Non-cryptographic Authentication Mechanisms 2397 A PIM-DM router SHOULD provide an option to limit the set of neighbors 2398 from which it will accept PIM-DM messages. Either static configuration 2399 of IP addresses or an IPSec security association may be used. All 2400 options that restrict the range of addresses from which packets are 2401 accepted MUST default to allowing all packets. 2403 Furthermore, a PIM router SHOULD NOT accept protocol messages from a 2404 router from which it has not yet received a valid Hello message. 2406 7.3. Authentication Using IPsec 2408 The IPSec [8] transport mode using the Authentication Header (AH) is the 2409 recommended method to prevent the above attacks in PIM. The specific AH 2410 authentication algorithm and parameters, including the choice of 2411 authentication algorithm and the choice of key, are configured by the 2412 network administrator. The Encapsulating Security Payload (ESP) MAY also 2413 be used to provide both encryption and authentication of PIM protocol 2414 messages. When IPsec authentication is used, a PIM router SHOULD reject 2415 (drop without processing) any unauthorized PIM protocol messages. 2417 To use IPSec, the administrator of a PIM network configures each PIM 2418 router with one or more Security Associations and associated SPI(s) that 2419 are used by senders to sign PIM protocol messages and are used by 2420 receivers to authenticate received PIM protocol messages. This document 2421 does not describe protocols for establishing Security Associations. It 2422 assumes that manual configuration of Security Associations is performed, 2423 but it does not preclude the use of some future negotiation protocol 2424 such as GDOI [15] to establish Security Associations. 2426 The network administrator defines a Security Association (SA) and 2427 Security Parameters Index (SPI) that is to be used to authenticate all 2428 PIM-DM protocol messages from each router on each link in a PIM-DM 2429 domain. 2431 Note that if the same SA is used by different sending routers on 2432 the same link, it will not be possible to authenticate the individual 2433 sender precisely and anti-replay mechanisms would prevent the 2434 acceptance of legitimate PIM-DM messages, so IPSec's Replay Protection 2435 would need to be disabled. 2437 The Security Policy Database at a PIM-DM router should be configured to 2438 ensure that all incoming and outgoing PIM-DM packets use the SA 2439 associated with the interface to which the packet is sent. Note that, 2440 according to [8], there is nominally a different Security Association 2441 Database (SAD) for each router interface. Thus, the selected Security 2442 Association for an inbound PIM-DM packet can vary depending on the 2443 interface on which the packet arrived. This fact allows the network 2444 administrator to use different authentication methods for each link, 2445 even though the destination address is the same for most PIM-DM packets, 2446 regardless of interface. 2448 7.4. Denial of Service Attacks 2450 There are a number of possible denial of service attacks against PIM 2451 that can be caused by generating false PIM protocol messages or even by 2452 generating false data traffic. Authenticating PIM protocol traffic 2453 prevents some, but not all of these attacks. The possible attacks 2454 include: 2456 * Sending packets to many different group addresses quickly can be a 2457 denial of service attack in and of itself. These messages will 2458 initially be flooded throughout the network before they are pruned 2459 back. The maintenance of state machines and State Refresh messages 2460 will be a continual drain on network resources. 2462 * Forged State Refresh messages sent quickly could be propagated by 2463 downstream routers, creating a potential denial of service attack. 2464 Therefore, a PIM-DM router SHOULD rate limit State Refresh messages 2465 propagated. 2467 8. Authors' Addresses 2469 Andrew Adams 2470 NextHop Technologies 2471 825 Victors Way, Suite 100 2472 Ann Arbor, MI 48108-2738 2473 ala@nexthop.com 2475 Jonathan Nicholas 2476 ITT Industries 2477 Aerospace/Communications Division 2478 100 Kingsland Rd 2479 Clifton, NJ 07014 2480 jonathan.nicholas@itt.com 2482 William Siadak 2483 NextHop Technologies 2484 825 Victors Way, Suite 100 2485 Ann Arbor, MI 48108-2738 2486 wfs@nexthop.com 2488 9. Acknowledgments 2490 The major features of PIM-DM were originally designed by Stephen 2491 Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy, 2492 David Meyer, and Liming Wei. Additional features for state refresh 2493 were designed by Dino Farinacci, Isidor Kouvelas and Kurt Windisch. 2494 This revision was undertaken to incorporate some of the lessons learned 2495 during the evolution of the PIM-SM specification and early deployments 2496 of PIM-DM. 2498 Thanks the PIM Working Group for their comments. 2500 10. References 2502 [1] S.E. Deering, "Multicast Routing in a Datagram Internetwork", 2503 Ph.D. Thesis, Electrical Engineering Dept., Stanford University, 2504 December 1991. 2506 [2] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast 2507 Routing Protocol", November 1988, RFC 1075 2509 [3] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol 2510 Independent Multicast - Sparse Mode (PIM-SM)", 2511 draft-ietf-pim-sm-v2-new-06.txt, work in progress. 2513 [4] S.E. Deering, "Host Extensions for IP Multicasting", August 1989, 2514 RFC 1112. 2516 [5] W.Fenner, "Internet Group Management Protocol, Version 2", 2517 November 1997, RFC 2236. 2519 [6] IANA, "Address Family Numbers", linked from 2520 http://www.iana.org/numbers.html. 2522 [7] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 2523 Considerations Section in RFCs", October 1998, RFC 2434. 2525 [8] S. Kent, R. Atkinson, "Security Architecture for the Internet 2526 Protocol", November 1998, RFC 2401. 2528 [9] H.Holbrook, B. Cain, "Source Specific Multicast for IP", 2529 draft-ietf-ssm-arch-01.txt, work in progress. 2531 [10] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, 2532 "Internet Group Management Protocol, Version 3", 2533 October 2002, RFC 3376. 2535 [11] D. Thaler, "Interoperability Rules for Multicast Routing 2536 Protocols", October 1999, RFC 2715 2538 [12] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol 2539 Independent Multicast MIB for IPv4", October 2000, RFC 2934 2541 [13] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 2542 Specification", December 1998, RFC 2460. 2544 [14] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional 2545 Protocol Independent Multicast", draft-ietf-pim-bidir-04.txt, 2546 work in progress. 2548 [15] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group Domain of 2549 Interpretation", draft-ietf-msec-gdoi-07.txt, work in progress.