Internet Engineering Task Force                                   PIM WGINTERNET-DRAFT                                          Bill Fenner/AT&Tdraft-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 ModeStatus of this DocumentThis document is an Internet-Draft and is in full conformance with allprovisions of Section 10 of RFC2026.Internet-Drafts are working documents of the Internet Engineering TaskForce (IETF), its areas, and its working groups.  Note that other groupsmay also distribute working documents as Internet-Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime.  It is inappropriate to use Internet- Drafts as reference materialor to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txtThe list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.This document is a product of the IETF PIM WG.  Comments should beaddressed to the authors, or the WG's mailing list atpim@catarina.usc.edu.                                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.  TheFenner/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. . . . . . . . . . . . . . . . . .  12Fenner/Handley/Kermode/Thaler                                   [Page 3]INTERNET-DRAFT            Expires: August 2003             February 20031.  IntroductionNote: this document assumes familiarity with the workings of ProtocolIndependent Multicast - Sparse Mode, as defined in [3], and withAdministratively Scoped Multicast, as described in [6].For correct operation, every PIM Sparse-mode router within a PIM domainmust be able to map a particular global-scope multicast group address tothe same RP.  If this is not the case then black holes may appear, wheresome receivers in the domain cannot receive some groups.  A domain inthis context is a contiguous set of routers that all implement PIM andare configured to operate within a common boundary defined by PIMMulticast Border Routers (PMBRs). PMBRs connect each PIM domain to therest of the internet.A PIM domain may also broken up into multiple administrative scoperegions - these are regions where a border has been configured so that arange of multicast groups will not be forwarded across that border.  Formore information on Administratively Scoped IP Multicast, see RFC 2365.The modified criteria for admin-scoped regions are that the region isconvex with respect to forwarding based on the MRIB, and that all PIMrouters within the same scope region map a particular scoped group tothe same RP within that region.The PIM-SM specification does not mandate the use of a single mechanismto provide routers with the information to perform the group-to-RPmapping.  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 mechanismfrom RFC 2362, and also extends it to cope with administratively scopedregion boundaries.1.1.  General Overview and BackgroundEvery PIM-SM multicast group needs to be associated with the IP addressof a Rendezvous-Point (RP).  When a new multicast sender starts sending,its local Designated Router (DR) will encapsulate these data packets ina 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 Joinmessage towards the RP for that multicast group.  When any PIM routersends a (*,G) Join message, it needs to know which is the next howrouter towards the RP for G to send the message to.  Also when a PIMrouter is forwarding data packets using (*,G) state, it needs to knowwhich is the correct incoming interface for packets destined for G, asit needs to reject any packets that arrive on other interfaces.  Thus itis important for all the PIM routers in a domain to be able to map eachmulticast group to the correct RP address.Fenner/Handley/Kermode/Thaler                     Section 1.1.  [Page 4]INTERNET-DRAFT            Expires: August 2003             February 2003There are a number of ways that group-to-RP mapping can be done; thesimplest solution is for all the routers in the domain to be configuredwith the same information.  However, static configuration generallydoesn't scale well, and also does not dynamically adapt to route aroundrouter or link failures.  The mechanism specified in this document isknown as the PIM BootStrap Router mechanism, or BSR for short, andprovides a dynamic, adaptive mechanism to distribute group-to-RP mappinginformation rapidly throughout a domain.Before we discuss the BSR mechanism itself, we should understand therules a PIM-SM router will apply to the mapping information.Irrespective of how it obtains the mapping information, a PIM-SM routerwill have a mapping table containing multiple entries, each of which hasthe 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; aparticular multicast group may be covered by multiple mapping entries.When this is the case, the router chooses only one of the entries byapplying a deterministic algorithm (specified in the PIM-SM protocolspecification) so that all routers in the domain make the same choice ofentry and hence apply the same group-to-RP mapping.The BSR mechanism provides a way in which viable group-to-RP mappingscan 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 bedetected and the mapping tables will be modified so that the unreachableRP is no longer used, and the new tables will be rapidly distributedthroughout the domain.The general idea behind the BSR-mechanism is that some of the PIMrouters within a PIM domain are configured to be potential RPs for thedomain.  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.  Inaddition, some of the PIM routers in the domain are configured ascandidate bootstrap routers (C-BSRs).  One of these C-BSRs will beelected to serve as the bootstrap router (BSR) for the domain, and allthe PIM routers in the domain will learn the result of this electionthrough Bootstrap messages.  The C-RPs will them report their candidacyto the elected BSR, which will choose a subset of the C-RPs to form theactual set of RPs to the used.  This RP-Set will then be distributed outto all the routers in the domain through Bootstrap messages.Fenner/Handley/Kermode/Thaler                     Section 1.1.  [Page 5]INTERNET-DRAFT            Expires: August 2003             February 2003The mechanism is complicated slightly by the presence ofadministratively-scoped multicast regions within the PIM-SM domain.  Anadmin-scope region is a convex connected set of PIM routers surroundedby an admin-scope boundary.  The boundary specifies a range of multicastaddresses that will not be forwarded into or out of the scoped region.This complicates BSR because we do not want a PIM router within thescoped 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'thappen - this is done by electing a BSR for every admin-scope regionwithin 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 adminscope zone the C-RP is in.  For the remainder of this overview we willignore admin-scope regions, and concentrate on the global BSR and itsrole.  Within each scope zone, the BSR for that zone acts in a similarmanner to how the global BSR acts for the whole domain.There are four basic phases to the BSR mechanism (although in practiceall 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 globalscope and for admin scoping, before specifying the protocol starting insection 2.Fenner/Handley/Kermode/Thaler                     Section 1.1.  [Page 6]INTERNET-DRAFT            Expires: August 2003             February 20031.2.  Overview of Bootstrap and RP Discovery for Global ScopeA small set of routers from a domain are configured as candidate