idnits 2.17.1 draft-ietf-idmr-pim-sm-spec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) 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) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-idmr-PIM-SM-spec-00', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-ietf-idmr-PIM-SM-spec-00', but the file name used is 'draft-ietf-idmr-pim-sm-spec-00' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 63 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 893 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 18 has weird spacing: '... Drafts are ...' == Line 19 has weird spacing: '...cuments of t...' == Line 20 has weird spacing: '...ups may also ...' == Line 24 has weird spacing: '... Drafts may ...' == Line 25 has weird spacing: '...iate to use ...' == (888 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (Sept 7, 1995) is 10734 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 42 looks like a reference -- Missing reference section? '2' on line 73 looks like a reference -- Missing reference section? '3' on line 71 looks like a reference -- Missing reference section? '4' on line 71 looks like a reference -- Missing reference section? '5' on line 1678 looks like a reference -- Missing reference section? '6' on line 122 looks like a reference -- Missing reference section? '7' on line 663 looks like a reference -- Missing reference section? '8' on line 2297 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steven Deering (XEROX) 3 Internet Draft Deborah Estrin (USC) 4 Dino Farinacci (CISCO) 5 Van Jacobson (LBL) 6 Chinggung Liu (USC) 7 Liming Wei (USC) 8 Puneet Sharma (USC) 9 Ahmed Helmy (USC) 11 draft-ietf-idmr-PIM-SM-spec-00.txt Sept 7, 1995 13 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 14 Specification 16 Status of This Memo 18 This document is an Internet Draft. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its Areas, 20 and its Working Groups. (Note that other groups may also distribute 21 working documents as Internet Drafts). 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a 27 ``working'' draft'' or ``work in progress.'' 29 Please check the I-D abstract listing contained in each Internet 30 Draft directory to learn the current status of this or any other 31 Internet Draft. 33 1 Introduction 35 This document describes a protocol for efficiently routing to 36 multicast groups that may span wide-area (and inter-domain) 37 internets. We refer to the approach as Protocol Independent 38 Multicast--Sparse Mode (PIM-SM) because it is not dependent on any 39 particular unicast routing protocol, and because it is designed to 40 support sparse groups as defined in [1]. This document describes the 41 protocol details. For the motivation behind the design and a 42 description of the architecture, see [1]. Section 2 summarizes PIM- 43 SM operation. It describes the protocol from a network perspective, 44 in particular, how the participating routers interact to create and 45 maintain the multicast distribution tree. Section 3 describes PIM-SM 46 operations from the perspective of a single router implementing the 47 protocol; this section constitutes the main body of the protocol 48 specification. It is organized according to PIM-SM message type; for 49 each message type we describe its contents, its generation, and its 50 processing. Interoperability with other protocols is discussed in a 51 separate [2]. Section 4 provides packet format details and section 52 5 provides pseudocode that corresponds to the functions described in 53 section 3. The pseudocode is just for illustration, Section 4 is 54 authoritative. 56 The most significant functional changes since the January spec are 57 the RP-related mechanisms (for completeness) and the removal of the 58 PIM-DM protocol details to a separate [3] (for clarity). We rewrote 59 major portions for clarity and updated the packet formats 60 extensively. 62 The bibliography, pseudocode, and figures are all in preparation. 64 2 PIM-SM Protocol Overview 66 In this section we provide an overview of the architectural 67 components of PIM-SM. PIM-SM protocols operate on group addresses 68 taken from the Sparse portion of the multicast address space. [*] 70 _________________________ 71 [*] Non-SM group addresses may be treated using PIM-DM[3], DVMRP[4], or a 72 locally-configured default RP-list in conjunction with the PIM-SM 73 mechanisms described here. See [2] for more details of the latter. 75 A PIM-SM router receives explicit join messages from those 76 neighboring routers that have downstream group members. The PIM-SM 77 router then forwards data packets addressed to a multicast group, G, 78 only onto those interfaces on which explicit joins have been 79 received. 81 A Designated Router (DR) sends PIM-SM Join/Prune messages toward a 82 group-specific Rendezvous Point (RP) for each group for which it has 83 active members. Each router along the path toward the RP builds 84 wildcard (any-source) forwarding state for the group and sends 85 Join/Prune messages on toward the RP. The wildcard forwarding entry's 86 incoming interface points toward the RP; the outgoing interfaces 87 point to the neighboring downstream routers that have sent Join/Prune 88 messages toward the RP. This forwarding state creates a shared, RP- 89 centered, distribution tree that reaches all group members. When a 90 data source first sends to a group its DR unicasts Register messages 91 to the RP with the source's data packets encapsulated within. If the 92 data rate is high, the RP will send source-specific Join/Prune 93 messages back towards the source and the source's data packets will 94 follow the resulting forwarding state and travel unencapsulated to 95 the RP. Whether they arrive encapsulated or natively, the RP forwards 96 the source's decapsulated data packets down the RP-centered 97 distribution tree toward group members. If the data rate warrants it, 98 routers with local receivers can join a source-specific, shortest 99 path, distribution tree, and prune these source's packets off of the 100 shared RP-centered tree. Even if all receivers switch to the shortest 101 path tree, state for that source will be kept at the RP, so that new 102 members that join the RP-centered tree will receive data packets from 103 the source. For low data rate sources, neither the RP, nor last hop 104 routers need join a source-specific shortest path tree and data 105 packets can be delivered via the shared, RP-tree. 107 The following subsections describe SM operation in more detail, in 108 particular, the control messages that travel up and down the 109 distribution tree, and the actions they trigger. Section 3 describes 110 protocol operation from an implementors perspective, i.e., the 111 actions performed by a single PIM-SM router. 113 2.1 Local hosts joining a group 115 In order to join a multicast group, G, a host sends an IGMP Host- 116 Report message identifying the particular group. As specified in [5], 117 IGMP Host-Report messages are sent in response to a directly- 118 connected router's IGMP Host-Query message (see figure 1). From this 119 point on we refer to such a host as a receiver, R, (or member) of the 120 group G. The host also responds with an IGMP RP-Report message 121 identifying the (small) list of RPs associated with the group, 122 referred to as [6] 123 Fig. 1 Example: how a receiver joins, and sets up shared tree 125 When a DR receives a report for a new group, G, the DR will determine 126 based on the multicast address whether the group is a Sparse Mode 127 group; a specific portion of the multicast address space is being 128 allocated to Sparse Mode groups. If the group is SM the DR looks up 129 the associated RP-list, (see section 2.6), and selects the primary 130 RP. The DR (e.g., router A in figure 1) creates a wildcard multicast 131 forwarding entry for the group, referred to here as a (*,G) entry. 133 The RP address is included in a special record in the forwarding 134 entry, so that it will be included in upstream Join/Prune messages. 135 The outgoing interface is set to that over which the IGMP Host-Report 136 was received from the new member. The incoming interface is set to 137 the interface used to send unicast packets to the RP. A wildcard bit 138 (WC-bit) associated with this entry is set, indicating that this is a 139 wildcard entry; if there is no more specific match for a particular 140 source, it will be forwarded according to this entry. An RP-bit 141 associated with this entry is also set, indicating that this entry, 142 (*,G), represents state on the shared, RP tree. Each router on the 143 RP-tree with directly connected members sets a timer for this entry. 144 The RP-timer is reset each time an RP-Reachability message is 145 received for (*,G), see section 2.2 [*]. If the timer expires 146 and the router has no local members, the (*,G) state is deleted. If 147 the router does have local members, it refreshes the (*,G) entry 148 timer each time it gets an IGMP membership report; then, when the 149 RP-timer expires, the router attempts to join to the next RP on the 150 RP-list. 152 2.2 Establishing the RP-rooted shared tree 154 Triggered by the (*,G) state, the DR creates a Join/Prune message 155 with the RP address in its join list and the WC-bit and RP-bit set; 156 _________________________ 157 [*] Optionally, a router without directly connected 158 members may also process RP-reachability messages and thereby timeout 159 (*,G) state more rapidly. However, this is not required for proper 160 function of the protocol since the routers with directly connected 161 members will eventually time out their entries and stop sending (*,G) 162 Join/Prune messages toward the unreachable RP. 164 nothing is listed in its prune list. The RP-bit flags the join as 165 being associated with the shared tree and therefore the Join/Prune 166 message is propagated along the RP-tree. The WC-bit indicates that 167 the address is an RP and the receiver expects to receive packets from 168 all sources via this (shared tree) path. 170 Each upstream router creates or updates its multicast forwarding 171 entry for (*,G) when it receives a Join/Prune with the RP-bit and 172 WC-bit set. The interface on which the Join/Prune message arrived is 173 added to the list of outgoing interfaces (oifs) for (*,G). Based on 174 this entry each upstream router between the receiver and the RP sends 175 a PIM-SM- Join/Prune message in which the join list includes the RP. 176 The packet payload contains Multicast-Address=G, Join=RP,WCbit,RPbit, 177 Prune=NULL. 179 When a router that is willing to act as an RP receives a (*,G) Join 180 with itself listed as the RP, the router automatically performs the 181 functions specified here for an RP (i.e., a router does not need to 182 be specially configured to act as an RP). The incoming interface 183 (iif) in the RP's (*,G) entry is set to null. RP-Reachability 184 messages are generated by the RP periodically and distributed down 185 the (*,G) tree established for the group. This allows downstream 186 routers to detect when their current RP has become unreachable and 187 trigger joining towards an alternate RP, see section 2.6. When 188 alternate RPs are used, (*,G) Join/Prune messages include the 189 complete ordered RP-list. An RP performs the functions described thus 190 far whether it is the primary RP, or an alternate; however, alternate 191 RPs have the added task of polling preferred RPs on the RP-list and 192 notifying leaf routers when a preferred RP becomes reachable. 194 2.3 Hosts sending to a group 196 To start sending packets to a group, a host responds to IGMP queries 197 from the DR with an IGMP RP-Report for that group; the IGMP message 198 is sent to the "RP-Reporters" group with a TTL of 1. All PIM hosts on 199 the LAN join this group in order to implement suppression (see figure 200 2). The DR stores the indicated RP-Group mapping. When a host first 201 sends a multicast data packet to a group, its DR must deliver the 202 packet to the RP for distribution down the RP-tree. This is done by 203 the sender's DR unicasting a PIM-SM-Register packet to the primary RP 204 for the group (see section 2.6). The data packet is encapsulated in 205 the PIM-SM-Register packet so that the RP can decapsulate it and 206 deliver it to downstream members. The RP responds to Registers with 207 explicit Register-Ack messages. These Register-Ack messages are sent 208 periodically, and provide liveness indication; their absence does not 209 trigger retransmission, it triggers the router to select an alternate 210 RP. 212 Fig. 2 Example: a host sending to a group 214 If the data rate of the source warrants the use of a source-specific 215 shortest path tree, the RP constructs (S,G) state and sends periodic 216 Join/Prune messages toward the source. The routers between the source 217 and the RP build and maintain (S,G) state in response to these 218 messages and send (S,G) messages upstream toward the source. Each 219 (S,G) state entry includes the RP-address in the RP-Annotated field 220 of the entry. S,G Join/Prune messages triggered off of that state 221 will include the RP-address. 223 The source's DR stops encapsulating data packets in PIM-SM-Registers 224 when (and so long as) it receives Join/Prune(S,G) messages from the 225 active RP (i.e., S's RP Annotated-bit is set in the join list). Even 226 if the RP does not set up (S,G) state, it still responds to the 227 source's Register messages with Register-Acks, when requested (i.e., 228 if the Ack-Request flag is set in the Register message). If the RP 229 has a (S,G,RPbit) entry or (*,G) entry with a null oif list, the RP 230 sets a no-data flag in the Register-Ack to suppress the source's DR 231 from encapsulating the sources data packets. If the RP has no state 232 at all for that group, it responds with no-data Register-Acks. To 233 deal with a failure scenario in which the primary RP is unreachable 234 for extended periods and data sources are very bursty, the DR 235 continues to send null-Register messages periodically so long as 236 directly connected sources continue to send IGMP RP-reports; this is 237 only necessary when the active RP is not the primary RP. 239 If an RP has gone down during the register process, we want to limit 240 how long we encapsulate data packets. Also, if the encapsulating 241 stops and data is forwarded via (S,G) state to the RP, it is 242 desirable to know if that RP becomes unreachable. Therefore, there is 243 an RP (liveness) timer, and an RP-status flag, kept for the active RP 244 for all active groups in the DR of each source. The RP-timer is 245 reset, and the RP-status flag is set to "reachable'' when a 246 Join/Prune with the RP address included, or a Register-Ack message, 247 is received. When the RP-timer expires (for example, 270 seconds), 248 the RP-status flag is set for that RP indicating that it is in a 249 "down" state. The actions taken when an RP is detected as being 250 unreachable are described in section 2.6. 252 2.4 Switching from shared tree (RP-tree) to shortest path tree (SP- 253 tree)} When a PIM router has directly-connected members it first 254 joins the shared RP-tree. The router can switch to a source's 255 shortest path tree (SP-tree) after receiving packets from that source 256 over the shared RP-tree. The recommended policy is to initiate the 257 switch to the SP-tree after receiving a significant number of data 258 packets during a specified time interval from a particular source. To 259 realize this policy the router monitors data packets from sources for 260 which it has no source-specific multicast forwarding entry and 261 initiates such an entry when the data rate exceeds the configured 262 threshold. As shown in figure 3, router A initiates a new multicast 263 forwarding entry that is specific to the source, hereafter referred 264 to as (S,G) state. 266 Fig. 3 Example: Switching from shared tree to shortest path tree 268 When a (S,G) entry is activated (and periodically so long as the 269 state exists), a Join/Prune message will be sent upstream towards the 270 source, S, with S in the join list. The payload contains Multicast- 271 Address=G, Join=S, Prune=NULL. When the (S,G) entry is created, the 272 outgoing interface list is copied from (*,G), i.e., all local shared 273 tree branches are replicated in the new shortest path tree. In this 274 way when a data packet from S arrives and matches on this entry, all 275 receivers will continue to receive the source's packets along this 276 path unless and until the receivers choose to prune themselves. Note 277 that (S,G) state must be maintained in all last-hop routers where an 278 SP-tree is maintained. Even when (*,G) and (S,G) overlap, both states 279 are needed to trigger the source-specific Join/Prune messages. (S,G) 280 state is kept alive by data packets arriving from that source. A 281 timer, S-timer, is set for the (S,G) entry and this timer is reset 282 whenever a data packet for (S,G) is received. When the S-timer 283 expires the state is deleted. 285 Only routers with local members can initiate switching to the SP- 286 tree; intermediate routers do not. Consequently last hop routers 287 initialize (S,G) state in response to data packets from the source, 288 S; whereas intermediate routers only initialize (S,G) state in 289 response to Join messages from downstream that have S in the Join 290 list. To implement the policy that source-specific trees are only 291 setup for high-data rate source, a last-hop router does not 292 initialize a (S,G) entry until it has received m data packets from 293 the source within some interval of n seconds. The last-hop router 294 may alternatively be configured to not request switching to the 295 shortest path tree. 297 The (S,G) entry is initialized with the SPT-bit cleared, indicating 298 that the shortest path tree branch from S has not been setup 299 completely, and the router can still accept packets from S that 300 arrive on the (*,G) entry's iif. When a router with a (S,G) entry and 301 a cleared SPT-bit starts to receive packets from the new source S on 302 the iif for the (S,G) entry, and that iif differs from the (*,G) 303 entry's iif, the router sets the SPT-bit, and sends a Join/Prune 304 message towards the RP. This indicates that the router no longer 305 wants to receive packets from S via the shared RP-tree. The 306 Join/Prune message sent towards the RP includes S in the prune list, 307 with the RP-bit set indicating that S's packets should not be 308 forwarded down this branch of the shared tree. If the router 309 receiving the Join/Prune message has (S,G) state (with or without the 310 RPbit set), it deletes the arriving interface from the (S,G) oif 311 list. If the router has only (*,G) state, it creates an (S,G,RPbit) 312 entry. The Join/Prune message payload contains Multicast-Address=G, 313 Join=NULL, Prune=S,RPbit. 315 If at a later time a new receiver joins the RP-tree, the negative 316 cache state on the RP-tree must be eradicated to bring all sources' 317 data packets down to the new receiver. Therefore, when a (*,G) Join 318 arrives with a null prune list at a router that has any (S,G,RP-bit) 319 entries (which is causing it to send source-specific prunes toward 320 the RP), all RP-bit state for that group has to be updated upstream 321 of the router; so as to bring all sources' packets down to the new 322 member. To accomplish this the router updates all existing (S,G,RP- 323 bit) entries; it adds to each (S,G,RPbit) entry's oif list the 324 interface on which the (*,G) join arrived. The router also triggers a 325 (*,G) join upstream to cause the same updating of RP-bit settings 326 upstream and pull down all active sources' packets. If the arriving 327 (*,G) join has some sources included in its prune list, then the 328 corresponding (S,G,RP-bit) entries are left unchanged (i.e., the 329 RPbit remains set and no oif is added). 331 2.5 Steady state maintenance of distribution tree (i.e., router state)} 333 In the steady state each router sends periodic Join/Prune messages 334 for each active (S,G) or (*,G) entry; the Join/Prune messages are 335 sent to the RPF neighbor on the iif of the corresponding entry. These 336 messages are sent periodically to capture state, topology, and 337 membership changes. A Join/Prune message is also sent on an event- 338 triggered basis each time a new forwarding entry is established for 339 some new source (note that some damping function may be applied, 340 e.g., a merge time). Join/Prune messages do not elicit any form of 341 explicit acknowledgment; routers recover from lost packets using the 342 periodic refresh mechanism. 344 2.6 Use of alternate RPs (i.e., Adaptation to RP unreachability) 346 For each multicast group, the group initiator selects a primary RP 347 and a small ordered set of alternate RPs; referred to as the RP-list. 349 Except for transients while adapting to failures and recoveries, only 350 a single RP is active per group at any point in time. A later 351 section, 2.7, describes a mechanism to assist group initiators in 352 selecting routers for the RP-list. This section describes the use of 353 the RP-list once it has been constructed and advertised; in 354 particular, the use of alternate RPs when the primary RP becomes 355 unreachable. 357 When a router receives (*,G) Joins indicating itself as the RP, it 358 sets up (*,G) state and periodically sends RP-reachability messages. 359 These messages traverse the shared RP tree down to last hop routers 360 who use it to reset the timers on their (*,G) state. If a DR's (*,G) 361 state timer expires, this indicates that RP-reachability messages are 362 no longer being received. This triggers the DR to send (*,G) joins 363 toward the next RP on the ordered RP list for that group. When the 364 primary RP becomes unreachable, all DRs on the shared distribution 365 tree will detect the event and switch to the same alternate RP. 366 Consequently, aside from transients, there is always a single shared 367 RP-tree with a single active RP at any point in time. The only time 368 that different receiver's DRs will take different action from one 369 another is when there is a network partition and some DRs still 370 receive reachability messages while others do not. In this case only 371 the receivers on the other side of the partition will initiate joins 372 toward the secondary RP. The (*,G) join sent toward the alternate RP 373 includes the complete ordered list of RPs for that group (for reasons 374 explained below). 376 If and when the RP becomes unreachable, sources' first hop routers 377 will stop receiving the RP's (S,G) Join or Register-Ack messages. 378 Consequently, the RP timers in the sources' first hop routers will 379 also expire. This will trigger these routers to send subsequent (S,G) 380 data packets encapsulated in Register messages to the next RP in the 381 ordered list. The Register messages include the ordered RP-list. 383 Since all new members will be joining to the preferred RP once it is 384 reachable, the senders and receivers switch back to the preferred RP 385 when it becomes reachable. To achieve this, an active, alternate RP 386 periodically polls the preferred RPs (all RPs that appear before it 387 in the ordered RP list). 388 [*] 390 When the active alternate RP finds that one of the preferred RPs is 391 reachable, the active RP multicasts a RP-reachability message down 392 the (*,G) tree indicating which RP the last hop DRs should join. It 393 also unicasts a Register-Ack message to the sources' first hop 394 routers informing them of the now-reachable and preferred RP address. 395 A Register-Ack with the preferred RP-address included is sent in 396 response to a sampling of subsequent Register packets received. 398 The alternate RP may prune any upstream (S,G) state or just allow it 399 to time out. Note that switching back is unlikely to impose 400 significant degradation in performance, since for high data rate 401 sources, receivers will be joined to the SP-tree, and data delivery 402 will not be affected by the switch. 404 Note that we do not try to fix the case where a receiver can reach 405 the alternate RP and the alternate RP can reach the primary, but the 406 receiver can not reach the primary. This situation could result from 407 inconsistent unicast routing or perhaps an asymmetry caused by a 408 firewall. The former case should be addressed by the unicast routing 409 protocol (and is being so addressed) , and the latter case requires 410 that we articulate to firewall users how their firewalls and PIM-SM 411 routers need to be configured in order to allow PIM usage where 412 desired. 414 2.7 RP Selection 416 The mechanism proposed here is one possible means of selecting RPs; 417 it does not preclude the use of alternate methods, heuristics, and 418 even out of band procedures for selecting RPs, so long as the 419 selected RPs are placed in an ordered list and advertised to all 420 potential group members and sources to groups. However, the 421 particular mechanism proposed here will produce more scalable, 422 robust, and efficient RP distribution trees and therefore is 423 important to the overall architecture. 425 _________________________ 426 [*] RPn polls RPn-i, where i=n-1,...,1, so long as RPn 427 is active and and until an RPi responds. 429 To summarize our approach, we provide a mechanism for the Primary RP 430 to be selected from among routers close to the group initiator, and 431 alternate RPs from other parts of the network, depending upon the 432 anticipated geographic scope of the group. We assume that in general 433 the network is not partitioned and the primary RP is used. Network 434 topology changes will be reflected in routing protocol adaptations 435 and consequent adaptation of the affected branches of the RP (and 436 source specific) tree. Only when the primary RP fails or when the 437 network partitions (i.e., a failure occurs that routing cannot heal), 438 does the protocol automatically switch to one of the alternate RPs 439 specified for a group. In other words, the adaptation mechanism 440 occurs in response to relatively rare events. 442 Routers that are willing to act as RPs use a low-frequency 443 advertisement protocol as follows: 445 1. Candidate-RP-Advertisement messages are sent to a well- 446 known, multicast group such as that used by sd for session 447 advertisements. 449 2. Each message includes an Intended-Hop-Count value set by the 450 advertising router; this value is not modified by the other routers 451 which forward the packet to the well-known distribution group. The 452 advertising router initializes the TTL in the containing IP packet to 453 this Intended-hop-count value as a means of controlling the range of 454 its advertisements and its resulting use as an RP. Candidate-RP- 455 Advertisements also include a group address and group mask fields, 456 which convey information about the range of groups for which the 457 advertising router is willing to become an RP. 458 [*] 460 Hosts that are used for multicast group initiation (e.g., those that now 461 run the sd protocol, or a smaller set of servers that are queried by 462 such hosts) join the Candidate-RP-Advertisement group and receive 463 advertisements from all candidate RP routers whose scope extends far 464 enough. These hosts/servers classify the received advertisements 465 according to the "distance" of the advertising router. The distance of 466 an advertising candidate can be computed based on the advertisement 467 message by subtracting the IP header TTL value from the Intended-hop- 468 count value. For example, in the context of a particular server/host 469 contacted by the group initiator, the local Candidate-RPs might consist 470 _________________________ 471 [*] If a router has multiple interfaces and is sending 472 candidate RP advertisements, it should advertise its 473 most generally reachable address. 475 of only the current DR or a set of routers and Border Routers in the 476 same domain as the initiator; whereas the regional Candidate-RPs might 477 be all those that are within a small number of hops beyond the local 478 domain. Candidate-RP-Advertisements are slowly aged to allow for changes 479 in the candidacy of an RP. 481 When a group initiator defines a multicast group, it will specify the 482 likely-group-scope. The RP selection tool will then select the primary 483 RP from the local RP-candidate list. The alternate RP list will be 484 constructed by selecting one (possibly 2) RP from each of the candidate 485 list sets that is within the group scope. 487 Once the alternate RPs have been selected they are placed in an ordered 488 list, with the primary RP first. We assume the existence of an sd-like 489 tool for RP-list advertisement. RP-reports are sent by group 490 participants (receivers and senders) to their directly connected DRs, to 491 inform them of the RP-list. 493 2.8 Multicast data packet processing 495 Data packets are processed in a manner similar to existing multicast 496 schemes. A router first performs a longest match on the source and group 497 address in the data packet. A (S,G) entry will be matched first if one 498 exists; a (*,G) entry will be matched otherwise. If neither state 499 exists, then the packet is dropped. An incoming interface check (RPF 500 check) is performed on the matching state and if it fails the packet is 501 dropped, otherwise the packet is forwarded to all interfaces listed in 502 the outgoing interface list. 504 The following two actions must be introduced in order to deliver data 505 packets continuously during the transition from a shared to shortest 506 path tree. First, when a data packet matches on a (S,G) entry with a 507 cleared SPT-bit, if the packet does not match the incoming interface for 508 that (S,G) entry, but the packet does match the incoming interface for 509 the (*,G) entry, then the packet is forwarded according to the (S,G) 510 entry. In addition, when a data packet matches on a (S,G) entry with a 511 cleared SPT-bit, and the incoming interface of the packet matches that 512 of the (S,G) entry, then the packet is forwarded and the SPT-bit is set 513 for that entry. 515 Data packets to SM groups never trigger prunes. However, data packets 516 may trigger actions which in turn trigger prunes. For example, when 517 router 518 B in figure 3 decides to switch to SP-tree at step 3, it creates a 519 (S,G) entry with SPT-bit set to 0. When data packets from S arrive at 520 interface 2 of B, B sets the SPT-bit to 1, which in turn triggers the 521 sending of prunes towards the RP. 523 2.9 Operation over Multi-access Networks 525 This section describes a few additional protocol mechanisms needed to 526 operate PIM over multi-access networks: Designated Router election, 527 Using Assert messages to resolve parallel paths, and suppressing 528 redundant Joins and Registers on multi-access networks. 530 2.9.1 Designated router election 532 When there are multiple PIM routers connected to a multi-access network, 533 one of them should be chosen to operate as the designated router (DR) at 534 any point in time. The DR is responsible for sending IGMP Host-Query 535 messages to solicit host group membership IGMP Host-Reports; the DR is 536 also responsible for initiating (*,G) state to trigger Join/Prune 537 messages toward the RP and keep track of the active RP status for local 538 senders. 540 A simple designated router (DR) election mechanism is used for both SM 541 and traditional IP multicast routing. 543 Neighboring routers send PIM-Query packets to each other. The sender 544 with the largest IP address assumes the role of DR. Each PIM router 545 connected to the multi-access LAN sends the PIM-Queries periodically in 546 order to adapt to changes in router status. 548 2.9.2 Parallel paths to a source or the RP 550 If a router receives a multicast datagram on a multi-access LAN from a 551 source whose corresponding (S,G) outgoing interface list includes the 552 received interface, the packet must be a duplicate. In this case a 553 single forwarder must be elected. Using PIM-Assert messages addressed to 554 224.0.0.2 (all routers) on the LAN, upstream routers can decide which 555 one becomes the forwarder. Downstream routers listen to the asserts so 556 they know which one was elected (i.e. typically this is the same as the 557 downstream router's RPF neighbor but there are circumstances when using 558 different unicast protocols where this might not be the case), and 559 therefore where to send subsequent Joins. 561 The upstream router elected is the one that has the shortest distance to 562 the source. Therefore, when a packet is received on an outgoing 563 interface a router will send a PIM-Assert packet on the multi-access LAN 564 indicating what metric it uses to reach the source of the data packet. 565 The router with the smallest numerical metric will become the forwarder. 566 All other upstream routers will delete the interface from their outgoing 567 interface list. The downstream routers also do the comparison in case 568 the forwarder is different than the RPF neighbor. 569 [*] 571 Associated with the metric is a metric preference value. This is 572 provided to deal with the case where the upstream routers may run 573 different unicast routing protocols. The numerically smaller metric 574 preference is always preferred. The metric preference should be treated 575 as the high-order part of an assert metric comparison. Therefore, a 576 metric value can be compared with another metric value provided both 577 metric preferences are the same. A metric preference can be assigned per 578 unicast routing protocol and needs to be consistent for all routers on 579 the multi-access network. 581 Asserts are also needed for (*,G) entries since there may be parallel 582 paths from the RP and sources to a multi-access network. When an assert 583 is sent for a (*,G) entry, the first bit in the metric preference (RP- 584 bit) is always set to 1 to indicate that this path corresponds to the RP 585 tree. Furthermore, the RP-bit is always cleared for SP-tree entries 586 metric preference, this causes an SP-tree path to always look better 587 than an RP-tree path. When the SP-tree and RPtree cross the same LAN, 588 this mechanism eliminates the duplicates that would otherwise be carried 589 over the LAN. 591 The DR may lose to another router on the LAN by the Assert process if 592 there are multiple paths to the active RP through the LAN. From then on, 593 the DR is no longer the last-hop router for local receivers. The winning 594 router becomes the last-hop router and is responsible for sending (*,G) 595 join messages to the RP. Asserts are rate limited. 597 2.9.3 Join/Prune suppression 599 If a Join/Prune message arrives on the incoming interface for an 600 existing (S,G) entry, and the sender of the Join/Prune has a higher IP 601 address than the recipient of the message, a Joiner-bit is cleared to 602 _________________________ 603 [*] The downstream routers will change their upstream 604 neighbor to the router that sent the last PIM-Assert 605 message during the assert process. This is important so 606 downstream routers send subsequent PIM-Joins/Prunes (in 607 SM) to the correct neighbor. 609 suppress further Join/Prune messages. A timer is set for the Joiner-bit; 610 after it expires the Joiner-bit is set indicating further periodic 611 Join/Prunes should be sent for this entry. The Joiner-bit timer is reset 612 each time a Join/Prune message is received from a higher-IP-addressed 613 PIM neighbor. 615 2.9.4 Register suppression and Register-Acks 617 When a router receives a (S,G) join for a source, S, that is directly 618 connected to the router via a multiaccess network, the router must send 619 the join to 0.0.0.0 on the mutliaccess network, in case it is not the 620 DR. This address is used when the upstream router is not known and so 621 the target for the Join/Prune is not known. When a DR receives the 622 Join/Prune on its incoming interface for a directly connected source 623 whose RP Annotated-bit is set in the join list, the DR sets its Register 624 timer to suppress the sending of registers for that source. If such 625 Join/Prune messages stop arriving at the DR, its RP register timer will 626 eventually expire and subsequent packets from the source will cause 627 registers to be sent to the RP. 629 2.10 Unicast Routing Changes 631 When unicast routing changes, an RPF check is done on all active (S,G) 632 and (*,G) entries, and all affected expected incoming interfaces are 633 updated. In particular, if the new incoming interface appears in the 634 outgoing interface list, it is deleted from the outgoing interface list. 635 The previous incoming interface may be added to the outgoing interface 636 list by a subsequent Join/Prune from downstream. Joins received on the 637 current incoming interface are ignored. Joins received on new interfaces 638 or existing outgoing interfaces are not ignored. Other outgoing 639 interfaces are left as is until they are explicitly pruned by downstream 640 routers or are timed out due to lack of appropriate Join/Prune messages. 642 The PIM router must send a Join/Prune message with S in the Join list 643 out its new incoming interface to inform upstream routers that it 644 expects multicast datagrams over the interface. It may also send a 645 Join/Prune message with S in the Prune list out the old incoming 646 interface, if the link is operational, to inform upstream routers that 647 this part of the distribution tree is going away. 649 2.11 Interaction with non-PIM-SM protocols 651 Interaction with non-PIM-SM networks is discussed in a separate 652 interoperability document. 653 _________________________ 654 [*] This document is currently in preparation. 656 All special mechanisms that deal with interoperability are executed in 657 Border Routers of the PIM-SM region and do not require any modification 658 of regular PIM-SM routers. 660 2.12 Treatment of non-SM groups 662 PIM-SM routers may be configured to run a DM protocol to handle non-SM 663 groups, e.g., PIM-DM, DVMRP, or [7]. Alternatively, PIM-SM routers may 664 be configured with a default RP-list for use with all non-PIM-SM groups. 665 For SM groups, PIM-SM relies on a group-specific RP-lists that are 666 advertised and used by all members and sources, internet-wide. For non- 667 SM groups, PIM-SM would use a local domain-specific RP-list that is 668 configured and used for all groups, but only within that domain. Each 669 domain would create and configure its own local RP-list. Apart from the 670 local definition of the RP-list, all other PIM-SM mechanisms remain 671 unchanged. 673 Unlike the other alternatives, this would create a single shared tree 674 within the domain for use by all non-SM groups. PIM-DM, DVMRP, and MOSPF 675 all create source-specific trees. 677 3 Detailed Protocol Description 679 This section describes the protocol operations from the perspective of 680 an individual PIM router implementation. In particular, for each message 681 type we describe how it is generated and processed. In this version of 682 the spec we suggest particular numerical timer settings. A future 683 version of the spec will specify a mechanism for timers to be set as a 684 function of the outgoing link bandwidth. 686 3.1 Query 688 PIM-Query messages are sent so neighboring PIM routers can discover each 689 other. 691 3.1.1 Sending Queries 693 Query messages are sent periodically between PIM neighbors. By default 694 they are transmitted every 30 seconds. This informs routers what 695 interfaces have PIM neighbors. Query messages are multicast using 696 address 224.0.0.2. The packet includes the holdtime for neighbors to 697 keep the information valid. The recommended holdtime is 3 times the 698 query transmission interval. By default the holdtime is 90 seconds. 699 Queries are sent on all types of communication links. 701 3.1.2 Receiving queries 703 When a router receives a PIM-Query packet, it stores the IP address for 704 that neighbor, sets the PIM neighbor timer based on the PIM-Query 705 holdtime, and determines the Designated Router (DR) for that interface. 706 The highest IP addressed system is elected DR. Each query received 707 causes the DR's address to be updated. 709 3.1.3 Timing out neighbor entries 711 A periodic process is run to time out PIM neighbors that have not sent 712 queries. If the DR has gone down, a new DR is chosen by scanning all 713 neighbors on the interface and selecting the new DR to be the one with 714 the highest IP address. If an interface has gone down, the router may 715 optionally time out all PIM neighbors associated with the interface. 717 3.2 IGMP RP-Reports 719 { Editors Note: This section will be detailed in the next I-D release. 720 We decided at the last moment that although RP-Reports are a part of 721 IGMP and not PIM, per se, that we need the detailed specification of 722 their handling included in the PIM-SM specification. This subsection on 723 IGMP RP-Reports is just a draft and has not been reviewed.} 725 Hosts respond to IGMP-Queries with IGMP RP-Reports if they have live 726 RP-Group mapping information. The RP-Report contains the following 727 information: 729 * The Group address. 731 * The ordered list of RP addresses for the group. 733 * A two bit flag. The receiver-flag bit is set if the host 734 wishes to join the group. The source-flag bit is set if the 735 host intends to send data to the group. At least one bit will 736 be set; both may be set. 738 The RP-Reports are sent to the RP-Reporters group with a TTL of 1. 739 In addition to the routers that support PIM, all hosts on the LAN 740 that send IGMP RP-Reports join the RP-Reporters group. RP-Report 741 information is suppressed by equivalent information in other recent 742 RP-Reports. Information is equivalent if the Group address and 743 RPlist are the same, and the corresponding Sender/Receiver flags 744 are set. 746 When a DR receives an IGMP RP-Report message it processes it as 747 follows. 749 * If no corresponding RP-Group-mapping exists, the DR 750 initializes one. If there exists RP-Group-mapping the RPlist 751 is updated. 753 * Sets the Source-flag and Receiver-flag bits in the RP-group- 754 mapping state according to the flag setting in the RP-Report. 756 * Resets the RP-Group-mapping timer associated with the RP- 757 Group-mapping state. 759 * If the Source flag is set to 1 and the Ack-Request timer for 760 this group is non-existent or has a zero value, then the 761 group's Ack-Request timer is initialized and the Ack-Request 762 flag is set to 1. 764 * If the Receiver flag is set to 1, the (*,G) state is refreshed 765 or initialized. 767 3.3 Join/Prune 769 Join/Prune messages are sent to join or prune a branch off of the 770 multicast distribution tree. A single message contains both a join 771 and prune list, either one of which may be null. Each list contains 772 a set of source addresses, indicating the source-specific trees or 773 shared tree that the router wants to join or prune. 775 3.3.1 Sending Join/Prune Messages 777 Join/Prune messages are merged such that a message sent to a 778 particular upstream neighbor, N, includes all of the current joined 779 and pruned sources that are reached via N; according to unicast 780 routing Join/Prune messages are multicast to all routers on multi- 781 access networks with the target address set to the next hop router 782 towards S or RP. Join/Prune messages are sent periodically. 783 Currently the period is set to 60 seconds. [*] 785 A router will send a periodic Join/Prune message to each distinct 786 RPF neighbor associated with each (S,G) and (*,G) entry. 788 Join/Prune messages are only sent if the RPF neighbor is a PIM 789 neighbor. A periodic Join/Prune message sent towards a particular 790 RPF neighbor is constructed as follows: 792 1 The RP address (with RP and WC bits set) is included in the 793 join list, and the RP-list is included in the RP-Address 794 fields, of a periodic Join/Prune message under the following 795 conditions: 797 1 The Join/Prune message is being sent to the RPF neighbor 798 to the RP. 800 2 The active RP is determined to be in Up state, and 802 3 The outgoing interface list in the (*,G) entry is non- 803 NULL, or the router is the DR on the same interface as 804 the RPF neighbor. 805 _________________________ 806 [*] In the future we will introduce mechanisms to 807 rate-limit this control traffic on a hop by hop basis, 808 in order to avoid excessive overhead on small links. 810 2 A particular source address, S, is included in the join list 811 with the RP and WC bits cleared under the following 812 conditions: 814 1 The Join/Prune message is being sent to the RPF neighbor 815 to S, and 817 2 There exists an active (S,G) entry with the RPbit 818 cleared, and 820 3 The { oif/} list in the (S,G) entry is not null. 822 The RP Annotated-bit (A-bit) is set for source S in the join 823 list if the local (S,G) entry has a valid IP address listed in 824 its RP-Annotated field. The (S,G) entry's RP-Annotated field 825 is included in the group's RP-Address-1 field and the RP count 826 is set to 1. 828 3 A particular source address, S, is included in the prune list 829 with the RP and WC bits cleared (and A-bit cleared) under the 830 following conditions: 832 1 The Join/Prune message is being sent to the RPF neighbor 833 to S, and 835 2 There exists an active (S,G) entry with the RPbit 836 cleared, and 838 3 The { oif/} list in the (S,G) entry is null. 840 4 A particular source address, S, is included in the prune list 841 with the RP bit set and the WC bit cleared (and A-bit 842 cleared) under the following conditions: 844 1 The Join/Prune message is being sent to the RPF neighbor 845 toward the RP and there exists a (S,G) entry with the 846 RPbit set and null { oif/} list, or 848 2 The Join/Prune message is being sent to the RPF neighbor 849 toward the RP, there exists a (S,G) entry with the RPbit 850 cleared and SPT-bit set, and the incoming interface 851 toward S is different than the incoming interface toward 852 the RP. 854 In addition to these periodic messages, the following events will 855 trigger Join/Prune messages (the contents of triggered messages are 856 the same as the periodic, described above) 858 1 Receipt of an IGMP Host-Report message for a new SM group G 859 (i.e., an SM group for which the receiving router does not 860 have a (*,G) entry) will trigger creation of a (*,G) entry and 861 sending of a Join/Prune message towards the RP with the RP 862 address and RP-bit and WC-bits set in the join list. 864 2 Receipt of a Join/Prune message for (S,G) or (*,G) will cause 865 building or modifying corresponding state, and subsequent 866 triggering of upstream Join/Prune messages, in the following 867 cases: 869 1 When there is no current forwarding entry, an entry will 870 be created. The new entry will in turn trigger an 871 upstream Join/Prune message. 873 2 When the outgoing interface list of (S,G,RPbit) entry is 874 null, the triggered Join/Prune message will contain S in 875 the prune list. 877 3 When a source, S, in the Join/Prune message has its RP 878 Annotated-bit set to zero, and the existing (S,G) entry 879 has the RP-Annotated field set to a valid IP address (the 880 RP's address). 882 4 When the source, S, in the Join/Prune message has its RP 883 Annotated-bit set to one, and the existing (S,G) entry 884 has the RP-Annotated field set to all zeros: the (S,G) 885 entry is updated to correspond to the arriving Join/Prune 886 message and the triggered Join/Prune message reflects the 887 new setting in the entry. 889 5 When an oif times out for which the A-bit was set, and no 890 other oif has the A-bit set, the entry's A-bit and RP- 891 Annotate fields are cleared and a Join/Prune message is 892 triggered upstream to represent the new state status. 894 3 Receipt of a packet on a (S,G) entry whose SPT-bit is cleared 895 triggers the following if the packet arrived on the correct 896 incoming interface and there is a (*,G) entry with a different 897 incoming RPF neighbor: a) setting of the SPT-bit on (S,G) 898 entry, and b) sending a Prune message towards the RP with 899 S,RP-bit in the prune list if the iif(S,G) does not equal the 900 iif(*,G). 902 4 When a Join/Prune message is received for a group G, the prune 903 list is checked. If it contains a source for which the 904 receiving router has an active (S,G) entry, and whose { iif/} 905 is that on which the Join/Prune was received, then a join for 906 (S,G) is triggered to override the prune. (This is necessary 907 in the case of parallel downstream routers connected to a 908 multi-access network.) 910 5 When a router receives a Join/Prune message with a source in 911 the join list that is directly connected to the router via a 912 multi-access LAN, the router must send the Join/Prune to 913 0.0.0.0 on the LAN in case it is not the DR. 915 6 When the active RP fails, RP-Reachability messages will not 916 reach the receivers' last-hop routers, hence, the (*,G) state 917 RP-timers will expire. This triggers the last-hop routers to 918 send (*,G) joins towards the next RP on the RP list for that 919 group. The Join/Prune message to the alternate RP includes the 920 ordered RP-list. 922 7 When an active alternate RP finds one of the preferred RPs 923 reachable, the active RP sends a special RP-reachability 924 message down the (*,G) tree indicating to which RP the last- 925 hop routers should join. This triggers updating of the (*,G) 926 state at the last hop routers, which in turn triggers sending 927 of a (*,G) Join upstream. 929 We do not trigger prunes onto interfaces for SM groups based on 930 data packets. Data packets that arrive on the wrong incoming 931 interface for an SM group are silently dropped. 933 3.3.2 Receiving Join/Prune Messages When a router receives a 934 Join/Prune message, it processes it as follows: 936 1 The receiver of the Join/Prune notes the interface on which 937 the PIM message arrived, call it I. The router accepts this 938 Join/Prune message if this Join/Prune message is addressed to 939 the router itself. If the Join/Prune is for this router the 940 following actions are taken: 942 1 If an address Sj in the join list has RP-bit and WC- bit 943 set, then Sj is an RP address and the following actions 944 are taken: 946 1 Add I to the outgoing interface list of the (*,G) 947 forwarding entry and set the timer for that 948 interface (if there is no (*,G) entry, the router 949 initializes one first), 951 2 For each (Si,G) entry associated with group G, if Si 952 is not included in the prune list, and if I is not 953 the iif then interface I is added to the { oif/} 954 list and the timers are reset for that interface in 955 each affected entry, 957 3 If the (Si,G) entry is an RP-bit entry and its { 958 oif/} list is the same as (*,G) { oif/} list, then 959 the (Si,G,RPbit) entry is deleted, 961 4 The incoming interface is set to the interface used 962 to send unicast packets to the RP in the (*,G) 963 forwarding entry, i.e., RPF interface to the RP. 965 5 The RP-list associated with the (*,G) entry is 966 populated with the addresses found in the RP-address 967 fields in the Join/Prune message. 969 2 For each address Si in the join list whose RP-bit and 970 WC-bit are not set, and for which there is no existing 971 (Si,G) forwarding entry, the router initiates one. 972 [*] 974 1 The outgoing interface for (Si,G) is set to I (and I 975 is added to the oif list for (*,G), if it exists). 976 The incoming interface for (Si,G) is set to the 977 interface used to send unicast packets to Si (i.e., 978 the RPF neighbor). 980 2 If the interface used to reach Si is the same as the 981 outgoing interface being built, I, this represents 982 an error and the Join/Prune should not be processed. 984 3 If the source address in the join list of the 985 Join/Prune message has its RP Annotated-bit set, the 986 corresponding (S,G) state entry stores the address 987 found in the RP-Address-1 field for G in the RP- 988 Annotated field. The A-bit for interface I is set 989 accordingly. 991 3 For any Si included in the join list of the PIM- 992 Join/Prune message, for which there is an existing (Si,G) 993 forwarding entry, 995 1 If the RP-bit is not set for Si listed in the 996 Join/Prune message, but the RP-bit is set on the 997 _________________________ 998 [*] The router creates a (S,G) entry and copies all 999 outgoing interfaces, excluding iif(S,G), from the (*,G) 1000 entry, if it exists. If a router does not copy all out- 1001 going interfaces from the (*,G) entry, all receivers on 1002 RP-tree, downstream from outgoing interfaces other than 1003 the one newly added to (S,G), will not receive packets 1004 from source S. Data packets of S arriving from the RP 1005 will match the (S,G) entry instead of (*,G) entry, and 1006 will be dropped because the incoming interface is in- 1007 correct. 1009 existing (Si,G) entry, the router clears the RP-bit 1010 on (Si,G) entry, sets the incoming interface to 1011 point towards Si for that (Si,G) entry, and sends a 1012 Join/Prune to the new incoming interface; and 1014 2 The router adds I to the list of outgoing interfaces 1015 if I is not the same as the existing incoming 1016 interface; the timer for I is initialized. 1018 3 The (Si,G) SPT bit is initialized to be cleared 1019 until data comes down the shortest path tree. 1021 4 If the RP Annotated-bit (the A-bit) in Si's source- 1022 address flags-field in the join list is set, the 1023 address found in the RP-Address-1 field is copied 1024 into the RP-Annotated field in the (Si,G) state 1025 entry. The A-bit is set for the oif on which the 1026 Join/Prune message arrived. If the router is a DR, 1027 it also resets its Ack-Request timer for that group 1028 to suppress Ack-requests. 1030 5 If the RP-annotate bit (the A-bit) is cleared then 1031 the A-bit is cleared in the oif on which the 1032 Join/Prune message arrived. Also the RP-Annotated 1033 field is updated accordingly. 1035 4 For each address Si in the prune list, 1037 1 If there is an existing (Si,G) forwarding entry, the 1038 router schedules a deletion of I from the list of 1039 outgoing interfaces. If I is a multi-access LAN, the 1040 deletion is not executed until a timer expires; 1041 allowing for other downstream routers on the LAN to 1042 override the prune. 1044 2 If the router has a current (*,G) forwarding entry, 1045 and if a (Si,G) RP-bit entry also exists then the 1046 (Si,G) RP-bit entry is maintained even if its 1047 outgoing interface list is null. 1049 5 For any Si in the prune list that has the RP-bit set: 1051 1 If (*,G) state exists, but there is no (Si,G) entry, 1052 an (Si,G,RP-bit) entry is created . The outgoing 1053 interface list is copied from the (*,G) entry, with 1054 the interface, I, on which the prune was received 1055 deleted. Packets from the pruned source, Si, match 1056 on this state and are not forwarded toward the 1057 pruned receivers. 1059 2 If there exists a (Si,G) entry, with or without the 1060 RPbit set, the iif on which the prune was received, 1061 I, is deleted from the { oif/} list, and the entry 1062 timer is reset. 1064 6 When a DR receives a Join/Prune message for an (S,G) 1065 entry for a directly connected source, and the source's 1066 RP Annotated-bit is set to one, and the message contains 1067 a valid RP address in the group's RP-Address-1 field, the 1068 DR sets its RP-Register timer; this suppresses the 1069 sending of registers for that source. If the RP-Register 1070 timer expires, the A-bit is reset, and this causes 1071 subsequent packets from the source to be encapsulated and 1072 sent in Register messages to the active RP. If the RP- 1073 timer expires subsequent packets will trigger sending of 1074 Registers to the next RP in the RPlist. 1076 2 If the received Join/Prune does not indicate the router as its 1077 target, then if the Join/Prune is for a (S,G) pair for which 1078 the router has an active (S,G) entry, and if the Join/Prune 1079 arrived an the { iif/} for that entry. The router compares the 1080 IP address of the generator of the Join/Prune, to its own IP 1081 address. 1083 1 If its own IP address is higher, the Joiner-bit in the 1084 (S,G) entry is set. 1086 2 If its own IP address is lower, the Joiner-bit in the 1087 (S,G) entry is cleared, and the Joiner-bit timer is 1088 activated. 1090 After the timer expires the Joiner-bit is set indicating 1091 further periodic Join/Prunes should be sent for this entry. 1092 The Joiner-bit timer is reset each time a Join/Prune message 1093 is received from a higher-IP-addressed PIM neighbor. 1095 For any new (S,G) or (*,G) entry created by an incoming 1096 Join/Prune message, the Joiner-bit is set and the SPT-bit is 1097 cleared. 1099 3.4 RP-Reachability 1101 RP-Reachability messages are sent by the RP and processed by last 1102 hop routers on the shared RP-distribution tree. A router acts as an 1103 RP when it has (*,G) state with a null incoming interface and 1104 itself as the associated RP; this state is set up in response to 1105 (*,G) Join messages that indicate the router as the associated RP. 1107 3.4.1 Sending RP-Reachability messages 1109 The router sends the periodic RP-Reachability messages out all 1110 outgoing interfaces in the (*,G) entry. The default interval for 1111 this message is 90 seconds. The messages are addressed to the All- 1112 Routers Group (224.0.0.2) class D address and the message content 1113 includes the RP and G. 1115 When an alternate active RP detects that a preferred RP is now 1116 reachable, it includes the address of the reachable, preferred RP 1117 in its RP-reachability messages. This is referred to as the 1118 active-RP-address field. 1120 3.4.2 Receiving RP-Reachability messages 1122 When a router receives an RP-Reachability message it does the 1123 following: 1125 1 If the arriving interface for the RP-reachability message is 1126 not the same as the incoming interface in the (*,G) entry, 1127 drop the RP-Reachability message. 1129 2 If the router is a last-hop router (i.e., has directly 1130 connected members), check if the active-RP-address included 1131 inside the PIM message is the same as the current RP being 1132 used. If it is the same, simply reset the corresponding RP- 1133 timer. If it is different, reset the RP-timer and update the 1134 (*,G) entry incoming interface to point to the now-reachable 1135 preferred RP indicated in the RP-Reachability message and 1136 trigger a (*,G) join toward that RP. 1138 3.5 Register and Register-Ack 1140 When a source first starts sending to a group its packets are 1141 encapsulated in PIM-Register messages and sent to the active RP. 1142 The RP sends Register-Ack messages towards the source(s); or if 1143 their data rate warrants source-specific paths, the RP sets up 1144 source specific state and starts sending (S,G) Join/Prune messages 1145 toward the source, with an annotation indicating that the Joins 1146 were initiated by the RP and act as an implicit Register-Ack. 1148 3.5.1 Sending Registers and Receiving Register-Acks 1150 Register messages are sent as follows: 1152 1 When a DR receives a packet from a directly connected source, 1153 S: 1155 1 If there is no corresponding (S,G) entry, the DR creates 1156 one with the Register-flag set to 1 and the RP address 1157 set according to RP-Group-mapping state in the DR. The 1158 Register-flag-timer is initialized to zero; the 1159 Register-flag-timer is non-zero only when the Register 1160 flag is set to 0. If there is no existing (*,G) or (Si,G) 1161 state for this group, the RP-timer and Ack-Request timers 1162 are initialized and the Ack-Request flag is set to 1. 1164 2 If there is a (S,G) entry in existence, the DR simply 1165 resets the corresponding S-timer (entry timer). 1167 The Register-flag-timer is initialized to one-third the RP- 1168 timer when the Register flag for the (S,G) entry is set to 1169 zero (cleared). The Register-flag-timer and the Register-flag 1170 are reset by no-data Register-Acks for the particular source. 1171 They are also reset by Join/Prune messages with the RP- 1172 annotated bit set and RP-field indicating the current RP. IF 1173 and when the Register-flag-timer expires, the Register flag 1174 for that entry is set to one to reinstigate Register messages 1175 for that source. 1177 2 If the new or previously-existing (S,G) entry has the 1178 Register-bit set, the data packet is encapsulated in a 1179 Register message and unicast to the active RP for that group. 1180 The data packet is also forwarded according to (S,G) state in 1181 the DR if the oif list is not null; since a receiver may join 1182 the SP-tree while the DR is still registering to the RP. 1184 1 If the RP-Group-mapping state's Ack-request flag is set, 1185 the DR sets the Ack-request flag in the Register message 1186 and clears the Ack-request flag in the RP-Group-mapping 1187 state. It also resets the Ack-request timer. 1189 3 If the (S,G) entry has the Register-flag cleared, the data 1190 packet is not sent in a Register message, it is just forwarded 1191 according to the (S,G) oif list. 1193 4 If the DR's Ack-Request timer expires for some group, G, the 1194 following actions are taken if the RP-Group-mapping timer has 1195 not expired: 1197 1 The DR schedules sending of a null-Register message 1198 (i.e., a Register message with no encapsulated data and 1199 the Ack-Request and no-data flags set to 1.) The null- 1200 Register message is scheduled for sending after some 1201 short delay. The DR sets the Ack-Request flag for the 1202 group. This delay is introduced to take advantage of 1203 piggybacking the Ack-Request in a pending Register with 1204 encapsulated data. 1206 2 If the DR flag for the group is not cleared within the 1207 short time period scheduled, the DR sends the null- 1208 Register message. 1210 In this way, the Ack-request timer is used to drive periodic 1211 probing of the RP using the Ack-request flag in either data- 1212 driven Registers or null-Registers. The Ack-Request timer is 1213 reset, and null-Register messages are suppressed, by 1214 indications of RP reachability (Register-Acks or Join/Prune 1215 messages with the RP-annotated bit set by the RP). The Ack- 1216 request timer is initialized to one third of the RP-timer 1217 initialization value. The RP-Group-mapping timer indicates 1218 that the DR has directly connected sources interested in 1219 sending to the group. The RP-Group-mapping timer is reset by 1220 IGMP RP-Report messages sent by directly-connected hosts, with 1221 the source-flag set in the RP-Report message. 1223 5 If the DR's RP-timer expires for some group, G, the following 1224 actions are taken: 1226 1 The DR assumes that the current RP is not reachable and 1227 chooses the next RP on the RP-list. Subsequent Register 1228 messages are sent to the newly selected RP. The RP-timer 1229 is reset. In addition, the Register flags and Register- 1230 timers for all existing (Si,G) entries are reinitialized. 1231 The RP-list is treated as a ring so that the first RP is 1232 tried again, following the last RP on the list. 1234 2 The subsequent data packets or null-Register messages are 1235 sent to the new RP. 1237 The RP-timer is reset by indications of RP reachability 1238 (Register-Acks or Join/Prune messages with the RP-annotated 1239 bit set by that RP.) 1241 The DR processes Register-Ack messages as follows: 1243 1 If the RP-address is different from the RP address currently 1244 used by the DR, the DR sets the active RP for that group to 1245 that indicated in the Register-Ack and resets the Register- 1246 flag in corresponding (S,G) entries. If the indicated RP- 1247 address is not a valid IP unicast address it should be 1248 ignored. 1250 2 The DR resets the Ack-Request-timer and RP-timer for the 1251 corresponding group. 1253 3 If the no-data flag is set, the DR clears the Register-flag 1254 and initializes the Register-flag-timer in the corresponding 1255 (S,G) entry(ies). 1257 When a Register-flag-timer expires, the corresponding entry(ies) 1258 Register flag is set to 1 to reinstigate encapsulation of data 1259 packets in Register messages. 1261 3.5.2 Receiving Register Messages and Sending Register-Acks 1263 When a router (i.e., the RP) receives a Register message, the 1264 router does the following: 1266 1 Decapsulates the data packet, and checks for a corresponding 1267 (S,G) entry. 1269 1 If a (S,G) entry exists and 1270 the packet arrived from the decapsulation 1271 process, the packet is forwarded but the SPT bit is left 1272 cleared (0). If the SPT bit is 1, the packet is dropped. 1274 2 If there is no (S,G) entry, but there is a (*,G) entry, 1275 the packet is forwarded according to the (*,G) entry. 1277 3 If there is no G related entry, the RP initializes one 1278 with a null oif list and the iif null. A timer for the 1279 entry is also initialized. 1281 The (S,G) state timer is reset by packets arriving from that 1282 source to that group. If the Register message contains a 1283 null-data portion, the (S,G) state timer is still reset. 1285 2 If the Ack-Request flag is set in the Register message, or if 1286 the matching (S,G) or (*,G) state contains a null oif list, 1287 the RP unicasts a Register-Ack message to the source of the 1288 Register message. If the relevant entry, either (S,G) or 1289 (*,G), has a null oif list, then the no-data flag is set; in 1290 the latter case, the source-address field is set to the 1291 wildcard value (all 0's). This message is not processed by 1292 intermediate routers, hence no (S,G) state is constructed 1293 between the active RP and the source. Register-Acks are rate 1294 limited. 1296 3 If the Register message arrival rate warrants it and there is 1297 no existing (S,G) entry, the RP sets up a (S,G) forwarding 1298 entry with the outgoing interface list, excluding iif(S,G), 1299 copied from the (*,G) outgoing interface list, its SPT-bit is 1300 initialized to 0. The (S,G) state entry includes the RP- 1301 Address in the RP-Annotated field. A timer is set for the 1302 (S,G) entry and this timer is reset by receipt of data packets 1303 for (S,G). The (S,G) entry causes the RP to send a Join/Prune 1304 message for the indicated group towards the source of the 1305 register message. The Join/Prune message includes the RP's 1306 address in the RP-Address-1 field for that group. The 1307 Join/Prune message includes the source's address in the Join 1308 list with its RP Annotated-bit set to 1. 1310 If the (S,G) oif list becomes null, Join/Prune messages will 1311 not be sent towards the source, S. 1313 4 If the currently active RP is not the preferred RP, it 1314 periodically polls the preferred RP(s) (all the RPs that 1315 appear before it in the ordered RP-list). When one of the 1316 preferred RPs becomes reachable, the active alternate RP 1317 unicasts a Register-Ack to the sources' first-hop routers; the 1318 message contains the address of the now-reachable and 1319 preferred RP in the active-RP-address field. See the section 1320 on RP Polling for more details. 1322 3.6 Poll and Poll-Response 1324 The Poll message is used by an alternate RP to check the status of 1325 preferred RPs. The Poll-Response message is sent from a recovered 1326 (or now reachable) preferred RP to the currently-active alternate- 1327 RP to notify it of this recovery. 1329 3.6.1 Sending Poll 1331 The following events trigger sending Poll messages: 1333 1 When a PIM router receives a Join/Prune message with its 1334 address in the join list with the RP-bit and WC-bit set (hence 1335 it knows it is the active RP), the router starts sending 1336 periodic Poll messages to preferred RPs; i.e. the RPs that are 1337 before it in the ordered RP-list included in the Join/Prune 1338 message (note that the first RP on the list does not send 1339 Polls). 1341 2 When a PIM router receives a Register message, it starts 1342 sending periodic Poll messages to the preferred RPs. 1344 Poll messages are sent with the Poll bit set. 1346 3.6.2 Receiving Poll and Sending Poll-Response 1348 When a PIM router receives a Poll message, it clears the Poll bit 1349 in the message (hence, the message becomes a Poll-Response) and 1350 sends the message back to its source. 1352 3.6.3 Receiving Poll-Response 1354 When the active-alternate RP receives a Poll-Response message, it 1355 performs the following: 1357 1 Includes the RP-Address of the now-reachable and preferred RP 1358 in the RP-Reachability messages sent down the (*,G) tree to 1359 receivers. 1361 2 Includes the RP-Address of the now-reachable and preferred RP 1362 in Register-Ack messages unicast to sources. 1364 A Register-Ack message is triggered when the active RP finds that a 1365 preferred-RP is reachable. 1367 3.7 Multicast Data Packet Forwarding 1369 Processing a multicast data packet involves the following steps: 1371 1 Lookup forwarding state based on a longest match of the source 1372 address, and an exact match of the destination address in the 1373 data packet and compare the RPF check on the source address in 1374 the packet header with the { iif/} specified in the forwarding 1375 entry. 1377 2 If the packet arrived on the interface found in the matching- 1378 entry's { iif/} field: 1380 1 Forward the packet to the { oif/} list for that entry and 1381 reset the entry's timer. 1383 2 If the entry's SPT-bit is cleared, set the SPT-bit for 1384 that entry. If (*,G) also exists and their incoming 1385 interfaces are different, trigger a (S,G) prune with RP- 1386 bit set towards the active RP. 1388 3 If the source of the packet is a directly-connected host 1389 and the router is the DR on a multi-access network, check 1390 the Register flag associated with the (S,G) entry. If it 1391 is set, then the router encapsulates the data packet in a 1392 register message and sends it to the active RP. 1394 This covers the common case of a packet arriving on the RPF 1395 interface to the source or RP and being forwarded to all 1396 joined branches. It also detects when packets arrive on the 1397 SP-tree, and triggers their pruning from the RP-tree. If it is 1398 the DR for the source, it sends data packets encapsulated in 1399 PIM-Registers to the RPs. 1401 3 If the packet matches to an entry but did not arrive on the 1402 the interface found in the entry's { iif/} field, check the 1403 SPT-bit of the entry. If the SPT-bit is set, drop the packet. 1405 If the SPT-bit is cleared, then lookup the (*,G) entry for the 1406 packet. If the packet arrived on the { iif/} found in (*,G), 1407 forward the packet to the { oif/} list of the (S,G) entry. 1408 This covers the case when a data packet matches on a (S,G) 1409 entry for which the SP-tree has not yet been completely 1410 established upstream. 1412 4 If the packet does not match to any entry, but the source of 1413 the data packet is a local, directly-connected host, and if 1414 the router is the DR on a multi-access LAN and knows of the 1415 active RP associated with the destination group, G, then the 1416 DR checks the register flag associated with the local sender 1417 (if there is no such a register flag, a new register flag, 1418 associated with the local sender, is created and set), the 1419 data packet is encapsulated in a register message and sent to 1420 the active RP. 1422 5 If the packet does not match to any entry, and it is not a 1423 local host or the router is not the DR, drop the packet. 1425 3.8 Data triggered switch to shortest path tree (SP-tree) 1427 When a (*,G) entry is created, a data rate counter may be initiated 1428 at the last-hop routers. The counter is incremented with every data 1429 packet received for directly connected members of an SM group, if 1430 the longest match is (*,G). If and when the data rate for the group 1431 exceeds a certain configured threshold (t1), the router initiates 1432 'source-specific' data rate counters for the following data 1433 packets. Then, each counter for a source, is incremented when 1434 packets matching on (*,G) are received from that source. If the 1435 data rate from the particular source exceeds a configured threshold 1436 (t2), a (S,G) entry is created and a Join/Prune message is sent 1437 towards the source. If the RPF interface for (S,G) is 1438 not the same as that for (*,G), then the SPT-bit is cleared in the 1439 (S,G) entry. Other configured rules may be enforced to cause or 1440 prevent establishment of (S,G) state. 1442 3.9 Assert 1444 Asserts are used to resolve which of the parallel routers connected 1445 to a multi-access LAN is responsible for forwarding packets onto 1446 the LAN. 1448 3.9.1 Sending Asserts 1450 The following Assert rules are provided when a multicast packet is 1451 received on an outgoing multi-access interface of an existing (S,G) 1452 entry: 1454 1 Do unicast routing table lookup on source IP address from data 1455 packet, and send assert on interface for source IP address in 1456 data packet; include metric preference of routing protocol and 1457 metric from routing table lookup. 1459 2 If route is not found, use metric preference of 0x7fffffff and 1460 metric 0xffffffff. 1462 3 When an assert is sent for a (*,G) entry, the first bit in the 1463 metric preference (the RP-bit) is set to 1, indicating the 1464 data packet is routed down the RP-tree. 1466 Asserts are rate-limited by the router. 1468 3.9.2 Receiving Asserts 1470 When an assert is received the router performs a longest match on 1471 the source and group address in the assert message. The router 1472 checks the first bit of the metric preference (RP-bit). If the RP- 1473 bit is set, the router does a match on (*,G) entries, otherwise, 1474 the router matches (S,G) entries. If the interface that received 1475 the Assert message is in the { oif/} list of the matched entry, 1476 then this assert is targeted for this router and the message is 1477 processed as follows: 1479 1 Compare the metric received in the Assert with the one the 1480 router would have advertised in an assert. Note that, the 1481 metric preference should be treated as the high-order part of 1482 an assert metric comparison. If the value in the assert is 1483 less than the router's value, delete the interface from the 1484 entry. If the value is the same, compare IP addresses, if the 1485 routers address is less than the assert sender, delete the 1486 interface. 1488 2 If the router has won the election and there are directly 1489 connected members on the multi-access LAN, the router keeps 1490 the interface in its outgoing interface list. It acts as the 1491 forwarder for the LAN. 1493 3 If the router won the election but there are no directly 1494 connected members on the multi-access LAN, the router 1495 schedules to delete the interface. The LAN might be a stub LAN 1496 with no members (and no downstream routers). If no subsequent 1497 Join/Prunes are received, the router deletes the interface 1498 from the outgoing interface list; otherwise it keeps the 1499 interface in its outgoing interface and acts as the forwarder 1500 for the LAN. 1502 The winning router should send out an assert message including its 1503 own metric to that outgoing interface, so the other router will 1504 prune that interface from its forwarding entry. Also, when an 1505 assert is received, the router performs an exact match based on the 1506 source address, group address and the RP-bit of the metric 1507 preference in the assert message. Note that, this is not a longest 1508 match, only exact state will be matched. If there is no such state, 1509 then the router drops the assert message. Otherwise, If the 1510 interface that received the assert matches the incoming interface 1511 of the exactly matched entry, then the assert message is processed 1512 as follows: 1514 1 Downstream routers will select the upstream router with the 1515 smallest metric as their RPF neighbor. If two metrics are the 1516 same, the highest IP address is chosen to break the tie. 1518 2 If the downstream routers have downstream members, they must 1519 schedule a join to inform the upstream router that packets 1520 should be forwarded on the multi-access network. This will 1521 cause the upstream forwarder to cancel its delayed deletion of 1522 the interface. 1524 3.10 Candidate-RP-Advertisements 1526 Candidate-RP-Advertisements are low frequency PIM-messages sent by 1527 PIM routers willing to become RPs. The messages are sent to a 1528 well-known multicast group. Group initiators use these 1529 advertisements to build the RP-list for the group. 1531 Candidate-RP-Advertisements carry group address and group mask 1532 fields. This enables the advertising router to limit the 1533 advertisement to a certain range or scope of groups. The router may 1534 enforce this scope acceptance when receiving Registers or 1535 Join/Prune messages. 1537 3.11 Processing Timer Events 1539 { Editors Note: This subsection needs some more work to be 1540 complete. We decided we should have a separate section on timer 1541 processing but we have a bit more work to do before this section is 1542 complete, ie. before ALL timers used in PIM are described here in 1543 detail. Timers are also discussed individually in the sections that 1544 pertain to the protocol messages that they trigger/affect.} 1546 In this subsection we mention some critical timer events that are 1547 not always associated with the receipt or sending of messages and 1548 therefore are not fully covered by earlier subsections. 1550 Each (S,G) and (*,G) entry has timers associated with it. There are 1551 multiple timers maintained: one for the multicast routing entry 1552 itself and one for each interface in the outgoing interface list. 1554 Timers on entries are handled as follows: 1556 1 The { S-timer} of a (S,G) entry is reset whenever data packets 1557 for (S,G) are forwarded, or when a PIM-Register is received 1558 from S. 1560 2 The entry-timer for a (*,G) entry is reset when any of its 1561 oif timers gets reset. 1563 3 The S-timer for a (S,G) RP-bit entry is reset whenever a (S,G) 1564 prune with RP-bit set is received. 1566 Each timer expires after 3 times the refresh period; a typical 1567 value is 3 minutes (because a typical Join/Prune refresh interval 1568 is 1 minute.) 1570 The RP-Group-mapping timer is a group-specific, not source- 1571 specific, timer, that is initialized when a DR first receives an 1572 RP-Report message for a particular group. The timer is reset when 1573 the DR receives an IGMP RP-Report for that group. So long as this 1574 timer is non--zero, the DR will enable periodic null-Register 1575 messages to keep track of RP liveness. 1577 A timer is also maintained for each outgoing interface listed in 1578 each (S,G) or (*,G) entry. Each oif timer is managed as follows. 1580 1 The timer is set when the interface is added. 1582 2 The timer is reset each time a Join/Prune message or an IGMP 1583 membership report for G is received on that interface for that 1584 forwarding entry (i.e., (*,G)). 1586 3 When a timer is reset for an outgoing interface listed in a 1587 (*,G) entry, the timers are reset for that interface, in all 1588 existing (S,G) entries whose oif list contains that interface. 1589 Because some of the outgoing interfaces in (S,G) entry are 1590 copied from the (*,G) outgoing interface list, they may not 1591 have explicit (S,G) join messages from some of the downstream 1592 routers (i.e., where members are joining to the (*,G) tree 1593 only). 1594 [*] 1596 _________________________ 1597 [*] If there are sources in the prune list of the (*,G) 1598 join, then the timers for arriving interface will first 1599 be reset for those sources, and then this interface 1600 will be deleted from these same entries; producing a 1601 correct result, even though the updating of the timers 1602 was unnecessary. An implementation could optimize this 1603 by checking the prune list before processing the join 1604 list. 1606 4 When an outgoing interface timer expires, the corresponding 1607 outgoing interface is deleted from the outgoing interface 1608 list. 1610 A deletion timer is used to schedule deletion of multicast 1611 forwarding entries. Entries may be scheduled for deletion when 1612 their oif lists become null: 1614 1 When the oif list of an (S,G) entry becomes null, and the RP- 1615 bit is not set to 1, the entry is scheduled for deletion. 1617 [*] 1619 Once the (S,G) is timed out, it may be recreated when the next 1620 Join/Prune arrives. 1622 When the oif list for a (*,G) entry is null in a router that 1623 is not a DR or the RP, the entry is deleted. 1625 2 When the oif list for a (*,G) entry is null in the router that 1626 is the RP for that entry, the entry is scheduled for deletion 1627 (to allow time for polling preferred RPs). 1629 3 When the oif list for a (*,G) entry is null in a router that 1630 is the DR, and the RPF neighbor to the RP is the LAN, then the 1631 (*,G) entry is kept alive even though the oif list is null. 1633 4 When a (*,G) entry is deleted, all associated (S,G,RPbit) 1634 entries are also deleted. 1636 The RP-timer is a timer associated with the active RP per group. 1638 _________________________ 1639 [*] (S,G) entries with the RP-bit set, i.e., (S,G) RP- 1640 bit entries, are kept alive by receipt of Prunes. We do 1641 not want to delete such entries if a (*,G) entry ex- 1642 ists; otherwise, data packets will travel down both the 1643 RP-tree and SP-tree. While this would not result in 1644 periodic duplicates (because of the RPF check), it 1645 would waste network bandwidth. 1647 1 When an RP-Reachability message is received at the receivers' 1648 last hop routers the RP timer is reset. RP-Reachability 1649 messages contain the time-out period. The RP timer must be set 1650 to this value. 1652 2 When a Register-Ack or Join/Prune with the RP-annotate bit and 1653 RP address included is received at a DR with the corresponding 1654 (S,G) state, the associated RP timer is updated; the RP timer 1655 is set to 270 seconds, or to the Holdtime in the Join/Prune 1656 message, respectively. 1658 { Editors Note: The Assert timer sections were added recently. Will 1659 be sanity-checked for next I-D submission.} 1661 Routers on multiaccess LANs have Assert Timers. This timer is set 1662 in the downstream router(s) when one of the upstream routers on the 1663 LAN wins an Assert and becomes the upstream neighbor, in conflict 1664 with the unicast routing table's RPF upstream neighbor. When this 1665 timer expires, the downstream router should change its RPF neighbor 1666 back to the unicast routing table's RPF neighbor so as to reflect 1667 topology changes. 1668 TBD 1670 Another timer associated with Asserts is the Assert Rate-limit 1671 timer referred to in the section on Processing Assert messages. The 1672 Assert Rate-limit timer is reset whenever an Assert message is 1673 sent. An Assert message is not sent for a particular oif unless the 1674 Assert Rate-limit timer expires. 1676 4 Packet Formats 1678 RFC-1112, see [5], specifies two types of IGMP packets for hosts 1679 and routers to convey multicast group membership and reachability 1680 information. An IGMP Host-Query packet is transmitted periodically 1681 by routers to ask hosts to report multicast groups of which they 1682 are members. An IGMP Host- Report packet is transmitted by hosts in 1683 response to received queries advertising group membership. 1685 This section introduces new types of IGMP packets that are used by 1686 PIM routers. All PIM control messages are encoded in IGMP messages. 1688 4.1 IGMP Fixed Header The fixed header packet format is: 1690 0 1 2 3 1691 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 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 |Version| Type | Code | Checksum | 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 | Address | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 Version 1699 This memo specifies version 1 of IGMP. 1701 Type There are nine types of IGMP messages: 1703 1 = Host Membership Query 1704 2 = Host Membership Report 1705 3 = Router DVMRP Messages 1706 4 = Router PIM Messages 1707 5 = Cisco Trace Messages 1708 6 = New Host Membership Report 1709 7 = Host Membership Leave 1710 14 = Mtrace Response 1711 15 = Mtrace Request 1713 Code Codes for specific message types. Used only by DVMRP and PIM. 1714 PIM codes are: 1716 0 = Router-Query 1717 1 = Register 1718 2 = Register-Ack 1719 3 = Join/Prune 1720 4 = RP-Reachability 1721 5 = Assert 1722 6 = Graft 1723 7 = Graft-Ack 1724 8 = Candidate-RP-Advertisement 1725 9 = Poll 1727 Checksum 1728 The checksum is the 16-bit one's complement of the one's 1729 complement sum of the entire IGMP message. For computing the 1730 checksum, the checksum field is zeroed. 1732 Address 1733 PIM Version field when IGMP type is PIM. 1735 4.2 PIM Fixed Header 1737 The PIM fixed header carries the PIM version number, in addition to 1738 a reserved field and address length specifier fields. 1740 0 1 2 3 1741 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 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 |PIM Ver| Reserved | Addr length | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 PIM Ver 1747 PIM Version number is 2. 1749 Reserved 1750 Transmitted as zero, ignored on receipt. 1752 Addr length 1753 Address length in bytes. Throughout this section this would 1754 indicate the number of bytes in the Address field of an 1755 address. 1757 4.3 Encoded Source and Group Address formats 1759 1 Unicast address: Only the address is included. The length of 1760 the unicast address in bytes is specified in the 'Addr length' 1761 field in the header. 1763 2 Encoded-Group-Address: Takes the following format: 1765 0 1 2 3 1766 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 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Reserved | Mask Len | Group multicast Address ... | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | ...Group multicast Address ...| 1771 +-+-+-+-+-+-+-+-+-+-+++++++ 1772 Reserved 1773 Transmitted as zero. Ignored upon receipt. 1775 Mask Len 1776 The Mask length is 8 bits. The value is the number of 1777 contiguous bits left justified used as a mask which 1778 describes the address. It is less than or equal to Addr 1779 length * 8. If the message is sent for a single group 1780 then the Mask length should equal Addr length * 8. In 1781 version 2 of PIM, it is strongly recommend that this 1782 field be set to 32 for IPv4 and 128 for IPv6. 1784 Group multicast Address 1785 contains the group address, and has number of bytes 1786 equal to that specified in the Addr length field. 1788 3 Encoded-Source-Address: Takes the following format: 1790 0 1 2 3 1791 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 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Rsrvd |A|S|W|R| Mask Len | Source Address ... | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | ... Source Address | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+++-+ 1798 Reserved 1799 Transmitted as zero, ignored on receipt. 1801 A,S,W,R 1802 See section7 ef{Join_format} for details. 1804 Mask Length 1805 Mask length is 8 bits. The value is the number of 1806 contiguous bits left justified used as a mask which 1807 describes the address. The mask length must be less than 1808 or equal to Addr Length * 8. If the message is sent for a 1809 single source then the Mask length should equal Addr 1810 length * 8. In version 2 of PIM, it is strongly recommend 1811 that this field be set to 32 for IPv4. 1813 Source Address 1814 The address length is indicated from the Addr length 1815 field at the beginning of the header. For IPv4, the 1816 address length is 4 octets. 1818 4.4 PIM-Query Message 1820 It is sent periodically by PIM routers on all interfaces. 1822 0 1 2 3 1823 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 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 |Version| Type | Code | Checksum | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 |PIM Ver| Reserved | Addr length | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | Reserved | Holdtime | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 Version, Type, Code, Checksum, PIM Version 1833 Described above. 1835 Reserved 1836 Transmitted as zero, ignored on receipt. 1838 Addr length 1839 not used. 1841 Holdtime 1842 The amount of time a receiver should keep the neighbor 1843 reachable, in seconds. 1845 4.5 PIM-Register Message 1847 It is sent by the Designated Router (DR) to the active RP when a 1848 multicast packet needs to be transmitted on the RP-tree. Source IP 1849 address is set to the address of the DR, destination IP address is 1850 to the RP's address. 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 |Version| Type | Code | Checksum | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 |PIM Ver| Reserved | Addr length | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 |D|Q| Reserved |RP-Cnt | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | Unicast-RP-Address-1 | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | . . | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Unicast-RP-Address-m | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | | 1868 Multicast data packet 1869 | | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 Version, Type, Code, Checksum, PIM Version 1873 Described above. 1875 Addr length 1876 The unicast address length in bytes. Specifies the address 1877 length of the Unicast-RP-Address fields. 1879 D The data flag, when cleared indicates no-data included in the 1880 Multicast data packet section. The D flag is cleared in null- 1881 Registers. 1883 Q The Ack-Request flag, is a 1 bit value. When set, signals 1884 Register-Acks to be sent in response. The Q flag is set 1885 periodically to trigger periodical Register-Acks in response. 1887 RP-Cnt The number of RP-Addresses include in the RPlist. 1889 Unicast-RP-Address-1 .. m 1890 The ordered RPlist, listed in order of preference. 1892 Multicast data packet 1893 The original packet sent by the source. For periodic sending 1894 of registers with the D flag cleared, this part contains only 1895 the IP header. 1897 4.6 PIM-Register-Ack Message 1899 It is triggered by the Ack-Request flag set in a Register message. 1900 A Register-Ack is unicast from the active RP to the sender of the 1901 Register message. Source IP address is the address to which the 1902 register was addressed. Destination IP address is the source 1903 address of the register message. 1905 0 1 2 3 1906 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 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 |Version| Type | Code | Checksum | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 |PIM Ver| Reserved | Addr length | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Encoded-Group Address | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 | Unicast-Source Address | 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 | Unicast-Active-RP-Address | 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 |N| Reserved | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 Version, Type, Code, Checksum, PIM Version, Addr length 1923 Described above. 1925 Encoded-Group Address 1926 Format described above. Note that for Register-Acks the Mask 1927 len field should contain Addr length * 8 (32 for IPv4), if the 1928 message is sent to a single group. 1930 Unicast-Source Address 1931 IP host address of source from multicast data packet in 1932 register. The length of this field in bytes is specified in 1933 the Addr length field. 1935 Unicast-Active-RP-Address 1936 The address of the now reachable and preferred RP. The length 1937 of this field in bytes is specified in Addr length field. If 1938 included, and different than the source of the Register-Ack, 1939 then the sender's DR would know to register to the RP that is 1940 given in the RP-Address field. If this field does not contain 1941 a valid IP unicast address it should be ignored. 1943 N No-Data flag. A bit, when set informs the source not to send 1944 any data in the Registers. 1946 4.7 Join/Prune Message 1948 It is sent by routers towards upstream sources and RPs. A join 1949 creates forwarding state and a prune destroys forwarding state. 1950 Joins are sent to build shared trees (RP trees) or source trees 1951 (SPT). Prunes are sent to prune source trees when members leave 1952 groups as well as sources that do not use the shared tree. 1954 0 1 2 3 1955 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 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 |Version| Type | Code | Checksum | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 |PIM Ver| Reserved | Addr length | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Unicast-Upstream Neighbor Address | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Reserved | Num groups | Holdtime | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | Encoded-Multicast Group Address-1 | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Reserved |RP-Cnt |Number of Join Srcs|NumberOf Prune Srcs| 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Unicast-RP Address-1 | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | . | 1972 | . | 1973 | . | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Unicast-RP Address-m | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 | Encoded-Join Source Address-1 | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | . | 1980 | . | 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | Encoded-Join Source Address-n | 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 | Encoded-Prune Source Address-1 | 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 | . | 1987 | . | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | Encoded-Prune Source Address-n | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | . | 1992 | . | 1993 | . | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | Encoded-Multicast Group Address-n | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 | Reserved |RP-Cnt |Number of Join Srcs|NumberOf Prune Srcs| 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | Unicast-RP Address-1 | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | . | 2002 | . | 2003 | . | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | Unicast-RP Address-m | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Encoded-Join Source Address-1 | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | . | 2010 | . | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | Encoded-Join Source Address-n | 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 | Encoded-Prune Source Address-1 | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | . | 2017 | . | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | Encoded-Prune Source Address-n | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 Version, Type, Code, Checksum, PIM Version 2023 Described above. 2025 Addr Length 2026 The length in bytes of the encoded source addresses in the 2027 join and prune lists and the unicast RP-Addresses. 2029 Upstream Neighbor Address 2030 The IP address of the RPF or upstream neighbor. 2032 Reserved 2033 Transmitted as zero, ignored on receipt. 2035 Holdtime 2036 The amount of time a receiver should keep the Join/Prune 2037 state alive, in seconds. 2039 Number of Groups 2040 The number of multicast group sets contained in the message. 2042 Encoded-Multicast group address 2043 For format description see section 2044 4.3. .IP "RP-Cnt" 2045 The RP count field contains the number of RP addresses 2046 included in the message for a specific group. For (*,G) 2047 Join/Prune messages (RP count $>$=1); depending on the number 2048 of RP's in the RPlist. For (S,G) Join/Prune messages sent from 2049 the RP to a source, the RP count is set to 1. For (S,G) 2050 Join/Prune messages in which all sources in the Join list have 2051 their RP Annotated bits (A-bits) set to 0, the RP-Cnt is set 2052 to 0. 2054 Unicast-RP Address-1 .. m 2055 This is a list of the RPs. RPs are listed in preference order 2056 received. 2058 Number of Join Sources 2059 Number of join source addresses listed for a given group. 2061 Join Source Address-1 .. n 2062 This list contains the sources that the sending router will 2063 forward multicast datagrams for if received on the interface 2064 this message is sent on. 2066 See format section 4.3. The fields explanation for the 2067 Encoded-Source-Address format follows: 2069 Reserved 2070 Described above. 2072 A RP Annotated-bit. When set, the RP Address is annotated 2073 in corresponding (S,G) entry. The A bit is always set to 2074 0 for sources in the prune list. 2076 S The Sparse bit is a 1 bit value, it is used by routers 2077 on the shortest path tree to indicate the group is in 2078 sparse-mode (since they do not know about any RPs for the 2079 group). This indicates to receivers to send periodic 2080 Join/Prune messages towards the source. When set to 1, 2081 the (S,G) should be treated in sparse-mode, otherwise, it 2082 should be treated in dense-mode. 2084 W The WC bit is a 1 bit value. If 1, the join or prune 2085 applies to the (*,G) entry. If 0, the join or prune 2086 applies to the (S,G) entry where S is Source Address. 2087 Joins and prunes sent towards the RP should have this bit 2088 set. 2090 R The RP bit is a 1 bit value. If 1, the information about 2091 (S,G) is sent towards the RP. If 0, the information 2092 should be sent about (S,G) toward S, where S is Source 2093 Address. 2095 Mask Length, Source Address 2096 Described above. 2098 Represented in the form of $< WCbit >< RPbit >< Mask length >< 2099 Source address>$: 2101 A source address could be a host IP address : 2103 $< 0 >< 0 >< 32 >< 192.1.1.17 >$ 2105 A source address could be the RP's IP address : 2107 $< 1 >< 1 >< 32 >< 131.108.13.111 >$ 2109 A source address could be a subnet address to prune from the 2110 RP-tree : 2112 $< 0 >< 1 >< 28 >< 192.1.1.16 >$ 2114 A source address could be a general aggregate : 2116 $< 0 >< 0 >< 16 >< 192.1.0.0 >$ 2118 Number of Prune Sources 2119 Number of prune source addresses listed for a group. 2121 Prune Source Address-1 .. n 2122 This list contains the sources that the sending router does 2123 not want to forward multicast datagrams for when received on 2124 the interface this message is sent on. See format below. 2126 4.8 PIM-RP-Reachability Message 2128 Each RP will send RP-Reachability messages to all routers on its 2129 distribution tree for a particular group. These messages are sent 2130 so routers can detect that an RP is reachable. Routers that have 2131 attached host members for a group will process the message. 2133 The RPs will address the RP-Reachability messages to 224.0.0.2 2134 (All-Routers-Group). Routers that have state for the group with 2135 respect to the RP distribution tree will propagate the message. 2136 Otherwise, the message is discarded.If an RP address timer expires, 2137 the router should attempt to send a PIM join message towards an 2138 alternate RP provided for that group if one is available. 2140 0 1 2 3 2141 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 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 |Version| Type | Code | Checksum | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 |PIM Ver| Reserved | Addr length | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | Encoded-Group Address | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | Unicast-RP Address | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 | Reserved | Holdtime | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 Version, Type, Code, Checksum, PIM Version, Addr length 2156 Described above. 2158 Encoded-Group Address 2159 The group address the RP is associated with. Format 2160 described earlier. 2162 Unicast-RP Address 2163 The rendezvous point IP address of the sender. If the RP 2164 Address field is different than the currently active RP, then 2165 the member's DR should join to the RP given in that field. If 2166 this field does not contain a valid IP unicast address it 2167 should be ignored. The length of this field in bytes is 2168 specified in Addr length. 2170 Reserved 2171 Transmitted as zero, ignored on receipt. 2173 Holdtime 2174 The amount of time in seconds receivers of this message 2175 should consider the RP reachable. 2177 4.9 PIM-Assert Message 2179 The PIM-Assert message is sent when a multicast data packet is 2180 received on an outgoing interface corresponding to the (S,G) or 2181 (*,G) associated with the source. 2183 0 1 2 3 2184 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 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 |Version| Type | Code | Checksum | 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 |PIM Ver| Reserved | Addr length | 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 | Encoded-Group Address | 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 | Unicast-Source Address | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 |R| Metric Preference | 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | Metric | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 Version, Type, Code, Checksum, PIM Version, Addr length 2201 Described above. 2203 Encoded-Group Address 2204 The group address to which the data packet was addressed, and 2205 which triggered the Assert. Format previously described. 2207 Unicast-Source Address 2208 Source IP address from IP multicast datagram that triggered 2209 the Assert packet to be sent. The length of this field in 2210 bytes is specified in Addr length. 2212 R RP bit is a 1 bit value. If the IP multicast datagram that 2213 triggered the Assert packet is routed down the RP tree, then 2214 the RP bit is 1; if the IP multicast datagram is routed down 2215 the SPT, it is 0. 2217 Metric Preference 2218 Preference value assigned to the unicast routing protocol 2219 that provided the route to Host address. 2221 Metric The unicast routing table metric. The metric is in units 2222 applicable to the unicast routing protocol used. 2224 4.10 PIM-Graft Message 2226 Used in dense-mode. Refer to PIM dense mode specification. 2228 4.11 PIM-Graft-Ack Message 2230 Used in dense-mode. Refer to PIM dense mode specification. 2232 4.12 Candidate-RP-Advertisement 2234 0 1 2 3 2235 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 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 |Version| Type | Code | Checksum | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 |PIM Ver| Reserved | Addr length | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Intended-Hop-Count | Holdtime | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Encoded-Group Address | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 Version, Type, Code, Checksum, PIM Version 2247 Described above. 2249 Addr length 2250 not used in this message. 2252 Intended-Hop-Count 2253 This field is copied from the original TTL field when the 2254 advertisement is originated. It is not modified by 2255 intermediate routers. 2257 Holdtime 2258 The amount of time the advertisement is valid. This field 2259 allows advertisements to be aged out. 2261 Encoded-Group Address 2262 The group address the RP is associated with. Format 2263 previously described. 2265 4.13 PIM-Poll and Poll-Response Message 2266 0 1 2 3 2267 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 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 |Version| Type | Code | Checksum | 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 |PIM Ver| Reserved | Addr length | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 |P| Reserved | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 Version, Type, Code, Checksum, PIM Version 2277 Described above. 2279 Addr length 2280 not used in this message. Transmitted as zero, and ignored 2281 upon receipt. 2283 P The poll bit. When set indicates a Poll message, and when 2284 cleared indicates a Poll-Response. 2286 5 Pseudocode 2288 { Editors Note: This section is still in progress.} In the 2289 future the pseudocode will be available by anonymous ftp at 2290 catarina.usc.edu:pub/estrin/pim/pim.sm.pseudocode. 2292 6 Acknowledgments 2294 Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul 2295 Francis, Joel Halpern, Horst Hodel, Stephen Ostrowski, Dave 2296 Thaler, and Lixia Zhang provided detailed comments on previous 2297 drafts. The authors of [8] and membership of the IDMR WG 2298 provided many of the motivating ideas for this work and useful 2299 feedback on design details. 2301 This work was supported by the National Science Foundation, 2302 ARPA, cisco Systems and Sun Microsystems. 2304 References 2306 1. S.Deering, D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, 2307 P.Sharma, and A.Helmy. Protocol independent multicast (pim) : 2308 Motivation and architecture. 2309 Internet Draft, May 1995. 2311 2. S.Deering, D.Estrin, D.Farinacci, B.Fenner, V.Jacobson, and 2312 A.Helmy. Interoperability architecture and mechanisms for pim-sm. 2313 Internet Draft, June 1995. 2315 3. S.Deering, D.Estrin, D.Farinacci, and V.Jacobson. Protocol 2316 independent multicast (pim), dense mode protocol : Specification. 2317 Internet Draft, March 1994. 2319 4. D.Waitzman S.Deering, C.Partridge. Distance vector multicast 2320 routing protocol, nov 1988. RFC1075. 2322 5. S.Deering. Host extensions for ip multicasting, aug 1989. RFC1112. 2324 6. S.Deering. Igmp. { ???}, November 1994. 2326 7. J.Moy. Multicast extension to ospf. 2327 Internet Draft, September 1992. 2329 8. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. In 2330 Proceedings of the ACM SIGCOMM, San Francisco, 1993.