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

BCAST Implementation for NS2

Internet Engineering Task Force                                   PIM WG
INTERNET-DRAFT                                          Bill Fenner/AT&T
draft-ietf-pim-sm-bsr-03.txt                           Mark Handley/ICIR
                                                  Roger Kermode/Motorola
                                                  David Thaler/Microsoft
                                                        25 February 2003
                                                    Expires: August 2003


          Bootstrap Router (BSR) Mechanism for PIM Sparse Mode



Status of this Document

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This document is a product of the IETF PIM WG.  Comments should be
addressed to the authors, or the WG's mailing list at
[e-mail].

                                Abstract


     This document specifies the Bootstrap Router (BSR) mechanism
     for Protocol Independent Multicast - Sparse Mode (PIM-SM).
     BSR is one way that a PIM-SM router can learn the set of
     group-to-RP mappings required in order to function.  The



Fenner/Handley/Kermode/Thaler                                   [Page 1]

INTERNET-DRAFT            Expires: August 2003             February 2003


     mechanism is dynamic, largely self-configuring, and robust to
     router failure.

















































Fenner/Handley/Kermode/Thaler                                   [Page 2]

INTERNET-DRAFT            Expires: August 2003             February 2003


                           Table of Contents


     1. Introduction. . . . . . . . . . . . . . . . . . . . . .   4
      1.1. General Overview and Background. . . . . . . . . . .   4
      1.2. Overview of Bootstrap and RP Discovery for
      Global Scope. . . . . . . . . . . . . . . . . . . . . . .   7
      1.3. Administratively Scoped Multicast and BSR. . . . . .   7
     2. BSR State and Timers. . . . . . . . . . . . . . . . . .   9
     3. Bootstrap Router Election and RP-Set
     Distribution . . . . . . . . . . . . . . . . . . . . . . .  10
      3.1. Sending Candidate-RP-Advertisements. . . . . . . . .  18
      3.2. Creating the RP-Set at the BSR . . . . . . . . . . .  19
      3.3. Forwarding Bootstrap Messages. . . . . . . . . . . .  20
      3.4. Receiving and Using the RP-Set . . . . . . . . . . .  21
     4. Message Formats . . . . . . . . . . . . . . . . . . . .  21
      4.1. Bootstrap Message Format . . . . . . . . . . . . . .  23
       4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . .  26
      4.2. Candidate-RP-Advertisement Format. . . . . . . . . .  28
     5. Default Values for Timers . . . . . . . . . . . . . . .  29
     6. Security Considerations . . . . . . . . . . . . . . . .  30
      6.1. Possible Threats . . . . . . . . . . . . . . . . . .  30
      6.2. Limiting Third-Party DoS Attacks . . . . . . . . . .  31
      6.3. BS Message Security. . . . . . . . . . . . . . . . .  31
      6.4. C-RP-Advertisement Security. . . . . . . . . . . . .  33
      6.5. Denial of Service using IPsec. . . . . . . . . . . .  33
     7. Authors' Addresses. . . . . . . . . . . . . . . . . . .  34
     8. References. . . . . . . . . . . . . . . . . . . . . . .  35
     9. Acknowledgments . . . . . . . . . . . . . . . . . . . .  35



                            List of Figures


     Figure 1. Per-Scope-Zone State-machine for a candi-
     date BSR . . . . . . . . . . . . . . . . . . . . . . . . .  10
     Figure 2. Per-Scope-Zone State-machine for a router
     not configured as C-BSR. . . . . . . . . . . . . . . . . .  12












Fenner/Handley/Kermode/Thaler                                   [Page 3]

INTERNET-DRAFT            Expires: August 2003             February 2003


1.  Introduction

Note: this document assumes familiarity with the workings of Protocol
Independent Multicast - Sparse Mode, as defined in [3], and with
Administratively Scoped Multicast, as described in [6].

For correct operation, every PIM Sparse-mode router within a PIM domain
must be able to map a particular global-scope 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 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
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
more information on Administratively Scoped IP Multicast, see RFC 2365.
The modified criteria for admin-scoped regions are that the region 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
the same RP within that region.

