idnits 2.17.1 draft-ietf-idmr-pim-sm-spec-05.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-18) 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. ** Expected the document's filename to be given on the first page, but didn't find any ** 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 21) being 61 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. (A line matching the expected section header was found, but with an unexpected indentation: ' 3.10 Security' ) ** 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. ** There are 846 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 39 instances of too long lines in the document, the longest one being 18 characters in excess of 72. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 ...' == (841 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. 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 41 looks like a reference -- Missing reference section? '3' on line 57 looks like a reference -- Missing reference section? '4' on line 115 looks like a reference -- Missing reference section? '5' on line 1744 looks like a reference -- Missing reference section? '6' on line 2361 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steven Deering (XEROX) 3 Internet Draft Deborah Estrin (USC) 4 Dino Farinacci (CISCO) 5 Mark Handley (UCL) 6 Ahmed Helmy (USC) 7 Van Jacobson (LBL) 8 Chinggung Liu (USC) 9 Puneet Sharma (USC) 10 David Thaler (UMICH) 11 Liming Wei (CISCO) 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][2]. This document describes 40 the protocol details. For the motivation behind the design and a 41 description of the architecture, see [1][2]. Section 2 summarizes 42 PIM-SM operation. It describes the protocol from a network 43 perspective, in particular, how the participating routers interact to 44 create and maintain the multicast distribution tree. Section 3 45 describes PIM-SM operations from the perspective of a single router 46 implementing the protocol; this section constitutes the main body of 47 the protocol specification. It is organized according to PIM-SM 48 message type; for each message type we describe its contents, its 49 generation, and its processing. 51 Section 4 provides packet format details. Sections 3.8 and 3.9 52 summarize the timers and flags referred to throughout this document. 54 The most significant functional changes since the January '95 version 55 involve the Rendezvous Point-related mechanisms, several resulting 56 simplifications to the protocol, and removal of the PIM-DM protocol 57 details to a separate [3] (for clarity). 59 2 PIM-SM Protocol Overview 61 In this section we provide an overview of the architectural 62 components of PIM-SM. 64 A router [*] 66 receives explicit Join/Prune messages from those neighboring routers 67 that have downstream group members. The router then forwards data 68 packets addressed to a multicast group, G, only onto those interfaces 69 on which explicit joins have been received. 71 A Designated Router (DR) sends periodic Join/Prune messages toward a 72 group-specific Rendezvous Point (RP) for each group for which it has 73 active members. Each router along the path toward the RP builds a 74 wildcard (any-source) forwarding state. for the group and sends 75 _________________________ 76 [*] All routers mentioned in this document are assumed 77 to be PIM-SM capable, unless otherwise specified. 79 messages on toward the RP. We use the term entry to refer to the 80 forwarding state maintained in a router to represent the distribution 81 tree. Each entry includes such things as the incoming interface from 82 which packets are accepted, the list of outgoing interfaces to which 83 packets are sent, timers, flag bits, etc. The wildcard forwarding 84 entry's incoming interface points toward the RP; the outgoing 85 interfaces point to the neighboring downstream routers that have sent 86 Join/Prune messages toward the RP. This forwarding state creates a 87 shared, RP-centered, distribution tree that reaches all group 88 members. When a data source first sends to a group, its DR unicasts 89 Register messages to the RP with the source's data packets 90 encapsulated within. If the data rate is high, the RP can send 91 source-specific Join/Prune messages back towards the source and the 92 source's data packets will follow the resulting forwarding state and 93 travel unencapsulated to the RP. Whether they arrive encapsulated or 94 natively, the RP forwards the source's decapsulated data packets down 95 the RP-centered distribution tree toward group members. If the data 96 rate warrants it, routers with local receivers can join a source- 97 specific, shortest path, distribution tree, and prune these source's 98 packets off of the shared RP-centered tree. Even if all receivers 99 switch to the shortest path tree, state for that source will be kept 100 at the RP, so that new members that join the RP-centered tree will 101 receive data packets from the source. For low data rate sources, 102 neither the RP, nor last-hop routers need join a source-specific 103 shortest path tree and data packets can be delivered via the shared, 104 RP-tree. 106 The following subsections describe SM operation in more detail, in 107 particular, the control messages, and the actions they trigger. 108 Section 3 describes protocol operation from an implementors 109 perspective, i.e., the actions performed by a single router. 111 2.1 Local hosts joining a group 113 In order to join a multicast group, G, a host sends an IGMP Host- 114 Membership-Report message identifying the particular group. As 115 specified in [4], IGMP Host-Membership-Report messages are sent in 116 response to a directly-connected router's IGMP Host-Membership-Query 117 message (see figure 1) [*] From this point on we refer to such a 118 host as a receiver, R, (or member) of the group G. 120 _________________________ 121 [*] All figures used in this section are for illustra- 122 tion and are not intended to be complete. For complete 123 and detailed protocol action see Section 3 . 125 Fig. 1 Example: how a receiver joins, and sets up shared tree 127 When a DR receives an IGMP Host-Membership-Report for a new group, G, 128 the DR looks up the associated RP. The DR (e.g., router A in figure 129 1) creates a wildcard multicast forwarding entry for the group, 130 referred to here as a (*,G) entry; if there is no more specific match 131 for a particular source, the packet will be forwarded according to 132 this entry. 134 The RP address is included in a special field in the forwarding entry 135 and is included in periodic upstream Join/Prune messages. The 136 outgoing interface is set to that over which the IGMP Host- 137 Membership-Report was received from the new member. The incoming 138 interface is set to the interface used to send unicast packets to the 139 RP. The RPT-bit flag associated with this entry is also set to 1, 140 indicating that this entry, (*,G), represents state on the shared 141 RP-tree. Each DR on the RP-tree with directly connected members sets 142 a timer for this entry. If the timer expires and the DR has neither 143 local members nor downstream receivers, the (*,G) state is deleted. 144 If the DR does have local members, it refreshes the (*,G) entry timer 145 each time it gets an IGMP Host-Membership-Report. 147 2.2 Establishing the RP-rooted shared tree 149 Triggered by the (*,G) state, the DR creates a Join/Prune message 150 with the RP address in its join list and the the WC-bit and RPT-bit 151 set to 1. The prune list is left empty. When the RPT-bit is set to 1 152 it indicates that the join is associated with the shared RP-tree and 153 therefore the Join/Prune message is propagated along the RP-tree. 154 When the WC-bit is set to 1 it indicates that the address is an RP 155 and the downstream receivers expect to receive packets from all 156 sources via this (shared tree) path; WC stands for wildcard 157 [*] 159 Each upstream router creates or updates its multicast forwarding 160 _________________________ 161 [*] Note that the term RPT-bit is used to refer to both 162 the RPT-bit flags associated with forwarding entries, 163 and the RPT-bit included in each encoded address in a 164 Join/Prune message. 166 entry for (*,G) when it receives a Join/Prune with the RPT-bit and 167 WC-bit set. The interface on which the Join/Prune message arrived is 168 added to the list of outgoing interfaces (oifs) for (*,G). Based on 169 this entry each upstream router between the receiver and the RP sends 170 a Join/Prune message in which the join list includes the RP. The 171 packet payload contains Multicast-Address=G, Join=RP,WC-bit,RPT-bit, 172 Prune=NULL. 174 2.3 Hosts sending to a group 176 When a host starts sending multicast data packets to a group, 177 initially its DR must deliver each packet to the RP for distribution 178 down the RP-tree (see figure 2). The sender's DR initially 179 encapsulates each data packet in a Register message and unicasts it 180 to the RP for that group. The RP decapsulates each Register message 181 and forwards the enclosed data packet natively to downstream members 182 on the shared RP-tree. 184 Fig. 2 Example: a host sending to a group 186 If the data rate of the source warrants [*] 188 the use of a source-specific shortest path tree (SPT), the RP may 189 construct a new multicast forwarding entry that is specific to the 190 source, hereafter referred to as (S,G) state, and send periodic 191 Join/Prune messages toward the source. The routers between the source 192 and the RP build and maintain (S,G) state in response to these 193 messages and send (S,G) messages upstream toward the source. 195 The source's DR must stop encapsulating data packets in Registers 196 when (and so long as) it receives Register-Stop messages from the RP. 197 The RP triggers Register-Stop messages in response to Registers, if 198 the RP has no downstream receivers for the group (or for that 199 particular source), or if the RP has already joined the (S,G) tree 200 _________________________ 201 [*] This decision is a local policy established at the 202 RP. For example, when the Register rate exceeds a con- 203 figured threshold at the RP, this may warrant the use 204 of the SPT. 206 and is receiving the data packets natively. Each source's DR 207 maintains, per (S,G), a Register-bit and a Register-bit timer. The 208 Register-bit timer is started by the Register-Stop message; upon 209 expiration, the Register-bit is set to 1 and the source's DR resumes 210 sending data packets encapsulated in Register messages. 212 2.4 Switching from shared tree (RP-tree) to shortest path tree (SP- 213 tree) 215 When a router has directly-connected members, it first joins the 216 shared RP-tree. The router can switch to a source's shortest path 217 tree (SP-tree) after receiving packets from that source over the 218 shared RP-tree. The recommended policy is to initiate the switch to 219 the SP-tree after receiving a significant number of data packets 220 during a specified time interval from a particular source. To realize 221 this policy the router can monitor data packets from sources for 222 which it has no source-specific multicast forwarding entry and 223 initiate such an entry when the data rate exceeds the configured 224 threshold. As shown in figure 3, router `A' initiates a (S,G) state. 226 Fig. 3 Example: Switching from shared tree to shortest path tree 228 When a (S,G) entry is activated (and periodically so long as the 229 state exists), a Join/Prune message is sent upstream towards the 230 source, S, with S in the join list. The payload contains Multicast- 231 Address=G, Join=S, Prune=NULL. When the (S,G) entry is created, the 232 outgoing interface list is copied from (*,G), i.e., all local shared 233 tree branches are replicated in the new shortest path tree [*] In 234 this way when a data packet from S arrives and matches on this entry, 235 all receivers will continue to receive the source's packets along 236 this path. Note that (S,G) state must be maintained in each last-hop 237 router that is responsible for initiating and maintaining an SP-tree. 238 [*] 239 _________________________ 240 [*] In more complicated scenarios, other entries in the 241 router have to be considered. For details see Section 3. 242 [*] By last-hop router we mean the router that delivers 243 the packets to their ultimate end-system destination. 244 This is the router that monitors if there is group 245 membership and joins or prunes the appropriate distri- 246 Even when (*,G) and (S,G) overlap, both states are needed to trigger 247 the source-specific Join/Prune messages. (S,G) state is kept alive by 248 data packets arriving from that source. A timer, S-timer, is set for 249 the (S,G) entry and this timer is restarted whenever a data packet 250 for (S,G) is forwarded out at least one oif. When the S-timer expires 251 the state is deleted. 253 Only the RP and routers with local members can initiate switching to 254 the SP-tree; intermediate routers do not. Consequently, last-hop 255 routers create (S,G) state in response to data packets from the 256 source, S; whereas intermediate routers only create (S,G) state in 257 response to Join/Prune messages from downstream that have S in the 258 Join list [*] 260 The (S,G) entry is initialized with the SPT-bit cleared, indicating 261 that the shortest path tree branch from S has not yet been setup 262 completely, and the router can still accept packets from S that 263 arrive on the (*,G) entry's indicated incoming interface (iif). [*] 265 When a router with a (S,G) entry and a cleared SPT-bit starts to 266 receive packets from the new source S on the iif for the (S,G) entry, 267 and that iif differs from the (*,G) entry's iif, the router sets the 268 SPT-bit, and sends a Join/Prune message towards the RP, indicating 269 that the router no longer wants to receive packets from S via the 270 shared RP-tree. The Join/Prune message sent towards the RP includes S 271 in the prune list, with the RPT-bit set indicating that S's packets 272 should not be forwarded down this branch of the shared tree. If the 273 router receiving the Join/Prune message has (S,G) state (with or 274 without the forwarding entry's RPT-bit flag set), it deletes the 275 arriving interface from the (S,G) oif list. If the router has only 276 (*,G) state, it creates an entry with the RPT-bit flag set to 1. For 277 brevity we refer to an (S,G) entry that has the RPT-bit flag set to 1 278 _________________________ 279 bution trees in response. In general the last-hop 280 router is the Desgnated Router (DR) for the LAN. Howev- 281 er, under various conditions described later, a paral- 282 lel router connected to the same LAN may take over as 283 the last-hop router in place of the DR. 284 [*] For example, to implement the policy that source- 285 specific trees are only setup for high-data rate 286 source, a last-hop router might not create a (S,G) en- 287 try until it has received m data packets from the 288 source within some interval of n seconds. 289 [*] As in DVMRP, each PIM multicast forwarding entry 290 has an associated incoming interface on which packets 291 are expected to arrive. 293 as an (S,G)RPT-bit entry. This notational distinction is useful to 294 point out the different actions taken for (S,G) entries depending on 295 the setting of the RPT-bit flag. Note that a router can have no more 296 than one (S,G) entry for any particular S and G, at any particular 297 time; whether the RPT-bit flag is set or not. In other words, a 298 router never has both an (S,G) and an (S,G)RPT-bit entry for the same 299 S and G at the same time. The Join/Prune message payload contains 300 Multicast-Address=G, Join=NULL, Prune=S,RPT-bit. 302 A new receiver may join an existing RP-tree on which source-specific 303 prune state has been established (e.g., because downstream receivers 304 have switched to SP-trees). In this case the prune state must be 305 eradicated upstream of the new receiver to bring all sources' data 306 packets down to the new receiver. Therefore, when a (*,G) Join 307 arrives at a router that has any (Si,G)RPT-bit entries (i.e., entries 308 that cause the router to send source-specific prunes toward the RP), 309 these entries must be updated upstream of the router so as to bring 310 all sources' packets down to the new member. To accomplish this, each 311 router that receives a (*,G) Join/Prune message updates any existing 312 (S,G)RPT-bit entries. The router may also trigger a (*,G) join 313 upstream to cause the same updating of RPT-bit settings upstream and 314 pull down all active sources' packets. If the arriving (*,G) join has 315 some sources included in its prune list, then the corresponding 316 (S,G)RPT-bit entries are left unchanged (i.e., the RPT-bit remains 317 set and no oif is added). 319 2.5 Steady state maintenance of distribution tree (i.e., router state) 321 In the steady state each router sends periodic Join/Prune messages 322 for each active PIM forwarding entry; the Join/Prune messages are 323 sent to the neighbor indicated in the iif field of the corresponding 324 entry. These messages are sent periodically to capture state, 325 topology, and membership changes. A Join/Prune message is also sent 326 on an event-triggered basis each time a new forwarding entry is 327 established for some new source (note that some damping function may 328 be applied, e.g., a merge time). Join/Prune messages do not elicit 329 any form of explicit acknowledgment; routers recover from lost 330 packets using the periodic refresh mechanism. 332 2.6 Obtaining RP information 334 To obtain the RP information, all routers within a PIM domain collect 335 RP-Set messages. RP-Set messages are sent hop-by-hop within the 336 domain; the domain's bootstrap router (BSR) is responsible for 337 originating the RP-set messages. The BSR is elected dynamically 338 within each domain. 340 [*] 342 Routers then use the set of RPs to get the proper Group to RP 343 mapping. Details are as follows: 345 A (small) set of routers, within a domain, are configured as 346 candidate bootstrap routers. Initially, each of these candidates 347 includes its address in `RP-set' messages. Through a simple election 348 mechanism, a single bootstrap router (BSR) is elected for that domain 349 (see Section 3.6). 351 A set of routers within a domain are configured as candidate RPs (C- 352 RPs); typically these will be the same routers that are configured as 353 C-BSRs. Candidate RPs periodically unicast Candidate-RP-Advertisement 354 messages (C-RP-Advs) to the BSR of that domain. C-RP-Advs include the 355 address of the advertising C-RP, as well as an optional group address 356 and a mask length field, indicating the group prefix(es) for which 357 the candidacy is advertised. The BSR then includes a set of these 358 Candidate-RPs in the RP-Set messages, along with the corresponding 359 group prefixes (see Section 360 3.6.2). RP-Set messages are periodically sent hop-by-hop throughout 361 the domain. 363 Routers receive and store RP-Set messages originated by the BSR. When 364 a DR receives IGMP Host-Membership-Report (or a data packet) from a 365 directly connected host, for a group for which it has no entry, the 366 DR uses a hash function to map the pertinent group to one of the C- 367 RPs whose Group-prefix includes the group (see Section 3.7). The DR 368 then sends a Join/Prune message towards (or unicasts Registers to) 369 that RP. 371 The RP-Set message indicates liveness of the RPs included therein; if 372 an RP is included in the message, then it is tagged as `up' at the 373 routers, while RPs not included in the message are tagged as `down' 374 and removed from the list of RPs over which the hash algorithm acts. 375 Each router continues to use the contents of the most recently 376 received RP-set message until it receives a new RP-set message. 377 _________________________ 378 [*] A domain in this context is a contiguous set of 379 routers that all implement PIM and are configured to 380 operate within a common boundary defined by PIM Multi- 381 cast Border Routers (PMBRs). PMBRs connect each PIM 382 domain to the rest of the internet. 384 2.7 Interoperation with dense mode protocols such as DVMRP 386 In order to interoperate with networks that run dense-mode, 387 broadcast and prune, protocols, such as DVMRP, all packets generated 388 within a PIM-SM region must be pulled down to that region's PIM 389 Multicast Border Routers (PMBRs) and injected (i.e., broadcast) into 390 the DVMRP network. [*] 392 To achieve this capability, a special entry type, referred to as 393 (*,*,RP), must be supported by all PIM routers. For this reason we 394 include details about (*,*,RP) entry handling in this general PIM 395 specification. 397 A data packet will match on a (*,*,RP) entry if there is no more 398 specific entry (such as (S,G) or (*,G)) and the destination group 399 address in the packet maps to the RP listed in the (*,*,RP) entry. In 400 this sense, a (*,*,RP) entry represents an aggregation of all the 401 groups supported by that RP. PMBRs initialize (*,*,RP) state for each 402 RP in the domain's RPset. The (*,*,RP) state causes the PMBRs to send 403 Join/Prune messages toward each of the active RPs in the domain. As a 404 result distribution trees are built that carry all data packets 405 originated within the PIM domain (and sent to the RPs) down to the 406 PMBRs. 408 All PIM routers must be capable of supporting (*,*,RP) state and 409 interpreting associated Join/Prune messages. We describe the handling 410 of (*,*,RP) entries and messages throughout this document. However, 411 detailed PIM Multicast Border Router functions will be specified in a 412 separate interoperability document. 414 2.8 Multicast data packet processing 416 Data packets are processed in a manner similar to existing multicast 417 schemes. A router first performs a longest match on the source and 418 group address in the data packet. A (S,G) entry is matched first if 419 one exists; a (*,G) entry is matched otherwise. If neither state 420 exists, then a (*,*,RP) entry match is attempted as follows: the 421 router hashes on G to identify the RP for group G, and looks for a 422 _________________________ 423 [*] A PMBR is a router that sits at the boundary of a 424 PIM-SM domain and interoperates with other types of 425 multicast routers such as those that run DVMRP. Gen- 426 erally a PMBR would speak both protocols and implement 427 interoperability functions not required by regular PIM 428 routers. 430 (*,*,RP) entry that has this RP address associated with it. If none 431 of the above exists, then the packet is dropped. If a state is 432 matched, the router compares the interface on which the packet 433 arrived to the incoming interface field in the matched forwarding 434 entry. If the iif check fails the packet is dropped, otherwise the 435 packet is forwarded to all interfaces listed in the outgoing 436 interface list. 438 Some special actions are needed to deliver packets continuously while 439 switching from the shared to shortest-path tree. In particular, when 440 a (S,G) entry is matched, incoming packets are forwarded as follows: 442 1 If the SPT-bit is set, then: 444 1 if the incoming interface is the same as a matching 445 (S,G) iif, the packet is forwarded to the oif-list of 446 (S,G). 448 2 if the incoming interface is different than a matching 449 (S,G) iif , the packet is discarded. 451 2 If the SPT-bit is cleared, then: 453 1 if the incoming interface is the same as a matching 454 (S,G) iif, the packet is forwarded to the oif-list of 455 (S,G). In addition, the SPT bit is set for that entry 456 if the incoming interface differs from the incoming 457 interface of the (*,G) or (*,*,RP) entry. 459 2 if the incoming interface is different than a matching 460 (S,G) iif, the incoming interface is tested against a 461 matching (*,G) or (*,*,RP) entry. IF the iif is the 462 same as one of those, the packet is forwarded to the 463 oif-list of the matching entry. 465 3 Otherwise the iif does not match any entry for G and 466 the packet is discarded. 468 Data packets never trigger prunes. However, data packets may 469 trigger actions that in turn trigger prunes. For example, when 470 router B in figure 3 decides to switch to SP-tree at step 3, it 471 creates a (S,G) entry with SPT-bit set to 0. When data packets 472 from S arrive at interface 2 of B, B sets the SPT-bit to 1 473 since the iif for (*,G) is different than that for (S,G). This 474 triggers the sending of prunes towards the RP. 476 2.9 Operation over Multi-access Networks 478 This section describes a few additional protocol mechanisms 479 needed to operate PIM over multi-access networks: Designated 480 Router election, Assert messages to resolve parallel paths, and 481 the Joiner bit to suppress redundant Joins on multi-access 482 networks. 484 2.9.1 Designated router election 486 When there are multiple routers connected to a multi-access 487 network, one of them should be chosen to operate as the 488 designated router (DR) at any point in time. The DR is 489 responsible for sending triggered Join/Prune and Register 490 messages toward the RP [*] 492 A simple designated router (DR) election mechanism is used for 493 both SM and traditional IP multicast routing. 495 Neighboring routers send Query messages to each other. The 496 sender with the largest IP address assumes the role of DR. Each 497 router connected to the multi-access LAN sends the Queries 498 periodically in order to adapt to changes in router status. 500 2.9.2 Parallel paths to a source or the RP--Assert process 502 If a router receives a multicast datagram on a multi-access LAN 503 from a source whose corresponding (S,G) outgoing interface list 504 includes the interface to that LAN, the packet must be a 505 duplicate. In this case a single forwarder must be elected. 506 Using Assert messages addressed to `224.0.0.13' (ALL-PIM-ROUTERS 507 group) on the LAN, upstream routers can resolve which one will 508 act as the forwarder. Downstream routers listen to the Asserts 509 so they know which one was elected, and therefore where to send 510 _________________________ 511 [*] IGMP Queries are sent by a PIMv2 DR if it supports 512 IGMPv1. If a PIMv2 router is using IGMPv2 then Host 513 queries are not sent by the PIMv2 DR but by the IGMP 514 querier. 516 subsequent Joins. Typically this is the same as the downstream 517 router's RPF (Reverse Path Forwarding) neighbor; but there are 518 circumstances where this might not be the case, e.g., when using 519 different unicast protocols. [*] 521 The upstream router elected is the one that has the shortest 522 distance to the source. Therefore, when a packet is received on 523 an outgoing interface a router sends an Assert message on the 524 multi-access LAN indicating what metric it uses to reach the 525 source of the data packet. The router with the smallest 526 numerical metric (with ties broken by highest address) will 527 become the forwarder. All other upstream routers will delete the 528 interface from their outgoing interface list. The downstream 529 routers also do the comparison in case the forwarder is 530 different than the RPF neighbor. 532 Associated with the metric is a metric preference value. This is 533 provided to deal with the case where the upstream routers may 534 run different unicast routing protocols. The numerically smaller 535 metric preference is always preferred. The metric preference 536 should be treated as the high-order part of an assert metric 537 comparison. Therefore, a metric value can be compared with 538 another metric value provided both metric preferences are the 539 same. A metric preference can be assigned per unicast routing 540 protocol and needs to be consistent for all routers on the 541 multi-access network. 543 Asserts are also needed for (*,G) entries since there may be 544 parallel paths from the RP and sources to a multi-access 545 network. When an assert is sent for a (*,G) entry, the first bit 546 in the metric preference (RPT-bit) is always set to 1 to 547 indicate that this path corresponds to the RP tree, and that the 548 match should be done on (*,G) if it exists. Furthermore, the 549 RPT-bit is always cleared for metric preferences that refer to 550 SP-tree entries; this causes an SP-tree path to always look 551 better than an RP-tree path. When the SP-tree and RPtree cross 552 the same LAN, this mechanism eliminates the duplicates that 553 would otherwise be carried over the LAN. 555 In case the packet, or the Assert message, matches on oif for 556 _________________________ 557 [*] The RPF neighbor for a particular source (or RP) is 558 the next-hop router to which packets are forwarded en 559 route to that source (or RP); and therefore is con- 560 sidered a good path via which to accept packets from 561 that source. 563 (*,*,RP) entry, a (*,G) entry is created, and asserts take place 564 as if the matching state were (*,G). 566 The DR may lose the (*,G) Assert process to another router on 567 the LAN if there are multiple paths to the RP through the LAN. 568 From then on, the DR is no longer the last-hop router for local 569 receivers and removes the LAN from its (*,G) oif list. The 570 winning router becomes the last-hop router and is responsible 571 for sending (*,G) join messages to the RP. Asserts are rate 572 limited. 574 2.9.3 Join/Prune suppression 576 If a Join/Prune message arrives and matches on the incoming 577 interface for an existing (S,G), (*,G), or (*,*,RP) entry, and 578 the sender of the Join/Prune has a higher IP address than the 579 recipient of the message, the Joiner-bit in the recipient's 580 multicast routing table entry is cleared to suppress further 581 Join/Prune messages. A timer is set for the Joiner-bit; after it 582 expires the recipient sets the Joiner-bit to resume further 583 periodic Join/Prunes for this entry. The Joiner-bit timer is 584 restarted each time a Join/Prune message is received from a 585 higher-IP-addressed PIM neighbor. 587 2.10 Unicast Routing Changes 589 When unicast routing changes, an RPF check is done on all active 590 (S,G), (*,G) and (*,*,RP) entries, and all affected expected 591 incoming interfaces are updated. In particular, if the new 592 incoming interface appears in the outgoing interface list, it is 593 deleted from the outgoing interface list. The previous incoming 594 interface may be added to the outgoing interface list by a 595 subsequent Join/Prune from downstream. Join/Prune messages 596 received on the current incoming interface are ignored. 597 Join/Prune messages received on new interfaces or existing 598 outgoing interfaces are not ignored. Other outgoing interfaces 599 are left as is until they are explicitly pruned by downstream 600 routers or are timed out due to lack of appropriate Join/Prune 601 messages. If the router has a (S,G) entry with the SPT-bit set, 602 and the updated iif(S,G) does not differ from iif(*,G) or 603 iif(*,*,RP), then the router resets the SPT-bit. 605 The router must send a Join/Prune message with S in the Join 606 list out its new incoming interface to inform upstream routers 607 that it expects multicast datagrams over the interface. It may 608 also send a Join/Prune message with S in the Prune list out the 609 old incoming interface, if the link is operational, to inform 610 upstream routers that this part of the distribution tree is 611 going away. 613 2.11 PIM-SM for Inter-Domain Multicast 615 Future documents will address the use of PIM-SM as a backbone 616 inter-domain multicast routing protocol. Design choices center 617 primarily around the distribution and usage of RP information 618 for wide area, inter-domain groups. 620 2.12 Security 622 All PIM control messages may use [5] to address security 623 concerns. Security mechanisms are likely to be enhanced in the 624 near future. 626 3 Detailed Protocol Description 628 This section describes the protocol operations from the 629 perspective of an individual router implementation. In 630 particular, for each message type we describe how it is 631 generated and processed. 633 3.1 Query 635 Query messages are sent so neighboring routers can discover each 636 other. 638 3.1.1 Sending Queries 640 Query messages are sent periodically between PIM neighbors. By 641 default they are transmitted every 30 seconds. This informs 642 routers what interfaces have PIM neighbors. Query messages are 643 multicast using address 224.0.0.13 (ALL-PIM-ROUTERS group). The 644 packet includes the holdtime for neighbors to keep the 645 information valid. The recommended holdtime is 3 times the query 646 transmission interval. By default the holdtime is 90 seconds. 647 Queries are sent on all types of communication links. 649 3.1.2 Receiving queries 651 When a router receives a Query packet, it stores the IP address 652 for that neighbor, sets the PIM neighbor timer based on the 653 Query holdtime, and determines the Designated Router (DR) for 654 that interface. The highest IP addressed system is elected DR. 655 Each query received causes the DR's address to be updated. 657 When a router that is the active DR receives a query from a new 658 neighbor (i.e., from an IP address that is not yet in the DRs 659 neighbor table), the DR unicasts its most recent RP-set 660 information to the new neighbor. 662 3.1.3 Timing out neighbor entries 664 A periodic process is run to time out PIM neighbors that have 665 not sent queries. If the DR has gone down, a new DR is chosen by 666 scanning all neighbors on the interface and selecting the new DR 667 to be the one with the highest IP address. If an interface has 668 gone down, the router may optionally time out all PIM neighbors 669 associated with the interface. 671 3.2 Join/Prune 673 Join/Prune messages are sent to join or prune a branch off of 674 the multicast distribution tree. A single message contains both 675 a join and prune list, either one of which may be null. Each 676 list contains a set of source addresses, indicating the source- 677 specific trees or shared tree that the router wants to join or 678 prune. 680 3.2.1 Sending Join/Prune Messages 682 Join/Prune messages are merged such that a message sent to a 683 particular upstream neighbor, N, includes all of the current 684 joined and pruned sources that are reached via N; according to 685 unicast routing Join/Prune messages are multicast to all routers 686 on multi-access networks with the target address set to the next 687 hop router towards S or RP. Join/Prune messages are sent 688 periodically. Currently the period is set to 60 seconds. [*] 690 In addition, certain events cause triggered Join/Prune messages 691 to be sent. 693 3.2.1.1 Periodic Join/Prune Messages 695 A router sends a periodic Join/Prune message to each distinct 696 RPF neighbor associated with each (S,G), (*,G) and (*,*,RP) 697 entry. Join/Prune messages are only sent if the RPF neighbor is 698 a PIM neighbor. A periodic Join/Prune message sent to a 699 particular RPF neighbor is constructed as follows: 701 1 Each router determines the RP for a (*,G) entry by using 702 the hash function described. The RP address (with RP and WC 703 bits set) is included in the join list of a periodic 704 Join/Prune message under the following conditions: 706 1 The Join/Prune message is being sent to the RPF 707 neighbor toward the RP for an active (*,G) or (*,*,RP) 708 entry, and 710 _________________________ 711 [*] In the future we will introduce mechanisms to 712 rate-limit this control traffic on a hop by hop basis, 713 in order to avoid excessive overhead on small links. 715 2 The outgoing interface list in the (*,G) or (*,*,RP) 716 entry is non-NULL, or the router is the DR on the same 717 interface as the RPF neighbor. 719 2 A particular source address, S, is included in the join 720 list with the RP and WC bits cleared under the following 721 conditions: 723 1 The Join/Prune message is being sent to the RPF 724 neighbor toward S, and 726 2 There exists an active (S,G) entry with the RPT-bit 727 flag cleared, and 729 3 The oif list in the (S,G) entry is not null. 731 3 A particular source address, S, is included in the prune 732 list with the RP and WC bits cleared under the following 733 conditions: 735 1 The Join/Prune message is being sent to the RPF 736 neighbor toward S, and 738 2 There exists an active (S,G) entry with the RPT-bit 739 flag cleared, and 741 3 The oif list in the (S,G) entry is null. 743 4 A particular source address, S, is included in the prune 744 list with the RPT-bit set and the WC bit cleared under the 745 following conditions: 747 1 The Join/Prune message is being sent to the RPF 748 neighbor toward the RP and there exists a (S,G) entry 749 with the RPT-bit flag set and null oif list, or 751 2 The Join/Prune message is being sent to the RPF 752 neighbor toward the RP, there exists a (S,G) entry 753 with the RPT-bit flag cleared and SPT-bit set, and the 754 incoming interface toward S is different than the 755 incoming interface toward the RP, or 757 3 The Join/Prune message is being sent to the RPF 758 neighbor toward the RP, and there exists a (*,G) entry 759 and (S,G) entry for a directly connected source. 761 5 The RP address (with RP and WC bits set) is included in the 762 prune list if: 764 1 The Join/Prune message is being sent to the RPF 765 neighbor toward the RP and there exists a (*,G) entry 766 with a null oif list (see Section 3.5.2). 768 3.2.1.2 Triggered Join/Prune Messages 770 In addition to periodic messages, the following events will 771 trigger Join/Prune messages (the contents of triggered messages 772 are the same as the periodic, described above): 774 1 Receipt of an IGMP Host-Membership-Report message for a 775 group G will cause building or modifying corresponding 776 (*,G) state, and subsequent triggering of upstream 777 Join/Prune messages as follows: 779 1 If the receiving router does not have a forwarding 780 entry for G the router creates a (*,G) entry, with the 781 interface upon which the IGMP Host-Membership-Report 782 was received included in the oif list. The router 783 sends a Join/Prune message towards the RP with the RP 784 address and RPT-bit and WC-bits set in the join list. 785 A timer is initiated for each interface in the oif 786 list. Or, 788 2 If the (*,G) already exists, the interface upon which 789 the IGMP Host-Membership-Report was received is added 790 to the oif list (if it was not included already) and 791 the timer for that interface is restarted. 793 2 Receipt of a Join/Prune message for (S,G), (*,G) or 794 (*,*,RP) will cause building or modifying corresponding 795 state, and subsequent triggering of upstream Join/Prune 796 messages, in the following cases: 798 1 When there is no current forwarding entry, the RP 799 address included in the Join/Prune message is checked 800 against the local RP-Set information. If it matches, 801 an entry will be created. If the router has no RP-Set 802 information it may discard the message, or optionally 803 use the RP address included in the message. 805 The new entry will in turn trigger an upstream 806 Join/Prune message. 808 2 When the outgoing interface list of (S,G)RPT-bit entry 809 is null, the triggered Join/Prune message will contain 810 S in the prune list. 812 3 Receipt of a packet that matches on a (S,G) entry whose 813 SPT-bit is cleared triggers the following if the packet 814 arrived on the correct incoming interface and there is a 815 (*,G) or (*,*,RP) entry with a different incoming RPF 816 neighbor: a) the router sets the SPT-bit on the (S,G) 817 entry, and b) if the iif of the (S,G) entry is different 818 from the iif of the local (*,G) or (*,*,RP) entries, the 819 router sends a Join/Prune message towards the RP with S and 820 a set RPT-bit in the prune list. 822 4 When a Join/Prune message is received for a group G, the 823 prune list is checked. If it contains a source for which 824 the receiving router has a corresponding active (S,G), 825 (*,G) or (*,*,RP) entry, and whose iif is that on which 826 the Join/Prune was received, then a join for (S,G), (*,G) 827 or (*,*,RP) is triggered to override the prune, 828 respectively. (This is necessary in the case of parallel 829 downstream routers connected to a multi-access network.) 831 5 When the RP fails, the RP will not be included in the RP- 832 Set messages sent to all routers in that domain. This 833 triggers the DRs to send (*,G) Join/Prune messages towards 834 the new RP for the group, as determined by the RP-Set and 835 the hash function [*] 837 We do not trigger prunes onto interfaces for SM groups based on 838 data packets. Data packets that arrive on the wrong incoming 839 interface for an SM group are silently dropped. 841 3.2.1.3 Fragmentation 842 It is possible that a Join/Prune message 843 constructed according to the preceeding rules could exceed the 844 MTU of a network. In this case, the message can undergo semantic 845 fragmentation whereby information corresponding to different 846 groups can be sent in different messages. However, if a 847 Join/Prune message must be fragmented the complete prune list 848 corresponding to a group G must be included in the same 849 Join/Prune message as the associated RP-tree Join for G. 851 3.2.2 Receiving Join/Prune Messages When a router receives a 852 Join/Prune message, it processes it as follows. 854 The receiver of the Join/Prune notes the interface on which the 855 PIM message arrived, call it I. The receiver then checks to see 856 if the Join/Prune message was addressed to the receiving router 857 itself (i.e., the router's address appears in the Unicast 858 Upstream Neighbor Router field of the the Join/Prune message) 859 [*] If the Join/Prune is for this router the following actions 860 are taken. 862 For each Sj in the join list of the Join/Prune message: 864 1 If an address, Sj, in the join list of the Join/Prune 865 messagehas the RPT-bit and WC-bit set, then Sj is the RP 866 address used by the downstream router(s) and the following 867 actions are taken: 869 1 If Sj is not the same as the receiving router's RP 870 mapping for G, the receiving router may ignore the 871 _________________________ 872 [*] As described earlier, PMBRs trigger (*,*,RP) joins 873 towards each RP in the RP-Set. 874 [*] If the router is connected to a multiaccess LAN, 875 the message could be intended for a different router. 877 Join/Prune message with respect to that group entry. 878 If the router does not have any RP-Set information, it 879 may use the address Sj included in the Join/Prune 880 message as the RP for the group. 882 2 If Sj is the same as the receiving router's RP mapping 883 for G, the receiving router adds I to the outgoing 884 interface list of the (*,G) forwarding entry and sets 885 the timer for that interface (if there is no (*,G) 886 entry, the router creates one first). If a (*,*,RP) 887 entry exists, for the RP associated with G, then the 888 oif list of the newly created (*,G) entry is copied 889 from that (*,*,RP) entry. 891 3 For each (Si,G) entry associated with group G, if Si 892 is not included in the prune list, and if I is not the 893 iif then interface I is added to the oif list and 894 the timers are restarted for that interface in each 895 affected entry. If the group address in the Join/Prune 896 message is `*' then every (*,G) and (S,G) entry, whose 897 group address hashes to the RP indicated in the 898 (*,*,RP) Join/Prune message, is updated accordingly 899 [*] 901 4 If the (Si,G) entry has its RPT-bit flag set to 1, and 902 its oif list is the same as the (*,G) oif 903 list, then the (Si,G)RPT-bit entry is deleted, 905 5 The incoming interface is set to the interface used to 906 send unicast packets to the RP in the (*,G) forwarding 907 entry, i.e., RPF interface toward the RP. 909 2 For each address, Sj, in the join list whose RPT-bit and 910 WC-bit are not set, and for which there is no existing 911 (Sj,G) forwarding entry, the router initiates one. 912 [*] 913 _________________________ 914 [*] A `*' in the group field of the Join/Prune is 915 represented by a group address 224.0.0.0 and a group 916 mask length of 4, indicating a (*,*,RP) Join. 917 [*] The router creates a (S,G) entry and copies all 918 1 The outgoing interface for (Sj,G) is set to I. The 919 incoming interface for (Sj,G) is set to the interface 920 used to send unicast packets to Sj (i.e., the RPF 921 neighbor). 923 2 If the interface, I, used to reach Sj, is the same as 924 the outgoing interface being initialized, this 925 represents an error (or a unicast routing change) and 926 the Join/Prune should not be processed. 928 3 For each address, Sj, in the join list of the Join/Prune 929 message, for which there is an existing (Sj,G) forwarding 930 entry, 932 1 If the RPT-bit is not set for Sj listed in the 933 Join/Prune message, but the RPT-bit flag is set on the 934 existing (Sj,G) entry, the router clears the RPT-bit 935 flag on the (Sj,G) entry, sets the incoming interface 936 to point towards Sj for that (Sj,G) entry, and sends a 937 Join/Prune message corresponding to that entry through 938 the new incoming interface; and 940 2 If I is not the same as the existing incoming 941 interface, the router adds I to the list of outgoing 942 interfaces. 944 3 The timer for I is restarted. 946 4 The (Sj,G) entry's SPT bit is cleared until data comes 947 down the shortest path tree. 949 _________________________ 950 outgoing interfaces from the (S,G)RPT-bit entry, if it 951 exists. If there is no (S,G) entry, the oif list is 952 copied from the (*,G) entry; and if there is no (*,G) 953 entry, the oif list is copied from the (*,*,RP) entry, 954 if it exists. In all cases, the iif of the (S,G) entry 955 is always excluded from the oif list. 957 For each Sp in the prune list of the Join/Prune message: 959 1 For each address, Sp, in the prune list whose RPT-bit and 960 WC-bit are cleared: 962 1 If there is an existing (Sp,G) forwarding entry, the 963 router schedules a deletion of I from the list of 964 outgoing interfaces by lowering that oif timer to 5 965 seconds (unless it is already lower). The deletion is 966 not executed until this timer expires, allowing for 967 other downstream routers on a multi-access LAN to 968 override the prune. 970 2 If the router has a current (*,G), or (*,*,RP), 971 forwarding entry, and if the existing (Sp,G) entry has 972 its RPT-bit flag set to 1, then this (Sp,G)RPT-bit 973 entry is maintained (not deleted) even if its outgoing 974 interface list is null. 976 2 For each address, Sp, in the prune list whose RPT-bit is 977 set and whose WC-bit cleared: 979 1 If there is an existing (Sp,G) forwarding entry, the 980 router schedules a deletion of I from the list of 981 outgoing interfaces by lowering that oif timer to 5 982 seconds (unless it is already lower). The deletion is 983 not executed until this timer expires, allowing for 984 other downstream routers on a multi-access LAN to 985 override the prune. 987 2 If the router has a current (*,G), or (*,*,RP), 988 forwarding entry, and if the existing (Sp,G) entry has 989 its RPT-bit flag set to 1, then this (Sp,G)RPT-bit 990 entry is maintained (not deleted) even if its outgoing 991 interface list is null. 993 3 If (*,G), or corresponding (*,*,RP), state exists, but 994 there is no (Sp,G) entry, an (Sp,G)RPT-bit entry is 995 created . The outgoing interface list is copied from 996 the (*,G), or (*,*,RP), entry, with the interface, I, 997 on which the prune was received, is deleted. Packets 998 from the pruned source, Sp, match on this state and 999 are not forwarded toward the pruned receivers. 1001 4 If there exists a (Sp,G) entry, with or without the 1002 RPT-bit set, the iif on which the prune was received, 1003 I, is deleted from the oif list, and the entry 1004 timer is restarted. 1006 3 For each address, Sp, in the prune list whose RPT-bit and 1007 WC-bit are both set: 1009 1 If there is an existing (*,G) entry, with Sp as the RP 1010 for G, the router schedules a deletion of I from the 1011 list of outgoing interfaces by lowering that oif timer 1012 to 5 seconds (unless it is already lower). The 1013 deletion is not executed until this timer expires, 1014 allowing for other downstream routers on a multi- 1015 access LAN to override the prune. 1017 2 If the corresponding (*,*,RP) state exists, but there 1018 is no (*,G) entry, a (*,G) entry is created. The 1019 outgoing interface list is copied from (*,*,RP) entry, 1020 with the interface, I, on which the prune was 1021 received, deleted. 1023 3 If there exists a (*,G) entry, the interface on which 1024 the prune was received, I, is deleted from the oif 1025 list, and the entry timer is restarted. 1027 For any new (S,G), (*,G) or (*,*,RP) entry created by an 1028 incoming Join/Prune message, the Joiner-bit is initialized 1029 to 1 and the SPT-bit is cleared. 1031 If the received Join/Prune does not indicate the router as its 1032 target, then if the Join/Prune matches an existing (S,G), (*,G), 1033 or (*,*,RP) entry and the Join/Prune arrived on the iif for 1034 that entry, then the router compares the IP address of the 1035 generator of the Join/Prune, to its own IP address and sets the 1036 Joiner-bit as follows. 1038 1 If its own IP address is higher, the Joiner-bit in the 1039 entry is set. 1041 2 If its own IP address is lower, the Joiner-bit in the entry 1042 is cleared, and the Joiner-bit timer is activated. 1044 After the timer expires the Joiner-bit is set indicating further 1045 periodic Join/Prunes should be sent for this entry. The Joiner- 1046 bit timer is restarted each time a Join/Prune message is 1047 received from a higher-IP-addressed PIM neighbor. 1049 3.3 Register and Register-Stop 1051 When a source first starts sending to a group its packets are 1052 encapsulated in Register messages and sent to the RP. If the 1053 data rate warrants source-specific paths, the RP sets up source 1054 specific state and starts sending (S,G) Join/Prune messages 1055 toward the source, with S in the join list. 1057 3.3.1 Sending Registers and Receiving Register-Stops 1059 Register messages are sent as follows: 1061 1 When a DR receives a packet from a directly connected 1062 source, S [*] : 1064 1 If there is no corresponding (S,G) entry, and the 1065 _________________________ 1066 [*] When a PMBR (e.g., a router that connects the PIM- 1067 SM region to a dense mode region running DVMRP or PIM- 1068 DM) receives a packet from a source in the dense mode 1069 region, the router treats the packet as if it were from 1070 a directly connected source. A separate document will 1071 describe the details of interoperabiity. 1073 router has RP-Set information, the DR creates one with 1074 the Register-bit set to 1 and the RP address set 1075 according to the hash function mapping for the 1076 corresponding group. The Register-bit-timer is 1077 initialized to zero; the Register-bit-timer is non- 1078 zero only when the Register-bit is set to 0. 1080 2 If there is a (S,G) entry in existence, the DR simply 1081 restarts the corresponding S-timer (entry timer). 1083 2 If the new or previously-existing (S,G) entry has the 1084 Register-bit set, the data packet is encapsulated in a 1085 Register message and unicast to the RP for that group. The 1086 data packet is also forwarded according to (S,G) state in 1087 the DR if the oif list is not null; since a receiver may 1088 join the SP-tree while the DR is still registering to the 1089 RP. 1091 3 If the (S,G) entry has the Register-bit cleared, the data 1092 packet is not sent in a Register message, it is just 1093 forwarded according to the (S,G) oif list. 1095 When the DR receives a Register-Stop message it clears the 1096 Register-bit and restarts the Register-bit-timer in the 1097 corresponding (S,G) entry(ies). 1099 When a Register-bit-timer expires, the corresponding entry(ies) 1100 Register-bit is set to 1 to reinstigate encapsulation of data 1101 packets in Register messages. 1103 3.3.2 Receiving Register Messages and Sending Register-Stops 1105 When a router (i.e., the RP) receives a Register message, the 1106 router does the following: 1108 1 Decapsulates the data packet, and checks for a 1109 corresponding (S,G) entry. 1111 1 If a (S,G) entry exists, the packet is forwarded but 1112 the SPT bit is left cleared (0). If the SPT bit is 1, 1113 the packet is dropped, and Register-Stop messages are 1114 triggered. Register-Stops are rate limited. [*] 1116 2 If there is no (S,G) entry, but there is a (*,G) 1117 entry, or a (*,*,RP) entry with the RP corresponding 1118 to G, the packet is forwarded according to that entry. 1120 3 If there is a (*,*,RP) entry but no (*,G) entry, a 1121 (*,G) or (S,G) entry is created and the oif is copied 1122 from the (*,*,RP) entry to the new entry. 1124 4 If there is no G or (*,*,RP) entry corresponding to G, 1125 the packet is dropped, and a Register-Stop is 1126 triggered. 1128 5 A ``Border bit'' bit is added to the Register message, 1129 to facilitate interoperability mechanisms. PMBRs set 1130 this bit when registering for external sources (see 1131 Section 2.7). If the ``Border bit'' is set in the 1132 Register, the RP does the following: 1134 1 If there is no matching (S,G) state, the RP 1135 creates one, with a `PMBR' field. This field 1136 holds the source of the Register (i.e. the outer 1137 IP address of the register packet). The RP 1138 triggers a (S,G) join towards the source of the 1139 data packet, and clears the SPT bit for the (S,G) 1140 entry, else 1142 _________________________ 1143 [*] Register-Stops should be rate limited so that no 1144 more than a few are sent per round trip time. This 1145 prevents a high datarate stream of packets from 1146 triggering a large number of Register-stop messages 1147 between the time that the first packet is received and 1148 the time when the source receives the first Register- 1149 Stop. 1151 2 If the `PMBR' field for the corresponding (S,G) 1152 entry matches the source of the Register packet, 1153 the decapsulated packet is forwarded to the oif 1154 list of that entry, else 1156 3 The packet is dropped, and a Register-stop is 1157 triggered towards the source of the Register. 1159 The (S,G) state timer is restarted by Registers arriving 1160 from that source to that group. 1162 2 If the matching (S,G) or (*,G) state contains a null oif 1163 list, the RP unicasts a Register-Stop message to the source 1164 of the Register message; in the latter case, the source- 1165 address field, within the Register-Stop message, is set to 1166 the wildcard value (all 0's). This message is not processed 1167 by intermediate routers, hence no (S,G) state is 1168 constructed between the RP and the source. 1170 3 If the Register message arrival rate warrants it and there 1171 is no existing (S,G) entry, the RP sets up a (S,G) 1172 forwarding entry with the outgoing interface list, 1173 excluding iif(S,G), copied from the (*,G) outgoing 1174 interface list, its SPT-bit is initialized to 0. If a (*,G) 1175 entry does not exist, but there exists a (*,*,RP) entry 1176 with the RP corresponding to G , the oif list for (S,G) is 1177 copied -excluding the iif- from that (*,*,RP) entry. 1179 A timer is set for the (S,G) entry and this timer is 1180 restarted by receipt of data packets for (S,G). The (S,G) 1181 entry causes the RP to send a Join/Prune message for the 1182 indicated group towards the source of the register message. 1184 If the (S,G) oif list becomes null, Join/Prune messages 1185 will not be sent towards the source, S. 1187 3.4 Multicast Data Packet Forwarding 1189 Processing a multicast data packet involves the following steps: 1191 1 Lookup forwarding state based on a longest match of the 1192 source address, and an exact match of the destination 1193 address in the data packet. If neither S, nor G, find a 1194 longest match entry, and the RP for the packet's 1195 destination group address has a corresponding (*,*,RP) 1196 entry, then the longest match does not require an exact 1197 match on the destination group address. In summary, the 1198 longest match is performed in the following order: (1) 1199 (S,G), (2) (*,G). If neither is matched, then a lookup is 1200 performed on (*,*,RP) entries. 1202 2 If the packet arrived on the interface found in the 1203 matching-entry's iif field, and the oif list is not 1204 null: 1206 1 Forward the packet to the oif list for that entry 1207 and restarted the entry's timer if the matching entry 1208 is (S,G) [*] 1210 2 If the entry is a (S,G) entry with a cleared SPT-bit, 1211 and a (*,G) or associated (*,*,RP) also exists whose 1212 incoming interface is different than that for (S,G), 1213 set the SPT-bit for the (S,G) entry and trigger an 1214 (S,G) RPT-bit prune towards the RP. 1216 3 If the source of the packet is a directly-connected 1217 host and the router is the DR on a multi-access 1218 network, check the Register-bit associated with the 1219 (S,G) entry. If it is set, then the router 1220 encapsulates the data packet in a register message and 1221 sends it to the RP. 1223 This covers the common case of a packet arriving on the RPF 1224 interface to the source or RP and being forwarded to all 1225 joined branches. It also detects when packets arrive on the 1226 SP-tree, and triggers their pruning from the RP-tree. If it 1227 _________________________ 1228 [*] Optionally, the (S,G) timer may be restarted by 1229 periodic checking of the matching packet count. 1231 is the DR for the source, it sends data packets 1232 encapsulated in Registers to the RPs. 1234 3 If the packet matches to an entry but did not arrive on the 1235 interface found in the entry's iif field, check the 1236 SPT-bit of the entry. If the SPT-bit is set, drop the 1237 packet. If the SPT-bit is cleared, then lookup the (*,G), 1238 or (*,*,RP), entry for G. If the packet arrived on the 1239 iif found in (*,G), or the corresponding (*,*,RP), 1240 forward the packet to the oif list of the matching 1241 entry. This covers the case when a data packet matches on a 1242 (S,G) entry for which the SP-tree has not yet been 1243 completely established upstream. 1245 4 If the packet does not match to any entry, but the source 1246 of the data packet is a local, directly-connected host, and 1247 the router is the DR on a multi-access LAN and has RP-Set 1248 information, the DR uses the hash function to determine the 1249 RP associated with the destination group, G. The DR then 1250 checks the Register-bit associated with the local sender 1251 (if there is no such a Register-bit, a new register flag, 1252 associated with the local sender, is created and set), and 1253 encapsulates the data packet in a Register message and 1254 unicasts it to the RP. 1256 5 If the packet does not match to any entry, and it is not a 1257 local host or the router is not the DR, drop the packet. 1259 3.4.1 Data triggered switch to shortest path tree (SP-tree) 1261 Different criteria can be applied to trigger switching over from 1262 the RP-based shared tree to source-specific, shortest path 1263 trees. 1265 One proposed example is to do so based on data rate. For 1266 example, when a (*,G), or corresponding (*,*,RP), entry is 1267 created, a data rate counter may be initiated at the last-hop 1268 routers. The counter is incremented with every data packet 1269 received for directly connected members of an SM group, if the 1270 longest match is (*,G) or (*,*,RP). If and when the data rate 1271 for the group exceeds a certain configured threshold (t1), the 1272 router initiates `source-specific' data rate counters for the 1273 following data packets. Then, each counter for a source, is 1274 incremented when packets matching on (*,G), or (*,*,RP), are 1275 received from that source. If the data rate from the particular 1276 source exceeds a configured threshold (t2), a (S,G) entry is 1277 created and a Join/Prune message is sent towards the source. If 1278 the RPF interface for (S,G) is 1279 not the same as that for (*,G) -or (*,*,RP), then the SPT-bit 1280 is cleared in the (S,G) entry. 1282 Other configured rules may be enforced to cause or prevent 1283 establishment of (S,G) state. 1285 3.5 Assert 1287 Asserts are used to resolve which of the parallel routers 1288 connected to a multi-access LAN is responsible for forwarding 1289 packets onto the LAN. 1291 3.5.1 Sending Asserts 1293 The following Assert rules are provided when a multicast packet 1294 is received on an outgoing multi-access interface of an existing 1295 (S,G) entry: 1297 1 Do unicast routing table lookup on source IP address from 1298 data packet, and send assert on interface for source IP 1299 address in data packet; include metric preference of 1300 routing protocol and metric from routing table lookup. 1302 2 If route is not found, use metric preference of 0x7fffffff 1303 and metric 0xffffffff. 1305 When an assert is sent for a (*,G) entry, the first bit in the 1306 metric preference (the RPT-bit) is set to 1, indicating the data 1307 packet is routed down the RP-tree. 1309 Asserts are rate-limited by the router. 1311 3.5.2 Receiving Asserts 1313 When an assert is received the router performs a longest match 1314 on the source and group address in the assert message. The 1315 router checks the first bit of the metric preference (RPT-bit). 1317 1 If the RPT-bit is set, the router first does a match on 1318 (*,G), or (*,*,RP), entries; if no matching entry is found, 1319 the router matches (S,G) entries. 1321 2 If the RPT-bit is not set in the Assert, the router first 1322 does a match on (S,G) entries; if no matching entry is 1323 found, the router matches (*,G) or (*,*,RP) entries. 1325 3.5.2.1 Receiving Asserts on an entry's outgoing interface 1327 If the interface that received the Assert message is in the 1328 oif list of the matched entry, then this assert should be 1329 processed by this router as follows: 1331 1 If the Assert's RPT-bit is set and the matching entry is 1332 (*,*,RP), the router creates a (*,G) entry. If the Assert's 1333 RPT-bit is cleared and the matching entry is (*,G), or 1334 (*,*,RP), the router creates a (S,G)RPT-bit entry. 1336 2 Compare the metric received in the Assert with the one the 1337 router would have advertised in an assert. The metric 1338 preference should be treated as the high-order part of an 1339 assert metric comparison. If the value in the assert is 1340 less than the router's value, delete the interface from the 1341 entry. If the value is the same, compare IP addresses, if 1342 the routers address is less than the assert sender, delete 1343 the interface. 1345 3 If the router has won the election and there are directly 1346 connected members on the multi-access LAN, the router keeps 1347 the interface in its outgoing interface list. It acts as 1348 the forwarder for the LAN. 1350 4 If the router won the election but there are no directly 1351 connected members on the multi-access LAN, the router 1352 schedules to delete the interface. The LAN might be a stub 1353 LAN with no members (and no downstream routers). If no 1354 subsequent Join/Prunes are received, the router deletes the 1355 interface from the outgoing interface list; otherwise it 1356 keeps the interface in its outgoing interface and acts as 1357 the forwarder for the LAN. 1359 The winning router should send out an assert message including 1360 its own metric to that outgoing interface. This will cause other 1361 routers on the LAN to prune that interface from their forwarding 1362 entries. 1364 3.5.2.2 Receiving Asserts on an entry's incoming interface 1366 If the Assert arrived on the incoming interface of an existing 1367 (S,G), (*,G), or (*,*,RP) entry, the Assert is processed as 1368 follows. If the Assert message does not match the entry, 1369 exactly, it is ignored; i.e, longest-match is not used in this 1370 case. If the Assert message does match exactly, then: 1372 1 Downstream routers will select the upstream router with the 1373 smallest metric as their RPF neighbor. If two metrics are 1374 the same, the highest IP address is chosen to break the 1375 tie. [*] 1377 2 If the downstream routers have downstream members, they 1378 must schedule a join to inform the upstream router that 1379 packets should be forwarded on the multi-access network. 1380 This will cause the upstream forwarder to cancel its 1381 _________________________ 1382 [*] This is important so that downstream routers send 1383 subsequent Joins/Prunes (in SM) to the correct neigh- 1384 bor. An Assert timer is initiated when changing the RPF 1385 neighbor to the Assert winner. When the timer expires 1386 the router resets its RPF neighbor according to its un- 1387 icast routing tables to capture failures of the Assert 1388 winner. 1390 scheduled deletion of the interface. 1392 3.6 Candidate-RP-Advertisements and RP-Set messages 1394 Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM 1395 messages unicast by those routers that are configured as 1396 Candidate-RPs (C-RPs). 1398 RP-Set messages are periodic PIM messages originated by the 1399 Bootstrap router (BSR) within a domain, and forwarded hop-by-hop 1400 to distribute the current RP-set to all routers in that domain. 1402 The RP-Set messages also support a simple mechanism by which the 1403 Candidate BSR (C-BSR) with the highest BSR-priority and IP 1404 address (referred to as the preferred BSR) is elected as the BSR 1405 for the domain [*] Sections 3.6.2 and 3.6.3 describe the 1406 combined function of RP-Set messages as the vehicle for BSR 1407 election and RP-Set distribution. 1409 _________________________ 1410 [*] We recommend that each router configured as a C-RP 1411 also be configured as a C-BSR. 1413 3.6.1 Sending Candidate-RP-Advertisements 1415 C-RPs periodically unicast C-RP-Advs to the BSR for that domain. 1416 The interval for sending these messages is subject to local 1417 configuration at the C-RP. A recommended default value is 60 1418 seconds. 1420 Candidate-RP-Advertisements carry group address and group mask 1421 fields. This enables the advertising router to limit the 1422 advertisement to certain prefixes or scopes of groups. The 1423 advertising router may enforce this scope acceptance when 1424 receiving Registers or Join/Prune messages. 1426 3.6.2 Receiving C-RP-Advs and Originating RP-Set 1428 Upon receiving a C-RP-Adv, a router does the following: 1430 1 If the router is not the elected BSR, it ignores the 1431 message, else 1433 2 The BSR adds the RP address to its local pool of candidate 1434 RPs, according to the associated group prefix(es) in the 1435 C-RP-Adv message [*] The BSR may override the prefix 1436 indicated in a C-RP-Adv. 1438 The BSR keeps an RP-timer per RP in its local RP-set. The RP- 1439 timer is initialized to the holdtime in the RP's C-RP-Adv. When 1440 the timer expires, the corresponding RP is removed from the RP- 1441 set. The RP-timer is restarted by the C-RP-Advs from the 1442 corresponding RP. 1444 The BSR also keeps an RP-Set timer to send RP-Set messages 1445 periodically. In particular, when the RP-Set timer expires, the 1446 BSR originates an RP-Set message on each of its PIM interfaces. 1447 The message is sent with a TTL of 1 to the `ALL-PIM-ROUTERS' 1448 group. In steady state, the BSR originates RP-Set messages every 1449 60 seconds. At startup, the RP-Set timer is initialized to 180 1450 seconds, causing the first RP-Set message to be originated after 1451 180 seconds, when/if the timer expires. For timer details see 1452 Section 3.6.3. A DR unicasts an RP-Set message to new PIM 1453 neighbors starting up, after receiving their Query messages. 1454 _________________________ 1455 [*] The BSR may apply a local policy to limit the 1456 number of Candidate RPs included in the RP-Set message. 1458 (since after DR election the new neighbor may become the new 1459 DR.) 1461 The RP-Set message is subdivided into sets of group-prefix,RP- 1462 Count,RP-addresses. The format of the RP-Set message allows 1463 `semantic fragmentation', if the length of the original RP-Set 1464 message exceeds the packet maximum boundaries (see Section 4). 1465 However, we recommend against configuring a large number of 1466 routers as C-RPs, to reduce the semantic fragmentation required. 1468 3.6.3 Receiving and Forwarding RP-Set 1470 Each router keeps an RP-Set timer, initialized to 180 seconds at 1471 startup. 1473 When a router receives RP-Set message sent to `ALL-PIM-ROUTERS' 1474 group, it performs the following: 1476 1 If the message was not sent by the RPF neighbor towards the 1477 BSR address included, the message is dropped. Else 1479 2 If the included BSR is not preferred over, and not equal 1480 to, the currently active BSR: 1482 1 If the RP-Set timer is not yet expired, or if the 1483 receiving router is a C-BSR, then the RP-Set message 1484 is dropped. Else 1486 2 The RP-Set timer has expired and the receiving router 1487 is not a C-BSR, so the receiving router stores the 1488 RP-Set and BSR address and priority found in the 1489 message, and restarts the timer with its maximum 1490 value. The RP-Set message is then forwarded out all 1491 PIM interfaces, excluding the one over which the 1492 message arrived, to `ALL-PIM-ROUTERS' group, with a 1493 TTL of 1. 1495 3 If the RP-Set message includes a BSR address that is 1496 preferred over, or equal to, the currently active BSR, the 1497 router resets its RP-Set timer to 180 seconds, and stores 1498 the BSR address and RP-Set information. The RP-Set message 1499 is then forwarded out all PIM interfaces, excluding the one 1500 over which the message arrived, to `ALL-PIM-ROUTERS' group, 1501 with a TTL of 1. 1503 4 If the receiving router has no current RP set information 1504 and the RP-set was unicast to it from a directly connected 1505 neighbor, the router stores the information as its new RP- 1506 set. This covers the startup condition when a newly booted 1507 router obtains the RP-Set and BSR address from its DR. 1509 When a router receives a new RP-Set it checks if each of the RPs 1510 referred to by existing state (i.e., by (*,G), (*,*,RP), or 1511 (S,G)RPT-bit entries) is in the new RP-Set. If an RP is not in 1512 the new RP-set, that RP is considered unreachable and the hash 1513 algorithm (see below) is re-performed for each group with 1514 locally active state that previously hashed to that RP. This 1515 will cause those groups to be distributed among the remaining 1516 RPs. When the new RP-Set contains a new RP, the value of the new 1517 RP is calculated for each group covered by that C-RP's Group- 1518 prefix. Any group for which the new RP's value is greater than 1519 the previously active RP's value is switched over to the new RP. 1521 3.7 Hash Function 1523 The hash function is used by all routers within a domain, to map 1524 a group to one of the C-RPs from the RP-Set. For a particular 1525 group, G, the hash function uses only those C-RPs whose Group- 1526 prefix covers G. The algorithm takes as input the group address, 1527 and the addresses of the Candidate RPs, and gives as output one 1528 RP address to be used. 1530 The protocol requires that all routers hash to the same RP 1531 within a domain (except for transients). The following hash 1532 function must be used in each router: 1534 1 For each candidate RP address Ci in the Candidate-RP- 1535 Set, whose Group-prefix covers G, compute a value: 1536 Value(G,M,Ci) = 1537 1103515245 ((1103515245 (G&M)+12345) XOR Ci)+ 12345 mod 2^31 1538 where M is a hash-mask included in RP-Set messages. 1539 This hash-mask allows a small number of 1540 consecutive groups (e.g., 4) to always hash to the same RP. 1541 For instance, hierarchically-encoded data can be sent on 1542 consecutive group addresses to get the same delay and 1543 fate-sharing characteristics. 1545 In standard C, this corresponds to: 1547 srand(G & M); 1548 srand(rand() ^ Ci); 1549 value = rand(); 1551 2 The candidate with the highest resulting value is then 1552 chosen as the RP for that group, and its identity and hash 1553 value are stored with the entry created. 1555 Ties between C-RPs having the same hash value, are broken 1556 in advantage of the highest address. 1558 The hash function algorithm is invoked by a DR, upon reception 1559 of a packet, or IGMP Host-Membership-Report, for a group, for 1560 which the DR has no entry. It is invoked by any router that has 1561 (*,*,RP) state when a packet is received for which there is no 1562 corresponding (S,G) or (*,G) entry. Furthermore, the hash 1563 function is invoked by all routers upon receiving a Join/Prune 1564 message with WC-bit set. 1566 3.8 Processing Timer Events 1568 In this subsection, we enumerate all timers that have been 1569 discussed or implied. Since some critical timer events are not 1570 associated with the receipt or sending of messages, they are not 1571 fully covered by earlier subsections. 1573 Timers may either count up or count down. If they count up then 1574 expiration means that the timer has reached its configured 1575 maximum value. If they count down then expiration means that the 1576 timer has reached zero. 1578 In many cases, the values for timers come from Holdtime fields 1579 in PIM control messages, in which case the default values used 1580 in these Holdtime fields are shown in the tables below. 1581 Otherwise, the default value used when setting the timer is 1582 shown. In general, the default timeout value for state 1583 information is three times the refresh period. For example, 1584 Queries refresh Neighbor state and the default Query-timer 1585 period is 30 seconds, so a default Neighbor-timer duration of 90 1586 seconds is included in the Holdtime field of the Queries. 1588 In this version of the spec we suggest particular numerical 1589 timer settings. A future version of the specification will 1590 specify a mechanism for timers to be set as a function of the 1591 outgoing link bandwidth. 1593 3.8.1 Timers related to tree maintenance 1595 Each (S,G), (*,G), and (*,*,RP) entry has multiple timers 1596 associated with it: one for each interface in the outgoing 1597 interface list, one for the multicast routing entry itself, and 1598 one for the Joiner-bit. Each (S,G) and (*,G) entry also has an 1599 Assert timer and an Assert-rate-limit timer. In addition, DR's 1600 have a Register-bit-timer for each (S,G) entry and every router 1601 has a single Join/Prune timer. 1603 Because some of the outgoing interfaces in an (S,G) entry are 1604 copied from the (*,G) outgoing interface list, they may not have 1605 explicit (S,G) join messages from some of the downstream routers 1606 (i.e., where members are joining to the (*,G) tree only). Thus, 1607 when a timer is reset for an outgoing interface listed in a 1608 (*,G) entry, the timers are reset for that interface in each 1609 existing (S,G) entry whose oif list contains that interface [*] 1610 The same rule applies to (*,G) and (S,G) entries when resetting 1611 an oif timer on a (*,*,RP) entry. 1613 _________________________ 1614 [*] If there are sources in the prune list of the (*,G) 1615 join, then the timers for the arriving interface will 1616 first be reset for those sources, and then this inter- 1617 face will be deleted from these same entries; producing 1618 a correct result, even though the updating of the ti- 1619 mers was unnecessary. An implementation could optimize 1620 this by checking the prune list before processing the 1621 join list. 1623 Timer DefVal Notes 1625 Joiner-bit 90 Started : When Joiner bit is cleared 1626 per route entry Reset by: Receiving Join from higher-IP neighbor on iif 1627 Action : Set Joiner bit 1629 Join/Prune 60 Started : When booting 1630 Reset by: Nothing 1631 Action : Send Join/Prune to each RPF neighbor, restart timer 1633 oif 180 Started : When adding oif to oiflist 1634 per (*,*,RP) oif Restarted by: Receiving (*,*,RP) Join on that iface 1635 Action : Remove oif from oiflist 1637 oif 180 Started : When adding oif to oiflist 1638 per (*,G) oif Restarted by: Receiving (*,G) Join or IGMP 1639 Host-Membership-Report for G on that iface, or 1640 restartedting oif timer in (*,*,RP). 1641 Action : Remove oif from oiflist 1643 oif 180 Started : When adding oif to oiflist 1644 per (S,G) oif Restarted by: Receiving (S,G) Join on that 1645 iface, or restartedting oif timer in (*,G) or 1646 (*,*,RP). 1647 Action : Remove oif from oiflist 1649 (*,*,RP) entry 180 Started : When entry is created 1650 per (*,*,RP) Restarted by: Restartedting timer on any oif 1651 Action : Delete entry 1653 (*,G) entry 180 Started : When entry is created 1654 per (*,G) Restarted by: Receiving (*,G) prune, 1655 restarting timer on any oif, or receiving an 1656 Assert with RPT-bit set. 1657 Action : Delete entry and any associated 1658 (S,G)RPT-bit entries 1660 (S,G) entry 180 Started : When entry is created 1661 aka S-timer Restarted by: Forwarding data packet, 1662 per (S,G) receiving Register, receiving (S,G)RPT-bit 1663 prune, restarting timer on any oif, 1664 or receiving an Assert without RPT-bit set. 1665 Action : Delete entry 1667 Register-bit 60 Started : When Register bit is cleared by 1668 per (S,G) receiving a Register-Stop 1669 Restarted by: Receiving Register-Stop 1670 Action : Set Register bit 1672 Assert 180 Started : Receiving an Assert where the 1673 per (S,G) upstream RPF neighbor is not your unicast RPF 1674 and (*,G) neighbor. 1675 Restarted by: Receiving an Assert where the 1676 upstream RPF neighbor is not your unicast 1677 RPF neighbor. 1678 Action : Change RPF neighbor to unicast RPF neighbor 1680 Assert-Rate-limit 5 Started : When an Assert is sent 1681 per (S,G) Restarted by: Nothing 1682 and (*,G) Action : Allow asserts to be triggered by 1683 data packets 1685 3.8.2 Timers relating to neighbor discovery 1687 Timer DefVal Notes 1689 Query 30 Started : When booting 1690 Restarted by: Nothing 1691 Action : Send Query on all ifaces, restart timer 1693 Neighbor 90 Started : When receive first Query from neighbor 1694 per neighbor Restarted by: When receive subsequent Queries 1695 Action : Delete neighbor entry 1697 3.8.3 Timers relating to RP information 1698 Timer DefVal Notes 1700 C-RP-Adv 60 Started : When booting if you're a Cand-RP 1701 Restarted by: Nothing 1702 Action : Send C-RP-Adv, restart C-RP-Adv timer 1704 RP 180 Started : When adding an RP to the RP-Set if 1705 per RP you are BSR 1706 Restarted by: Receiving C-RP-Adv 1707 Action : Remove RP from RP-Set 1709 RP-Set 180/60 Started : Set to 180 when booting if 1710 you're a C-BSR 1711 Restarted by: Restarted to 180 when receive 1712 RP-Set from preferred router if you're a C-BSR 1713 Action : Send RP-Set and restart timer to 60 secs 1715 3.9 Summary of flags used 1717 Following is a summary of all the flags used in our scheme. 1719 Bit Used in Definition 1721 Border Register Register is coming from a PIM multicast border router. 1722 Joiner Route entry Periodic Join/Prunes should be sent for this entry. 1723 Register (S,G) entry Encapsulate packets from directly connected 1724 sources in Register messages unicast to the RP 1725 for that group. 1726 RP Route entry Entry represents state on the RP-tree. 1727 RP Join/Prune Join is associated with the shared tree and therefore 1728 the Join/Prune message is propagated along the RP-tree. 1729 RP Assert The data packet was routed down the shared tree; thus, 1730 the path indicated corresponds to the RP tree. 1731 SPT (S,G) entry Packets have arrived on the iif towards S, 1732 and the iif is different from the (*,G) iif. 1733 WC Join Included address is an RP and the receiver expects to 1734 receive packets from all sources via this (shared tree) 1735 path. Thus, the Join/Prune applies to a (*,G) entry. 1736 WC Route entry Wildcard entry; if there is no more specific match for 1737 a particular source, packets will be forwarded according 1738 to this entry. 1740 3.10 Security 1742 Editors Note: this section is to be completed. 1744 All PIM control messages may use [5] to address security 1745 concerns. 1747 4 Packet Formats 1749 This section describes the details of the packet formats for PIM 1750 control messages. 1752 All PIM control messages have protocol number 103. 1754 Basically, PIM messages are either unicast (e.g. Registers and 1755 Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' 1756 group `224.0.0.13' (e.g. Join/Prune, Asserts, etc.). 1758 0 1 2 3 1759 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 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 |PIM Ver| Type | Addr length | Checksum | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 PIM Ver 1765 PIM Version number is 2. 1767 Type Types for specific PIM messages. PIM Types are: 1769 0 = Query 1770 1 = Register 1771 2 = Register-Stop 1772 3 = Join/Prune 1773 4 = RP-Set 1774 5 = Assert 1775 6 = Graft (used in PIM-DM only) 1776 7 = Graft-Ack (used in PIM-DM only) 1777 8 = Candidate-RP-Advertisement 1779 Addr length 1780 Address length in bytes. Throughout this section this 1781 would indicate the number of bytes in the Address field of 1782 an address, including unicast and group addresses. 1784 Checksum 1785 The checksum is the 16-bit one's complement of the one's 1786 complement sum of the entire PIM message, (excluding the 1787 data portion in the Register message). For computing the 1788 checksum, the checksum field is zeroed. 1790 4.1 Encoded Source and Group Address formats 1792 1 Unicast address: Only the address is included. The length 1793 of the unicast address in bytes is specified in the `Addr 1794 length' field in the header. 1796 2 Encoded-Group-Address: Takes the following format: 1798 0 1 2 3 1799 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 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | Reserved | Mask Len | Group multicast Address ... | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | ...Group multicast Address ...| 1804 +-+-+-+-+-+-+-+-+-+-+~+~+~+~+~+~+ 1806 Reserved 1807 Transmitted as zero. Ignored upon receipt. 1809 Mask Len 1810 The Mask length is 8 bits. The value is the number of 1811 contiguous bits left justified used as a mask which 1812 describes the address. It is less than or equal to 1813 Addr length * 8. If the message is sent for a single 1814 group then the Mask length should equal Addr length * 1815 8 (i.e. 32 for IPv4 and 128 for IPv6). 1817 Group multicast Address 1818 contains the group address, and has number of bytes 1819 equal to that specified in the Addr length field. 1821 3 Encoded-Source-Address: Takes the following format: 1823 0 1 2 3 1824 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 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 | Rsrvd |S|W|R| Mask Len | Source Address ... | 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | ... Source Address | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+-+ 1831 Reserved 1832 Transmitted as zero, ignored on receipt. 1834 S,W,R See Section 4.5 for details. 1836 Mask Length 1837 Mask length is 8 bits. The value is the number of 1838 contiguous bits left justified used as a mask which 1839 describes the address. The mask length must be less 1840 than or equal to Addr Length * 8. If the message is 1841 sent for a single source then the Mask length should 1842 equal Addr length * 8. In version 2 of PIM, it is 1843 strongly recommended that this field be set to 32 for 1844 IPv4. 1846 Source Address 1847 The address length is indicated from the Addr length 1848 field at the beginning of the header. For IPv4, the 1849 address length is 4 octets. 1851 4.2 Query Message 1853 It is sent periodically by routers on all interfaces. 1855 0 1 2 3 1856 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 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 |PIM Ver| Type | Addr length | Checksum | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Reserved | Holdtime | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 PIM Version, Type, Addr length, Checksum 1864 Described above. 1866 Reserved 1867 Transmitted as zero, ignored on receipt. 1869 Holdtime 1870 The amount of time a receiver should keep the neighbor 1871 reachable, in seconds. 1873 4.3 Register Message 1875 It is sent by the Designated Router (DR) to the RP when a 1876 multicast packet needs to be transmitted on the RP-tree. Source 1877 IP address is set to the address of the DR, destination IP 1878 address is to the RP's address. 1880 0 1 2 3 1881 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 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 |PIM Ver| Type | Addr length | Checksum | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 |B| Reserved | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | | 1888 Multicast data packet 1889 | | 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 PIM Version, Type, Addr length, Checksum 1893 Described above. Note that the checksum for Registers 1894 is done only on the PIM header, excluding the data packet 1895 portion. 1897 B The Border bit. Set to zero by all DRs. Set to `1' by the 1898 PIM Multicast Border Routers, when registering for external 1899 sources. 1901 Multicast data packet 1902 The original packet sent by the source. 1904 4.4 Register-Stop Message 1906 A Register-Stop is unicast from the RP to the sender of the 1907 Register message. Source IP address is the address to which the 1908 register was addressed. Destination IP address is the source 1909 address of the register message. 1911 0 1 2 3 1912 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 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 |PIM Ver| Type | Addr length | Checksum | 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 | Encoded-Group Address | 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 | Unicast-Source Address | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 PIM Version, Type, Addr length, Checksum 1922 Described above. 1924 Encoded-Group Address 1925 Format described above. Note that for Register-Stops the 1926 Mask Len field should contain Addr length * 8 (32 for 1927 IPv4), if the message is sent for 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. A special wild card value (0.0.0.0), 1933 can be used to indicate any source. 1935 4.5 Join/Prune Message 1937 It is sent by routers towards upstream sources and RPs. A join 1938 creates forwarding state and a prune destroys forwarding state. 1939 Joins are sent to build shared trees (RP trees) or source trees 1940 (SPT). Prunes are sent to prune source trees when members leave 1941 groups as well as sources that do not use the shared tree. 1943 0 1 2 3 1944 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 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 |PIM Ver| Type | Addr length | Checksum | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | Unicast-Upstream Neighbor Address | 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | Reserved | Num groups | Holdtime | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 | Encoded-Multicast Group Address-1 | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | Number of Joined Sources | Number of Pruned Sources | 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | Encoded-Joined Source Address-1 | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | . | 1959 | . | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Encoded-Joined Source Address-n | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Encoded-Pruned Source Address-1 | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | . | 1966 | . | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 | Encoded-Pruned Source Address-n | 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | . | 1971 | . | 1972 | . | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | Encoded-Multicast Group Address-n | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | Number of Joined Sources | Number of Pruned Sources | 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 | Encoded-Joined Source Address-1 | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 | . | 1981 | . | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | Encoded-Joined Source Address-n | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | Encoded-Pruned Source Address-1 | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | . | 1988 | . | 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 | Encoded-Pruned Source Address-n | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 PIM Version, Type, Addr length, Checksum 1994 Described above. 1996 Upstream Neighbor Address 1997 The IP address of the RPF or upstream neighbor. 1999 Reserved 2000 Transmitted as zero, ignored on receipt. 2002 Holdtime 2003 The amount of time a receiver should keep the Join/Prune 2004 state alive, in seconds. 2006 Number of Groups 2007 The number of multicast group sets contained in the 2008 message. 2010 Encoded-Multicast group address 2011 For format description see Section 2012 4.1. A wild card group in the (*,*,RP) join is represented 2013 by a 224.0.0.0 in the group address field and `4' in the 2014 mask length field. A (*,*,RP) join also has the WC-bit and 2015 the RPT-bit set. 2017 Number of Joined Sources 2018 Number of join source addresses listed for a given group. 2020 Join Source Address-1 .. n 2021 This list contains the sources that the sending router 2022 will forward multicast datagrams for if received on the 2023 interface this message is sent on. 2025 See format section 4.1. The fields explanation for the 2026 Encoded-Source-Address format follows: 2028 Reserved 2029 Described above. 2031 S The Sparse bit is a 1 bit value, set to 1 for PIM-SM. 2032 It is used for PIM v.1 compatability. 2034 W The WC bit is a 1 bit value. If 1, the join or prune 2035 applies to the (*,G) or (*,*,RP) entry. If 0, the join 2036 or prune applies to the (S,G) entry where S is Source 2037 Address. Joins and prunes sent towards the RP should 2038 have this bit set. 2040 R The RPT-bit is a 1 bit value. If 1, the information 2041 about (S,G) is sent towards the RP. If 0, the 2042 information should be sent about (S,G) toward S, where 2043 S is Source Address. 2045 Mask Length, Source Address 2046 Described above. 2048 Represented in the form of < WC-bit >< RPT-bit >< 2049 Mask length >< Source address>: 2051 A source address could be a host IP address : 2053 < 0 >< 0 >< 32 >< 192.1.1.17 > 2055 A source address could be the RP's IP address : 2057 < 1 >< 1 >< 32 >< 131.108.13.111 > 2059 A source address could be a subnet address to prune from 2060 the RP-tree : 2062 < 0 >< 1 >< 28 >< 192.1.1.16 > 2064 A source address could be a general aggregate : 2066 < 0 >< 0 >< 16 >< 192.1.0.0 > 2068 Number of Pruned Sources 2069 Number of prune source addresses listed for a group. 2071 Prune Source Address-1 .. n 2072 This list contains the sources that the sending router 2073 does not want to forward multicast datagrams for when 2074 received on the interface this message is sent on [*] 2075 _________________________ 2076 [*] If the Join/Prune message boundary exceeds the max- 2077 4.6 RP-Set 2079 The RP-Set messages are multicast to `ALL-PIM-ROUTERS' group, 2080 out all interfaces having PIM neighbors (excluding the one over 2081 which the message was received). RP-Set messages are sent with 2082 TTL value of 1. RP-Set messages originate at the BSR, and are 2083 forwarded by intermediate routers. 2085 RP-Set message is divided up into `semantic fragments', if the 2086 original message exceeds the maximum packet size boundaries. 2088 The semantics of a single `fragment' is given below: 2090 _________________________ 2091 imum packet size, then the join and prune lists for the 2092 same group must be included in the same packet. 2094 0 1 2 3 2095 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 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 |PIM Ver| Type | Addr length | Checksum | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | Fragment Tag | Hash Mask len | BSR-priority | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | Unicast-BSR-Address | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | Encoded-Group Address-1 | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | RP-Count-1 | Frag RP-Cnt-1 | Reserved | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | Unicast-RP-Address-1 | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | . | 2110 | . | 2111 | . | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | Unicast-RP-Address-m | 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | . | 2116 | . | 2117 | . | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | Encoded-Group Address-n | 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 | RP-Count-m | Frag RP-Cnt-m | Reserved | 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | Unicast-RP-Address-1 | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2125 | . | 2126 | . | 2127 | . | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | Unicast-RP-Address-m | 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 PIM Version, Type, Addr length, Checksum 2133 Described above. 2135 Fragment Tag 2136 A randomly generated number, acts to distinguish the 2137 fragments belonging to different RP-Set messages; fragments 2138 belonging to same RP-Set message carry the same `Fragment 2139 Tag'. 2141 Hash Mask len 2142 The length (in bits) of the mask to use in the hash 2143 function. For IPv4 we recommend a value of 30. For IPv6 we 2144 recommend a value of 126. 2146 BSR-priority 2147 Contains the BSR priority value of the included BSR. This 2148 field is considered as a high order byte when comparing BSR 2149 addresses. 2151 Unicast-BSR-Address 2152 The IP address of the bootstrap router for the domain. The 2153 length of this field in bytes is specified in Addr length. 2155 Encoded-Group Address-1..n 2156 The group prefix (address and mask) with which the 2157 Candidate RPs are associated. Format previously described. 2159 RP-Count-1..n 2160 The number of Candidate RP addresses included in the whole 2161 RP-Set message for the corresponding group prefix [*] 2163 Frag RP-Cnt-1..m 2164 The number of Candidate RP addresses included in this 2165 fragment of the RP-Set message, for the corresponding group 2166 prefix. The `Frag RP-Cnt' field facilitates parsing of the 2167 RP-Set for a given group prefix, when carried over more 2168 than one fragment. 2170 Unicast-RP-address-1..m 2171 The address of the Candidate RPs, for the corresponding 2172 _________________________ 2173 [*] A router does not replace its old RP-Set for a 2174 given group prefix until/unless it receives `RP-Count' 2175 addresses for that prefix; the addresses could be car- 2176 ried over several fragments. If only part of the RP-Set 2177 for a given group prefix was received, the router dis- 2178 cards it, without updating that specific group prefix's 2179 RP-Set. 2181 group prefix. The length of this field in bytes is 2182 specified in Addr length. 2184 4.7 Assert Message 2186 The Assert message is sent when a multicast data packet is 2187 received on an outgoing interface corresponding to the (S,G) or 2188 (*,G) associated with the source. 2190 0 1 2 3 2191 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 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 |PIM Ver| Type | Addr length | Checksum | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | Encoded-Group Address | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | Unicast-Source Address | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 |R| Metric Preference | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | Metric | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 PIM Version, Type, Addr length, Checksum 2205 Described above. 2207 Encoded-Group Address 2208 The group address to which the data packet was addressed, 2209 and which triggered the Assert. Format previously 2210 described. 2212 Unicast-Source Address 2213 Source IP address from IP multicast datagram that 2214 triggered the Assert packet to be sent. The length of this 2215 field in bytes is specified in Addr length. 2217 R RPT-bit is a 1 bit value. If the IP multicast datagram 2218 that triggered the Assert packet is routed down the RP 2219 tree, then the RPT-bit is 1; if the IP multicast datagram 2220 is routed down the SPT, it is 0. 2222 Metric Preference 2223 Preference value assigned to the unicast routing protocol 2224 that provided the route to Host address. 2226 Metric The unicast routing table metric. The metric is in units 2227 applicable to the unicast routing protocol used. 2229 4.8 Graft Message 2231 Used in dense-mode. Refer to PIM dense mode specification. 2233 4.9 Graft-Ack Message 2235 Used in dense-mode. Refer to PIM dense mode specification. 2237 4.10 Candidate-RP-Advertisement 2239 Candidate-RP-Advertisements are periodically unicast from the 2240 C-RPs to the BSR. 2242 0 1 2 3 2243 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 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 |PIM Ver| Type | Addr length | Checksum | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 | Prefix-Cnt | Reserved | Holdtime | 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | Unicast-RP-Address | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 | Encoded-Group Address-1 | 2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2253 | . | 2254 | . | 2255 | . | 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 | Encoded-Group Address-n | 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 PIM Version, Type, Addr length, Checksum 2261 Described above. 2263 Prefix-Cnt 2264 The number of encoded group addresses included in the 2265 message; indicating the group prefixes for which the C-RP 2266 is advertising. A Prefix-Cnt of `0' implies a prefix of 2267 224.0.0.0 with mask length of 4; i.e. all multicast groups. 2268 If the C-RP is not configured with Group-prefix 2269 information, the C-RP puts a default value of `0' in this 2270 field. 2272 Holdtime 2273 The amount of time the advertisement is valid. This field 2274 allows advertisements to be aged out. 2276 Unicast-RP-Address 2277 The address of the interface to advertise as a Candidate 2278 RP. The length of this field in bytes is specified in Addr 2279 length. 2281 Encoded-Group Address-1..n 2282 The group prefixes for which the C-RP is advertising. 2283 Format previously described. 2285 5 Appendix I: Major Changes and Updates to the Spec 2287 This appendix populates the major changes in the specification 2288 document as compared to `draft-ietf-idmr-pim-spec-01.ps,txt'. 2290 5.1 Major Changes 2292 List of changes since March '96 IETF: 2294 1. (*,*,RP) Joins state and data forwarding check; replaces (*,G- 2295 Prefix) Joins state for interoperability. (*,G) negative cache 2296 introduced for the (*,*,RP) state supporting mechanisms. 2298 2. Semantic fragmentation for the RP-Set message. 2300 List of changes incurred since version 1 of the spec.: 2302 1. Proposal and refinement of bootstrap router (BSR) election 2303 mechanisms 2305 2. Introduction of hash functions for Group to RP mapping 2307 3. New RP-liveness indication mechanisms based upon the the 2308 Bootstrap Router (BSR) and the RP-Set messages. 2310 4. Removal of reachability messages, RP reports and multiple RPs 2311 per group. 2313 5.2 Packet Format Changes 2315 Packet Format incurred updates to accommodate different address 2316 lengths, and address aggregation. 2318 1 The `Addr length' field was added to the PIM fixed header 2319 to specify the address length in bytes of the underlying 2320 protocol, see section 4. 2322 2 The Encoded source and group address formats were 2323 introduced, with the use of a `Mask length' field to allow 2324 aggregation, section 4.1. 2326 3 Packet formats are no longer IGMP messages; rather PIM 2327 messages. 2329 PIM message types and formats were also modified: 2331 [ Note: most changes were made to the May 95 version, unless 2332 otherwise specified]. 2334 1 Obsolete messages: 2336 (a) Register-Ack [Feb. 96] 2338 (b) Poll and Poll Response [Feb. 96] 2340 (c) RP-Reachability [Feb. 96] 2342 (d) RPlist-Mapping [Feb. 96] 2344 2 New messages: 2346 (a) Candidate-RP-Advertisement [change made in October 95] 2347 RP-Set [Feb. 96] 2349 3 Modified messages: 2351 (a) Join/Prune [Feb. 96] 2353 (b) Register [Feb. 96] 2355 (c) Register-Stop [Feb. 96] 2356 6 Acknowledgments 2358 Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul 2359 Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen 2360 Ostrowski, and Lixia Zhang provided detailed comments on 2361 previous drafts. The authors of [6] and membership of the IDMR 2362 WG provided many of the motivating ideas for this work and 2363 useful feedback on design details. 2365 This work was supported by the National Science Foundation, 2366 ARPA, cisco Systems and Sun Microsystems. 2368 References 2370 1. S.Deering, D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, 2371 P.Sharma, and A.Helmy. Protocol independent multicast (pim) : 2372 Motivation and architecture. 2373 Internet Draft, May 1995. 2375 2. S.Deering, D.Estrin, D.Farinacci, V.Jacobson, C.Liu, and L.Wei. 2376 The pim architecture for wide-area multicast routing. 2377 ACM Transactions on Networks, April 1996. 2379 3. D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and 2380 A.Helmy. Protocol independent multicast-dense mode (pim-dm) : 2381 Protocol specification. Internet Draft, November 1995. 2383 4. S.Deering. Host extensions for ip multicasting, aug 1989. 2384 RFC1112. 2386 5. R.Atkinson. Security architecture for the internet protocol, 2387 August 1995. RFC-1825. 2389 6. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. 2390 In Proceedings of the ACM SIGCOMM, San Francisco, 1993.