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

BCAST Implementation for NS2

|             RP Address m (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RPm Holdtime         | RPm Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


PIM Version, Reserved, Checksum
     Described in [3].

Type PIM Message Type.  Value is 4 for a Bootstrap Message.


Fragment Tag
     A randomly generated number, acts to distinguish the fragments
     belonging to different Bootstrap messages; fragments belonging to
     same Bootstrap message carry the same `Fragment Tag'.


Hash Mask len
     The length (in bits) of the mask to use in the hash function. For
     IPv4 we recommend a value of 30. For IPv6 we recommend a value of
     126.


BSR priority
     Contains the BSR priority value of the included BSR.  This field is
     considered as a high order byte when comparing BSR addresses.  Note
     that for historical reasons, the highest BSR priority priority is
     255 (the higher the better), whereas the highest RP Priority (see
     below) is 0 (the lower the better).


Unicast BSR Address
     The address of the bootstrap router for the domain.  The format for
     this address is given in the Encoded-Unicast address in [3].

Group Address 1..n
     The group prefix (address and mask) with which the Candidate RPs
     are associated.  Format described in [3]. In a fragment containing
     admin scope ranges, the first group address in the fragment MUST be
     the group range for the entire admin scope range, and this MUST
     have the Admin Scope bit set.  This is the case even if there are
     no RPs in the RP set for the entire admin scope range - in this
     case the sub-ranges for the RP set are specified later in the
     fragment along with their RPs.






Fenner/Handley/Kermode/Thaler                    Section 4.1.  [Page 25]

INTERNET-DRAFT            Expires: August 2003             February 2003


RP Count 1..n
     The number of Candidate RP addresses included in the whole
     Bootstrap message for the corresponding group prefix. A router does
     not replace its old RP-Set for a given group prefix until/unless it
     receives `RP-Count' addresses for that prefix; the addresses could
     be carried over several fragments.  If only part of the RP-Set for
     a given group prefix was received, the router discards it, without
     updating that specific group prefix's RP-Set.


Frag RP Cnt 1..m
     The number of Candidate RP addresses included in this fragment of
     the Bootstrap message, for the corresponding group prefix. The
     `Frag RP-Cnt' field facilitates parsing of the RP-Set for a given
     group prefix, when carried over more than one fragment.


RP address 1..m
     The address of the Candidate RPs, for the corresponding group
     prefix.  The format for these addresses is given in the Encoded-
     Unicast address in [3].

RP1..m Holdtime
     The Holdtime for the corresponding RP.  This field is copied from
     the `Holdtime' field of the associated RP stored at the BSR.


RP1..m Priority
     The `Priority' of the corresponding RP and Encoded-Group Address.
     This field is copied from the `Priority' field stored at the BSR
     when receiving a Candidate-RP-Advertisement.  The highest priority
     is `0' (i.e. unlike BSR priority, the lower the value of the
     `Priority' field, the better).  Note that the priority is per RP
     per Group Address.


4.1.1.  Semantic Fragmentation of BSMs

Bootstrap messages may be split over several PIM Bootstrap Message
Fragment (BSMF) packets; this is known as semantic fragmentation.  There
are two reasons for semantic fragmentation:

o    The BSM would exceed the link MTU the packet will be forwarded
     over.

o    The BSM includes information about more than one admin scope zone.





Fenner/Handley/Kermode/Thaler                  Section 4.1.1.  [Page 26]

INTERNET-DRAFT            Expires: August 2003             February 2003


Let us initially consider only the former case; the packet would be too
large because the set of group prefixes and the RPs for each group
prefix are too long to fit in one packet.  The BSR will then split the
BSM across several BSMF packets; each of these must be a well-formed
BSMF packet in its own right.

If the BSR can split up the BSM so that different group prefixes (and
their RP information) can fit in different fragments, then it should do
so.  If one of these BSMF packets is then lost, the state from the
previous BSM for the group-prefix from the missing packet will be
retained.  Each fragment that does arrive will update the RP information
for the group-prefixes contained in that fragment, and the new group-to-
RP mapping for those can be used immediately.  The information from the
missing fragment will be obtained when the BSM is next transmitted.  In
this case, whilst the Fragment Tag must be set to the same value for all
BSMFs comprising a single BSM, the tag is not actually used by routers
receiving the BSM.

If the list of RPs for a single group-prefix is too long to fit in a
single BSMF packet, then that information must be split across multiple
BSMF packets.  In this case, all the BSMF packets comprising the
information for that group-prefix must be received before the group-to-
RP mapping in use can be modified.  This is the purpose of the RP Count
field - a router receiving BSMF packets from the same BSM (ie that have
the same fragment tag) must wait until the BSMFs providing RP Count RPs
for that group-prefix have been received before the new group-to-RP
mapping can be used for that group-prefix.  In a single BSMF from such a
large group-prefix is lost, then that entire group-prefix will have to
wait until the next BSM is originated.

Next we need to consider how a BSR would remove group-prefixes from the
BSM.  A router receiving a set of BSMFs cannot tell if a group-prefix is
missing.  If it has seen a group-prefix before, it must assume that that
group-prefix still exists, and that the BSMF describing it has been
lost.  It should retain this information for BS Timeout seconds.  Thus
for a BSR to remove a group-prefix from the BSR, it should include that
group-prefix, but with a RP Count of zero, and it should resend this
information in each BSM for BS Timeout seconds.

Finally, we come to the case of fragments for the purpose of conveying
admin scope group-prefixes.  In general, the information for each admin
scope range is independent of information about other admin scope
ranges.  As no BSMF is allowed to convey information for more than one
admin scope range, then the procedure above also applies to BSMs that
are fragmented due to admin scoping.  However, to time out all the state
for an entire admin scope zone requires waiting SZ Timeout rather than
BS Timeout, as admin scope zones are not expected to come and go
frequently.



Fenner/Handley/Kermode/Thaler                  Section 4.1.1.  [Page 27]

INTERNET-DRAFT            Expires: August 2003             February 2003


4.2.  Candidate-RP-Advertisement Format

Candidate-RP-Advertisements are periodically unicast from the C-RPs to
the BSR.

 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Cnt    |   Priority    |           Holdtime            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address (Encoded-Unicast format)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address 1 (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address n (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


PIM Version, Reserved, Checksum
     Described in [3].

Type PIM Message Type.  Value is 8 for a Candidate-RP-Advertisement
     Message.


Prefix Cnt
     The number of encoded group addresses included in the message;
     indicating the group prefixes for which the C-RP is advertising. A
     Prefix Cnt of `0' implies all multicast groups, e.g. for IPv4 a
     prefix of 224.0.0.0 with mask length of 4.  If the C-RP is not
     configured with Group-prefix information, the C-RP puts a default
     value of `0' in this field.


Priority
     The `Priority' of the included RP, for the corresponding Encoded-
     Group Address (if any).  highest priority is `0' (i.e. the lower
     the value of the `Priority' field, the higher the priority). This
     field is stored at the BSR upon receipt along with the RP address
     and corresponding Encoded-Group Address.





Fenner/Handley/Kermode/Thaler                    Section 4.2.  [Page 28]

INTERNET-DRAFT            Expires: August 2003             February 2003


Holdtime
     The amount of time the advertisement is valid. This field allows
     advertisements to be aged out.


RP Address
     The address of the interface to advertise as a Candidate RP.  The
     format for this address is given in the Encoded-Unicast address in
     [3].

Group Address-1..n
     The group prefixes for which the C-RP is advertising.  Format
     described in Encoded-Group-Address in [3].

5.  Default Values for Timers

Timer Name: Bootstrap Timer (BST)


+-------------------+--------------------------+------------------------+
|  Value Name       |   Value                  |   Explanation          |
+-------------------+--------------------------+------------------------+
|  BS Period        |   Default: 60 secs       |   Period between       |
|                   |                          |   bootstrap messages   |
+-------------------+--------------------------+------------------------+
|  BS Timeout       |   2 * BS_Period + 10     |   Period after last    |
|                   |   seconds                |   BS message before    |
|                   |                          |   BSR is timed out     |
|                   |                          |   and election         |
|                   |                          |   begins               |
+-------------------+--------------------------+------------------------+
|  rand_override    |   rand(0, 5.0 secs)      |   Suppression period   |
|                   |                          |   in BSR election to   |
|                   |                          |   prevent thrashing    |
+-------------------+--------------------------+------------------------+

Timer Name: C-RP Expiry Timer (CET(R))


+----------------+------------------+-----------------------------------+
| Value Name     |  Value           |  Explanation                      |
+----------------+------------------+-----------------------------------+
| C-RP Timeout   |  from message    |  Hold time from C-RP-Adv message  |
+----------------+------------------+-----------------------------------+

C-RP Advertisement messages are sent periodically with period C-RP-Adv-
Period.  C-RP-Adv-Period defaults to 60 seconds.  The holdtime to be
specified in a C-RP-Adv message should be set to (2.5 * C-RP-Adv-Period



Fenner/Handley/Kermode/Thaler                      Section 5.  [Page 29]

INTERNET-DRAFT            Expires: August 2003             February 2003


).

Timer Name: C-RP Advertisement Timer (CRPT)


+--------------------+--------------------------+-----------------------+
| Value Name         |   Value                  |  Explanation          |
+--------------------+--------------------------+-----------------------+
| C-RP-Adv-Period    |   Default: 60 seconds    |  Period with which    |
|                    |                          |  periodic C-RP        |
|                    |                          |  Advertisements are   |
|                    |                          |  sent to BSR          |
+--------------------+--------------------------+-----------------------+

Timer Name: Scope Zone Expiry Timer (SZT(Z))


+------------------------------------+--------------+--------------------+
|Value Name      Value   Explanation |              |                    |
+------------------------------------+--------------+--------------------+
|SZ Timeout                          | 1300 seconds | Interval after     |
|                                    |              | which a scope zone |
|                                    |              | will be timed out  |
|                                    |              | if the state is    |
|                                    |              | not refreshed      |
+------------------------------------+--------------+--------------------+


6.  Security Considerations

6.1.  Possible Threats

Threats affecting the PIM BSR mechanism are primarily of two forms:
denial of service attacks, and traffic diversion attacks.  An attacker
that subverts the BSR mechanism can prevent multicast traffic from
reaching the intended recipients, can divert multicast traffic to a
place where they can monitor it, and can potentially flood third parties
with traffic.

Traffic can be prevented from reaching the intended recipients by one of
two mechanisms:

o    Subverting a BSM, and specifying RPs that won't actually forward
     traffic.

o    Registering with the BSR as a C-RP, and then not forwarding
     traffic.




Fenner/Handley/Kermode/Thaler                    Section 6.1.  [Page 30]

INTERNET-DRAFT