draft-ietf-pim-sm-bsr-03.txt

BCAST Implementation for NS2

The interval for sending these messages is subject to local
configuration at the C-RP, but must be smaller than the HoldTime in the
C-RP-Adv.

A Candidate-RP-Advertisement carries a list of group address and group
mask field pairs.  This enables the C-RP router to restrict the
advertisement to certain prefixes or scopes of groups.  If the C-RP
becomes an RP, it may enforce this scope acceptance when receiving
Registers or Join/Prune messages.

The C-RP priority field determines which C-RPs get selected by the BSR
to be in the RP Set.  Note that a value of zero is the highest possible
priority.  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 to
the BSR for each scope for which it is currently serving as an RP; the
HoldTime in this C-RP-Adv message should be zero.  The BSR will then
immediately time out the C-RP and generate a new BSR message removing
the shut down RP from the RPset.


3.2.  Creating the RP-Set at the BSR

Upon receiving a C-RP-Adv, if the router is not the elected BSR, it
silently ignores the message.

If the router is the BSR, then it adds the RP address to its local pool
of candidate RPs.  For each C-RP, the BSR holds the following
information:

     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 from



Fenner/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 of
available C-RPs.

The BSR uses the pool of C-RPs to construct the RP-Set which is included
in 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 RPs
included in the Bootstrap message.  The BSR may override the prefix
indicated in a C-RP-Adv unless the `Priority' field from the C-RP-Adv is
less than 128.

The Bootstrap message is subdivided into sets of {group-prefix, RP-
Count, RP-addresses}.  For each RP-address, the corresponding HoldTime
is included in the "RP-HoldTime" field.  The format of the Bootstrap
message allows `semantic fragmentation', if the length of the original
Bootstrap message exceeds the packet maximum boundaries. However, we
recommend against configuring a large number of routers as C-RPs, to
reduce the semantic fragmentation required.

When an elected BSR is being shut down, it should immediately originate
a Bootstrap message listing its current RP set, but with the BSR
priority field set to the lowest priority value possible.  This will
cause the election of a new BSR to happen more quickly.


3.3.  Forwarding Bootstrap Messages

Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by
intermediate routers if they pass the Bootstrap Message Processing
Check.  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 which
the message was received).  The exception to this is if the interface is
an administrative scope boundary for the admin scope zone indicated in
the first group address in the BS message packet.  The IP source address
on the bootstrap message should be set to the forwarding router's IP
address on the interface the message is being forwarded from.  Bootstrap
messages 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 2003


3.4.  Receiving and Using the RP-Set

When a router receives and stores a new RP-Set, it checks if each of the
RPs 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 and
the hash algorithm (see PIM-SM specification) is re-performed for each
group with locally active state that previously hashed to that RP. This
will 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 the
new C-RP's Group-prefix.  Any group for which the new RP's hash value is
greater than hash value of the group's previous RP is switched over to
the new RP.

4.  Message Formats

BSR messages are PIM messages, as defined in [3]. The values of the PIM
message Type field for BSR messages are:

4    Bootstrap Message

8    Candidate-RP-Advertisement

In this section we use the following terms defined in the PIM-SM [3]:

o    Encoded-Unicast format

o    Encoded-Group format

We repeat these here to aid readability.

Encoded-Unicast address

An 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 address

Encoded-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 2003


Mask 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 Format


A bootstrap message is divided up into `semantic fragments' if the
original message exceeds the maximum packet size boundaries.  Basically,
a single bootstrap message can be sent as multiple packets (semantic
fragments), so long as the fragment tags of all the packets comprising
the message is the same.

If the bootstrap message contains information about more than one admin
scope zone, each different scope zone MUST occupy a different semantic
fragment.  This allows Zone Border Routers for an admin scope zone to
not forward only those fragments that should not traverse the admin
scope 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