idnits 2.17.1 draft-ietf-pim-sm-bsr-00.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 seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 130 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance 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 574: '...mically learned. The interval MUST be...' RFC 2119 keyword, line 631: '...otherwise this bit MUST NOT be set....' RFC 2119 keyword, line 650: '...ng shut down, it SHOULD immediately se...' RFC 2119 keyword, line 833: '...erent scope zone MUST occupy a differe...' RFC 2119 keyword, line 923: '... fragment MUST be the group range ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (23 February 2001) is 8460 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force PIM WG 2 INTERNET-DRAFT Bill Fenner/AT&T 3 draft-ietf-pim-sm-bsr-00.txt Mark Handley/ACIRI 4 David Thaler/Microsoft 5 23 February 2001 6 Expires: August 2001 8 Bootstrap Router (BSR) Mechanism for PIM Sparse Mode 10 Status of this Document 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is a product of the IETF PIM WG. Comments should be 31 addressed to the authors, or the WG's mailing list at 32 pim@catarina.usc.edu. 34 Abstract 36 This document specifies the Bootstrap Router (BSR) mechanism 37 for PIM Sparse Mode. BSR is one way that a PIM-SM router can 38 learn the set of group-to-RP mappings required in order to 39 function. The mechanism is dynamic, largely self-configuring, 40 and robust to router failure. 42 Table of Contents 44 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Overview of Bootstrap and RP Discovery . . . . . . . 3 46 1.2. Administratively Scoped Multicast. . . . . . . . . . 4 47 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 6 48 3. Bootstrap Router Election and RP-Set 49 Distribution . . . . . . . . . . . . . . . . . . . . . . . 7 50 3.1. Sending Candidate-RP-Advertisements. . . . . . . . . 15 51 3.2. Creating the RP-Set at the BSR . . . . . . . . . . . 16 52 3.3. Forwarding Bootstrap Messages. . . . . . . . . . . . 17 53 3.4. Receiving and Using the RP-Set . . . . . . . . . . . 17 54 4. Message Formats . . . . . . . . . . . . . . . . . . . . 18 55 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 20 56 4.2. Candidate-RP-Advertisement Format. . . . . . . . . . 23 57 5. Default Values for Timers . . . . . . . . . . . . . . . 25 58 6. Authors' Addresses. . . . . . . . . . . . . . . . . . . 26 59 7. References. . . . . . . . . . . . . . . . . . . . . . . 27 60 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 27 62 1. Introduction 64 For correct operation, every PIM router within a PIM domain must be able 65 to map a particular multicast group address to the same RP. If this is 66 not the case then black holes may appear, where some receivers in the 67 domain cannot receive some groups. A domain in this context is a 68 contiguous set of routers that all implement PIM and are configured to 69 operate within a common boundary defined by PIM Multicast Border Routers 70 (PMBRs). PMBRs connect each PIM domain to the rest of the internet. 72 A notable exception to this is where a PIM domain is broken up into 73 multiple administrative scope regions - these are regions where a border 74 has been configured so that a range of multicast groups will not be 75 forwarded across that border. For more information on Administratively 76 Scoped IP Multicast, see RFC 2365. The modified criteria for admin- 77 scoped regions are that the region is convex with respect to forwarding 78 based on the MRIB, and that all PIM routers within the scope region map 79 a particular scoped group to the same RP within that region. 81 The PIM-SM specification does not mandate the use of a single mechanism 82 to provide routers with the information to perform the group-to-RP 83 mapping. This document describes the Bootstrap Router (BSR) mechanism. 84 BSR was first defined in RFC 2362, which has since been obsoleted. This 85 document provides an updated specification of the BSR mechanism from RFC 86 2362, and also extends it to cope with administratively scoped region 87 boundaries. 89 1.1. Overview of Bootstrap and RP Discovery 91 A small set of routers from a domain are configured as candidate 92 bootstrap routers (C-BSRs) and, through a simple election mechanism, a 93 single BSR is selected for that domain. A set of routers within a domain 94 are also configured as candidate RPs (C-RPs); typically these will be 95 the same routers that are configured as C-BSRs. Candidate RPs 96 periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to 97 the BSR of that domain, advertising their willingness to be an RP. A C- 98 RP-Adv message includes the address of the advertising C-RP, as well as 99 an optional list of group addresses and a mask length fields, indicating 100 the group prefix(es) for which the candidacy is advertised. The BSR then 101 includes a set of these Candidate-RPs (the RP-Set), along with their 102 corresponding group prefixes, in Bootstrap messages it periodically 103 originates. Bootstrap messages are distributed hop-by-hop throughout 104 the domain. 106 All the PIM routers in the domain receive and store Bootstrap messages 107 originated by the BSR. When a DR gets a indication of local membership 108 from IGMP or a data packet from a directly connected host, for a group 109 for which it has no forwarding state, the DR uses a hash function to map 110 the group address to one of the C-RPs from the RP-Set whose group-prefix 111 includes the group (see RFC xxxx). The DR then sends a Join message 112 towards that RP if the local host joined the group, or it Register- 113 encapsulates and unicasts the data packet to the RP if the local host 114 sent a packet to the group. 116 A Bootstrap message indicates liveness of the RPs included therein. If 117 an RP is included in the message, then it is tagged as `up' at the 118 routers; RPs not included in the message are removed from the list of 119 RPs over which the hash algorithm acts. Each router continues to use the 120 contents of the most recently received Bootstrap message from the BSR 121 until it receives a new Bootstrap message. 123 If a PIM domain becomes partitioned, each area separated from the old 124 BSR will elect its own BSR, which will distribute an RP-Set containing 125 RPs that are reachable within that partition. When the partition heals, 126 another election will occur automatically and only one of the BSRs will 127 continue to send out Bootstrap messages. As is expected at the time of a 128 partition or healing, some disruption in packet delivery may occur. This 129 time will be on the order of the region's round-trip time and the 130 bootstrap router timeout value. 132 1.2. Administratively Scoped Multicast 134 Administratively Scoped IP Multicast, as defined in RFC 2365, permits a 135 network provider to configure scope boundaries at multicast routers. 136 Such a scope boundary consists of a range of multicast addresses 137 (expressed as an address and mask) that the router will not forward 138 across the boundary. For correct operation, such a scope zone border 139 must be complete and convex. By this we mean that there must be no path 140 from inside the scoped zone to outside it that does not pass through a 141 configured scope border router, and that the multicast capable path 142 between any arbitrary pair of multicast routers in the scope zone must 143 remain in the zone. 145 For PIM-SM using BSR to function correctly with admin scoping, there 146 must be a BSR and at least one C-RP within every admin scope region. 147 Admin scope zone boundaries must be configured at the Zone Border 148 Routers (ZBRs), as they need to filter PIM Join messages that might 149 inadvertantly cross the border due to error conditions. However we do 150 not wish any other router within the scope zone to require manual 151 configuration as this creates further possibilities for error, and makes 152 the configuration of large scope zones difficult. If all the C-BSR and 153 C-RP routers within a scope zone are ZBRs, then there is no problem, but 154 this may not the the desired case. Thus whilst we also permit interior 155 C-BSRs and C-RPs to be configured for the admin scope zone, we would 156 also require a mechanism by which all C-BSRs and C-RPs inside an admin 157 scope zone can automatically learn of the existence of the scope zone. 159 We do this by requiring all ZBRs to be both C-BSRs and C-RPs for the 160 scoped group range, although the default priority should be the lowest 161 possible. A ZBR that does not know of a higher-priority BSR advertising 162 RPs for the scope zone will therefore originate its own Bootstrap 163 message, initially only containing itself as a possible RP for the 164 scoped group range. The group-range field in the ZBRs bootstrap message 165 is marked (using the "Admin Scope" bit, previously a "Reserved" bit) to 166 indicate that this is an administrative scope range, and not just a 167 range that a particular set of RPs are configured to handle. Such a 168 bootstrap message is flooded in the normal way, but will not be 169 forwarded by another ZBR across the boundary for that scope zone (see 170 Section 3.3 for the specifics of this). 172 When a C-BSR within the scope zone receives such a Bootstrap message, it 173 stores state for the admin scope range contained in the message. A 174 separate BSR election will then take place for every admin scope range 175 (plus one for the global range). 177 When a C-RP within the scope zone receives such a Bootstrap message, it 178 also stores state for the admin scope range contained in the message. 179 It separately unicasts Candidate-RP-Advertisement messages to the BSR 180 for every admin scope range within which it is willing to serve as an 181 RP. Unless configured otherwise, all candidate RPs are willing to serve 182 as RPs for all groups in all ranges. 184 ZBRs are also C-RPs for the admin scope zone; they also learn of the 185 current BSR for the admin scope range from receiving a Bootstrap 186 message, and so they must also send a Candidate-RP-Advertisement message 187 to the BSR for the scope range. However, unlike an internal C-RP, a ZBR 188 sets the "Admin Scope" bit in the group-range field in its C-RP 189 advertisement. When the BSR receives such a C-RP-Adv message, it 190 updates the scope zone keepalive timer; if this timer ever expires the 191 BSR stops being the BSR for that admin scope zone and flushes all state 192 concerned with the scope zone. In this way, if all the ZBRs are 193 configured to no longer be ZBRs, then the BSR will eventually time out 194 the zone. 196 Note that so long as at least one reachable internal BSR and C-RP is 197 configured within the scope zone to have better-than-minimum priority, 198 then by default the ZBRs themselves will never actually be used as 199 either the BSR or an RP for the scope zone despite being a C-BSR and C- 200 RP. 202 2. BSR State and Timers 204 A PIM-SM router implementing BSR holds the following state in addition 205 to the state needed for PIM-SM operation: 207 At all routers: 209 List of Active Scope Zones 211 Per Scope Zone: 213 Scope-Zone Expiry Timer: SZT(Z) 215 Bootstrap State: 217 o Bootstrap Router's IP Address 219 o BSR Priority 221 o Bootstrap Timer (BST) 223 o List of Scope Group-Ranges for this BSR 225 RP Set 227 At a Candidate BSR: 229 Per Scope Zone: 231 o My state: One of "Candidate-BSR", "Pending-BSR", 232 "Elected-BSR" 234 At a router that is not a Candidate BSR: 236 Per Scope Zone: 238 o My state: One of "Accept Any", "Accept Preferred" 240 Bootstrap state is described in section 3, and the RP Set is described 241 in section 3.4. 243 The following timers are also required: 245 At the Bootstrap Router only: 247 Per Scope Zone (Z): 249 Per Candidate RP (C): 251 C-RP Expiry Timer: CET(C,Z) 253 At the C-RPs only: 255 C-RP Advertisement Timer: CRPT 257 3. Bootstrap Router Election and RP-Set Distribution 259 For simplicity, bootstrap messages (BSMs) are used in both the BSR 260 election and the RP-Set distribution mechanisms. 262 The state-machine for bootstrap messages depends on whether or not a 263 router has been configured to be a Candidate-BSR. The state-machine for 264 a C-BSR is given below, followed by the state-machine for a router that 265 is not configured to be a C-BSR. 267 Candidate-BSR State Machine 269 +-----------------------------------+ 270 | Figures omitted from text version | 271 +-----------------------------------+ 273 Figure 1: State-machine for a candidate BSR 275 In tabular form this state machine is: 277 +-----------------------------------------------------------------------+ 278 | When in No Info state | 279 +---------+-------------------------------+-----------------------------+ 280 | Event | Receive Preferred BSM for | Receive Non-Preferred BSM | 281 | | unknown Admin Scope | for unknown Admin Scope | 282 +---------+-------------------------------+-----------------------------+ 283 | | -> C-BSR state | -> P-BSR state | 284 | Action | Forward BSM; | Forward BSM; | 285 | | Store RP Set; | Store RP Set; | 286 | | Set BS Timer to BS Timeout | Set BS Timer to BS Timeout | 287 +---------+-------------------------------+-----------------------------+ 288 +-----------------------------------------------------------------------+ 289 | When in C-BSR state | 290 +------------+-------------------+-------------------+------------------+ 291 | Event | Receive | BS Timer | Receive BSM | 292 | | Preferred BSM | Expires | from BSR with | 293 | | | | Admin Scope | 294 | | | | bit cleared | 295 +------------+-------------------+-------------------+------------------+ 296 | | -> C-BSR state | -> P-BSR state | -> No Info | 297 | | | | state | 298 | Action | Forward BSM; | Set BS Timer | cancel timers, | 299 | | Store RP Set; | to | clear state | 300 | | Set BS Timer | rand_override | | 301 | | to BS Timeout | | | 302 +------------+-------------------+-------------------+------------------+ 304 +-----------------------------------------------------------------------+ 305 | When in P-BSR state | 306 +------------+-------------------+-------------------+------------------+ 307 | Event | Receive | BS Timer | Receive BSM | 308 | | Preferred BSM | Expires | from BSR with | 309 | | | | Admin Scope | 310 | | | | bit cleared | 311 +------------+-------------------+-------------------+------------------+ 312 | | -> C-BSR state | -> E-BSR state | -> No Info | 313 | | | | state | 314 | | Forward BSM; | Originate BSM; | cancel timers, | 315 | Action | Store RP Set; | Set BS Timer | clear state | 316 | | Set BS Timer | to BS Period; | | 317 | | to BS Timeout | Set SZ Timer | | 318 | | | to SZ Period | | 319 +------------+-------------------+-------------------+------------------+ 320 +-----------------------------------------------------------------------+ 321 | When in E-BSR state | 322 +----------+---------------+--------------+--------------+--------------+ 323 |Event | Receive | BS Timer | SZ Timer | Receive C- | 324 | | Preferred | Expires | Expires | RP-Adv for | 325 | | BSM | | | this Admin | 326 | | | | | Scope | 327 +----------+---------------+--------------+--------------+--------------+ 328 | | -> C-BSR | -> E-BSR | -> No Info | -> E-BSR | 329 | | state | state | state | state | 330 | | Forward BSM; | Originate | Originate | Set SZ Timer | 331 |Action | Store RP | BSM; Set BS | BSM with | to SZ | 332 | | Set; Set BS | Timer to BS | Admin Scope | Timeout | 333 | | Timer to BS | Period | bit cleared | | 334 | | Timeout | | | | 335 +----------+---------------+--------------+--------------+--------------+ 336 A candidate-BSR may be in one of four states for a particular scope 337 zone: 339 No Info 340 The router has no information about this scope zone. This state 341 does not apply if the router is configured to know about this scope 342 zone, or for the global scope zone. When in this state, no state 343 information is held and no timers run that refer to this scope 344 zone. 346 Candidate-BSR (C-BSR) 347 The router is a candidate to be a BSR, but currently another router 348 is the preferred BSR. 350 Pending-BSR (P-BSR) 351 The router is a candidate to be a BSR. Currently no other router 352 is the preferred BSR, but this router is not yet the BSR. For 353 comparisons with incoming BS messages, the router treats itself as 354 the BSR. This is a temporary state that prevents rapid thrashing 355 of the choice of BSR during BSR election. 357 Elected-BSR (E-BSR) 358 The router is the elected bootstrap router and it must perform all 359 the BSR functions. 361 On startup, the initial state for this scope zone is "Pending-BSR" for 362 routers that know about this scope zone, either through configuration or 363 because the scope zone is the global scope which always exists; the BS 364 Timer is initialized to the BS Timeout value. For routers that do not 365 know about a particular scope zone, the initial state is No Info; no 366 timers exist for the scope zone. 368 In addition to the four states, there are two timers: 370 o The bootstrap timer (BS Timer) - that is used to time out old 371 bootstrap router information, and used in the election process to 372 terminate P-BSR state. 374 o The scope zone timer (SZ Timer) - that is used to time out the scope 375 zone itself at an Elected BSR if no C-RP-Adv messages arrive from the 376 Zone Border Routers. 378 State-machine for Non-Candidate-BSR Routers 380 +-----------------------------------+ 381 | Figures omitted from text version | 382 +-----------------------------------+ 384 Figure 2: State-machine for a router not configured as C-BSR 386 In tabular form this state machine is: 388 +-----------------------------------------------------------------------+ 389 | When in No Info state | 390 +--------------------+--------------------------------------------------+ 391 | Event | Receive BSM for unknown Admin Scope | 392 +--------------------+--------------------------------------------------+ 393 | | -> AP State | 394 | Action | Forward BSM; Store RP-Set; | 395 | | Set BS Timer to BS Timeout; | 396 | | Set SZ Timer to SZ Timeout | 397 +--------------------+--------------------------------------------------+ 399 +-----------------------------------------------------------------------+ 400 | When in Accept Any state | 401 +---------------+-----------------------------+-------------------------+ 402 | Event | Receive BSM | SZ Timer Expires | 403 +---------------+-----------------------------+-------------------------+ 404 | | -> AP State | -> No Info state | 405 | | Forward BSM; Store | cancel timers; | 406 | Action | RP-Set; Set BS | clear state | 407 | | Timer to BS | | 408 | | Timeout | | 409 +---------------+-----------------------------+-------------------------+ 410 +-----------------------------------------------------------------------+ 411 | When in Accept Preferred state | 412 +-----------+------------------+-----------------+----------------------+ 413 | Event | Receive | BS Timer | Receive BSM from | 414 | | Preferred BSM | Expires | BSR with Admin | 415 | | | | Scope bit cleared | 416 +-----------+------------------+-----------------+----------------------+ 417 | | -> AP State | -> AA State | -> No Info state | 418 | | Forward BSM; | | cancel | 419 | Action | Store RP-Set; | | timers;clear | 420 | | Set BS Timer | | state | 421 | | to BS Timeout | | | 422 +-----------+------------------+-----------------+----------------------+ 424 A router that is not a candidate-BSR may be in one of three states: 426 No Info 427 The router has no information about this scope zone. This state 428 does not apply if the router is configured to know about this scope 429 zone, or for the global scope zone. When in this state, no state 430 information is held and no timers run that refer to this scope 431 zone. 433 Accept Any (AA) 434 The router does not know of an active BSR, and will accept the 435 first bootstrap message it sees as giving the new BSR's identity 436 and the RP-Set. If the router has an RP-Set cached from an 437 obsolete bootstrap message, it continues to use it. 439 Accept Preferred (AP) 440 The router knows the identity of the current BSR, and is using the 441 RP-Set provided by that BSR. Only bootstrap messages from that BSR 442 or from a C-BSR with higher weight than the current BSR will be 443 accepted. 445 On startup, the initial state for this scope zone is "Accept Any" for 446 routers that know about this scope zone, either through configuration or 447 because the scope zone is the global scope which always exists; the SZ 448 Timer is considered to be always running for such scope zones. For 449 routers that do not know about a particular scope zone, the initial 450 state is No Info; no timers exist for the scope zone. 452 In addition to the three states, there are two timers: 454 o The bootstrap timer (BS Timer) - that is used to time out old 455 bootstrap router information. 457 o The scope zone timer (SZ Timer) - that is used to time out the scope 458 zone itself if BS messages specifying this scope zone stop arriving. 460 Bootstrap Message Processing Checks 462 When a bootstrap message is received, the following initial checks must 463 be performed: 465 if (BSM.dst_ip_address == ALL-PIM-ROUTERS group) { 466 if ( BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address) ) { 467 drop the BS message silently 468 } 469 } else if (BSM.dst_ip_address is one of my addresses) { 470 if ( (No previous BSM received) 471 OR (DirectlyConnected(BSM.src_ip_address) == FALSE) ) { 472 #the packet was unicast, but this wasn't 473 #a quick refresh on startup 474 drop the BS message silently 475 } 476 } else { 477 drop the BS message silently 478 } 479 if (the interface the message arrived on is an Admin Scope 480 border for the BSM.first_group_address) { 481 drop the BS message silently 482 } 484 Basically, the packet must have been sent to the ALL-PIM-ROUTERS group 485 by the correct upstream router towards the BSR that originated the BS 486 message, or the router must have no BSR state (it just restarted) and 487 have received the BS message by unicast from a directly connected 488 neighbor. In addition it must not have arrived on an interface that is 489 a configured admin scope border for the first group address contained in 490 the BS message. 492 BS State-machine Transition Events 494 If the bootstrap message passes the initial checks above without being 495 discarded, then it may cause a state transition event in one of the 496 above state-machines. For both candidate and non-candidate BSRs, the 497 following transition events are defined: 499 Receive Preferred BSM 500 A bootstrap message is received from a BSR that has greater 501 than or equal weight than the current BSR. In a router is in 502 P-BSR state, then it uses its own weight as that of the 503 current BSR. 505 The weighting for a BSR is the concatenation in fixed- 506 precision unsigned arithmetic of the BSR priority field from 507 the bootstrap message and the IP address of the BSR from the 508 bootstrap message (with the BSR priority taking the most- 509 significant bits and the IP address taking the least 510 significant bits). 512 Receive BSM 513 A bootstrap message is received, regardless of BSR weight. 515 Receive BSM from BSR with Admin Scope bit cleared 516 The scope is not the global scope; it is an admin scope that 517 was previously learned from receiving a bootstrap message that 518 had the Admin Scope bit set for this scope. Now a bootstrap 519 message is received for this scope range from the BSR, but the 520 Admin Scope bit is cleared indicating that the BSR has timed 521 out the entire scope zone. 523 Receive C-RP-Adv for this Admin Scope 524 The scope is not the global scope; it is an admin scope range. 525 A C-RP-Adv message arrives with the Admin Scope bit set for 526 this scope range. This indicates that the sender of the C-RP- 527 Adv (normally a ZBR for the scope zone) believes the scope 528 zone is still active. 530 BS State-machine Actions 532 The state-machines specify actions that include setting the BS timer to 533 the following values: 535 BS Period 536 The periodic interval with which bootstrap messages are 537 normally sent. The default value is 60 seconds. 539 BS Timeout 540 The interval after which bootstrap router state is timed out 541 if no bootstrap message from that router has been heard. The 542 default value is 2.5 times the BS Period, which is 150 543 seconds. 545 Randomized Override Interval 546 The randomized interval during which a router avoids sending a 547 bootstrap message while it waits to see if another router has 548 a higher bootstrap weight. This interval is to reduce control 549 message overhead during BSR election. The following 550 pseudocode is proposed as an efficient implementation of this 551 "randomized" value: 553 Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) 554 + AddrDelay 556 where myPriority is the Candidate-BSR's configured priority, 557 and bestPriority equals: 559 bestPriority = Max(storedPriority, myPriority) 561 and AddrDelay is given by the following: 563 if ( bestPriority == myPriority) { 564 AddrDelay = log_2(bestAddr - myAddr) / 16 565 } else { 566 AddrDelay = 2 - (myAddr / 2^31) 567 } 569 where myAddr is the Candidate-BSR's address, and bestAddr is 570 the stored BSR's address. 572 SZ Period 573 The interval after which a router will time out an Admin Scope 574 zone that it has dynamically learned. The interval MUST be 575 larger than the C-RP-Adv period and the BS Timeout. The 576 default value is ten times the BS Timeout, which is 1500 577 seconds. 579 In addition to setting the timer, the following actions may be triggered 580 by state-changes in the state-machines: 582 Forward BSM 583 The bootstrap message is forwarded out of all multicast- 584 capable interfaces except the interface it was received on. 585 The source IP address of the message is the forwarding 586 router's IP address on the interface the message is being 587 forwarded from, the destination address is ALL-PIM-ROUTERS, 588 and the TTL of the message is set to 1. 590 Originate BSM 591 A new bootstrap message is constructed by the BSR, giving the 592 BSR's address and BSR priority, and containing the BSR's 593 chosen RP-Set. The message is forwarded out of all multicast- 594 capable interfaces. The IP source address of the message is 595 the forwarding router's IP address on the interface the 596 message is being forwarded from, the destination address is 597 ALL-PIM-ROUTERS, and the TTL of the message is set to 1. 599 Originate BSM with Admin Scope Bit Cleared 600 The action is the same as "Originate BSM", except that 601 although this scope zone is an Admin Scope zone, the group 602 range field for the scope zone has the Admin Scope bit 603 cleared. This serves as a signal that the scope zone is no 604 longer in existence. 606 Store RP Set 607 The RP-Set from the received bootstrap message is stored and 608 used by the router to decide the RP for each group that the 609 router has state for. Storing this RP Set may cause other 610 state-transitions to occur in the router. The BSR's IP 611 address and priority from the received bootstrap message are 612 also stored to be used to decide if future bootstrap messages 613 are preferred. 615 In addition to the above state-machine actions, a DR also unicasts a 616 stored copy of the Bootstrap message to each new PIM neighbor, i.e., 617 after the DR receives the neighbor's first Hello message. It does so 618 even if the new neighbor becomes the DR. 620 3.1. Sending Candidate-RP-Advertisements 622 Every C-RP periodically unicasts a C-RP-Adv to the BSR for that scope 623 zone to inform the BSR of the C-RP's willingness to function as an RP. 624 Unless configured otherwise, it does this for every Admin Scope zone for 625 which it has state, and for the global scope zone. If the same router 626 is BSR for more than one scope zone, the C-RP-Adv for these scope zones 627 MAY be combined into a single message. 629 If the C-RP is a ZBR for an admin scope zone, then the Admin Scope bit 630 MUST be set in the C-RP-Adv messages it sends for that scope zone; 631 otherwise this bit MUST NOT be set. 633 The interval for sending these messages is subject to local 634 configuration at the C-RP, but must be smaller than the HoldTime in the 635 C-RP-Adv. 637 A Candidate-RP-Advertisement carries a list of group address and group 638 mask field pairs. This enables the C-RP router to limit the 639 advertisement to certain prefixes or scopes of groups. If the C-RP 640 becomes an RP, it may enforce this scope acceptance when receiving 641 Registers or Join/Prune messages. 643 The C-RP priority field determines which C-RPs get selected by the BSR 644 to be in the RP Set. Note that a value of zero is the highest possible 645 priority. C-RPs should by default send C-RP-Adv messages with the 646 `Priority' field set to `192'. ZBRs that do not wish to serve as an RP 647 except under failure conditions should default to sending C-RP-Adv 648 messages with the `Priority' field set to `255'. 650 When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv to 651 the BSR for each scope for which it is currently serving as an RP; the 652 HoldTime in this C-RP-Adv message should be zero. The BSR will then 653 immediately time out the C-RP and generate a new BSR message removing 654 the shutdown RP from the RPset. 656 3.2. Creating the RP-Set at the BSR 658 Upon receiving a C-RP-Adv, if the router is not the elected BSR, it 659 silently ignores the message. 661 If the router is the BSR, then it adds the RP address to its local pool 662 of candidate RPs. For each C-RP, the BSR holds the following 663 information: 665 IP address 666 The IP address of the C-RP. 668 Group Prefix and Mask list 669 The list of group prefixes and group masks from the C-RP 670 advertisement. 672 HoldTime 673 The HoldTime from the C-RP-Adv message. This is included 674 later in the RP-set information in the Bootstrap Message. 676 C-RP Expiry Timer 677 The C-RP-Expiry Timer is used to time out the C-RP when the 678 BSR fails to receive C-RP-Advertisements from it. The expiry 679 timer is initialized to the HoldTime from the RP's C-RP-Adv, 680 and is reset to the HoldTime whenever a C-RP-Adv is received 681 from that C-RP. 683 C-RP Priority 684 The C-RP Priority is used to determine the subset of possible 685 RPs to use in the RP-Set. 687 When the C-RP Expiry Timer expires, the C-RP is removed from the pool of 688 available C-RPs. 690 The BSR uses the pool of C-RPs to construct the RP-Set which is included 691 in Bootstrap Messages and sent to all the routers in the PIM domain. 692 The BSR may apply a local policy to limit the number of Candidate RPs 693 included in the Bootstrap message. The BSR may override the prefix 694 indicated in a C-RP-Adv unless the `Priority' field from the C-RP-Adv is 695 less than 128. 697 The Bootstrap message is subdivided into sets of group-prefix,RP- 698 Count,RP-addresses. For each RP-address, the corresponding HoldTime is 699 included in the "RP-HoldTime" field. The format of the Bootstrap 700 message allows `semantic fragmentation', if the length of the original 701 Bootstrap message exceeds the packet maximum boundaries. However, we 702 recommend against configuring a large number of routers as C-RPs, to 703 reduce the semantic fragmentation required. 705 When an elected BSR is being shut down, it should immediately orginate a 706 Bootstrap message listing its current RP set, but with the BSR priority 707 field set to the lowest priority value possible. This will cause the 708 election of a new BSR to happen more quickly. 710 3.3. Forwarding Bootstrap Messages 712 Bootstrap messages originate at the BSR, and are forwarded by 713 intermediate routers if they pass the Bootstrap Message Processing 714 Check. Bootstrap messages are multicast to the `ALL-PIM-ROUTERS' group. 715 When A BS message is forwarded, it is forwarded out of every multicast- 716 capable interface which has PIM neighbors (excluding the one over which 717 the message was received). The exception to this is if the interface is 718 an adminstrative scope boundary for the admin scope zone indicated in 719 the first group address in the BS message packet. Bootstrap messages 720 are always originated or forwarded with an IP TTL value of 1. 722 3.4. Receiving and Using the RP-Set 724 When a router receives and stores a new RP-Set, it checks if each of the 725 RPs referred to by existing state (i.e., by (*,G), (*,*,RP), or 726 (S,G,rpt) entries) is in the new RP-Set. 728 If an RP is not in the new RP-Set, that RP is considered unreachable and 729 the hash algorithm (see PIM-SM specification) is re-performed for each 730 group with locally active state that previously hashed to that RP. This 731 will cause those groups to be distributed among the remaining RPs. 733 If the new RP-Set contains a RP that was not previously in the RP-Set, 734 the hash value of the new RP is calculated for each group covered by the 735 new C-RP's Group-prefix. Any group for which the new RP's hash value is 736 greater than hash value of the group's previous RP is switched over to 737 the new RP. 739 4. Message Formats 741 BSR messages are PIM messages, as defined in RFC xxxx. The values of 742 the PIM message Type field for BSR messages are: 744 4 Bootstrap Message 746 8 Candidate-RP-Advertisement 748 In this section we use the following terms defined in the PIM-SM 749 specification in RFC xxxx: 751 o Encoded-Unicast format 753 o Encoded-Group format 755 We repeat these here to aid readability. 757 Encoded-Unicast address 759 An Encoded-Unicast address takes the following format: 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Addr Family | Encoding Type | Unicast Address 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 767 Addr Family 768 The PIM address family of the `Unicast Address' field of this 769 address. 771 Values of 0-127 are as assigned by the IANA for Internet Address 772 Families in [1]. Values 128-250 are reserved to be assigned by the 773 IANA for PIM-specific Address Families. Values 251 though 255 are 774 designated for private use. As there is no assignment authority 775 for this space, collisions should be expected. 777 Encoding Type 778 The type of encoding used within a specific Address Family. The 779 value `0' is reserved for this field, and represents the native 780 encoding of the Address Family. 782 Unicast Address 783 The unicast address as represented by the given Address Family and 784 Encoding Type. 786 Encoded-Group address 788 Encoded-Group addresses take the following format: 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Addr Family | Encoding Type | Reserved |Z| Mask Len | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Group multicast Address 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 798 Addr Family 799 described above. 801 Encoding Type 802 described above. 804 Reserved 805 Transmitted as zero. Ignored upon receipt. 807 Admin Scope [Z]one 808 When set, this bit indicates that this group address range is an 809 adminstratively scoped range. 811 Mask Len 812 The Mask length field is 8 bits. The value is the number of 813 contiguous one bits left justified used as a mask which, combined 814 with the group address, describes a range of groups. It is less 815 than or equal to the address length in bits for the given Address 816 Family and Encoding Type. If the message is sent for a single group 817 then the Mask length must equal the address length in bits for the 818 given Address Family and Encoding Type. (e.g. 32 for IPv4 native 819 encoding and 128 for IPv6 native encoding). 821 Group multicast Address 822 Contains the group address. 824 4.1. Bootstrap Message Format 826 A bootstrap message is divided up into `semantic fragments', if the 827 original message exceeds the maximum packet size boundaries. Basically, 828 a single bootstrap message can be sent as multiple packets (semantic 829 fragments), so long as the fragment tage of all the packets comprising 830 the message is the same. 832 If the bootstrap message contains information about more than one admin 833 scope zone, each different scope zone MUST occupy a different semantic 834 fragment. This allows Zone Border Routers for an admin scope zone to 835 not forward only those fragments that should not traverse the admin 836 scope boundary. 838 The format of a single `fragment' is given below: 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 |PIM Ver| Type | Reserved | Checksum | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Fragment Tag | Hash Mask len | BSR-priority | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | BSR Address (Encoded-Unicast format) | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Group Address 1 (Encoded-Group format) | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | RP Count 1 | Frag RP Cnt 1 | Reserved | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | RP Address 1 (Encoded-Unicast format) | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | RP1 Holdtime | RP1 Priority | Reserved | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | RP Address 2 (Encoded-Unicast format) | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | RP2 Holdtime | RP2 Priority | Reserved | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | . | 862 | . | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | RP Address m (Encoded-Unicast format) | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | RPm Holdtime | RPm Priority | Reserved | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Group Address 2 (Encoded-Group format) | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | . | 871 | . | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Group Address n (Encoded-Group format) | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | RP Count n | Frag RP Cnt n | Reserved | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | RP Address 1 (Encoded-Unicast format) | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | RP1 Holdtime | RP1 Priority | Reserved | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | RP Address 2 (Encoded-Unicast format) | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | RP2 Holdtime | RP2 Priority | Reserved | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | . | 886 | . | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | RP Address m (Encoded-Unicast format) | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | RPm Holdtime | RPm Priority | Reserved | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 PIM Version, Reserved, Checksum 894 Described in RFC xxxx. 896 Type PIM Message Type. Value is 8 for a Bootstrap Message. 898 Fragment Tag 899 A randomly generated number, acts to distinguish the fragments 900 belonging to different Bootstrap messages; fragments belonging to 901 same Bootstrap message carry the same `Fragment Tag'. 903 Hash Mask len 904 The length (in bits) of the mask to use in the hash function. For 905 IPv4 we recommend a value of 30. For IPv6 we recommend a value of 906 126. 908 BSR priority 909 Contains the BSR priority value of the included BSR. This field is 910 considered as a high order byte when comparing BSR addresses. Note 911 that for historical reasons, the highest BSR priority priority is 912 255 (the higher the better), whereas the highest RP Priority (see 913 below) is 0 (the lower the better). 915 Unicast BSR Address 916 The address of the bootstrap router for the domain. The format for 917 this address is given in the Encoded-Unicast address in RFC xxxx. 919 Group Address 1..n 920 The group prefix (address and mask) with which the Candidate RPs 921 are associated. Format described in RFC xxxx. In a fragment 922 containing admin scope ranges, the first group address in the 923 fragment MUST be the group range for the entire admin scope range, 924 and this MUST have the Admin Scope bit set. This is the case even 925 if there are no RPs in the RP set for the entire admin scope range 926 - in this case the sub-ranges for the RP set are specified later in 927 the fragment along with their RPs. 929 RP Count 1..n 930 The number of Candidate RP addresses included in the whole 931 Bootstrap message for the corresponding group prefix. A router does 932 not replace its old RP-Set for a given group prefix until/unless it 933 receives `RP-Count' addresses for that prefix; the addresses could 934 be carried over several fragments. If only part of the RP-Set for 935 a given group prefix was received, the router discards it, without 936 updating that specific group prefix's RP-Set. 938 Frag RP Cnt 1..m 939 The number of Candidate RP addresses included in this fragment of 940 the Bootstrap message, for the corresponding group prefix. The 941 `Frag RP-Cnt' field facilitates parsing of the RP-Set for a given 942 group prefix, when carried over more than one fragment. 944 RP address 1..m 945 The address of the Candidate RPs, for the corresponding group 946 prefix. The format for these addresses is given in the Encoded- 947 Unicast address in RFC xxxx. 949 RP1..m Holdtime 950 The Holdtime for the corresponding RP. This field is copied from 951 the `Holdtime' field of the associated RP stored at the BSR. 953 RP1..m Priority 954 The `Priority' of the corresponding RP and Encoded-Group Address. 955 This field is copied from the `Priority' field stored at the BSR 956 when receiving a Candidate-RP-Advertisement. The highest priority 957 is `0' (i.e. unlike BSR priority, the lower the value of the 958 `Priority' field, the better). Note that the priority is per RP 959 per Group Address. 961 4.2. Candidate-RP-Advertisement Format 963 Candidate-RP-Advertisements are periodically unicast from the C-RPs to 964 the BSR. 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 |PIM Ver| Type | Reserved | Checksum | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Prefix Cnt | Priority | Holdtime | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | RP Address (Encoded-Unicast format) | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Group Address 1 (Encoded-Group format) | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | . | 978 | . | 979 | . | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Group Address n (Encoded-Group format) | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 PIM Version, Reserved, Checksum 985 Described in RFC xxxx. 987 Type PIM Message Type. Value is 4 for a Candidate-RP-Advertisement 988 Message. 990 Prefix Cnt 991 The number of encoded group addresses included in the message; 992 indicating the group prefixes for which the C-RP is advertising. A 993 Prefix Cnt of `0' implies all multicast groups, e.g. for IPv4 a 994 prefix of 224.0.0.0 with mask length of 4. If the C-RP is not 995 configured with Group-prefix information, the C-RP puts a default 996 value of `0' in this field. 998 Priority 999 The `Priority' of the included RP, for the corresponding Encoded- 1000 Group Address (if any). highest priority is `0' (i.e. the lower 1001 the value of the `Priority' field, the higher the priority). This 1002 field is stored at the BSR upon receipt along with the RP address 1003 and corresponding Encoded-Group Address. 1005 Holdtime 1006 The amount of time the advertisement is valid. This field allows 1007 advertisements to be aged out. 1009 RP Address 1010 The address of the interface to advertise as a Candidate RP. The 1011 format for this address is given in the Encoded-Unicast address in 1012 RFC xxxx. 1014 Group Address-1..n 1015 The group prefixes for which the C-RP is advertising. Format 1016 described in Encoded-Group-Address in RFC xxxx. 1018 5. Default Values for Timers 1020 Timer Name: Bootstrap Timer (BST) 1022 +----------------------+------------------------+-----------------------+ 1023 | Value Name | Value | Explanation | 1024 +----------------------+------------------------+-----------------------+ 1025 | BS Period | Default: 60 secs | Period between | 1026 | | | bootstrap messages | 1027 +----------------------+------------------------+-----------------------+ 1028 | BS Timeout | 2 * BS_Period + 10 | Period after last | 1029 | | seconds | BS message before | 1030 | | | BSR is timed out | 1031 | | | and election | 1032 | | | begins | 1033 +----------------------+------------------------+-----------------------+ 1034 | BS randomized | rand(0, 5.0 secs) | Suppression period | 1035 | override interval | | in BSR election to | 1036 | | | prevent thrashing | 1037 +----------------------+------------------------+-----------------------+ 1039 Timer Name: C-RP Expiry Timer (CET(R)) 1041 +----------------+------------------+-----------------------------------+ 1042 | Value Name | Value | Explanation | 1043 +----------------+------------------+-----------------------------------+ 1044 | C-RP Timeout | from message | Hold time from C-RP-Adv message | 1045 +----------------+------------------+-----------------------------------+ 1046 C-RP Advertisement messages are sent periodically with period C-RP-Adv- 1047 Period. C-RP-Adv-Period defaults to 60 seconds. The holdtime to be 1048 specified in a C-RP-Adv message should be set to (2.5 * C-RP-Adv-Period 1049 ). 1051 Timer Name: C-RP Advertisement Timer (CRPT) 1053 +--------------------+--------------------------+-----------------------+ 1054 | Value Name | Value | Explanation | 1055 +--------------------+--------------------------+-----------------------+ 1056 | C-RP-Adv-Period | Default: 60 seconds | Period with which | 1057 | | | periodic C-RP | 1058 | | | Advertisements are | 1059 | | | sent to BSR | 1060 +--------------------+--------------------------+-----------------------+ 1062 Timer Name: Scope Zone Expiry Timer (SZT(Z)) 1064 +------------------------------------+--------------+-------------------+ 1065 |Value Name Value Explanation | | | 1066 +------------------------------------+--------------+-------------------+ 1067 |SZ Timeout |1500 seconds |Interval after | 1068 | | |which a scope zone | 1069 | | |will be timed out | 1070 | | |if the state is | 1071 | | |not refreshed | 1072 +------------------------------------+--------------+-------------------+ 1074 6. Authors' Addresses 1076 Bill Fenner 1077 AT&T Labs - Research 1078 75 Willow Road 1079 Menlo Park, CA 94025 1080 fenner@research.att.com 1082 Mark Handley 1083 ACIRI/ICSI 1084 1947 Center St, Suite 600 1085 Berkeley, CA 94708 1086 mjh@aciri.org 1087 David Thaler 1088 Microsoft Corporation 1089 One Microsoft Way 1090 Redmond, WA 98052 1091 dthaler@Exchange.Microsoft.com 1093 7. References 1095 [1] IANA, "Address Family Numbers", linked from 1096 http://www.iana.org/numbers.html 1098 8. Acknowledgments 1100 PIM-SM was designed over many years by a large group of people, 1101 including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve 1102 Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, 1103 Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, 1104 Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish 1105 Chandranmenon, and Pavlin Radoslavov. This BSR specification draws 1106 heavily on text from RFC 2362.