The PIM-SM specification does not mandate the use of a single mechanism
to provide routers with the information to perform the group-to-RP
mapping.  This document describes the Bootstrap Router (BSR) mechanism.
BSR was first defined in RFC 2362 [2], which has since been obsoleted.
This document provides an updated specification of the BSR mechanism
from RFC 2362, and also extends it to cope with administratively scoped
region boundaries.

1.1.  General Overview and Background

Every PIM-SM multicast group needs to be associated with the IP address
of a Rendezvous-Point (RP).  When a new multicast sender starts sending,
its local Designated Router (DR) will encapsulate these data packets in
a PIM Register message and send them to the RP for that multicast group.
When a new multicast receiver joins, its local DR will send a PIM Join
message towards the RP for that multicast group.  When any PIM router
sends a (*,G) Join message, it needs to know which is the next how
router towards the RP for G to send the message to.  Also when a PIM
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.




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


There are a number of ways that group-to-RP mapping can be done; the
simplest solution is for all the routers in the domain to be configured
with the same information.  However, static configuration generally
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
rules a PIM-SM router will apply to the mapping information.
Irrespective of how it obtains the mapping information, a PIM-SM router
will have a mapping table containing multiple entries, each of which has
the following form:

o Multicast group range, expressed as an address and prefix length.

o RP Priority.

o IP address of RP.

In general, these mapping entries may overlap in arbitrary ways; a
particular multicast group may be covered by multiple mapping entries.
When this is the case, the router chooses only one of the entries by
applying a deterministic algorithm (specified in the PIM-SM protocol
specification) so that all routers in the domain make the same choice of
entry and hence apply the same group-to-RP mapping.

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.
It is adaptive, in that if an RP becomes unreachable, this will be
detected and the mapping tables will be modified so that the unreachable
RP is no longer used, and the new tables will be rapidly distributed
throughout the domain.

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
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
addition, some of the PIM routers in the domain are configured as
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
the PIM routers in the domain will learn the result of this election
through Bootstrap messages.  The C-RPs will them report their candidacy
to the elected BSR, which will choose a subset of the C-RPs to form the
actual set of RPs to the used.  This RP-Set will then be distributed out
to all the routers in the domain through Bootstrap messages.




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


The mechanism is complicated slightly by the presence of
administratively-scoped multicast regions within the PIM-SM domain.  An
admin-scope region is a convex connected set of PIM routers surrounded
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.
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).
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
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
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
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.

There are four basic phases to the BSR mechanism (although in practice
all phases may by occurring simultaneously):

1.   BSR election.  Each Candidate-BSR originates bootstrap messages
     (BSMs).  Every BSM contains a BSR priority field.  Routers within
     the domain flood the BSMs throughout the domain.  A C-BSR that
     hears about a higher-priority C-BSR than itself then suppresses its
     sending of further BSMs for some period of time.  The single
     remaining C-BSR becomes the elected BSR, and its BSMs inform all
     the other routers in the domain that it is the elected BSR.

2.   C-RP advertisement.  Each Candidate-RP within a domain sends
     periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the
     elected BSR.  In this way, the BSR learns about possible RPs that
     are currently up and reachable.

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
     should do this in such a way that the RP-Set is neither too large
     to inform all the routers in the domain about, nor too small so
     that load is overly concentrated on some RPs.  It should also
     attempt to produce an RP-Set that does not change frequently.

4.   RP-Set Flooding.  In future bootstrap messages, the BSR includes
     the RP-Set information.  As bootstrap messages are flooded rapidly
     through the domain, this ensures that the RP-Set rapidly reaches
     all the routers in the domain.  BSMs are originated periodically to
     ensure consistency after failure restoration.

In the following sections we discuss more details about BSR for global
scope and for admin scoping, before specifying the protocol starting in
section 2.



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


1.2.  Overview of Bootstrap and RP Discovery for Global Scope

A small set of routers from a domain are configured as candidate