The interval for sending these messages is subject to localconfiguration at the C-RP, but must be smaller than the HoldTime in theC-RP-Adv.A Candidate-RP-Advertisement carries a list of group address and groupmask field pairs.  This enables the C-RP router to restrict theadvertisement to certain prefixes or scopes of groups.  If the C-RPbecomes an RP, it may enforce this scope acceptance when receivingRegisters or Join/Prune messages.The C-RP priority field determines which C-RPs get selected by the BSRto be in the RP Set.  Note that a value of zero is the highest possiblepriority.  C-RPs should by default send C-RP-Adv messages with the`Priority' field set to 192.When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv tothe BSR for each scope for which it is currently serving as an RP; theHoldTime in this C-RP-Adv message should be zero.  The BSR will thenimmediately time out the C-RP and generate a new BSR message removingthe shut down RP from the RPset.3.2.  Creating the RP-Set at the BSRUpon receiving a C-RP-Adv, if the router is not the elected BSR, itsilently ignores the message.If the router is the BSR, then it adds the RP address to its local poolof candidate RPs.  For each C-RP, the BSR holds the followinginformation:     IP address          The IP address of the C-RP.     Group Prefix and Mask list          The list of group prefixes and group masks from the C-RP          advertisement.     HoldTime          The HoldTime from the C-RP-Adv message.  This is included          later in the RP-set information in the Bootstrap Message.     C-RP Expiry Timer          The C-RP-Expiry Timer is used to time out the state associated          with a C-RP when the BSR fails to receive C-RP-Advertisements          from it.  The expiry timer is initialized to the HoldTime fromFenner/Handley/Kermode/Thaler                    Section 3.2.  [Page 19]INTERNET-DRAFT            Expires: August 2003             February 2003          the RP's C-RP-Adv, and is reset to the HoldTime whenever a C-          RP-Adv is received from that C-RP.     C-RP Priority          The C-RP Priority is used to determine the subset of possible          RPs to use in the RP-Set. Smaller values are deemed to be of          higher priority than large ones.When the C-RP Expiry Timer expires, the C-RP is removed from the pool ofavailable C-RPs.The BSR uses the pool of C-RPs to construct the RP-Set which is includedin Bootstrap Messages and sent to all the routers in the PIM domain.The BSR may apply a local policy to limit the number of Candidate RPsincluded in the Bootstrap message.  The BSR may override the prefixindicated in a C-RP-Adv unless the `Priority' field from the C-RP-Adv isless than 128.The Bootstrap message is subdivided into sets of {group-prefix, RP-Count, RP-addresses}.  For each RP-address, the corresponding HoldTimeis included in the "RP-HoldTime" field.  The format of the Bootstrapmessage allows `semantic fragmentation', if the length of the originalBootstrap message exceeds the packet maximum boundaries. However, werecommend against configuring a large number of routers as C-RPs, toreduce the semantic fragmentation required.When an elected BSR is being shut down, it should immediately originatea Bootstrap message listing its current RP set, but with the BSRpriority field set to the lowest priority value possible.  This willcause the election of a new BSR to happen more quickly.3.3.  Forwarding Bootstrap MessagesBootstrap messages originate at the BSR, and are hop-by-hop forwarded byintermediate routers if they pass the Bootstrap Message ProcessingCheck.  Bootstrap messages are multicast to the `ALL-PIM-ROUTERS' group.When a BS message is forwarded, it is forwarded out of every multicast-capable interface which has PIM neighbors (excluding the one over whichthe message was received).  The exception to this is if the interface isan administrative scope boundary for the admin scope zone indicated inthe first group address in the BS message packet.  The IP source addresson the bootstrap message should be set to the forwarding router's IPaddress on the interface the message is being forwarded from.  Bootstrapmessages are always originated or forwarded with an IP TTL value of 1.Fenner/Handley/Kermode/Thaler                    Section 3.3.  [Page 20]INTERNET-DRAFT            Expires: August 2003             February 20033.4.  Receiving and Using the RP-SetWhen a router receives and stores a new RP-Set, it checks if each of theRPs referred to by existing state (i.e., by (*,G), (*,*,RP), or(S,G,rpt) entries) is in the new RP-Set.If an RP is not in the new RP-Set, that RP is considered unreachable andthe hash algorithm (see PIM-SM specification) is re-performed for eachgroup with locally active state that previously hashed to that RP. Thiswill cause those groups to be distributed among the remaining RPs.If the new RP-Set contains a RP that was not previously in the RP-Set,the hash value of the new RP is calculated for each group covered by thenew C-RP's Group-prefix.  Any group for which the new RP's hash value isgreater than hash value of the group's previous RP is switched over tothe new RP.4.  Message FormatsBSR messages are PIM messages, as defined in [3]. The values of the PIMmessage Type field for BSR messages are:4    Bootstrap Message8    Candidate-RP-AdvertisementIn this section we use the following terms defined in the PIM-SM [3]:o    Encoded-Unicast formato    Encoded-Group formatWe repeat these here to aid readability.Encoded-Unicast addressAn Encoded-Unicast address takes the following format: 0                   1                   2                   3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|  Addr Family  | Encoding Type |     Unicast Address+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...Addr Family     The PIM address family of the `Unicast Address' field of this     address.Fenner/Handley/Kermode/Thaler                      Section 4.  [Page 21]INTERNET-DRAFT            Expires: August 2003             February 2003     Values of 0-127 are as assigned by the IANA for Internet Address     Families in [5]. Values 128-250 are reserved to be assigned by the     IANA for PIM-specific Address Families.  Values 251 though 255 are     designated for private use.  As there is no assignment authority     for this space, collisions should be expected.Encoding Type     The type of encoding used within a specific Address Family.  The     value `0' is reserved for this field, and represents the native     encoding of the Address Family.Unicast Address     The unicast address as represented by the given Address Family and     Encoding Type.Encoded-Group addressEncoded-Group addresses take the following format: 0                   1                   2                   3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|  Addr Family  | Encoding Type |   Reserved  |Z|  Mask Len     |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                Group multicast Address+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...Addr Family     described above.Encoding Type     described above.Reserved     Transmitted as zero. Ignored upon receipt.Admin Scope [Z]one     When set, this bit indicates that this group address range is an     administratively scoped range.Fenner/Handley/Kermode/Thaler                      Section 4.  [Page 22]INTERNET-DRAFT            Expires: August 2003             February 2003Mask Len     The Mask length field is 8 bits. The value is the number of     contiguous one bits left justified used as a mask which, combined     with the group address, describes a range of groups. It is less     than or equal to the address length in bits for the given Address     Family and Encoding Type. If the message is sent for a single group     then the Mask length must equal the address length in bits for the     given Address Family and Encoding Type.  (e.g. 32 for IPv4 native     encoding and 128 for IPv6 native encoding).Group multicast Address     Contains the group address.4.1.  Bootstrap Message FormatA bootstrap message is divided up into `semantic fragments' if theoriginal message exceeds the maximum packet size boundaries.  Basically,a single bootstrap message can be sent as multiple packets (semanticfragments), so long as the fragment tags of all the packets comprisingthe message is the same.If the bootstrap message contains information about more than one adminscope zone, each different scope zone MUST occupy a different semanticfragment.  This allows Zone Border Routers for an admin scope zone tonot forward only those fragments that should not traverse the adminscope boundary.The format of a single `fragment' is given below:Fenner/Handley/Kermode/Thaler                    Section 4.1.  [Page 23]INTERNET-DRAFT            Expires: August 2003             February 2003 0                   1                   2                   3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|PIM Ver| Type  |   Reserved    |           Checksum            |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|         Fragment Tag          | Hash Mask len | BSR-priority  |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|             BSR Address (Encoded-Unicast format)              |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|            Group Address 1 (Encoded-Group format)             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RP Count 1    | Frag RP Cnt 1 |         Reserved              |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|             RP Address 1 (Encoded-Unicast format)             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|          RP1 Holdtime         | RP1 Priority  |   Reserved    |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|             RP Address 2 (Encoded-Unicast format)             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|          RP2 Holdtime         | RP2 Priority  |   Reserved    |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                               .                               ||                               .                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|             RP Address m (Encoded-Unicast format)             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|          RPm Holdtime         | RPm Priority  |   Reserved    |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|            Group Address 2 (Encoded-Group format)             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                               .                               ||                               .                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|            Group Address n (Encoded-Group format)             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RP Count n    | Frag RP Cnt n |          Reserved             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|             RP Address 1 (Encoded-Unicast format)             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|          RP1 Holdtime         | RP1 Priority  |   Reserved    |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|             RP Address 2 (Encoded-Unicast format)             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|          RP2 Holdtime         | RP2 Priority  |   Reserved    |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                               .                               ||                               .                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Fenner/Handley/Kermode/Thaler                    Section 4.1.  [Page 24]INTERNET-DRAFT            Expires: August 2003             February 2003