diff options
Diffstat (limited to 'doc/rfc/rfc6226.txt')
| -rw-r--r-- | doc/rfc/rfc6226.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc6226.txt b/doc/rfc/rfc6226.txt new file mode 100644 index 0000000..1fb9180 --- /dev/null +++ b/doc/rfc/rfc6226.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Joshi +Request for Comments: 6226 Infosys Technologies Ltd. +Updates: 4601 A. Kessler +Category: Standards Track Cisco Systems, Inc. +ISSN: 2070-1721 D. McWalter + May 2011 + + + PIM Group-to-Rendezvous-Point Mapping + +Abstract + + Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in + a PIM domain that supports Any Source Multicast (ASM) maintains + Group-to-RP mappings that are used to identify a Rendezvous Point + (RP) for a specific multicast group. PIM-SM has defined an algorithm + to choose a RP from the Group-to-RP mappings learned using various + mechanisms. This algorithm does not consider the PIM mode and the + mechanism through which a Group-to-RP mapping was learned. + + This document defines a standard algorithm to deterministically + choose between several Group-to-RP mappings for a specific group. + This document first explains the requirements to extend the Group-to- + RP mapping algorithm and then proposes the new algorithm. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6226. + + + + + + + + + + + + + +Joshi, et al. Standards Track [Page 1] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Existing Algorithm ..............................................4 + 4. Assumptions .....................................................5 + 5. Common Use Cases ................................................5 + 6. Proposed Algorithm ..............................................6 + 7. Interpretation of MIB Objects ...................................8 + 8. Clarification for MIB Objects ...................................8 + 9. Use of Dynamic Group-to-RP Mapping Protocols ....................9 + 10. Considerations for Bidirectional-PIM and BSR Hash ..............9 + 11. Filtering Group-to-RP Mappings at Domain Boundaries ............9 + 12. Security Considerations .......................................10 + 13. Acknowledgements ..............................................10 + 14. Normative References ..........................................10 + +1. Introduction + + Multiple mechanisms exist today to create and distribute Group-to-RP + mappings. Each PIM-SM router may learn Group-to-RP mappings through + various mechanisms, as described in Section 4. + + It is critical that each router select the same 'RP' for a specific + multicast group address; otherwise, full multicast connectivity will + not be established. This is true even when using an Anycast RP to + provide redundancy. This RP address may correspond to a different + physical router, but it is one logical RP address and must be + consistent across the PIM domain. This is usually achieved by using + the same algorithm to select the RP in all the PIM routers in a + domain. + + + + + +Joshi, et al. Standards Track [Page 2] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + + PIM-SM [RFC4601] has defined an algorithm to select a 'RP' for a + given multicast group address, but it is not flexible enough for an + administrator to apply various policies. Please refer to Section 3 + for more details. + + The PIM-STD-MIB [RFC5060] includes a number of objects to allow an + administrator to set the precedence for Group-to-RP mappings that are + learned statically or dynamically and stored in the + 'pimGroupMappingTable'. The Management Information Base (MIB) module + also defines an algorithm that can be applied to the data contained + in the 'pimGroupMappingTable' to determine Group-to-RP mappings. + However, this algorithm is not completely deterministic, because it + includes an implementation-specific 'precedence' value. + + Network management stations will be able to deduce which RPs will be + selected by applying the algorithm from this document to the list of + Group-to-RP mappings from the 'pimGroupMappingTable'. The algorithm + provides MIB visibility into how routers will apply Group-to-RP + mappings and also fixes the inconsistency introduced by the way that + different vendors implement the selection of the Group-to-RP mappings + to create multicast forwarding state. + + Embedded-RP, as defined in Section 7.1 of "Embedding the Rendezvous + Point (RP) Address in an IPv6 Multicast Address" [RFC3956], specifies + the following: "To avoid loops and inconsistencies, for addresses in + the range ff70::/12, the Embedded-RP mapping MUST be considered the + longest possible match and higher priority than any other mechanism". + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + This document also uses the following terms: + + o PIM Mode + + PIM Mode is the mode of operation for which a particular multicast + group is used. Wherever this term is used in this document, it + refers to either Sparse Mode or Bidirectional (BIDIR) Mode. + + o Dynamic Group-to-RP Mapping Mechanisms + + The term "dynamic Group-to-RP mapping mechanisms" in this document + refers to Bootstrap Router (BSR) [RFC5059] and Auto-RP. + + + + + +Joshi, et al. Standards Track [Page 3] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + + o Dynamic Mappings and Dynamically Learned Mappings + + The terms "dynamic mappings" and "dynamically learned mappings" + refer to Group-to-RP mappings that have been learned by either BSR + or Auto-RP. Group-to-RP mappings that have been learned by + Embedded-RP are referred to as Embedded Group-to-RP mappings. + + o Filtering + + Filtering is the selective discarding of dynamic Group-to-RP + mapping information, based on the group address, the type of + Group-to-RP mapping message, and the interface on which the + mapping message was received. + + o Multicast Domain and Boundaries + + The term "multicast domain" used in this document refers to a + network topology that has a consistent set of Group-to-RP + mappings. The interface between two or more multicast domains is + a multicast domain boundary. The multicast boundaries are usually + enforced by filtering the dynamic mapping messages and/or + configuring different static RP mappings. + +3. Existing Algorithm + + The existing algorithm defined in PIM-SM (Section 4.7.1 of [RFC4601]) + does not consider the following constraints: + + o It does not consider the origin of a Group-to-RP mapping and + therefore will treat all of them equally. + + o It does not provide the flexibility to give higher priority to a + specific PIM mode. For example, an entry learned for the PIM- + BIDIR Mode is treated with the same priority as an entry learned + for PIM-SM. + + The algorithm defined in this document updates the algorithm defined + in PIM-SM (Section 4.7.1 of [RFC4601]). The new algorithm is + backward compatible and will produce the same result only if the + Group-to-RP mappings are learned from a single mapping source. The + full benefits of the new algorithm will not be realized until it is + widely deployed. + + + + + + + + + +Joshi, et al. Standards Track [Page 4] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + +4. Assumptions + + We have made the following assumptions in defining this algorithm: + + o A Group-to-RP mapping can be learned from various mechanisms. We + assume that the following list is ordered by decreasing preference + for these mechanisms: + + * Embedded Group-to-RP mappings + + * Dynamically learned mappings + + * Static configuration + + * Other mapping method + + o Embedded Group-to-RP mappings are special and always have the + highest priority. They cannot be overridden by static + configuration or by dynamic Group-to-RP mappings. + + o Dynamic mappings will override a static RP configuration if they + have overlapping ranges. However, it is possible to override + dynamic Group-to-RP mappings with static configurations, either by + filtering, or by configuring longer static group addresses that + override dynamic mappings when longest prefix matching is applied. + + o A Group-to-RP mapping learned for PIM-BIDIR Mode is preferred to + an entry learned for PIM-SM Mode as stipulated in Section 3.3 of + [RFC5059]. + + o Dynamic Group-to-RP mapping mechanisms are filtered at domain + boundaries or for policy enforcement inside a domain. + +5. Common Use Cases + + A network operator deploying IP Multicast will require a + deterministic way to select the precedence for Group-to-RP mappings + in the following use cases: + + o Default static Group-to-RP mappings with dynamically learned + entries + + Many network operators will have a dedicated infrastructure for + the standard multicast group range (224/4) and so might be using + statically configured Group-to-RP mappings for this range. In + this case, to support some specific applications, they might want + to learn Group-to-RP mappings dynamically using either the BSR or + Auto-RP mechanism. In this case, to select Group-to-RP mappings + + + +Joshi, et al. Standards Track [Page 5] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + + for these specific applications, a longer prefix match should be + given preference over statically configured Group-to-RP mappings. + For example, 239.100.0.0/16, an administratively scoped multicast + address range, could be learned for a corporate communications + application. Network operators may change the Group-to-RP + mappings for these applications more often, and the mappings would + need to be learned dynamically. This is not an issue for IPv6 + Multicast address ranges. + + o Migration situations + + Network operators occasionally go through a migration due to an + acquisition or a change in their network design. In order to + facilitate this migration, there is a need to have a deterministic + behavior of Group-to-RP mapping selection for entries learned + using the BSR and Auto-RP mechanisms. This will help in avoiding + any unforeseen interoperability issues between different vendors' + network elements. + + o Use by management systems + + A network management station can determine the RP for a specific + group in a specific router by running this algorithm on the Group- + to-RP mapping table fetched using MIB objects. + +6. Proposed Algorithm + + The following algorithm deterministically chooses between several + Group-to-RP mappings for a specific group. It also addresses the + above-mentioned shortcomings in the existing mechanism. + + 1. If the multicast group address being looked up contains an + embedded RP, the RP address extracted from the group address is + selected as the Group-to-RP mapping. + + 2. If the multicast group address being looked up is in the Source + Specific Multicast (SSM) range or is configured for Dense Mode, + no Group-to-RP mapping is selected, and this algorithm + terminates. The fact that no Group-to-RP mapping has been + selected can be represented in the PIM-STD-MIB module [RFC5060] + by setting the address type of the RP to 'unknown', as described + in Section 8. + + 3. From the set of all Group-to-RP mapping entries, the subset + whose group prefix contains the multicast group that is being + looked up is selected. + + + + + +Joshi, et al. Standards Track [Page 6] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + + 4. If there are no entries available, then the Group-to-RP mapping + is undefined, and this algorithm terminates. + + 5. A longest prefix match is performed on the subset of Group-to-RP + mappings. + + * If there is only one entry available, then that entry is + selected as the Group-to-RP mapping. + + * If there are multiple entries available, the algorithm + continues with this smaller set of Group-to-RP mappings. + + 6. From the remaining set of Group-to-RP mappings, we select the + subset of entries based on the preference for the PIM modes to + which the multicast group addresses are assigned. A Group-to-RP + mapping entry with PIM Mode 'BIDIR' will be preferred to an + entry with PIM Mode 'PIM-SM'. + + * If there is only one entry available, then that entry is + selected as the Group-to-RP mapping. + + * If there are multiple entries available, the algorithm + continues with this smaller set of Group-to-RP mappings. + + 7. From the remaining set of Group-to-RP mappings, we select the + subset of the entries based on the origin. Group-to-RP mappings + learned dynamically are preferred over static mappings. If the + remaining dynamic Group-to-RP mappings are from BSR and Auto-RP, + then the mappings from BSR are preferred. + + * If there is only one entry available, then that entry is + selected as the Group-to-RP mapping. + + * If there are multiple entries available, the algorithm + continues with this smaller set of Group-to-RP mappings. + + 8. If the remaining Group-to-RP mappings were learned through BSR, + then the RP will be selected by comparing the RP Priority values + in the Candidate-RP-Advertisement messages. The RP mapping with + the lowest value indicates the highest priority [RFC5059]. + + * If more than one RP has the same highest priority (i.e., the + same lowest value), the algorithm continues with those Group- + to-RP mappings. + + * If the remaining Group-to-RP mappings were NOT learned from + BSR, the algorithm continues with the next step. + + + + +Joshi, et al. Standards Track [Page 7] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + + 9. If the remaining Group-to-RP mappings were learned through BSR + and the PIM Mode of the group is 'PIM-SM', then the hash + function as defined in Section 4.7.2 of [RFC4601] will be used + to choose the RP. The RP with the highest resulting hash value + will be selected. Please see Section 10 for consideration of + hash for BIDIR-PIM and BSR. + + * If more than one RP has the same highest hash value, the + algorithm continues with those Group-to-RP mappings. + + * If the remaining Group-to-RP mappings were NOT learned from + BSR, the algorithm continues with the next step. + + 10. From the remaining set of Group-to-RP mappings, the RP with the + highest IP address (numerically greater) will be selected. This + will serve as a final tiebreaker. + +7. Interpretation of MIB Objects + + As described in [RFC5060], the Group-to-RP mapping information is + summarized in the pimGroupMappingTable. The precedence value is + stored in the 'pimGroupMappingPrecedence' object, which covers both + the dynamically learned Group-to-RP mapping information and the + static configuration. For static configurations, the + 'pimGroupMappingPrecedence' object uses the value of the + 'pimStaticRPPrecedence' object from the pimStaticRPTable. + + The algorithm defined in this document does not use the concept of + precedence, and therefore the values configured in the + 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects in + the PIM-STD-MIB module [RFC5060] are not applicable to the new + algorithm. The objects still retain their meaning for 'legacy' + implementations, but since the algorithm defined in this document is + to be used in preference to those found in PIM-SM [RFC4601] and the + PIM-STD-MIB [RFC5060], the values of these objects will be ignored on + implementations that support the new algorithm. + +8. Clarification for MIB Objects + + An implementation of this specification can continue to be managed + using the PIM-STD-MIB [RFC5060]. Group-to-RP mapping entries are + created in the pimGroupMappingTable for group ranges that are SSM or + Dense mode. In these cases, the pimGroupMappingRPAddressType object + is set to unknown(0), and the PIM Mode in the pimGroupMappingPimMode + object is set to either ssm(2) or dm(5) to reflect the type of the + group range. + + + + + +Joshi, et al. Standards Track [Page 8] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + + Also, all the entries that are already included in the SSM Range + table in the IP Multicast MIB [RFC5132] are copied to the + pimGroupMappingTable. Such entries have their type in the + pimGroupMappingOrigin object set to configSsm(3) and the RP address + type in the pimGroupMappingRPAddressType object set to unknown(0), as + described above. + +9. Use of Dynamic Group-to-RP Mapping Protocols + + It is not usually necessary to run several dynamic Group-to-RP + mapping mechanisms in one administrative domain. Specifically, + interoperation of BSR and Auto-RP is OPTIONAL. + + However, if a router does receive two overlapping sets of Group-to-RP + mappings, for example from Auto-RP and BSR, then some algorithm is + needed to deterministically resolve the situation. The algorithm in + this document MUST be used on all routers in the domain. This can be + important at domain border routers, and is likely to avoid conflicts + caused by misconfiguration (when routers receive overlapping sets of + Group-to-RP mappings) and when configuration is changing. + + An implementation of PIM that supports only one mechanism for + learning Group-to-RP mappings MUST also use this algorithm. The + algorithm has been chosen so that existing standard implementations + are already compliant. + +10. Considerations for Bidirectional-PIM and BSR Hash + + BIDIR-PIM [RFC5015] is designed to avoid any data-driven events. + This is especially true in the case of a source-only branch. The RP + mapping is determined based on a group mask when the mapping is + received through a dynamic mapping protocol or statically configured. + + Therefore, based on the algorithm defined in this document, the hash + in BSR is ignored for PIM-BIDIR RP mappings. It is RECOMMENDED that + network operators configure only one PIM-BIDIR RP for each RP + Priority. + +11. Filtering Group-to-RP Mappings at Domain Boundaries + + An implementation of PIM SHOULD support configuration to filter + specific dynamic mechanisms for a valid group prefix range. For + example, it should be possible to allow an administratively scoped + address range, such as 239/8, for the Auto-RP protocol, but to filter + out the BSR advertisement for the same range. Similarly, it should + be possible to filter out all Group-to-RP mappings learned from BSR + or the Auto-RP protocol. + + + + +Joshi, et al. Standards Track [Page 9] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + +12. Security Considerations + + This document enhances an existing algorithm to deterministically + choose between several Group-to-RP mappings for a specific group. + Different routers may select a different Group-to-RP mapping for the + same group if the Group-to-RP mappings learned in these routers are + not consistent. For example, let us assume that BSR is not enabled + in one of the routers, and so it does not learn any Group-to-RP + mappings from BSR. Now the Group-to-RP mappings learned in this + router may not be consistent with other routers in the network; it + may select a different RP or may not select any RP for a given group. + Such situations can be avoided if the mechanisms used to learn Group- + to-RP mappings are secure and consistent across the network. Secure + transport of the mapping protocols can be accomplished by using + authentication with IPsec, as described in Section 6.3 of [RFC4601]. + +13. Acknowledgements + + This document is created based on discussion that occurred during + work on the PIM-STD-MIB [RFC5060]. Many thanks to Stig Venaas, Yiqun + Cai, and Toerless Eckert for providing useful comments. + +14. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous + Point (RP) Address in an IPv6 Multicast Address", + RFC 3956, November 2004. + + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): + Protocol Specification (Revised)", RFC 4601, August 2006. + + [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, + "Bidirectional Protocol Independent Multicast (BIDIR- + PIM)", RFC 5015, October 2007. + + [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, + "Bootstrap Router (BSR) Mechanism for Protocol Independent + Multicast (PIM)", RFC 5059, January 2008. + + [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. + Kessler, "Protocol Independent Multicast MIB", RFC 5060, + January 2008. + + + + + +Joshi, et al. Standards Track [Page 10] + +RFC 6226 PIM Group-to-RP Mapping May 2011 + + + [RFC5132] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast + MIB", RFC 5132, December 2007. + +Authors' Addresses + + Bharat Joshi + Infosys Technologies Ltd. + 44 Electronics City, Hosur Road + Bangalore 560 100 + India + + EMail: bharat_joshi@infosys.com + URI: http://www.infosys.com/ + + + Andy Kessler + Cisco Systems, Inc. + 425 E. Tasman Drive + San Jose, CA 95134 + USA + + EMail: kessler@cisco.com + URI: http://www.cisco.com/ + + + David McWalter + + EMail: david@mcwalter.eu + + + + + + + + + + + + + + + + + + + + + + + +Joshi, et al. Standards Track [Page 11] + |