idnits 2.17.1 draft-ietf-pim-group-rp-mapping-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document updates RFC4601, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4601, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 12, 2011) is 4851 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group B. Joshi 3 Internet-Draft Infosys Technologies Ltd. 4 Updates: 4601 (if approved) A. Kessler 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: July 16, 2011 D. McWalter 7 January 12, 2011 9 PIM Group-to-RP Mapping 10 draft-ietf-pim-group-rp-mapping-09.txt 12 Abstract 14 Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain 15 which supports Any Source Multicast (ASM) maintains Group-to-RP 16 mappings which are used to identify a Rendezvous Point(RP) for a 17 specific multicast group. PIM-SM has defined an algorithm to choose 18 a RP from the Group-to-RP mappings learned using various mechanisms. 19 This algorithm does not consider the PIM mode and the mechanism 20 through which a Group-to-RP mapping was learned. 22 This document defines a standard algorithm to deterministically 23 choose between several Group-to-RP mappings for a specific group. 24 This document first explains the requirements to extend the 25 Group-to-RP mapping algorithm and then proposes the new algorithm. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 16, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Common use cases . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Interpretation of MIB Objects . . . . . . . . . . . . . . . . 10 68 8. Clarification for MIB Objects . . . . . . . . . . . . . . . . 11 69 9. Use of dynamic Group-to-RP mapping protocols . . . . . . . . . 12 70 10. Consideration for Bidirectional-PIM and BSR hash . . . . . . . 13 71 11. Filtering Group-to-RP mappings at domain boundaries . . . . . 14 72 12. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 73 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 74 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 75 15. Normative References . . . . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 Multiple mechanisms exist today to create and distribute Group-to-RP 81 mappings. Each PIM-SM router may learn Group-to-RP mappings through 82 various mechanisms as described in section 4. 84 It is critical that each router select the same 'RP' for a specific 85 multicast group address otherwise full multicast connectivity will 86 not be established. This is even true in the case of Anycast RP for 87 redundancy. This RP address may correspond to a different physical 88 router but it is one logical RP address and must be consistent across 89 the PIM domain. This is usually achieved by using the same algorithm 90 to select the RP in all the PIM routers in a domain. 92 PIM-SM [RFC4601] has defined an algorithm to select a 'RP' for a 93 given multicast group address but it is not flexible enough for an 94 administrator to apply various policies. Please refer to section 3 95 for more details. 97 PIM-STD-MIB [RFC5060] includes a number of objects to allow an 98 administrator to set the precedence for Group-to-RP mappings which 99 are learned statically or dynamically and stored in the 100 'pimGroupMappingTable'. The Management Information Base (MIB) module 101 also defines an algorithm that can be applied to the data contained 102 in the 'pimGroupMappingTable' to determine Group-to-RP mappings. 103 However, this algorithm is not completely deterministic, because it 104 includes an implementation-specific 'precedence' value. 106 Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6 107 Multicast address [RFC3956], mentions that to avoid loops and 108 inconsistencies, for addresses in the range FF70::/12, the 109 Embedded-RP mapping must be considered the longest possible match and 110 higher priority than any other mechanism. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 This document also uses following terms: 119 o PIM Mode 121 PIM Mode is the mode of operation a particular multicast group is 122 used for. Wherever this term is used in this document, it refers to 123 either Sparse Mode or Bidirectional (BIDIR) Mode. 125 o Dynamic group-to-RP mapping mechanisms 127 The term Dynamic group-to-RP mapping mechanisms in this document 128 refers to Bootstrap Router (BSR) [RFC5059] and Auto-RP. 130 o Dynamic mappings or Dynamically learned mappings 132 The terms Dynamic mappings or Dynamically learned mappings refer to 133 group-to-RP mappings that have been learned by BSR or Auto-RP. 134 Group-to-RP mappings that have been learned by embedded RP are 135 referred to as Embedded Group-to-RP mappings. 137 o Filtering 139 Filtering is selective discarding of dynamic Group-to-RP mapping 140 information, based on the group address, the type of Group-to-RP 141 mapping message and the interface on which the mapping message was 142 received. 144 o Multicast Domain and Boundaries 146 The term multicast domain used in this document refers to a network 147 topology that has a consistent set of Group-to-RP Mappings. The 148 interface between two or more multicast domains is a multicast domain 149 boundary. The multicast boundaries are usually enforced by filtering 150 the dynamic mapping messages and/or configuring different static RP 151 mappings. 153 3. Existing algorithm 155 The existing algorithm defined in PIM-SM (Section 4.7.1 in [RFC4601]) 156 does not consider following constraints: 158 o It does not consider the origin of a Group-to-RP mapping and 159 therefore will treat all of them equally. 161 o It does not provide the flexibility to give higher priority to a 162 specific PIM mode. For example, an entry learned for PIM-BIDIR 163 mode is treated with same priority as an entry learned for PIM-SM. 165 The algorithm defined in this document updates algorithm defined in 166 PIM-SM ( Section 4.7.1 in [RFC4601]). The new algorithm is backward 167 compatible and will produce the same result only if the Group-to-RP 168 mappings are learned from a single mapping source. The full benefits 169 of the new algorithm will not be realized until it is widely 170 deployed. 172 4. Assumptions 174 We have made following assumptions in defining this algorithm: 176 o A Group-to-RP mapping can be learned from various mechanisms. We 177 assume that following list is in the decreasing preferences of 178 these mechanism: 180 * Embedded Group-to-RP mappings 182 * Dynamically learned mappings 184 * Static configuration. 186 * Other mapping method 188 o Embedded Group-to-RP mappings are special and always have the 189 highest priority. They cannot be overridden either by static 190 configuration or by dynamic Group-to-RP mappings. 192 o Dynamic mappings will override a static RP config if they have 193 overlapping ranges. However, it is possible to override dynamic 194 Group-to-RP mappings with static configurations, either by 195 filtering, or by configuring longer static group addresses that 196 override dynamic mappings when longest prefix matching is applied. 198 o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to 199 an entry learned for PIM-SM mode as stipulated by section 3.3 of 200 [RFC5059]. 202 o Dynamic group-to-RP mapping mechanisms are filtered at domain 203 boundaries or for policy enforcement inside a domain. 205 5. Common use cases 207 o Default static Group-to-RP mappings with dynamically learned 208 entries 210 Many network operators will have a dedicated infrastructure for the 211 standard multicast group range (224/4) and so might be using 212 statically configured Group-to-RP mappings for this range. In this 213 case, to support some specific applications, they might like to learn 214 Group-to-RP mappings dynamically using either BSR or Auto-RP 215 mechanism. In this case to select Group-to-RP mappings for these 216 specific applications, a longer prefix match should be given 217 preference over statically configured Group-to-RP mappings. For 218 example 239.100.0.0/16, an administratively scoped multicast address 219 range, could be learned for a corporate communications application. 220 Network operators may change the Group-to-RP mappings for these 221 applications more often and would need to be learned dynamically. 222 This is not an issue for IPv6 Multicast address ranges. 224 o Migration situations 226 Network operators occasionally go through a migration due to an 227 acquisition or a change in their network design. In order to 228 facilitate this migration there is a need to have a deterministic 229 behaviour of Group-to-RP mapping selection for entries learned using 230 BSR and Auto-RP mechanism. This will help in avoiding any unforeseen 231 interoperability issues between different vendor's network elements. 233 o Use by management systems 235 A network management station can determine the RP for a specific 236 group in a specific router by running this algorithm on the 237 Group-to-RP mapping table fetched using MIB objects. 239 6. Proposed algorithm 241 The following algorithm deterministically chooses between several 242 Group-to-RP mappings for a specific group. It also addresses the 243 above mentioned shortcomings in the existing mechanism. 245 1. If the Multicast Group Address being looked up contains an 246 embedded RP, the RP address extracted from the Group address is 247 selected as the Group-to-RP mapping. 249 2. If the Multicast Group Address being looked up is in the Source 250 Specific Multicast (SSM) range or is configured for Dense mode, 251 no Group-to-RP mapping is selected, and this algorithm 252 terminates. The fact that no Group-to-RP mapping has been 253 selected can be represented in the PIM-STD-MIB module by setting 254 the address type of the RP to 'unknown' as described in Section 255 8. 257 3. From the set of all Group-to-RP mapping entries, the subset 258 whose group prefix contains the multicast group that is being 259 looked up, is selected. 261 4. If there are no entries available, then the Group-to-RP mapping 262 is undefined and this algorithm terminates. 264 5. A longest prefix match is performed on the subset of Group-to-RP 265 Mappings. 267 * If there is only one entry available then that entry is 268 selected as the Group-to-RP mapping. 270 * If there are multiple entries available, we continue with the 271 algorithm with this smaller set of Group-to-RP Mappings. 273 6. From the remaining set of Group-to-RP Mappings we select the 274 subset of entries based on the preference for the PIM modes 275 which they are assigned. A Group-to-RP mapping entry with PIM 276 Mode 'BIDIR' will be preferred to an entry with PIM Mode 277 'PIM-SM' 279 * If there is only one entry available then that entry is 280 selected as the Group-to-RP mapping. 282 * If there are multiple entries available, we continue with the 283 algorithm with this smaller set of Group-to-RP Mappings 285 7. From the remaining set of Group-to-RP Mappings we select the 286 subset of the entries based on the origin. Group-to-RP mappings 287 learned dynamically are preferred over static mappings. If the 288 remaining dynamic Group-to-RP mappings are from BSR and Auto-RP 289 then the mappings from BSR is preferred. 291 * If there is only one entry available then that entry is 292 selected as the Group-to-RP mapping. 294 * If there are multiple entries available, we continue with the 295 algorithm with this smaller set of Group-to-RP Mappings. 297 8. If the remaining Group-to-RP mappings were learned through BSR 298 then the RP will be selected by comparing the RP Priority in the 299 Candidate-RP-Advertisement messages. The RP mapping with the 300 lowest value indicates the highest priority [RFC5059]. 302 * If more than one RP has the same highest priority value we 303 continue with the algorithm with those Group-to-RP mappings. 305 * If the remaining Group-to-RP mappings were NOT learned from 306 BSR we continue the algorithm with the next step. 308 9. If the remaining Group-to-RP mappings were learned through BSR 309 and the PIM Mode of the Group is 'PIM-SM' then the hash function 310 as defined in section 4.7.2 of [RFC4601] will be used to choose 311 the RP. The RP with the highest resulting hash value will be 312 selected. Please look at section 10 for consideration of hash 313 for BIDIR-PIM and BSR. 315 * If more than one RP has the same highest hash value we 316 continue with the algorithm with those Group-to-RP mappings. 318 * If the remaining Group-to-RP mappings were NOT learned from 319 BSR we continue the algorithm with the next step. 321 10. From the remaining set of Group-to-RP Mappings we will select 322 the RP with the highest IP address (numerically greater). This 323 will serve as a final tiebreaker. 325 7. Interpretation of MIB Objects 327 The algorithm defined in this document does not use the concept of 328 precedence and therefore the values configured in the 329 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects of 330 the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060] 331 are not applicable to the new algorithm. The objects still retain 332 their meaning for 'legacy' implementations, but since the algorithm 333 defined in this document is to be used in preference to that found in 334 PIM-SM [RFC4601] and PIM-STD-MIB [RFC5060], the usage of these fields 335 will decline as implementations are upgraded to support the new 336 algorithm. 338 8. Clarification for MIB Objects 340 An implementation of this specification can continue to be managed 341 using the PIM-STD-MIB [RFC5060]. When a Group-to-RP mapping entry is 342 created in the pimGroupMappingTable with RP address type in the 343 pimGroupMappingRPAddressType object is set to unknown(0), and the PIM 344 Mode in the pimGroupMappingPimMode object is set to either ssm(2) or 345 dm(5) to represent group ranges for SSM or Dense mode. 347 Also, all the entries which are already included in the SSM Range 348 table in the IP Mcast MIB [RFC5132] are copied to the 349 pimGroupMappingTable. Such entries have their type in the 350 pimGroupMappingOrigin object set to configSsm(3), and the RP address 351 type in the pimGroupMappingRPAddressType object set to unknown(0) as 352 described above. 354 9. Use of dynamic Group-to-RP mapping protocols 356 It is not usually necessary to run several dynamic Group-to-RP 357 mapping mechanisms in one administrative domain. Specifically, 358 interoperation of BSR and Auto-RP is OPTIONAL. 360 However, if a router does receive two overlapping sets of Group-to-RP 361 mappings, for example from Auto-RP and BSR, then some algorithm is 362 needed to deterministically resolve the situation. The algorithm in 363 this document MUST be used on all routers in the domain. This can be 364 important at domain border routers, and is likely to avoid conflicts 365 under misconfiguration (when routers receive overlapping sets of 366 Group-to-RP mappings) and when configuration is changing. 368 An implementation of PIM that supports only one mechanism for 369 learning Group-to-RP mappings MUST also use this algorithm. The 370 algorithm has been chosen so that existing standard implementations 371 are already compliant. 373 10. Consideration for Bidirectional-PIM and BSR hash 375 BIDIR-PIM [RFC5015] is designed to avoid any data driven events. 376 This is especially true in the case of a source only branch. The RP 377 mapping is determined based on a group mask when the mapping is 378 received through a dynamic mapping protocol or statically configured. 380 Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based 381 on the algorithm defined in this document. It is RECOMMENDED that 382 network operators configure only one PIM-Bidir RP for each RP 383 Priority. 385 11. Filtering Group-to-RP mappings at domain boundaries 387 An implementation of PIM SHOULD support configuration to filter 388 specific dynamic mechanism for a valid group prefix range. For 389 example, it should be possible to allow an administratively scoped 390 address range, such as 239/8 range, for Auto-RP protocol but filter 391 out the BSR advertisement for the same range. Similarly it should be 392 possible to filter out all Group-to-RP mappings learned from BSR or 393 Auto-RP protocol. 395 12. Security Consideration 397 This document enhances an existing algorithm to deterministically 398 choose between several Group-to-RP Mappings for a specific group. 399 Different routers may select a different Group-to-RP Mapping for the 400 same group if the Group-to-RP Mappings learned in these routers are 401 not consistent. For example: let us assume that BSR is not enabled 402 in one of the routers and so it does not learn any Group-to-RP 403 Mappings from BSR. Now the Group-to-RP Mappings learned in this 404 router may not be consistent with other routers in the network, it 405 may select a different RP or may not select any RP for a given group. 406 Such situations can be avoided if the mechanisms used to learn Group- 407 to-RP Mappings are secure and consistent across the network. Secure 408 transport of the mapping protocols can be accomplished by using 409 authentication with IPsec as described in section 6.3 of [RFC4601]. 411 13. IANA Consideration 413 This draft does not create any namespace for IANA to manage. 415 14. Acknowledgements 417 This draft is created based on the discussion occurred during the 418 PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas, Yiqun Cai 419 and Toerless Eckert for providing useful comments. 421 15. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 427 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 428 Protocol Specification (Revised)", RFC 4601, August 2006. 430 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 431 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 432 January 2008. 434 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 435 Point (RP) Address in an IPv6 Multicast Address", 436 RFC 3956, November 2004. 438 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 439 "Bidirectional Protocol Independent Multicast (BIDIR- 440 PIM)", RFC 5015, October 2007. 442 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 443 "Bootstrap Router (BSR) Mechanism for Protocol Independent 444 Multicast (PIM)", RFC 5059, January 2008. 446 [RFC5132] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast 447 MIB", RFC 5132, December 2007. 449 Authors' Addresses 451 Bharat Joshi 452 Infosys Technologies Ltd. 453 44 Electronics City, Hosur Road 454 Bangalore 560 100 455 India 457 Email: bharat_joshi@infosys.com 458 URI: http://www.infosys.com/ 460 Andy Kessler 461 Cisco Systems, Inc. 462 425 E. Tasman Drive 463 San Jose, CA 95134 464 USA 466 Email: kessler@cisco.com 467 URI: http://www.cisco.com/ 469 David McWalter 471 Email: david@mcwalter.eu