idnits 2.17.1 draft-ietf-idmr-pim-spec-02.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-26) 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. ** 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 17 has weird spacing: '... Drafts are ...' == Line 18 has weird spacing: '...cuments of t...' == Line 19 has weird spacing: '...ups may also ...' == Line 23 has weird spacing: '... Drafts may ...' == Line 24 has weird spacing: '...iate to use ...' == (888 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Sept 7, 1995) is 10733 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 41 looks like a reference -- Missing reference section? '2' on line 72 looks like a reference -- Missing reference section? '3' on line 70 looks like a reference -- Missing reference section? '4' on line 70 looks like a reference -- Missing reference section? '5' on line 1677 looks like a reference -- Missing reference section? '6' on line 121 looks like a reference -- Missing reference section? '7' on line 662 looks like a reference -- Missing reference section? '8' on line 2296 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Steven Deering (XEROX) 2 Internet Draft Deborah Estrin (USC) 3 Dino Farinacci (CISCO) 4 Van Jacobson (LBL) 5 Chinggung Liu (USC) 6 Liming Wei (USC) 7 Puneet Sharma (USC) 8 Ahmed Helmy (USC) 10 draft-ietf-idmr-pim-spec-02.txt Sept 7, 1995 12 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 13 Specification 15 Status of This Memo 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. (Note that other groups may also distribute 20 working documents as Internet Drafts). 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a 26 ``working'' draft'' or ``work in progress.'' 28 Please check the I-D abstract listing contained in each Internet 29 Draft directory to learn the current status of this or any other 30 Internet Draft. 32 1 Introduction 34 This document describes a protocol for efficiently routing to 35 multicast groups that may span wide-area (and inter-domain) 36 internets. We refer to the approach as Protocol Independent 37 Multicast--Sparse Mode (PIM-SM) because it is not dependent on any 38 particular unicast routing protocol, and because it is designed to 39 support sparse groups as defined in [1]. This document describes the 40 protocol details. For the motivation behind the design and a 41 description of the architecture, see [1]. Section 2 summarizes PIM- 42 SM operation. It describes the protocol from a network perspective, 43 in particular, how the participating routers interact to create and 44 maintain the multicast distribution tree. Section 3 describes PIM-SM 45 operations from the perspective of a single router implementing the 46 protocol; this section constitutes the main body of the protocol 47 specification. It is organized according to PIM-SM message type; for 48 each message type we describe its contents, its generation, and its 49 processing. Interoperability with other protocols is discussed in a 50 separate [2]. Section 4 provides packet format details and section 51 5 provides pseudocode that corresponds to the functions described in 52 section 3. The pseudocode is just for illustration, Section 4 is 53 authoritative. 55 The most significant functional changes since the January spec are 56 the RP-related mechanisms (for completeness) and the removal of the 57 PIM-DM protocol details to a separate [3] (for clarity). We rewrote 58 major portions for clarity and updated the packet formats 59 extensively. 61 The bibliography, pseudocode, and figures are all in preparation. 63 2 PIM-SM Protocol Overview 65 In this section we provide an overview of the architectural 66 components of PIM-SM. PIM-SM protocols operate on group addresses 67 taken from the Sparse portion of the multicast address space. [*] 69 _________________________ 70 [*] Non-SM group addresses may be treated using PIM-DM[3], DVMRP[4], or a 71 locally-configured default RP-list in conjunction with the PIM-SM 72 mechanisms described here. See [2] for more details of the latter. 74 A PIM-SM router receives explicit join messages from those 75 neighboring routers that have downstream group members. The PIM-SM 76 router then forwards data packets addressed to a multicast group, G, 77 only onto those interfaces on which explicit joins have been 78 received. 80 A Designated Router (DR) sends PIM-SM Join/Prune messages toward a 81 group-specific Rendezvous Point (RP) for each group for which it has 82 active members. Each router along the path toward the RP builds 83 wildcard (any-source) forwarding state for the group and sends 84 Join/Prune messages on toward the RP. The wildcard forwarding entry's 85 incoming interface points toward the RP; the outgoing interfaces 86 point to the neighboring downstream routers that have sent Join/Prune 87 messages toward the RP. This forwarding state creates a shared, RP- 88 centered, distribution tree that reaches all group members. When a 89 data source first sends to a group its DR unicasts Register messages 90 to the RP with the source's data packets encapsulated within. If the 91 data rate is high, the RP will send source-specific Join/Prune 92 messages back towards the source and the source's data packets will 93 follow the resulting forwarding state and travel unencapsulated to 94 the RP. Whether they arrive encapsulated or natively, the RP forwards 95 the source's decapsulated data packets down the RP-centered 96 distribution tree toward group members. If the data rate warrants it, 97 routers with local receivers can join a source-specific, shortest 98 path, distribution tree, and prune these source's packets off of the 99 shared RP-centered tree. Even if all receivers switch to the shortest 100 path tree, state for that source will be kept at the RP, so that new 101 members that join the RP-centered tree will receive data packets from 102 the source. For low data rate sources, neither the RP, nor last hop 103 routers need join a source-specific shortest path tree and data 104 packets can be delivered via the shared, RP-tree. 106 The following subsections describe SM operation in more detail, in 107 particular, the control messages that travel up and down the 108 distribution tree, and the actions they trigger. Section 3 describes 109 protocol operation from an implementors perspective, i.e., the 110 actions performed by a single PIM-SM router. 112 2.1 Local hosts joining a group 114 In order to join a multicast group, G, a host sends an IGMP Host- 115 Report message identifying the particular group. As specified in [5], 116 IGMP Host-Report messages are sent in response to a directly- 117 connected router's IGMP Host-Query message (see figure 1). From this 118 point on we refer to such a host as a receiver, R, (or member) of the 119 group G. The host also responds with an IGMP RP-Report message 120 identifying the (small) list of RPs associated with the group, 121 referred to as [6] 122 Fig. 1 Example: how a receiver joins, and sets up shared tree 124 When a DR receives a report for a new group, G, the DR will determine 125 based on the multicast address whether the group is a Sparse Mode 126 group; a specific portion of the multicast address space is being 127 allocated to Sparse Mode groups. If the group is SM the DR looks up 128 the associated RP-list, (see section 2.6), and selects the primary 129 RP. The DR (e.g., router A in figure 1) creates a wildcard multicast 130 forwarding entry for the group, referred to here as a (*,G) entry. 132 The RP address is included in a special record in the forwarding 133 entry, so that it will be included in upstream Join/Prune messages. 134 The outgoing interface is set to that over which the IGMP Host-Report 135 was received from the new member. The incoming interface is set to 136 the interface used to send unicast packets to the RP. A wildcard bit 137 (WC-bit) associated with this entry is set, indicating that this is a 138 wildcard entry; if there is no more specific match for a particular 139 source, it will be forwarded according to this entry. An RP-bit 140 associated with this entry is also set, indicating that this entry, 141 (*,G), represents state on the shared, RP tree. Each router on the 142 RP-tree with directly connected members sets a timer for this entry. 143 The RP-timer is reset each time an RP-Reachability message is 144 received for (*,G), see section 2.2 [*]. If the timer expires 145 and the router has no local members, the (*,G) state is deleted. If 146 the router does have local members, it refreshes the (*,G) entry 147 timer each time it gets an IGMP membership report; then, when the 148 RP-timer expires, the router attempts to join to the next RP on the 149 RP-list. 151 2.2 Establishing the RP-rooted shared tree 153 Triggered by the (*,G) state, the DR creates a Join/Prune message 154 with the RP address in its join list and the WC-bit and RP-bit set; 155 _________________________ 156 [*] Optionally, a router without directly connected 157 members may also process RP-reachability messages and thereby timeout 158 (*,G) state more rapidly. However, this is not required for proper 159 function of the protocol since the routers with directly connected 160 members will eventually time out their entries and stop sending (*,G) 161 Join/Prune messages toward the unreachable RP. 163 nothing is listed in its prune list. The RP-bit flags the join as 164 being associated with the shared tree and therefore the Join/Prune 165 message is propagated along the RP-tree. The WC-bit indicates that 166 the address is an RP and the receiver expects to receive packets from 167 all sources via this (shared tree) path. 169 Each upstream router creates or updates its multicast forwarding 170 entry for (*,G) when it receives a Join/Prune with the RP-bit and 171 WC-bit set. The interface on which the Join/Prune message arrived is 172 added to the list of outgoing interfaces (oifs) for (*,G). Based on 173 this entry each upstream router between the receiver and the RP sends 174 a PIM-SM- Join/Prune message in which the join list includes the RP. 175 The packet payload contains Multicast-Address=G, Join=RP,WCbit,RPbit, 176 Prune=NULL. 178 When a router that is willing to act as an RP receives a (*,G) Join 179 with itself listed as the RP, the router automatically performs the 180 functions specified here for an RP (i.e., a router does not need to 181 be specially configured to act as an RP). The incoming interface 182 (iif) in the RP's (*,G) entry is set to null. RP-Reachability 183 messages are generated by the RP periodically and distributed down 184 the (*,G) tree established for the group. This allows downstream 185 routers to detect when their current RP has become unreachable and 186 trigger joining towards an alternate RP, see section 2.6. When 187 alternate RPs are used, (*,G) Join/Prune messages include the 188 complete ordered RP-list. An RP performs the functions described thus 189 far whether it is the primary RP, or an alternate; however, alternate 190 RPs have the added task of polling preferred RPs on the RP-list and 191 notifying leaf routers when a preferred RP becomes reachable. 193 2.3 Hosts sending to a group 195 To start sending packets to a group, a host responds to IGMP queries 196 from the DR with an IGMP RP-Report for that group; the IGMP message 197 is sent to the "RP-Reporters" group with a TTL of 1. All PIM hosts on 198 the LAN join this group in order to implement suppression (see figure 199 2). The DR stores the indicated RP-Group mapping. When a host first 200 sends a multicast data packet to a group, its DR must deliver the 201 packet to the RP for distribution down the RP-tree. This is done by 202 the sender's DR unicasting a PIM-SM-Register packet to the primary RP 203 for the group (see section 2.6). The data packet is encapsulated in 204 the PIM-SM-Register packet so that the RP can decapsulate it and 205 deliver it to downstream members. The RP responds to Registers with 206 explicit Register-Ack messages. These Register-Ack messages are sent 207 periodically, and provide liveness indication; their absence does not 208 trigger retransmission, it triggers the router to select an alternate 209 RP. 211 Fig. 2 Example: a host sending to a group 213 If the data rate of the source warrants the use of a source-specific 214 shortest path tree, the RP constructs (S,G) state and sends periodic 215 Join/Prune messages toward the source. The routers between the source 216 and the RP build and maintain (S,G) state in response to these 217 messages and send (S,G) messages upstream toward the source. Each 218 (S,G) state entry includes the RP-address in the RP-Annotated field 219 of the entry. S,G Join/Prune messages triggered off of that state 220 will include the RP-address. 222 The source's DR stops encapsulating data packets in PIM-SM-Registers 223 when (and so long as) it receives Join/Prune(S,G) messages from the 224 active RP (i.e., S's RP Annotated-bit is set in the join list). Even 225 if the RP does not set up (S,G) state, it still responds to the 226 source's Register messages with Register-Acks, when requested (i.e., 227 if the Ack-Request flag is set in the Register message). If the RP 228 has a (S,G,RPbit) entry or (*,G) entry with a null oif list, the RP 229 sets a no-data flag in the Register-Ack to suppress the source's DR 230 from encapsulating the sources data packets. If the RP has no state 231 at all for that group, it responds with no-data Register-Acks. To 232 deal with a failure scenario in which the primary RP is unreachable 233 for extended periods and data sources are very bursty, the DR 234 continues to send null-Register messages periodically so long as 235 directly connected sources continue to send IGMP RP-reports; this is 236 only necessary when the active RP is not the primary RP. 238 If an RP has gone down during the register process, we want to limit 239 how long we encapsulate data packets. Also, if the encapsulating 240 stops and data is forwarded via (S,G) state to the RP, it is 241 desirable to know if that RP becomes unreachable. Therefore, there is 242 an RP (liveness) timer, and an RP-status flag, kept for the active RP 243 for all active groups in the DR of each source. The RP-timer is 244 reset, and the RP-status flag is set to "reachable'' when a 245 Join/Prune with the RP address included, or a Register-Ack message, 246 is received. When the RP-timer expires (for example, 270 seconds), 247 the RP-status flag is set for that RP indicating that it is in a 248 "down" state. The actions taken when an RP is detected as being 249 unreachable are described in section 2.6. 251 2.4 Switching from shared tree (RP-tree) to shortest path tree (SP- 252 tree)} When a PIM router has directly-connected members it first 253 joins the shared RP-tree. The router can switch to a source's 254 shortest path tree (SP-tree) after receiving packets from that source 255 over the shared RP-tree. The recommended policy is to initiate the 256 switch to the SP-tree after receiving a significant number of data 257 packets during a specified time interval from a particular source. To 258 realize this policy the router monitors data packets from sources for 259 which it has no source-specific multicast forwarding entry and 260 initiates such an entry when the data rate exceeds the configured 261 threshold. As shown in figure 3, router A initiates a new multicast 262 forwarding entry that is specific to the source, hereafter referred 263 to as (S,G) state. 265 Fig. 3 Example: Switching from shared tree to shortest path tree 267 When a (S,G) entry is activated (and periodically so long as the 268 state exists), a Join/Prune message will be sent upstream towards the 269 source, S, with S in the join list. The payload contains Multicast- 270 Address=G, Join=S, Prune=NULL. When the (S,G) entry is created, the 271 outgoing interface list is copied from (*,G), i.e., all local shared 272 tree branches are replicated in the new shortest path tree. In this 273 way when a data packet from S arrives and matches on this entry, all 274 receivers will continue to receive the source's packets along this 275 path unless and until the receivers choose to prune themselves. Note 276 that (S,G) state must be maintained in all last-hop routers where an 277 SP-tree is maintained. Even when (*,G) and (S,G) overlap, both states 278 are needed to trigger the source-specific Join/Prune messages. (S,G) 279 state is kept alive by data packets arriving from that source. A 280 timer, S-timer, is set for the (S,G) entry and this timer is reset 281 whenever a data packet for (S,G) is received. When the S-timer 282 expires the state is deleted. 284 Only routers with local members can initiate switching to the SP- 285 tree; intermediate routers do not. Consequently last hop routers 286 initialize (S,G) state in response to data packets from the source, 287 S; whereas intermediate routers only initialize (S,G) state in 288 response to Join messages from downstream that have S in the Join 289 list. To implement the policy that source-specific trees are only 290 setup for high-data rate source, a last-hop router does not 291 initialize a (S,G) entry until it has received m data packets from 292 the source within some interval of n seconds. The last-hop router 293 may alternatively be configured to not request switching to the 294 shortest path tree. 296 The (S,G) entry is initialized with the SPT-bit cleared, indicating 297 that the shortest path tree branch from S has not been setup 298 completely, and the router can still accept packets from S that 299 arrive on the (*,G) entry's iif. When a router with a (S,G) entry and 300 a cleared SPT-bit starts to receive packets from the new source S on 301 the iif for the (S,G) entry, and that iif differs from the (*,G) 302 entry's iif, the router sets the SPT-bit, and sends a Join/Prune 303 message towards the RP. This indicates that the router no longer 304 wants to receive packets from S via the shared RP-tree. The 305 Join/Prune message sent towards the RP includes S in the prune list, 306 with the RP-bit set indicating that S's packets should not be 307 forwarded down this branch of the shared tree. If the router 308 receiving the Join/Prune message has (S,G) state (with or without the 309 RPbit set), it deletes the arriving interface from the (S,G) oif 310 list. If the router has only (*,G) state, it creates an (S,G,RPbit) 311 entry. The Join/Prune message payload contains Multicast-Address=G, 312 Join=NULL, Prune=S,RPbit. 314 If at a later time a new receiver joins the RP-tree, the negative 315 cache state on the RP-tree must be eradicated to bring all sources' 316 data packets down to the new receiver. Therefore, when a (*,G) Join 317 arrives with a null prune list at a router that has any (S,G,RP-bit) 318 entries (which is causing it to send source-specific prunes toward 319 the RP), all RP-bit state for that group has to be updated upstream 320 of the router; so as to bring all sources' packets down to the new 321 member. To accomplish this the router updates all existing (S,G,RP- 322 bit) entries; it adds to each (S,G,RPbit) entry's oif list the 323 interface on which the (*,G) join arrived. The router also triggers a 324 (*,G) join upstream to cause the same updating of RP-bit settings 325 upstream and pull down all active sources' packets. If the arriving 326 (*,G) join has some sources included in its prune list, then the 327 corresponding (S,G,RP-bit) entries are left unchanged (i.e., the 328 RPbit remains set and no oif is added). 330 2.5 Steady state maintenance of distribution tree (i.e., router state)} 332 In the steady state each router sends periodic Join/Prune messages 333 for each active (S,G) or (*,G) entry; the Join/Prune messages are 334 sent to the RPF neighbor on the iif of the corresponding entry. These 335 messages are sent periodically to capture state, topology, and 336 membership changes. A Join/Prune message is also sent on an event- 337 triggered basis each time a new forwarding entry is established for 338 some new source (note that some damping function may be applied, 339 e.g., a merge time). Join/Prune messages do not elicit any form of 340 explicit acknowledgment; routers recover from lost packets using the 341 periodic refresh mechanism. 343 2.6 Use of alternate RPs (i.e., Adaptation to RP unreachability) 345 For each multicast group, the group initiator selects a primary RP 346 and a small ordered set of alternate RPs; referred to as the RP-list. 348 Except for transients while adapting to failures and recoveries, only 349 a single RP is active per group at any point in time. A later 350 section, 2.7, describes a mechanism to assist group initiators in 351 selecting routers for the RP-list. This section describes the use of 352 the RP-list once it has been constructed and advertised; in 353 particular, the use of alternate RPs when the primary RP becomes 354 unreachable. 356 When a router receives (*,G) Joins indicating itself as the RP, it 357 sets up (*,G) state and periodically sends RP-reachability messages. 358 These messages traverse the shared RP tree down to last hop routers 359 who use it to reset the timers on their (*,G) state. If a DR's (*,G) 360 state timer expires, this indicates that RP-reachability messages are 361 no longer being received. This triggers the DR to send (*,G) joins 362 toward the next RP on the ordered RP list for that group. When the 363 primary RP becomes unreachable, all DRs on the shared distribution 364 tree will detect the event and switch to the same alternate RP. 365 Consequently, aside from transients, there is always a single shared 366 RP-tree with a single active RP at any point in time. The only time 367 that different receiver's DRs will take different action from one 368 another is when there is a network partition and some DRs still 369 receive reachability messages while others do not. In this case only 370 the receivers on the other side of the partition will initiate joins 371 toward the secondary RP. The (*,G) join sent toward the alternate RP 372 includes the complete ordered list of RPs for that group (for reasons 373 explained below). 375 If and when the RP becomes unreachable, sources' first hop routers 376 will stop receiving the RP's (S,G) Join or Register-Ack messages. 377 Consequently, the RP timers in the sources' first hop routers will 378 also expire. This will trigger these routers to send subsequent (S,G) 379 data packets encapsulated in Register messages to the next RP in the 380 ordered list. The Register messages include the ordered RP-list. 382 Since all new members will be joining to the preferred RP once it is 383 reachable, the senders and receivers switch back to the preferred RP 384 when it becomes reachable. To achieve this, an active, alternate RP 385 periodically polls the preferred RPs (all RPs that appear before it 386 in the ordered RP list). 387 [*] 389 When the active alternate RP finds that one of the preferred RPs is 390 reachable, the active RP multicasts a RP-reachability message down 391 the (*,G) tree indicating which RP the last hop DRs should join. It 392 also unicasts a Register-Ack message to the sources' first hop 393 routers informing them of the now-reachable and preferred RP address. 394 A Register-Ack with the preferred RP-address included is sent in 395 response to a sampling of subsequent Register packets received. 397 The alternate RP may prune any upstream (S,G) state or just allow it 398 to time out. Note that switching back is unlikely to impose 399 significant degradation in performance, since for high data rate 400 sources, receivers will be joined to the SP-tree, and data delivery 401 will not be affected by the switch. 403 Note that we do not try to fix the case where a receiver can reach 404 the alternate RP and the alternate RP can reach the primary, but the 405 receiver can not reach the primary. This situation could result from 406 inconsistent unicast routing or perhaps an asymmetry caused by a 407 firewall. The former case should be addressed by the unicast routing 408 protocol (and is being so addressed) , and the latter case requires 409 that we articulate to firewall users how their firewalls and PIM-SM 410 routers need to be configured in order to allow PIM usage where 411 desired. 413 2.7 RP Selection 415 The mechanism proposed here is one possible means of selecting RPs; 416 it does not preclude the use of alternate methods, heuristics, and 417 even out of band procedures for selecting RPs, so long as the 418 selected RPs are placed in an ordered list and advertised to all 419 potential group members and sources to groups. However, the 420 particular mechanism proposed here will produce more scalable, 421 robust, and efficient RP distribution trees and therefore is 422 important to the overall architecture. 424 _________________________ 425 [*] RPn polls RPn-i, where i=n-1,...,1, so long as RPn 426 is active and and until an RPi responds. 428 To summarize our approach, we provide a mechanism for the Primary RP 429 to be selected from among routers close to the group initiator, and 430 alternate RPs from other parts of the network, depending upon the 431 anticipated geographic scope of the group. We assume that in general 432 the network is not partitioned and the primary RP is used. Network 433 topology changes will be reflected in routing protocol adaptations 434 and consequent adaptation of the affected branches of the RP (and 435 source specific) tree. Only when the primary RP fails or when the 436 network partitions (i.e., a failure occurs that routing cannot heal), 437 does the protocol automatically switch to one of the alternate RPs 438 specified for a group. In other words, the adaptation mechanism 439 occurs in response to relatively rare events. 441 Routers that are willing to act as RPs use a low-frequency 442 advertisement protocol as follows: 444 1. Candidate-RP-Advertisement messages are sent to a well- 445 known, multicast group such as that used by sd for session 446 advertisements. 448 2. Each message includes an Intended-Hop-Count value set by the 449 advertising router; this value is not modified by the other routers 450 which forward the packet to the well-known distribution group. The 451 advertising router initializes the TTL in the containing IP packet to 452 this Intended-hop-count value as a means of controlling the range of 453 its advertisements and its resulting use as an RP. Candidate-RP- 454 Advertisements also include a group address and group mask fields, 455 which convey information about the range of groups for which the 456 advertising router is willing to become an RP. 457 [*] 459 Hosts that are used for multicast group initiation (e.g., those that now 460 run the sd protocol, or a smaller set of servers that are queried by 461 such hosts) join the Candidate-RP-Advertisement group and receive 462 advertisements from all candidate RP routers whose scope extends far 463 enough. These hosts/servers classify the received advertisements 464 according to the "distance" of the advertising router. The distance of 465 an advertising candidate can be computed based on the advertisement 466 message by subtracting the IP header TTL value from the Intended-hop- 467 count value. For example, in the context of a particular server/host 468 contacted by the group initiator, the local Candidate-RPs might consist 469 _________________________ 470 [*] If a router has multiple interfaces and is sending 471 candidate RP advertisements, it should advertise its 472 most generally reachable address. 474 of only the current DR or a set of routers and Border Routers in the 475 same domain as the initiator; whereas the regional Candidate-RPs might 476 be all those that are within a small number of hops beyond the local 477 domain. Candidate-RP-Advertisements are slowly aged to allow for changes 478 in the candidacy of an RP. 480 When a group initiator defines a multicast group, it will specify the 481 likely-group-scope. The RP selection tool will then select the primary 482 RP from the local RP-candidate list. The alternate RP list will be 483 constructed by selecting one (possibly 2) RP from each of the candidate 484 list sets that is within the group scope. 486 Once the alternate RPs have been selected they are placed in an ordered 487 list, with the primary RP first. We assume the existence of an sd-like 488 tool for RP-list advertisement. RP-reports are sent by group 489 participants (receivers and senders) to their directly connected DRs, to 490 inform them of the RP-list. 492 2.8 Multicast data packet processing 494 Data packets are processed in a manner similar to existing multicast 495 schemes. A router first performs a longest match on the source and group 496 address in the data packet. A (S,G) entry will be matched first if one 497 exists; a (*,G) entry will be matched otherwise. If neither state 498 exists, then the packet is dropped. An incoming interface check (RPF 499 check) is performed on the matching state and if it fails the packet is 500 dropped, otherwise the packet is forwarded to all interfaces listed in 501 the outgoing interface list. 503 The following two actions must be introduced in order to deliver data 504 packets continuously during the transition from a shared to shortest 505 path tree. First, when a data packet matches on a (S,G) entry with a 506 cleared SPT-bit, if the packet does not match the incoming interface for 507 that (S,G) entry, but the packet does match the incoming interface for 508 the (*,G) entry, then the packet is forwarded according to the (S,G) 509 entry. In addition, when a data packet matches on a (S,G) entry with a 510 cleared SPT-bit, and the incoming interface of the packet matches that 511 of the (S,G) entry, then the packet is forwarded and the SPT-bit is set 512 for that entry. 514 Data packets to SM groups never trigger prunes. However, data packets 515 may trigger actions which in turn trigger prunes. For example, when 516 router 517 B in figure 3 decides to switch to SP-tree at step 3, it creates a 518 (S,G) entry with SPT-bit set to 0. When data packets from S arrive at 519 interface 2 of B, B sets the SPT-bit to 1, which in turn triggers the 520 sending of prunes towards the RP. 522 2.9 Operation over Multi-access Networks 524 This section describes a few additional protocol mechanisms needed to 525 operate PIM over multi-access networks: Designated Router election, 526 Using Assert messages to resolve parallel paths, and suppressing 527 redundant Joins and Registers on multi-access networks. 529 2.9.1 Designated router election 531 When there are multiple PIM routers connected to a multi-access network, 532 one of them should be chosen to operate as the designated router (DR) at 533 any point in time. The DR is responsible for sending IGMP Host-Query 534 messages to solicit host group membership IGMP Host-Reports; the DR is 535 also responsible for initiating (*,G) state to trigger Join/Prune 536 messages toward the RP and keep track of the active RP status for local 537 senders. 539 A simple designated router (DR) election mechanism is used for both SM 540 and traditional IP multicast routing. 542 Neighboring routers send PIM-Query packets to each other. The sender 543 with the largest IP address assumes the role of DR. Each PIM router 544 connected to the multi-access LAN sends the PIM-Queries periodically in 545 order to adapt to changes in router status. 547 2.9.2 Parallel paths to a source or the RP 549 If a router receives a multicast datagram on a multi-access LAN from a 550 source whose corresponding (S,G) outgoing interface list includes the 551 received interface, the packet must be a duplicate. In this case a 552 single forwarder must be elected. Using PIM-Assert messages addressed to 553 224.0.0.2 (all routers) on the LAN, upstream routers can decide which 554 one becomes the forwarder. Downstream routers listen to the asserts so 555 they know which one was elected (i.e. typically this is the same as the 556 downstream router's RPF neighbor but there are circumstances when using 557 different unicast protocols where this might not be the case), and 558 therefore where to send subsequent Joins. 560 The upstream router elected is the one that has the shortest distance to 561 the source. Therefore, when a packet is received on an outgoing 562 interface a router will send a PIM-Assert packet on the multi-access LAN 563 indicating what metric it uses to reach the source of the data packet. 564 The router with the smallest numerical metric will become the forwarder. 565 All other upstream routers will delete the interface from their outgoing 566 interface list. The downstream routers also do the comparison in case 567 the forwarder is different than the RPF neighbor. 568 [*] 570 Associated with the metric is a metric preference value. This is 571 provided to deal with the case where the upstream routers may run 572 different unicast routing protocols. The numerically smaller metric 573 preference is always preferred. The metric preference should be treated 574 as the high-order part of an assert metric comparison. Therefore, a 575 metric value can be compared with another metric value provided both 576 metric preferences are the same. A metric preference can be assigned per 577 unicast routing protocol and needs to be consistent for all routers on 578 the multi-access network. 580 Asserts are also needed for (*,G) entries since there may be parallel 581 paths from the RP and sources to a multi-access network. When an assert 582 is sent for a (*,G) entry, the first bit in the metric preference (RP- 583 bit) is always set to 1 to indicate that this path corresponds to the RP 584 tree. Furthermore, the RP-bit is always cleared for SP-tree entries 585 metric preference, this causes an SP-tree path to always look better 586 than an RP-tree path. When the SP-tree and RPtree cross the same LAN, 587 this mechanism eliminates the duplicates that would otherwise be carried 588 over the LAN. 590 The DR may lose to another router on the LAN by the Assert process if 591 there are multiple paths to the active RP through the LAN. From then on, 592 the DR is no longer the last-hop router for local receivers. The winning 593 router becomes the last-hop router and is responsible for sending (*,G) 594 join messages to the RP. Asserts are rate limited. 596 2.9.3 Join/Prune suppression 598 If a Join/Prune message arrives on the incoming interface for an 599 existing (S,G) entry, and the sender of the Join/Prune has a higher IP 600 address than the recipient of the message, a Joiner-bit is cleared to 601 _________________________ 602 [*] The downstream routers will change their upstream 603 neighbor to the router that sent the last PIM-Assert 604 message during the assert process. This is important so 605 downstream routers send subsequent PIM-Joins/Prunes (in 606 SM) to the correct neighbor. 608 suppress further Join/Prune messages. A timer is set for the Joiner-bit; 609 after it expires the Joiner-bit is set indicating further periodic 610 Join/Prunes should be sent for this entry. The Joiner-bit timer is reset 611 each time a Join/Prune message is received from a higher-IP-addressed 612 PIM neighbor. 614 2.9.4 Register suppression and Register-Acks 616 When a router receives a (S,G) join for a source, S, that is directly 617 connected to the router via a multiaccess network, the router must send 618 the join to 0.0.0.0 on the mutliaccess network, in case it is not the 619 DR. This address is used when the upstream router is not known and so 620 the target for the Join/Prune is not known. When a DR receives the 621 Join/Prune on its incoming interface for a directly connected source 622 whose RP Annotated-bit is set in the join list, the DR sets its Register 623 timer to suppress the sending of registers for that source. If such 624 Join/Prune messages stop arriving at the DR, its RP register timer will 625 eventually expire and subsequent packets from the source will cause 626 registers to be sent to the RP. 628 2.10 Unicast Routing Changes 630 When unicast routing changes, an RPF check is done on all active (S,G) 631 and (*,G) entries, and all affected expected incoming interfaces are 632 updated. In particular, if the new incoming interface appears in the 633 outgoing interface list, it is deleted from the outgoing interface list. 634 The previous incoming interface may be added to the outgoing interface 635 list by a subsequent Join/Prune from downstream. Joins received on the 636 current incoming interface are ignored. Joins received on new interfaces 637 or existing outgoing interfaces are not ignored. Other outgoing 638 interfaces are left as is until they are explicitly pruned by downstream 639 routers or are timed out due to lack of appropriate Join/Prune messages. 641 The PIM router must send a Join/Prune message with S in the Join list 642 out its new incoming interface to inform upstream routers that it 643 expects multicast datagrams over the interface. It may also send a 644 Join/Prune message with S in the Prune list out the old incoming 645 interface, if the link is operational, to inform upstream routers that 646 this part of the distribution tree is going away. 648 2.11 Interaction with non-PIM-SM protocols 650 Interaction with non-PIM-SM networks is discussed in a separate 651 interoperability document. 652 _________________________ 653 [*] This document is currently in preparation. 655 All special mechanisms that deal with interoperability are executed in 656 Border Routers of the PIM-SM region and do not require any modification 657 of regular PIM-SM routers. 659 2.12 Treatment of non-SM groups 661 PIM-SM routers may be configured to run a DM protocol to handle non-SM 662 groups, e.g., PIM-DM, DVMRP, or [7]. Alternatively, PIM-SM routers may 663 be configured with a default RP-list for use with all non-PIM-SM groups. 664 For SM groups, PIM-SM relies on a group-specific RP-lists that are 665 advertised and used by all members and sources, internet-wide. For non- 666 SM groups, PIM-SM would use a local domain-specific RP-list that is 667 configured and used for all groups, but only within that domain. Each 668 domain would create and configure its own local RP-list. Apart from the 669 local definition of the RP-list, all other PIM-SM mechanisms remain 670 unchanged. 672 Unlike the other alternatives, this would create a single shared tree 673 within the domain for use by all non-SM groups. PIM-DM, DVMRP, and MOSPF 674 all create source-specific trees. 676 3 Detailed Protocol Description 678 This section describes the protocol operations from the perspective of 679 an individual PIM router implementation. In particular, for each message 680 type we describe how it is generated and processed. In this version of 681 the spec we suggest particular numerical timer settings. A future 682 version of the spec will specify a mechanism for timers to be set as a 683 function of the outgoing link bandwidth. 685 3.1 Query 687 PIM-Query messages are sent so neighboring PIM routers can discover each 688 other. 690 3.1.1 Sending Queries 692 Query messages are sent periodically between PIM neighbors. By default 693 they are transmitted every 30 seconds. This informs routers what 694 interfaces have PIM neighbors. Query messages are multicast using 695 address 224.0.0.2. The packet includes the holdtime for neighbors to 696 keep the information valid. The recommended holdtime is 3 times the 697 query transmission interval. By default the holdtime is 90 seconds. 698 Queries are sent on all types of communication links. 700 3.1.2 Receiving queries 702 When a router receives a PIM-Query packet, it stores the IP address for 703 that neighbor, sets the PIM neighbor timer based on the PIM-Query 704 holdtime, and determines the Designated Router (DR) for that interface. 705 The highest IP addressed system is elected DR. Each query received 706 causes the DR's address to be updated. 708 3.1.3 Timing out neighbor entries 710 A periodic process is run to time out PIM neighbors that have not sent 711 queries. If the DR has gone down, a new DR is chosen by scanning all 712 neighbors on the interface and selecting the new DR to be the one with 713 the highest IP address. If an interface has gone down, the router may 714 optionally time out all PIM neighbors associated with the interface. 716 3.2 IGMP RP-Reports 718 { Editors Note: This section will be detailed in the next I-D release. 719 We decided at the last moment that although RP-Reports are a part of 720 IGMP and not PIM, per se, that we need the detailed specification of 721 their handling included in the PIM-SM specification. This subsection on 722 IGMP RP-Reports is just a draft and has not been reviewed.} 724 Hosts respond to IGMP-Queries with IGMP RP-Reports if they have live 725 RP-Group mapping information. The RP-Report contains the following 726 information: 728 * The Group address. 730 * The ordered list of RP addresses for the group. 732 * A two bit flag. The receiver-flag bit is set if the host 733 wishes to join the group. The source-flag bit is set if the 734 host intends to send data to the group. At least one bit will 735 be set; both may be set. 737 The RP-Reports are sent to the RP-Reporters group with a TTL of 1. 738 In addition to the routers that support PIM, all hosts on the LAN 739 that send IGMP RP-Reports join the RP-Reporters group. RP-Report 740 information is suppressed by equivalent information in other recent 741 RP-Reports. Information is equivalent if the Group address and 742 RPlist are the same, and the corresponding Sender/Receiver flags 743 are set. 745 When a DR receives an IGMP RP-Report message it processes it as 746 follows. 748 * If no corresponding RP-Group-mapping exists, the DR 749 initializes one. If there exists RP-Group-mapping the RPlist 750 is updated. 752 * Sets the Source-flag and Receiver-flag bits in the RP-group- 753 mapping state according to the flag setting in the RP-Report. 755 * Resets the RP-Group-mapping timer associated with the RP- 756 Group-mapping state. 758 * If the Source flag is set to 1 and the Ack-Request timer for 759 this group is non-existent or has a zero value, then the 760 group's Ack-Request timer is initialized and the Ack-Request 761 flag is set to 1. 763 * If the Receiver flag is set to 1, the (*,G) state is refreshed 764 or initialized. 766 3.3 Join/Prune 768 Join/Prune messages are sent to join or prune a branch off of the 769 multicast distribution tree. A single message contains both a join 770 and prune list, either one of which may be null. Each list contains 771 a set of source addresses, indicating the source-specific trees or 772 shared tree that the router wants to join or prune. 774 3.3.1 Sending Join/Prune Messages 776 Join/Prune messages are merged such that a message sent to a 777 particular upstream neighbor, N, includes all of the current joined 778 and pruned sources that are reached via N; according to unicast 779 routing Join/Prune messages are multicast to all routers on multi- 780 access networks with the target address set to the next hop router 781 towards S or RP. Join/Prune messages are sent periodically. 782 Currently the period is set to 60 seconds. [*] 784 A router will send a periodic Join/Prune message to each distinct 785 RPF neighbor associated with each (S,G) and (*,G) entry. 787 Join/Prune messages are only sent if the RPF neighbor is a PIM 788 neighbor. A periodic Join/Prune message sent towards a particular 789 RPF neighbor is constructed as follows: 791 1 The RP address (with RP and WC bits set) is included in the 792 join list, and the RP-list is included in the RP-Address 793 fields, of a periodic Join/Prune message under the following 794 conditions: 796 1 The Join/Prune message is being sent to the RPF neighbor 797 to the RP. 799 2 The active RP is determined to be in Up state, and 801 3 The outgoing interface list in the (*,G) entry is non- 802 NULL, or the router is the DR on the same interface as 803 the RPF neighbor. 804 _________________________ 805 [*] In the future we will introduce mechanisms to 806 rate-limit this control traffic on a hop by hop basis, 807 in order to avoid excessive overhead on small links. 809 2 A particular source address, S, is included in the join list 810 with the RP and WC bits cleared under the following 811 conditions: 813 1 The Join/Prune message is being sent to the RPF neighbor 814 to S, and 816 2 There exists an active (S,G) entry with the RPbit 817 cleared, and 819 3 The { oif/} list in the (S,G) entry is not null. 821 The RP Annotated-bit (A-bit) is set for source S in the join 822 list if the local (S,G) entry has a valid IP address listed in 823 its RP-Annotated field. The (S,G) entry's RP-Annotated field 824 is included in the group's RP-Address-1 field and the RP count 825 is set to 1. 827 3 A particular source address, S, is included in the prune list 828 with the RP and WC bits cleared (and A-bit cleared) under the 829 following conditions: 831 1 The Join/Prune message is being sent to the RPF neighbor 832 to S, and 834 2 There exists an active (S,G) entry with the RPbit 835 cleared, and 837 3 The { oif/} list in the (S,G) entry is null. 839 4 A particular source address, S, is included in the prune list 840 with the RP bit set and the WC bit cleared (and A-bit 841 cleared) under the following conditions: 843 1 The Join/Prune message is being sent to the RPF neighbor 844 toward the RP and there exists a (S,G) entry with the 845 RPbit set and null { oif/} list, or 847 2 The Join/Prune message is being sent to the RPF neighbor 848 toward the RP, there exists a (S,G) entry with the RPbit 849 cleared and SPT-bit set, and the incoming interface 850 toward S is different than the incoming interface toward 851 the RP. 853 In addition to these periodic messages, the following events will 854 trigger Join/Prune messages (the contents of triggered messages are 855 the same as the periodic, described above) 857 1 Receipt of an IGMP Host-Report message for a new SM group G 858 (i.e., an SM group for which the receiving router does not 859 have a (*,G) entry) will trigger creation of a (*,G) entry and 860 sending of a Join/Prune message towards the RP with the RP 861 address and RP-bit and WC-bits set in the join list. 863 2 Receipt of a Join/Prune message for (S,G) or (*,G) will cause 864 building or modifying corresponding state, and subsequent 865 triggering of upstream Join/Prune messages, in the following 866 cases: 868 1 When there is no current forwarding entry, an entry will 869 be created. The new entry will in turn trigger an 870 upstream Join/Prune message. 872 2 When the outgoing interface list of (S,G,RPbit) entry is 873 null, the triggered Join/Prune message will contain S in 874 the prune list. 876 3 When a source, S, in the Join/Prune message has its RP 877 Annotated-bit set to zero, and the existing (S,G) entry 878 has the RP-Annotated field set to a valid IP address (the 879 RP's address). 881 4 When the source, S, in the Join/Prune message has its RP 882 Annotated-bit set to one, and the existing (S,G) entry 883 has the RP-Annotated field set to all zeros: the (S,G) 884 entry is updated to correspond to the arriving Join/Prune 885 message and the triggered Join/Prune message reflects the 886 new setting in the entry. 888 5 When an oif times out for which the A-bit was set, and no 889 other oif has the A-bit set, the entry's A-bit and RP- 890 Annotate fields are cleared and a Join/Prune message is 891 triggered upstream to represent the new state status. 893 3 Receipt of a packet on a (S,G) entry whose SPT-bit is cleared 894 triggers the following if the packet arrived on the correct 895 incoming interface and there is a (*,G) entry with a different 896 incoming RPF neighbor: a) setting of the SPT-bit on (S,G) 897 entry, and b) sending a Prune message towards the RP with 898 S,RP-bit in the prune list if the iif(S,G) does not equal the 899 iif(*,G). 901 4 When a Join/Prune message is received for a group G, the prune 902 list is checked. If it contains a source for which the 903 receiving router has an active (S,G) entry, and whose { iif/} 904 is that on which the Join/Prune was received, then a join for 905 (S,G) is triggered to override the prune. (This is necessary 906 in the case of parallel downstream routers connected to a 907 multi-access network.) 909 5 When a router receives a Join/Prune message with a source in 910 the join list that is directly connected to the router via a 911 multi-access LAN, the router must send the Join/Prune to 912 0.0.0.0 on the LAN in case it is not the DR. 914 6 When the active RP fails, RP-Reachability messages will not 915 reach the receivers' last-hop routers, hence, the (*,G) state 916 RP-timers will expire. This triggers the last-hop routers to 917 send (*,G) joins towards the next RP on the RP list for that 918 group. The Join/Prune message to the alternate RP includes the 919 ordered RP-list. 921 7 When an active alternate RP finds one of the preferred RPs 922 reachable, the active RP sends a special RP-reachability 923 message down the (*,G) tree indicating to which RP the last- 924 hop routers should join. This triggers updating of the (*,G) 925 state at the last hop routers, which in turn triggers sending 926 of a (*,G) Join upstream. 928 We do not trigger prunes onto interfaces for SM groups based on 929 data packets. Data packets that arrive on the wrong incoming 930 interface for an SM group are silently dropped. 932 3.3.2 Receiving Join/Prune Messages When a router receives a 933 Join/Prune message, it processes it as follows: 935 1 The receiver of the Join/Prune notes the interface on which 936 the PIM message arrived, call it I. The router accepts this 937 Join/Prune message if this Join/Prune message is addressed to 938 the router itself. If the Join/Prune is for this router the 939 following actions are taken: 941 1 If an address Sj in the join list has RP-bit and WC- bit 942 set, then Sj is an RP address and the following actions 943 are taken: 945 1 Add I to the outgoing interface list of the (*,G) 946 forwarding entry and set the timer for that 947 interface (if there is no (*,G) entry, the router 948 initializes one first), 950 2 For each (Si,G) entry associated with group G, if Si 951 is not included in the prune list, and if I is not 952 the iif then interface I is added to the { oif/} 953 list and the timers are reset for that interface in 954 each affected entry, 956 3 If the (Si,G) entry is an RP-bit entry and its { 957 oif/} list is the same as (*,G) { oif/} list, then 958 the (Si,G,RPbit) entry is deleted, 960 4 The incoming interface is set to the interface used 961 to send unicast packets to the RP in the (*,G) 962 forwarding entry, i.e., RPF interface to the RP. 964 5 The RP-list associated with the (*,G) entry is 965 populated with the addresses found in the RP-address 966 fields in the Join/Prune message. 968 2 For each address Si in the join list whose RP-bit and 969 WC-bit are not set, and for which there is no existing 970 (Si,G) forwarding entry, the router initiates one. 971 [*] 973 1 The outgoing interface for (Si,G) is set to I (and I 974 is added to the oif list for (*,G), if it exists). 975 The incoming interface for (Si,G) is set to the 976 interface used to send unicast packets to Si (i.e., 977 the RPF neighbor). 979 2 If the interface used to reach Si is the same as the 980 outgoing interface being built, I, this represents 981 an error and the Join/Prune should not be processed. 983 3 If the source address in the join list of the 984 Join/Prune message has its RP Annotated-bit set, the 985 corresponding (S,G) state entry stores the address 986 found in the RP-Address-1 field for G in the RP- 987 Annotated field. The A-bit for interface I is set 988 accordingly. 990 3 For any Si included in the join list of the PIM- 991 Join/Prune message, for which there is an existing (Si,G) 992 forwarding entry, 994 1 If the RP-bit is not set for Si listed in the 995 Join/Prune message, but the RP-bit is set on the 996 _________________________ 997 [*] The router creates a (S,G) entry and copies all 998 outgoing interfaces, excluding iif(S,G), from the (*,G) 999 entry, if it exists. If a router does not copy all out- 1000 going interfaces from the (*,G) entry, all receivers on 1001 RP-tree, downstream from outgoing interfaces other than 1002 the one newly added to (S,G), will not receive packets 1003 from source S. Data packets of S arriving from the RP 1004 will match the (S,G) entry instead of (*,G) entry, and 1005 will be dropped because the incoming interface is in- 1006 correct. 1008 existing (Si,G) entry, the router clears the RP-bit 1009 on (Si,G) entry, sets the incoming interface to 1010 point towards Si for that (Si,G) entry, and sends a 1011 Join/Prune to the new incoming interface; and 1013 2 The router adds I to the list of outgoing interfaces 1014 if I is not the same as the existing incoming 1015 interface; the timer for I is initialized. 1017 3 The (Si,G) SPT bit is initialized to be cleared 1018 until data comes down the shortest path tree. 1020 4 If the RP Annotated-bit (the A-bit) in Si's source- 1021 address flags-field in the join list is set, the 1022 address found in the RP-Address-1 field is copied 1023 into the RP-Annotated field in the (Si,G) state 1024 entry. The A-bit is set for the oif on which the 1025 Join/Prune message arrived. If the router is a DR, 1026 it also resets its Ack-Request timer for that group 1027 to suppress Ack-requests. 1029 5 If the RP-annotate bit (the A-bit) is cleared then 1030 the A-bit is cleared in the oif on which the 1031 Join/Prune message arrived. Also the RP-Annotated 1032 field is updated accordingly. 1034 4 For each address Si in the prune list, 1036 1 If there is an existing (Si,G) forwarding entry, the 1037 router schedules a deletion of I from the list of 1038 outgoing interfaces. If I is a multi-access LAN, the 1039 deletion is not executed until a timer expires; 1040 allowing for other downstream routers on the LAN to 1041 override the prune. 1043 2 If the router has a current (*,G) forwarding entry, 1044 and if a (Si,G) RP-bit entry also exists then the 1045 (Si,G) RP-bit entry is maintained even if its 1046 outgoing interface list is null. 1048 5 For any Si in the prune list that has the RP-bit set: 1050 1 If (*,G) state exists, but there is no (Si,G) entry, 1051 an (Si,G,RP-bit) entry is created . The outgoing 1052 interface list is copied from the (*,G) entry, with 1053 the interface, I, on which the prune was received 1054 deleted. Packets from the pruned source, Si, match 1055 on this state and are not forwarded toward the 1056 pruned receivers. 1058 2 If there exists a (Si,G) entry, with or without the 1059 RPbit set, the iif on which the prune was received, 1060 I, is deleted from the { oif/} list, and the entry 1061 timer is reset. 1063 6 When a DR receives a Join/Prune message for an (S,G) 1064 entry for a directly connected source, and the source's 1065 RP Annotated-bit is set to one, and the message contains 1066 a valid RP address in the group's RP-Address-1 field, the 1067 DR sets its RP-Register timer; this suppresses the 1068 sending of registers for that source. If the RP-Register 1069 timer expires, the A-bit is reset, and this causes 1070 subsequent packets from the source to be encapsulated and 1071 sent in Register messages to the active RP. If the RP- 1072 timer expires subsequent packets will trigger sending of 1073 Registers to the next RP in the RPlist. 1075 2 If the received Join/Prune does not indicate the router as its 1076 target, then if the Join/Prune is for a (S,G) pair for which 1077 the router has an active (S,G) entry, and if the Join/Prune 1078 arrived an the { iif/} for that entry. The router compares the 1079 IP address of the generator of the Join/Prune, to its own IP 1080 address. 1082 1 If its own IP address is higher, the Joiner-bit in the 1083 (S,G) entry is set. 1085 2 If its own IP address is lower, the Joiner-bit in the 1086 (S,G) entry is cleared, and the Joiner-bit timer is 1087 activated. 1089 After the timer expires the Joiner-bit is set indicating 1090 further periodic Join/Prunes should be sent for this entry. 1091 The Joiner-bit timer is reset each time a Join/Prune message 1092 is received from a higher-IP-addressed PIM neighbor. 1094 For any new (S,G) or (*,G) entry created by an incoming 1095 Join/Prune message, the Joiner-bit is set and the SPT-bit is 1096 cleared. 1098 3.4 RP-Reachability 1100 RP-Reachability messages are sent by the RP and processed by last 1101 hop routers on the shared RP-distribution tree. A router acts as an 1102 RP when it has (*,G) state with a null incoming interface and 1103 itself as the associated RP; this state is set up in response to 1104 (*,G) Join messages that indicate the router as the associated RP. 1106 3.4.1 Sending RP-Reachability messages 1108 The router sends the periodic RP-Reachability messages out all 1109 outgoing interfaces in the (*,G) entry. The default interval for 1110 this message is 90 seconds. The messages are addressed to the All- 1111 Routers Group (224.0.0.2) class D address and the message content 1112 includes the RP and G. 1114 When an alternate active RP detects that a preferred RP is now 1115 reachable, it includes the address of the reachable, preferred RP 1116 in its RP-reachability messages. This is referred to as the 1117 active-RP-address field. 1119 3.4.2 Receiving RP-Reachability messages 1121 When a router receives an RP-Reachability message it does the 1122 following: 1124 1 If the arriving interface for the RP-reachability message is 1125 not the same as the incoming interface in the (*,G) entry, 1126 drop the RP-Reachability message. 1128 2 If the router is a last-hop router (i.e., has directly 1129 connected members), check if the active-RP-address included 1130 inside the PIM message is the same as the current RP being 1131 used. If it is the same, simply reset the corresponding RP- 1132 timer. If it is different, reset the RP-timer and update the 1133 (*,G) entry incoming interface to point to the now-reachable 1134 preferred RP indicated in the RP-Reachability message and 1135 trigger a (*,G) join toward that RP. 1137 3.5 Register and Register-Ack 1139 When a source first starts sending to a group its packets are 1140 encapsulated in PIM-Register messages and sent to the active RP. 1141 The RP sends Register-Ack messages towards the source(s); or if 1142 their data rate warrants source-specific paths, the RP sets up 1143 source specific state and starts sending (S,G) Join/Prune messages 1144 toward the source, with an annotation indicating that the Joins 1145 were initiated by the RP and act as an implicit Register-Ack. 1147 3.5.1 Sending Registers and Receiving Register-Acks 1149 Register messages are sent as follows: 1151 1 When a DR receives a packet from a directly connected source, 1152 S: 1154 1 If there is no corresponding (S,G) entry, the DR creates 1155 one with the Register-flag set to 1 and the RP address 1156 set according to RP-Group-mapping state in the DR. The 1157 Register-flag-timer is initialized to zero; the 1158 Register-flag-timer is non-zero only when the Register 1159 flag is set to 0. If there is no existing (*,G) or (Si,G) 1160 state for this group, the RP-timer and Ack-Request timers 1161 are initialized and the Ack-Request flag is set to 1. 1163 2 If there is a (S,G) entry in existence, the DR simply 1164 resets the corresponding S-timer (entry timer). 1166 The Register-flag-timer is initialized to one-third the RP- 1167 timer when the Register flag for the (S,G) entry is set to 1168 zero (cleared). The Register-flag-timer and the Register-flag 1169 are reset by no-data Register-Acks for the particular source. 1170 They are also reset by Join/Prune messages with the RP- 1171 annotated bit set and RP-field indicating the current RP. IF 1172 and when the Register-flag-timer expires, the Register flag 1173 for that entry is set to one to reinstigate Register messages 1174 for that source. 1176 2 If the new or previously-existing (S,G) entry has the 1177 Register-bit set, the data packet is encapsulated in a 1178 Register message and unicast to the active RP for that group. 1179 The data packet is also forwarded according to (S,G) state in 1180 the DR if the oif list is not null; since a receiver may join 1181 the SP-tree while the DR is still registering to the RP. 1183 1 If the RP-Group-mapping state's Ack-request flag is set, 1184 the DR sets the Ack-request flag in the Register message 1185 and clears the Ack-request flag in the RP-Group-mapping 1186 state. It also resets the Ack-request timer. 1188 3 If the (S,G) entry has the Register-flag cleared, the data 1189 packet is not sent in a Register message, it is just forwarded 1190 according to the (S,G) oif list. 1192 4 If the DR's Ack-Request timer expires for some group, G, the 1193 following actions are taken if the RP-Group-mapping timer has 1194 not expired: 1196 1 The DR schedules sending of a null-Register message 1197 (i.e., a Register message with no encapsulated data and 1198 the Ack-Request and no-data flags set to 1.) The null- 1199 Register message is scheduled for sending after some 1200 short delay. The DR sets the Ack-Request flag for the 1201 group. This delay is introduced to take advantage of 1202 piggybacking the Ack-Request in a pending Register with 1203 encapsulated data. 1205 2 If the DR flag for the group is not cleared within the 1206 short time period scheduled, the DR sends the null- 1207 Register message. 1209 In this way, the Ack-request timer is used to drive periodic 1210 probing of the RP using the Ack-request flag in either data- 1211 driven Registers or null-Registers. The Ack-Request timer is 1212 reset, and null-Register messages are suppressed, by 1213 indications of RP reachability (Register-Acks or Join/Prune 1214 messages with the RP-annotated bit set by the RP). The Ack- 1215 request timer is initialized to one third of the RP-timer 1216 initialization value. The RP-Group-mapping timer indicates 1217 that the DR has directly connected sources interested in 1218 sending to the group. The RP-Group-mapping timer is reset by 1219 IGMP RP-Report messages sent by directly-connected hosts, with 1220 the source-flag set in the RP-Report message. 1222 5 If the DR's RP-timer expires for some group, G, the following 1223 actions are taken: 1225 1 The DR assumes that the current RP is not reachable and 1226 chooses the next RP on the RP-list. Subsequent Register 1227 messages are sent to the newly selected RP. The RP-timer 1228 is reset. In addition, the Register flags and Register- 1229 timers for all existing (Si,G) entries are reinitialized. 1230 The RP-list is treated as a ring so that the first RP is 1231 tried again, following the last RP on the list. 1233 2 The subsequent data packets or null-Register messages are 1234 sent to the new RP. 1236 The RP-timer is reset by indications of RP reachability 1237 (Register-Acks or Join/Prune messages with the RP-annotated 1238 bit set by that RP.) 1240 The DR processes Register-Ack messages as follows: 1242 1 If the RP-address is different from the RP address currently 1243 used by the DR, the DR sets the active RP for that group to 1244 that indicated in the Register-Ack and resets the Register- 1245 flag in corresponding (S,G) entries. If the indicated RP- 1246 address is not a valid IP unicast address it should be 1247 ignored. 1249 2 The DR resets the Ack-Request-timer and RP-timer for the 1250 corresponding group. 1252 3 If the no-data flag is set, the DR clears the Register-flag 1253 and initializes the Register-flag-timer in the corresponding 1254 (S,G) entry(ies). 1256 When a Register-flag-timer expires, the corresponding entry(ies) 1257 Register flag is set to 1 to reinstigate encapsulation of data 1258 packets in Register messages. 1260 3.5.2 Receiving Register Messages and Sending Register-Acks 1262 When a router (i.e., the RP) receives a Register message, the 1263 router does the following: 1265 1 Decapsulates the data packet, and checks for a corresponding 1266 (S,G) entry. 1268 1 If a (S,G) entry exists and 1269 the packet arrived from the decapsulation 1270 process, the packet is forwarded but the SPT bit is left 1271 cleared (0). If the SPT bit is 1, the packet is dropped. 1273 2 If there is no (S,G) entry, but there is a (*,G) entry, 1274 the packet is forwarded according to the (*,G) entry. 1276 3 If there is no G related entry, the RP initializes one 1277 with a null oif list and the iif null. A timer for the 1278 entry is also initialized. 1280 The (S,G) state timer is reset by packets arriving from that 1281 source to that group. If the Register message contains a 1282 null-data portion, the (S,G) state timer is still reset. 1284 2 If the Ack-Request flag is set in the Register message, or if 1285 the matching (S,G) or (*,G) state contains a null oif list, 1286 the RP unicasts a Register-Ack message to the source of the 1287 Register message. If the relevant entry, either (S,G) or 1288 (*,G), has a null oif list, then the no-data flag is set; in 1289 the latter case, the source-address field is set to the 1290 wildcard value (all 0's). This message is not processed by 1291 intermediate routers, hence no (S,G) state is constructed 1292 between the active RP and the source. Register-Acks are rate 1293 limited. 1295 3 If the Register message arrival rate warrants it and there is 1296 no existing (S,G) entry, the RP sets up a (S,G) forwarding 1297 entry with the outgoing interface list, excluding iif(S,G), 1298 copied from the (*,G) outgoing interface list, its SPT-bit is 1299 initialized to 0. The (S,G) state entry includes the RP- 1300 Address in the RP-Annotated field. A timer is set for the 1301 (S,G) entry and this timer is reset by receipt of data packets 1302 for (S,G). The (S,G) entry causes the RP to send a Join/Prune 1303 message for the indicated group towards the source of the 1304 register message. The Join/Prune message includes the RP's 1305 address in the RP-Address-1 field for that group. The 1306 Join/Prune message includes the source's address in the Join 1307 list with its RP Annotated-bit set to 1. 1309 If the (S,G) oif list becomes null, Join/Prune messages will 1310 not be sent towards the source, S. 1312 4 If the currently active RP is not the preferred RP, it 1313 periodically polls the preferred RP(s) (all the RPs that 1314 appear before it in the ordered RP-list). When one of the 1315 preferred RPs becomes reachable, the active alternate RP 1316 unicasts a Register-Ack to the sources' first-hop routers; the 1317 message contains the address of the now-reachable and 1318 preferred RP in the active-RP-address field. See the section 1319 on RP Polling for more details. 1321 3.6 Poll and Poll-Response 1323 The Poll message is used by an alternate RP to check the status of 1324 preferred RPs. The Poll-Response message is sent from a recovered 1325 (or now reachable) preferred RP to the currently-active alternate- 1326 RP to notify it of this recovery. 1328 3.6.1 Sending Poll 1330 The following events trigger sending Poll messages: 1332 1 When a PIM router receives a Join/Prune message with its 1333 address in the join list with the RP-bit and WC-bit set (hence 1334 it knows it is the active RP), the router starts sending 1335 periodic Poll messages to preferred RPs; i.e. the RPs that are 1336 before it in the ordered RP-list included in the Join/Prune 1337 message (note that the first RP on the list does not send 1338 Polls). 1340 2 When a PIM router receives a Register message, it starts 1341 sending periodic Poll messages to the preferred RPs. 1343 Poll messages are sent with the Poll bit set. 1345 3.6.2 Receiving Poll and Sending Poll-Response 1347 When a PIM router receives a Poll message, it clears the Poll bit 1348 in the message (hence, the message becomes a Poll-Response) and 1349 sends the message back to its source. 1351 3.6.3 Receiving Poll-Response 1353 When the active-alternate RP receives a Poll-Response message, it 1354 performs the following: 1356 1 Includes the RP-Address of the now-reachable and preferred RP 1357 in the RP-Reachability messages sent down the (*,G) tree to 1358 receivers. 1360 2 Includes the RP-Address of the now-reachable and preferred RP 1361 in Register-Ack messages unicast to sources. 1363 A Register-Ack message is triggered when the active RP finds that a 1364 preferred-RP is reachable. 1366 3.7 Multicast Data Packet Forwarding 1368 Processing a multicast data packet involves the following steps: 1370 1 Lookup forwarding state based on a longest match of the source 1371 address, and an exact match of the destination address in the 1372 data packet and compare the RPF check on the source address in 1373 the packet header with the { iif/} specified in the forwarding 1374 entry. 1376 2 If the packet arrived on the interface found in the matching- 1377 entry's { iif/} field: 1379 1 Forward the packet to the { oif/} list for that entry and 1380 reset the entry's timer. 1382 2 If the entry's SPT-bit is cleared, set the SPT-bit for 1383 that entry. If (*,G) also exists and their incoming 1384 interfaces are different, trigger a (S,G) prune with RP- 1385 bit set towards the active RP. 1387 3 If the source of the packet is a directly-connected host 1388 and the router is the DR on a multi-access network, check 1389 the Register flag associated with the (S,G) entry. If it 1390 is set, then the router encapsulates the data packet in a 1391 register message and sends it to the active RP. 1393 This covers the common case of a packet arriving on the RPF 1394 interface to the source or RP and being forwarded to all 1395 joined branches. It also detects when packets arrive on the 1396 SP-tree, and triggers their pruning from the RP-tree. If it is 1397 the DR for the source, it sends data packets encapsulated in 1398 PIM-Registers to the RPs. 1400 3 If the packet matches to an entry but did not arrive on the 1401 the interface found in the entry's { iif/} field, check the 1402 SPT-bit of the entry. If the SPT-bit is set, drop the packet. 1404 If the SPT-bit is cleared, then lookup the (*,G) entry for the 1405 packet. If the packet arrived on the { iif/} found in (*,G), 1406 forward the packet to the { oif/} list of the (S,G) entry. 1407 This covers the case when a data packet matches on a (S,G) 1408 entry for which the SP-tree has not yet been completely 1409 established upstream. 1411 4 If the packet does not match to any entry, but the source of 1412 the data packet is a local, directly-connected host, and if 1413 the router is the DR on a multi-access LAN and knows of the 1414 active RP associated with the destination group, G, then the 1415 DR checks the register flag associated with the local sender 1416 (if there is no such a register flag, a new register flag, 1417 associated with the local sender, is created and set), the 1418 data packet is encapsulated in a register message and sent to 1419 the active RP. 1421 5 If the packet does not match to any entry, and it is not a 1422 local host or the router is not the DR, drop the packet. 1424 3.8 Data triggered switch to shortest path tree (SP-tree) 1426 When a (*,G) entry is created, a data rate counter may be initiated 1427 at the last-hop routers. The counter is incremented with every data 1428 packet received for directly connected members of an SM group, if 1429 the longest match is (*,G). If and when the data rate for the group 1430 exceeds a certain configured threshold (t1), the router initiates 1431 'source-specific' data rate counters for the following data 1432 packets. Then, each counter for a source, is incremented when 1433 packets matching on (*,G) are received from that source. If the 1434 data rate from the particular source exceeds a configured threshold 1435 (t2), a (S,G) entry is created and a Join/Prune message is sent 1436 towards the source. If the RPF interface for (S,G) is 1437 not the same as that for (*,G), then the SPT-bit is cleared in the 1438 (S,G) entry. Other configured rules may be enforced to cause or 1439 prevent establishment of (S,G) state. 1441 3.9 Assert 1443 Asserts are used to resolve which of the parallel routers connected 1444 to a multi-access LAN is responsible for forwarding packets onto 1445 the LAN. 1447 3.9.1 Sending Asserts 1449 The following Assert rules are provided when a multicast packet is 1450 received on an outgoing multi-access interface of an existing (S,G) 1451 entry: 1453 1 Do unicast routing table lookup on source IP address from data 1454 packet, and send assert on interface for source IP address in 1455 data packet; include metric preference of routing protocol and 1456 metric from routing table lookup. 1458 2 If route is not found, use metric preference of 0x7fffffff and 1459 metric 0xffffffff. 1461 3 When an assert is sent for a (*,G) entry, the first bit in the 1462 metric preference (the RP-bit) is set to 1, indicating the 1463 data packet is routed down the RP-tree. 1465 Asserts are rate-limited by the router. 1467 3.9.2 Receiving Asserts 1469 When an assert is received the router performs a longest match on 1470 the source and group address in the assert message. The router 1471 checks the first bit of the metric preference (RP-bit). If the RP- 1472 bit is set, the router does a match on (*,G) entries, otherwise, 1473 the router matches (S,G) entries. If the interface that received 1474 the Assert message is in the { oif/} list of the matched entry, 1475 then this assert is targeted for this router and the message is 1476 processed as follows: 1478 1 Compare the metric received in the Assert with the one the 1479 router would have advertised in an assert. Note that, the 1480 metric preference should be treated as the high-order part of 1481 an assert metric comparison. If the value in the assert is 1482 less than the router's value, delete the interface from the 1483 entry. If the value is the same, compare IP addresses, if the 1484 routers address is less than the assert sender, delete the 1485 interface. 1487 2 If the router has won the election and there are directly 1488 connected members on the multi-access LAN, the router keeps 1489 the interface in its outgoing interface list. It acts as the 1490 forwarder for the LAN. 1492 3 If the router won the election but there are no directly 1493 connected members on the multi-access LAN, the router 1494 schedules to delete the interface. The LAN might be a stub LAN 1495 with no members (and no downstream routers). If no subsequent 1496 Join/Prunes are received, the router deletes the interface 1497 from the outgoing interface list; otherwise it keeps the 1498 interface in its outgoing interface and acts as the forwarder 1499 for the LAN. 1501 The winning router should send out an assert message including its 1502 own metric to that outgoing interface, so the other router will 1503 prune that interface from its forwarding entry. Also, when an 1504 assert is received, the router performs an exact match based on the 1505 source address, group address and the RP-bit of the metric 1506 preference in the assert message. Note that, this is not a longest 1507 match, only exact state will be matched. If there is no such state, 1508 then the router drops the assert message. Otherwise, If the 1509 interface that received the assert matches the incoming interface 1510 of the exactly matched entry, then the assert message is processed 1511 as follows: 1513 1 Downstream routers will select the upstream router with the 1514 smallest metric as their RPF neighbor. If two metrics are the 1515 same, the highest IP address is chosen to break the tie. 1517 2 If the downstream routers have downstream members, they must 1518 schedule a join to inform the upstream router that packets 1519 should be forwarded on the multi-access network. This will 1520 cause the upstream forwarder to cancel its delayed deletion of 1521 the interface. 1523 3.10 Candidate-RP-Advertisements 1525 Candidate-RP-Advertisements are low frequency PIM-messages sent by 1526 PIM routers willing to become RPs. The messages are sent to a 1527 well-known multicast group. Group initiators use these 1528 advertisements to build the RP-list for the group. 1530 Candidate-RP-Advertisements carry group address and group mask 1531 fields. This enables the advertising router to limit the 1532 advertisement to a certain range or scope of groups. The router may 1533 enforce this scope acceptance when receiving Registers or 1534 Join/Prune messages. 1536 3.11 Processing Timer Events 1538 { Editors Note: This subsection needs some more work to be 1539 complete. We decided we should have a separate section on timer 1540 processing but we have a bit more work to do before this section is 1541 complete, ie. before ALL timers used in PIM are described here in 1542 detail. Timers are also discussed individually in the sections that 1543 pertain to the protocol messages that they trigger/affect.} 1545 In this subsection we mention some critical timer events that are 1546 not always associated with the receipt or sending of messages and 1547 therefore are not fully covered by earlier subsections. 1549 Each (S,G) and (*,G) entry has timers associated with it. There are 1550 multiple timers maintained: one for the multicast routing entry 1551 itself and one for each interface in the outgoing interface list. 1553 Timers on entries are handled as follows: 1555 1 The { S-timer} of a (S,G) entry is reset whenever data packets 1556 for (S,G) are forwarded, or when a PIM-Register is received 1557 from S. 1559 2 The entry-timer for a (*,G) entry is reset when any of its 1560 oif timers gets reset. 1562 3 The S-timer for a (S,G) RP-bit entry is reset whenever a (S,G) 1563 prune with RP-bit set is received. 1565 Each timer expires after 3 times the refresh period; a typical 1566 value is 3 minutes (because a typical Join/Prune refresh interval 1567 is 1 minute.) 1569 The RP-Group-mapping timer is a group-specific, not source- 1570 specific, timer, that is initialized when a DR first receives an 1571 RP-Report message for a particular group. The timer is reset when 1572 the DR receives an IGMP RP-Report for that group. So long as this 1573 timer is non--zero, the DR will enable periodic null-Register 1574 messages to keep track of RP liveness. 1576 A timer is also maintained for each outgoing interface listed in 1577 each (S,G) or (*,G) entry. Each oif timer is managed as follows. 1579 1 The timer is set when the interface is added. 1581 2 The timer is reset each time a Join/Prune message or an IGMP 1582 membership report for G is received on that interface for that 1583 forwarding entry (i.e., (*,G)). 1585 3 When a timer is reset for an outgoing interface listed in a 1586 (*,G) entry, the timers are reset for that interface, in all 1587 existing (S,G) entries whose oif list contains that interface. 1588 Because some of the outgoing interfaces in (S,G) entry are 1589 copied from the (*,G) outgoing interface list, they may not 1590 have explicit (S,G) join messages from some of the downstream 1591 routers (i.e., where members are joining to the (*,G) tree 1592 only). 1593 [*] 1595 _________________________ 1596 [*] If there are sources in the prune list of the (*,G) 1597 join, then the timers for arriving interface will first 1598 be reset for those sources, and then this interface 1599 will be deleted from these same entries; producing a 1600 correct result, even though the updating of the timers 1601 was unnecessary. An implementation could optimize this 1602 by checking the prune list before processing the join 1603 list. 1605 4 When an outgoing interface timer expires, the corresponding 1606 outgoing interface is deleted from the outgoing interface 1607 list. 1609 A deletion timer is used to schedule deletion of multicast 1610 forwarding entries. Entries may be scheduled for deletion when 1611 their oif lists become null: 1613 1 When the oif list of an (S,G) entry becomes null, and the RP- 1614 bit is not set to 1, the entry is scheduled for deletion. 1616 [*] 1618 Once the (S,G) is timed out, it may be recreated when the next 1619 Join/Prune arrives. 1621 When the oif list for a (*,G) entry is null in a router that 1622 is not a DR or the RP, the entry is deleted. 1624 2 When the oif list for a (*,G) entry is null in the router that 1625 is the RP for that entry, the entry is scheduled for deletion 1626 (to allow time for polling preferred RPs). 1628 3 When the oif list for a (*,G) entry is null in a router that 1629 is the DR, and the RPF neighbor to the RP is the LAN, then the 1630 (*,G) entry is kept alive even though the oif list is null. 1632 4 When a (*,G) entry is deleted, all associated (S,G,RPbit) 1633 entries are also deleted. 1635 The RP-timer is a timer associated with the active RP per group. 1637 _________________________ 1638 [*] (S,G) entries with the RP-bit set, i.e., (S,G) RP- 1639 bit entries, are kept alive by receipt of Prunes. We do 1640 not want to delete such entries if a (*,G) entry ex- 1641 ists; otherwise, data packets will travel down both the 1642 RP-tree and SP-tree. While this would not result in 1643 periodic duplicates (because of the RPF check), it 1644 would waste network bandwidth. 1646 1 When an RP-Reachability message is received at the receivers' 1647 last hop routers the RP timer is reset. RP-Reachability 1648 messages contain the time-out period. The RP timer must be set 1649 to this value. 1651 2 When a Register-Ack or Join/Prune with the RP-annotate bit and 1652 RP address included is received at a DR with the corresponding 1653 (S,G) state, the associated RP timer is updated; the RP timer 1654 is set to 270 seconds, or to the Holdtime in the Join/Prune 1655 message, respectively. 1657 { Editors Note: The Assert timer sections were added recently. Will 1658 be sanity-checked for next I-D submission.} 1660 Routers on multiaccess LANs have Assert Timers. This timer is set 1661 in the downstream router(s) when one of the upstream routers on the 1662 LAN wins an Assert and becomes the upstream neighbor, in conflict 1663 with the unicast routing table's RPF upstream neighbor. When this 1664 timer expires, the downstream router should change its RPF neighbor 1665 back to the unicast routing table's RPF neighbor so as to reflect 1666 topology changes. 1667 TBD 1669 Another timer associated with Asserts is the Assert Rate-limit 1670 timer referred to in the section on Processing Assert messages. The 1671 Assert Rate-limit timer is reset whenever an Assert message is 1672 sent. An Assert message is not sent for a particular oif unless the 1673 Assert Rate-limit timer expires. 1675 4 Packet Formats 1677 RFC-1112, see [5], specifies two types of IGMP packets for hosts 1678 and routers to convey multicast group membership and reachability 1679 information. An IGMP Host-Query packet is transmitted periodically 1680 by routers to ask hosts to report multicast groups of which they 1681 are members. An IGMP Host- Report packet is transmitted by hosts in 1682 response to received queries advertising group membership. 1684 This section introduces new types of IGMP packets that are used by 1685 PIM routers. All PIM control messages are encoded in IGMP messages. 1687 4.1 IGMP Fixed Header The fixed header packet format is: 1689 0 1 2 3 1690 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 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 |Version| Type | Code | Checksum | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Address | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 Version 1698 This memo specifies version 1 of IGMP. 1700 Type There are nine types of IGMP messages: 1702 1 = Host Membership Query 1703 2 = Host Membership Report 1704 3 = Router DVMRP Messages 1705 4 = Router PIM Messages 1706 5 = Cisco Trace Messages 1707 6 = New Host Membership Report 1708 7 = Host Membership Leave 1709 14 = Mtrace Response 1710 15 = Mtrace Request 1712 Code Codes for specific message types. Used only by DVMRP and PIM. 1713 PIM codes are: 1715 0 = Router-Query 1716 1 = Register 1717 2 = Register-Ack 1718 3 = Join/Prune 1719 4 = RP-Reachability 1720 5 = Assert 1721 6 = Graft 1722 7 = Graft-Ack 1723 8 = Candidate-RP-Advertisement 1724 9 = Poll 1726 Checksum 1727 The checksum is the 16-bit one's complement of the one's 1728 complement sum of the entire IGMP message. For computing the 1729 checksum, the checksum field is zeroed. 1731 Address 1732 PIM Version field when IGMP type is PIM. 1734 4.2 PIM Fixed Header 1736 The PIM fixed header carries the PIM version number, in addition to 1737 a reserved field and address length specifier fields. 1739 0 1 2 3 1740 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 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 |PIM Ver| Reserved | Addr length | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 PIM Ver 1746 PIM Version number is 2. 1748 Reserved 1749 Transmitted as zero, ignored on receipt. 1751 Addr length 1752 Address length in bytes. Throughout this section this would 1753 indicate the number of bytes in the Address field of an 1754 address. 1756 4.3 Encoded Source and Group Address formats 1758 1 Unicast address: Only the address is included. The length of 1759 the unicast address in bytes is specified in the 'Addr length' 1760 field in the header. 1762 2 Encoded-Group-Address: Takes the following format: 1764 0 1 2 3 1765 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 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 | Reserved | Mask Len | Group multicast Address ... | 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | ...Group multicast Address ...| 1770 +-+-+-+-+-+-+-+-+-+-+++++++ 1771 Reserved 1772 Transmitted as zero. Ignored upon receipt. 1774 Mask Len 1775 The Mask length is 8 bits. The value is the number of 1776 contiguous bits left justified used as a mask which 1777 describes the address. It is less than or equal to Addr 1778 length * 8. If the message is sent for a single group 1779 then the Mask length should equal Addr length * 8. In 1780 version 2 of PIM, it is strongly recommend that this 1781 field be set to 32 for IPv4 and 128 for IPv6. 1783 Group multicast Address 1784 contains the group address, and has number of bytes 1785 equal to that specified in the Addr length field. 1787 3 Encoded-Source-Address: Takes the following format: 1789 0 1 2 3 1790 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 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Rsrvd |A|S|W|R| Mask Len | Source Address ... | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | ... Source Address | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+++-+ 1797 Reserved 1798 Transmitted as zero, ignored on receipt. 1800 A,S,W,R 1801 See section7 ef{Join_format} for details. 1803 Mask Length 1804 Mask length is 8 bits. The value is the number of 1805 contiguous bits left justified used as a mask which 1806 describes the address. The mask length must be less than 1807 or equal to Addr Length * 8. If the message is sent for a 1808 single source then the Mask length should equal Addr 1809 length * 8. In version 2 of PIM, it is strongly recommend 1810 that this field be set to 32 for IPv4. 1812 Source Address 1813 The address length is indicated from the Addr length 1814 field at the beginning of the header. For IPv4, the 1815 address length is 4 octets. 1817 4.4 PIM-Query Message 1819 It is sent periodically by PIM routers on all interfaces. 1821 0 1 2 3 1822 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 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 |Version| Type | Code | Checksum | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 |PIM Ver| Reserved | Addr length | 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Reserved | Holdtime | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 Version, Type, Code, Checksum, PIM Version 1832 Described above. 1834 Reserved 1835 Transmitted as zero, ignored on receipt. 1837 Addr length 1838 not used. 1840 Holdtime 1841 The amount of time a receiver should keep the neighbor 1842 reachable, in seconds. 1844 4.5 PIM-Register Message 1846 It is sent by the Designated Router (DR) to the active RP when a 1847 multicast packet needs to be transmitted on the RP-tree. Source IP 1848 address is set to the address of the DR, destination IP address is 1849 to the RP's address. 1851 0 1 2 3 1852 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 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 |Version| Type | Code | Checksum | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 |PIM Ver| Reserved | Addr length | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 |D|Q| Reserved |RP-Cnt | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Unicast-RP-Address-1 | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | . . | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | Unicast-RP-Address-m | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | | 1867 Multicast data packet 1868 | | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 Version, Type, Code, Checksum, PIM Version 1872 Described above. 1874 Addr length 1875 The unicast address length in bytes. Specifies the address 1876 length of the Unicast-RP-Address fields. 1878 D The data flag, when cleared indicates no-data included in the 1879 Multicast data packet section. The D flag is cleared in null- 1880 Registers. 1882 Q The Ack-Request flag, is a 1 bit value. When set, signals 1883 Register-Acks to be sent in response. The Q flag is set 1884 periodically to trigger periodical Register-Acks in response. 1886 RP-Cnt The number of RP-Addresses include in the RPlist. 1888 Unicast-RP-Address-1 .. m 1889 The ordered RPlist, listed in order of preference. 1891 Multicast data packet 1892 The original packet sent by the source. For periodic sending 1893 of registers with the D flag cleared, this part contains only 1894 the IP header. 1896 4.6 PIM-Register-Ack Message 1898 It is triggered by the Ack-Request flag set in a Register message. 1899 A Register-Ack is unicast from the active RP to the sender of the 1900 Register message. Source IP address is the address to which the 1901 register was addressed. Destination IP address is the source 1902 address of the register message. 1904 0 1 2 3 1905 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 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 |Version| Type | Code | Checksum | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 |PIM Ver| Reserved | Addr length | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 | Encoded-Group Address | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 | Unicast-Source Address | 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | Unicast-Active-RP-Address | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 |N| Reserved | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 Version, Type, Code, Checksum, PIM Version, Addr length 1922 Described above. 1924 Encoded-Group Address 1925 Format described above. Note that for Register-Acks the Mask 1926 len field should contain Addr length * 8 (32 for IPv4), if the 1927 message is sent to a single group. 1929 Unicast-Source Address 1930 IP host address of source from multicast data packet in 1931 register. The length of this field in bytes is specified in 1932 the Addr length field. 1934 Unicast-Active-RP-Address 1935 The address of the now reachable and preferred RP. The length 1936 of this field in bytes is specified in Addr length field. If 1937 included, and different than the source of the Register-Ack, 1938 then the sender's DR would know to register to the RP that is 1939 given in the RP-Address field. If this field does not contain 1940 a valid IP unicast address it should be ignored. 1942 N No-Data flag. A bit, when set informs the source not to send 1943 any data in the Registers. 1945 4.7 Join/Prune Message 1947 It is sent by routers towards upstream sources and RPs. A join 1948 creates forwarding state and a prune destroys forwarding state. 1949 Joins are sent to build shared trees (RP trees) or source trees 1950 (SPT). Prunes are sent to prune source trees when members leave 1951 groups as well as sources that do not use the shared tree. 1953 0 1 2 3 1954 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 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 |Version| Type | Code | Checksum | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 |PIM Ver| Reserved | Addr length | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | Unicast-Upstream Neighbor Address | 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 | Reserved | Num groups | Holdtime | 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 | Encoded-Multicast Group Address-1 | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | Reserved |RP-Cnt |Number of Join Srcs|NumberOf Prune Srcs| 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 | Unicast-RP Address-1 | 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | . | 1971 | . | 1972 | . | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | Unicast-RP Address-m | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | Encoded-Join Source Address-1 | 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 | . | 1979 | . | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Encoded-Join Source Address-n | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | Encoded-Prune Source Address-1 | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | . | 1986 | . | 1987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 | Encoded-Prune Source Address-n | 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 | . | 1991 | . | 1992 | . | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 | Encoded-Multicast Group Address-n | 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 | Reserved |RP-Cnt |Number of Join Srcs|NumberOf Prune Srcs| 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | Unicast-RP Address-1 | 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | . | 2001 | . | 2002 | . | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | Unicast-RP Address-m | 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | Encoded-Join Source Address-1 | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | . | 2009 | . | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | Encoded-Join Source Address-n | 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 | Encoded-Prune Source Address-1 | 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | . | 2016 | . | 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | Encoded-Prune Source Address-n | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 Version, Type, Code, Checksum, PIM Version 2022 Described above. 2024 Addr Length 2025 The length in bytes of the encoded source addresses in the 2026 join and prune lists and the unicast RP-Addresses. 2028 Upstream Neighbor Address 2029 The IP address of the RPF or upstream neighbor. 2031 Reserved 2032 Transmitted as zero, ignored on receipt. 2034 Holdtime 2035 The amount of time a receiver should keep the Join/Prune 2036 state alive, in seconds. 2038 Number of Groups 2039 The number of multicast group sets contained in the message. 2041 Encoded-Multicast group address 2042 For format description see section 2043 4.3. .IP "RP-Cnt" 2044 The RP count field contains the number of RP addresses 2045 included in the message for a specific group. For (*,G) 2046 Join/Prune messages (RP count $>$=1); depending on the number 2047 of RP's in the RPlist. For (S,G) Join/Prune messages sent from 2048 the RP to a source, the RP count is set to 1. For (S,G) 2049 Join/Prune messages in which all sources in the Join list have 2050 their RP Annotated bits (A-bits) set to 0, the RP-Cnt is set 2051 to 0. 2053 Unicast-RP Address-1 .. m 2054 This is a list of the RPs. RPs are listed in preference order 2055 received. 2057 Number of Join Sources 2058 Number of join source addresses listed for a given group. 2060 Join Source Address-1 .. n 2061 This list contains the sources that the sending router will 2062 forward multicast datagrams for if received on the interface 2063 this message is sent on. 2065 See format section 4.3. The fields explanation for the 2066 Encoded-Source-Address format follows: 2068 Reserved 2069 Described above. 2071 A RP Annotated-bit. When set, the RP Address is annotated 2072 in corresponding (S,G) entry. The A bit is always set to 2073 0 for sources in the prune list. 2075 S The Sparse bit is a 1 bit value, it is used by routers 2076 on the shortest path tree to indicate the group is in 2077 sparse-mode (since they do not know about any RPs for the 2078 group). This indicates to receivers to send periodic 2079 Join/Prune messages towards the source. When set to 1, 2080 the (S,G) should be treated in sparse-mode, otherwise, it 2081 should be treated in dense-mode. 2083 W The WC bit is a 1 bit value. If 1, the join or prune 2084 applies to the (*,G) entry. If 0, the join or prune 2085 applies to the (S,G) entry where S is Source Address. 2086 Joins and prunes sent towards the RP should have this bit 2087 set. 2089 R The RP bit is a 1 bit value. If 1, the information about 2090 (S,G) is sent towards the RP. If 0, the information 2091 should be sent about (S,G) toward S, where S is Source 2092 Address. 2094 Mask Length, Source Address 2095 Described above. 2097 Represented in the form of $< WCbit >< RPbit >< Mask length >< 2098 Source address>$: 2100 A source address could be a host IP address : 2102 $< 0 >< 0 >< 32 >< 192.1.1.17 >$ 2104 A source address could be the RP's IP address : 2106 $< 1 >< 1 >< 32 >< 131.108.13.111 >$ 2108 A source address could be a subnet address to prune from the 2109 RP-tree : 2111 $< 0 >< 1 >< 28 >< 192.1.1.16 >$ 2113 A source address could be a general aggregate : 2115 $< 0 >< 0 >< 16 >< 192.1.0.0 >$ 2117 Number of Prune Sources 2118 Number of prune source addresses listed for a group. 2120 Prune Source Address-1 .. n 2121 This list contains the sources that the sending router does 2122 not want to forward multicast datagrams for when received on 2123 the interface this message is sent on. See format below. 2125 4.8 PIM-RP-Reachability Message 2127 Each RP will send RP-Reachability messages to all routers on its 2128 distribution tree for a particular group. These messages are sent 2129 so routers can detect that an RP is reachable. Routers that have 2130 attached host members for a group will process the message. 2132 The RPs will address the RP-Reachability messages to 224.0.0.2 2133 (All-Routers-Group). Routers that have state for the group with 2134 respect to the RP distribution tree will propagate the message. 2135 Otherwise, the message is discarded.If an RP address timer expires, 2136 the router should attempt to send a PIM join message towards an 2137 alternate RP provided for that group if one is available. 2139 0 1 2 3 2140 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 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 |Version| Type | Code | Checksum | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 |PIM Ver| Reserved | Addr length | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | Encoded-Group Address | 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Unicast-RP Address | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | Reserved | Holdtime | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 Version, Type, Code, Checksum, PIM Version, Addr length 2155 Described above. 2157 Encoded-Group Address 2158 The group address the RP is associated with. Format 2159 described earlier. 2161 Unicast-RP Address 2162 The rendezvous point IP address of the sender. If the RP 2163 Address field is different than the currently active RP, then 2164 the member's DR should join to the RP given in that field. If 2165 this field does not contain a valid IP unicast address it 2166 should be ignored. The length of this field in bytes is 2167 specified in Addr length. 2169 Reserved 2170 Transmitted as zero, ignored on receipt. 2172 Holdtime 2173 The amount of time in seconds receivers of this message 2174 should consider the RP reachable. 2176 4.9 PIM-Assert Message 2178 The PIM-Assert message is sent when a multicast data packet is 2179 received on an outgoing interface corresponding to the (S,G) or 2180 (*,G) associated with the source. 2182 0 1 2 3 2183 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 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 |Version| Type | Code | Checksum | 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 |PIM Ver| Reserved | Addr length | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | Encoded-Group Address | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | Unicast-Source Address | 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 |R| Metric Preference | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | Metric | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 Version, Type, Code, Checksum, PIM Version, Addr length 2200 Described above. 2202 Encoded-Group Address 2203 The group address to which the data packet was addressed, and 2204 which triggered the Assert. Format previously described. 2206 Unicast-Source Address 2207 Source IP address from IP multicast datagram that triggered 2208 the Assert packet to be sent. The length of this field in 2209 bytes is specified in Addr length. 2211 R RP bit is a 1 bit value. If the IP multicast datagram that 2212 triggered the Assert packet is routed down the RP tree, then 2213 the RP bit is 1; if the IP multicast datagram is routed down 2214 the SPT, it is 0. 2216 Metric Preference 2217 Preference value assigned to the unicast routing protocol 2218 that provided the route to Host address. 2220 Metric The unicast routing table metric. The metric is in units 2221 applicable to the unicast routing protocol used. 2223 4.10 PIM-Graft Message 2225 Used in dense-mode. Refer to PIM dense mode specification. 2227 4.11 PIM-Graft-Ack Message 2229 Used in dense-mode. Refer to PIM dense mode specification. 2231 4.12 Candidate-RP-Advertisement 2233 0 1 2 3 2234 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 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 |Version| Type | Code | Checksum | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 |PIM Ver| Reserved | Addr length | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 | Intended-Hop-Count | Holdtime | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | Encoded-Group Address | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 Version, Type, Code, Checksum, PIM Version 2246 Described above. 2248 Addr length 2249 not used in this message. 2251 Intended-Hop-Count 2252 This field is copied from the original TTL field when the 2253 advertisement is originated. It is not modified by 2254 intermediate routers. 2256 Holdtime 2257 The amount of time the advertisement is valid. This field 2258 allows advertisements to be aged out. 2260 Encoded-Group Address 2261 The group address the RP is associated with. Format 2262 previously described. 2264 4.13 PIM-Poll and Poll-Response Message 2265 0 1 2 3 2266 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 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 |Version| Type | Code | Checksum | 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 |PIM Ver| Reserved | Addr length | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 |P| Reserved | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 Version, Type, Code, Checksum, PIM Version 2276 Described above. 2278 Addr length 2279 not used in this message. Transmitted as zero, and ignored 2280 upon receipt. 2282 P The poll bit. When set indicates a Poll message, and when 2283 cleared indicates a Poll-Response. 2285 5 Pseudocode 2287 { Editors Note: This section is still in progress.} In the 2288 future the pseudocode will be available by anonymous ftp at 2289 catarina.usc.edu:pub/estrin/pim/pim.sm.pseudocode. 2291 6 Acknowledgments 2293 Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul 2294 Francis, Joel Halpern, Horst Hodel, Stephen Ostrowski, Dave 2295 Thaler, and Lixia Zhang provided detailed comments on previous 2296 drafts. The authors of [8] and membership of the IDMR WG 2297 provided many of the motivating ideas for this work and useful 2298 feedback on design details. 2300 This work was supported by the National Science Foundation, 2301 ARPA, cisco Systems and Sun Microsystems. 2303 References 2305 1. S.Deering, D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, 2306 P.Sharma, and A.Helmy. Protocol independent multicast (pim) : 2307 Motivation and architecture. 2308 Internet Draft, May 1995. 2310 2. S.Deering, D.Estrin, D.Farinacci, B.Fenner, V.Jacobson, and 2311 A.Helmy. Interoperability architecture and mechanisms for pim-sm. 2312 Internet Draft, June 1995. 2314 3. S.Deering, D.Estrin, D.Farinacci, and V.Jacobson. Protocol 2315 independent multicast (pim), dense mode protocol : Specification. 2316 Internet Draft, March 1994. 2318 4. D.Waitzman S.Deering, C.Partridge. Distance vector multicast 2319 routing protocol, nov 1988. RFC1075. 2321 5. S.Deering. Host extensions for ip multicasting, aug 1989. RFC1112. 2323 6. S.Deering. Igmp. { ???}, November 1994. 2325 7. J.Moy. Multicast extension to ospf. 2326 Internet Draft, September 1992. 2328 8. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. In 2329 Proceedings of the ACM SIGCOMM, San Francisco, 1993.