idnits 2.17.1 draft-ietf-idmr-pim-sm-spec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-idmr-PIM-SM-spec-02', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-ietf-idmr-PIM-SM-spec-02', but the file name used is 'draft-ietf-idmr-pim-sm-spec-02' ** 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 37) 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 806 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 38 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 19 has weird spacing: '... Drafts are ...' == Line 20 has weird spacing: '...cuments of t...' == Line 21 has weird spacing: '...ups may also ...' == Line 25 has weird spacing: '... Drafts may ...' == Line 26 has weird spacing: '...iate to use ...' == (801 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 7, 1996) is 10213 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 43 looks like a reference -- Missing reference section? '2' on line 43 looks like a reference -- Missing reference section? '3' on line 58 looks like a reference -- Missing reference section? '4' on line 111 looks like a reference -- Missing reference section? '5' on line 1661 looks like a reference -- Missing reference section? '6' on line 2285 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Steven Deering (XEROX) 2 Internet Draft Deborah Estrin (USC) 3 Dino Farinacci (CISCO) 4 Mark Handley (UCL) 5 Ahmed Helmy (USC) 6 Van Jacobson (LBL) 7 Chinggung Liu (USC) 8 Puneet Sharma (USC) 9 David Thaler (UMICH) 10 Liming Wei (CISCO) 12 draft-ietf-idmr-PIM-SM-spec-02.txt May 7, 1996 14 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 15 Specification 17 Status of This Memo 19 This document is an Internet Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its Areas, 21 and its Working Groups. (Note that other groups may also distribute 22 working documents as Internet Drafts). 24 Internet Drafts are draft documents valid for a maximum of six 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet 27 Drafts as reference material or to cite them other than as a 28 ``working'' draft'' or ``work in progress.'' 30 Please check the I-D abstract listing contained in each Internet 31 Draft directory to learn the current status of this or any other 32 Internet Draft. 34 1 Introduction 36 This document describes a protocol for efficiently routing to 37 multicast groups that may span wide-area (and inter-domain) 38 internets. We refer to the approach as Protocol Independent 39 Multicast--Sparse Mode (PIM-SM) because it is not dependent on any 40 particular unicast routing protocol, and because it is designed to 41 support sparse groups as defined in [1][2]. This document describes 42 the protocol details. For the motivation behind the design and a 43 description of the architecture, see [1][2]. Section 2 summarizes 44 PIM-SM operation. It describes the protocol from a network 45 perspective, in particular, how the participating routers interact to 46 create and maintain the multicast distribution tree. Section 3 47 describes PIM-SM operations from the perspective of a single router 48 implementing the protocol; this section constitutes the main body of 49 the protocol specification. It is organized according to PIM-SM 50 message type; for each message type we describe its contents, its 51 generation, and its processing. Interoperability with other protocols 52 will be further discussed in an appendix to this document. 54 Section 4 provides packet format details. 56 The most significant functional changes since the January '95 57 version, are the Rendezvous Point-related mechanisms and the removal 58 of the PIM-DM protocol details to a separate [3] (for clarity). 60 2 PIM-SM Protocol Overview 62 In this section we provide an overview of the architectural 63 components of PIM-SM. 65 A router [*] 67 receives explicit Join/Prune messages from those neighboring routers 68 that have downstream group members. The router then forwards data 69 packets addressed to a multicast group, G, only onto those interfaces 70 on which explicit joins have been received. 72 A Designated Router (DR) sends periodic Join/Prune messages toward a 73 group-specific Rendezvous Point (RP) for each group for which it has 74 active members. Each router along the path toward the RP builds 75 wildcard (any-source) forwarding state for the group and sends 76 messages on toward the RP. The wildcard forwarding entry's incoming 77 _________________________ 78 [*] All routers mentioned in this document are assumed 79 to be PIM-SM capable, unless otherwise specified. 81 interface points toward the RP; the outgoing interfaces point to the 82 neighboring downstream routers that have sent Join/Prune messages 83 toward the RP. This forwarding state creates a shared, RP-centered, 84 distribution tree that reaches all group members. When a data source 85 first sends to a group, its DR unicasts Register messages to the RP 86 with the source's data packets encapsulated within. If the data rate 87 is high, the RP can send source-specific Join/Prune messages back 88 towards the source and the source's data packets will follow the 89 resulting forwarding state and travel unencapsulated to the RP. 90 Whether they arrive encapsulated or natively, the RP forwards the 91 source's decapsulated data packets down the RP-centered distribution 92 tree toward group members. If the data rate warrants it, routers with 93 local receivers can join a source-specific, shortest path, 94 distribution tree, and prune these source's packets off of the shared 95 RP-centered tree. Even if all receivers switch to the shortest path 96 tree, state for that source will be kept at the RP, so that new 97 members that join the RP-centered tree will receive data packets from 98 the source. For low data rate sources, neither the RP, nor last hop 99 routers need join a source-specific shortest path tree and data 100 packets can be delivered via the shared, RP-tree. 102 The following subsections describe SM operation in more detail, in 103 particular, the control messages, and the actions they trigger. 104 Section 3 describes protocol operation from an implementors 105 perspective, i.e., the actions performed by a single router. 107 2.1 Local hosts joining a group 109 In order to join a multicast group, G, a host sends an IGMP Host- 110 Membership-Report message identifying the particular group. As 111 specified in [4], IGMP Host-Membership-Report messages are sent in 112 response to a directly-connected router's IGMP Host-Membership-Query 113 message (see figure 1). [*] 115 From this point on we refer to such a host as a receiver, R, (or 116 member) of the group G. 118 _________________________ 119 [*] All figures used in this section are for illustra- 120 tion and are not intended to be complete. For complete 121 and detailed protocol action see Section 3. 123 Fig. 1 Example: how a receiver joins, and sets up shared tree 125 When a DR receives an IGMP Host-Membership-Report for a new group, G, 126 the DR looks up the associated RP. The DR (e.g., router A in figure 127 1) creates a wildcard multicast forwarding entry for the group, 128 referred to here as a (*,G) entry; if there is no more specific match 129 for a particular source, the packet will be forwarded according to 130 this entry. 132 The RP address is included in a special field in the forwarding entry 133 and is included in periodic upstream Join/Prune messages. The 134 outgoing interface is set to that over which the IGMP Host- 135 Membership-Report was received from the new member. The incoming 136 interface is set to the interface used to send unicast packets to the 137 RP. An RP-bit associated with this entry is also set, indicating that 138 this entry, (*,G), represents state on the shared RP-tree. Each DR on 139 the RP-tree with directly connected members sets a timer for this 140 entry. If the timer expires and the DR has neither local members nor 141 downstream receivers, the (*,G) state is deleted. If the DR does have 142 local members, it refreshes the (*,G) entry timer each time it gets 143 an IGMP Host-Membership-Report. 145 2.2 Establishing the RP-rooted shared tree 147 Triggered by the (*,G) state, the DR creates a Join/Prune message 148 with the RP address in its join list and the WC-bit and RP-bit set; 149 nothing is listed in its prune list. The RP-bit flags the join as 150 being associated with the shared tree and therefore the Join/Prune 151 message is propagated along the RP-tree. The WC-bit indicates that 152 the address is an RP and the receiver expects to receive packets from 153 all sources via this (shared tree) path. 155 Each upstream router creates or updates its multicast forwarding 156 entry for (*,G) when it receives a Join/Prune with the RP-bit and 157 WC-bit set. The interface on which the Join/Prune message arrived is 158 added to the list of outgoing interfaces (oifs) for (*,G). Based on 159 this entry each upstream router between the receiver and the RP sends 160 a Join/Prune message in which the join list includes the RP. The 161 packet payload contains Multicast-Address=G, Join=RP,WCbit,RPbit, 162 Prune=NULL. 164 2.3 Hosts sending to a group 166 When a host first sends a multicast data packet to a group, its DR 167 must deliver the packet to the RP for distribution down the RP-tree 168 (see figure 2). This is done by the sender's DR unicasting a Register 169 packet to the RP for the group. The data packet is encapsulated in 170 the Register packet so that the RP can decapsulate it and deliver it 171 to downstream members. 173 Fig. 2 Example: a host sending to a group 175 If the data rate of the source warrants [*] 177 the use of a source-specific shortest path tree (SPT), the RP may 178 construct a new multicast forwarding entry that is specific to the 179 source, hereafter referred to as (S,G) state, and send periodic 180 Join/Prune messages toward the source. The routers between the source 181 and the RP build and maintain (S,G) state in response to these 182 messages and send (S,G) messages upstream toward the source. 184 The source's DR must stop encapsulating data packets in Registers 185 when (and so long as) it receives Register-Stop messages from the RP. 186 The RP triggers Register-Stop messages in response to Registers, if 187 the RP has no downstream receivers for the group (or for that 188 particular source), or if the RP has already joined the (S,G) tree 189 and is receiving the data packets natively. 191 2.4 Switching from shared tree (RP-tree) to shortest path tree (SP- 192 tree)} 194 When a router has directly-connected members, it first joins the 195 shared RP-tree. The router can switch to a source's shortest path 196 tree (SP-tree) after receiving packets from that source over the 197 shared RP-tree. The recommended policy is to initiate the switch to 198 the SP-tree after receiving a significant number of data packets 199 _________________________ 200 [*] This decision is a local policy established at the 201 RP. For example, when the Register rate exceeds a con- 202 figured threshold at the RP, this may warrant the use 203 of the SPT. 205 during a specified time interval from a particular source. To realize 206 this policy the router can monitor data packets from sources for 207 which it has no source-specific multicast forwarding entry and 208 initiate such an entry when the data rate exceeds the configured 209 threshold. As shown in figure 3, router `A' initiates a (S,G) state. 211 Fig. 3 Example: Switching from shared tree to shortest path tree 213 When a (S,G) entry is activated (and periodically so long as the 214 state exists), a Join/Prune message is sent upstream towards the 215 source, S, with S in the join list. The payload contains Multicast- 216 Address=G, Join=S, Prune=NULL. When the (S,G) entry is created, the 217 outgoing interface list is copied from (*,G), i.e., all local shared 218 tree branches are replicated in the new shortest path tree [*] In 219 this way when a data packet from S arrives and matches on this entry, 220 all receivers will continue to receive the source's packets along 221 this path. Note that (S,G) state must be maintained in all last-hop 222 routers where an SP-tree is maintained. Even when (*,G) and (S,G) 223 overlap, both states are needed to trigger the source-specific 224 Join/Prune messages. (S,G) state is kept alive by data packets 225 arriving from that source. A timer, S-timer, is set for the (S,G) 226 entry and this timer is restarted whenever a data packet for (S,G) is 227 forwarded out at least one oif. When the S-timer expires the state is 228 deleted. 230 Only the RP and routers with local members can initiate switching to 231 the SP-tree; intermediate routers do not. Consequently, last hop 232 routers create (S,G) state in response to data packets from the 233 source, S; whereas intermediate routers only create (S,G) state in 234 response to Join/Prune messages from downstream that have S in the 235 Join list [*] 236 _________________________ 237 [*] In more complicated scenarios, other entries in the 238 router have to be considered. For details see Section 3. 239 [*] For example, to implement the policy that source- 240 specific trees are only setup for high-data rate 241 source, a last-hop router might not create a (S,G) en- 242 try until it has received m data packets from the 243 source within some interval of n seconds. 245 The (S,G) entry is initialized with the SPT-bit cleared, indicating 246 that the shortest path tree branch from S has not yet been setup 247 completely, and the router can still accept packets from S that 248 arrive on the (*,G) entry's iif. 250 When a router with a (S,G) entry and a cleared SPT-bit starts to 251 receive packets from the new source S on the iif for the (S,G) entry, 252 and that iif differs from the (*,G) entry's iif, the router sets the 253 SPT-bit, and sends a Join/Prune message towards the RP, indicating 254 that the router no longer wants to receive packets from S via the 255 shared RP-tree. The Join/Prune message sent towards the RP includes S 256 in the prune list, with the RP-bit set indicating that S's packets 257 should not be forwarded down this branch of the shared tree. If the 258 router receiving the Join/Prune message has (S,G) state (with or 259 without the RPbit set), it deletes the arriving interface from the 260 (S,G) oif list. If the router has only (*,G) state, it creates an 261 (S,G)RP-bit entry. The Join/Prune message payload contains 262 Multicast-Address=G, Join=NULL, Prune=S,RPbit. 264 If at a later time a new receiver joins the RP-tree, the negative 265 cache state on the RP-tree must be eradicated to bring all sources' 266 data packets down to the new receiver. Therefore, when a (*,G) Join 267 arrives with a null prune list at a router that has any (S,G)RP-bit 268 entries (which is causing it to send source-specific prunes toward 269 the RP), all RP-bit state for that group has to be updated upstream 270 of the router; so as to bring all sources' packets down to the new 271 member. To accomplish this the router updates all existing (S,G)RP- 272 bit entries; it adds to each (S,G)RP-bit entry's oif list the 273 interface on which the (*,G) join arrived. The router also triggers a 274 (*,G) join upstream to cause the same updating of RP-bit settings 275 upstream and pull down all active sources' packets. If the arriving 276 (*,G) join has some sources included in its prune list, then the 277 corresponding (S,G)RP-bit entries are left unchanged (i.e., the RPbit 278 remains set and no oif is added). 280 2.5 Steady state maintenance of distribution tree (i.e., router state)} 282 In the steady state each router sends periodic Join/Prune messages 283 for each active (S,G), (*,G) or (*,*,RP) [*] 285 entry; the Join/Prune messages are sent to the RPF neighbor on the 286 iif of the corresponding entry. These messages are sent periodically 287 to capture state, topology, and membership changes. A Join/Prune 288 _________________________ 289 [*] (*,*,RP) entry is introduced for interoperability, 290 see Sections 2.10 and 6. 292 message is also sent on an event-triggered basis each time a new 293 forwarding entry is established for some new source (note that some 294 damping function may be applied, e.g., a merge time). Join/Prune 295 messages do not elicit any form of explicit acknowledgment; routers 296 recover from lost packets using the periodic refresh mechanism. 298 2.6 Obtaining RP information 300 To obtain the RP information, all routers collect RP-Set messages. 301 RP-Set messages are sent hop-by-hop within the domain; originating at 302 the domain's bootstrap router (BSR). The BSR is elected dynamically 303 within each domain. 304 [*] 306 Routers then use the set of RPs to get the proper Group to RP 307 mapping. Details are as follows: 309 2.6.1 Bootstrap Router 311 A (small) set of routers, within a domain, are configured as 312 candidate bootstrap routers. Initially, each of these candidates 313 includes its address in `RP-set' messages. Through a simple election 314 mechanism, a single bootstrap router (BSR) is elected for that domain 315 (see Section 3.6). 316 2.6.2 Candidate RPs 318 A set of routers within a domain are configured as candidate RPs (C- 319 RPs); typically these will be the same routers that are configured as 320 C-BSRs. Candidate RPs periodically unicast Candidate-RP-Advertisement 321 messages (C-RP-Advs) to the BSR of that domain. C-RP-Advs include the 322 address of the advertising C-RP, as well as an optional group address 323 and a mask length field, indicating the group prefix(es) for which 324 the candidacy is advertised. The BSR then includes a set of these 325 Candidate-RPs in the RP-Set messages, along with the corresponding 326 group prefixes (see Section 327 3.6.2). RP-Set messages are periodically sent hop-by-hop throughout 328 the domain. 330 _________________________ 331 [*] A domain in this context is a multicast region in 332 which routers implement PIM-SM. PIM-SM border routers 333 are assumed to connect a domain to the rest of the in- 334 ternet. 336 2.6.3 Group to RP mapping 338 Routers receive and store RP-Set messages originated by the BSR. When 339 a DR receives IGMP Host-Membership-Report (or a data packet) from a 340 directly connected host, for a group for which it has no entry, the 341 DR uses a hash function to map the pertinent group to one of the C- 342 RPs whose Group-prefix includes the group (see Section 3.7). The DR 343 then sends a Join/Prune message towards (or unicasts Registers to) 344 that RP. 345 [*] 347 2.6.4 Providing RP liveness 349 The RP-Set message indicates liveness of the RPs included therein; if 350 an RP is included in the message, then it is tagged as `up' at the 351 routers, while RPs not included in the message are tagged as `down' 352 and removed from the list of RPs over which the hash algorithm acts. 353 Each router continues to use the contents of the most recently 354 received RP-set message until it receives a new RP-set message. 356 2.7 Multicast data packet processing 358 Data packets are processed in a manner similar to existing multicast 359 schemes. A router first performs a longest match on the source and 360 group address in the data packet. A (S,G) entry is matched first if 361 one exists; a (*,G) entry is matched otherwise. If neither state 362 exists, then a (*,*,RP) entry match is attempted as follows: the 363 router hashes on G to identify the RP for group G, and looks for a 364 (*,*,RP) entry that has this RP address associated with it. If none 365 of the above exists, then the packet is dropped. If a state is 366 matched, an incoming interface check (RPF check) is performed on the 367 matching state and if it fails the packet is dropped, otherwise the 368 packet is forwarded to all interfaces listed in the outgoing 369 interface list. 371 Some special actions are needed to deliver packets continuously while 372 switching from the shared to shortest-path tree. In particular, when 373 a (S,G) entry is matched, incoming packets are forwarded as follows: 375 1 If the SPT-bit is set, then: 376 _________________________ 377 [*] Each intermediate router also uses this same hash 378 function to determine the (*,*,RP) match for incoming 379 data packets. 381 1 if the incoming interface is the same as a matching 382 (S,G) iif, the packet is forwarded to the oif-list of 383 (S,G). 385 2 if the incoming interface is different than a matching 386 (S,G) iif , the packet is discarded. 388 2 If the SPT-bit is cleared, then: 390 1 if the incoming interface is the same as a matching 391 (S,G) iif, the packet is forwarded to the oif-list of 392 (S,G). In addition, the SPT bit is set for that entry 393 if the incoming interface differs from the incoming 394 interface of the (*,G) or (*,*,RP) entry. 396 2 if the incoming interface is different than a matching 397 (S,G) iif, the incoming interface is tested against a 398 matching (*,G) or (*,*,RP) entry. IF the iif is the 399 same as one of those, the packet is forwarded to the 400 oif-list of the matching entry. 402 3 Otherwise the iif does not match any entry for G and 403 the packet is discarded. 405 Data packets never trigger prunes. However, data packets may 406 trigger actions that in turn trigger prunes. For example, when 407 router B in figure 3 decides to switch to SP-tree at step 3, it 408 creates a (S,G) entry with SPT-bit set to 0. When data packets 409 from S arrive at interface 2 of B, B sets the SPT-bit to 1 410 since the iif for (*,G) is different than that for (S,G). This 411 triggers the sending of prunes towards the RP. 413 2.8 Operation over Multi-access Networks 415 This section describes a few additional protocol mechanisms 416 needed to operate PIM over multi-access networks: Designated 417 Router election, Assert messages to resolve parallel paths, and 418 the Joiner bit to suppress redundant Joins on multi-access 419 networks. 421 2.8.1 Designated router election 423 When there are multiple routers connected to a multi-access 424 network, one of them should be chosen to operate as the 425 designated router (DR) at any point in time. The DR is 426 responsible for sending triggered Join/Prune and Register 427 messages toward the RP [*] 429 A simple designated router (DR) election mechanism is used for 430 both SM and traditional IP multicast routing. 432 Neighboring routers send Query messages to each other. The 433 sender with the largest IP address assumes the role of DR. Each 434 router connected to the multi-access LAN sends the Queries 435 periodically in order to adapt to changes in router status. 437 2.8.2 Parallel paths to a source or the RP 439 If a router receives a multicast datagram on a multi-access LAN 440 from a source whose corresponding (S,G) outgoing interface list 441 includes the interface to that LAN, the packet must be a 442 duplicate. In this case a single forwarder must be elected. 443 Using Assert messages addressed to `224.0.0.13' (ALL-PIM-ROUTERS 444 group) on the LAN, upstream routers can resolve which one will 445 act as the forwarder. Downstream routers listen to the Asserts 446 so they know which one was elected, and therefore where to send 447 subsequent Joins. Typically this is the same as the downstream 448 router's RPF neighbor but there are circumstances where this 449 might not be the case, e.g., when using different unicast 450 protocols. 452 The upstream router elected is the one that has the shortest 453 distance to the source. Therefore, when a packet is received on 454 an outgoing interface a router sends an Assert message on the 455 multi-access LAN indicating what metric it uses to reach the 456 source of the data packet. The router with the smallest 457 numerical metric (with ties broken by highest address) will 458 become the forwarder. All other upstream routers will delete the 459 interface from their outgoing interface list. The downstream 460 routers also do the comparison in case the forwarder is 461 different than the RPF neighbor. 462 _________________________ 463 [*] IGMP Queries are sent by a PIMv2 DR if it supports 464 IGMPv1. If a PIMv2 router is using IGMPv2 then Host 465 queries are not sent by the PIMv2 DR but by the IGMP 466 querier. 468 Associated with the metric is a metric preference value. This is 469 provided to deal with the case where the upstream routers may 470 run different unicast routing protocols. The numerically smaller 471 metric preference is always preferred. The metric preference 472 should be treated as the high-order part of an assert metric 473 comparison. Therefore, a metric value can be compared with 474 another metric value provided both metric preferences are the 475 same. A metric preference can be assigned per unicast routing 476 protocol and needs to be consistent for all routers on the 477 multi-access network. 479 Asserts are also needed for (*,G) entries since there may be 480 parallel paths from the RP and sources to a multi-access 481 network. When an assert is sent for a (*,G) entry, the first bit 482 in the metric preference (RP-bit) is always set to 1 to indicate 483 that this path corresponds to the RP tree, and that the match 484 should be done on (*,G) if exits. Furthermore, the RP-bit is 485 always cleared for SP-tree entries' metric preference; this 486 causes an SP-tree path to always look better than an RP-tree 487 path. When the SP-tree and RPtree cross the same LAN, this 488 mechanism eliminates the duplicates that would otherwise be 489 carried over the LAN. 491 In case the packet, or the Assert message, matches on oif for 492 (*,*,RP) entry, a (*,G) entry is created, and asserts take place 493 as if the matching state were (*,G). 495 The DR may lose to another router on the LAN by the Assert 496 process if there are multiple paths to the RP through the LAN. 497 From then on, the DR is no longer the last-hop router for local 498 receivers. The winning router becomes the last-hop router and is 499 responsible for sending (*,G) join messages to the RP. Asserts 500 are rate limited. 502 2.8.3 Join/Prune suppression 504 If a Join/Prune message arrives on the incoming interface for an 505 existing (S,G) entry, and the sender of the Join/Prune has a 506 higher IP address than the recipient of the message, a Joiner- 507 bit in the multicast routing table entry is cleared to suppress 508 further Join/Prune messages. A timer is set for the Joiner-bit; 509 after it expires the Joiner-bit is set indicating further 510 periodic Join/Prunes should be sent for this entry. The Joiner- 511 bit timer is restarted each time a Join/Prune message is 512 received from a higher-IP-addressed PIM neighbor. 514 2.9 Unicast Routing Changes 516 When unicast routing changes, an RPF check is done on all active 517 (S,G), (*,G) and (*,*,RP) entries, and all affected expected 518 incoming interfaces are updated. In particular, if the new 519 incoming interface appears in the outgoing interface list, it is 520 deleted from the outgoing interface list. The previous incoming 521 interface may be added to the outgoing interface list by a 522 subsequent Join/Prune from downstream. Join/Prune messages 523 received on the current incoming interface are ignored. 524 Join/Prune messages received on new interfaces or existing 525 outgoing interfaces are not ignored. Other outgoing interfaces 526 are left as is until they are explicitly pruned by downstream 527 routers or are timed out due to lack of appropriate Join/Prune 528 messages. If the router has a (S,G) entry with the SPT-bit set, 529 and the updated iif(S,G) does not differ from iif(*,G) or 530 iif(*,*,RP), then the router resets the SPT-bit. 532 The router must send a Join/Prune message with S in the Join 533 list out its new incoming interface to inform upstream routers 534 that it expects multicast datagrams over the interface. It may 535 also send a Join/Prune message with S in the Prune list out the 536 old incoming interface, if the link is operational, to inform 537 upstream routers that this part of the distribution tree is 538 going away. 540 2.10 Interaction with dense mode protocols such as DVMRP 542 The essential problem in connecting to dense mode protocols is 543 to pull all packets generated within the PIM-SM region down to 544 the dense mode routers. To do this, a special entry type, 545 referred to as (*,*,RP), is introduced. Every (*,*,RP) entry is 546 associated with a particular RP in the domain; that RP is used 547 to conduct RPF checks. Border routers initiate the building of 548 (*,*,RP) towards all internal Candidate RPs. (*,*,RP) entries 549 represent an aggregation of all the groups supported by the RP. 551 Most of the mechanisms needed to support interoperability with 552 dense mode protocols such as DVMRP are implemented in BRs, i.e., 553 special routers that sit at the boundary between a PIM-SM 554 regions and the DVMRP regions and which speak both protocols. 555 However, all PIM-SM routers must be capable of supporting 556 (*,*,RP) state and interpreting associated Join messages. 557 Interaction with non-PIM-SM networks will be discussed in a 558 separate interoperability appendix. 560 2.11 PIM-SM for Inter-Domain Multicast 562 Future documents will address the use of PIM-SM as a backbone 563 inter-domain multicast routing protocol. Design choices center 564 primarily around the distribution and usage of RP information 565 for wide area, inter-domain groups. 567 2.12 Security 569 { Editors Note: This section requires further work.} 571 All PIM control messages may use [5] to address security 572 concerns. 574 3 Detailed Protocol Description 576 This section describes the protocol operations from the 577 perspective of an individual router implementation. In 578 particular, for each message type we describe how it is 579 generated and processed. 581 3.1 Query 583 Query messages are sent so neighboring routers can discover each 584 other. 586 3.1.1 Sending Queries 588 Query messages are sent periodically between PIM neighbors. By 589 default they are transmitted every 30 seconds. This informs 590 routers what interfaces have PIM neighbors. Query messages are 591 multicast using address 224.0.0.13 (ALL-PIM-ROUTERS group). The 592 packet includes the holdtime for neighbors to keep the 593 information valid. The recommended holdtime is 3 times the query 594 transmission interval. By default the holdtime is 90 seconds. 595 Queries are sent on all types of communication links. 597 3.1.2 Receiving queries 599 When a router receives a Query packet, it stores the IP address 600 for that neighbor, sets the PIM neighbor timer based on the 601 Query holdtime, and determines the Designated Router (DR) for 602 that interface. The highest IP addressed system is elected DR. 603 Each query received causes the DR's address to be updated. 605 When a router that is the active DR receives a query from a new 606 neighbor (i.e., from an IP address that is not yet in the DRs 607 neighbor table), the DR unicasts its most recent RP-set 608 information to the new neighbor. 610 3.1.3 Timing out neighbor entries 612 A periodic process is run to time out PIM neighbors that have 613 not sent queries. If the DR has gone down, a new DR is chosen by 614 scanning all neighbors on the interface and selecting the new DR 615 to be the one with the highest IP address. If an interface has 616 gone down, the router may optionally time out all PIM neighbors 617 associated with the interface. 619 3.2 Join/Prune 621 Join/Prune messages are sent to join or prune a branch off of 622 the multicast distribution tree. A single message contains both 623 a join and prune list, either one of which may be null. Each 624 list contains a set of source addresses, indicating the source- 625 specific trees or shared tree that the router wants to join or 626 prune. 628 3.2.1 Sending Join/Prune Messages 630 Join/Prune messages are merged such that a message sent to a 631 particular upstream neighbor, N, includes all of the current 632 joined and pruned sources that are reached via N; according to 633 unicast routing Join/Prune messages are multicast to all routers 634 on multi-access networks with the target address set to the next 635 hop router towards S or RP. Join/Prune messages are sent 636 periodically. Currently the period is set to 60 seconds. [*] 638 A router sends a periodic Join/Prune message to each 639 distinct RPF neighbor associated with each (S,G), (*,G) and 640 (*,*,RP) entry. Join/Prune messages are only sent if the RPF 641 neighbor is a PIM neighbor. A periodic Join/Prune message sent 642 towards a particular RPF neighbor is constructed as follows: 644 1 Each router determines the RP for a (*,G) entry by using 645 the hash function described. The RP address (with RP and WC 646 bits set) is included in the join list of a periodic 647 Join/Prune message under the following conditions: 649 1 The Join/Prune message is being sent to the RPF 650 neighbor to the RP for an active (*,G) or (*,*,RP) 651 entry, and 653 2 The outgoing interface list in the (*,G) or (*,*,RP) 654 entry is non-NULL, or the router is the DR on the same 655 interface as the RPF neighbor. 657 _________________________ 658 [*] In the future we will introduce mechanisms to 659 rate-limit this control traffic on a hop by hop basis, 660 in order to avoid excessive overhead on small links. 662 2 A particular source address, S, is included in the join 663 list with the RP and WC bits cleared under the following 664 conditions: 666 1 The Join/Prune message is being sent to the RPF 667 neighbor to S, and 669 2 There exists an active (S,G) entry with the RPbit 670 cleared, and 672 3 The oif list in the (S,G) entry is not null. 674 3 A particular source address, S, is included in the prune 675 list with the RP and WC bits cleared under the following 676 conditions: 678 1 The Join/Prune message is being sent to the RPF 679 neighbor to S, and 681 2 There exists an active (S,G) entry with the RPbit 682 cleared, and 684 3 The oif list in the (S,G) entry is null. 686 4 A particular source address, S, is included in the prune 687 list with the RP bit set and the WC bit cleared under the 688 following conditions: 690 1 The Join/Prune message is being sent to the RPF 691 neighbor toward the RP and there exists a (S,G) entry 692 with the RPbit set and null oif list, or 694 2 The Join/Prune message is being sent to the RPF 695 neighbor toward the RP, there exists a (S,G) entry 696 with the RPbit cleared and SPT-bit set, and the 697 incoming interface toward S is different than the 698 incoming interface toward the RP, or 700 3 The Join/Prune message is being sent to the RPF 701 neighbor toward the RP, and there exists a (*,G) entry 702 and (S,G) entry for a directly connected source. 704 5 The RP address (with RP and WC bits set) is included in the 705 prune list if: 707 1 The Join/Prune message is being sent to the RPF 708 neighbor toward the RP and there exists a (*,G) entry 709 with a null oif list (see Section 3.5.2). 711 In addition to these periodic messages, the following events 712 will trigger Join/Prune messages (the contents of triggered 713 messages are the same as the periodic, described above) 715 1 Receipt of an IGMP Host-Membership-Report message for a 716 group G will cause building or modifying corresponding 717 (*,G) state, and subsequent triggering of upstream 718 Join/Prune messages as follows: 720 1 If the receiving router does not have a forwarding 721 entry for G the router creates a (*,G) entry, with the 722 interface upon which the IGMP Host-Membership-Report 723 was received included in the oif list. The router 724 sends a Join/Prune message towards the RP with the RP 725 address and RP-bit and WC-bits set in the join list. A 726 timer is initiated for each interface in the oif list. 727 Or, 729 2 If the (*,G) already exists, the interface upon which 730 the IGMP Host-Membership-Report was received is added 731 to the oif list (if it was not included already) and 732 the timer for that interface is restarted. 734 2 Receipt of a Join/Prune message for (S,G), (*,G) or 735 (*,*,RP) will cause building or modifying corresponding 736 state, and subsequent triggering of upstream Join/Prune 737 messages, in the following cases: 739 1 When there is no current forwarding entry, the RP 740 address included in the Join/Prune message is checked 741 against the local RP-Set information. If it matches, 742 an entry will be created. If the router has no RP-Set 743 information it may discard the message, or optionally 744 use the RP address included in the message. 746 The new entry will in turn trigger an upstream 747 Join/Prune message. 749 2 When the outgoing interface list of (S,G) RPbit entry 750 is null, the triggered Join/Prune message will contain 751 S in the prune list. 753 3 Receipt of a packet on a (S,G) entry whose SPT-bit is 754 cleared triggers the following if the packet arrived on the 755 correct incoming interface and there is a (*,G) or (*,*,RP) 756 entry with a different incoming RPF neighbor: a) setting of 757 the SPT-bit on (S,G) entry, and b) sending a Join/Prune 758 message towards the RP with S,RP-bit in the prune list if 759 the iif of (S,G) is different from the iif of (*,G) or 760 (*,*,RP). 762 4 When a Join/Prune message is received for a group G, the 763 prune list is checked. If it contains a source for which 764 the receiving router has a corresponding active (S,G), 765 (*,G) or (*,*,RP) entry, and whose iif is that on which 766 the Join/Prune was received, then a join for (S,G), (*,G) 767 or (*,*,RP) is triggered to override the prune, 768 respectively. (This is necessary in the case of parallel 769 downstream routers connected to a multi-access network.) 771 5 When the RP fails, the RP will not be included in the RP- 772 Set messages sent to the receivers' last-hop routers. This 773 triggers the last-hop routers to send (*,G) joins towards 774 the new RP for the group, as determined by the RP-Set and 775 the hash function [*] 777 _________________________ 778 [*] PIM Multicast Border Routers (PMBRs), handling in- 779 teroperability functionality, trigger (*,*,RP) joins 780 towards each RP in the RP-Set. 782 We do not trigger prunes onto interfaces for SM groups based on 783 data packets. Data packets that arrive on the wrong incoming 784 interface for an SM group are silently dropped. 786 It is possible that a Join/Prune message constructed according 787 to the preceeding rules could exceed the MTU of a network. In 788 this case, the message can undergo semantic fragmentation 789 whereby information corresponding to different groups can be 790 sent in different messages. However, if a Join/Prune message 791 must be fragmented the following rule must be followed: 793 1 The complete prune list corresponding to a group G must be 794 included in the same Join/Prune message as the associated 795 RP-tree Join for G. 797 3.2.2 Receiving Join/Prune Messages When a router receives a 798 Join/Prune message, it processes it as follows: 800 1 The receiver of the Join/Prune notes the interface on which 801 the PIM message arrived, call it I. The router accepts this 802 Join/Prune message if this Join/Prune message is addressed 803 to the router itself. If the Join/Prune is for this router 804 the following actions are taken: 806 1 If an address Sj in the join list has RP-bit and WC- 807 bit set, then Sj is the RP address used by the 808 downstream router and the following actions are taken: 810 1 If Sj is not the same as the receiving router's 811 RP mapping for G, the receiving router may ignore 812 that group entry in the Join/Prune message. If 813 the router does not have any RP-Set information, 814 it may use the address Sj included in the 815 Join/Prune message as the RP for the group. 817 2 If Sj is the same as the receiving router's RP 818 mapping for G, it adds I to the outgoing 819 interface list of the (*,G) forwarding entry and 820 sets the timer for that interface (if there is no 821 (*,G) entry, the router creates one first). If a 822 (*,*,RP) exists, for the RP associated with G, 823 then the oif list of the newly created (*,G) is 824 copied from that (*,*,RP) state, excluding 825 iif(*,G), 827 3 For each (Si,G) entry associated with group G, if 828 Si is not included in the prune list, and if I is 829 not the iif then interface I is added to the 830 oif list and the timers are restarted for that 831 interface in each affected entry. If the G in the 832 join message is `*' [*] , then every (*,G) and 833 (S,G) entry, whose group address hashes to the RP 834 indicated in the (*,*,RP) join message, is 835 updated accordingly, 837 4 If the (Si,G) entry is an RP-bit entry and its 838 oif list is the same as (*,G) oif list, 839 then the (Si,G,RPbit) entry is deleted, 841 5 The incoming interface is set to the interface 842 used to send unicast packets to the RP in the 843 (*,G) forwarding entry, i.e., RPF interface to 844 the RP. 846 2 For each address Si in the join list whose RP-bit and 847 WC-bit are not set, and for which there is no 848 existing (Si,G) forwarding entry, the router initiates 849 one. 850 [*] 851 _________________________ 852 [*] A `*' in the group field of the Join/Prune is 853 represented by a group address 224.0.0.0 and a group 854 mask length of 4, indicating a (*,*,RP) Join. 855 [*] The router creates a (S,G) entry and copies all 856 outgoing interfaces, excluding iif(S,G), from the 857 (S,G)RP-bit, (*,G), or (*,*,RP), entry, if it exists. 858 If a router does not copy all outgoing interfaces from 859 the (*,G), or (*,*,RP) entry, all receivers on RP-tree, 860 downstream from outgoing interfaces other than the one 861 1 The outgoing interface for (Si,G) is set to I. 862 The incoming interface for (Si,G) is set to the 863 interface used to send unicast packets to Si 864 (i.e., the RPF neighbor). 866 2 If the interface used to reach Si is the same as 867 the outgoing interface being built, I, this 868 represents an error and the Join/Prune should not 869 be processed. 871 3 For any Si included in the join list of the Join/Prune 872 message, for which there is an existing (Si,G) 873 forwarding entry, 875 1 If the RP-bit is not set for Si listed in the 876 Join/Prune message, but the RP-bit is set on the 877 existing (Si,G) entry, the router clears the RP- 878 bit on (Si,G) entry, sets the incoming interface 879 to point towards Si for that (Si,G) entry, and 880 sends a Join/Prune to the new incoming interface; 881 and 883 2 The router adds I to the list of outgoing 884 interfaces if I is not the same as the existing 885 incoming interface; the timer for I is restarted. 887 3 The (Si,G) SPT bit is initialized to be cleared 888 until data comes down the shortest path tree. 890 4 For each address Si in the prune list, with the RP-bit 891 is either set or cleared, and the WC-bit cleared: 892 _________________________ 893 newly added to (S,G), will not receive packets from 894 source S. Data packets of S arriving from the RP will 895 match the (S,G) entry instead of (*,G), or (*,*,RP), 896 entry, and will be dropped because the incoming inter- 897 face is incorrect. 899 1 If there is an existing (Si,G) forwarding entry, 900 the router schedules a deletion of I from the 901 list of outgoing interfaces by lowering that oif 902 timer to 5 seconds (unless it is already lower). 903 The deletion is not executed until this timer 904 expires, allowing for other downstream routers on 905 a multi-access LAN to override the prune. 907 2 If the router has a current (*,G), or (*,*,RP), 908 forwarding entry, and if a (Si,G)RP-bit entry 909 also exists then the (Si,G)RP-bit entry is 910 maintained even if its outgoing interface list is 911 null. 913 5 For any Si in the prune list that has the RP-bit set, 914 and the WC-bit cleared: 916 1 If (*,G), or corresponding (*,*,RP), state 917 exists, but there is no (Si,G) entry, an 918 (Si,G)RP-bit entry is created . The outgoing 919 interface list is copied from the (*,G), or 920 (*,*,RP), entry, with the interface, I, on which 921 the prune was received deleted. Packets from the 922 pruned source, Si, match on this state and are 923 not forwarded toward the pruned receivers. 925 2 If there exists a (Si,G) entry, with or without 926 the RPbit set, the iif on which the prune was 927 received, I, is deleted from the oif list, 928 and the entry timer is restarted. 930 6 For each address Si in the prune list, with the RP-bit 931 and the WC-bit set: 933 1 If there is an existing (*,G) entry, with Si as 934 the RP for G, the router schedules a deletion of 935 I from the list of outgoing interfaces by 936 lowering that oif timer to 5 seconds (unless it 937 is already lower). The deletion is not executed 938 until this timer expires, allowing for other 939 downstream routers on a multi-access LAN to 940 override the prune. 942 2 If the corresponding (*,*,RP) state exists, but 943 there is no (*,G) entry, a (*,G) entry is 944 created. The outgoing interface list is copied 945 from (*,*,RP) entry, with the interface, I, on 946 which the prune was received, deleted. 948 3 If there exists a (*,G) entry, the interface on 949 which the prune was received, I, is deleted from 950 the oif list, and the entry timer is 951 restarted. 953 2 If the received Join/Prune does not indicate the router as 954 its target, then if the Join/Prune is for a (S,G) pair for 955 which the router has an active (S,G) entry, and if the 956 Join/Prune arrived on the iif for that entry, then the 957 router compares the IP address of the generator of the 958 Join/Prune, to its own IP address. 960 1 If its own IP address is higher, the Joiner-bit in the 961 (S,G) entry is set. 963 2 If its own IP address is lower, the Joiner-bit in the 964 (S,G) entry is cleared, and the Joiner-bit timer is 965 activated. 967 After the timer expires the Joiner-bit is set indicating 968 further periodic Join/Prunes should be sent for this entry. 969 The Joiner-bit timer is restarted each time a Join/Prune 970 message is received from a higher-IP-addressed PIM 971 neighbor. 973 For any new (S,G), (*,G) or (*,*,RP) entry created by an 974 incoming Join/Prune message, the Joiner-bit is set and the 975 SPT-bit is cleared. 977 3.3 Register and Register-Stop 979 When a source first starts sending to a group its packets are 980 encapsulated in Register messages and sent to the RP. If the 981 data rate warrants source-specific paths, the RP sets up source 982 specific state and starts sending (S,G) Join/Prune messages 983 toward the source. 985 3.3.1 Sending Registers and Receiving Register-Stops 987 Register messages are sent as follows: 989 1 When a DR receives a packet from a directly connected 990 source, S [*] : 992 1 If there is no corresponding (S,G) entry, and the 993 router has RP-Set information, the DR creates one with 994 the Register-bit set to 1 and the RP address set 995 according to the hash function mapping for the 996 corresponding group. The Register-bit-timer is 997 initialized to zero; the Register-bit-timer is non- 998 zero only when the Register-bit is set to 0. 1000 2 If there is a (S,G) entry in existence, the DR simply 1001 restarts the corresponding S-timer (entry timer). 1002 _________________________ 1003 [*] When a border router (e.g., a router that connects 1004 the PIM-SM region to a dense mode region running DVMRP 1005 or PIM-DM) receives a packet from a source in the dense 1006 mode region, the router treats the packet as if it were 1007 from a directly connected source. See the Appendix on 1008 Interoperability for more details. 1010 2 If the new or previously-existing (S,G) entry has the 1011 Register-bit set, the data packet is encapsulated in a 1012 Register message and unicast to the RP for that group. The 1013 data packet is also forwarded according to (S,G) state in 1014 the DR if the oif list is not null; since a receiver may 1015 join the SP-tree while the DR is still registering to the 1016 RP. 1018 3 If the (S,G) entry has the Register-bit cleared, the data 1019 packet is not sent in a Register message, it is just 1020 forwarded according to the (S,G) oif list. 1022 The DR processes Register-Stop messages as follows: 1024 1 The DR clears the Register-bit and restarts the Register- 1025 bit-timer in the corresponding (S,G) entry(ies). 1027 When a Register-bit-timer expires, the corresponding entry(ies) 1028 Register-bit is set to 1 to reinstigate encapsulation of data 1029 packets in Register messages. 1031 3.3.2 Receiving Register Messages and Sending Register-Stops 1033 When a router (i.e., the RP) receives a Register message, the 1034 router does the following: 1036 1 Decapsulates the data packet, and checks for a 1037 corresponding (S,G) entry. 1039 1 If a (S,G) entry exists, the packet is forwarded but 1040 the SPT bit is left cleared (0). If the SPT bit is 1, 1041 the packet is dropped, and Register-Stop messages are 1042 triggered. Register-Stops are rate limited. [*] 1043 _________________________ 1044 [*] Register-Stops should be rate limited so that no 1045 more than a few are sent per round trip time. This 1046 2 If there is no (S,G) entry, but there is a (*,G) 1047 entry, or a (*,*,RP) entry with the RP corresponding 1048 to G, the packet is forwarded according to that entry. 1050 3 If there is a (*,*,RP) entry but no (*,G) entry, a 1051 (*,G) or (S,G) entry is created and the oif is copied 1052 from the (*,*,RP) entry to the new entry. 1054 4 If there is no G or (*,*,RP) entry corresponding to G, 1055 the packet is dropped, and a Register-Stop is 1056 triggered. 1058 5 A ``Border bit'' bit is added to the Register message, 1059 to facilitate interoperability mechanisms. PIM MBRs 1060 set this bit when registering for external sources 1061 (see Sections 2.10 and 6). If the ``Border bit'' is 1062 set in the Register, the RP does the following: 1064 1 If there is no matching (S,G) state, the RP 1065 creates one, with a `PMBR' field. This field 1066 holds the source of the Register (i.e. the outer 1067 IP address of the register packet). The RP 1068 triggers a (S,G) join towards the source of the 1069 data packet, and clears the SPT bit for the (S,G) 1070 entry, else 1072 2 If the `PMBR' field for the corresponding (S,G) 1073 entry matches the source of the Register packet, 1074 the decapsulated packet is forwarded to the oif 1075 list of that entry, else 1077 3 The packet is dropped, and a Register-stop is 1078 triggered towards the source of the Register. 1080 _________________________ 1081 prevents a high datarate stream of packets from 1082 triggering a large number of Register-stop messages 1083 between the time that the first packet is received and 1084 the time when the source receives the first Register- 1085 Stop. 1087 The (S,G) state timer is restarted by Registers arriving 1088 from that source to that group. 1090 2 If the matching (S,G) or (*,G) state contains a null oif 1091 list, the RP unicasts a Register-Stop message to the source 1092 of the Register message; in the latter case, the source- 1093 address field, within the Register-Stop message, is set to 1094 the wildcard value (all 0's). This message is not processed 1095 by intermediate routers, hence no (S,G) state is 1096 constructed between the RP and the source. 1098 3 If the Register message arrival rate warrants it and there 1099 is no existing (S,G) entry, the RP sets up a (S,G) 1100 forwarding entry with the outgoing interface list, 1101 excluding iif(S,G), copied from the (*,G) outgoing 1102 interface list, its SPT-bit is initialized to 0. If a (*,G) 1103 entry does not exist, but there exists a (*,*,RP) entry 1104 with the RP corresponding to G , the oif list for (S,G) is 1105 copied -excluding the iif- from that (*,*,RP) entry. 1107 A timer is set for the (S,G) entry and this timer is 1108 restarted by receipt of data packets for (S,G). The (S,G) 1109 entry causes the RP to send a Join/Prune message for the 1110 indicated group towards the source of the register message. 1112 If the (S,G) oif list becomes null, Join/Prune messages 1113 will not be sent towards the source, S. 1115 3.4 Multicast Data Packet Forwarding 1117 Processing a multicast data packet involves the following steps: 1119 1 Lookup forwarding state based on a longest match 1120 [*] 1122 of the source address, and an exact match of the 1123 destination address in the data packet and compare the RPF 1124 check on the source address in the packet header with the 1125 _________________________ 1126 [*] The longest match is performed in the following 1127 order: (1) (S,G), (2) (*,G). If neither is matched, 1128 then a lookup is performed on (*,*,RP) entries. 1130 iif specified in the forwarding entry. 1132 2 If the packet arrived on the interface found in the 1133 matching-entry's iif field, and the oif list is not 1134 null: 1136 1 Forward the packet to the oif list for that entry 1137 and restarted the entry's timer if the matching entry 1138 is (S,G) [*] 1140 2 If the entry is a (S,G) entry with a cleared SPT-bit, 1141 and a (*,G) or associated (*,*,RP) also exists whose 1142 incoming interface is different than that for (S,G), 1143 set the SPT-bit for the (S,G) entry and trigger an 1144 (S,G) RP-bit prune towards the RP. 1146 3 If the source of the packet is a directly-connected 1147 host and the router is the DR on a multi-access 1148 network, check the Register-bit associated with the 1149 (S,G) entry. If it is set, then the router 1150 encapsulates the data packet in a register message and 1151 sends it to the RP. 1153 This covers the common case of a packet arriving on the RPF 1154 interface to the source or RP and being forwarded to all 1155 joined branches. It also detects when packets arrive on the 1156 SP-tree, and triggers their pruning from the RP-tree. If it 1157 is the DR for the source, it sends data packets 1158 encapsulated in Registers to the RPs. 1160 3 If the packet matches to an entry but did not arrive on the 1161 interface found in the entry's iif field, check the 1162 SPT-bit of the entry. If the SPT-bit is set, drop the 1163 packet. If the SPT-bit is cleared, then lookup the (*,G), 1164 or (*,*,RP), entry for G. If the packet arrived on the 1165 _________________________ 1166 [*] Optionally, the (S,G) timer may be restarted by 1167 periodic checking of the matching packet count. 1169 iif found in (*,G), or the corresponding (*,*,RP), 1170 forward the packet to the oif list of the matching 1171 entry. This covers the case when a data packet matches on a 1172 (S,G) entry for which the SP-tree has not yet been 1173 completely established upstream. 1175 4 If the packet does not match to any entry, but the source 1176 of the data packet is a local, directly-connected host, and 1177 the router is the DR on a multi-access LAN and has RP-Set 1178 information, the DR uses the hash function to determine the 1179 RP associated with the destination group, G. The DR then 1180 checks the Register-bit associated with the local sender 1181 (if there is no such a Register-bit, a new register flag, 1182 associated with the local sender, is created and set), and 1183 encapsulates the data packet in a Register message and 1184 unicasts it to the RP. 1186 5 If the packet does not match to any entry, and it is not a 1187 local host or the router is not the DR, drop the packet. 1189 3.4.1 Data triggered switch to shortest path tree (SP-tree) 1191 Different criteria can be applied to trigger switching over from 1192 the RP-based shared tree to source-specific, shortest path 1193 trees. 1195 One proposed example is to do so based on data rate. For 1196 example, when a (*,G), or corresponding (*,*,RP), entry is 1197 created, a data rate counter may be initiated at the last-hop 1198 routers. The counter is incremented with every data packet 1199 received for directly connected members of an SM group, if the 1200 longest match is (*,G) or (*,*,RP). If and when the data rate 1201 for the group exceeds a certain configured threshold (t1), the 1202 router initiates `source-specific' data rate counters for the 1203 following data packets. Then, each counter for a source, is 1204 incremented when packets matching on (*,G), or (*,*,RP), are 1205 received from that source. If the data rate from the particular 1206 source exceeds a configured threshold (t2), a (S,G) entry is 1207 created and a Join/Prune message is sent towards the source. If 1208 the RPF interface for (S,G) is 1209 not the same as that for (*,G) -or (*,*,RP), then the SPT-bit 1210 is cleared in the (S,G) entry. 1212 Other configured rules may be enforced to cause or prevent 1213 establishment of (S,G) state. 1215 3.5 Assert 1217 Asserts are used to resolve which of the parallel routers 1218 connected to a multi-access LAN is responsible for forwarding 1219 packets onto the LAN. 1221 3.5.1 Sending Asserts 1223 The following Assert rules are provided when a multicast packet 1224 is received on an outgoing multi-access interface of an existing 1225 (S,G) entry: 1227 1 Do unicast routing table lookup on source IP address from 1228 data packet, and send assert on interface for source IP 1229 address in data packet; include metric preference of 1230 routing protocol and metric from routing table lookup. 1232 2 If route is not found, use metric preference of 0x7fffffff 1233 and metric 0xffffffff. 1235 3 When an assert is sent for a (*,G) entry, the first bit in 1236 the metric preference (the RP-bit) is set to 1, indicating 1237 the data packet is routed down the RP-tree. 1239 Asserts are rate-limited by the router. 1241 3.5.2 Receiving Asserts 1243 When an assert is received the router performs a longest match 1244 on the source and group address in the assert message. The 1245 router checks the first bit of the metric preference (RP-bit). 1246 If the RP-bit is set, the router does a match on (*,G), or 1247 (*,*,RP), entries, otherwise, the router matches (S,G) entries. 1248 If the matching entry is (*,*,RP), the router creates a (*,G) 1249 entry. 1251 If the interface that received the Assert message is in the 1252 oif list of the matched entry, then this assert should be 1253 processed by this router as follows: 1255 1 Compare the metric received in the Assert with the one the 1256 router would have advertised in an assert. The metric 1257 preference should be treated as the high-order part of an 1258 assert metric comparison. If the value in the assert is 1259 less than the router's value, delete the interface from the 1260 entry. If the value is the same, compare IP addresses, if 1261 the routers address is less than the assert sender, delete 1262 the interface. 1264 2 If the router has won the election and there are directly 1265 connected members on the multi-access LAN, the router keeps 1266 the interface in its outgoing interface list. It acts as 1267 the forwarder for the LAN. 1269 3 If the router won the election but there are no directly 1270 connected members on the multi-access LAN, the router 1271 schedules to delete the interface. The LAN might be a stub 1272 LAN with no members (and no downstream routers). If no 1273 subsequent Join/Prunes are received, the router deletes the 1274 interface from the outgoing interface list; otherwise it 1275 keeps the interface in its outgoing interface and acts as 1276 the forwarder for the LAN. 1278 The winning router should send out an assert message including 1279 its own metric to that outgoing interface. This will cause other 1280 routers on the LAN to prune that interface from their forwarding 1281 entries. 1283 Note that when an Assert is received, the router performs an 1284 exact match based on the source address, group address and the 1285 RP-bit of the metric preference in the assert message. This is 1286 not a longest match; only exact state will be matched. If there 1287 is no such state, then the router drops the Assert message. 1288 Otherwise, If the interface that received the Assert matches the 1289 incoming interface of the exactly matched entry, then the Assert 1290 message is processed as follows: 1292 1 Downstream routers will select the upstream router with the 1293 smallest metric as their RPF neighbor. If two metrics are 1294 the same, the highest IP address is chosen to break the 1295 tie. [*] 1297 2 If the downstream routers have downstream members, they 1298 must schedule a join to inform the upstream router that 1299 packets should be forwarded on the multi-access network. 1300 This will cause the upstream forwarder to cancel its 1301 scheduled deletion of the interface. 1303 _________________________ 1304 [*] This is important so that downstream routers send 1305 subsequent Joins/Prunes (in SM) to the correct neigh- 1306 bor. An Assert timer is initiated when changing the RPF 1307 neighbor to the Assert winner. When the timer expires 1308 the router resets its RPF neighbor according to its un- 1309 icast routing tables to capture failures of the Assert 1310 winner. 1312 3.6 Candidate-RP-Advertisements and RP-Set messages 1314 Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM 1315 messages unicast by those routers that are configured as 1316 Candidate-RPs (C-RPs). 1318 RP-Set messages are periodic PIM messages originated by the 1319 Bootstrap router (BSR) within a domain, and forwarded hop-by-hop 1320 to distribute the current RP-set to all routers in that domain. 1321 The RP-Set messages also support a simple mechanism by which the 1322 Candidate BSR (C-BSR) with the highest BSR-priority and IP 1323 address (referred to as the preferred BSR) is elected as the BSR 1324 for the domain [*] 1326 3.6.1 Sending Candidate-RP-Advertisements 1328 C-RPs periodically unicast C-RP-Advs to the BSR for that domain. 1329 The interval for sending these messages is subject to local 1330 configuration at the C-RP. A recommended default value is 60 1331 seconds. 1333 Candidate-RP-Advertisements carry group address and group mask 1334 fields. This enables the advertising router to limit the 1335 advertisement to certain prefixes or scopes of groups. The 1336 advertising router may enforce this scope acceptance when 1337 receiving Registers or Join/Prune messages. 1339 3.6.2 Receiving C-RP-Advs and Originating RP-Set 1341 Upon receiving a C-RP-Adv, a router does the following: 1343 1 If the router is not the elected BSR, it ignores the 1344 message, else 1346 2 The BSR adds the RP address to its local pool of candidate 1347 RPs, according to the associated group prefix(es) in the 1348 C-RP-Adv message [*] The BSR may override the prefix 1349 indicated in a C-RP-Adv. 1351 _________________________ 1352 [*] We recommend that each router configured as a C-RP 1353 also be configured as a C-BSR. 1354 [*] The BSR may apply a local policy to limit the 1355 number of Candidate RPs included in the RP-Set message. 1357 The BSR keeps an RP-timer per RP in its local RP-set. The RP- 1358 timer is initialized to three times the holdtime in the RP's C- 1359 RP-Adv. When the timer expires, the corresponding RP is removed 1360 from the RP-set. The RP-timer is restarted by the C-RP-Advs from 1361 the corresponding RP. 1363 The BSR also keeps an RP-Set timer to send RP-Set messages 1364 periodically. In particular, when the RP-Set timer expires, the 1365 BSR originates an RP-Set message on each of its interfaces. The 1366 message is sent with a TTL of 1 to the `ALL-PIM-ROUTERS' group. 1367 In steady state, the BSR originates RP-Set messages every 60 1368 seconds. At startup, the RP-Set timer is initialized to 180 1369 seconds, causing the first RP-Set message to be originated after 1370 180 seconds, when/if the timer expires. For timer details see 1371 Section 3.6.3. A DR unicasts an RP-Set message to new PIM 1372 neighbors starting up, after receiving their Query messages. 1373 (since after DR election the new neighbor may become the new 1374 DR.) 1376 The RP-Set message is subdivided into sets of group-prefix,RP- 1377 Count,RP-addresses. The format of the RP-Set message allows 1378 `semantic fragmentation', if the length of the original RP-Set 1379 message exceeds the packet maximum boundaries (see Section 4). 1380 However, we recommend against configuring a large number of 1381 routers as C-RPs, to reduce the semantic fragmentation required. 1383 3.6.3 Receiving and Forwarding RP-Set 1385 Each router keeps an RP-Set timer, initialized to 180 seconds at 1386 startup. 1388 When a router receives RP-Set message sent to `ALL-PIM-ROUTERS' 1389 group, it performs the following: 1391 1 If the message was not sent by the RPF neighbor towards the 1392 BSR address included, the message is dropped. Else 1394 2 If the included BSR is not preferred over, and not equal 1395 to, the currently active BSR: 1397 1 If the RP-Set timer is not yet expired, or if the 1398 receiving router is a C-BSR, then the RP-Set message 1399 is dropped. Else 1401 2 The RP-Set timer is expired and the receiving router 1402 is 1404 not a C-BSR, so the receiving router stores the RP-Set 1405 and BSR address found in the message. The RP-Set 1406 message is then forwarded out all PIM interfaces, 1407 excluding the one over which the message arrived, to 1408 `ALL-PIM-ROUTERS' group, with a TTL of 1. 1410 3 If the RP-Set message includes a BSR address that is 1411 preferred over, or equal to, the currently active BSR, the 1412 router resets its RP-Set timer to 180 seconds, and stores 1413 the BSR address and RP-Set information. The RP-Set message 1414 is then forwarded out all PIM interfaces, excluding the one 1415 over which the message arrived, to `ALL-PIM-ROUTERS' group, 1416 with a TTL of 1. 1418 If the receiving router has no current RP set information and 1419 the RP-set was unicast to it from a directly connected neighbor, 1420 the router stores the information as its new RP-set. This covers 1421 the startup condition when a newly booted router obtains the 1422 RP-Set and BSR address from its DR. 1424 When a router receives a new RP-Set it checks if each of the RPs 1425 referred to by existing state (i.e., by (*,G), (*,*,RP), or 1426 (S,G)RPbit entries) is in the new RP-Set. If an RP is not in the 1427 new RP-set, that RP is considered unreachable and the hash 1428 algorithm (see below) is re-performed for each group with 1429 locally active state that previously hashed to that RP. This 1430 will cause those groups to be distributed among the remaining 1431 RPs. When the new RP-Set contains a new RP, the value of the new 1432 RP is calculated for each group covered by that C-RP's Group- 1433 prefix. Any group for which the new RP's value is greater than 1434 the previously active RP's value is switched over to the new RP. 1436 3.7 Hash Function 1438 The hash function is used by all routers within a domain, to map 1439 a group to one of the C-RPs from the RP-Set. For a particular 1440 group, G, the hash function uses only those C-RPs whose Group- 1441 prefix covers G. The algorithm takes as input the group address, 1442 and the addresses of the Candidate RPs, and gives as output one 1443 RP address to be used. 1445 The protocol requires that all routers hash to the same RP 1446 within a domain (except for transients). The following hash 1447 function must be used in each router: 1449 1 For each candidate RP address Ci in the Candidate-RP- 1450 Set, whose Group-prefix covers G, compute a value: 1451 Value(G,M,Ci) = 1452 1103515245 ((1103515245 (G&M)+12345) XOR Ci)+ 12345 mod 2^31 1453 where M is a hash-mask included in RP-Set messages. 1454 This hash-mask allows a small number of 1455 consecutive groups (e.g., 4) to always hash to the same RP. 1456 For instance, hierarchically-encoded data can be sent on 1457 consecutive group addresses to get the same delay and 1458 fate-sharing characteristics. 1460 In standard C, this corresponds to: 1462 srand(G & M); 1463 srand(rand() ^ Ci); 1464 value = rand(); 1466 2 The candidate with the highest resulting value is then 1467 chosen as the RP for that group, and its identity and hash 1468 value are stored with the entry created. 1470 Ties between C-RPs having the same hash value, are broken 1471 in advantage of the highest address. 1473 The hash function algorithm is invoked by a DR, upon reception 1474 of a packet, or IGMP Host-Membership-Report, for a group, for 1475 which the DR has no entry. It is invoked by any router that has 1476 (*,*,RP) state when a packet is received for which there is no 1477 corresponding (S,G) or (*,G) entry. Furthermore, the hash 1478 function is invoked by all routers upon receiving a Join/Prune 1479 message with WC-bit set. 1481 3.8 Processing Timer Events 1483 { Editors Note: Timers are also discussed individually in the 1484 sections that pertain to the protocol messages that they 1485 trigger/affect. Until we finalize this section, if discrepencies 1486 exist, then assume that the individual sections are 1487 authoritative over this table.} 1489 In this subsection, we enumerate all timers that have been 1490 discussed or implied. Since some critical timer events are not 1491 associated with the receipt or sending of messages, they are not 1492 fully covered by earlier subsections. 1494 In many cases, the values for timers come from Holdtime fields 1495 in PIM control messages, in which case the default values used 1496 in these Holdtime fields are shown in the tables below. 1497 Otherwise, the default value used when setting the timer is 1498 shown. In general, the default timeout value for state 1499 information is three times the refresh period. For example, 1500 Queries refresh Neighbor state and the default Query-timer 1501 period is 30 seconds, so a default Neighbor-timer duration of 90 1502 seconds is included in the Holdtime field of the Queries. 1504 In this version of the spec we suggest particular numerical 1505 timer settings. A future version of the specification will 1506 specify a mechanism for timers to be set as a function of the 1507 outgoing link bandwidth. 1509 bsubsection*Timers related to tree maintenance 1511 Each (S,G), (*,G), and (*,*,RP) entry has multiple timers 1512 associated with it: one for each interface in the outgoing 1513 interface list, one for the multicast routing entry itself, and 1514 one for the Joiner-bit. Each (S,G) and (*,G) entry also has an 1515 Assert timer and an Assert-rate-limit timer. In addition, DR's 1516 have a Register-bit-timer for each (S,G) entry and every router 1517 has a single Join/Prune timer. 1519 Because some of the outgoing interfaces in an (S,G) entry are 1520 copied from the (*,G) outgoing interface list, they may not have 1521 explicit (S,G) join messages from some of the downstream routers 1522 (i.e., where members are joining to the (*,G) tree only). Thus, 1523 when a timer is reset for an outgoing interface listed in a 1524 (*,G) entry, the timers are reset for that interface in each 1525 existing (S,G) entry whose oif list contains that interface [*] 1526 _________________________ 1527 [*] If there are sources in the prune list of the (*,G) 1528 join, then the timers for the arriving interface will 1529 first be reset for those sources, and then this inter- 1530 face will be deleted from these same entries; producing 1531 a correct result, even though the updating of the ti- 1532 mers was unnecessary. An implementation could optimize 1533 The same rule applies to (*,G) and (S,G) entries when resetting 1534 an oif timer on a (*,*,RP) entry. 1536 _________________________ 1537 this by checking the prune list before processing the 1538 join list. 1540 Timer DefVal Notes 1542 Joiner-bit 90 Started : When Joiner bit is cleared 1543 per route entry Reset by: Receiving Join from higher-IP neighbor on iif 1544 Action : Set Joiner bit 1546 Join/Prune 60 Started : When booting 1547 Reset by: Nothing 1548 Action : Send Join/Prune to each RPF neighbor, restart timer 1550 oif 180 Started : When adding oif to oiflist 1551 per (*,*,RP) oif Restarted by: Receiving (*,*,RP) Join on that iface 1552 Action : Remove oif from oiflist 1554 oif 180 Started : When adding oif to oiflist 1555 per (*,G) oif Restarted by: Receiving (*,G) Join or IGMP 1556 Host-Membership-Report for G on that iface, or 1557 restartedting oif timer in (*,*,RP). 1558 Action : Remove oif from oiflist 1560 oif 180 Started : When adding oif to oiflist 1561 per (S,G) oif Restarted by: Receiving (S,G) Join on that 1562 iface, or restartedting oif timer in (*,G) or 1563 (*,*,RP). 1564 Action : Remove oif from oiflist 1566 (*,*,RP) entry 180 Started : When entry is created 1567 per (*,*,RP) Restarted by: Restartedting timer on any oif 1568 Action : Delete entry 1570 (*,G) entry 180 Started : When entry is created 1571 per (*,G) Restarted by: Receiving (*,G) prune, 1572 restarting timer on any oif, or receiving an 1573 Assert with RP-bit set. 1574 Action : Delete entry and any associated 1575 (S,G)RP-bit entries 1577 (S,G) entry 180 Started : When entry is created 1578 aka S-timer Restarted by: Forwarding data packet, 1579 per (S,G) receiving Register, receiving (S,G) RP-bit 1580 prune, restarting timer on any oif, 1581 or receiving an Assert without RP-bit set. 1582 Action : Delete entry 1584 Register-bit 60 Started : When Register bit is cleared by 1585 per (S,G) receiving a Register-Stop 1586 Restarted by: Receiving Register-Stop 1587 Action : Set Register bit 1589 Assert 180 Started : Receiving an Assert where the 1590 per (S,G) upstream RPF neighbor is not your unicast RPF 1591 and (*,G) neighbor. 1592 Restarted by: Receiving an Assert where the 1593 upstream RPF neighbor is not your unicast 1594 RPF neighbor. 1595 Action : Change RPF neighbor to unicast RPF neighbor 1597 Assert-Rate-limit 5 Started : When an Assert is sent 1598 per (S,G) Restarted by: Nothing 1599 and (*,G) Action : Allow asserts to be triggered by 1600 data packets 1602 *Timers relating to neighbor discovery 1604 Timer DefVal Notes 1606 Query 30 Started : When booting 1607 Restarted by: Nothing 1608 Action : Send Query on all ifaces, restart timer 1610 Neighbor 90 Started : When receive first Query from neighbor 1611 per neighbor Restarted by: When receive subsequent Queries 1612 Action : Delete neighbor entry 1614 *Timers relating to RP information 1615 Timer DefVal Notes 1617 C-RP-Adv 60 Started : When booting if you're a Cand-RP 1618 Restarted by: Nothing 1619 Action : Send C-RP-Adv, restart C-RP-Adv timer 1621 RP 180 Started : When adding an RP to the RP-Set if 1622 per RP you are BSR 1623 Restarted by: Receiving C-RP-Adv 1624 Action : Remove RP from RP-Set 1626 RP-Set 180/60 Started : Set to 180 when booting if 1627 you're a C-BSR 1628 Restarted by: Restarted to 180 when receive 1629 RP-Set from preferred router if you're a C-BSR 1630 Action : Send RP-Set and restart timer to 60 secs 1632 3.9 Summary of flags used 1634 Following is a summary of all the flags used in our scheme. 1636 Bit Used in Definition 1638 Border Register Register is coming from a PIM border router. 1639 Joiner Route entry Periodic Join/Prunes should be sent for this entry. 1640 Register (S,G) entry Encapsulate packets from directly connected 1641 sources in Register messages unicast to the RP 1642 for that group. 1643 RP Route entry Entry represents state on the RP-tree. 1644 RP Join/Prune Join is associated with the shared tree and therefore 1645 the Join/Prune message is propagated along the RP-tree. 1646 RP Assert The data packet was routed down the shared tree; thus, 1647 the path indicated corresponds to the RP tree. 1648 SPT (S,G) entry Packets have arrived on the iif towards S, 1649 and the iif is different from the (*,G) iif. 1650 WC Join Included address is an RP and the receiver expects to 1651 receive packets from all sources via this (shared tree) 1652 path. Thus, the Join/Prune applies to a (*,G) entry. 1653 WC Route entry Wildcard entry; if there is no more specific match for 1654 a particular source, packets will be forwarded according 1655 to this entry. 1657 3.10 Security 1659 { Editors Note: this section is to be completed.} 1661 All PIM control messages may use [5] to address security 1662 concerns. 1664 4 Packet Formats 1666 This section describes the details of the packet formats for PIM 1667 control messages. 1669 All PIM control messages have protocol number 103. 1671 Basically, PIM messages are either unicast (e.g. Registers and 1672 Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' 1673 group `224.0.0.13' (e.g. Join/Prune, Asserts, etc.). 1675 0 1 2 3 1676 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 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 |PIM Ver| Type | Addr length | Checksum | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 PIM Ver 1682 PIM Version number is 2. 1684 Type Types for specific PIM messages. PIM Types are: 1686 0 = Query 1687 1 = Register 1688 2 = Register-Stop 1689 3 = Join/Prune 1690 4 = RP-Set 1691 5 = Assert 1692 6 = Graft (used in PIM-DM only) 1693 7 = Graft-Ack (used in PIM-DM only) 1694 8 = Candidate-RP-Advertisement 1696 Addr length 1697 Address length in bytes. Throughout this section this 1698 would indicate the number of bytes in the Address field of 1699 an address, including unicast and group addresses. 1701 Checksum 1702 The checksum is the 16-bit one's complement of the one's 1703 complement sum of the entire PIM message, (excluding the 1704 data portion in the Register message). For computing the 1705 checksum, the checksum field is zeroed. 1707 4.1 Encoded Source and Group Address formats 1709 1 Unicast address: Only the address is included. The length 1710 of the unicast address in bytes is specified in the `Addr 1711 length' field in the header. 1713 2 Encoded-Group-Address: Takes the following format: 1715 0 1 2 3 1716 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 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Reserved | Mask Len | Group multicast Address ... | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | ...Group multicast Address ...| 1721 +-+-+-+-+-+-+-+-+-+-+~+~+~+~+~+~+ 1723 Reserved 1724 Transmitted as zero. Ignored upon receipt. 1726 Mask Len 1727 The Mask length is 8 bits. The value is the number of 1728 contiguous bits left justified used as a mask which 1729 describes the address. It is less than or equal to 1730 Addr length * 8. If the message is sent for a single 1731 group then the Mask length should equal Addr length * 1732 8 (i.e. 32 for IPv4 and 128 for IPv6). 1734 Group multicast Address 1735 contains the group address, and has number of bytes 1736 equal to that specified in the Addr length field. 1738 3 Encoded-Source-Address: Takes the following format: 1740 0 1 2 3 1741 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | Rsrvd |S|W|R| Mask Len | Source Address ... | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | ... Source Address | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+-+ 1748 Reserved 1749 Transmitted as zero, ignored on receipt. 1751 S,W,R See Section7 ef{Join_format} for details. 1753 Mask Length 1754 Mask length is 8 bits. The value is the number of 1755 contiguous bits left justified used as a mask which 1756 describes the address. The mask length must be less 1757 than or equal to Addr Length * 8. If the message is 1758 sent for a single source then the Mask length should 1759 equal Addr length * 8. In version 2 of PIM, it is 1760 strongly recommended that this field be set to 32 for 1761 IPv4. 1763 Source Address 1764 The address length is indicated from the Addr length 1765 field at the beginning of the header. For IPv4, the 1766 address length is 4 octets. 1768 4.2 Query Message 1770 It is sent periodically by routers on all interfaces. 1772 0 1 2 3 1773 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 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 |PIM Ver| Type | Addr length | Checksum | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | Reserved | Holdtime | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 PIM Version, Type, Addr length, Checksum 1781 Described above. 1783 Reserved 1784 Transmitted as zero, ignored on receipt. 1786 Holdtime 1787 The amount of time a receiver should keep the neighbor 1788 reachable, in seconds. 1790 4.3 Register Message 1792 It is sent by the Designated Router (DR) to the RP when a 1793 multicast packet needs to be transmitted on the RP-tree. Source 1794 IP address is set to the address of the DR, destination IP 1795 address is to the RP's address. 1797 0 1 2 3 1798 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 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 |PIM Ver| Type | Addr length | Checksum | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 |B| Reserved | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | | 1805 Multicast data packet 1806 | | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 PIM Version, Type, Addr length, Checksum 1810 Described above. { Note that the checksum for Registers 1811 is done only on the PIM header, excluding the data packet 1812 portion.} 1814 B The Border bit. Set to zero by all DRs. Set to `1' by the 1815 PIM Multicast Border Routers, when registering for external 1816 sources. 1818 Multicast data packet 1819 The original packet sent by the source. 1821 4.4 Register-Stop Message 1823 A Register-Stop is unicast from the RP to the sender of the 1824 Register message. Source IP address is the address to which the 1825 register was addressed. Destination IP address is the source 1826 address of the register message. 1828 0 1 2 3 1829 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 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 |PIM Ver| Type | Addr length | Checksum | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | Encoded-Group Address | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | Unicast-Source Address | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 PIM Version, Type, Addr length, Checksum 1839 Described above. 1841 Encoded-Group Address 1842 Format described above. Note that for Register-Stops the 1843 Mask Len field should contain Addr length * 8 (32 for 1844 IPv4), if the message is sent for a single group. 1846 Unicast-Source Address 1847 IP host address of source from multicast data packet in 1848 register. The length of this field in bytes is specified in 1849 the Addr length field. A special wild card value (0.0.0.0), 1850 can be used to indicate any source. 1852 4.5 Join/Prune Message 1854 It is sent by routers towards upstream sources and RPs. A join 1855 creates forwarding state and a prune destroys forwarding state. 1856 Joins are sent to build shared trees (RP trees) or source trees 1857 (SPT). Prunes are sent to prune source trees when members leave 1858 groups as well as sources that do not use the shared tree. 1860 0 1 2 3 1861 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 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 |PIM Ver| Type | Addr length | Checksum | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Unicast-Upstream Neighbor Address | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | Reserved | Num groups | Holdtime | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | Encoded-Multicast Group Address-1 | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Number of Joined Sources | Number of Pruned Sources | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | Encoded-Joined Source Address-1 | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | . | 1876 | . | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 | Encoded-Joined Source Address-n | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Encoded-Pruned Source Address-1 | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | . | 1883 | . | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Encoded-Pruned Source Address-n | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | . | 1888 | . | 1889 | . | 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | Encoded-Multicast Group Address-n | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Number of Joined Sources | Number of Pruned Sources | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | Encoded-Joined Source Address-1 | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 | . | 1898 | . | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | Encoded-Joined Source Address-n | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | Encoded-Pruned Source Address-1 | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | . | 1905 | . | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Encoded-Pruned Source Address-n | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 PIM Version, Type, Addr length, Checksum 1911 Described above. 1913 Upstream Neighbor Address 1914 The IP address of the RPF or upstream neighbor. 1916 Reserved 1917 Transmitted as zero, ignored on receipt. 1919 Holdtime 1920 The amount of time a receiver should keep the Join/Prune 1921 state alive, in seconds. 1923 Number of Groups 1924 The number of multicast group sets contained in the 1925 message. 1927 Encoded-Multicast group address 1928 For format description see Section 1929 4.1. A wild card group in the (*,*,RP) join is represented 1930 by a 224.0.0.0 in the group address field and `4' in the 1931 mask length field. A (*,*,RP) join also has the WC-bit and 1932 the RP-bit set. 1934 Number of Joined Sources 1935 Number of join source addresses listed for a given group. 1937 Join Source Address-1 .. n 1938 This list contains the sources that the sending router 1939 will forward multicast datagrams for if received on the 1940 interface this message is sent on. 1942 See format section 4.1. The fields explanation for the 1943 Encoded-Source-Address format follows: 1945 Reserved 1946 Described above. 1948 S The Sparse bit is a 1 bit value, set to 1 for PIM-SM. 1949 It is used for PIM v.1 compatability. 1951 W The WC bit is a 1 bit value. If 1, the join or prune 1952 applies to the (*,G) or (*,*,RP) entry. If 0, the join 1953 or prune applies to the (S,G) entry where S is Source 1954 Address. Joins and prunes sent towards the RP should 1955 have this bit set. 1957 R The RP bit is a 1 bit value. If 1, the information 1958 about (S,G) is sent towards the RP. If 0, the 1959 information should be sent about (S,G) toward S, where 1960 S is Source Address. 1962 Mask Length, Source Address 1963 Described above. 1965 Represented in the form of 1966 < WCbit >< RPbit >< Mask length>< Source address>: 1968 A source address could be a host IP address : 1970 < 0 >< 0 >< 32 >< 192.1.1.17 > 1972 A source address could be the RP's IP address : 1974 < 1 >< 1 >< 32 >< 131.108.13.111 > 1976 A source address could be a subnet address to prune from 1977 the RP-tree : 1979 < 0 >< 1 >< 28 >< 192.1.1.16 > 1981 A source address could be a general aggregate : 1983 < 0 >< 0 >< 16 >< 192.1.0.0 > 1985 Number of Pruned Sources 1986 Number of prune source addresses listed for a group. 1988 Prune Source Address-1 .. n 1989 This list contains the sources that the sending router 1990 does not want to forward multicast datagrams for when 1991 received on the interface this message is sent on [*] 1992 _________________________ 1993 [*] If the Join/Prune message boundary exceeds the max- 1994 4.6 RP-Set 1996 The RP-Set messages are multicast to `ALL-PIM-ROUTERS' group, 1997 out all interfaces having PIM neighbors (excluding the one over 1998 which the message was received). RP-Set messages are sent with 1999 TTL value of 1. RP-Set messages originate at the BSR, and are 2000 forwarded by intermediate routers. 2002 RP-Set message is divided up into `semantic fragments', if the 2003 original message exceeds the maximum packet size boundaries. 2005 The semantics of a single `fragment' is given below: 2007 _________________________ 2008 imum packet size, then the join and prune lists for the 2009 same group must be included in the same packet. 2011 0 1 2 3 2012 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 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 |PIM Ver| Type | Addr length | Checksum | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | Fragment Tag | Hash Mask len | BSR-priority | 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | Unicast-BSR-Address | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | Encoded-Group Address-1 | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | RP-Count-1 | Frag RP-Cnt-1 | Reserved | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | Unicast-RP-Address-1 | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | . | 2027 | . | 2028 | . | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | Unicast-RP-Address-m | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | . | 2033 | . | 2034 | . | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Encoded-Group Address-n | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | RP-Count-m | Frag RP-Cnt-m | Reserved | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | Unicast-RP-Address-1 | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | . | 2043 | . | 2044 | . | 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 | Unicast-RP-Address-m | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 PIM Version, Type, Addr length, Checksum 2050 Described above. 2052 Fragment Tag 2053 A randomly generated number, acts to distinguish the 2054 fragments belonging to different RP-Set messages; fragments 2055 belonging to same RP-Set message carry the same `Fragment 2056 Tag'. 2058 Hash Mask len 2059 The length (in bits) of the mask to use in the hash 2060 function. For IPv4 we recommend a value of 30. For IPv6 we 2061 recommend a value of 126. 2063 BSR-priority 2064 Contains the BSR priority value of the included BSR. This 2065 field is considered as a high order byte when comparing BSR 2066 addresses. 2068 Unicast-BSR-Address 2069 The IP address of the bootstrap router for the domain. The 2070 length of this field in bytes is specified in Addr length. 2072 Encoded-Group Address-1..n 2073 The group prefix (address and mask) with which the 2074 Candidate RPs are associated. Format previously described. 2076 RP-Count-1..n 2077 The number of Candidate RP addresses included in the whole 2078 RP-Set message for the corresponding group prefix [*] 2080 Frag RP-Cnt-1..m 2081 The number of Candidate RP addresses included in this 2082 fragment of the RP-Set message, for the corresponding group 2083 prefix. The `Frag RP-Cnt' field facilitates parsing of the 2084 RP-Set for a given group prefix, when carried over more 2085 than one fragment. 2087 Unicast-RP-address-1..m 2088 The address of the Candidate RPs, for the corresponding 2089 _________________________ 2090 [*] A router does not replace its old RP-Set for a 2091 given group prefix until/unless it receives `RP-Count' 2092 addresses for that prefix; the addresses could be car- 2093 ried over several fragments. If only part of the RP-Set 2094 for a given group prefix was received, the router dis- 2095 cards it, without updating that specific group prefix's 2096 RP-Set. 2098 group prefix. The length of this field in bytes is 2099 specified in Addr length. 2101 4.7 Assert Message 2103 The Assert message is sent when a multicast data packet is 2104 received on an outgoing interface corresponding to the (S,G) or 2105 (*,G) associated with the source. 2107 0 1 2 3 2108 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 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 |PIM Ver| Type | Addr length | Checksum | 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | Encoded-Group Address | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | Unicast-Source Address | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 |R| Metric Preference | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | Metric | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 PIM Version, Type, Addr length, Checksum 2122 Described above. 2124 Encoded-Group Address 2125 The group address to which the data packet was addressed, 2126 and which triggered the Assert. Format previously 2127 described. 2129 Unicast-Source Address 2130 Source IP address from IP multicast datagram that 2131 triggered the Assert packet to be sent. The length of this 2132 field in bytes is specified in Addr length. 2134 R RP bit is a 1 bit value. If the IP multicast datagram that 2135 triggered the Assert packet is routed down the RP tree, 2136 then the RP bit is 1; if the IP multicast datagram is 2137 routed down the SPT, it is 0. 2139 Metric Preference 2140 Preference value assigned to the unicast routing protocol 2141 that provided the route to Host address. 2143 Metric The unicast routing table metric. The metric is in units 2144 applicable to the unicast routing protocol used. 2146 4.8 Graft Message 2148 Used in dense-mode. Refer to PIM dense mode specification. 2150 4.9 Graft-Ack Message 2152 Used in dense-mode. Refer to PIM dense mode specification. 2154 4.10 Candidate-RP-Advertisement 2156 Candidate-RP-Advertisements are periodically unicast from the 2157 C-RPs to the BSR. 2159 0 1 2 3 2160 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 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 |PIM Ver| Type | Addr length | Checksum | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | Prefix-Cnt | Reserved | Holdtime | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | Unicast-RP-Address | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Encoded-Group Address-1 | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | . | 2171 | . | 2172 | . | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Encoded-Group Address-n | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 PIM Version, Type, Addr length, Checksum 2178 Described above. 2180 Prefix-Cnt 2181 The number of encoded group addresses included in the 2182 message; indicating the group prefixes for which the C-RP 2183 is advertising. A Prefix-Cnt of `0' implies a prefix of 2184 224.0.0.0 with mask length of 4; i.e. all multicast groups. 2185 If the C-RP is not configured with Group-prefix 2186 information, the C-RP puts a default value of `0' in this 2187 field. 2189 Holdtime 2190 The amount of time the advertisement is valid. This field 2191 allows advertisements to be aged out. 2193 Unicast-RP-Address 2194 The address of the interface to advertise as a Candidate 2195 RP. The length of this field in bytes is specified in Addr 2196 length. 2198 Encoded-Group Address-1..n 2199 The group prefixes for which the C-RP is advertising. 2200 Format previously described. 2202 5 Appendix I: Changes and Updates to the Spec 2204 This appendix populates the major changes in the specification 2205 document as compared to `draft-ietf-idmr-pim-spec-01.ps,txt'. 2207 5.1 Major Changes 2209 List of changes since March '96 IETF: 2211 1. (*,*,RP) Joins state and data forwarding check; replaces (*,G- 2212 Prefix) Joins state for interoperability. (*,G) negative cache 2213 introduced for the (*,*,RP) state supporting mechanisms. 2215 2. Semantic fragmentation for the RP-Set message. 2217 3. Appendix II on interoperability details with DVMRP in 2218 preparation. 2220 List of changes incurred since version 1 of the spec: 2222 1. Proposal and refinement of bootstrap router (BSR) election 2223 mechanisms 2225 2. Introduction of hash functions for Group to RP mapping 2227 3. New RP-liveness indication mechanisms based upon the the 2228 Bootstrap Router (BSR) and the RP-Set messages. 2230 4. Removal of reachability messages, RP reports and multiple RPs 2231 per group. 2233 5.2 Packet Format Changes 2235 Packet Format incurred updates to accommodate different address 2236 lengths, and address aggregation. 2238 1 The `Addr length' field was added to the PIM fixed header 2239 to specify the address length in bytes of the underlying 2240 protocol, see section 4. 2242 2 The Encoded source and group address formats were 2243 introduced, with the use of a `Mask length' field to allow 2244 aggregation, section 4.1. 2246 3 Packet formats are no longer IGMP messages; rather PIM 2247 messages. 2249 PIM message types and formats were also modified: 2251 [{ Note: most changes were made to the May 95 version, unless 2252 otherwise specified}]. 2254 1 Obsolete messages: 2256 a. Register-Ack [Feb. 96] 2258 b. Poll and Poll Response [Feb. 96] 2260 c. RP-Reachability [Feb. 96] 2262 d. RPlist-Mapping [Feb. 96] 2264 2 New messages: 2266 a. Candidate-RP-Advertisement [change made in October 95] 2268 b. RP-Set [Feb. 96] 2270 3 Modified messages: 2272 a. Join/Prune [Feb. 96] 2274 b. Register [Feb. 96] 2276 c. Register-Stop [Feb. 96] 2277 6 Appendix II: Interoperability with Dense Mode Protocols 2279 { Editors Note: This section is to be completed.} 2280 7 Acknowledgments 2282 Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul 2283 Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen 2284 Ostrowski, and Lixia Zhang provided detailed comments on 2285 previous drafts. The authors of [6] and membership of the IDMR 2286 WG provided many of the motivating ideas for this work and 2287 useful feedback on design details. 2289 This work was supported by the National Science Foundation, 2290 ARPA, cisco Systems and Sun Microsystems. 2292 References 2294 1. S.Deering, D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, 2295 P.Sharma, and A.Helmy. Protocol independent multicast (pim) : 2296 Motivation and architecture. 2297 Internet Draft, May 1995. 2299 2. S.Deering, D.Estrin, D.Farinacci, V.Jacobson, C.Liu, and L.Wei. 2300 The pim architecture for wide-area multicast routing. 2301 ACM Transactions on Networks, April 1996. 2303 3. D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and 2304 A.Helmy. Protocol independent multicast-dense mode (pim-dm) : 2305 Protocol specification. Internet Draft, November 1995. 2307 4. S.Deering. Host extensions for ip multicasting, aug 1989. 2308 RFC1112. 2310 5. R.Atkinson. Security architecture for the internet protocol, 2311 August 1995. RFC-1825. 2313 6. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. 2314 In Proceedings of the ACM SIGCOMM, San Francisco, 1993. 2316 Expire in six months