draft-ietf-pim-sm-bsr-05.txt   draft-ietf-pim-sm-bsr-06.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Nidhi Bhaskar/Cisco INTERNET-DRAFT Nidhi Bhaskar/Cisco
draft-ietf-pim-sm-bsr-05.txt Alexander Gall/SWITCH draft-ietf-pim-sm-bsr-06.txt Alexander Gall/SWITCH
James Lingard/Data Connection James Lingard
Stig Venaas/UNINETT Stig Venaas/UNINETT
18 February 2005 23 October 2005
Expires: August 2005 Expires: April 2006
Bootstrap Router (BSR) Mechanism for PIM Bootstrap Router (BSR) Mechanism for PIM
Status of this Document Status of this Document
By submitting this Internet-Draft, I certify that any applicable patent By submitting this Internet-Draft, each author represents that any
or other IPR claims of which I am aware have been disclosed, or will be applicable patent or other IPR claims of which he or she is aware have
disclosed, and any of which I become aware will be disclosed, in been or will be disclosed, and any of which he or she becomes aware will
accordance with RFC 3668. be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than a "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is a product of the IETF PIM WG. Comments should be This document is a product of the IETF PIM WG. Comments should be
addressed to the authors, or the WG's mailing list at pim@ietf.org. addressed to the authors, or the WG's mailing list at pim@ietf.org.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies the Bootstrap Router (BSR) mechanism This document specifies the Bootstrap Router (BSR) mechanism
for the class of multicast routing protocols in the PIM for the class of multicast routing protocols in the PIM
(Protocol Independent Multicast) family that use the concept (Protocol Independent Multicast) family that use the concept
of a Rendezvous Point as a means for receivers to discover the of a Rendezvous Point as a means for receivers to discover the
sources that send to a particular multicast group. BSR is one sources that send to a particular multicast group. BSR is one
way that a multicast router can learn the set of group-to-RP way that a multicast router can learn the set of group-to-RP
mappings required in order to function. The mechanism is mappings required in order to function. The mechanism is
dynamic, largely self-configuring, and robust to router dynamic, largely self-configuring, and robust to router
failure. failure.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . 5
1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 6 1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 7
1.3. Administrative Scoping and BSR . . . . . . . . . . . 7 1.3. Administrative Scoping and BSR . . . . . . . . . . . 8
2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 10
3. Bootstrap Router Election and RP-Set 3. Bootstrap Router Election and RP-Set
Distribution. . . . . . . . . . . . . . . . . . . . . . 9 Distribution. . . . . . . . . . . . . . . . . . . . . . 10
3.1. Bootstrap Router Election. . . . . . . . . . . . . . 9 3.1. Bootstrap Router Election. . . . . . . . . . . . . . 10
3.1.1. Per-Scope-Zone Candidate-BSR State 3.1.1. Per-Scope-Zone Candidate-BSR State
Machine . . . . . . . . . . . . . . . . . . . . . 10 Machine . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Per-Scope-Zone State Machine for Non- 3.1.2. Per-Scope-Zone State Machine for Non-
Candidate-BSR Routers . . . . . . . . . . . . . . 12 Candidate-BSR Routers . . . . . . . . . . . . . . 13
3.1.3. Bootstrap Message Processing Checks . . . . . . . 14 3.1.3. Bootstrap Message Processing Checks . . . . . . . 15
3.1.4. State Machine Transition Events . . . . . . . . . 14 3.1.4. State Machine Transition Events . . . . . . . . . 15
3.1.5. State Machine Actions . . . . . . . . . . . . . . 15 3.1.5. State Machine Actions . . . . . . . . . . . . . . 16
3.2. Sending Candidate-RP-Advertisement Messages. . . . . 16 3.2. Sending Candidate-RP-Advertisement Messages. . . . . 18
3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 18 3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 19
3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 20 3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 22
3.5. Unicasting Bootstrap Messages to New and 3.5. Unicasting Bootstrap Messages to New and
Rebooting Routers. . . . . . . . . . . . . . . . . . 21 Rebooting Routers. . . . . . . . . . . . . . . . . . 22
3.6. Receiving and Using the RP-Set . . . . . . . . . . . 21 3.6. Receiving and Using the RP-Set . . . . . . . . . . . 23
4. Message Formats . . . . . . . . . . . . . . . . . . . . 21 4. Message Formats . . . . . . . . . . . . . . . . . . . . 23
4.1. Bootstrap Message Format . . . . . . . . . . . . . . 24 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 25
4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 27 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 29
4.2. Candidate-RP-Advertisement Message Format. . . . . . 29 4.2. Candidate-RP-Advertisement Message Format. . . . . . 30
5. Timers and Timer Values . . . . . . . . . . . . . . . . 30 5. Timers and Timer Values . . . . . . . . . . . . . . . . 32
6. Security Considerations . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . 35
6.1. Possible Threats . . . . . . . . . . . . . . . . . . 33 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 35
6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 33 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 35
6.3. Bootstrap Message Security . . . . . . . . . . . . . 34 6.3. Bootstrap Message Security . . . . . . . . . . . . . 36
6.3.1. Rejecting Unicast Bootstrap Messages. . . . . . . 34 6.3.1. Rejecting Unicast Bootstrap Messages. . . . . . . 36
6.3.2. Rejecting Bootstrap Messages from Invalid 6.3.2. Rejecting Bootstrap Messages from Invalid
Neighbors . . . . . . . . . . . . . . . . . . . . 35 Neighbors . . . . . . . . . . . . . . . . . . . . 37
6.4. Candidate-RP-Advertisement Message Security. . . . . 35 6.4. Candidate-RP-Advertisement Message Security. . . . . 37
6.4.1. Non-Cryptographic Security of C-RP-Adv 6.4.1. Non-Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 35 Messages. . . . . . . . . . . . . . . . . . . . . 37
6.4.2. Cryptographic Security of C-RP-Adv 6.4.2. Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 36 Messages. . . . . . . . . . . . . . . . . . . . . 38
6.5. Denial of Service using IPsec. . . . . . . . . . . . 36 6.5. Denial of Service using IPsec. . . . . . . . . . . . 38
7. Contributors. . . . . . . . . . . . . . . . . . . . . . 37 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 39
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 37 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 39
9. IANA Considerations . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . 39
10. Normative References . . . . . . . . . . . . . . . . . 37 10. Normative References . . . . . . . . . . . . . . . . . 39
11. Informative References . . . . . . . . . . . . . . . . 38 11. Informative References . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document assumes some familiarity with the concepts of Protocol This document assumes some familiarity with the concepts of Protocol
Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi- Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi-
directional Protocol Independent Multicast (BIDIR-PIM), as defined in directional Protocol Independent Multicast (BIDIR-PIM), as defined in
[2], as well as with Administratively Scoped IP Multicast, as described [2], as well as with Administratively Scoped IP Multicast, as described
in [3], and the IPv6 Scoped Address Architecture, described in [4]. in [3], and the IPv6 Scoped Address Architecture, described in [4].
For correct operation, every multicast router within a PIM domain must For correct operation, every multicast router within a PIM domain must
skipping to change at page 10, line 26 skipping to change at page 10, line 26
message is called a non-scoped BSM. message is called a non-scoped BSM.
In a scoped IPv4 BSM, the scope of the message is given by the first In a scoped IPv4 BSM, the scope of the message is given by the first
group range in the message, which can be any sub-range of 224/4. In a group range in the message, which can be any sub-range of 224/4. In a
scoped IPv6 BSM, the scope of the message is given by the scope ID of scoped IPv6 BSM, the scope of the message is given by the scope ID of
the first group range in the message, which must have a mask length of the first group range in the message, which must have a mask length of
at least 16. For example, a group range of ff05::/16 with the Admin at least 16. For example, a group range of ff05::/16 with the Admin
Scope Zone bit set indicates that the Bootstrap message is for the scope Scope Zone bit set indicates that the Bootstrap message is for the scope
with scope ID 5. If the mask length of the first group range in a with scope ID 5. If the mask length of the first group range in a
scoped IPv6 BSM is less than 16, the message MUST be dropped and a scoped IPv6 BSM is less than 16, the message MUST be dropped and a
warning SHOULD is logged. warning SHOULD be logged.
The state machine for Bootstrap messages depends on whether or not a The state machine for Bootstrap messages depends on whether or not a
router has been configured to be a Candidate-BSR for a particular scope router has been configured to be a Candidate-BSR for a particular scope
zone. The per-scope-zone state machine for a C-BSR is given below, zone. The per-scope-zone state machine for a C-BSR is given below,
followed by the state machine for a router that is not configured to be followed by the state machine for a router that is not configured to be
a C-BSR. a C-BSR.
3.1.1. Per-Scope-Zone Candidate-BSR State Machine 3.1.1. Per-Scope-Zone Candidate-BSR State Machine
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
skipping to change at page 12, line 12 skipping to change at page 12, line 12
The router is the elected BSR for the scope zone and it must The router is the elected BSR for the scope zone and it must
perform all the BSR functions. perform all the BSR functions.
In addition to the three states, there is one timer: In addition to the three states, there is one timer:
o The Bootstrap Timer (BST) - used to time out old bootstrap router o The Bootstrap Timer (BST) - used to time out old bootstrap router
information, and used in the election process to terminate P-BSR information, and used in the election process to terminate P-BSR
state. state.
On startup, the initial state for this configured scope zone is On startup, the initial state for this configured scope zone is
"Pending-BSR"; the Bootstrap Timer is initialized to the BS_Timeout "Pending-BSR"; the Bootstrap Timer is initialized to BS_Rand_Override.
value.
3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers 3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in NoInfo state | | When in NoInfo state |
+---------------------+-------------------------------------------------+ +---------------------+-------------------------------------------------+
| Event | Receive BSM | | Event | Receive BSM |
+---------------------+-------------------------------------------------+ +---------------------+-------------------------------------------------+
| | -> AP state | | | -> AP state |
| Action | Forward BSM; Store RP-Set; | | Action | Forward BSM; Store RP-Set; |
skipping to change at page 15, line 7 skipping to change at page 15, line 7
If the Bootstrap message passes the initial checks above without being If the Bootstrap message passes the initial checks above without being
discarded, then it may cause a state transition event in one of the discarded, then it may cause a state transition event in one of the
above state machines. For both candidate and non-candidate BSRs, the above state machines. For both candidate and non-candidate BSRs, the
following transition events are defined: following transition events are defined:
Receive Preferred BSM Receive Preferred BSM
A Bootstrap message is received from a BSR that has higher or A Bootstrap message is received from a BSR that has higher or
equal weight than the current BSR. If a router is in P-BSR equal weight than the current BSR. If a router is in P-BSR
state, then it uses its own weight as that of the current BSR. state, then it uses its own weight as that of the current BSR.
A Bootstrap message is also preferred if it is from the
current BSR with a lower weight than the previous BSM it sent,
provided that if the router is a Candidate BSR the current BSR
still has a weight higher or equal than the router itself. In
this case, the "Current Bootstrap Router's BSR Priority" state
must be updated. (For lower weight, see Non-preferred BSM from
Elected BSR case.)
The weight of a BSR is defined to be the concatenation in The weight of a BSR is defined to be the concatenation in
fixed-precision unsigned arithmetic of the BSR Priority field fixed-precision unsigned arithmetic of the BSR Priority field
from the Bootstrap message and the IP address of the BSR from from the Bootstrap message and the IP address of the BSR from
the Bootstrap message (with the BSR Priority taking the most- the Bootstrap message (with the BSR Priority taking the most-
significant bits and the IP address taking the least significant bits and the IP address taking the least
significant bits). significant bits).
Receive Non-preferred BSM Receive Non-preferred BSM
A Bootstrap message is received from a BSR that has lower A Bootstrap message is received from a BSR that has lower
weight than the current BSR. If a router is in P-BSR state, weight than the current BSR. If a router is in P-BSR state,
skipping to change at page 16, line 4 skipping to change at page 16, line 12
A Bootstrap message that passes the Bootstrap Message A Bootstrap message that passes the Bootstrap Message
Processing Checks is forwarded out of all interfaces with PIM Processing Checks is forwarded out of all interfaces with PIM
neighbors (including the interface it is received on), except neighbors (including the interface it is received on), except
where this would cause the BSM to cross an admin-scope where this would cause the BSM to cross an admin-scope
boundary for the scope zone indicated in the message. For boundary for the scope zone indicated in the message. For
details, see section 3.4. details, see section 3.4.
Originate BSM Originate BSM
A new Bootstrap message is constructed by the BSR, giving the A new Bootstrap message is constructed by the BSR, giving the
BSR's address and BSR priority, and containing the BSR's BSR's address and BSR priority, and containing the BSR's
chosen RP-Set. The message is forwarded out of all multicast- chosen RP-Set. The message is forwarded out of all interfaces
capable interfaces, except where this would cause the BSM to on which PIM neighbors exist, except where this would cause
cross an admin-scope boundary for the scope zone indicated in the BSM to cross an admin-scope boundary for the scope zone
the message. indicated in the message.
Store RP-Set Store RP-Set
The router uses the group-to-RP mappings contained in a BSM to The router uses the group-to-RP mappings contained in a BSM to
update its local RP-Set. update its local RP-Set.
This action is skipped for an empty BSM. A BSM is empty if it
contains no group ranges, or if it only contains a single
group range where that group range has the Admin Scope Zone
bit set (a scoped BSM) and an RP count of zero.
If a mapping does not yet exist, it is created and the If a mapping does not yet exist, it is created and the
associated Group-to-RP mapping Expiry Timer (GET) is associated Group-to-RP mapping Expiry Timer (GET) is
initialized with the holdtime from the BSM. initialized with the holdtime from the BSM.
If a mapping already exists, its GET is set to the holdtime If a mapping already exists, its GET is set to the holdtime
from the BSM. If the holdtime is zero, the mapping is removed from the BSM. If the holdtime is zero, the mapping is removed
immediately. immediately. Note that for an existing mapping, the RP
priority must be updated if changed.
Mappings for a group range are also to be immediately removed
if they are not present in the received group range. This
means that if there are any existing Group-to-RP mappings for
a range where the respective RPs are not in the received
range, then those mappings must be removed.
All RP mappings associated with the scope zone of the BSM are All RP mappings associated with the scope zone of the BSM are
updated with the new hash mask length from the received BSM. updated with the new hash mask length from the received BSM.
This includes any RP mappings learned from the current BSR but This includes any RP mappings learned from the current BSR but
not contained in the received BSM, as well as any RP mappings not contained in the received BSM, as well as any RP mappings
learned from any previous BSR for the scope zone. learned from any previous BSR for the scope zone.
In addition, the entire BSM is stored for use in the action In addition, the entire BSM is stored for use in the action
Refresh RP-Set and to prime a new PIM neighbor as described Refresh RP-Set and to prime a new PIM neighbor as described
below. below.
skipping to change at page 16, line 49 skipping to change at page 17, line 23
Remove BSR state Remove BSR state
When the Bootstrap Timer expires, all state associated with When the Bootstrap Timer expires, all state associated with
the current BSR is removed (see section 2). Note that this the current BSR is removed (see section 2). Note that this
does not include any group-to-RP mappings. does not include any group-to-RP mappings.
3.2. Sending Candidate-RP-Advertisement Messages 3.2. Sending Candidate-RP-Advertisement Messages
Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each
scope zone for which it has state, to inform the BSR of the C-RP's scope zone for which it has state, to inform the BSR of the C-RP's
willingness to function as an RP. These messages are sent with an willingness to function as an RP. These messages are sent with an
interval of C_RP_Adv_Period. interval of C_RP_Adv_Period, except when a new BSR is elected, see
below.
[NOTE: possible optimization: prime the CRPT with a small random value When a new BSR is elected, the C-RP SHOULD send one to three C-RP-Adv
when a new BSR is elected. This will allow the newly elected BSR to messages, waiting a randomized amount of 0-3 seconds before sending each
learn group mappings fast.] message. We recommend sending three messages because it is important
that the BSR quickly learns which RPs are active, and some packet loss
may occur when a new BSR is elected due to changes in the network. One
way of implementing this is to set the CRPT to 0-3 seconds when the new
BSR is elected, as well as setting a counter to 2. Whenever the CRPT
expires, we first send a C-RP-Adv message as usual. Next, if the
counter is non-zero, it is decremented and the CRPT is again set to 0-3
seconds instead of C_RP_Adv_Period.
[NOTE: what happens if the message becomes too large to fit in a single [NOTE: Add a name for this timer and counter?]
packet? With the per-mapping timers, it's not a problem to send several
advertisements. We need to say something about this.]
The Priority field in these messages is used by the BSR to select which The Priority field in these messages is used by the BSR to select which
C-RPs to include in the RP-Set. Note that lower values of this field C-RPs to include in the RP-Set. Note that lower values of this field
indicate higher priorities, so that a value of zero is the highest indicate higher priorities, so that a value of zero is the highest
possible priority. C-RPs should by default send C-RP-Adv messages with possible priority. C-RPs should by default send C-RP-Adv messages with
the Priority field set to 192. the Priority field set to 192.
When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv
message to the BSR for each scope zone for which it is currently serving message to the BSR for each scope zone for which it is currently serving
as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR
skipping to change at page 18, line 49 skipping to change at page 19, line 26
set to the Priority from the C-RP-Adv message. set to the Priority from the C-RP-Adv message.
If the mapping is already part of the C-RP-Set, it is updated with the If the mapping is already part of the C-RP-Set, it is updated with the
Priority from the C-RP-Adv message and its associated CGET is reset to Priority from the C-RP-Adv message and its associated CGET is reset to
the holdtime from the C-RP-Adv message. If the holdtime is zero, the the holdtime from the C-RP-Adv message. If the holdtime is zero, the
mapping is immediately removed from the C-RP-Set. mapping is immediately removed from the C-RP-Set.
The hash mask length is a global property of the BSR and is therefore The hash mask length is a global property of the BSR and is therefore
the same for all mappings managed by the BSR. the same for all mappings managed by the BSR.
[NOTE: This is substantially different from version 03, where state was
kept per C-RP. The behaviour is the same if a C-RP always sends all
advertisements in a single message. However, there seems to be no
requirement for this (and the case where all advertisements don't fit in
a single message seems not to be covered). Keeping state per group
mapping allows a C-RP to send C-RP-Adv messages in chunks and even
allows for different holdtimes for different group ranges (which may or
may not be useful) while being compatible with the old version.]
For compatibility with the previous version of the BSR specification, a For compatibility with the previous version of the BSR specification, a
C-RP-Adv message with no group ranges SHOULD be treated as though it C-RP-Adv message with no group ranges SHOULD be treated as though it
contained the single group range ff00::/8 or 224/4. Therefore, contained the single group range ff00::/8 or 224/4. Therefore,
according to the rule above, this group range will be accepted if and according to the rule above, this group range will be accepted if and
only if the router is elected as the non-scoped BSR. only if the router is elected as the non-scoped BSR.
When a CGET expires, the corresponding group-to-C-RP mapping is removed When a CGET expires, the corresponding group-to-C-RP mapping is removed
from the C-RP-Set. from the C-RP-Set.
The BSR constructs the RP-Set from the C-RP-Set. It may apply a local The BSR constructs the RP-Set from the C-RP-Set. It may apply a local
skipping to change at page 19, line 32 skipping to change at page 19, line 48
`Priority' field from the C-RP-Adv message is less than 128. `Priority' field from the C-RP-Adv message is less than 128.
For inclusion in a BSM, the RP-Set is subdivided into sets of {group- For inclusion in a BSM, the RP-Set is subdivided into sets of {group-
prefix, RP-Count, RP-addresses}. For each RP-address, the corresponding prefix, RP-Count, RP-addresses}. For each RP-address, the corresponding
Holdtime is included in the "RP-Holdtime" field. The format of the Holdtime is included in the "RP-Holdtime" field. The format of the
Bootstrap message allows `semantic fragmentation', if the length of the Bootstrap message allows `semantic fragmentation', if the length of the
original Bootstrap message exceeds the packet maximum boundaries. original Bootstrap message exceeds the packet maximum boundaries.
However, we recommend against configuring a large number of routers as However, we recommend against configuring a large number of routers as
C-RPs, to reduce the semantic fragmentation required. C-RPs, to reduce the semantic fragmentation required.
In general BSMs are originated at regular intervals according to the
BS_Period timer. We do recommend that a BSM is also originated whenever
the RP-set to be announced in the BSMs changes. This will usually
happen when receiving C-RP advertisements from a new C-RP, or when a C-
RP is shut down (C-RP advertisement with a holdtime of zero). There
MUST however be a minimum of 10 seconds between each time a BSM is sent.
In particular, when a new BSR is elected, it will first send one BSM
(which is likely to be empty since it has not yet received any C-RP
advertisements), and then wait at least 10 seconds before sending a new
one. During those 10 seconds, it is likely to have received C-RP
advertisements from all usable C-RPs (since we say that a C-RP should
send one or more advertisements with small random delays of 0-3 seconds
when a new BSR is elected). For this case in particular, where routers
may not have a usable RP-set, we recommend originating a BSM as soon as
those 10 seconds have passed. We suggest though that a BSR can do this
in general. One way of implementing this, is to decrease the Bootstrap
Timer to 10 seconds whenever the RP-set changes, while not changing the
timer if it is less or equal to 10.
[NOTE: Add a name for this 10s value as a function of the 0-3s random
delay?]
A BSR originates separate scoped BSMs for each scope zone for which it A BSR originates separate scoped BSMs for each scope zone for which it
is the elected BSR, as well as originating non-scoped BSMs if it is the is the elected BSR, as well as originating non-scoped BSMs if it is the
elected non-scoped BSR. elected non-scoped BSR.
Each group-to-C-RP mapping is included in precisely one of these BSM, Each group-to-C-RP mapping is included in precisely one of these BSM,
namely the scoped BSM for the narrowest scope containing the group range namely the scoped BSM for the narrowest scope containing the group range
of the mapping, if any, or the non-scoped BSM otherwise. of the mapping, if any, or the non-scoped BSM otherwise.
A scoped BSM MUST have at least one group range, and the first group A scoped BSM MUST have at least one group range, and the first group
range in a scoped BSM MUST have the "Admin Scope Zone" bit set. This range in a scoped BSM MUST have the "Admin Scope Zone" bit set. This
skipping to change at page 24, line 13 skipping to change at page 25, line 4
native encoding and 128 for IPv6 native encoding). native encoding and 128 for IPv6 native encoding).
Group multicast Address Group multicast Address
Contains the group address. Contains the group address.
4.1. Bootstrap Message Format 4.1. Bootstrap Message Format
A Bootstrap message is divided up into `semantic fragments' if the A Bootstrap message is divided up into `semantic fragments' if the
original message exceeds the maximum packet size boundaries. Basically, original message exceeds the maximum packet size boundaries. Basically,
a single Bootstrap message can be sent as multiple packets (semantic a single Bootstrap message can be sent as multiple packets (semantic
fragments), so long as the fragment tags of all the packets comprising fragments), so long as the fragment tags of all the packets comprising
the message is the same. 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: The format of a single `fragment' is given below:
0 1 2 3 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 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 | |PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask Len | BSR Priority | | Fragment Tag | Hash Mask Len | BSR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSR Address (Encoded-Unicast format) | | BSR Address (Encoded-Unicast format) |
skipping to change at page 26, line 40 skipping to change at page 27, line 40
that for historical reasons, the highest BSR priority is 255 (the that for historical reasons, the highest BSR priority is 255 (the
higher the better), whereas the highest RP Priority (see below) is higher the better), whereas the highest RP Priority (see below) is
0 (the lower the better). 0 (the lower the better).
BSR Address BSR Address
The address of the bootstrap router for the domain. The format for The address of the bootstrap router for the domain. The format for
this address is given in the Encoded-Unicast address in [1]. this address is given in the Encoded-Unicast address in [1].
Group Address 1..n Group Address 1..n
The group prefix (address and mask) with which the Candidate-RPs The group prefix (address and mask) with which the Candidate-RPs
are associated. Format described in [1]. In an fragment are associated. Format described in [1]. In a fragment containing
containing admin scope ranges, the first group address in the admin scope ranges, the first group address in the fragment MUST
fragment MUST satisfy the following conditions: it MUST have the satisfy the following conditions: it MUST have the Admin Scope bit
Admin Scope bit set; for IPv4 it MUST be the group range for the set; for IPv4 it MUST be the group range for the entire admin scope
entire admin scope range; for IPv6 the Mask Len MUST be at least 16 range (this is the case even if there are no RPs in the RP-Set for
and have the scope ID of the admin scope range. This is the case the entire admin scope range - in this case the sub-ranges for the
even if there are no RPs in the RP-Set for the entire admin scope RP-Set are specified later in the fragment along with their RPs);
range - in this case the sub-ranges for the RP-Set are specified for IPv6 the Mask Len MUST be at least 16 and have the scope ID of
later in the fragment along with their RPs. the admin scope range.
RP Count 1..n RP Count 1..n
The number of Candidate-RP addresses included in the whole The number of Candidate-RP addresses included in the whole
Bootstrap message for the corresponding group prefix. A router Bootstrap message for the corresponding group prefix. A router
does not replace its old RP-Set for a given group prefix does not replace its old RP-Set for a given group prefix
until/unless it receives `RP-Count' addresses for that prefix; the until/unless it receives `RP-Count' addresses for that prefix; the
addresses could be carried over several fragments. If only part of addresses could be carried over several fragments. If only part of
the RP-Set for a given group prefix was received, the router the RP-Set for a given group prefix was received, the router
discards it, without updating that specific group prefix's RP-Set. discards it, without updating that specific group prefix's RP-Set.
skipping to change at page 27, line 44 skipping to change at page 28, line 47
Within a Bootstrap message, the BSR Address, all the Group Addresses and Within a Bootstrap message, the BSR Address, all the Group Addresses and
all the RP Addresses MUST be of the same address family. In addition, all the RP Addresses MUST be of the same address family. In addition,
the address family of the fields in the message MUST be the same as the the address family of the fields in the message MUST be the same as the
IP source and destination addresses of the packet. This permits maximum IP source and destination addresses of the packet. This permits maximum
implementation flexibility for dual-stack IPv4/IPv6 routers. implementation flexibility for dual-stack IPv4/IPv6 routers.
4.1.1. Semantic Fragmentation of BSMs 4.1.1. Semantic Fragmentation of BSMs
Bootstrap messages may be split over several PIM Bootstrap Message Bootstrap messages may be split over several PIM Bootstrap Message
Fragment (BSMF) packets; this is known as semantic fragmentation. There Fragment (BSMF) packets; this is known as semantic fragmentation. It is
are two reasons for semantic fragmentation: needed when the BSM would exceed the MTU of the link the packet will be
forwarded over.
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. 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
Let us initially consider only the former case; the packet would be too will then split the BSM across several BSMF packets; each of these must
large because the set of group prefixes and the RPs for each group be a well-formed BSMF packet in its own right.
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 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 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 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 previous BSM for the group-prefix from the missing packet will be
retained. Each fragment that does arrive will update the RP information retained. Each fragment that does arrive will update the RP information
for the group-prefixes contained in that fragment, and the new group-to- 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 RP mapping for those can be used immediately. The information from the
missing fragment will be obtained when the BSM is next transmitted. In 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 this case, whilst the Fragment Tag must be set to the same value for all
skipping to change at page 28, line 44 skipping to change at page 30, line 5
Next we need to consider how a BSR would remove group-prefixes from the 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 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 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 group-prefix still exists, and that the BSMF describing it has been
lost. It should retain this information for BS_Timeout. Thus for a BSR lost. It should retain this information for BS_Timeout. Thus for a BSR
to remove a group-prefix from the BSR, it should include that group- 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 prefix, but with a RP Count of zero, and it should resend this
information in each BSM for BS_Timeout. information in each BSM for BS_Timeout.
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.
4.2. Candidate-RP-Advertisement Message Format 4.2. Candidate-RP-Advertisement Message Format
Candidate-RP-Advertisement messages are periodically unicast from the C- Candidate-RP-Advertisement messages are periodically unicast from the C-
RPs to the BSR. RPs to the BSR.
0 1 2 3 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 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 | |PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 37, line 45 skipping to change at page 38, line 45
v2-new-11.txt v2-new-11.txt
[2] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional [2] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft- Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft-
ietf-pim-bidir-07.txt ietf-pim-bidir-07.txt
[3] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul [3] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul
1998. 1998.
[4] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill, "IPv6 [4] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill, "IPv6
Scoped Address Architecture", Internet Draft draft-ietf- Scoped Address Architecture", RFC 4007, Mar 2005.
ipv6-scoping-arch-02.txt
[5] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6) [5] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, Apr 2003. Addressing Architecture", RFC 3513, Apr 2003.
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, Mar 1997. Levels", BCP 14, RFC 2119, Mar 1997.
11. Informative References 11. Informative References
[7] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode [7] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification", RFC 2362, June 1998 (now (PIM-SM): Protocol Specification", RFC 2362, June 1998 (now
obsolete). obsolete).
[8] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point [8] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point
(RP) mechanism using Protocol Independent Multicast (PIM) and (RP) mechanism using Protocol Independent Multicast (PIM) and
Multicast Source Discovery Protocol (MSDP)", RFC 3446, Jan 2003. Multicast Source Discovery Protocol (MSDP)", RFC 3446, Jan 2003.
[9] D. Farinacci, Y. Cai, "Anycast-RP using PIM", Internet Draft draft- [9] D. Farinacci, Y. Cai, "Anycast-RP using PIM", Internet Draft draft-
ietf-pim-anycast-rp-02.txt ietf-pim-anycast-rp-04.txt
[10] IANA, "Address Family Numbers", linked from [10] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
Authors' Addresses Authors' Addresses
Nidhi Bhaskar Nidhi Bhaskar
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 38, line 44 skipping to change at page 39, line 44
CH-8021 Zurich CH-8021 Zurich
Switzerland Switzerland
gall@switch.ch gall@switch.ch
James Lingard James Lingard
Data Connection Ltd Data Connection Ltd
100 Church Street 100 Church Street
Enfield Enfield
EN2 6BQ EN2 6BQ
United Kingdom United Kingdom
james.lingard@dataconnection.com james@lingard.com
Stig Venaas Stig Venaas
UNINETT UNINETT
NO-7465 Trondheim NO-7465 Trondheim
Norway Norway
venaas@uninett.no venaas@uninett.no
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject to Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
 End of changes. 37 change blocks. 
115 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/