PIM Working Group R.Kermode Internet Engineering Task Force Motorola INTERNET-DRAFT 2 November 2000 Expires 2 May 2001 PIM-SM Admin Scoped BSR election Status of this Memo 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 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 a "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document describes the means by which the current Boot Strap Router (BSR) election method within the PIM-SM routing protocol can be augmented for use within administratively scoped networks. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Draft PIM-SM Administratively Scoped BSR election 2 Nov 2000 1. Introduction The PIM-SM multicast routing protocol [PIM-SM] is a sparse-mode protocol that requires the explicit designation of a Rendezvous Point (RP) to root the multicast routing tree for a given multicast group. The Boot Strap Router (BSR) election mechanism within PIM-SM provides the means to select one or more routers to act as RPs for ranges of multicast addresses and to further propagate the identity of these routers to all PIM-SM speaking routers within a PIM domain. The current BSR election mechanism assumes globally scoped multicast groups and unfortunately does not work when PIM-SM is deployed within administratively scoped environments where the scope zones are smaller than the PIM-SM domain. The crux of the problem lies in the fact that each administratively scoped zone will require its own BSR and that the election process for each scope zone must stay inside the scope zone. An additional complication arises when one realizes the interdependency that arises when routers use the learn MZAP protocol [RFC2776], which requires the presence of operational multicast routing, to learn about the existence of administrative scopes. This document describes the means by which the current PIM-SM BSR election method can be augmented to work around both of these challenges. 2. The current PIM-SM BSR election mechanism The PIM-SM BSR election is fully described in [PIM-SM]. For the purposes of clarity, it is summarized here, readers who are interested in learning the full details of the PIM-SM BSR election mechanism are referred to [PIM-SM]. The current BSR election mechanism is as follows: o Candidate Boot Strap Routers (C-BSRs) perform a dynamic prioritized announce-listen distributed election to choose a BSR for specific ranges of multicast addresses. o The BSR-election take place via the use of Boostrap messages which are multicast with TTL=1 to the global ALL-PIM-ROUTERS group. o PIM routers perform a pruned-flood of received Bootstrap messages out of all multicast-enabled interfaces after first performing an RPF check on the originator of the messages. Hence, there is no need for multicast routing to be active in order for the election to take place. Expires 2 May 2001 [Page 2] Draft PIM-SM Administratively Scoped BSR election 2 Nov 2000 o Once elected, a BSR periodically resends BSR messages to inform all PIM routers of its election and the fact that it is still alive. o Candidate RP routers (C-RPs) periodically unicast notification of their eligibility to act as an RP for a range of multicast addresses to the BSR, which then collects this information into a set of C-RPs and sent in subsequent Boostrap messages. o PIM routers within a PIM domain listen to the boostrap messages and hence learn about which RP to use for a specific group. 3. Why global BSR election doesn't work for Administrative Scopes The application of the current BSR election mechanism within administrative scopes that are smaller than the PIM-domain results in only one BSR being elected for the entire PIM-SM domain. This means that the BSR will be located outside of all but one of any scopes zones smaller than the PIM-SM domain. This situation is illustrated below which shows three small scope zones; Zones 1, 2, and 3, and one large scope zone, Zone 4, which is the union of the three small scopes and had a boundary that matches that of the PIM domain. Consider the case where the election process has taken place and router A has been elected as the BSR. In this case router A can act as the BSR for the Zone 2 and for Zone 4. It cannot, however, act as the BSR for zones 2 and 3 since this requires that the traffic for these scopes be forwarded outside of their respective scope zone boundaries. One can also see that electing either router B or C as the BSR would result in a similar problem. +----------+---------+ ----- PIM domain boundary and scope | Zone 1 : Zone 2 | zone boundary for the large | : B | scope zone, Zone 4. | A :.........+ ..... Internal scope zone boundary | : Zone 3 | for the smaller scope zones: | : C | Zones 1, 2, and 3. +----------+---------+ A,B,C Candidate BSRs Figure 1: BSR outside of scope example Expires 2 May 2001 [Page 3] Draft PIM-SM Administratively Scoped BSR election 2 Nov 2000 4. Solution to the external BSR problem A general solution to the problem stated in section 3 is to extend the current BSR election mechanism so that each scope zone is guaranteed to have a BSR located within its border when the scope zones are smaller than the PIM-SM domain in which they reside. While this may seem trivial there are a number of complications that must be addressed as will be shown in the following sections. 4.1. Initial Solution At a first glance, providing a BSR for each scope-zone appears simple: Create a new scope relative address for each scope, the ALL-PIM-ROUTERS- THIS-SCOPE group, and transmit all bootstrap messages over the scope relative address instead of the global ALL-PIM-ROUTERS address. This approach uses the scope zones themselves to restrict the election process to within each scope and to furthermore differentiate between elections within different scopes. Unfortunately, this approach will not work since it overlooks two complications that result from the application of scope relative elections. 4.1.1. Complication 1 - Circular dependency with MZAP The first complication relates to the fact that routers will usually learn about the existence of scope zones via Zone Announce Messages (ZAMs) sent using the MZAP protocol [RFC2776]. The complication is that MZAP requires a working multicast routing protocol in order to distributed the ZAMs. Thus, a circular dependency arises in that within a pure PIM-SM domain, PIM routers require MZAP in order to learn about the scope zones, while MZAP requires that PIM-SM be up and working for the ZAMs to be distributed. 4.1.2. Complication 2 - Scopes larger than the PIM domain The second complication that arises from the use of scope relative addresses for the BSR election when the scope is bigger than the PIM domain. When this is the case the BSR messages intended for inside a particular PIM domain are forwarded outside the original PIM domain and into other PIM domains. This leakage causes BSR elections from one PIM domain to needlessly involve routers in other PIM domains, an artifact that breaks the intra domain requirement inherent within PIM's design. Expires 2 May 2001 [Page 4] Draft PIM-SM Administratively Scoped BSR election 2 Nov 2000 4.1.3. MZAP's routing requirements At this stage it is worth examining exactly what kind of forwarding service MZAP assumes to be present in order for it to function correctly. Multicast administrative scopes are well defined for IPv6 [RFC2373]. That is scopes with smaller SCOP values nest within scopes with larger SCOP values. Furthermore, since the SCOP values are contained within the IPv6 multicast address themselves, the scope address boundaries and scope relative addresses are pre-defined. IPv4 multicast administratively scopes, on the other hand, are not well defined; scope values are not explicitly stated, scopes may or may not nest, and the address ranges for each scope are variable. Consequently, the routers do not know which addresses are used to forward MZAP's ZAM messages prior to the scopes being announced. Given the above one must therefore conclude that when MZAP is used within a sparse mode domain the routers must support dense mode forwarding and confine multicast traffic to within the domain until such time that sparse mode operation becomes available. 4.2. Final Solution The key to solving the circular dependency complication lies in the way PIM-SM forwards BSR messages. PIM-SM assumes that no routing protocol is present and uses a pruned flooding mechanism to disperse the messages. A similar mechanism can be used to forward MZAP traffic and hence eliminate the complication. (N.B. it should be noted that the resulting solution looks very similar to Cisco's proprietary auto-rp mechanism). The mechanism is as follows: 1) Require that PIM routers MUST learn about the existence of a scope before commencing a BSR election for that scope. 2) Require that for chunks of multicast address space for which there is no known scope or BSR, PIM-SM routers MUST forward multicast traffic using the same RPF-checked mechanism they use for forwarding BSR messages with the following two exceptions a) TTLs are not reset to 1 and are instead decremented in the standard manner. b) Traffic is not forwarded to interfaces which would result Expires 2 May 2001 [Page 5] Draft PIM-SM Administratively Scoped BSR election 2 Nov 2000 in a domain or scope border being broken. Routers affected by this clause will be pre-configured and hence be able to determine the presence of such a border between its various interfaces. 3) Once a scope is successfully identified, the routers within a scope-zone may start a BSR election process. 4) Perform BSR elections independently within each scope by mandating that, for the chunk of multicast address space designated for admin scoped multicast BSR, messages will be sent to the well-known ALL-PIM-ROUTERS-THIS-SCOPE group instead of the global ALL-PIM-ROUTERS group. 5) Once a BSR is elected for a scope zone and C-RP information has been disseminated, all groups within that scope zone cease to run in dense-mode and instead run using PIM-SM with the one exception being that of the ALL-PIM-ROUTERS-THIS-SCOPE group for that scope which continues to run dense mode. 5. Summary The solution described above solves the problems which stem from the requirement of per-scope zone BSRs, and the MZAP/PIM-SM circular dependency that arise when PIM-SM is deployed within administratively scoped multicast networks. Specially the solution ensures that: o An RP is independently elected for each scope-zone. o MZAP now works inside PIM-SM domains prior to a BSR being elected when RPs have been announced. o There are no dependencies on PIM-SM by MZAP, and hence no changes to MZAP are required for it to operate in PIM-SM domains. o The solution allows PIM-SM routers to learn about scopes by means other than MZAP, and hence there's no dependence on MZAP by PIM-SM. o RPs for large scope zones are announced within the confines of a PIM domain and not outside it. Expires 2 May 2001 [Page 6] Draft PIM-SM Administratively Scoped BSR election 2 Nov 2000 6. IANA Considerations [ALL-PIM-ROUTERS-THIS-SCOPE]: A well-known scope relative multicast address to be assigned by IANA should this proposal be accepted. 7. Security Considerations The successful operation of the administratively scoped BSR election mechanism described within this document is dependent upon the current BSR mechanism used within PIM-SM and the correct operation. As such this mechanism is subject to the same weaknesses and attacks that may be perpetrated upon MZAP and the current PIM-SM BSR election mechanism. Readers are referred to Security Considerations section of the documents defining these protocols for further details. 8. Acknowledgements The Author would like to acknowledge the useful feedback he's about to receive from the member of the PIM WG that will help shape and refine this document! 9. References [PIM-SM] Fenner, W., Handley, M., Holbrook, H., Kouvelas, I. "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)," draft-ietf-pim-sm-v2-new-00.txt, work-in- progress. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast," RFC 2365, July 1998 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC2776] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000. Expires 2 May 2001 [Page 7] Draft PIM-SM Administratively Scoped BSR election 2 Nov 2000 10. Author's Addresses Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany NSW 1455, Australia. Roger.Kermode@motorola.com 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Expires 2 May 2001 [Page 8] Draft PIM-SM Administratively Scoped BSR election 2 Nov 2000 Table of Contents 1 Introduction .................................................... 2 2 The current PIM-SM BSR election mechanism ....................... 2 3 Why global BSR election doesn't work for Administrative Scopes .............................................................. 3 4 Solution to the external BSR problem ............................ 4 4.1 Initial Solution .............................................. 4 4.1.1 Complication 1 - Circular dependency with MZAP .............. 4 4.1.2 Complication 2 - Scopes larger than the PIM domain .......... 4 4.1.3 MZAP's routing requirements ................................. 5 4.2 Final Solution ................................................ 5 5 Summary ......................................................... 6 6 IANA Considerations ............................................. 7 7 Security Considerations ......................................... 7 8 Acknowledgements ................................................ 7 9 References ...................................................... 7 10 Author's Addresses ............................................. 8 11 Full Copyright Statement ....................................... 8 Expires 2 May 2001 [Page 9]