idnits 2.17.1 draft-ietf-pim-v2-sm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 13 longer pages, the longest (page 57) being 146 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 65 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 25 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 25 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 5 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 654: '... Priority Option SHOULD be included in...' RFC 2119 keyword, line 661: '...oing this option SHOULD always include...' RFC 2119 keyword, line 665: '...r (GenID) Option SHOULD also be includ...' RFC 2119 keyword, line 668: '...or, that neighbor SHOULD be treated as...' RFC 2119 keyword, line 851: '...in/Prune message SHOULD include (S,G)R...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 222 has weird spacing: '...ee) to short...' == Line 399 has weird spacing: '...se mode proto...' == Line 778 has weird spacing: '...eighbor towar...' == Line 779 has weird spacing: '...it flag set ...' == Line 919 has weird spacing: '... When a ro...' == (10 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1999) is 8927 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 2764 looks like a reference -- Missing reference section? '2' on line 2765 looks like a reference -- Missing reference section? '4' on line 2767 looks like a reference -- Missing reference section? '5' on line 122 looks like a reference -- Missing reference section? '6' on line 630 looks like a reference -- Missing reference section? 'Hello-Period' on line 1910 looks like a reference -- Missing reference section? 'Hello-Holdtime' on line 1907 looks like a reference -- Missing reference section? 'Register-Suppression-Timeout' on line 1879 looks like a reference -- Missing reference section? 'Bootstrap-Timeout' on line 2871 looks like a reference -- Missing reference section? '7' on line 1625 looks like a reference -- Missing reference section? 'Data-Timeout' on line 1876 looks like a reference -- Missing reference section? 'Assert-Timeout' on line 1895 looks like a reference -- Missing reference section? 'Probe-Time' on line 1888 looks like a reference -- Missing reference section? 'Random-Delay-Join-Timeout' on line 1899 looks like a reference -- Missing reference section? 'Hello-Timer' on line 1778 looks like a reference -- Missing reference section? 'C-RP-Adv-Period' on line 1917 looks like a reference -- Missing reference section? 'RP-Holdtime' on line 1915 looks like a reference -- Missing reference section? 'Bootstrap-Timer' on line 1815 looks like a reference -- Missing reference section? 'Bootstrap-Period' on line 2822 looks like a reference -- Missing reference section? '9' on line 2646 looks like a reference -- Missing reference section? '8' on line 2654 looks like a reference -- Missing reference section? '3' on line 2766 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L Wei 2 Internet Draft Editor, Siara 3 D. Estrin 4 USC 5 D. Farinacci 6 Procket 7 A. Helmy 8 USC 9 D. Thaler 10 Microsoft 11 S. Deering 12 Cisco 13 M. Handley 14 ACIRI 15 V. Jacobson 16 Cisco 17 C. Liu 18 Fujitsu 19 P. Sharma 20 Expires May 2, 2000 HPL 21 November 1999 22 draft-ietf-pim-v2-sm-01.txt 24 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 25 Specification 27 Status of this Memo 29 This document is an Internet-Draft and is in full conformance 30 with all provisions of Section 10 of RFC2026. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other 39 documents at any time. It is inappropriate to use Internet- 40 Drafts as reference material or to cite them other than as 41 "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Copyright Notice 51 Copyright (C) The Internet Society (1999). All Rights Reserved. 53 1 Introduction 55 This document describes a protocol for efficiently routing to 56 multicast groups that may span wide-area (and inter-domain) 57 internets. We refer to the approach as Protocol Independent 58 Multicast--Sparse Mode (PIM-SM) because it is not dependent on any 59 particular unicast routing protocol, and because it is designed to 60 support sparse groups as defined in [1][2]. This document describes 61 the protocol details. For the motivation behind the design and a 62 description of the architecture, see [1][2]. Section 2 summarizes 63 PIM-SM operation. It describes the protocol from a network 64 perspective, in particular, how the participating routers interact to 65 create and maintain the multicast distribution tree. Section 3 66 describes PIM-SM operations from the perspective of a single router 67 implementing the protocol; this section constitutes the main body of 68 the protocol specification. It is organized according to PIM-SM 69 message type; for each message type we describe its contents, its 70 generation, and its processing. 72 Sections 3.8 and 3.9 summarize the timers and flags referred to 73 throughout this document. Section 4 provides packet format details. 75 2 PIM-SM Protocol Overview 77 In this section we provide an overview of the architectural 78 components of PIM-SM. 80 A router receives explicit Join/Prune messages from those neighboring 81 routers that have downstream group members. The router then forwards 82 data packets addressed to a multicast group, G, only onto those 83 interfaces on which explicit joins have been received. Note that all 84 routers mentioned in this document are assumed to be PIM-SM capable, 85 unless otherwise specified. 87 A Designated Router (DR) sends periodic Join/Prune messages toward a 88 group-specific Rendezvous Point (RP) for each group for which it has 89 active members. Each router along the path toward the RP builds a 90 wildcard (any-source) state for the group and sends Join/Prune 91 messages on toward the RP. We use the term route entry to refer to 92 the state maintained in a router to represent the distribution tree. 93 A route entry may include such fields as the source address, the 94 group address, the incoming interface from which packets are 95 accepted, the list of outgoing interfaces to which packets are sent, 96 timers, flag bits, etc. The wildcard route entry's incoming interface 97 points toward the RP; the outgoing interfaces point to the 98 neighboring downstream routers that have sent Join/Prune messages 99 toward the RP. This state creates a shared, RP-centered, distribution 100 tree that reaches all group members. When a data source first sends 101 to a group, its DR unicasts Register messages to the RP with the 102 source's data packets encapsulated within. If the data rate is high, 103 the RP can send source-specific Join/Prune messages back towards the 104 source and the source's data packets will follow the resulting 105 forwarding state and travel unencapsulated to the RP. Whether they 106 arrive encapsulated or natively, the RP forwards the source's 107 decapsulated data packets down the RP-centered distribution tree 108 toward group members. If the data rate warrants it, routers with 109 local receivers can join a source-specific, shortest path, 110 distribution tree, and prune this source's packets off of the shared 111 RP-centered tree. For low data rate sources, neither the RP, nor 112 last-hop routers need join a source-specific shortest path tree and 113 data packets can be delivered via the shared, RP-tree. 115 The following subsections describe SM operation in more detail, in 116 particular, the control messages, and the actions they trigger. 118 2.1 Local hosts joining a group 120 In order to join a multicast group, G, a host conveys its membership 121 information through the Internet Group Management Protocol (IGMP), as 122 specified in [4][5], (see figure 1). From this point on we refer to 123 such a host as a receiver, R, (or member) of the group G. 125 Note that all figures used in this section are for illustration and 126 are not intended to be complete. For complete and detailed protocol 127 action see Section 3. 129 | ----- ----- ------- 130 Host -+- | A |----------------| B |-----------------| C | RP 131 | ----- ----- ------- 132 -----> -----------> -----------> 133 IGMP report (*,G) join (*,G) join 135 Fig. 1 Example: how a receiver joins, and sets up shared tree 137 When a DR (e.g., router A in figure 1) gets a membership indication 138 from IGMP for a new group, G, the DR looks up the associated RP. The 139 DR creates a wildcard multicast route entry for the group, referred 140 to here as a (*,G) entry; if there is no more specific match for a 141 particular source, the packet will be forwarded according to this 142 entry. 144 The RP address is included in a special field in the route entry and 145 is included in periodic upstream Join/Prune messages. The outgoing 146 interface is set to that included in the IGMP membership indication 147 for the new member. The incoming interface is set to the interface 148 used to send unicast packets to the RP. 150 When there are no longer directly connected members for the group, 151 IGMP notifies the DR. If the DR has neither local members nor 152 downstream receivers, the (*,G) state is deleted. 154 2.2 Establishing the RP-rooted shared tree 156 Triggered by the (*,G) state, the DR creates a Join/Prune message 157 with the RP address in its join list and the the wildcard bit (WC- 158 bit) and RP-tree bit (RPT-bit) set to 1. The WC-bit indicates that 159 any source may match and be forwarded according to this entry if 160 there is no longer match; the RPT-bit indicates that this join is 161 being sent up the shared, RP-tree. The prune list is left empty. When 162 the RPT-bit is set to 1 it indicates that the join is associated with 163 the shared RP-tree and therefore the Join/Prune message is propagated 164 along the RP-tree. When the WC-bit is set to 1 it indicates that the 165 address is an RP and the downstream receivers expect to receive 166 packets from all sources via this (shared tree) path. The term RPT- 167 bit is used to refer to both the RPT-bit flags associated with route 168 entries, and the RPT-bit included in each encoded address in a 169 Join/Prune message. 171 Each upstream router creates or updates its multicast route entry for 172 (*,G) when it receives a Join/Prune with the RPT-bit and WC-bit set. 173 The interface on which the Join/Prune message arrived is added to the 174 list of outgoing interfaces (oifs) for (*,G). Based on this entry 175 each upstream router between the receiver and the RP sends a 176 Join/Prune message in which the join list includes the RP. The packet 177 payload contains Multicast-Address=G, Join=RP,WC-bit,RPT-bit, 178 Prune=NULL. 180 2.3 Hosts sending to a group 182 When a host starts sending multicast data packets to a group, 183 initially its DR must deliver each packet to the RP for distribution 184 down the RP-tree (see figure 2). The sender's DR initially 185 encapsulates each data packet in a Register message and unicasts it 186 to the RP for that group. The RP decapsulates each Register message 187 and forwards the enclosed data packet natively to downstream members 188 on the shared RP-tree. 190 -------- | 191 |Source| | ----- ----- ---- ------ | ---------- 192 |Host |--+---| A |---| B |--|RP|----| C |-----+---| Receiver| 193 -------- | ----- ----- ---- ------ | | Host | 194 -------> ----------> ------------> ----------- 195 Data packet Register forward 196 decapsulated 197 data packet 199 Fig. 2 Example: a host sending to a group 201 If the data rate of the source warrants the use of a source-specific 202 shortest path tree (SPT), the RP may construct a new multicast route 203 entry that is specific to the source, hereafter referred to as (S,G) 204 state, and send periodic Join/Prune messages toward the source. Note 205 that over time, the rules for when to switch can be modified without 206 global coordination. When and if the RP does switch to the SPT, the 207 routers between the source and the RP build and maintain (S,G) state 208 in response to these messages and send (S,G) messages upstream toward 209 the source. 211 The source's DR must stop encapsulating data packets in Registers 212 when (and so long as) it receives Register-Stop messages from the RP. 213 The RP triggers Register-Stop messages in response to Registers, if 214 the RP has no downstream receivers for the group (or for that 215 particular source), or if the RP has already joined the (S,G) tree 216 and is receiving the data packets natively. Each source's DR 217 maintains, per (S,G), a Register-Suppression-timer. The Register- 218 Suppression-timer is started by the Register-Stop message; upon 219 expiration, the source's DR resumes sending data packets to the RP, 220 encapsulated in Register messages. 222 2.4 Switching from shared tree (RP-tree) to shortest path tree 223 (SP-tree)} 225 A router with directly-connected members first joins the shared RP- 226 tree. The router can switch to a source's shortest path tree (SP- 227 tree) after receiving packets from that source over the shared RP- 228 tree. The recommended policy is to initiate the switch to the SP-tree 229 after receiving a significant number of data packets during a 230 specified time interval from a particular source. To realize this 231 policy the router can monitor data packets from sources for which it 232 has no source-specific multicast route entry and initiate such an 233 entry when the data rate exceeds the configured threshold. As shown 234 in figure 3, router `A' initiates a (S,G) state. 236 First Hop Router for Source 237 ----- ------- 238 | D |-------| Host| 239 / ----- ------- 240 Source tree / / \ 241 <-------------------/ / \ 242 / \ 243 ------ | ----- ----- - ----- 244 |Host|--+-| A |----------------| B |---------------| C | RP 245 ------ | ----- ----- ----- 246 Receiver| <--------------------------------------- 247 Shared tree 249 Fig. 3 Example: Switching from shared tree to shortest path tree 251 When a (S,G) entry is activated (and periodically so long as the 252 state exists), a Join/Prune message is sent upstream towards the 253 source, S, with S in the join list. The payload contains Multicast- 254 Address=G, Join=S, Prune=NULL. When the (S,G) entry is created, the 255 outgoing interface list is copied from (*,G), i.e., all local shared 256 tree branches are replicated in the new shortest path tree. In this 257 way when a data packet from S arrives and matches on this entry, all 258 receivers will continue to receive the source's packets along this 259 path. (In more complicated scenarios, other entries in the router 260 have to be considered, as described in Section 3). Note that (S,G) 261 state must be maintained in each last-hop router that is responsible 262 for initiating and maintaining an SP-tree. Even when (*,G) and (S,G) 263 overlap, both states are needed to trigger the source-specific 264 Join/Prune messages. (S,G) state is kept alive by data packets 265 arriving from that source. A timer, Entry-timer, is set for the (S,G) 266 entry and this timer is restarted whenever data packets for (S,G) are 267 forwarded out at least one oif, or Registers are sent. When the 268 Entry-timer expires, the state is deleted. The last-hop router is the 269 router that delivers the packets to their ultimate end-system 270 destination. This is the router that monitors if there is group 271 membership and joins or prunes the appropriate distribution trees in 272 response. In general the last-hop router is the Designated Router 273 (DR) for the LAN. However, under various conditions described later, 274 a parallel router connected to the same LAN may take over as the 275 last-hop router in place of the DR. 277 Only the RP and routers with local members can initiate switching to 278 the SP-tree; intermediate routers do not. Consequently, last-hop 279 routers create (S,G) state in response to data packets from the 280 source, S; whereas intermediate routers only create (S,G) state in 281 response to Join/Prune messages from downstream that have S in the 282 Join list. 284 The (S,G) entry is initialized with the SPT-bit cleared, indicating 285 that the shortest path tree branch from S has not yet been setup 286 completely, and the router can still accept packets from S that 287 arrive on the (*,G) entry's indicated incoming interface (iif). Each 288 PIM multicast entry has an associated incoming interface on which 289 packets are expected to arrive. 291 When a router with a (S,G) entry and a cleared SPT-bit starts to 292 receive packets from the new source S on the iif for the (S,G) entry, 293 and that iif differs from the (*,G) entry's iif, the router sets the 294 SPT-bit, and sends a Join/Prune message towards the RP, indicating 295 that the router no longer wants to receive packets from S via the 296 shared RP-tree. The Join/Prune message sent towards the RP includes S 297 in the prune list, with the RPT-bit set indicating that S's packets 298 must not be forwarded down this branch of the shared tree. If the 299 router receiving the Join/Prune message has (S,G) state (with or 300 without the route entry's RPT-bit flag set), it deletes the arriving 301 interface from the (S,G) oif list. If the router has only (*,G) 302 state, it creates an entry with the RPT-bit flag set to 1. For 303 brevity we refer to an (S,G) entry that has the RPT-bit flag set to 1 304 as an (S,G)RPT-bit entry. This notational distinction is useful to 305 point out the different actions taken for (S,G) entries depending on 306 the setting of the RPT-bit flag. Note that a router can have no more 307 than one active (S,G) entry for any particular S and G, at any 308 particular time; whether the RPT-bit flag is set or not. In other 309 words, a router never has both an (S,G) and an (S,G)RPT-bit entry for 310 the same S and G at the same time. The Join/Prune message payload 311 contains Multicast-Address=G, Join=NULL, Prune=S,RPT-bit. 313 A new receiver may join an existing RP-tree on which source-specific 314 prune state has been established (e.g., because downstream receivers 315 have switched to SP-trees). In this case the prune state must be 316 eradicated upstream of the new receiver to bring all sources' data 317 packets down to the new receiver. Therefore, when a (*,G) Join 318 arrives at a router that has any (Si,G)RPT-bit entries (i.e., entries 319 that cause the router to send source-specific prunes toward the RP), 320 these entries must be updated upstream of the router so as to bring 321 all sources' packets down to the new member. To accomplish this, each 322 router that receives a (*,G) Join/Prune message updates all existing 323 (S,G)RPT-bit entries. The router may also trigger a (*,G) Join/Prune 324 message upstream to cause the same updating of RPT-bit settings 325 upstream and pull down all active sources' packets. If the arriving 326 (*,G) join has some sources included in its prune list, then the 327 corresponding (S,G)RPT-bit entries are left unchanged (i.e., the 328 RPT-bit remains set and no oif is added). 330 2.5 Steady state maintenance of distribution tree (i.e., router state)} 332 In the steady state each router sends periodic Join/Prune messages 333 for each active PIM route entry; the Join/Prune messages are sent to 334 the neighbor indicated in the corresponding entry. These messages are 335 sent periodically to capture state, topology, and membership changes. 336 A Join/Prune message is also sent on an event-triggered basis each 337 time a new route entry is established for some new source (note that 338 some damping function may be applied, e.g., a short delay to allow 339 for merging of new Join information). Join/Prune messages do not 340 elicit any form of explicit acknowledgment; routers recover from lost 341 packets using the periodic refresh mechanism. 343 2.6 Obtaining RP information 345 To obtain the RP information, all routers within a PIM domain collect 346 Bootstrap messages. Bootstrap messages are sent hop-by-hop within the 347 domain; the domain's bootstrap router (BSR) is responsible for 348 originating the Bootstrap messages. Bootstrap messages are used to 349 carry out a dynamic BSR election when needed and to distribute RP 350 information in steady state. 352 A domain in this context is a contiguous set of routers that all 353 implement PIM and are configured to operate within a common boundary 354 defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each 355 PIM domain to the rest of the internet. 357 Routers use a set of available RPs (called the RP-Set) distributed in 358 Bootstrap messages to get the proper Group to RP mapping. The 359 following paragraphs summarize the mechanism; details of the 360 mechanism may be found in Sections 3.6 and Appendix 6.2. A (small) 361 set of routers, within a domain, are configured as candidate BSRs 362 and, through a simple election mechanism, a single BSR is selected 363 for that domain. A set of routers within a domain are also configured 364 as candidate RPs (C-RPs); typically these will be the same routers 365 that are configured as C-BSRs. Candidate RPs periodically unicast 366 Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of that 367 domain. C-RP-Advs include the address of the advertising C-RP, as 368 well as an optional group address and a mask length field, indicating 369 the group prefix(es) for which the candidacy is advertised. The BSR 370 then includes a set of these Candidate-RPs (the RP-Set), along with 371 the corresponding group prefixes, in Bootstrap messages it 372 periodically originates. Bootstrap messages are distributed hop-by- 373 hop throughout the domain. 375 Routers receive and store Bootstrap messages originated by the BSR. 376 When a DR gets a membership indication from IGMP for (or a data 377 packet from) a directly connected host, for a group for which it has 378 no entry, the DR uses a hash function to map the group address to one 379 of the C-RPs whose Group-prefix includes the group (see Section 3.7). 380 The DR then sends a Join/Prune message towards (or unicasts Registers 381 to) that RP. 383 The Bootstrap message indicates liveness of the RPs included therein. 384 If an RP is included in the message, then it is tagged as `up' at the 385 routers; while RPs not included in the message are removed from the 386 list of RPs over which the hash algorithm acts. Each router continues 387 to use the contents of the most recently received Bootstrap message 388 until it receives a new Bootstrap message. 390 If a PIM domain partitions, each area separated from the old BSR will 391 elect its own BSR, which will distribute an RP-Set containing RPs 392 that are reachable within that partition. When the partition heals, 393 another election will occur automatically and only one of the BSRs 394 will continue to send out Bootstrap messages. As is expected at the 395 time of a partition or healing, some disruption in packet delivery 396 may occur. This time will be on the order of the region's round-trip 397 time and the bootstrap router timeout value. 399 2.7 Interoperation with dense mode protocols such as DVMRP 401 In order to interoperate with networks that run dense-mode, broadcast 402 and prune, protocols, such as DVMRP, all packets generated within a 403 PIM-SM region must be pulled out to that region's PIM Multicast 404 Border Routers (PMBRs) and injected (i.e., broadcast) into the DVMRP 405 network. A PMBR is a router that sits at the boundary of a PIM-SM 406 domain and interoperates with other types of multicast routers such 407 as those that run DVMRP. Generally a PMBR would speak both protocols 408 and implement interoperability functions not required by regular PIM 409 routers. To support interoperability, a special entry type, referred 410 to as (*,*,RP), must be supported by all PIM routers. For this 411 reason we include details about (*,*,RP) entry handling in this 412 general PIM specification. 414 A data packet will match on a (*,*,RP) entry if there is no more 415 specific entry (such as (S,G) or (*,G)) and the destination group 416 address in the packet maps to the RP listed in the (*,*,RP) entry. In 417 this sense, a (*,*,RP) entry represents an aggregation of all the 418 groups that hash to that RP. PMBRs initialize (*,*,RP) state for each 419 RP in the domain's RPset. The (*,*,RP) state causes the PMBRs to send 420 (*,*,RP) Join/Prune messages toward each of the active RPs in the 421 domain. As a result distribution trees are built that carry all data 422 packets originated within the PIM domain (and sent to the RPs) down 423 to the PMBRs. 425 PMBRs are also responsible for delivering externally-generated 426 packets to routers within the PIM domain. To do so, PMBRs initially 427 encapsulate externally-originated packets (i.e., received on DVMRP 428 interfaces) in Register messages and unicast them to the 429 corresponding RP within the PIM domain. The Register message has a 430 bit indicating that it was originated by a border router and the RP 431 caches the originating PMBR's address in the route entry so that 432 duplicate Registers from other PMBRs can be declined with a 433 Register-Stop message. 435 All PIM routers must be capable of supporting (*,*,RP) state and 436 interpreting associated Join/Prune messages. We describe the handling 437 of (*,*,RP) entries and messages throughout this document; however, 438 detailed PIM Multicast Border Router (PMBR) functions will be 439 specified in a separate interoperability document (see directory, 440 http://catarina.usc.edu/pim/interop/). 442 2.8 Multicast data packet processing 444 Data packets are processed in a manner similar to other multicast 445 schemes. A router first performs a longest match on the source and 446 group address in the data packet. A (S,G) entry is matched first if 447 one exists; a (*,G) entry is matched otherwise. If neither state 448 exists, then a (*,*,RP) entry match is attempted as follows: the 449 router hashes on G to identify the RP for group G, and looks for a 450 (*,*,RP) entry that has this RP address associated with it. If none 451 of the above exists, then the packet is dropped. If a state is 452 matched, the router compares the interface on which the packet 453 arrived to the incoming interface field in the matched route entry. 454 If the iif check fails the packet is dropped, otherwise the packet is 455 forwarded to all interfaces listed in the outgoing interface list. 457 Some special actions are needed to deliver packets continuously while 458 switching from the shared to shortest-path tree. In particular, when 459 a (S,G) entry is matched, incoming packets are forwarded as follows: 461 1 If the SPT-bit is set, then: 463 1 if the incoming interface is the same as a matching 464 (S,G) iif, the packet is forwarded to the oif-list of 465 (S,G). 467 2 if the incoming interface is different than a matching 468 (S,G) iif , the packet is discarded. 470 2 If the SPT-bit is cleared, then: 472 1 if the incoming interface is the same as a matching 473 (S,G) iif, the packet is forwarded to the oif-list of 474 (S,G). In addition, the SPT bit is set for that entry if 475 the incoming interface differs from the incoming interface 476 of the (*,G) or (*,*,RP) entry. 478 2 if the incoming interface is different than a matching 479 (S,G) iif, the incoming interface is tested against a 480 matching (*,G) or (*,*,RP) entry. If the iif is the same as 481 one of those, the packet is forwarded to the oif-list of 482 the matching entry. 484 3 Otherwise the iif does not match any entry for G and 485 the packet is discarded. 487 Data packets never trigger prunes. However, data packets may trigger 488 actions that in turn trigger prunes. For example, when router B in 489 figure 3 decides to switch to SP-tree at step 3, it creates a (S,G) 490 entry with SPT-bit set to 0. When data packets from S arrive at 491 interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G) is 492 different than that for (S,G). This triggers the sending of prunes 493 towards the RP. 495 2.9 Operation over Multi-access Networks 497 This section describes a few additional protocol mechanisms needed to 498 operate PIM over multi-access networks: Designated Router election, 499 Assert messages to resolve parallel paths, and the Join/Prune- 500 Suppression-Timer to suppress redundant Joins on multi-access 501 networks. 503 Designated router election: 505 When there are multiple routers connected to a multi-access network, 506 one of them must be chosen to operate as the designated router (DR) 507 at any point in time. The DR is responsible for sending triggered 508 Join/Prune and Register messages toward the RP. 510 A simple designated router (DR) election mechanism is used for both 511 SM and traditional IP multicast routing. Neighboring routers send 512 Hello messages to each other. The sender with the largest network 513 layer address assumes the role of DR. Each router connected to the 514 multi-access LAN sends the Hellos periodically in order to adapt to 515 changes in router status. 517 Parallel paths to a source or the RP--Assert process: 519 If a router receives a multicast datagram on a multi-access LAN from 520 a source whose corresponding (S,G) outgoing interface list includes 521 the interface to that LAN, the packet must be a duplicate. In this 522 case a single forwarder must be elected. Using Assert messages 523 addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN, 524 upstream routers can resolve which one will act as the forwarder. 525 Downstream routers listen to the Asserts so they know which one was 526 elected, and therefore where to send subsequent Joins. Typically this 527 is the same as the downstream router's RPF (Reverse Path Forwarding) 528 neighbor; but there are circumstances where this might not be the 529 case, e.g., when using multiple unicast routing protocols on that 530 LAN. The RPF neighbor for a particular source (or RP) is the next-hop 531 router to which packets are forwarded en route to that source (or 532 RP); and therefore is considered a good path via which to accept 533 packets from that source. 535 The upstream router elected is the one that has the shortest distance 536 to the source. Therefore, when a packet is received on an outgoing 537 interface a router sends an Assert message on the multi-access LAN 538 indicating what metric it uses to reach the source of the data 539 packet. The router with the smallest numerical metric (with ties 540 broken by highest address) will become the forwarder. All other 541 upstream routers will delete the interface from their outgoing 542 interface list. The downstream routers also do the comparison in case 543 the forwarder is different than the RPF neighbor. 545 Associated with the metric is a metric preference value. This is 546 provided to deal with the case where the upstream routers may run 547 different unicast routing protocols. The numerically smaller metric 548 preference is always preferred. The metric preference is treated as 549 the high-order part of an assert metric comparison. Therefore, a 550 metric value can be compared with another metric value provided both 551 metric preferences are the same. A metric preference can be assigned 552 per unicast routing protocol and needs to be consistent for all 553 routers on the multi-access network. 555 Asserts are also needed for (*,G) entries since an RP-Tree and an 556 SP-Tree for the same group may both cross the same multi-access 557 network. When an assert is sent for a (*,G) entry, the first bit in 558 the metric preference (RPT-bit) is always set to 1 to indicate that 559 this path corresponds to the RP tree, and that the match must be done 560 on the RP-Tree (i.e. match on S,G RPTbit entry first, and *,G second). 561 Furthermore, the RPT-bit is always cleared for metric preferences that 562 refer to SP-tree entries; this causes an SP-tree path to always look 563 better than an RP-tree path. When the SP-tree and RPtree cross the 564 same LAN, this mechanism eliminates the duplicates that would 565 otherwise be carried over the LAN. Note that the source address 566 carried inside the assert message is always the source address of 567 the data packet causing this assert. The RPTbit is set to indicate 568 an RP-Tree metric. 570 In case the packet, or the Assert message, matches on oif for 571 (*,*,RP) entry, a (*,G) entry is created, and asserts take place as 572 if the matching state were (*,G). 574 The DR may lose the (*,G) Assert process to another router on the LAN 575 if there are multiple paths to the RP through the LAN. From then on, 576 the DR is no longer the last-hop router for local receivers and 577 removes the LAN from its (*,G) oif list. The winning router becomes 578 the last-hop router and is responsible for sending (*,G) join 579 messages to the RP. 581 Join/Prune suppression: 583 Join/Prune suppression may be used on multi-access LANs to reduce 584 duplicate control message overhead; it is not required for correct 585 performance of the protocol. If a Join/Prune message arrives and 586 matches on the incoming interface for an existing (S,G), (*,G), or 587 (*,*,RP) route entry, and the Holdtime included in the Join/Prune 588 message is greater than the recipient's own [Join/Prune-Holdtime] 589 (with ties resolved in favor of the higher network layer address), a 590 timer (the Join/Prune-Suppression-timer) in the recipient's route 591 entry may be started to suppress further Join/Prune messages. After 592 this timer expires, the recipient triggers a Join/Prune message, and 593 resumes sending periodic Join/Prunes, for this entry. The 594 Join/Prune-Suppression-timer should be restarted each time a 595 Join/Prune message is received with a higher Holdtime. 597 2.10 Unicast Routing Changes 599 When unicast routing changes, an RPF check is done on all active 600 (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming 601 interfaces are updated. In particular, if the new incoming interface 602 appears in the outgoing interface list, it is deleted from the 603 outgoing interface list. The previous incoming interface may be added 604 to the outgoing interface list by a subsequent Join/Prune from 605 downstream. Join/Prune messages received on the new incoming 606 interface are ignored. Join/Prune messages received on new 607 interfaces or existing outgoing interfaces are not ignored. Other 608 outgoing interfaces are left as is until they are explicitly pruned 609 by downstream routers or are timed out due to lack of appropriate 610 Join/Prune messages. If the router has a (S,G) entry with the SPT-bit 611 set, and the updated iif(S,G) does not differ from iif(*,G) or 612 iif(*,*,RP), then the router resets the SPT-bit. 614 The router must send a Join/Prune message with S or RP in the Join 615 list out any new incoming interfaces to inform upstream routers that 616 it expects multicast datagrams over the interface. It may also send a 617 Join/Prune message with S or RP in the Prune list out the old incoming 618 interface, if the link is operational, to inform upstream routers 619 that this part of the distribution tree is going away. 621 2.11 PIM-SM for Inter-Domain Multicast 623 Future documents will address the use of PIM-SM as a backbone inter- 624 domain multicast routing protocol. Design choices center primarily 625 around the distribution and usage of RP information for wide area, 626 inter-domain groups. 628 2.12 Security 630 All PIM control messages may use IPsec [6] to address security 631 concerns. Security mechanisms are likely to be enhanced in the near 632 future. 634 3 Detailed Protocol Description 636 This section describes the protocol operations from the perspective 637 of an individual router implementation. In particular, for each 638 message type we describe how it is generated and processed. 640 3.1 Hello 642 Hello messages are sent so neighboring routers can discover each 643 other. 645 3.1.1 Sending Hellos 647 Hello messages are sent periodically between PIM neighbors, every 648 [Hello-Period] seconds. This informs routers what interfaces have 649 PIM neighbors. Hello messages are multicast using address 224.0.0.13 650 (ALL-PIM-ROUTERS group). The packet includes a Holdtime, set to 651 [Hello-Holdtime], for neighbors to keep the information valid. Hellos 652 are sent on all types of communication links. 654 The DR Election Priority Option SHOULD be included in all Hello 655 messages, to allow DR election to be independent of the relative IP 656 addresses. The DR election priority is a 32-bit unsigned number. 657 The numerically larger priority is always preferred. The priority 658 based DR election is used only when all routers on the LAN include 659 this option in their Hellos. 661 An implementation capable of doing this option SHOULD always include 662 it in the Hellos even if no DR election priority is explicitly 663 configured. The default priority is 1. 665 The Generation Identifier (GenID) Option SHOULD also be included in 666 all Hello messages. This option contains a randomly generated 32-bit 667 value that is different each time a router restarts. Once a new 668 GenID is found from a neighbor, that neighbor SHOULD be treated as 669 a new neighbor by the local system. 671 3.1.2 Receiving Hellos 673 When a router receives a Hello message, it stores the network layer 674 address for that neighbor, sets its Neighbor-timer for the Hello 675 sender to the Holdtime included in the Hello, and determines the 676 Designated Router (DR) for that interface. The highest addressed 677 system is elected DR. Each Hello received causes reevaluation of 678 the DR's address. 680 If no DR election priority option is specified in a Hello message, 681 the Hello sender is deemed not capable of handling the DR 682 election priority option. When such a hello message is received, the 683 neighbor with the highest IP address is elected the DR. This way new 684 systems can interoperate with systems implementing older versions 685 of this specification. 687 The DR election priority received in a Hello is kept until the 688 next Hello from the same system arrives. The newly received priority 689 replaces the cached priority for the same neighbor. 691 When a router that is the active DR receives a Hello from a new 692 neighbor (i.e., from an address that is not yet in the DRs neighbor 693 table, or a neighbor with a new GenID), the DR unicasts its most 694 recent RP-set information to the new neighbor. 696 3.1.3 Timing out neighbor entries 698 A periodic process is run to time out PIM neighbors that have not 699 sent Hellos. If the DR has gone down, a new DR is chosen by scanning 700 all neighbors on the interface and selecting the new DR to be the one 701 with the highest network layer address. If an interface has gone 702 down, the router may optionally time out all PIM neighbors associated 703 with the interface. 705 3.2 Join/Prune 707 Join/Prune messages are sent to join or prune a branch off of the 708 multicast distribution tree. A single message contains both a join 709 and prune list, either one of which may be null. Each list contains 710 a set of source addresses, indicating the source-specific trees or 711 shared tree that the router wants to join or prune. In this 712 specification, the term (S,G) entry covers all (S,G) entries, 713 irrespective of any flag settings unless explicitly stated otherwise. 715 3.2.1 Sending Join/Prune Messages 717 Join/Prune messages are merged such that a message sent to a 718 particular upstream neighbor, N, includes all of the current joined 719 and pruned sources that are reached via N; according to unicast 720 routing Join/Prune messages are multicast to all routers on multi- 721 access networks with the target address set to the next hop router 722 towards S or RP. Join/Prune messages are sent every [Join/Prune- 723 Period] seconds. In the future we will introduce mechanisms to rate- 724 limit this control traffic on a hop by hop basis, in order to avoid 725 excessive overhead on small links. In addition, certain events cause 726 triggered Join/Prune messages to be sent. 728 Periodic Join/Prune Messages: 730 A router sends a periodic Join/Prune message to each distinct RPF 731 neighbor associated with each (S,G), (*,G) and (*,*,RP) entry. 732 Join/Prune messages are only sent if the RPF neighbor is a PIM 733 neighbor. A periodic Join/Prune message sent to a particular RPF 734 neighbor is constructed as follows: 736 1 Each router determines the RP for a (*,G) entry by using 737 the hash function described. The RP address (with RPT and WC 738 bits set) is included in the join list of a periodic Join/Prune 739 message under the following conditions: 741 1 The Join/Prune message is being sent to the RPF 742 neighbor toward the RP for an active (*,G) or (*,*,RP) 743 entry, and 745 2 The outgoing interface list in the (*,G) or (*,*,RP) 746 entry is non-NULL, or the router is the DR on the same 747 interface as the RPF neighbor. 749 2 A particular source address, S, is included in the join 750 list with the RPT and WC bits cleared under the following 751 conditions: 753 1 The Join/Prune message is being sent to the RPF 754 neighbor toward S, and 756 2 There exists an active (S,G) entry with the RPT-bit 757 flag cleared, and 759 3 The oif list in the (S,G) entry is not null. 761 3 A particular source address, S, is included in the prune 762 list with the RPT and WC bits cleared under the following 763 conditions: 765 1 The Join/Prune message is being sent to the RPF 766 neighbor toward S, and 768 2 There exists an active (S,G) entry with the RPT-bit 769 flag cleared, and 771 3 The oif list in the (S,G) entry is null. 773 4 A particular source address, S, is included in the prune 774 list with the RPT-bit set and the WC bit cleared under the 775 following conditions: 777 1 The Join/Prune message is being sent to the RPF 778 neighbor toward the RP and there exists a (S,G) entry with 779 the RPT-bit flag set and null oif list, or 781 2 The Join/Prune message is being sent to the RPF 782 neighbor toward the RP, there exists a (S,G) entry with the 783 RPT-bit flag cleared and SPT-bit set, and the incoming 784 interface toward S is different than the incoming interface 785 toward the RP, or 787 3 The Join/Prune message is being sent to the RPF 788 neighbor toward the RP, and there exists a (*,G) entry and 789 (S,G) entry for a directly connected source. 791 5 The RP address (with RPT and WC bits set) is included in 792 the prune list if: 794 1 The Join/Prune message is being sent to the RPF 795 neighbor toward the RP and there exists a (*,G) entry with 796 a null oif list (see Section 3.5.2). 798 Triggered Join/Prune Messages: 800 In addition to periodic messages, the following events will 801 trigger Join/Prune messages if as a result, a) a new entry is 802 created, or b) the oif list changes from null to non-null or non- 803 null to null. The contents of triggered messages are the same as 804 the periodic, described above. 806 1 Receipt of an indication from IGMP that the state of 807 directly-connected-membership has changed (i.e., new members 808 have just joined `membership indication' or all members have 809 left), for a group G, may cause the last-hop router to build or 810 modify corresponding (*,G) state. When IGMP indicates that 811 there are no longer directly connected members, the oif is 812 removed from the oif list if the oif-timer is not running. A 813 Join/Prune message is triggered if and only if a) a new entry is 814 created, or b) the oif list changes from null to non-null or 815 non-null to null, as follows: 817 1 If the receiving router does not have a route entry 818 for G the router creates a (*,G) entry, copies the oif list 819 from the corresponding (*,*,RP) entry (if it exists), and 820 includes the interface included in the IGMP membership 821 indication in the oif list; as always, the router never 822 includes the entry's iif in the oif list. The router sends 823 a Join/Prune message towards the RP with the RP address and 824 RPT-bit and WC-bits set in the join list. Or, 826 2 If a (S,G)RPT-bit or (*,G) entry already exists, the 827 interface included in the IGMP membership indication is 828 added to the oif list (if it was not included already). 830 2 Receipt of a Join/Prune message for (S,G), (*,G) or 831 (*,*,RP) will cause building or modifying corresponding state, 832 and subsequent triggering of upstream Join/Prune messages, in 833 the following cases: 835 1 When there is no current route entry, the RP address 836 included in the Join/Prune message is checked against the 837 local RP-Set information. If it matches, an entry will be 838 created and the new entry will in turn trigger an upstream 839 Join/Prune message. If the router has no RP-Set information 840 it may discard the message, or optionally use the RP 841 address included in the message. 843 2 When the outgoing interface list of an (S,G)RPT-bit 844 entry becomes null, the triggered Join/Prune message will 845 contain S in the prune list. 847 3 When there exists a (S,G)RPT-bit with null oif list, 848 and an (*,G) Join/Prune message is received, the arriving 849 interface is added to the oif list and a (*,G) Join/Prune 850 message is triggered upstream. This triggered (*,G) 851 Join/Prune message SHOULD include (S,G)RPT-bit prunes for 852 all (S,G)RPT-bit entries with null oif list. 854 4 When there exists a (*,G) with null oif list, and a 855 (*,*,RP) Join/Prune message is received, the receiving 856 interface is added to the oif list and a (*,*,RP) 857 Join/Prune message is triggered upstream. 859 3 Receipt of a packet that matches on a (S,G) entry whose 860 SPT-bit is cleared triggers the following if the packet arrived 861 on the correct incoming interface and there is a (*,G) or 862 (*,*,RP) entry with a different incoming interface: a) the 863 router sets the SPT-bit on the (S,G) entry, and b) the router 864 sends a Join/Prune message towards the RP with S in the prune 865 list and the RPT-bit set. 867 4 Receipt of a packet at the DR from a directly connected 868 source S, on the subnet containing the address S, triggers a 869 Join/Prune message towards the RP with S in the prune list and 870 the RPT-bit set under the following conditions: a) there is no 871 matching (S,G) state, and b) there exists a (*,G) or (*,*,RP) 872 for which the DR is not the RP. 874 5 When a Join/Prune message is received for a group G, the 875 prune list is checked. If the prune list contains a source or RP 876 for which the receiving router has a corresponding active (S,G), 877 (*,G) or (*,*,RP) entry, and whose iif is that on which the 878 Join/Prune was received, then a join for (S,G), (*,G) or 879 (*,*,RP) is triggered to override the prune, respectively. (This 880 is necessary in the case of parallel downstream routers 881 connected to a multi-access network.) 883 6 When the RP fails, the RP will not be included in the 884 Bootstrap messages sent to all routers in that domain. This 885 triggers the DRs to send (*,G) Join/Prune messages towards the 886 new RP for the group, as determined by the RP-Set and the hash 887 function. As described earlier, PMBRs trigger (*,*,RP) joins 888 towards each RP in the RP-Set. 890 7 When an entry's Join/Prune-Suppression timer expires, a 891 Join/Prune message is triggered upstream corresponding to that 892 entry, even if the outgoing interface has not transitioned 893 between null and non-null states. 895 8 When the RPF neighbor changes (whether due to an Assert or 896 changes in unicast routing), the router sets a random delay 897 timer (the Random-Delay-Join-Timer) whose expiration triggers 898 sending of a Join/Prune message for the asserted route entry to 899 the Assert winner (if the Join/Prune Suppression timer has 900 expired.) 902 We do not trigger prunes onto interfaces based on data packets. Data 903 packets that arrive on the wrong incoming interface are silently 904 dropped. However, on point-to-point interfaces triggered prunes may 905 be sent as an optimization. 907 It is possible that a Join/Prune message constructed according to the 908 preceding rules could exceed the MTU of a network. In this case, the 909 message can undergo semantic fragmentation whereby information 910 corresponding to different groups can be sent in different messages. 911 However, if a Join/Prune message must be fragmented the complete prune 912 list corresponding to a group G must be included in the same Join/Prune 913 message as the associated RP-tree Join for G. If such semantic 914 fragmentation is not possible, IP fragmentation should be used between 915 the two neighboring hops. 917 3.2.2 Receiving Join/Prune Messages 919 When a router receives Join/Prune message, it processes it as follows. 921 The receiver of the Join/Prune notes the interface on which the PIM 922 message arrived, call it I. The receiver then checks to see if the 923 Join/Prune message was addressed to the receiving router itself 924 (i.e., the router's address appears in the Unicast Upstream Neighbor 925 Router field of the Join/Prune message). (If the router is connected 926 to a multiaccess LAN, the message could be intended for a different 927 router.) If the Join/Prune is for this router the following actions 928 are taken. 930 For each group address G, in the Join/Prune message, the associated 931 join list is processed as follows. We refer to each address in the 932 join list as Sj; Sj refers to the RP if the RPT-bit and WC-bit are 933 both set. For each Sj in the join list of the Join/Prune message: 935 1 If an address, Sj, in the join list of the Join/Prune 936 message has the RPT-bit and WC-bit set, then Sj is the RP 937 address used by the downstream router(s) and the following 938 actions are taken: 940 1 If Sj is not the same as the receiving router's RP 941 mapping for G, the receiving router may ignore the 942 Join/Prune message with respect to that group entry. If 943 the router does not have any RP-Set information, it may use 944 the address Sj included in the Join/Prune message as the RP 945 for the group. 947 2 If Sj is the same as the receiving router's RP mapping 948 for G, the receiving router adds I to the outgoing 949 interface list of the (*,G) route entry (if there is no 950 (*,G) entry, the router creates one first) and sets the 951 Oif-timer for that interface to the Holdtime specified in 952 the Join/Prune message. In addition, the Oif-Deletion-Delay 953 for that interface is set to 1/3rd the Holdtime specified 954 in the Join/Prune message. If a (*,*,RP) entry exists, for 955 the RP associated with G, then the oif list of the newly 956 created (*,G) entry is copied from that (*,*,RP) entry. 958 3 For each (Si,G) entry associated with group G: i) if 959 Si is not included in the prune list, ii) if I is not on 960 the same subnet as the address Si, and iii) if I is not the 961 iif, then interface I is added to the oif list and the 962 Oif-timer for that interface in each affected entry is 963 increased (never decreased) to the Holdtime included in the 964 Join/Prune message. In addition, if the Oif-timer for that 965 interface is increased, the Oif-Deletion-Delay for that 966 interface is set to 1/3rd the Holdtime specified in the 967 Join/Prune message. 969 If the group address in the Join/Prune message is `*' then 970 every (*,G) and (S,G) entry, whose group address hashes to 971 the RP indicated in the (*,*,RP) Join/Prune message, is 972 updated accordingly. A `*' in the group field of the 973 Join/Prune is represented by a group address 224.0.0.0 and 974 a group mask length of 4, indicating a (*,*,RP) Join. 976 4 If the (Si,G) entry has its RPT-bit flag set to 1, and 977 its oif list is the same as the (*,G) oif list, then the 978 (Si,G)RPT-bit entry is deleted, 980 5 The incoming interface is set to the interface used to 981 send unicast packets to the RP in the (*,G) route entry, 982 i.e., RPF interface toward the RP. 984 2 For each address, Sj, for which there is no existing (Sj,G) 985 route entry, the router initiates one. The router creates a 986 (S,G) entry and copies all outgoing interfaces from the 987 (*,G) entry; and if there is no (*,G) entry, the oif list is 988 copied from the (*,*,RP) entry, if it exists. In all cases, 989 the iif of the (S,G) entry is always excluded from the oif list. 991 1 If the interface used to reach Sj, is the same as I, 992 this represents an error (or a unicast routing change) and 993 the Join/Prune must not be processed. 995 2 Make the RPT-bit setting of the created (Sj,G) entry be 996 the same as the RPT-bit setting in the Join/Prune 997 packet. 999 3 Interface I is added to the outgoing interface list to 1000 (Sj,G). The incoming interface for (Sj,G) is set to the 1001 interface used to send unicast packets to Sj (i.e., the 1002 RPF neighbor). 1004 3 For each address, Sj, in the join list of the Join/Prune 1005 message, for which there is an existing (Sj,G) route entry, 1007 1 If the RPT-bit is not set for Sj listed in the 1008 Join/Prune message, but the RPT-bit flag is set on the 1009 existing (Sj,G) entry, the router clears the RPT-bit flag 1010 on the (Sj,G) entry, sets the incoming interface to point 1011 towards Sj for that (Sj,G) entry, and sends a Join/Prune 1012 message corresponding to that entry through the new 1013 incoming interface; and 1015 2 If I is not the same as the existing incoming 1016 interface, the router adds I to the list of outgoing 1017 interfaces. 1019 3 The Oif-timer for I is increased (never decreased) to 1020 the Holdtime included in the Join/Prune message. In 1021 addition, if the Oif-timer for that interface is increased, 1022 the Oif-Deletion-Delay for that interface is set to 1/3rd 1023 the Holdtime specified in the Join/Prune message. 1025 There may be situations when an implementation may want to send 1026 (S,G)RPT-bit jois up the RP-tree, to re-enable forwarding of packets 1027 down the RP-tree without (*,G) joins. Such (S,G)RPTbit joins 1028 SHOULD be accepted. For each address, Sj, in the join list of the 1029 Join/Prune message whose RPT-bit is set and WC-bit cleared, 1031 1 If no (Sj,G) and no (*,G) entry exists, create an (*,G) entry 1032 with NULL outgoing interface list. Create an (Sj,G)RPT-bit 1033 and follow the next rule; 1035 2 If no (Sj,G) entry exists but (*,G) entry exists, 1036 create an (Sj,G)RPT-bit entry, and follow the next 1037 rule; 1039 3 If an (Sj,G) or (Sj,G) RPT-bit entry exists, add I to the 1040 outgoing interface list if it is not the same as the incoming 1041 interface. If the addition of I causes the entry to go into 1042 forwarding state, an (Sj,G) or (Sj,G)RPT-bit join should 1043 be triggered. 1045 For each group address G, in the Join/Prune message, the 1046 associated prune list is processed as follows. We refer to each 1047 address in the prune list as Sp; Sp refers to the RP if the RPT- 1048 bit and WC-bit are both set. When IGMP members exist for the 1049 group G on the receiving interface, the prune is ignored. 1050 Otherwise, for each Sp in the prune list of the Join/Prune message: 1052 1 For each address, Sp, in the prune list whose RPT-bit and 1053 WC-bit are cleared: 1055 1 If there is an existing (Sp,G) route entry, the router 1056 lowers the entry's Oif-timer for I to its Oif-Deletion- 1057 Delay, allowing for other downstream routers on a multi- 1058 access LAN to override the prune. However, on point-to- 1059 point links, the oif-timer is expired immediately. 1061 2 If the router has a current (*,G), or (*,*,RP), route 1062 entry, and if the existing (Sp,G) entry has its RPT-bit 1063 flag set to 1, then this (Sp,G)RPT-bit entry is maintained 1064 (not deleted) even if its outgoing interface list is null. 1066 2 For each address, Sp, in the prune list whose RPT-bit is 1067 set and whose WC-bit cleared: 1069 1 If there is an existing (Sp,G) route entry, the router 1070 lowers the entry's Oif-timer for I to its Oif-Deletion- 1071 Delay, allowing for other downstream routers on a multi- 1072 access LAN to override the prune. However, on point-to- 1073 point links, the oif-timer is expired immediately. 1075 2 If the router has a current (*,G), or (*,*,RP), route 1076 entry, and if the existing (Sp,G) entry has its RPT-bit 1077 flag set to 1, then this (Sp,G)RPT-bit entry is not 1078 deleted, and the Entry-timer is restarted, even if its 1079 outgoing interface list is null. 1081 3 If (*,G), or corresponding (*,*,RP), state exists, but 1082 there is no (Sp,G) entry, an (Sp,G)RPT-bit entry is created 1083 . The outgoing interface list is copied from the (*,G), or 1084 (*,*,RP), entry, with the interface, I, on which the prune 1085 was received, is deleted. Packets from the pruned source, 1086 Sp, match on this state and are not forwarded toward the 1087 pruned receivers. 1089 3 For each address, Sp, in the prune list whose RPT-bit and 1090 WC-bit are both set: 1092 1 If there is an existing (*,G) entry, with Sp as the RP 1093 for G, the router lowers the entry's Oif-timer for I to its 1094 Oif-Deletion-Delay, allowing for other downstream routers 1095 on a multi-access LAN to override the prune. However, on 1096 point-to-point links, the oif-timer is expired immediately. 1098 2 If the corresponding (*,*,RP) state exists, but there 1099 is no (*,G) entry, a (*,G) entry is created. The outgoing 1100 interface list is copied from (*,*,RP) entry, with the 1101 interface, I, on which the prune was received, deleted. 1103 For any new (S,G), (*,G) or (*,*,RP) entry created by an 1104 incoming Join/Prune message, the SPT-bit is cleared (and if a 1105 Join/Prune-Suppression timer is used, it is left off.) 1107 If the entry has a Join/Prune-Suppression timer associated with it, 1108 and if the received Join/Prune does not indicate the router as its 1109 target, then the receiving router examines the join and prune lists 1110 to see if any addresses in the list `completely-match' existing 1111 (S,G), (*,G), or (*,*,RP) state for which the receiving router 1112 currently schedules Join/Prune messages. An element on the join or 1113 prune list `completely-matches' a route entry only if both the 1114 addresses and RPT-bit flag are the same. If the incoming Join/Prune 1115 message completely matches an existing (S,G), (*,G), or (*,*,RP) 1116 entry and the Join/Prune arrived on the iif for that entry, then the 1117 router compares the Holdtime included in the Join/Prune message, to 1118 its own [Join/Prune-Holdtime]. If its own [Join/Prune-Holdtime] is 1119 lower, the Join/Prune-Suppression-timer is started at the 1120 [Join/Prune-Suppression-Timeout]. When the Join/Prune Suppression 1121 timer expires, the router triggers a Join/Prune message for the 1122 corresponding entry(ies). 1124 3.3 Register and Register-Stop 1126 When a source first starts sending to a group its packets are 1127 encapsulated in Register messages and sent to the RP. If the data 1128 rate warrants source-specific paths, the RP sets up source specific 1129 state and starts sending (S,G) Join/Prune messages toward the source, 1130 with S in the join list. 1132 3.3.1 Sending Registers and Receiving Register-Stops 1134 Register messages are sent as follows: 1136 1 When a DR receives a packet from a directly connected 1137 source, S, on the subnet containing the address S, 1139 1 If there is no corresponding (S,G) entry, and the 1140 router has RP-Set information, and the DR is not the RP for 1141 G, the DR creates an (S,G) entry with the Register- 1142 Suppression-timer turned off and the RP address set 1143 according to the hash function mapping for the 1144 corresponding group. The oif list is copied from existing 1145 (*,G) or (*,*,RP) entries, if they exist. The iif of the 1146 (S,G) entry is always excluded from the oif list. If there 1147 exists a (*,G) or (*,*,RP) entry, the DR sends a Join/Prune 1148 message towards the RP with S in the prune list and the 1149 RPT-bit set. 1151 2 If there is a (S,G) entry in existence, the DR simply 1152 restarts the corresponding Entry-timer. 1154 When a PMBR (e.g., a router that connects the PIM-SM region 1155 to a dense mode region running DVMRP or PIM-DM) receives a 1156 packet from a source in the dense mode region, the router 1157 treats the packet as if it were from a directly connected 1158 source. A separate document will describe the details of 1159 interoperability. 1161 2 If the new or previously-existing (S,G) entry's Register- 1162 Suppression-timer is not running, the data packet is 1163 encapsulated in a Register message and unicast to the RP for 1164 that group. The data packet is also forwarded according to (S,G) 1165 state in the DR if the oif list is not null; since a receiver 1166 may join the SP-tree while the DR is still registering to the 1167 RP. 1169 3 If the (S,G) entry's Register-Suppression-timer is running, 1170 the data packet is not sent in a Register message, it is just 1171 forwarded according to the (S,G) oif list. 1173 When the DR receives a Register-Stop message, it restarts the 1174 Register-Suppression-timer in the corresponding (S,G) entry(ies) at 1175 [Register-Suppression-Timeout] seconds. If there is data to be 1176 registered, the DR may send a null Register (a Register message with 1177 a zero-length data portion in the inner packet) to the RP, [Probe- 1178 Time] seconds before the Register-Suppression-timer expires, to avoid 1179 sending occasional bursts of traffic to an RP unnecessarily. 1181 3.3.2 Receiving Register Messages and Sending Register-Stops 1183 When a router (i.e., the RP) receives a Register message, the router 1184 does the following: 1186 1 Decapsulates the data packet, and checks for a 1187 corresponding (S,G) entry. 1189 1 If a (S,G) entry with cleared (0) SPT bit exists, and 1190 the received Register does not have the Null-Register-Bit 1191 set to 1, the packet is forwarded; and the SPT bit is left 1192 cleared (0). If the SPT bit is 1, the packet is dropped, 1193 and Register-Stop messages are triggered. Register-Stops 1194 should be rate-limited (in an implementation-specific 1195 manner) so that no more than a few are sent per round trip 1196 time. This prevents a high datarate stream of packets from 1197 triggering a large number of Register-Stop messages between 1198 the time that the first packet is received and the time 1199 when the source receives the first Register-Stop. 1201 2 If there is no (S,G) entry, but there is a (*,G) 1202 entry, and the received Register does not have the Null- 1203 Register-Bit set to 1, the packet is forwarded according to 1204 the (*,G) entry. 1206 3 If there is a (*,*,RP) entry but no (*,G) entry, and 1207 the Register received does not have the Null-Register-Bit 1208 set to 1, a (*,G) or (S,G) entry is created and the oif 1209 list is copied from the (*,*,RP) entry to the new entry. 1210 The packet is forwarded according to the created entry. 1212 4 If there is no G or (*,*,RP) entry corresponding to G, 1213 the packet is dropped, and a Register-Stop is triggered. 1215 5 A "Border bit" bit is added to the Register message, 1216 to facilitate interoperability mechanisms. PMBRs set this 1217 bit when registering for external sources (see Section 1218 2.7). If the "Border bit" is set in the Register, 1219 the RP does the following: 1221 1 If there is no matching (S,G) state, but there 1222 exists (*,G) or (*,*,RP) entry, the RP creates a (S,G) 1223 entry, with a `PMBR' field. This field holds the 1224 source of the Register (i.e. the outer network layer 1225 address of the register packet). The RP triggers a 1226 (S,G) join towards the source of the data packet, and 1227 clears the SPT bit for the (S,G) entry. If the 1228 received Register is not a `null Register' the packet 1229 is forwarded according to the created state. Else, 1231 2 If the `PMBR' field for the corresponding (S,G) 1232 entry matches the source of the Register packet, and 1233 the received Register is not a `null Register', the 1234 decapsulated packet is forwarded to the oif list of 1235 that entry. Else, 1237 3 The packet is dropped, and a Register-stop is 1238 triggered towards the source of the Register. 1240 The (S,G) Entry-timer is restarted by Registers arriving from 1241 that source to that group. 1243 2 If the matching (S,G) or (*,G) state contains a null oif 1244 list, the RP unicasts a Register-Stop message to the source of 1245 the Register message; in the latter case, the source-address 1246 field, within the Register-Stop message, is set to the wildcard 1247 value (all 0's). This message is not processed by intermediate 1248 routers, hence no (S,G) state is constructed between the RP and 1249 the source. 1251 3 If the Register message arrival rate warrants it and there 1252 is no existing (S,G) entry, the RP sets up a (S,G) route entry 1253 with the outgoing interface list, excluding iif(S,G), copied 1254 from the (*,G) outgoing interface list, its SPT-bit is 1255 initialized to 0. If a (*,G) entry does not exist, but there 1256 exists a (*,*,RP) entry with the RP corresponding to G , the oif 1257 list for (S,G) is copied - excluding the iif - from that 1258 (*,*,RP) entry. 1260 A timer (Entry-timer) is set for the (S,G) entry and this timer 1261 is restarted by receipt of data packets for (S,G). The (S,G) 1262 entry causes the RP to send a Join/Prune message for the 1263 indicated group towards the source of the register message. 1265 If the (S,G) oif list becomes null, Join/Prune messages will not 1266 be sent towards the source, S. 1268 3.4 Multicast Data Packet Forwarding 1270 Processing a multicast data packet involves the following steps: 1272 1 Lookup route state based on a longest match of the source 1273 address, and an exact match of the destination address in the 1274 data packet. If neither S, nor G, find a longest match entry, 1275 and the RP for the packet's destination group address has a 1276 corresponding (*,*,RP) entry, then the longest match does not 1277 require an exact match on the destination group address. In 1278 summary, the longest match is performed in the following order: 1279 (1) (S,G), (2) (*,G). If neither is matched, then a lookup is 1280 performed on (*,*,RP) entries. 1282 2 If the packet arrived on the interface found in the 1283 matching-entry's iif field, and the oif list is not null: 1285 1 Forward the packet to the oif list for that entry, 1286 excluding the subnet containing S, and restart the Entry- 1287 timer if the matching entry is (S,G). Optionally, the 1288 (S,G) Entry-timer may be restarted by periodic checking of 1289 the matching packet count. 1291 2 If the entry is a (S,G) entry with a cleared SPT-bit, 1292 and a (*,G) or associated (*,*,RP) also exists whose 1293 incoming interface is different than that for (S,G), set 1294 the SPT-bit for the (S,G) entry and trigger an (S,G) RPT- 1295 bit prune towards the RP. 1297 If the receiving router is the RP, a register stop SHOULD 1298 be sent to the DR, indicating the native SP-tree path between 1299 the source and the RP has already be setup. 1301 3 If the source of the packet is a directly-connected 1302 host and the router is the DR on the receiving interface, 1303 check the Register-Suppression-timer associated with the 1304 (S,G) entry. If it is not running, then the router 1305 encapsulates the data packet in a register message and 1306 sends it to the RP. 1308 This covers the common case of a packet arriving on the RPF 1309 interface to the source or RP and being forwarded to all 1310 joined branches. It also detects when packets arrive on the 1311 SP-tree, and triggers their pruning from the RP-tree. If it 1312 is the DR for the source, it sends data packets 1313 encapsulated in Registers to the RPs. 1315 3 If the packet matches to an entry but did not arrive on the 1316 interface found in the entry's iif field, check the SPT-bit 1317 of the entry. If the SPT-bit is set, drop the packet. If 1318 the SPT-bit is cleared, then lookup the (*,G), or (*,*,RP), 1319 entry for G. If the packet arrived on the iif found in 1320 (*,G), or the corresponding (*,*,RP), forward the packet to 1321 the oif list of the matching entry. This covers the case 1322 when a data packet matches on a (S,G) entry for which the 1323 SP-tree has not yet been completely established upstream. 1325 4 If the packet does not match any entry, but the source of 1326 the data packet is a local, directly-connected host, and 1327 the router is the DR on a multi-access LAN and has RP-Set 1328 information, the DR uses the hash function to determine the 1329 RP associated with the destination group, G. The DR creates 1330 a (S,G) entry, with the Register-Suppression-timer not 1331 running, encapsulates the data packet in a Register message 1332 and unicasts it to the RP. 1334 5 If a packet is received from S on the RPF interface to S, and 1335 there is existing (*,G) but no (S,G) state, the implementation 1336 MUST guarantee that packets from this source are not forwarded 1337 via the RP Tree onto the source subnet. In the absence of 1338 other efficient mechanisms to enforce this, an implementation 1339 in this situation MAY create (S,G) state with an outgoing 1340 interface list of null, and discard the packet. 1342 3.4.1 Data triggered switch to shortest path tree (SP-tree) 1344 Different criteria can be applied to trigger switching over from the 1345 RP-based shared tree to source-specific, shortest path trees. 1347 One proposed example is to do so based on data rate. For example, 1348 when a (*,G), or corresponding (*,*,RP), entry is created, a data 1349 rate counter may be initiated at the last-hop routers. The counter 1350 is incremented with every data packet received for directly connected 1351 members of an SM group, if the longest match is (*,G) or (*,*,RP). If 1352 and when the data rate for the group exceeds a certain configured 1353 threshold (t1), the router initiates `source-specific' data rate 1354 counters for the following data packets. Then, each counter for a 1355 source, is incremented when packets matching on (*,G), or (*,*,RP), 1356 are received from that source. If the data rate from the particular 1357 source exceeds a configured threshold (t2), a (S,G) entry is created 1358 and a Join/Prune message is sent towards the source. If the RPF 1359 interface for (S,G) is not the same as that for (*,G) -or (*,*,RP), 1360 then the SPT-bit is cleared in the (S,G) entry. 1362 Other configured rules may be enforced to cause or prevent 1363 establishment of (S,G) state. 1365 3.5 Assert 1367 Asserts are used to resolve which of the parallel routers connected 1368 to a multi-access LAN is responsible for forwarding packets onto the 1369 LAN. 1371 3.5.1 Sending Asserts 1373 The following Assert rules are provided when a multicast packet is 1374 received on an outgoing multi-access interface "I" of an existing 1375 active (S,G), (*,G) or (*,*,RP) entry: 1377 1 Do unicast routing table lookup on source address from data 1378 packet for (S,G) and do lookup on the RP if matching on (*,G) 1379 or (*,*,RP) entry. Send assert on interface "I", include source 1380 address in data packet; include metric preference of routing 1381 protocol and metric from routing table lookup. 1383 2 If route is not found, use metric preference of 0x7fffffff 1384 and metric 0xffffffff. 1386 When an assert is sent for a (*,G) entry, the first bit in the metric 1387 preference (the RPT-bit) is set to 1, indicating the data packet is 1388 routed down the RP-tree. 1390 Asserts should be rate-limited in an implementation-specific manner. 1392 3.5.2 Receiving Asserts 1394 When an Assert is received the router performs a longest match on the 1395 source and group address in the Assert message, only active entries 1396 -- that have packet forwarding state -- are matched. The router 1397 checks the first bit of the metric preference (RPT-bit). 1399 1 If the RPT-bit is set, the router first does a match on 1400 (*,G), or (*,*,RP), entries; if no matching entry is found, it 1401 ignores the Assert. 1403 2 If the RPT-bit is not set in the Assert, the router first 1404 does a match on (S,G) entries; if no matching entry is found, 1405 the router matches (*,G) or (*,*,RP) entries. 1407 Receiving Asserts on an entry's outgoing interface: 1409 If the interface that received the Assert message is in the oif 1410 list of the matched entry, then this Assert is processed by this 1411 router as follows: 1413 1 If the Assert's RPT-bit is set and the matching entry is 1414 (*,*,RP), the router creates a (*,G) entry. If the Assert's 1415 RPT-bit is cleared and the matching entry is (*,G), or (*,*,RP), 1416 the router creates a (S,G)RPT-bit entry. Otherwise, no new 1417 entry is created in response to the Assert. 1419 2 The router then compares the metric values received in the 1420 Assert with the metric values associated with the matched entry. 1421 The RPT-bit and metric preference (in that order) are treated as 1422 the high-order part of an Assert metric comparison. If the value 1423 in the Assert is less than the router's value (with ties broken 1424 by the IP address, where higher network layer address wins), 1425 delete the interface from the entry. The Entry-timer for the 1426 affected entries is restarted. 1428 3 If the router has won the election the router keeps the 1429 interface in its outgoing interface list. It acts as the 1430 forwarder for the LAN. 1432 The winning router sends an Assert message containing its own metric 1433 to that outgoing interface. This will cause other routers on the LAN 1434 to prune that interface from their route entries. The winning router 1435 sets the RPT-bit in the Assert message if a (*,G) or (S,G)RPT-bit 1436 entry was matched. 1438 Receiving Asserts on an entry's incoming interface 1440 If the Assert arrived on the incoming interface of an existing (S,G), 1441 (*,G), or (*,*,RP) entry, the Assert is processed as follows. 1442 If a longest match lookup does not find any entry, the Assert is 1443 ignored. If the longest match lookup found an entry for the Assert 1444 message, then: 1446 1 Downstream routers will select the upstream router with the 1447 smallest metric preference and metric as their RPF neighbor. If 1448 two metrics are the same, the highest network layer address is 1449 chosen to break the tie. This is important so that downstream 1450 routers send subsequent Joins/Prunes (in SM) to the correct 1451 neighbor. An Assert-timer is initiated when changing the RPF 1452 neighbor to the Assert winner. When the timer expires, the 1453 router resets its RPF neighbor according to its unicast routing 1454 tables to capture network dynamics and router failures. 1456 2 If the downstream routers have downstream members, and if 1457 the Assert caused the RPF neighbor to change, the downstream 1458 routers must trigger a Join/Prune message to inform the upstream 1459 router that packets are to be forwarded on the multi-access 1460 network. 1462 3.6 Candidate-RP-Advertisements and Bootstrap messages 1464 Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM messages 1465 unicast to the BSR by those routers that are configured as 1466 Candidate-RPs (C-RPs). 1468 Bootstrap messages are periodic PIM messages originated by the 1469 Bootstrap router (BSR) within a domain, and forwarded hop-by-hop to 1470 distribute the current RP-set to all routers in that domain. 1472 The Bootstrap messages also support a simple mechanism by which the 1473 Candidate BSR (C-BSR) with the highest BSR-priority and address 1474 (referred to as the preferred BSR) is elected as the BSR for the 1475 domain. We recommend that each router configured as a C-RP also be 1476 configured as a C-BSR. Sections 3.6.2 and 3.6.3 describe the combined 1477 function of Bootstrap messages as the vehicle for BSR election and 1478 RP-Set distribution. 1480 A Finite State Machine description of the BSR election and RP-Set 1481 distribution mechanisms is included in Appendix II. 1483 3.6.1 Sending Candidate-RP-Advertisements 1485 C-RPs periodically unicast C-RP-Advs to the BSR for that domain. The 1486 interval for sending these messages is subject to local configuration 1487 at the C-RP. 1489 Candidate-RP-Advertisements carry group address and group mask 1490 fields. This enables the advertising router to limit the 1491 advertisement to certain prefixes or scopes of groups. The 1492 advertising router may enforce this scope acceptance when receiving 1493 Registers or Join/Prune messages. C-RPs should send C-RP-Adv 1494 messages with the `Priority' field set to `0'. 1496 3.6.2 Receiving C-RP-Advs and Originating Bootstrap 1498 Upon receiving a C-RP-Adv, a router does the following: 1500 1 If the router is not the elected BSR, it ignores the 1501 message, else 1503 2 The BSR adds the RP address to its local pool of candidate 1504 RPs, according to the associated group prefix(es) in the C-RP- 1505 Adv message. The Holdtime in the C-RP-Adv message is also stored 1506 with the corresponding RP, to be included later in the Bootstrap 1507 message. The BSR may apply a local policy to limit the number of 1508 Candidate RPs included in the Bootstrap message. The BSR may 1509 override the prefix indicated in a C-RP-Adv unless the 1510 `Priority' field is not zero. 1512 The BSR keeps an RP-timer per RP in its local RP-set. The RP-timer is 1513 initialized to the Holdtime in the RP's C-RP-Adv. When the timer 1514 expires, the corresponding RP is removed from the RP-set. The RP- 1515 timer is restarted by the C-RP-Advs from the corresponding RP. 1517 The BSR also uses its Bootstrap-timer to periodically send Bootstrap 1518 messages. In particular, when the Bootstrap-timer expires, the BSR 1519 originates a Bootstrap message on each of its PIM interfaces. To 1520 reduce the bootstrap message overhead during partition healing, the 1521 BSR should set a random time (as a function of the priority and 1522 address) after which the Bootstrap message is originated only if no 1523 other preferred Bootstrap message is received. For details see 1524 appendix 6.2. The message is sent with a TTL of 1 to the `ALL-PIM- 1525 ROUTERS' group. In steady state, the BSR originates Bootstrap 1526 messages periodically. At startup, the Bootstrap-timer is 1527 initialized to [Bootstrap-Timeout], causing the first Bootstrap 1528 message to be originated only when and if the timer expires. For 1529 timer details, see Section 3.6.3. A DR unicasts a Bootstrap message 1530 to each new PIM neighbor, i.e., after the DR receives the neighbor's 1531 Hello message (it does so even if the new neighbor becomes the DR). 1533 The Bootstrap message is subdivided into sets of group-prefix,RP- 1534 Count,RP-addresses. For each RP-address, the corresponding Holdtime 1535 is included in the "RP-Holdtime" field. The format of the Bootstrap 1536 message allows `semantic fragmentation', if the length of the 1537 original Bootstrap message exceeds the packet maximum boundaries (see 1538 Section 4). However, we recommend against configuring a large number 1539 of routers as C-RPs, to reduce the semantic fragmentation required. 1541 3.6.3 Receiving and Forwarding Bootstrap 1543 Each router keeps a Bootstrap-timer, initialized to [Bootstrap- 1544 Timeout] at startup. 1546 When a router receives Bootstrap message sent to `ALL-PIM-ROUTERS' 1547 group, it performs the following: 1549 1 If the message was not sent by the RPF neighbor towards the 1550 BSR address included, the message is dropped. Else 1552 2 If the included BSR is not preferred over, and not equal 1553 to, the currently active BSR: 1555 1 If the Bootstrap-timer has not yet expired, or if the 1556 receiving router is a C-BSR, then the Bootstrap message is 1557 dropped. Else 1559 2 If the Bootstrap-timer has expired and the receiving 1560 router is not a C-BSR, the receiving router stores the RP- 1561 Set and BSR address and priority found in the message, and 1562 restarts the timer by setting it to [Bootstrap-Timeout]. 1563 The Bootstrap message is then forwarded out all PIM 1564 interfaces, excluding the one over which the message 1565 arrived, to `ALL-PIM-ROUTERS' group, with a TTL of 1. 1567 3 If the Bootstrap message includes a BSR address that is 1568 preferred over, or equal to, the currently active BSR, the 1569 router restarts its Bootstrap-timer at [Bootstrap-Timeout] 1570 seconds. and stores the BSR address and RP-Set information. 1572 The Bootstrap message is then forwarded out all PIM interfaces, 1573 excluding the one over which the message arrived, to `ALL-PIM- 1574 ROUTERS' group, with a TTL of 1. 1576 4 If the receiving router has no current RP set information 1577 and the Bootstrap was unicast to it from a directly connected 1578 neighbor, the router stores the information as its new RP-set. 1579 This covers the startup condition when a newly booted router 1580 obtains the RP-Set and BSR address from its DR. 1582 When a router receives a new RP-Set, it checks if each of the RPs 1583 referred to by existing state (i.e., by (*,G), (*,*,RP), or 1584 (S,G)RPT-bit entries) is in the new RP-Set. If an RP is not in the 1585 new RP-set, that RP is considered unreachable and the hash algorithm 1586 (see below) is re-performed for each group with locally active state 1587 that previously hashed to that RP. This will cause those groups to be 1588 distributed among the remaining RPs. When the new RP-Set contains a 1589 new RP, the value of the new RP is calculated for each group covered 1590 by that C-RP's Group-prefix. Any group for which the new RP's value 1591 is greater than the previously active RP's value is switched over to 1592 the new RP. 1594 3.7 Hash Function 1596 The hash function is used by all routers within a domain, to map a 1597 group to one of the C-RPs from the RP-Set. For a particular group, G, 1598 the hash function uses only those C-RPs whose Group-prefix covers G. 1599 The algorithm takes as input the group address, and the addresses of 1600 the Candidate RPs, and gives as output one RP address to be used. 1602 The protocol requires that all routers hash to the same RP within a 1603 domain (except for transients). The following hash function must be 1604 used in each router: 1606 1 For RP addresses in the RP-Set, whose Group-prefix is the longest 1607 that covers G, select the RPs with the highest priority (i.e. 1608 lowest `Priority' value), and compute a value: 1610 Value(G,M,C(i))= 1611 (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31 1613 where C_i is the RP address and M is a hash-mask included in 1614 Bootstrap messages. The hash-mask allows a small number of 1615 consecutive groups (e.g., 4) to always hash to the same RP. For 1616 instance, hierarchically-encoded data can be sent on consecutive 1617 group addresses to get the same delay and fate-sharing 1618 characteristics. 1620 For address families other than IPv4, a 32-bit digest to be used 1621 as C_i must first be derived from the actual RP address. Such a 1622 digest method must be used consistently throughout the PIM 1623 domain. For IPv6 addresses, we recommend using the equivalent 1624 IPv4 address for an IPv4-compatible address, and the CRC-32 1625 checksum [7] of all other IPv6 addresses. 1627 2 From the RPs with the highest priority (i.e. lowest 1628 `Priority' value), the candidate with the highest resulting 1629 value is then chosen as the RP for that group, and its identity 1630 and hash value are stored with the entry created. 1632 Ties between RPs having the same hash value and priority, are 1633 broken in advantage of the highest address. 1635 The hash function algorithm is invoked by a DR, upon reception of a 1636 packet, or IGMP membership indication, for a group, for which the DR 1637 has no entry. It is invoked by any router that has (*,*,RP) state 1638 when a packet is received for which there is no corresponding (S,G) 1639 or (*,G) entry. Furthermore, the hash function is invoked by all 1640 routers upon receiving a (*,G) or (*,*,RP) Join/Prune message. 1642 3.8 Processing Timer Events 1644 In this subsection, we enumerate all timers that have been discussed 1645 or implied. Since some critical timer events are not associated with 1646 the receipt or sending of messages, they are not fully covered by 1647 earlier subsections. 1649 Timers are implemented in an implementation-specific manner. For 1650 example, a timer may count up or down, or may simply expire at a 1651 specific time. Setting a timer to a value T means that it will expire 1652 after T seconds. 1654 3.8.1 Timers related to tree maintenance 1656 Each (S,G), (*,G), and (*,*,RP) route entry has multiple timers 1657 associated with it: one for each interface in the outgoing interface 1658 list, one for the multicast routing entry itself, and one optional 1659 Join/Prune-Suppression-Timer. Each (S,G) and (*,G) entry also has an 1660 Assert-timer and a Random-Delay-Join-Timer for use with Asserts. In 1661 addition, DR's have a Register-Suppression-timer for each (S,G) entry 1662 and every router has a single Join/Prune-timer. (A router may 1663 optionally keep separate Join/Prune-timers for different interfaces 1664 or route entries if different Join/Prune periods are desired.) 1666 * [Join/Prune-Timer] This timer is used for periodically 1667 sending aggregate Join/Prune messages. To avoid 1668 synchronization among routers booting simultaneously, it is 1669 initially set to a random value between 1 and [Join/Prune- 1670 Period]. When it expires, the timer is immediately restarted 1671 to [Join/Prune-Period]. A Join/Prune message is then sent out 1672 each interface. This timer should not be restarted by other 1673 events. 1675 * [Join/Prune-Suppression-Timer (kept per route entry)] A 1676 route entry's (optional) Join/Prune-Suppression-Timer may be 1677 used to suppress duplicate joins from multiple downstream 1678 routers on the same LAN. When a Join message is received from 1679 a neighbor on the entry's incoming interface in which the 1680 included Holdtime is higher than the router's own 1681 [Join/Prune-Holdtime] (with ties broken by higher network 1682 layer address), the timer is set to [Join/Prune-Suppression- 1683 Timeout], with some random jitter introduced to avoid 1684 synchronization of triggered Join/Prune messages on 1685 expiration. (The random timeout value must be < 1.5 * 1686 [Join/Prune-Period] to prevent losing data after 2 dropped 1687 Join/Prunes.) The timer is restarted every time a subsequent 1688 Join/Prune message (with higher Holdtime/IP address) for the 1689 entry is received on its incoming interface. While the timer 1690 is running, Join/Prune messages for the entry are not sent. 1691 This timer is idle (not running) for point-to-point links. 1693 * [Oif-Timer (kept per oif for each route entry)] A timer for 1694 each oif of a route entry is used to time out that oif. 1695 Because some of the outgoing interfaces in an (S,G) entry are 1696 copied from the (*,G) outgoing interface list, they may not 1697 have explicit (S,G) join messages from some of the downstream 1698 routers (i.e., where members are joining to the (*,G) tree 1699 only). Thus, when an Oif-timer is restarted in a (*,G) entry, 1700 the Oif-timer is restarted for that interface in each existing 1701 (S,G) entry whose oif list contains that interface. The same 1702 rule applies to (*,G) and (S,G) entries when restarting an 1703 Oif-timer on a (*,*,RP) entry. 1705 The following table shows its usage when first adding the oif 1706 to the entry's oiflist, when it should be restarted (unless it 1707 is already higher), and when it should be decreased (unless it 1708 is already lower). 1710 Set to | When | Applies to 1711 included Holdtime | adding oif off Join/Prune | (S,G) (*,G) 1712 | | (*,*,RP) 1714 Increased (only) to | When | Applies to 1715 included Holdtime | received Join/Prune | (S,G) (*,G) 1716 | | (*,*,RP) 1717 (*,*,RP) oif-timer value | (*,*,RP) oif-timer restarted | (S,G) (*,G) 1718 (*,G) oif-timer value | (*,G) oif-timer restarted | (S,G) 1719 When the timer expires, the oif is removed from the oiflist, 1720 if there are no directly-connected members. When the deletion occurs 1721 for a (*,G) or (*,*,RP) entry , the interface is also deleted 1722 from any associated (S,G)RPT-bit or (*,G) entries, respectively. 1723 The Entry-timer for the affected entries is restarted. 1725 * [Entry-Timer (kept per route entry)] A timer for each route 1726 entry is used to time out that entry. The following table 1727 summarizes its usage when first adding the oif to the entry's 1728 oiflist, and when it should be restarted (unless it is already 1729 higher). 1731 Set to | When | Applies to 1732 [Data-Timeout] | created off data packet | (S,G) 1733 included Holdtime | created off Join/Prune | (S,G) (*,G) (*,*,RP) 1735 Increased (only) to | When | Applies to 1736 [Data-Timeout] | receiving data packets | (S,G)no RPT-bit 1737 oif-timer value | any oif-timer restarted | (S,G)RPT-bit (*,G) 1738 | | (*,*,RP) 1739 [Assert-Timeout] | assert received | (S,G)RPT-bit (*,G) 1740 | | w/null oif 1742 When the timer expires, the route entry is deleted; if the 1743 entry is a (*,G) or (*,*,RP) entry, all associated (S,G)RPT- 1744 bit entries are also deleted. 1746 * [Register-Suppression-Timer (kept per (S,G) route entry)] 1747 An (S,G) route entry's Register-Suppression-Timer is used to 1748 suppress registers when the RP is receiving data packets 1749 natively. When a Register-Stop message for the entry is 1750 received from the RP, the timer is set to a random value in 1751 the range 0.5 * [Register-Suppression-Timeout] to 1.5 * 1752 [Register-Suppression-Timeout]. While the timer is running, 1753 Registers for that entry will be suppressed. If null 1754 registers are used, a null register is sent [Probe-Time] 1755 seconds before the timer expires. 1757 * [Assert-Timer (per (S,G) or (*,G) route entry)] The 1758 Assert-Timer for an (S,G) or (*,G) route entry is used for 1759 timing out Asserts received. When an Assert is received and 1760 the RPF neighbor is changed to the Assert winner, the Assert- 1761 Timer is set to [Assert-Timeout], and is restarted to this 1762 value every time a subsequent Assert for the entry is received 1763 on its incoming interface. When the timer expires, the router 1764 resets its RPF neighbor according to its unicast routing 1765 table. 1767 * [Random-Delay-Join-Timer (per (S,G) or (*,G) route entry)] 1768 The Random-Delay-Join-Timer for an (S,G) or (*,G) route entry 1769 is used to prevent synchronization among downstream routers on 1770 a LAN when their RPF neighbor changes. When the RPF neighbor 1771 changes, this timer is set to a random value between 0 and 1772 [Random-Delay-Join-Timeout] seconds. When the timer expires, a 1773 triggered Join/Prune message is sent for the entry unless its 1774 Join/Prune-Suppression-Timer is running. 1776 3.8.2 Timers relating to neighbor discovery 1778 * [Hello-Timer] This timer is used to periodically send Hello 1779 messages. To avoid synchronization among routers booting 1780 simultaneously, it is initially set to a random value between 1781 1 and [Hello-Period]. When it expires, the timer is 1782 immediately restarted to [Hello-Period]. A Hello message is 1783 then sent out each interface. This timer should not be 1784 restarted by other events. 1786 * [Neighbor-Timer (kept per neighbor)] A Neighbor-Timer for 1787 each neighbor is used to time out the neighbor state. When a 1788 Hello message is received from a new neighbor, the timer is 1789 initially set to the Holdtime included in the Hello message 1790 (which is equal to the neighbor's value of [Hello-Holdtime]). 1791 Every time a subsequent Hello is received from that neighbor, 1792 the timer is restarted to the Holdtime in the Hello. When the 1793 timer expires, the neighbor state is removed. 1795 3.8.3 Timers relating to RP information 1797 * [C-RP-Adv-Timer (C-RP's only)] Routers configured as 1798 candidate RP's use this timer to periodically send C-RP-Adv 1799 messages. To avoid synchronization among routers booting 1800 simultaneously, the timer is initially set to a random value 1801 between 1 and [C-RP-Adv-Period]. When it expires, the timer is 1802 immediately restarted to [C-RP-Adv-Period]. A C-RP-Adv message 1803 is then sent to the elected BSR. This timer should not be 1804 restarted by other events. 1806 * [RP-Timer (BSR only, kept per RP in RP-Set)] The BSR uses a 1807 timer per RP in the RP-Set to monitor liveness. When a C-RP is 1808 added to the RP-Set, its timer is set to the Holdtime included 1809 in the C-RP-Adv message from that C-RP (which is equal to the 1810 C-RP's value of [RP-Holdtime]). Every time a subsequent C-RP- 1811 Adv is received from that RP, its timer is restarted to the 1812 Holdtime in the C-RP-Adv. When the timer expires, the RP is 1813 removed from the RP-Set included in Bootstrap messages. 1815 * [Bootstrap-Timer] This timer is used by the BSR to 1816 periodically originate Bootstrap messages, and by other 1817 routers to time out the BSR (see 3.6.3). This timer is 1818 initially set to [Bootstrap-Timeout]. A C-BSR restarts this 1819 timer to [Bootstrap-Timeout] upon receiving a Bootstrap 1820 message from a preferred router, and originates a Bootstrap 1821 message and restarts the timer to [Bootstrap-Period] when it 1822 expires. Routers not configured as C-BSR's restart this timer 1823 to [Bootstrap-Timeout] upon receiving a Bootstrap message from 1824 the elected or a more preferred BSR, and ignore Bootstrap 1825 messages from non-preferred C-BSRs while it is running. 1827 3.8.4 Default timer values 1829 Most of the default timeout values for state information are 3.5 1830 times the refresh period. For example, Hellos refresh Neighbor state 1831 and the default Hello-timer period is 30 seconds, so a default 1832 Neighbor-timer duration of 105 seconds is included in the Holdtime 1833 field of the Hellos. In order to improve convergence, however, the 1834 default timeout value for information related to RP liveness and 1835 Bootstrap messages is 2.5 times the refresh period. 1837 In this version of the spec, we suggest particular numerical timer 1838 settings. A future version of the specification will specify a 1839 mechanism for timer values to be scaled based upon observed network 1840 parameters. 1842 * [Join/Prune-Period] This is the interval between 1843 sending Join/Prune messages. Default: 60 seconds. This value 1844 may be set to take into account such things as the configured 1845 bandwidth and expected average number of multicast route 1846 entries for the attached network or link (e.g., the period 1847 would be longer for lower-speed links, or for routers in the 1848 center of the network that expect to have a larger number of 1849 entries). In addition, a router could modify this value (and 1850 corresponding Join/Prune-Holdtime value) if the number of 1851 route entries changes significantly (e.g., by an order of 1852 magnitude). For example, given a default minimum Join/Prune- 1853 Period value, if the number of route entries with a particular 1854 iif increases from N to N*100, the router could increase its 1855 Join/Prune-Period (and Join/Prune-Holdtime), for that 1856 interface, by a factor of 10; and if/when the number of 1857 entries decreases back to N, the Join/Prune-Period (and 1858 Join/Prune-Holdtime) could be decreased to its previous value. 1859 If the Join/Prune-Period is modified, these changes should be 1860 made relatively infrequently and the router should continue to 1861 refresh at its previous Join/Prune-Period for at least 1862 Join/Prune-Holdtime, in order to allow the upstream router to 1863 adapt. 1865 * [Join-Prune Holdtime] This is the Holdtime specified in 1866 Join/Prune messages, and is used to time out oifs. This should 1867 be set to 3.5 * [Join/Prune-Period]. Default: 210 seconds. 1869 * [Join/Prune-Suppression-Timeout] This is the mean 1870 interval between receiving a Join/Prune with a higher Holdtime 1871 (with ties broken by higher network layer address) and 1872 allowing duplicate Join/Prunes to be sent again. This should 1873 be set to approximately 1.25 * [Join/Prune-Period]. Default: 1874 75 seconds. 1876 * [Data-Timeout] This is the time after which (S,G) state 1877 for a silent source will be deleted. Default: 210 seconds. 1879 * [Register-Suppression-Timeout] This is the mean 1880 interval between receiving a Register-Stop and allowing 1881 Registers to be sent again. A lower value means more frequent 1882 register bursts at RP, while a higher value means longer join 1883 latency for new receivers. Default: 60 seconds. (Note that 1884 if null Registers are sent [Probe-Time] seconds before the 1885 timeout, register bursts are prevents, and [Register- 1886 Suppression-Timeout] may be lowered to decrease join latency.) 1888 * [Probe-Time] When null Registers are used, this is the 1889 time between sending a null Register and the Register- 1890 Suppression-Timer expiring unless it is restarted by receiving 1891 a Register-Stop. Thus, a null Register would be sent when the 1892 Register-Suppression-Timer reaches this value. Default: 5 1893 seconds. 1895 * [Assert-Timeout] This is the interval between the last 1896 time an Assert is received, and the time at which the assert 1897 is timed out. Default: 180 seconds. 1899 * [Random-Delay-Join-Timeout] This is the maximum 1900 interval between the time when the RPF neighbor changes, and 1901 the time at which a triggered Join/Prune message is sent. 1902 Default: 4.5 seconds. 1904 * [Hello-Period] This is the interval between sending 1905 Hello messages. Default: 30 seconds. 1907 * [Hello-Holdtime] This is the Holdtime specified in 1908 Hello messages, after which neighbors will time out their 1909 neighbor entries for the router. This should be set to 3.5 * 1910 [Hello-Period]. Default: 105 seconds. 1912 * [C-RP-Adv-Period] For C-RPs, this is the interval 1913 between sending C-RP-Adv messages. Default: 60 seconds. 1915 * [RP-Holdtime] For C-RPs, this is the Holdtime specified 1916 in C-RP-Adv messages, and is used by the BSR to time out RPs. 1917 This should be set to 2.5 * [C-RP-Adv-Period]. Default: 150 1918 seconds. 1920 * [Bootstrap-Period] At the elected BSR, this is the 1921 interval between originating Bootstrap messages, and should be 1922 equal to 60 seconds. 1924 * [Bootstrap-Timeout] This is the time after which the 1925 elected BSR will be assumed unreachable when Bootstrap 1926 messages are not received from it. This should be set to `2 * 1927 [Bootstrap-Period] + 10'. Default: 130 seconds. 1929 3.9 Summary of flags used 1931 delete the interface from the entry. When the deletion occurs 1932 for a (*,G) or (*,*,RP) entry , the interface is also deleted 1933 from any associated (S,G)RPT-bit or (*,G) entries, respectively. 1934 The Entry-timer for the affected entries is restarted. 1935 Following is a summary of all the flags used in our scheme. 1937 Bit | Used in | Definition 1939 Border | Register | Register for external sources is coming 1940 from PIM multicast border router 1941 Null | Register | Register sent as Probe of RP, the 1942 encapsulated IP data packet should not 1943 be forwarded 1944 RPT | Route entry | Entry represents state on the RP-tree 1945 RPT | Join/Prune | Join is associated with the shared tree and 1946 therefore the Join/Prune message is 1947 propagated along the RP-tree (source 1948 encoded is an RP address) 1949 RPT | Assert | The data packet was routed down the shared 1950 tree; thus, the path indicated corresponds 1951 to the RP tree 1952 SPT | (S,G) entry | Packets have arrived on the iif towards 1953 S, and the iif is different from the 1954 (*,G) iif 1955 WC |Join | The receiver expects to receive packets 1956 from all sources via this (shared tree) 1957 path. Thus, the Join/Prune applies to a 1958 (*,G) entry 1959 WC | Route entry | Wildcard entry; if there is no more 1960 specific match for a particular source, 1961 packets will be forwarded according to 1962 this entry 1964 4 Packet Formats 1966 This section describes the details of the packet formats for PIM 1967 control messages. 1969 All PIM control messages have protocol number 103. 1971 Basically, PIM messages are either unicast (e.g. Registers and 1972 Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group 1973 `224.0.0.13' (e.g. Join/Prune, Asserts, etc.). 1975 0 1 2 3 1976 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 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 |PIM Ver| Type | Reserved | Checksum | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 PIM Ver 1982 PIM Version number is 2. 1984 Type Types for specific PIM messages. PIM Types are: 1986 0 = Hello 1987 1 = Register 1988 2 = Register-Stop 1989 3 = Join/Prune 1990 4 = Bootstrap 1991 5 = Assert 1992 6 = Graft (used in PIM-DM only) 1993 7 = Graft-Ack (used in PIM-DM only) 1994 8 = Candidate-RP-Advertisement 1996 Reserved 1997 set to zero. Ignored upon receipt. 1999 Checksum 2000 The checksum is the 16-bit one's complement of the one's 2001 complement sum of the entire PIM message, (excluding the 2002 data portion in the Register message). For computing the 2003 checksum, the checksum field is zeroed. 2005 4.1 Encoded Source and Group Address formats 2007 1 Encoded-Unicast-address: Takes the following format: 2009 0 1 2 3 2010 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 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | Addr Family | Encoding Type | Unicast Address | 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++ 2015 Addr Family 2016 The address family of the `Unicast Address' field of 2017 this address. 2019 Here is the address family numbers assigned by IANA: 2021 Number Description 2022 -------- --------------------------------------------------------- 2023 0 Reserved 2024 1 IP (IP version 4) 2025 2 IP6 (IP version 6) 2026 3 NSAP 2027 4 HDLC (8-bit multidrop) 2028 5 BBN 1822 2029 6 802 (includes all 802 media plus Ethernet "canonical format") 2030 7 E.163 2031 8 E.164 (SMDS, Frame Relay, ATM) 2032 9 F.69 (Telex) 2033 10 X.121 (X.25, Frame Relay) 2034 11 IPX 2035 12 Appletalk 2036 13 Decnet IV 2037 14 Banyan Vines 2038 15 E.164 with NSAP format subaddress 2040 Encoding Type 2041 The type of encoding used within a specific Address 2042 Family. The value `0' is reserved for this field, 2043 and represents the native encoding of the Address 2044 Family. 2046 Unicast Address 2047 The unicast address as represented by the given 2048 Address Family and Encoding Type. 2050 2 Encoded-Group-Address: Takes the following format: 2052 0 1 2 3 2053 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 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | Addr Family | Encoding Type | Reserved | Mask Len | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | Group multicast Address | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 Addr Family 2061 described above. 2063 Encoding Type 2064 described above. 2066 Reserved 2067 Transmitted as zero. Ignored upon receipt. 2069 Mask Len 2070 The Mask length is 8 bits. The value is the number of 2071 contiguous bits left justified used as a mask which 2072 describes the address. It is less than or equal to the 2073 address length in bits for the given Address Family 2074 and Encoding Type. If the message is sent for a single 2075 group then the Mask length must equal the address 2076 length in bits for the given Address Family and 2077 Encoding Type. (e.g. 32 for IPv4 native encoding and 2078 128 for IPv6 native encoding). 2080 Group multicast Address 2081 contains the group address. 2083 3 Encoded-Source-Address: Takes the following format: 2085 0 1 2 3 2086 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 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 | Source Address | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 Addr Family 2094 described above. 2096 Encoding Type 2097 described above. 2099 Reserved 2100 Transmitted as zero, ignored on receipt. 2102 S,W,R See Section 4.5 for details. 2104 Mask Length 2105 Mask length is 8 bits. The value is the number of 2106 contiguous bits left justified used as a mask which 2107 describes the address. The mask length must be less 2108 than or equal to the address length in bits for the 2109 given Address Family and Encoding Type. If the message 2110 is sent for a single group then the Mask length must 2111 equal the address length in bits for the given Address 2112 Family and Encoding Type. In version 2 of PIM, it is 2113 strongly recommended that this field be set to 32 for 2114 IPv4 native encoding. 2116 Source Address 2117 The source address. 2119 4.2 Hello Message 2121 It is sent periodically by routers on all interfaces. 2123 0 1 2 3 2124 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 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 |PIM Ver| Type | Reserved | Checksum | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | OptionType | OptionLength | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | OptionValue | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 2132 | . | 2133 | . | 2134 | . | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | OptionType | OptionLength | 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | OptionValue | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 2141 PIM Version, Type, Reserved, Checksum 2142 Described above. 2144 OptionType 2145 The type of the option given in the following OptionValue 2146 field. 2148 OptionLength 2149 The length of the OptionValue field in bytes. 2151 OptionValue 2152 A variable length field, carrying the value of the option. 2154 The Option fields may contain the following values: 2156 * OptionType = 1; OptionLength = 2; OptionValue = Holdtime; 2157 where Holdtime is the amount of time a receiver must keep the 2158 neighbor reachable, in seconds. If the Holdtime is set to 2159 `0xffff', the receiver of this message never times out the 2160 neighbor. This may be used with ISDN lines, to avoid keeping 2161 the link up with periodic Hello messages. Furthermore, if the 2162 Holdtime is set to `0', the information is timed out 2163 immediately. 2165 * OptionType 2 to 16: reserved 2167 * OptionType = 18; OptionLength = 4; OptionValue = DR Priority; 2168 where DR Priority is a 32-bit unsigned number and SHOULD be 2169 treated as the higher order bits of the address during DR 2170 election. 2172 * OptionType = 19; OptionLength = 0; Bidirectional PIM capable 2174 * OptionType = 20; OptionLength = 4; OptionValue = Generation ID; 2175 where Generation ID is a random 32-bit value generated upon 2176 router startup. 2178 * OptionType = 21; OptionLength = 4; OptionValue = 1; 2179 This is the State Refresh capable option for dense mode. 2181 * The rest of the OptionTypes are defined in another 2182 document. 2184 In general, options may be ignored; but a router must not ignore the 2185 'Holdtime' OptionType. 2187 4.3 Register Message 2189 A Register message is sent by the DR or a PMBR to the RP when a 2190 multicast packet needs to be transmitted on the RP-tree. Source 2191 address is set to the address of the DR, destination address is to 2192 the RP's address. 2194 0 1 2 3 2195 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 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 |PIM Ver| Type | Reserved | Checksum | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 |B|N| Reserved | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | | 2202 Multicast data packet 2203 | | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 PIM Version, Type, Reserved, Checksum 2206 Described above. Note that the checksum for Registers 2207 is done only on first 8 bytes of packet, including the PIM 2208 header and the next 4 bytes, excluding the data packet 2209 portion. For interoperability reasons, a message 2210 carrying checksum done over the entire PIM register message 2211 SHOULD be accepted. 2213 B The Border bit. If the router is a DR for a source that it 2214 is directly connected to, it sets the B bit to 0. If the 2215 router is a PMBR for a source in a directly connected 2216 cloud, it sets the B bit to 1. 2218 N The Null-Register bit. Set to 1 by a DR that is probing 2219 the RP before expiring its local Register-Suppression 2220 timer. Set to 0 otherwise. 2222 Multicast data packet 2223 The original packet sent by the source. 2225 For (S,G) null Registers, the Multicast data packet portion 2226 contains only a dummy header with S as the source address, G as 2227 the destination address, and a data length of zero. 2229 4.4 Register-Stop Message 2231 A Register-Stop is unicast from the RP to the sender of the Register 2232 message. Source address is the address to which the register was 2233 addressed. Destination address is the source address of the register 2234 message. 2236 0 1 2 3 2237 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 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 |PIM Ver| Type | Reserved | Checksum | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Encoded-Group Address | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Encoded-Unicast-Source Address | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 PIM Version, Type, Reserved, Checksum 2247 Described above. 2249 Encoded-Group Address 2250 Format described above. Note that for Register-Stops the 2251 Mask Len field contains full address length * 8 (e.g. 32 2252 for IPv4 native encoding), if the message is sent for a 2253 single group. 2255 Encoded-Unicast-Source Address 2256 host address of source from multicast data packet in 2257 register. The format for this address is given in the 2258 Encoded-Unicast-Address in 4.1. A special wild card value 2259 (0's), can be used to indicate any source. 2261 4.5 Join/Prune Message 2263 A Join/Prune message is sent by routers towards upstream sources and 2264 RPs. Joins are sent to build shared trees (RP trees) or source trees 2265 (SPT). Prunes are sent to prune source trees when members leave 2266 groups as well as sources that do not use the shared tree. 2268 0 1 2 3 2269 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 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 |PIM Ver| Type | Reserved | Checksum | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | Encoded-Unicast-Upstream Neighbor Address | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | Reserved | Num groups | Holdtime | 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | Encoded-Multicast Group Address-1 | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Number of Joined Sources | Number of Pruned Sources | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | Encoded-Joined Source Address-1 | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | . | 2284 | . | 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | Encoded-Joined Source Address-n | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 | Encoded-Pruned Source Address-1 | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 | . | 2291 | . | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | Encoded-Pruned Source Address-n | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 | . | 2296 | . | 2297 | . | 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 | Encoded-Multicast Group Address-n | 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | Number of Joined Sources | Number of Pruned Sources | 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 | Encoded-Joined Source Address-1 | 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 | . | 2306 | . | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | Encoded-Joined Source Address-n | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2310 | Encoded-Pruned Source Address-1 | 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2312 | . | 2313 | . | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | Encoded-Pruned Source Address-n | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 PIM Version, Type, Reserved, Checksum 2319 Described above. 2321 Encoded-Unicast Upstream Neighbor Address 2322 The address of the RPF or upstream neighbor. The format 2323 for this address is given in the Encoded-Unicast-Address in 2324 4.1. .IP "Reserved" 2325 Transmitted as zero, ignored on receipt. 2327 Holdtime 2328 The amount of time a receiver must keep the Join/Prune 2329 state alive, in seconds. If the Holdtime is set to 2330 `0xffff', the receiver of this message never times out the 2331 oif. This may be used with ISDN lines, to avoid keeping the 2332 link up with periodical Join/Prune messages. Furthermore, 2333 if the Holdtime is set to `0', the information is timed out 2334 immediately. 2336 Number of Groups 2337 The number of multicast group sets contained in the 2338 message. 2340 Encoded-Multicast group address 2341 For format description see Section 2342 4.1. A wild card group in the (*,*,RP) join is represented 2343 by a 224.0.0.0 in the group address field and `4' in the 2344 mask length field. A (*,*,RP) join also has the WC-bit and 2345 the RPT-bit set. 2347 Number of Joined Sources 2348 Number of join source addresses listed for a given group. 2350 Join Source Address-1 .. n 2351 This list contains the sources that the sending router 2352 will forward multicast datagrams for if received on the 2353 interface this message is sent on. 2355 See format section 4.1. The fields explanation for the 2356 Encoded-Source-Address format follows: 2358 Reserved 2359 Described above. 2361 S The Sparse bit is a 1 bit value, set to 1 for PIM-SM. 2362 It is used for PIM v.1 compatibility. 2364 W The WC bit is a 1 bit value. If 1, the join or prune 2365 applies to the (*,G) or (*,*,RP) entry. If 0, the join 2366 or prune applies to the (S,G) entry where S is Source 2367 Address. Joins and prunes sent towards the RP must 2368 have this bit set. 2370 R The RPT-bit is a 1 bit value. If 1, the information 2371 about (S,G) is sent towards the RP. If 0, the 2372 information must be sent toward S, where S is the 2373 Source Address. 2375 Mask Length, Source Address 2376 Described above. 2378 Represented in the form of 2379 < WC-bit >< RPT-bit >< Source address>: 2381 A source address could be a host IPv4 native encoding 2382 address : 2384 < 0 >< 0 >< 32 >< 192.1.1.17 > 2386 A source address could be the RP's IP address : 2388 < 1 >< 1 >< 32 >< 131.108.13.111 > 2390 A source address could be a subnet address to prune from 2391 the RP-tree : 2393 < 0 >< 1 >< 28 >< 192.1.1.16 > 2395 A source address could be a general aggregate : 2397 < 0 >< 0 >< 16 >< 192.1.0.0 > 2399 Number of Pruned Sources 2400 Number of prune source addresses listed for a group. 2402 Prune Source Address-1 .. n 2403 This list contains the sources that the sending router 2404 does not want to forward multicast datagrams for when 2405 received on the interface this message is sent on. If the 2406 Join/Prune message boundary exceeds the maximum packet 2407 size, then the join and prune lists for the same group must 2408 be included in the same packet. 2410 4.6 Bootstrap Message 2412 The Bootstrap messages are multicast to `ALL-PIM-ROUTERS' group, out 2413 all interfaces having PIM neighbors (excluding the one over which the 2414 message was received). Bootstrap messages are sent with TTL value of 2415 1. Bootstrap messages originate at the BSR, and are forwarded by 2416 intermediate routers. 2418 Bootstrap message is divided up into `semantic fragments', if the 2419 original message exceeds the maximum packet size boundaries. 2421 The semantics of a single `fragment' is given below: 2423 0 1 2 3 2424 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 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 |PIM Ver| Type | Reserved | Checksum | 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 | Fragment Tag | Hash Mask len | BSR-priority | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | Encoded-Unicast-BSR-Address | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | Encoded-Group Address-1 | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | RP-Count-1 | Frag RP-Cnt-1 | Reserved | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | Encoded-Unicast-RP-Address-1 | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | RP1-Holdtime | RP1-Priority | Reserved | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 | Encoded-Unicast-RP-Address-2 | 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 | RP2-Holdtime | RP2-Priority | Reserved | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 | . | 2445 | . | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Encoded-Unicast-RP-Address-m | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | RPm-Holdtime | RPm-Priority | Reserved | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 | Encoded-Group Address-2 | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 | . | 2454 | . | 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | Encoded-Group Address-n | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | RP-Count-n | Frag RP-Cnt-n | Reserved | 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2460 | Encoded-Unicast-RP-Address-1 | 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 | RP1-Holdtime | RP1-Priority | Reserved | 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 | Encoded-Unicast-RP-Address-2 | 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 | RP2-Holdtime | RP2-Priority | Reserved | 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 | . | 2469 | . | 2470 | . | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | Encoded-Unicast-RP-Address-m | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | RPm-Holdtime | RPm-Priority | Reserved | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 PIM Version, Type, Reserved, Checksum 2478 Described above. 2480 Fragment Tag 2481 A randomly generated number, acts to distinguish the 2482 fragments belonging to different Bootstrap messages; 2483 fragments belonging to same Bootstrap message carry the 2484 same `Fragment Tag'. 2486 Hash Mask len 2487 The length (in bits) of the mask to use in the hash 2488 function. For IPv4 we recommend a value of 30. For IPv6 we 2489 recommend a value of 126. 2491 BSR-priority 2492 Contains the BSR priority value of the included BSR. This 2493 field is considered as a high order byte when comparing BSR 2494 addresses. 2496 Encoded-Unicast-BSR-Address 2497 The address of the bootstrap router for the domain. The 2498 format for this address is given in the Encoded-Unicast- 2499 Address in 4.1. .IP "Encoded-Group Address-1..n" 2500 The group prefix (address and mask) with which the 2501 Candidate RPs are associated. Format previously described. 2503 RP-Count-1..n 2504 The number of Candidate RP addresses included in the whole 2505 Bootstrap message for the corresponding group prefix. A 2506 router does not replace its old RP-Set for a given group 2507 prefix until/unless it receives `RP-Count' addresses for 2508 that prefix; the addresses could be carried over several 2509 fragments. If only part of the RP-Set for a given group 2510 prefix was received, the router discards it, without 2511 updating that specific group prefix's RP-Set. 2513 Frag RP-Cnt-1..m 2514 The number of Candidate RP addresses included in this 2515 fragment of the Bootstrap message, for the corresponding 2516 group prefix. The `Frag RP-Cnt' field facilitates parsing 2517 of the RP-Set for a given group prefix, when carried over 2518 more than one fragment. 2520 Encoded-Unicast-RP-address-1..m 2521 The address of the Candidate RPs, for the corresponding 2522 group prefix. The format for this address is given in the 2523 Encoded-Unicast-Address in 4.1. .IP "RP1..m-Holdtime" 2524 The Holdtime for the corresponding RP. This field is 2525 copied from the `Holdtime' field of the associated RP 2526 stored at the BSR. 2528 RP1..m-Priority 2529 The `Priority' of the corresponding RP and Encoded-Group 2530 Address. This field is copied from the `Priority' field 2531 stored at the BSR when receiving a Candidate-RP- 2532 Advertisement. The highest priority is `0' (i.e. the lower 2533 the value of the `Priority' field, the higher). Note that 2534 the priority is per RP per Encoded-Group Address. 2536 4.7 Assert Message 2538 The Assert message is sent when a multicast data packet is received 2539 on an outgoing interface corresponding to the (S,G) or (*,G) 2540 associated with the source. 2542 0 1 2 3 2543 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 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 |PIM Ver| Type | Reserved | Checksum | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Encoded-Group Address | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | Encoded-Unicast-Source Address | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 |R| Metric Preference | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Metric | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 PIM Version, Type, Reserved, Checksum 2557 Described above. 2559 Encoded-Group Address 2560 The group address to which the data packet was addressed, 2561 and which triggered the Assert. Format previously 2562 described. 2564 Encoded-Unicast-Source Address 2565 Source address from multicast datagram that triggered the 2566 Assert packet to be sent. The format for this address is 2567 given in the Encoded-Unicast-Address in 4.1. .IP "R" 2568 RPT-bit is a 1 bit value. If the multicast datagram that 2569 triggered the Assert packet is routed down the RP tree, 2570 then the RPT-bit is 1; if the multicast datagram is routed 2571 down the SPT, it is 0. 2573 Metric Preference 2574 Preference value assigned to the unicast routing protocol 2575 that provided the route to Host address. 2577 Metric The unicast routing table metric. The metric is in units 2578 applicable to the unicast routing protocol used. 2580 4.8 Graft Message 2582 Used in dense-mode. Refer to PIM dense mode specification. 2584 4.9 Graft-Ack Message 2586 Used in dense-mode. Refer to PIM dense mode specification. 2588 4.10 Candidate-RP-Advertisement 2590 Candidate-RP-Advertisements are periodically unicast from the C-RPs 2591 to the BSR. 2593 0 1 2 3 2594 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 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 |PIM Ver| Type | Reserved | Checksum | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | Prefix-Cnt | Priority | Holdtime | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 | Encoded-Unicast-RP-Address | 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 | Encoded-Group Address-1 | 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 | . | 2605 | . | 2606 | . | 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 | Encoded-Group Address-n | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 PIM Version, Type, Reserved, Checksum 2612 Described above. 2614 Prefix-Cnt 2615 The number of encoded group addresses included in the 2616 message; indicating the group prefixes for which the C-RP 2617 is advertising. A Prefix-Cnt of `0' implies a prefix of 2618 224.0.0.0 with mask length of 4; i.e. all multicast groups. 2619 If the C-RP is not configured with Group-prefix 2620 information, the C-RP puts a default value of `0' in this 2621 field. 2623 Priority 2624 The `Priority' of the included RP, for the corresponding 2625 Encoded-Group Address (if any). highest priority is `0' 2626 (i.e. the lower the value of the `Priority' field, the 2627 higher the priority). This field is stored at the BSR upon 2628 receipt along with the RP address and corresponding 2629 Encoded-Group Address. 2631 Holdtime 2632 The amount of time the advertisement is valid. This field 2633 allows advertisements to be aged out. 2635 Encoded-Unicast-RP-Address 2636 The address of the interface to advertise as a Candidate 2637 RP. The format for this address is given in the Encoded- 2638 Unicast-Address in 4.1. .IP "Encoded-Group Address-1..n" 2639 The group prefixes for which the C-RP is advertising. 2640 Format previously described. 2642 5 Security Considerations 2644 All PIM control messages MAY use IPsec \cite{IPsec} to address security 2645 concerns. The authentication methods are addressed in a companion 2646 document[9]. 2648 6 Acknowledgments 2650 Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul Francis, 2651 Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia 2652 Zhang, Girish Chandranmenon, Rob Coltun and many members of the PIM 2653 WG provided detailed comments on previous drafts. The authors of 2654 CBT [8] and membership of the IDMR WG provided many of the motivating 2655 ideas for this work and useful feedback on design details. 2657 This work was supported by the National Science Foundation, ARPA, 2658 cisco Systems and Sun Microsystems. 2660 7 Appendices 2662 7.1 Appendix I: Major Changes and Updates to the Spec 2664 This appendix populates the major changes in the specification 2665 document as compared to RFC2362. 2667 7.1.1 Major Changes 2669 1 DR priority election option for Hello message; 2671 2 Security Considerations section 2673 3 Hello Geneneration Identifier (GenID) option 2675 4 Section 3.2.1.2.3 (in Triggered Join/Prune messages:). Clarification 2676 on triggered (*,G) join need to be accompanied by (S,G)RPT-bit prunes. 2678 7.1.2 Packet Format Changes 2680 Packet format now includes Hello DR priority election option and 2681 Generation Identifier (GenID) option. 2683 7.2 Appendix II: BSR Election and RP-Set Distribution 2685 For simplicity, the bootstrap message is used in both the BSR 2686 election and the RP-Set distribution mechanisms. These mechanisms 2687 are described by the following state machine, illustrated in figure 2688 4. The protocol transitions for a Candidate-BSR are given in state 2689 diagram (a). For routers not configured as Candidate-BSRs, the 2690 protocol transitions are given in state diagram (b). 2692 PrefBSMRxd;FwdBSM, [1][2][3] TExp;OrigBSM,[4] 2693 / \ / \ 2694 | | _______________________ | | 2695 | \|/ / \ | \|/ 2696 ---------- / \ --------------- 2697 |CandBSR |--- -->| Elected BSR | 2698 | |<--\ ___| | 2699 ---------- \__________________________/ --------------- 2701 Initial state: CandBSR; LclBSR = Local address, LclRP-Set = empty 2703 (a) State transition diagram for a candidate BSR 2705 PrefBSMRxd; FwdBSM,[1][2][3] 2706 / \ 2707 TExp | | 2708 /-----------------------\ | \|/ 2709 ----------- / \ ----------- 2710 | AxptAny |--- --->| AxpPref | 2711 | |<---\ _____| | 2712 ----------- \______________________/ ----------- 2713 BSMRxd;FwdBSM,[1][2][3] 2715 Initial state: AxptAny; LclBSR = 0, LclRP-Set = empty 2717 (b) State transition diagram for a router not configured as C-BSR 2719 State Variables 2721 LclBSR = Local concatenated BSR priority and BSR IP address 2722 LclRP-Set = Local RP-Set 2723 RxdBSR = Received concatenated BSR priority and BSR IP address 2724 RxdRP-Set = Received RP-Set 2725 Bootstrap-Period = 60 seconds 2726 Bootstrap-Timeout = 2.5 x Bootstrap-Period = 150 seconds 2728 Predicates 2730 Name Meaning 2731 -------------------------------------------- 2732 P RxdBSR >= LclBSR 2734 Incoming Events 2736 Name Interface Meaning 2737 ------------------------------------------------------------- 2738 PrefBSMRxd RPF nbr toward Bootstrap msg rcvd satisfying P 2739 included BSR 2740 BSMRxd RPF nbr toward Bootstrap message received 2741 included BSR 2742 TExp Timer provider Bootstrap timer expired 2743 machinery 2745 States 2747 Name Meaning 2748 ---------------------------------------------------------------------- 2749 AxptPref Accept only Bootstrap messages from preferred or equal BSR 2750 AxptAny Accept any RP-Set messages coming thru the right interface 2751 CandBSR Candidate bootstrap router 2752 ElectedBSR Elected bootstrap router 2754 Outgoing events 2756 Name Interface Meaning 2757 ------------------------------------------------------------- 2758 FwdBSM All interfaces except Forward Bootstrap message 2759 receiving interface 2760 OrigBSM All interfaces Originate Bootstrap message 2762 Specific actions 2764 [1] = Restart Bootstrap timer at Bootstrap-Timeout 2765 [2] = (LclBSR = RxdBSR) 2766 [3] = (LclRP-Set = RxdRP-Set) 2767 [4] = Restart Bootstrap timer at Bootstrap-Period 2769 Fig. 4 State Diagram for the BSR election and RP-Set distribution 2771 Each PIM router keeps a bootstrap-timer, initialized to [Bootstrap- 2772 Timeout], in addition to a local BSR field `LclBSR' (initialized to a 2773 local address if Candidate-BSR, or to 0 otherwise), and a local RP- 2774 Set `LclRP-Set' (initially empty). The main stimuli to the state 2775 machine are timer events and arrival of bootstrap messages: 2777 Initial States and Timer Events 2779 1 If the router is a Candidate-BSR: 2781 1 2783 2 The router operates initially in the `CandBSR' state, 2784 where it does not originate any bootstrap messages. 2786 3 If the bootstrap-timer expires, and the current state 2787 is `CandBSR', the router originates a bootstrap 2788 message carrying the local RP-Set and its own BSR 2789 priority and address, restarts the bootstrap-timer at 2790 [Bootstrap-Period] seconds, and transits into the 2791 `ElectedBSR' state. Note that the actual sending of 2792 the bootstrap message may be delayed by a random value 2793 to reduce transient control overhead. To obtain best 2794 results, the random value is set such that the 2795 preferred BSR is the first to originate a bootstrap 2796 message. We propose the following as an efficient 2797 implementation of the random value delay (in seconds): 2799 Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) + AddrDelay 2801 where myPriority is the Candidate-BSR's 2802 configured priority, and bestPriority equals: 2804 bestPriority = Max(storedPriority, myPriority) ] 2806 and AddrDelay is given by the following: 2808 1 if ( bestPriority equals myPriority) then 2809 [AddrDelay = log_2(bestAddr - myAddr) / 16, ] 2811 2 else [AddrDelay = 2 - (myAddr / 2^31) ] 2813 where myAddr is the Candidate-BSR's address, and 2814 bestAddr is the stored BSR's address. 2816 4 If the bootstrap-timer expires, and the current state 2817 is `ElectedBSR', the router originates a bootstrap 2818 message, and restarts the RP-Set timer at [Bootstrap- 2819 Period]. No state transition is incurred. 2821 This way, the elected BSR originates periodic 2822 bootstrap messages every [Bootstrap-Period]. 2824 2 If a router is not a Candidate-BSR: 2826 1 2828 2 The router operates initially in the `AxptAny' state. 2829 In such state, a router accepts the first bootstrap 2830 message from the The Reverse Path Forwarding (RPF) 2831 neighbor toward the included BSR. The RPF neighbor in 2832 this case is the next hop router en route to the 2833 included BSR. 2835 3 If the bootstrap-timer expires, and the current state 2836 is `AxptPref'-- where the router accepts only 2837 preferred bootstrap messages (those that carry BSR- 2838 priority and address higher than, or equal to, 2839 `LclBSR') from the RPF neighbor toward the included 2840 BSR-- the router transits into the `AxptAny' state. 2842 In this case, if an elected BSR becomes unreachable, 2843 the routers start accepting bootstrap messages from 2844 another Candidate-BSR after the bootstrap-timer 2845 expires. All PIM routers within a domain converge on 2846 the preferred reachable Candidate-BSR. 2848 Receiving Bootstrap Message: 2850 To avoid loops, an RPF check is performed on the included BSR 2851 address. Upon receiving a bootstrap message from the RPF 2852 neighbor toward the included BSR, the following actions are 2853 taken: 2855 1 If the router is not a Candidate-BSR: 2857 1 If the current state is `AxptAny', the router accepts 2858 the bootstrap message, and transits into the 2859 `AxptPref' state. 2861 2 If the current state is `AxptPref', and the bootstrap 2862 message is preferred, the message is accepted. No 2863 state transition is incurred. 2865 2 If the router is a Candidate-BSR, and the bootstrap message 2866 is preferred, the message is accepted. Further, if this 2867 happens when the current state is `Elected BSR', the router 2868 transits into the `CandBSR' state. 2870 When a bootstrap message is accepted, the router restarts the 2871 bootstrap-timer at [Bootstrap-Timeout], stores the received BSR 2872 priority and address in `LclBSR', and the received RP-Set in 2873 `LclRP-Set', and forwards the bootstrap message out all 2874 interfaces except the receiving interface. 2876 If a bootstrap message is rejected, no state transitions are 2877 triggered. 2879 7.3 Appendix III: Glossary of Terms 2881 Following is an alphabetized list of terms and definitions used 2882 throughout this specification. 2884 * { Bootstrap router (BSR)}. A BSR is a dynamically elected 2885 router within a PIM domain. It is responsible for constructing 2886 the RP-Set and originating Bootstrap messages. 2888 * { Candidate-BSR (C-BSR)}. A C-BSR is a router configured to 2889 participate in the BSR election and act as BSRs if elected. 2891 * { Candidate RP (C-RP)}. A C-RP is a router configured to 2892 send periodic Candidate-RP-Advertisement messages to the BSR, 2893 and act as an RP when it receives Join/Prune or Register 2894 messages for the advertised group prefix. 2896 * { Designated Router (DR)}. The DR sets up multicast route 2897 entries and sends corresponding Join/Prune and Register 2898 messages on behalf of directly-connected receivers and 2899 sources, respectively. The DR may or may not be the same 2900 router as the IGMP Querier. The DR may or may not be the 2901 long-term, last-hop router for the group; a router on the LAN 2902 that has a lower metric route to the data source, or to the 2903 group's RP, may take over the role of sending Join/Prune 2904 messages. 2906 * { Incoming interface (iif)}. The iif of a multicast route 2907 entry indicates the interface from which multicast data 2908 packets are accepted for forwarding. The iif is initialized 2909 when the entry is created. 2911 * Join list. The Join list is one of two lists of addresses 2912 that is included in a Join/Prune message; each address refers 2913 to a source or RP. It indicates those sources or RPs to which 2914 downstream receiver(s) wish to join. 2916 * { Last-hop router}. The last-hop router is the last router 2917 to receive multicast data packets before they are delivered to 2918 directly-connected member hosts. In general the last-hop 2919 router is the DR for the LAN. However, under various 2920 conditions described in this document a parallel router 2921 connected to the same LAN may take over as the last-hop router 2922 in place of the DR. 2924 * { Outgoing interface (oif) list}. Each multicast route 2925 entry has an oif list containing the outgoing interfaces to 2926 which multicast packets should be forwarded. 2928 * Prune List. The Prune list is the second list of addresses 2929 that is included in a Join/Prune message. It indicates those 2930 sources or RPs from which downstream receiver(s) wish to 2931 prune. 2933 * { PIM Multicast Border Router (PMBR)}. A PMBR connects a 2934 PIM domain to other multicast routing domain(s). 2936 * { Rendezvous Point (RP)}. Each multicast group has a 2937 shared-tree via which receivers hear of new sources and new 2938 receivers hear of all sources. The RP is the root of this 2939 per-group shared tree, called the RP-Tree. 2941 * { RP-Set}. The RP-Set is a set of RP addresses constructed 2942 by the BSR based on Candidate-RP advertisements received. The 2943 RP-Set information is distributed to all PIM routers in the 2944 BSR's PIM domain. 2946 * { Reverse Path Forwarding (RPF)}. RPF is used to select the 2947 appropriate incoming interface for a multicast route entry . 2948 The RPF neighbor for an address X is the the next-hop router 2949 used to forward packets toward X. The RPF interface is the 2950 interface to that RPF neighbor. In the common case this is the 2951 next hop used by the unicast routing protocol for sending 2952 unicast packets toward X. For example, in cases where unicast 2953 and multicast routes are not congruent, it can be different. 2955 * { Route entry.} A multicast route entry is state maintained 2956 in a router along the distribution tree and is created, and 2957 updated based on incoming control messages. The route entry 2958 may be different from the forwarding entry; the latter is used 2959 to forward data packets in real time. Typically a forwarding 2960 entry is not created until data packets arrive, the forwarding 2961 entry's iif and oif list are copied from the route entry, and 2962 the forwarding entry may be flushed and recreated at will. 2964 * { Shortest path tree (SPT)}. The SPT is the multicast 2965 distribution tree created by the merger of all of the shortest 2966 paths that connect receivers to the source (as determined by 2967 unicast routing). 2969 * { Sparse Mode (SM)}. SM is one mode of operation of a 2970 multicast protocol. PIM SM uses explicit Join/Prune messages 2971 and Rendezvous points in place of Dense Mode PIM's and DVMRP's 2972 broadcast and prune mechanism. 2974 * { Wildcard (WC) multicast route entry}. Wildcard multicast 2975 route entries are those entries that may be used to forward 2976 packets for any source sending to the specified group. 2977 Wildcard bots in the join list of a Join/Prune message 2978 represent either a (*,G) or (*,*,RP) join; in the prune list 2979 they represent a (*,G) prune. 2981 * { (S,G) route entry}. (S,G) is a source-specific route 2982 entry. It may be created in response to data packets, 2983 Join/Prune messages, or Asserts. The (S,G) state in routers 2984 creates a source-rooted, shortest path (or reverse shortest 2985 path) distribution tree. (S,G)RPT bit entries are source- 2986 specific entries on the shared RP-Tree; these entries are used 2987 to prune particular sources off of the shared tree. 2989 * { (*,G) route entry}. Group members join the shared RP-Tree 2990 for a particular group. This tree is represented by (*,G) 2991 multicast route entries along the shortest path branches 2992 between the RP and the group members. 2994 * { (*,*,RP) route entry}. (*,*,RP) refers to any source and 2995 any multicast group that maps to the RP included in the entry. 2996 The routers along the shortest path branches between a 2997 domain's RP(s) and its PMBRs keep (*,*,RP) state and use it to 2998 determine how to deliver packets toward the PMBRs if data 2999 packets arrive for which there is not a longer match. The 3000 wildcard group in the (*,*,RP) route entry is represented by a 3001 group address of 224.0.0.0 and a mask length of 4 bits. 3003 References 3005 1. Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C., 3006 Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast 3007 (pim): Motivation and Architecture", Work in Progress. 3009 2. S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. 3010 Wei. The pim architecture for wide-area multicast routing. ACM 3011 Transactions on Networks, April 1996. 3013 3. Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, 3014 P., and A. Helmy, "Protocol Independent Multicast-dense Mode (pim- 3015 dm): Protocol Specification", Work in Progress. 3017 4. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 3018 1112, August 1989. 3020 5. Fenner, W., "Internet Group Management Protocol, Version 2", RFC 3021 2236, November 1997. 3023 6. Atkinson, R., "Security Architecture for the Internet Protocol", 3024 RFC 1825, August 1995. 3026 7. Mark R. Nelson. File verification using CRC. Dr. Dobb's 3027 Journal, May 1992. 3029 8. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. 3030 In Proceedings of the ACM SIGCOMM, San Francisco, 1993. 3032 9. Wei, L., "Authenticating PIM Version 2 Messages", 3033 draft-ietf-pim-v2-auth-01.txt, work in progress. 3035 Authors' Addresses 3037 NOTE: The author list has been reordered to reflect the involvement 3038 in detailed editorial work on this specification document. The first 3039 four authors are the primary editors and are listed alphabetically. 3040 The rest of the authors, also listed alphabetically, participated in 3041 all aspects of the architectural and detailed design but managed to 3042 get away without hacking the latex! 3044 Deborah Estrin 3045 Computer Science Dept/ISI 3046 University of Southern Calif. 3047 Los Angeles, CA 90089 3048 EMail: estrin@usc.edu 3050 Dino Farinacci 3051 Procket Networks, Inc 3052 EMail: dino@procket.com 3054 Ahmed Helmy 3055 Computer Science Dept. 3056 University of Southern Calif. 3057 Los Angeles, CA 90089 3058 EMail: helmy@ceng.usc.edu 3060 David Thaler 3061 Microsoft Corporation 3062 One Microsoft Way 3063 Redmond, WA 98052 3064 EMail: dthaler@microsoft.com 3065 Stephen Deering 3066 Cisco Systems, inc, 3067 San Jose, CA 95134 3068 EMail: deering@cisco.com 3070 Mark Handley 3071 AT&T Center for Internet Research at ICSI, 3072 International Computer Science Institute, 3073 1947 Center Street, Suite 600, 3074 Berkeley, CA 94704, USA 3075 EMail: mjh@aciri.org 3077 Van Jacobson 3078 Cisco Systems, Inc. 3079 170 W Tasman Drive 3080 San Jose, CA 95134 3081 EMail: van.jacobson@cisco.com 3083 Ching-Gung Liu 3084 Fujitsu Laboratories of America, Inc. 3085 595, Lawrence Expressway, Sunnyvale, CA 91748 3086 EMail: charley@fla.fujitsu.com 3088 Puneet Sharma 3089 Hewlett Packard Laboratories 3090 1501 Page Mill Road, Palo Alto, CA 94304 3091 Email: puneet@hpl.hp.com 3093 Liming Wei 3094 Siara Systems, Inc. 3095 300 Ferguson Drive 3096 Mountain View, CA 94043 3097 EMail: lwei@siara.com 3099 Full Copyright Statement 3101 Copyright (C) The Internet Society (1999). All Rights Reserved. 3103 This document and translations of it may be copied and furnished to 3104 others, and derivative works that comment on or otherwise explain it 3105 or assist in its implementation may be prepared, copied, published 3106 and distributed, in whole or in part, without restriction of any 3107 kind, provided that the above copyright notice and this paragraph are 3108 included on all such copies and derivative works. However, this 3109 document itself may not be modified in any way, such as by removing 3110 the copyright notice or references to the Internet Society or other 3111 Internet organizations, except as needed for the purpose of 3112 developing Internet standards in which case the procedures for 3113 copyrights defined in the Internet Standards process must be 3114 followed, or as required to translate it into languages other than 3115 English. 3117 The limited permissions granted above are perpetual and will not be 3118 revoked by the Internet Society or its successors or assigns. 3120 This document and the information contained herein is provided on an 3121 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3122 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3123 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3124 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3125 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.