draft-ietf-pim-sm-bsr-03.txt   draft-ietf-pim-sm-bsr-04.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Bill Fenner/AT&T INTERNET-DRAFT Nidhi Bhaskar/Cisco
draft-ietf-pim-sm-bsr-03.txt Mark Handley/ICIR draft-ietf-pim-sm-bsr-04.txt Alexander Gall/SWITCH
Roger Kermode/Motorola Stig Venaas/UNINETT
David Thaler/Microsoft 18 July 2004
25 February 2003 Expires: January 2005
Expires: August 2003
Bootstrap Router (BSR) Mechanism for PIM Sparse Mode Bootstrap Router (BSR) Mechanism for PIM
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all By submitting this Internet-Draft, I certify that any applicable patent
provisions of Section 10 of RFC2026. or other IPR claims of which I am aware have been disclosed, or will be
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
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 as "work in progress." or to cite them other than a "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/ietf/1id-abstracts.txt 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 addressed to the authors, or the WG's mailing list at
pim@catarina.usc.edu. pim@catarina.usc.edu.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document specifies the Bootstrap Router (BSR) mechanism This document specifies the Bootstrap Router (BSR) mechanism
for Protocol Independent Multicast - Sparse Mode (PIM-SM). for the class of multicast routing protocols in the PIM
BSR is one way that a PIM-SM router can learn the set of (Protocol Independent Multicast protocol) family that use the
group-to-RP mappings required in order to function. The concept of a Rendezvous Point as a means for receivers to
mechanism is dynamic, largely self-configuring, and robust to discover the sources that send to a particular multicast
router failure. group. BSR is one way that a multicast router can learn the
set of group-to-RP mappings required in order to function.
The mechanism is dynamic, largely self-configuring, and robust
to router failure.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
1.1. General Overview and Background. . . . . . . . . . . 4 1.1. General Overview and Background. . . . . . . . . . . 4
1.2. Overview of Bootstrap and RP Discovery for 1.2. Overview of Bootstrap and RP Discovery for
Global Scope. . . . . . . . . . . . . . . . . . . . . . . 7 Global Scope. . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Administratively Scoped Multicast and BSR. . . . . . 7 1.3. Administratively Scoped Multicast and BSR. . . . . . 8
1.4. Bi-directional PIM . . . . . . . . . . . . . . . . . 9
2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9
3. Bootstrap Router Election and RP-Set 3. Bootstrap Router Election and RP-Set
Distribution . . . . . . . . . . . . . . . . . . . . . . . 10 Distribution . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Sending Candidate-RP-Advertisements. . . . . . . . . 18 3.1. Sending Candidate-RP-Advertisements. . . . . . . . . 19
3.2. Creating the RP-Set at the BSR . . . . . . . . . . . 19 3.2. Creating the RP-Set at the BSR . . . . . . . . . . . 20
3.3. Forwarding Bootstrap Messages. . . . . . . . . . . . 20 3.3. Forwarding Bootstrap Messages. . . . . . . . . . . . 21
3.4. Receiving and Using the RP-Set . . . . . . . . . . . 21 3.4. Receiving and Using the RP-Set . . . . . . . . . . . 22
4. Message Formats . . . . . . . . . . . . . . . . . . . . 21 4. Message Formats . . . . . . . . . . . . . . . . . . . . 22
4.1. Bootstrap Message Format . . . . . . . . . . . . . . 23 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 25
4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 26 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 28
4.2. Candidate-RP-Advertisement Format. . . . . . . . . . 28 4.2. Candidate-RP-Advertisement Format. . . . . . . . . . 30
5. Default Values for Timers . . . . . . . . . . . . . . . 29 5. Default Values for Timers . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . 32
6.1. Possible Threats . . . . . . . . . . . . . . . . . . 30 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 32
6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 31 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 33
6.3. BS Message Security. . . . . . . . . . . . . . . . . 31 6.3. BS Message Security. . . . . . . . . . . . . . . . . 33
6.4. C-RP-Advertisement Security. . . . . . . . . . . . . 33 6.4. C-RP-Advertisement Security. . . . . . . . . . . . . 35
6.5. Denial of Service using IPsec. . . . . . . . . . . . 33 6.5. Denial of Service using IPsec. . . . . . . . . . . . 36
7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 34 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 36
8. References. . . . . . . . . . . . . . . . . . . . . . . 35 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 36
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . 37
10. Normative References . . . . . . . . . . . . . . . . . 37
11. Informative References . . . . . . . . . . . . . . . . 37
12. Authors' Addresses . . . . . . . . . . . . . . . . . . 37
List of Figures List of Figures
Figure 1. Per-Scope-Zone State-machine for a candi- Figure 1. Per-Scope-Zone State-machine for a candi-
date BSR . . . . . . . . . . . . . . . . . . . . . . . . . 10 date BSR . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 2. Per-Scope-Zone State-machine for a router Figure 2. Per-Scope-Zone State-machine for a router
not configured as C-BSR. . . . . . . . . . . . . . . . . . 12 not configured as C-BSR. . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Note: this document assumes familiarity with the workings of Protocol This document assumes familiarity with the workings of Rendezvous Point-
Independent Multicast - Sparse Mode, as defined in [3], and with based multicast routing protocols in the PIM protocol family, in
Administratively Scoped Multicast, as described in [6]. particular with Protocol Independent Multicast - Sparse Mode (PIM-SM),
as defined in [1], and Bi-directional Protocol Independent Multicast
(BIDIR-PIM), as defined in [3], as well as with Administratively Scoped
Multicast, as described in [2].
For correct operation, every PIM Sparse-mode router within a PIM domain Throughout the document, any reference to the PIM protocol family is
must be able to map a particular global-scope multicast group address to restricted to the subset of RP-based protocols unless stated otherwise.
the same RP. If this is not the case then black holes may appear, where
some receivers in the domain cannot receive some groups. A domain in
this context is a contiguous set of routers that all implement PIM and
are configured to operate within a common boundary defined by PIM
Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the
rest of the internet.
A PIM domain may also broken up into multiple administrative scope For correct operation, every multicast router within a PIM domain must
be able to map a particular multicast group address to the same RP. If
this is not the case then black holes may appear, where some receivers
in the domain cannot receive some groups. A PIM domain in this context
is a contiguous set of routers that all implement the multicast routing
protocol and are configured to operate within a common boundary defined
by PIM Multicast Border Routers (PMBRs). PMBRs connect each PIM domain
to the rest of the internet.
A PIM domain may also be broken up into multiple administrative scope
regions - these are regions where a border has been configured so that a regions - these are regions where a border has been configured so that a
range of multicast groups will not be forwarded across that border. For range of multicast groups will not be forwarded across that border. For
more information on Administratively Scoped IP Multicast, see RFC 2365. more information on Administratively Scoped IP Multicast, see RFC 2365
The modified criteria for admin-scoped regions are that the region is [2]. The modified criteria for admin-scoped regions are that the region
convex with respect to forwarding based on the MRIB, and that all PIM is convex with respect to forwarding based on the MRIB, and that all PIM
routers within the same scope region map a particular scoped group to routers within the same scope region map a particular scoped group to
the same RP within that region. the same RP within that region.
The PIM-SM specification does not mandate the use of a single mechanism The PIM specifications do not mandate the use of a single mechanism to
to provide routers with the information to perform the group-to-RP provide routers with the information to perform the group-to-RP mapping.
mapping. This document describes the Bootstrap Router (BSR) mechanism. This document describes the Bootstrap Router (BSR) mechanism. BSR was
BSR was first defined in RFC 2362 [2], which has since been obsoleted. first defined in RFC 2362 [5], which has since been obsoleted. This
This document provides an updated specification of the BSR mechanism document provides an updated specification of the BSR mechanism from RFC
from RFC 2362, and also extends it to cope with administratively scoped 2362, and also extends it to cope with administratively scoped region
region boundaries. boundaries and different flavours of routing protocols.
1.1. General Overview and Background 1.1. General Overview and Background
Every PIM-SM multicast group needs to be associated with the IP address Every PIM multicast group needs to be associated with the IP address of
of a Rendezvous-Point (RP). When a new multicast sender starts sending, a Rendezvous Point (RP). This address is used to build a group-specific
its local Designated Router (DR) will encapsulate these data packets in distribution tree rooted at that address whose branches extend to all
a PIM Register message and send them to the RP for that multicast group. nodes in the domain that want to receive traffic sent to the group.
When a new multicast receiver joins, its local DR will send a PIM Join Senders inject packets into the tree in such a manner that they reach
message towards the RP for that multicast group. When any PIM router all connected receivers. How this is done and how the packets are
sends a (*,G) Join message, it needs to know which is the next how forwarded along the distribution tree depends on the particular routing
router towards the RP for G to send the message to. Also when a PIM protocol.
router is forwarding data packets using (*,G) state, it needs to know
which is the correct incoming interface for packets destined for G, as
it needs to reject any packets that arrive on other interfaces. Thus it
is important for all the PIM routers in a domain to be able to map each
multicast group to the correct RP address.
There are a number of ways that group-to-RP mapping can be done; the For all senders to reach all receivers, it is crucial that there exists
simplest solution is for all the routers in the domain to be configured a single distribution tree. This can only be achieved when all routers
with the same information. However, static configuration generally in the domain use the same mappings of group addresses to RP addresses.
doesn't scale well, and also does not dynamically adapt to route around
router or link failures. The mechanism specified in this document is
known as the PIM BootStrap Router mechanism, or BSR for short, and
provides a dynamic, adaptive mechanism to distribute group-to-RP mapping
information rapidly throughout a domain.
Before we discuss the BSR mechanism itself, we should understand the There are a number of ways how such group-to-RP mappings can be
rules a PIM-SM router will apply to the mapping information. established. The simplest solution is for all the routers in the domain
Irrespective of how it obtains the mapping information, a PIM-SM router to be statically configured with the same information. However, static
will have a mapping table containing multiple entries, each of which has configuration generally doesn't scale well, and also does not
the following form: dynamically adapt to route around router or link failures. The
mechanism specified in this document is known as the PIM BootStrap
Router mechanism, or BSR for short, and provides a dynamic, adaptive
mechanism to distribute group-to-RP mapping information rapidly
throughout a domain.
o Multicast group range, expressed as an address and prefix length. A group-to-RP mapping contains the following elements.
o RP Priority. o Multicast group range, expressed as an address and prefix length
o IP address of RP. o RP Priority
o <<<<<<< bsr.nrf IP address of RP.
o RP Holdtime ======= IP address of RP
o RP Holdtime >>>>>>> 1.49
o Hash mask length
The collection of all group-to-RP mappings known to a router at any
point in time is called the RP-set. The router that assumes the role of
the BSR maintains a logically distinct RP-set called the C-RP-set, from
which it constructs the actual RP-set as explained below.
In general, these mapping entries may overlap in arbitrary ways; a In general, these mapping entries may overlap in arbitrary ways; a
particular multicast group may be covered by multiple mapping entries. particular multicast group may be covered by multiple mapping entries.
When this is the case, the router chooses only one of the entries by When this is the case, the router chooses only one of the entries by
applying a deterministic algorithm (specified in the PIM-SM protocol applying a deterministic algorithm so that all routers in the domain
specification) so that all routers in the domain make the same choice of make the same choice and hence apply the same group-to-RP mapping. It
entry and hence apply the same group-to-RP mapping. is important to note that this algorithm is part of the specification of
the individual routing protocols (and may differ among them), not of the
BSR specification.
The BSR mechanism provides a way in which viable group-to-RP mappings The BSR mechanism provides a way in which viable group-to-RP mappings
can be created and distributed to all the PIM-SM routers in a domain. can be created and distributed to all the PIM routers in a domain. It
It is adaptive, in that if an RP becomes unreachable, this will be is adaptive, in that if an RP becomes unreachable, this will be detected
detected and the mapping tables will be modified so that the unreachable and the mapping tables will be modified so that the unreachable RP is no
RP is no longer used, and the new tables will be rapidly distributed longer used, and the new tables will be rapidly distributed throughout
throughout the domain. the domain.
The general idea behind the BSR-mechanism is that some of the PIM The general idea behind the BSR-mechanism is that some of the PIM
routers within a PIM domain are configured to be potential RPs for the routers within a PIM domain are configured to be potential RPs for the
domain. These are known as candidate-RPs (C-RPs). A subset of the C- domain. These are known as candidate-RPs (C-RPs). A subset of the C-
RPs will eventually be used as the actual RPs for the domain. In RPs will eventually be used as the actual RPs for the domain. In
addition, some of the PIM routers in the domain are configured as addition, some of the PIM routers in the domain are configured as
candidate bootstrap routers (C-BSRs). One of these C-BSRs will be candidate bootstrap routers (C-BSRs). One of these C-BSRs will be
elected to serve as the bootstrap router (BSR) for the domain, and all elected to serve as the bootstrap router (BSR) for the domain, and all
the PIM routers in the domain will learn the result of this election the PIM routers in the domain will learn the result of this election
through Bootstrap messages. The C-RPs will them report their candidacy through Bootstrap messages. The C-RPs will then report their candidacy
to the elected BSR, which will choose a subset of the C-RPs to form the to the elected BSR, which stores the group-to-C-RP mappings in its C-RP-
actual set of RPs to the used. This RP-Set will then be distributed out set. It will chose a subset of these mappings as the actual RP-set and
to all the routers in the domain through Bootstrap messages. distribute it to all the routers in the domain through Bootstrap
messages.
The mechanism is complicated slightly by the presence of The mechanism is complicated slightly by the presence of
administratively-scoped multicast regions within the PIM-SM domain. An administratively-scoped multicast regions within the PIM domain. An
admin-scope region is a convex connected set of PIM routers surrounded admin-scope region is a convex connected set of PIM routers surrounded
by an admin-scope boundary. The boundary specifies a range of multicast by an admin-scope boundary. The boundary specifies a range of multicast
addresses that will not be forwarded into or out of the scoped region. addresses that will not be forwarded into or out of the scoped region.
This complicates BSR because we do not want a PIM router within the This complicates BSR because we do not want a PIM router within the
scoped region to use an RP outside the scoped region (or vice-versa). scoped region to use an RP outside the scoped region (or vice-versa).
Thus we need to modify the basic mechanism to ensure that this doesn't Thus we need to modify the basic mechanism to ensure that this doesn't
happen - this is done by electing a BSR for every admin-scope region happen - this is done by electing a BSR for every admin-scope region
within a PIM domain, and also a global BSR for the whole PIM domain. C- within a PIM domain, and also a global BSR for the whole PIM domain. C-
RPs typically register multiple times; once to the BSR of every admin RPs typically register multiple times; once to the BSR of every admin
scope zone the C-RP is in. For the remainder of this overview we will scope zone the C-RP is in. For the remainder of this overview we will
ignore admin-scope regions, and concentrate on the global BSR and its ignore admin-scope regions, and concentrate on the global BSR and its
role. Within each scope zone, the BSR for that zone acts in a similar role. Within each scope zone, the BSR for that zone acts in a similar
manner to how the global BSR acts for the whole domain. manner to how the global BSR acts for the whole domain.
There are four basic phases to the BSR mechanism (although in practice There are four basic phases to the BSR mechanism (although in practice
all phases may by occurring simultaneously): all phases may be occurring simultaneously):
1. BSR election. Each Candidate-BSR originates bootstrap messages 1. BSR election. Each Candidate-BSR originates bootstrap messages
(BSMs). Every BSM contains a BSR priority field. Routers within (BSMs). Every BSM contains a BSR priority field. Routers within
the domain flood the BSMs throughout the domain. A C-BSR that the domain flood the BSMs throughout the domain. A C-BSR that
hears about a higher-priority C-BSR than itself then suppresses its hears about a higher-priority C-BSR than itself then suppresses its
sending of further BSMs for some period of time. The single sending of further BSMs for some period of time. The single
remaining C-BSR becomes the elected BSR, and its BSMs inform all remaining C-BSR becomes the elected BSR, and its BSMs inform all
the other routers in the domain that it is the elected BSR. the other routers in the domain that it is the elected BSR.
2. C-RP advertisement. Each Candidate-RP within a domain sends 2. C-RP advertisement. Each Candidate-RP within a domain sends
periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the
elected BSR. In this way, the BSR learns about possible RPs that elected BSR. In this way, the BSR learns about possible RPs that
are currently up and reachable. are currently up and reachable.
3. C-RP-Set Formation. The BSR selects a subset of the C-RPs that it 3. C-RP-Set Formation. The BSR selects a subset of the C-RPs that it
has heard C-RP-Adv messages from to form the RP-Set. In general it has received C-RP-Adv messages from to form the RP-Set. In general
should do this in such a way that the RP-Set is neither too large it should do this in such a way that the RP-Set is neither too
to inform all the routers in the domain about, nor too small so large to inform all the routers in the domain about, nor too small
that load is overly concentrated on some RPs. It should also so that load is overly concentrated on some RPs. It should also
attempt to produce an RP-Set that does not change frequently. attempt to produce an RP-Set that does not change frequently.
4. RP-Set Flooding. In future bootstrap messages, the BSR includes 4. RP-Set Flooding. In future bootstrap messages, the BSR includes
the RP-Set information. As bootstrap messages are flooded rapidly the RP-Set information. As bootstrap messages are flooded rapidly
through the domain, this ensures that the RP-Set rapidly reaches through the domain, this ensures that the RP-Set rapidly reaches
all the routers in the domain. BSMs are originated periodically to all the routers in the domain. BSMs are originated periodically to
ensure consistency after failure restoration. ensure consistency after failure restoration.
When a PIM router receives a Bootstrap message, it adds the group-
to-RP mappings contained therein to its pool of mappings obtained
from other sources (e.g. static configuration). It calculates the
final mappings of group addresses to RP addresses from this pool
according to rules specific to the particular routing protocol and
uses that information to construct multicast distribution trees.
In the following sections we discuss more details about BSR for global In the following sections we discuss more details about BSR for global
scope and for admin scoping, before specifying the protocol starting in scope and for admin scoping, before specifying the protocol starting in
section 2. section 2.
1.2. Overview of Bootstrap and RP Discovery for Global Scope 1.2. Overview of Bootstrap and RP Discovery for Global Scope
A small set of routers from a domain are configured as candidate A small set of routers from a domain are configured as candidate
bootstrap routers (C-BSRs) and, through a simple election mechanism, a bootstrap routers (C-BSRs) and, through a simple election mechanism, a
single BSR is selected for that domain. A set of routers within a domain single BSR is selected for that domain. A set of routers within a
are also configured as candidate RPs (C-RPs); typically these will be domain are also configured as candidate RPs (C-RPs); typically these
the same routers that are configured as C-BSRs. Candidate RPs will be the same routers that are configured as C-BSRs. Candidate RPs
periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to
the BSR of that domain, advertising their willingness to be an RP. A C- the BSR of that domain, advertising their willingness to be an RP. A C-
RP-Adv message includes the address of the advertising C-RP, as well as RP-Adv message includes the address of the advertising C-RP, as well as
an optional list of group addresses and a mask length fields, indicating an optional list of group addresses and mask length fields, indicating
the group prefix(es) for which the candidacy is advertised. The BSR then the group prefix(es) for which the candidacy is advertised. The BSR
includes a set of these Candidate-RPs (the RP-Set), along with their then includes a set of these Candidate-RPs (the RP-Set), along with
corresponding group prefixes, in Bootstrap messages it periodically their corresponding group prefixes, in Bootstrap messages it
originates. Bootstrap messages are distributed hop-by-hop throughout periodically originates. Bootstrap messages are distributed hop-by-hop
the domain. throughout the domain.
All the PIM routers in the domain receive and store Bootstrap messages
originated by the BSR. When a DR receives an indication of local
membership (typically from IGMP [4] or MLD [1]) or a data packet from a
directly connected host, for a group for which it has no forwarding
state, the DR uses a hash function to map the group address to one of
the C-RPs from the RP-Set whose group-prefix includes the group (see
[3]). The DR then sends a Join message towards that RP if the local host
joined the group, or it Register-encapsulates and unicasts the data
packet to the RP if the local host sent a packet to the group.
A Bootstrap message indicates liveness of the RPs included therein. If
an RP is included in the message, then it is tagged as `up' at the
routers; RPs not included in the message are removed from the list of
RPs over which the hash algorithm acts. Each router continues to use the
contents of the most recently received Bootstrap message from the BSR
until it accepts a new Bootstrap message.
If a PIM domain becomes partitioned, each area separated from the old If a PIM domain becomes partitioned, each area separated from the old
BSR will elect its own BSR, which will distribute an RP-Set containing BSR will elect its own BSR, which will distribute an RP-Set containing
RPs that are reachable within that partition. When the partition heals, RPs that are reachable within that partition. When the partition heals,
another election will occur automatically and only one of the BSRs will another election will occur automatically and only one of the BSRs will
continue to send out Bootstrap messages. As is expected at the time of a continue to send out Bootstrap messages. As is expected at the time of
partition or healing, some disruption in packet delivery may occur. This a partition or healing, some disruption in packet delivery may occur.
time will be on the order of the region's round-trip time and the This time will be on the order of the region's round-trip time and the
bootstrap router timeout value. bootstrap router timeout value.
1.3. Administratively Scoped Multicast and BSR 1.3. Administratively Scoped Multicast and BSR
Administratively Scoped IP Multicast, as defined in RFC 2365, permits a Administratively Scoped IP Multicast, as defined in RFC 2365 [2],
network provider to configure scope boundaries at multicast routers. permits a network provider to configure scope boundaries at multicast
routers. Such a scope boundary consists of a range of multicast
Such a scope boundary consists of a range of multicast addresses addresses (expressed as an address and mask) that the router will not
(expressed as an address and mask) that the router will not forward forward across the boundary. For correct operation, such a scope zone
across the boundary. For correct operation, such a scope zone border border must be complete and convex. By this we mean that there must be
must be complete and convex. By this we mean that there must be no path no path from inside the scoped zone to outside it that does not pass
from inside the scoped zone to outside it that does not pass through a through a configured scope border router, and that the multicast capable
configured scope border router, and that the multicast capable path path between any arbitrary pair of multicast routers in the scope zone
between any arbitrary pair of multicast routers in the scope zone must must remain in the zone.
remain in the zone.
For PIM-SM using BSR to function correctly with admin scoping, there For BSR to function correctly with admin scoping, there must be a BSR
must be a BSR and at least one C-RP within every admin scope region. and at least one C-RP within every admin scope region. Admin scope zone
Admin scope zone boundaries must be configured at the Zone Border boundaries must be configured at the Zone Border Routers (ZBRs), as they
Routers (ZBRs), as they need to filter PIM Join messages that might need to filter PIM Join messages that might inadvertently cross the
inadvertently cross the border due to error conditions. In addition, at border due to error conditions. In addition, at least one C-BSR within
least one C-BSR within the admin scope zone must be configured to be a the admin scope zone must be configured to be a C-BSR for the admin
C-BSR for the admin scope zone's address range. scope zone's address range.
A separate BSR election will then take place (using bootstrap messages) A separate BSR election will then take place (using bootstrap messages)
for every admin scope range (plus one for the global range). Admin for every admin scope range (plus one for the global range). Admin
scope ranges are identified in the bootstrap message because the group scope ranges are identified in the bootstrap message because the group
range is marked (using the "Admin Scope" bit, previously a "Reserved" range is marked (using the "Admin Scope" bit, previously a "Reserved"
bit) to indicate that this is an administrative scope range, and not bit) to indicate that this is an administrative scope range, and not
just a range that a particular set of RPs are configured to handle. just a range that a particular set of RPs are configured to handle.
Such admin scoped bootstrap message packets are flooded in the normal Such admin scoped bootstrap message packets are flooded in the normal
way, but will not be forwarded by another ZBR across the boundary for way, but will not be forwarded by another ZBR across the boundary for
skipping to change at page 8, line 49 skipping to change at page 9, line 4
default be that a C-RP is a C-RP for all scopes, both global and admin default be that a C-RP is a C-RP for all scopes, both global and admin
scoped. scoped.
Unless configured otherwise, C-RPs discover the existence of the admin Unless configured otherwise, C-RPs discover the existence of the admin
scope zone and its group range from receiving a bootstrap message from scope zone and its group range from receiving a bootstrap message from
the scope zone's elected BSR containing the scope zone's group-range, the scope zone's elected BSR containing the scope zone's group-range,
marked using the "Admin Scope" bit. A C-RP stores each elected BSR's marked using the "Admin Scope" bit. A C-RP stores each elected BSR's
address and the admin scope range contained in its bootstrap message. address and the admin scope range contained in its bootstrap message.
It separately unicasts Candidate-RP-Advertisement messages to the It separately unicasts Candidate-RP-Advertisement messages to the
appropriate BSR for every admin scope range within which it is willing appropriate BSR for every admin scope range within which it is willing
to serve as an RP. to serve as an RP.
All PIM routers within a PIM bootstrap domain where admin scope ranges All PIM routers within a PIM bootstrap domain where admin scope ranges
are in use must be capable of receiving bootstrap messages and storing are in use must be capable of receiving bootstrap messages and storing
the winning BSR and RP-set for all admin scope zones that apply. Thus
the winning BSR and RPset for all admin scope zones that apply. Thus
PIM routers that only implement RFC 2362 (which only allows one BSR per PIM routers that only implement RFC 2362 (which only allows one BSR per
domain) cannot be used in PIM domains where admin scope zones are domain) cannot be used in PIM domains where admin scope zones are
configured. configured.
1.4. Bi-directional PIM
Routers doing Bi-directional PIM [3] need group-to-RP mappings similar
to PIM-SM. Group ranges for use by Bi-directional PIM are identified in
bootstrap messages by a "Bi-dir" bit (previously a "Reserved" bit).
Routers that don't support Bi-directional PIM MUST NOT ignore these
ranges. They MUST NOT treat them as having the default mode, i.e. PIM-
SM.
2. BSR State and Timers 2. BSR State and Timers
A PIM-SM router implementing BSR holds the following state in addition A PIM router implementing BSR holds the following state
to the state needed for PIM-SM operation:
At all routers: At all routers:
List of Active Scope Zones List of Active Scope Zones
Per Scope Zone: Per Scope Zone:
Bootstrap State: Bootstrap State:
o Bootstrap Router's IP Address o Bootstrap Router's IP Address
o BSR Priority o BSR Priority
o Bootstrap Timer (BST) o Bootstrap Timer (BST)
o List of Scope Group-Ranges for this BSR o Last BSM received from this BSR
RP Set RP-Set
At a Candidate BSR: At a Candidate BSR:
Per Scope Zone: Per Scope Zone:
o My state: One of "Candidate-BSR", "Pending-BSR", o My state: One of "Candidate-BSR", "Pending-BSR",
"Elected-BSR" "Elected-BSR"
At a router that is not a Candidate BSR: At a router that is not a Candidate BSR:
Per Scope Zone: Per Scope Zone:
My state: One of "Accept Any", "Accept Preferred" My state: One of "Accept Any", "Accept Preferred"
Scope-Zone Expiry Timer: SZT(Z) Scope-Zone Expiry Timer: SZT(Z)
Bootstrap state is described in section 3, and the RP Set is described Bootstrap state is described in section 3, and the RP-Set is described
in section 3.4. in section 3.4.
The following timers are also required: The following timers are also required:
At the Bootstrap Router only: At the Bootstrap Router only:
Per Scope Zone (Z): Per Scope Zone (Z):
Per Candidate RP (C): Per group-to-C-RP mapping (M):
C-RP Expiry Timer: CET(C,Z) Group-to-C-RP mapping Expiry Timer: CGET(M,Z)
At the C-RPs only: At the C-RPs only:
C-RP Advertisement Timer: CRPT C-RP Advertisement Timer: CRPT
At all routers:
Per Scope Zone (Z):
Per group-to-RP mapping (M):
Group-to-RP mapping Expiry Timer: GET(M,Z)
3. Bootstrap Router Election and RP-Set Distribution 3. Bootstrap Router Election and RP-Set Distribution
For simplicity, bootstrap messages (BSMs) are used in both the BSR For simplicity, bootstrap messages (BSMs) are used in both the BSR
election and the RP-Set distribution mechanisms. election and the RP-Set distribution mechanisms.
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.
skipping to change at page 11, line 19 skipping to change at page 11, line 19
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in C-BSR state | | When in C-BSR state |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
| Event | Receive | BS Timer | Receive non- | | Event | Receive | BS Timer | Receive non- |
| | Preferred BSM | Expires | preferred BSM | | | Preferred BSM | Expires | preferred BSM |
| | | | from Elected | | | | | from Elected |
| | | | BSR | | | | | BSR |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
| | -> C-BSR state | -> P-BSR state | -> P-BSR state | | | -> C-BSR state | -> P-BSR state | -> P-BSR state |
| | Forward BSM; | Set BS Timer | Set BS Timer | | | Forward BSM; | Set BS Timer | Set BS Timer |
| Action | Store RP Set; | to | to | | Action | Store RP-Set; | to | to |
| | Set BS Timer | rand_override | rand_override | | | Set BS Timer | rand_override | rand_override |
| | to BS Timeout | | | | | to BS Timeout | | |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in P-BSR state | | When in P-BSR state |
+-------------+-------------------+------------------+------------------+ +-------------+-------------------+------------------+------------------+
| Event | Receive | BS Timer | Receive Non- | | Event | Receive | BS Timer | Receive Non- |
| | Preferred BSM | Expires | preferred BSM | | | Preferred BSM | Expires | preferred BSM |
+-------------+-------------------+------------------+------------------+ +-------------+-------------------+------------------+------------------+
| | -> C-BSR state | -> E-BSR state | -> P-BSR state | | | -> C-BSR state | -> E-BSR state | -> P-BSR state |
| | Forward BSM; | Originate BSM; | | | | Forward BSM; | Originate BSM; | |
| Action | Store RP Set; | Set BS Timer | | | Action | Store RP-Set; | Set BS Timer | |
| | Set BS Timer | to BS Period | | | | Set BS Timer | to BS Period | |
| | to BS Timeout | | | | | to BS Timeout | | |
+-------------+-------------------+------------------+------------------+ +-------------+-------------------+------------------+------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in E-BSR state | | When in E-BSR state |
+-------------+-------------------+------------------+------------------+ +-------------+-------------------+------------------+------------------+
| Event | Receive | BS Timer | Receive Non- | | Event | Receive | BS Timer | Receive Non- |
| | Preferred BSM | Expires | preferred BSM | | | Preferred BSM | Expires | preferred BSM |
+-------------+-------------------+------------------+------------------+ +-------------+-------------------+------------------+------------------+
| | -> C-BSR state | -> E-BSR state | -> E-BSR state | | | -> C-BSR state | -> E-BSR state | -> E-BSR state |
| | Forward BSM; | Originate BSM; | Originate BSM; | | | Forward BSM; | Originate BSM; | Originate BSM; |
| Action | Store RP Set; | Set BS Timer | Set BS Timer | | Action | Store RP-Set; | Set BS Timer | Set BS Timer |
| | Set BS Timer | to BS Period | to BS Period | | | Set BS Timer | to BS Period | to BS Period |
| | to BS Timeout | | | | | to BS Timeout | | |
+-------------+-------------------+------------------+------------------+ +-------------+-------------------+------------------+------------------+
A candidate-BSR may be in one of three states for a particular scope A candidate-BSR may be in one of three states for a particular scope
zone: zone:
Candidate-BSR (C-BSR) Candidate-BSR (C-BSR)
The router is a candidate to be the BSR for the scope zone, but The router is a candidate to be the BSR for the scope zone, but
currently another router is the preferred BSR. currently another router is the preferred BSR.
skipping to change at page 13, line 28 skipping to change at page 13, line 28
| | Set SZ Timer to SZ Timeout | | | Set SZ Timer to SZ Timeout |
+--------------------+--------------------------------------------------+ +--------------------+--------------------------------------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in Accept Any state | | When in Accept Any state |
+---------------+-----------------------------+-------------------------+ +---------------+-----------------------------+-------------------------+
| Event | Receive BSM | SZ Timer Expires | | Event | Receive BSM | SZ Timer Expires |
+---------------+-----------------------------+-------------------------+ +---------------+-----------------------------+-------------------------+
| | -> AP State | -> No Info state | | | -> AP State | -> No Info state |
| | Forward BSM; Store | cancel timers; | | | Forward BSM; Store | cancel timers; |
| Action | RP-Set; Set BS | clear state | | | RP-Set; Set BS | clear state |
| | Timer to BS | | | Action | Timer to BS | |
| | Timeout; Set SZ | |
| | Timer to SZ | |
| | Timeout | | | | Timeout | |
+---------------+-----------------------------+-------------------------+ +---------------+-----------------------------+-------------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in Accept Preferred state | | When in Accept Preferred state |
+------------+-------------------+-------------------+------------------+ +------------+--------------------+------------------+------------------+
| Event | Receive | BS Timer | Receive Non- | | Event | Receive | BS Timer | Receive Non- |
| | Preferred BSM | Expires | preferred BSM | | | Preferred BSM | Expires | preferred BSM |
+------------+-------------------+-------------------+------------------+ +------------+--------------------+------------------+------------------+
| | -> AP State | -> AA State | -> AP State | | | -> AP State | -> AA State | -> AP State |
| | Forward BSM; | | | | | Forward BSM; | Refresh RP- | |
| Action | Store RP-Set; | | | | | Store RP-Set; | set; Remove | |
| | Set BS Timer | | | | Action | Set BS Timer | BSR state | |
| | to BS Timeout | | | | | to BS Timeout; | | |
+------------+-------------------+-------------------+------------------+ | | Set SZ Timer | | |
| | to SZ Timeout | | |
+------------+--------------------+------------------+------------------+
A router that is not a candidate-BSR may be in one of three states: A router that is not a candidate-BSR may be in one of three states:
No Info No Info
The router has no information about this scope zone. This state The router has no information about this scope zone. This state
does not apply if the router is configured to know about this scope does not apply if the router is configured to know about this scope
zone, or for the global scope zone. When in this state, no state zone, or for the global scope zone. When in this state, no state
information is held and no timers run that refer to this scope information is held and no timers run that refer to this scope
zone. zone.
Accept Any (AA) Accept Any (AA)
The router does not know of an active BSR, and will accept the The router does not know of an active BSR, and will accept the
first bootstrap message it sees as giving the new BSR's identity first bootstrap message it sees as giving the new BSR's identity
and the RP-Set. If the router has an RP-Set cached from an and the RP-Set.
obsolete bootstrap message, it continues to use it.
Accept Preferred (AP) Accept Preferred (AP)
The router knows the identity of the current BSR, and is using the The router knows the identity of the current BSR, and is using the
RP-Set provided by that BSR. Only bootstrap messages from that BSR RP-Set provided by that BSR. Only bootstrap messages from that BSR
or from a C-BSR with higher weight than the current BSR will be or from a C-BSR with higher weight than the current BSR will be
accepted. accepted.
On startup, the initial state for this scope zone is "Accept Any" for On startup, the initial state for this scope zone is "Accept Any" for
routers that know about this scope zone, either through configuration or routers that know about this scope zone, either through configuration or
because the scope zone is the global scope which always exists; the SZ because the scope zone is the global scope which always exists; the SZ
skipping to change at page 15, line 14 skipping to change at page 15, line 14
if ( (DirectlyConnected(BSM.src_ip_address) == FALSE) if ( (DirectlyConnected(BSM.src_ip_address) == FALSE)
OR (we have no Hello state for BSM.src_ip_address)) { OR (we have no Hello state for BSM.src_ip_address)) {
drop the BS message silently drop the BS message silently
} }
if (BSM.dst_ip_address == ALL-PIM-ROUTERS group) { if (BSM.dst_ip_address == ALL-PIM-ROUTERS group) {
if ( BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address) ) { if ( BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address) ) {
drop the BS message silently drop the BS message silently
} }
} else if (BSM.dst_ip_address is one of my addresses) { } else if (BSM.dst_ip_address is one of my addresses) {
if ( (Any previous BSM for this scope has been accepted) { if (Any previous BSM for this scope has been accepted) {
#the packet was unicast, but this wasn't #the packet was unicast, but this wasn't
#a quick refresh on startup #a quick refresh on startup
drop the BS message silently drop the BS message silently
} }
} else { } else {
drop the BS message silently drop the BS message silently
} }
if (the interface the message arrived on is an Admin Scope if (the interface the message arrived on is an Admin Scope
border for the BSM.first_group_address) { border for the BSM.first_group_address) {
drop the BS message silently drop the BS message silently
} }
Basically, the packet must have come from a directly connected neighbor Basically, the packet must have come from a directly connected neighbor
for which we have active Hello state. It must have been sent to the for which we have active Hello state. It must have been sent to the
ALL-PIM-ROUTERS group by the correct upstream router towards the BSR ALL-PIM-ROUTERS group by the correct upstream router towards the BSR
that originated the BS message, or the router must have no BSR state (it that originated the BS message, or the router must have no BSR state for
just restarted) and have received the BS message by unicast. In that admin scope (it just restarted) and have received the BS message by
addition it must not have arrived on an interface that is a configured unicast. In addition it must not have arrived on an interface that is a
admin scope border for the first group address contained in the BS configured admin scope border for the first group address contained in
message. the BS message.
BS State-machine Transition Events BS State-machine Transition Events
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 greater A bootstrap message is received from a BSR that has greater
than or equal weight than the current BSR. In a router is in than or equal weight than the current BSR. If a router is in
P-BSR state, then it uses its own weight as that of the P-BSR state, then it uses its own weight as that of the
current BSR. current BSR.
The weighting for a BSR is the concatenation in fixed- The weighting for a BSR is the concatenation in fixed-
precision unsigned arithmetic of the BSR priority field from precision unsigned arithmetic of the BSR priority field from
the bootstrap message and the IP address of the BSR from the the bootstrap message and the IP address of the BSR from the
bootstrap message (with the BSR priority taking the most- 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 BSM Receive BSM
A bootstrap message is received, regardless of BSR weight. A bootstrap message is received, regardless of BSR weight.
A non-candidate BSM also has the following transition event defined:
A non-candidate BSR also has the following transition event defined:
Receive BSM for unknown Admin Scope Receive BSM for unknown Admin Scope
As "Receive BSM", except that the admin scope zone indicated As "Receive BSM", except that the admin scope zone indicated
in the BSM was not previously known at this router. in the BSM was not previously known at this router.
BS State-machine Actions BS State-machine Actions
The state-machines specify actions that include setting the BS timer to The state-machines specify actions that include setting the BS timer to
the following values: the following values:
skipping to change at page 17, line 37 skipping to change at page 17, line 37
the BS Timeout, which is 1300 seconds. the BS Timeout, which is 1300 seconds.
In addition to setting the timers, the following actions may be In addition to setting the timers, the following actions may be
triggered by state-changes in the state-machines: triggered by state-changes in the state-machines:
Forward BSM Forward BSM
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. The boundary for the scope zone indicated in the message. For
source IP address of the message is the forwarding router's IP details, see section 3.3.
address on the interface the message is being forwarded from,
the destination address is ALL-PIM-ROUTERS, and the TTL of the
message is set to 1.
As an optimation, a router MAY choose not to forward a BSM out
of the interface the message was received on if that interface
is a point-to-point interface. On interfaces with multiple
PIM neighbors, a router MUST forward an accepted BSM onto the
interface that BSM was received on, but if the number of PIM
neighbors on that interface is large, it MAY delay forwarding
a BSM onto that interface by a small randomized interval to
prevent message implosion.
Rationale: A BSM needs to be forwarded onto the interface the
message was received on (in addition to the other interfaces)
because the routers on a LAN may not have consistent routing
information. If three routers on a LAN and A, B, and C, and
at router B RPF(BSR)==A and at router C RPF(BSR)==B, then
router A originally forwards the BSM onto the LAN, but router
C will only accept it when router B re-forwards the message
onto the LAN.
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 multicast-
capable interfaces, except where this would cause the BSM to capable interfaces, except where this would cause the BSM to
cross an admin-scope boundary for the scope zone indicated in cross an admin-scope boundary for the scope zone indicated in
the message. The IP source address of the message is the the message. The IP source address of the message is the
originating router's IP address on the interface the message originating router's IP address on the interface the message
is being forwarded from, the destination address is ALL-PIM- is being forwarded from, the destination address is ALL-PIM-
ROUTERS, and the TTL of the message is set to 1. ROUTERS, and the TTL of the message is set to 1.
Store RP Set Store RP-Set
The RP-Set from the received bootstrap message is stored and The router uses the group-to-RP mappings contained in a BSM to
used by the router to decide the RP for each group that the update its local RP-set.
router has state for. Storing this RP Set may cause other
state-transitions to occur in the router. The BSR's IP If a mapping does not yet exist, it is created and the
address and priority from the received bootstrap message are associated group-to-RP mapping expiry timer (GET) is
also stored to be used to decide if future bootstrap messages initialized with the holdtime from the BSM.
are preferred.
If a mapping already exists, its GET is set to the holdtime
from the BSM. If the holdtime is zero, the mapping is removed
immediately.
In addition, the entire BSM is stored for use in the action
Refresh RP-Set and to prime a new PIM neighbor as described
below.
Refresh RP-Set
When the BS Timer expires, the router uses the copy of the
last BSM that it has received to refresh its RP-set according
to the action Store RP-Set as if it had just received it.
This will increase the chance that the group-to-RP mappings
will not expire during the election of the new BSR.
Remove BSR state
When the BS Timer expires, all state associated with the
current BSR is removed (see section 2). Note that this does
not include any group-to-RP mappings.
In addition to the above state-machine actions, a DR also unicasts a In addition to the above state-machine actions, a DR also unicasts a
stored copy of the Bootstrap message to each new PIM neighbor, i.e., stored copy of the Bootstrap message to each new PIM neighbor, i.e.,
after the DR receives the neighbor's first Hello message, and sends a after the DR receives the neighbor's first Hello message, and sends a
Hello message in response. It does so even if the new neighbor becomes Hello message in response. It does so even if the new neighbor becomes
the DR. the DR.
3.1. Sending Candidate-RP-Advertisements 3.1. Sending Candidate-RP-Advertisements
Every C-RP periodically unicasts a C-RP-Adv to the BSR for that scope Every C-RP periodically unicasts a C-RP-Adv to the BSR for that scope
skipping to change at page 19, line 4 skipping to change at page 18, line 52
zone to inform the BSR of the C-RP's willingness to function as an RP. zone to inform the BSR of the C-RP's willingness to function as an RP.
Unless configured otherwise, it does this for every Admin Scope zone for Unless configured otherwise, it does this for every Admin Scope zone for
which it has state, and for the global scope zone. If the same router which it has state, and for the global scope zone. If the same router
is the BSR for more than one scope zone, the C-RP-Adv for these scope is the BSR for more than one scope zone, the C-RP-Adv for these scope
zones MAY be combined into a single message. zones MAY be combined into a single message.
If the C-RP is a ZBR for an admin scope zone, then the Admin Scope bit If the C-RP is a ZBR for an admin scope zone, then the Admin Scope bit
MUST be set in the C-RP-Adv messages it sends for that scope zone; MUST be set in the C-RP-Adv messages it sends for that scope zone;
otherwise this bit MUST NOT be set. This information is currently only otherwise this bit MUST NOT be set. This information is currently only
used for logging purposes by the BSR, but might allow for future used for logging purposes by the BSR, but might allow for future
extensions of the protocol. extensions of the protocol.
The interval for sending these messages is subject to local The interval for sending these messages is subject to local
configuration at the C-RP, but must be smaller than the HoldTime in the configuration at the C-RP, but must be smaller than the HoldTime in the
C-RP-Adv. C-RP-Adv.
[NOTE: possible optimization: prime the CRPT with a small random value
when a new BSR is elected. This will allow the newly elected BSR to
learn group mappings fast.]
A Candidate-RP-Advertisement carries a list of group address and group A Candidate-RP-Advertisement carries a list of group address and group
mask field pairs. This enables the C-RP router to restrict the mask field pairs. This enables the C-RP router to restrict the
advertisement to certain prefixes or scopes of groups. If the C-RP advertisement to certain prefixes or scopes of groups. If the C-RP
becomes an RP, it may enforce this scope acceptance when receiving becomes an RP, it may enforce this scope acceptance when receiving
Registers or Join/Prune messages. Registers or Join/Prune messages.
The C-RP priority field determines which C-RPs get selected by the BSR 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 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. C-RPs should by default send C-RP-Adv messages with the
`Priority' field set to 192. `Priority' field set to 192.
When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv to 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 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 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 immediately time out the C-RP and generate a new BSR message removing
the shut down RP from the RPset. the shut down RP from the RP-set.
[NOTE: Should a new BSM be sent immediately when C-RP-Adv with HoldTime
of 0 is received? Need to clarify.]
[NOTE: what happens if the message becomes too large to fit in a single
packet? With the per-mapping timers, it's not a problem to send several
advertisements. We need to say something about this.]
3.2. Creating the RP-Set at the BSR 3.2. Creating the RP-Set at the BSR
Upon receiving a C-RP-Adv, if the router is not the elected BSR, it Upon receiving a C-RP-Adv, if the router is not the elected BSR, it
silently ignores the message. silently ignores the message.
If the router is the BSR, then it adds the RP address to its local pool If the router is the BSR, it creates a group-to-C-RP mapping for every
of candidate RPs. For each C-RP, the BSR holds the following group range in the C-RP-Adv. These mappings have identical values for
information: the C-RP address, C-RP priority and holdtime. The hash mask length is a
global property of the BSR and is therefore the same for all mappings
IP address managed by the BSR.
The IP address of the C-RP.
Group Prefix and Mask list [NOTE: This is substantially different from version 03, where state was
The list of group prefixes and group masks from the C-RP kept per C-RP. The behaviour is the same if a C-RP always sends all
advertisement. advertisements in a single message. However, there seems to be no
requirement for this (and the case where all advertisements don't fit in
HoldTime a single message seems not to be covered). Keeping state per group
The HoldTime from the C-RP-Adv message. This is included mapping allows a C-RP to send C-RP-Advs in chunks and even allows for
later in the RP-set information in the Bootstrap Message. different holdtimes for different group ranges (which may or may not be
useful) while being compatible with the old version.]
C-RP Expiry Timer Every mapping that is not part of the C-RP-set is added to the C-RP-set
The C-RP-Expiry Timer is used to time out the state associated and the associated group-to-C-RP mapping expiry timer (CGET) is
with a C-RP when the BSR fails to receive C-RP-Advertisements initialized to the holdtime.
from it. The expiry timer is initialized to the HoldTime from
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 If a mapping already exists (i.e. the C-RP-set contains a mapping with
The C-RP Priority is used to determine the subset of possible identical group-range and C-RP-address), it is updated with the
RPs to use in the RP-Set. Smaller values are deemed to be of information from the BSM and its associated CGET is reset to the
higher priority than large ones. holdtime from the BSM. If the holdtime is zero, the mapping is
immediately removed from the C-RP-set.
When the C-RP Expiry Timer expires, the C-RP is removed from the pool of When a CGET expires, the corresponding group-to-C-RP mapping is removed
available C-RPs. from the C-RP-set.
The BSR uses the pool of C-RPs to construct the RP-Set which is included The BSR constructs the RP-set from the C-RP-set. It may apply a local
in Bootstrap Messages and sent to all the routers in the PIM domain. policy to limit the number of Candidate RPs included in the RP-set. The
The BSR may apply a local policy to limit the number of Candidate RPs BSR may override the prefix indicated in a C-RP-Adv unless the
included in the Bootstrap message. The BSR may override the prefix `Priority' field from the C-RP-Adv is less than 128.
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- For inclusion in a BSM, the RP-set is subdivided into sets of {group-
Count, RP-addresses}. For each RP-address, the corresponding HoldTime prefix, RP-Count, RP-addresses}. For each RP-address, the corresponding
is included in the "RP-HoldTime" field. The format of the Bootstrap HoldTime is included in the "RP-HoldTime" field. The format of the
message allows `semantic fragmentation', if the length of the original Bootstrap message allows `semantic fragmentation', if the length of the
Bootstrap message exceeds the packet maximum boundaries. However, we original Bootstrap message exceeds the packet maximum boundaries.
recommend against configuring a large number of routers as C-RPs, to However, we recommend against configuring a large number of routers as
reduce the semantic fragmentation required. C-RPs, to reduce the semantic fragmentation required.
When an elected BSR is being shut down, it should immediately originate When an elected BSR is being shut down, it should immediately originate
a Bootstrap message listing its current RP set, but with the BSR a Bootstrap message listing its current RP-Set, but with the BSR
priority field set to the lowest priority value possible. This will priority field set to the lowest priority value possible. This will
cause the election of a new BSR to happen more quickly. cause the election of a new BSR to happen more quickly.
3.3. Forwarding Bootstrap Messages 3.3. Forwarding Bootstrap Messages
Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by
intermediate routers if they pass the Bootstrap Message Processing intermediate routers if they pass the Bootstrap Message Processing
Check. Bootstrap messages are multicast to the `ALL-PIM-ROUTERS' group. Check. Bootstrap messages are multicast to the `ALL-PIM-ROUTERS' group.
When a BS message is forwarded, it is forwarded out of every multicast- When a BS message is forwarded, it is forwarded out of every multicast-
capable interface which has PIM neighbors (excluding the one over which capable interface which has PIM neighbors (including the one over which
the message was received). The exception to this is if the interface is the message was received). The exception to this is if the interface is
an administrative scope boundary for the admin scope zone indicated in an administrative scope boundary for the admin scope zone indicated in
the first group address in the BS message packet. The IP source address 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 on the bootstrap message should be set to the forwarding router's IP
address on the interface the message is being forwarded from. Bootstrap address on the interface the message is being forwarded from. Bootstrap
messages are always originated or forwarded with an IP TTL value of 1. messages are always originated or forwarded with an IP TTL value of 1.
3.4. Receiving and Using the RP-Set As an optimization, a router MAY choose not to forward a BSM out of the
interface the message was received on if that interface is a point-to-
point interface. On interfaces with multiple PIM neighbors, a router
SHOULD forward an accepted BSM onto the interface that BSM was received
on, but if the number of PIM neighbors on that interface is large, it
MAY delay forwarding a BSM onto that interface by a small randomized
interval to prevent message implosion. A configuration option MAY be
provided to disable forwarding onto the interface a message was received
on, but we recommend that the default behavior is to forward onto that
interface.
When a router receives and stores a new RP-Set, it checks if each of the Rationale: A BSM needs to be forwarded onto the interface the message
RPs referred to by existing state (i.e., by (*,G), (*,*,RP), or was received on (in addition to the other interfaces) because the
(S,G,rpt) entries) is in the new RP-Set. routers on a LAN may not have consistent routing information. If three
routers on a LAN are A, B, and C, and at router B RPF(BSR)==A and at
router C RPF(BSR)==B, then router A originally forwards the BSM onto the
LAN, but router C will only accept it when router B re-forwards the
message onto the LAN. If the underlying routing protocol configuration
guarantees that the routers have consistent routing information, then
forwarding onto the incoming interface may safely be disabled.
If an RP is not in the new RP-Set, that RP is considered unreachable and 3.4. Receiving and Using the RP-Set
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, [NOTE: what should go into this section? It doesn't make sense to
the hash value of the new RP is calculated for each group covered by the repeat what is said in the "Store RP-set" action.]
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 RP-set maintained by BSR is used by RP-based multicast routing
the new RP. protocols like PIM-SM and Bi-directional PIM. These protocols may
obtain RP-sets from other sources as well. How the final group-to-RP
mappings are obtained from these RP-sets is not part of the BSR
specification. In general, the routing protocols need to re-calculate
the mappings when any of their RP-sets change. How such a change is
signalled to the routing protocol is also not part of the present
specification.
4. Message Formats 4. Message Formats
BSR messages are PIM messages, as defined in [3]. The values of the PIM BSR messages are PIM messages, as defined in [1]. The values of the PIM
message Type field for BSR messages are: message Type field for BSR messages are:
4 Bootstrap Message 4 Bootstrap Message
8 Candidate-RP-Advertisement 8 Candidate-RP-Advertisement
In this section we use the following terms defined in the PIM-SM [3]: In this section we use the following terms defined in the PIM-SM [1]:
o Encoded-Unicast format o Encoded-Unicast format
o Encoded-Group format o Encoded-Group format
We repeat these here to aid readability. We repeat these here to aid readability.
Encoded-Unicast address Encoded-Unicast address
An Encoded-Unicast address takes the following format: An Encoded-Unicast address takes the following format:
skipping to change at page 22, line 6 skipping to change at page 22, line 28
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address | Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
The PIM address family of the `Unicast Address' field of this The PIM address family of the `Unicast Address' field of this
address. address.
Values of 0-127 are as assigned by the IANA for Internet Address 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 Families in [7]. Values 128-250 are reserved to be assigned by the
IANA for PIM-specific Address Families. Values 251 though 255 are IANA for PIM-specific Address Families. Values 251 though 255 are
designated for private use. As there is no assignment authority designated for private use. As there is no assignment authority
for this space, collisions should be expected. for this space, collisions should be expected.
Encoding Type Encoding Type
The type of encoding used within a specific Address Family. The The type of encoding used within a specific Address Family. The
value `0' is reserved for this field, and represents the native value `0' is reserved for this field, and represents the native
encoding of the Address Family. encoding of the Address Family.
Unicast Address Unicast Address
The unicast address as represented by the given Address Family and The unicast address as represented by the given Address Family and
Encoding Type. Encoding Type.
Encoded-Group address Encoded-Group address
Encoded-Group addresses take the following format: Encoded-Group addresses take the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Reserved |Z| Mask Len | | Addr Family | Encoding Type |B| Reserved |Z| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address | Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
described above. described above.
Encoding Type Encoding Type
described above. described above.
[B]IDIR bit
When set, all BIDIR capable PIM routers will operate the protocol
described in [3] for the specified group range.
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Admin Scope [Z]one Admin Scope [Z]one
When set, this bit indicates that this group address range is an When set, this bit indicates that this group address range is an
administratively scoped range. administratively scoped range.
Mask Len Mask Len
The Mask length field is 8 bits. The value is the number of The Mask length field is 8 bits. The value is the number of
contiguous one bits left justified used as a mask which, combined contiguous one bits left justified used as a mask which, combined
skipping to change at page 25, line 11 skipping to change at page 26, line 11
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address m (Encoded-Unicast format) | | RP Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm Holdtime | RPm Priority | Reserved | | RPm Holdtime | RPm Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum PIM Version, Reserved, Checksum
Described in [3]. Described in [1].
Type PIM Message Type. Value is 4 for a Bootstrap Message. Type PIM Message Type. Value is 4 for a Bootstrap Message.
Fragment Tag Fragment Tag
A randomly generated number, acts to distinguish the fragments A randomly generated number, acts to distinguish the fragments
belonging to different Bootstrap messages; fragments belonging to belonging to different Bootstrap messages; fragments belonging to
same Bootstrap message carry the same `Fragment Tag'. same Bootstrap message carry the same `Fragment Tag'.
Hash Mask len Hash Mask len
The length (in bits) of the mask to use in the hash function. For 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 IPv4 we recommend a value of 30. For IPv6 we recommend a value of
126. 126.
BSR priority BSR priority
Contains the BSR priority value of the included BSR. This field is Contains the BSR priority value of the included BSR. This field is
considered as a high order byte when comparing BSR addresses. Note considered as a high order byte when comparing BSR addresses. Note
that for historical reasons, the highest BSR priority priority is that for historical reasons, the highest BSR priority is 255 (the
255 (the higher the better), whereas the highest RP Priority (see higher the better), whereas the highest RP Priority (see below) is
below) is 0 (the lower the better). 0 (the lower the better).
Unicast 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 [3]. 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 [3]. In a fragment containing are associated. Format described in [1]. In a fragment containing
admin scope ranges, the first group address in the fragment MUST be admin scope ranges, the first group address in the fragment MUST be
the group range for the entire admin scope range, and this MUST 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 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 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 case the sub-ranges for the RP-Set are specified later in the
fragment along with their RPs. fragment along with their RPs.
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 does Bootstrap message for the corresponding group prefix. A router does
not replace its old RP-Set for a given group prefix until/unless it not replace its old RP-Set for a given group prefix until/unless it
receives `RP-Count' addresses for that prefix; the addresses could receives `RP-Count' addresses for that prefix; the addresses could
be carried over several fragments. If only part of the RP-Set for be carried over several fragments. If only part of the RP-Set for
a given group prefix was received, the router discards it, without a given group prefix was received, the router discards it, without
updating that specific group prefix's RP-Set. updating that specific group prefix's RP-Set.
Frag RP Cnt 1..m Frag RP Cnt 1..m
The number of Candidate RP addresses included in this fragment of The number of Candidate RP addresses included in this fragment of
the Bootstrap message, for the corresponding group prefix. The the Bootstrap message, for the corresponding group prefix. The
`Frag RP-Cnt' field facilitates parsing of the RP-Set for a given `Frag RP Cnt' field facilitates parsing of the RP-Set for a given
group prefix, when carried over more than one fragment. group prefix, when carried over more than one fragment.
RP address 1..m RP address 1..m
The address of the Candidate RPs, for the corresponding group The address of the Candidate RPs, for the corresponding group
prefix. The format for these addresses is given in the Encoded- prefix. The format for these addresses is given in the Encoded-
Unicast address in [3]. Unicast address in [1].
RP1..m Holdtime RP1..m Holdtime
The Holdtime for the corresponding RP. This field is copied from The Holdtime for the corresponding RP. This field is copied from
the `Holdtime' field of the associated RP stored at the BSR. the `Holdtime' field of the associated RP stored at the BSR.
RP1..m Priority RP1..m Priority
The `Priority' of the corresponding RP and Encoded-Group Address. The `Priority' of the corresponding RP and Encoded-Group Address.
This field is copied from the `Priority' field stored at the BSR This field is copied from the `Priority' field stored at the BSR
when receiving a Candidate-RP-Advertisement. The highest priority when receiving a Candidate-RP-Advertisement. The highest priority
is `0' (i.e. unlike BSR priority, the lower the value of the is `0' (i.e. unlike BSR priority, the lower the value of the
skipping to change at page 27, line 31 skipping to change at page 28, line 31
receiving the BSM. receiving the BSM.
If the list of RPs for a single group-prefix is too long to fit in a 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 single BSMF packet, then that information must be split across multiple
BSMF packets. In this case, all the BSMF packets comprising the BSMF packets. In this case, all the BSMF packets comprising the
information for that group-prefix must be received before the group-to- 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 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 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 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 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 mapping can be used for that group-prefix. If a single BSMF from such a
large group-prefix is lost, then that entire group-prefix will have to large group-prefix is lost, then that entire group-prefix will have to
wait until the next BSM is originated. wait until the next BSM is originated.
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 seconds. Thus 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 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 group-prefix, but with a RP Count of zero, and it should resend this
skipping to change at page 28, line 15 skipping to change at page 29, line 15
4.2. Candidate-RP-Advertisement Format 4.2. Candidate-RP-Advertisement Format
Candidate-RP-Advertisements are periodically unicast from the C-RPs to Candidate-RP-Advertisements are periodically unicast from the C-RPs to
the BSR. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Cnt | Priority | Holdtime | | Prefix Count | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address (Encoded-Unicast format) | | RP Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) | | Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address n (Encoded-Group format) | | Group Address n (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum PIM Version, Reserved, Checksum
Described in [3]. Described in [1].
Type PIM Message Type. Value is 8 for a Candidate-RP-Advertisement Type PIM Message Type. Value is 8 for a Candidate-RP-Advertisement
Message. Message.
Prefix Cnt Prefix Count
The number of encoded group addresses included in the message; The number of encoded group addresses included in the message;
indicating the group prefixes for which the C-RP is advertising. A 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 Count 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 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 configured with Group-prefix information, the C-RP puts a default
value of `0' in this field. value of `0' in this field.
Priority Priority
The `Priority' of the included RP, for the corresponding Encoded- The `Priority' of the included RP, for the corresponding Encoded-
Group Address (if any). highest priority is `0' (i.e. the lower Group Address (if any). highest priority is `0' (i.e. the lower
the value of the `Priority' field, the higher the priority). This the value of the `Priority' field, the higher the priority). This
field is stored at the BSR upon receipt along with the RP address field is stored at the BSR upon receipt along with the RP address
and corresponding Encoded-Group Address. and corresponding Encoded-Group Address.
Holdtime Holdtime
The amount of time the advertisement is valid. This field allows The amount of time the advertisement is valid. This field allows
advertisements to be aged out. advertisements to be aged out.
RP Address RP Address
The address of the interface to advertise as a Candidate RP. The The address of the interface to advertise as a Candidate RP. The
format for this address is given in the Encoded-Unicast address in format for this address is given in the Encoded-Unicast address in
[3]. [1].
Group Address-1..n Group Address-1..n
The group prefixes for which the C-RP is advertising. Format The group prefixes for which the C-RP is advertising. Format
described in Encoded-Group-Address in [3]. described in Encoded-Group-Address in [1].
5. Default Values for Timers 5. Default Values for Timers
Timer Name: Bootstrap Timer (BST) Timer Name: Bootstrap Timer (BST)
+-------------------+--------------------------+------------------------+ +-------------------+--------------------------+------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+-------------------+--------------------------+------------------------+ +-------------------+--------------------------+------------------------+
| BS Period | Default: 60 secs | Period between | | BS Period | Default: 60 secs | Period between |
| | | originating |
| | | bootstrap messages | | | | bootstrap messages |
+-------------------+--------------------------+------------------------+ +-------------------+--------------------------+------------------------+
| BS Timeout | 2 * BS_Period + 10 | Period after last | | BS Timeout | 2 * BS_Period + 10 | Period after last |
| | seconds | BS message before | | | seconds | BS message before |
| | | BSR is timed out | | | | BSR is timed out |
| | | and election | | | | and election |
| | | begins | | | | begins |
+-------------------+--------------------------+------------------------+ +-------------------+--------------------------+------------------------+
| rand_override | rand(0, 5.0 secs) | Suppression period | | rand_override | rand(0, 5.0 secs) | Suppression period |
| | | in BSR election to | | | | in BSR election to |
| | | prevent thrashing | | | | prevent thrashing |
+-------------------+--------------------------+------------------------+ +-------------------+--------------------------+------------------------+
Timer Name: C-RP Expiry Timer (CET(R)) Timer Name: Group-to-C-RP apping Expiry Timer (CGET(M,Z))
+----------------+------------------+-----------------------------------+ +----------------------+--------------+---------------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+----------------+------------------+-----------------------------------+ +----------------------+--------------+---------------------------------+
| C-RP Timeout | from message | Hold time from C-RP-Adv message | |C-RP Mapping Timeout |from message | Hold time from C-RP-Adv message |
+----------------+------------------+-----------------------------------+ +----------------------+--------------+---------------------------------+
C-RP Advertisement messages are sent periodically with period C-RP-Adv- 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 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 specified in a C-RP-Adv message should be set to (2.5 * C-RP-Adv-Period
). This timer is used for group-to-C-RP mappings in the C-RP-set at the
BSR.
). Timer Name: Group-to-RP mapping Expiry Timer (GET(M,Z))
+------------------------+--------------------+-------------------------+
| Value Name | Value | Explanation |
+------------------------+--------------------+-------------------------+
| RP Mapping Timeout | from message | Hold time from BSM |
+------------------------+--------------------+-------------------------+
This timer is identical to CGET, except that it applies to the mappings
in the RP-set rather than the C-RP-set.
Timer Name: C-RP Advertisement Timer (CRPT) Timer Name: C-RP Advertisement Timer (CRPT)
+--------------------+--------------------------+-----------------------+ +--------------------+--------------------------+-----------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+--------------------+--------------------------+-----------------------+ +--------------------+--------------------------+-----------------------+
| C-RP-Adv-Period | Default: 60 seconds | Period with which | | C-RP-Adv-Period | Default: 60 seconds | Period with which |
| | | periodic C-RP | | | | periodic C-RP |
| | | Advertisements are | | | | Advertisements are |
| | | sent to BSR | | | | sent to BSR |
skipping to change at page 32, line 4 skipping to change at page 33, line 19
feature that might be enabled once the configuration of a domain has feature that might be enabled once the configuration of a domain has
stabilized. stabilized.
The primary security requirement for BSR (as for PIM) is that it is The primary security requirement for BSR (as for PIM) is that it is
possible to prevent hosts that are not legitimate PIM routers, either possible to prevent hosts that are not legitimate PIM routers, either
within or outside the domain, from subverting the BSR mechanism. within or outside the domain, from subverting the BSR mechanism.
The Bootstrap Message Processing Checks prevent a router from accepting The Bootstrap Message Processing Checks prevent a router from accepting
a BS message from outside of the PIM Domain, as the source address on BS a BS message from outside of the PIM Domain, as the source address on BS
Messages must be an immediate PIM neighbor. There is however a small Messages must be an immediate PIM neighbor. There is however a small
window of time after a reboot where a PIM router will accept a bad BS window of time after a reboot where a PIM router will accept a bad BS
Message unicast from an immediate neighbor, and it might be possible to Message unicast from an immediate neighbor, and it might be possible to
unicast a BS Message to a router during this interval from outside the unicast a BS Message to a router during this interval from outside the
domain, using the spoofed source address of a neighbor. This can be domain, using the spoofed source address of a neighbor. This can be
prevented if PMBRs perform source-address filtering to prevent packets prevented if PMBRs perform source-address filtering to prevent packets
entering the PIM domain with IP source addresses that are infrastructure entering the PIM domain with IP source addresses that are infrastructure
addresses in the PIM domain. addresses in the PIM domain.
The principle threat to BS Message security comes from hosts within the The principal threat to BS Message security comes from hosts within the
PIM domain that attempt to subvert the BSR mechanism. They may be able PIM domain that attempt to subvert the BSR mechanism. They may be able
to do this by sending PIM messages to their local router, or by to do this by sending PIM messages to their local router, or by
unicasting a BS message to another PIM router during the brief interval unicasting a BS message to another PIM router during the brief interval
after it has restarted. after it has restarted.
All BS Messages SHOULD carry the Router Alert IP option. If a PIM All BS Messages SHOULD carry the Router Alert IP option. If a PIM
router receives a BS Message that does not carry the router alert router receives a BS Message that does not carry the router alert
option, it SHOULD drop it (a configuration option should also be option, it SHOULD drop it (a configuration option should also be
provided to disable this check on a per-interface basic for backward provided to disable this check on a per-interface basic for backward
compatibility with older PIM routers). The Router Alert option allows a compatibility with older PIM routers). The Router Alert option allows a
PIM router to perform checks on unicast packets it would otherwise PIM router to perform checks on unicast packets it would otherwise
blindly forward. All PIM routers should check that packets with Router blindly forward. All PIM routers should check that packets with Router
Alert that are not destined for the router itself are not PIM BootStrap Alert that are not destined for the router itself are not PIM Bootstrap
messages. Any such packets should be dropped and logged as a possible messages. Any such packets should be dropped and logged as a possible
security issue - it is never acceptable for a PIM BS message to travel security issue - it is never acceptable for a PIM BS message to travel
multiple IP hops. multiple IP hops.
Most hosts that are likely to attempt to subvert PIM BSR are likely to Most hosts that are likely to attempt to subvert PIM BSR are likely to
be located on leaf subnets. We recommend that implementors provide a be located on leaf subnets. We recommend that implementors provide a
configuration option that specifies an interface is a leaf subnet, and configuration option that specifies an interface is a leaf subnet, and
that no PIM packets are accepted on such interfaces. that no PIM packets are accepted on such interfaces.
On multi-access subnets with multiple PIM routers and hosts that are not On multi-access subnets with multiple PIM routers and hosts that are not
trusted, we recommend that IPsec AH is used to protect communication trusted, we recommend that IPsec AH is used to protect communication
between PIM routers, and that such routers are configured to drop and between PIM routers, and that such routers are configured to drop and
log communication attempts from any host that do not pass the log communication attempts from any host that do not pass the
authentication check. When all the PIM routers are under the same authentication check. When all the PIM routers are under the same
administrative control, this authentication may use a configured shared administrative control, this authentication may use a configured shared
secret. The securing of interactions between PIM neighbors is discussed secret. The securing of interactions between PIM neighbors is discussed
in more detail in the Security Considerations section of [3], and so we in more detail in the Security Considerations section of [1], and so we
do not discuss the details further here. The same security mechanisms do not discuss the details further here. The same security mechanisms
than can be used to secure PIM Join, Prune and Assert messages should that can be used to secure PIM Join, Prune and Assert messages should
also be used to secure BS messages. also be used to secure BS messages.
6.4. C-RP-Advertisement Security 6.4. C-RP-Advertisement Security
Even if it is not possible to subvert BS Messages, an attacker might be Even if it is not possible to subvert BS Messages, an attacker might be
able to perform most of the same attacks by simply sending C-RP-Adv able to perform most of the same attacks by simply sending C-RP-Adv
messages to the BSR specifying the attacker's choice of RPs. Thus it is messages to the BSR specifying the attacker's choice of RPs. Thus it is
necessary to control the sending of C-RP-Adv messages in essentially the necessary to control the sending of C-RP-Adv messages in essentially the
same ways that we control BS Messages. However, C-RP-Adv messages are same ways that we control BS Messages. However, C-RP-Adv messages are
unicast and normally travel multiple hops, so controlling them is a unicast and normally travel multiple hops, so controlling them is a
skipping to change at page 33, line 35 skipping to change at page 34, line 47
source MAC address is that of a valid PIM neighbor. PMBRs should ensure source MAC address is that of a valid PIM neighbor. PMBRs should ensure
that no C-RP-Adv messages enter the domain from an external neighbor. that no C-RP-Adv messages enter the domain from an external neighbor.
For true security, we recommend that all C-RPs are configured to use For true security, we recommend that all C-RPs are configured to use
IPsec authentication. The authentication process for a C-RP-Adv message IPsec authentication. The authentication process for a C-RP-Adv message
between a C-RP and the BSR is identical to the authentication process between a C-RP and the BSR is identical to the authentication process
for PIM Register messages between a DR and the relevant RP, except that for PIM Register messages between a DR and the relevant RP, except that
there will normally be fewer C-RPs in a domain than there are DRs, so there will normally be fewer C-RPs in a domain than there are DRs, so
key management is a little simpler. We do not describe the details of key management is a little simpler. We do not describe the details of
this process further here, but refer to the Security Considerations this process further here, but refer to the Security Considerations
section of [3]. Note that the use of cryptographic security for C-RP- section of [1]. Note that the use of cryptographic security for C-RP-
Advs does not remove the need for the non-cryptographic mechanisms, as Advs does not remove the need for the non-cryptographic mechanisms, as
explained below. explained below.
6.5. Denial of Service using IPsec 6.5. Denial of Service using IPsec
An additional concern is that of Denial-of-Service attacks caused by An additional concern is that of Denial-of-Service attacks caused by
sending high volumes of BS Messages or C-RP-Adv messages with invalid sending high volumes of BS Messages or C-RP-Adv messages with invalid
IPsec authentication information. It is possible that these messages IPsec authentication information. It is possible that these messages
could overwhelm the CPU resources of the recipient. could overwhelm the CPU resources of the recipient.
skipping to change at page 34, line 20 skipping to change at page 35, line 32
be configured, to be applied to the forwarding of unicast PIM packets be configured, to be applied to the forwarding of unicast PIM packets
containing Router Alert options. The rate-limiter MUST independently containing Router Alert options. The rate-limiter MUST independently
rate-limit different types of PIM packets - for example a flood of C-RP- rate-limit different types of PIM packets - for example a flood of C-RP-
Adv messages MUST NOT cause a rate limiter to drop low-rate BS Messages. Adv messages MUST NOT cause a rate limiter to drop low-rate BS Messages.
Such a rate-limiter might itself be used to cause a denial of service Such a rate-limiter might itself be used to cause a denial of service
attack by causing valid packets to be dropped, but in practice this is attack by causing valid packets to be dropped, but in practice this is
more likely to constrain bad PIM Messages close to their origin. In more likely to constrain bad PIM Messages close to their origin. In
addition, the rate limiter will prevent attacks on PIM from affecting addition, the rate limiter will prevent attacks on PIM from affecting
other activity on the destination router, such as unicast routing. other activity on the destination router, such as unicast routing.
7. Authors' Addresses 7. Contributors
Bill Fenner Bill Fenner, Mark Handley, Roger Kermode and David Thaler have
AT&T Labs - Research contributed greatly to this draft. They were authors of this draft up
75 Willow Road to version 03. Most of the current text is identical to 03.
Menlo Park, CA 94025
fenner@research.att.com
Mark Handley 8. Acknowledgments
ICIR/ICSI
1947 Center St, Suite 600
Berkeley, CA 94708
mjh@icir.org
Roger Kermode PIM-SM was designed over many years by a large group of people,
Motorola Australian Research Centre including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve
Locked Bag 5028 Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri,
Botany NSW 1455, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern,
Australia Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish
Roger.Kermode@motorola.com Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh
Holbrook. This BSR specification draws heavily on text from RFC 2362.
David Thaler 9. IANA Considerations
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
dthaler@Microsoft.com
8. References This document has no actions for IANA.
[1] S. Deering , W. Fenner , B. Haberman, "Multicast Listener Discovery 10. Normative References
[1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Internet Draft draft-ietf-pim-sm-
v2-new-09.ps
[2] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul
1998.
[3] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft-
ietf-pim-bidir-06.txt
11. Informative References
[4] S. Deering , W. Fenner , B. Haberman, "Multicast Listener Discovery
(MLD) for IPv6", RFC 2710, Oct 1999. (MLD) for IPv6", RFC 2710, Oct 1999.
[2] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode [5] 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).
[3] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol [6] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Internet Draft draft-ietf-pim-sm-
v2-new-05.ps
[4] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
2236, Nov 1997. 2236, Nov 1997.
[5] IANA, "Address Family Numbers", linked from [7] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
[6] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul 12. Authors' Addresses
1998.
9. Acknowledgments Nidhi Bhaskar
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
nbhaskar@cisco.com
Alexander Gall
SWITCH
Limmatquai 138
P.O. Box
CH-8021 Zurich
Switzerland
gall@switch.ch
PIM-SM was designed over many years by a large group of people, Stig Venaas
including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve UNINETT
Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, NO-7465 Trondheim
Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Norway
Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish venaas@uninett.no
Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh
Holbrook. This BSR specification draws heavily on text from RFC 2362. Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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