idnits 2.17.1 draft-ietf-pim-group-rp-mapping-10.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 28, 2011) is 4799 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: August 1, 2011 D. McWalter 7 January 28, 2011 9 PIM Group-to-RP Mapping 10 draft-ietf-pim-group-rp-mapping-10.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 August 1, 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 Network Management stations will be able to deduce which RPs will be 107 selected by applying the algorithm from this document to the list of 108 Group-to-RP mappings from the 'pimGroupMappingTable'. The algorithm 109 provides MIB visibility into how routers will apply Group-to-RP 110 mappings and also fixes the protocol inconsistency with how different 111 vendors select the Group-to-RP mappings to create multicast 112 forwarding state. 114 Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6 115 Multicast address [RFC3956], mentions that to avoid loops and 116 inconsistencies, for addresses in the range FF70::/12, the 117 Embedded-RP mapping must be considered the longest possible match and 118 higher priority than any other mechanism. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 This document also uses following terms: 127 o PIM Mode 129 PIM Mode is the mode of operation a particular multicast group is 130 used for. Wherever this term is used in this document, it refers to 131 either Sparse Mode or Bidirectional (BIDIR) Mode. 133 o Dynamic group-to-RP mapping mechanisms 135 The term Dynamic group-to-RP mapping mechanisms in this document 136 refers to Bootstrap Router (BSR) [RFC5059] and Auto-RP. 138 o Dynamic mappings or Dynamically learned mappings 140 The terms Dynamic mappings or Dynamically learned mappings refer to 141 group-to-RP mappings that have been learned by BSR or Auto-RP. 142 Group-to-RP mappings that have been learned by embedded RP are 143 referred to as Embedded Group-to-RP mappings. 145 o Filtering 147 Filtering is selective discarding of dynamic Group-to-RP mapping 148 information, based on the group address, the type of Group-to-RP 149 mapping message and the interface on which the mapping message was 150 received. 152 o Multicast Domain and Boundaries 154 The term multicast domain used in this document refers to a network 155 topology that has a consistent set of Group-to-RP Mappings. The 156 interface between two or more multicast domains is a multicast domain 157 boundary. The multicast boundaries are usually enforced by filtering 158 the dynamic mapping messages and/or configuring different static RP 159 mappings. 161 3. Existing algorithm 163 The existing algorithm defined in PIM-SM (Section 4.7.1 in [RFC4601]) 164 does not consider following constraints: 166 o It does not consider the origin of a Group-to-RP mapping and 167 therefore will treat all of them equally. 169 o It does not provide the flexibility to give higher priority to a 170 specific PIM mode. For example, an entry learned for PIM-BIDIR 171 mode is treated with same priority as an entry learned for PIM-SM. 173 The algorithm defined in this document updates algorithm defined in 174 PIM-SM ( Section 4.7.1 in [RFC4601]). The new algorithm is backward 175 compatible and will produce the same result only if the Group-to-RP 176 mappings are learned from a single mapping source. The full benefits 177 of the new algorithm will not be realized until it is widely 178 deployed. 180 4. Assumptions 182 We have made following assumptions in defining this algorithm: 184 o A Group-to-RP mapping can be learned from various mechanisms. We 185 assume that following list is in the decreasing preferences of 186 these mechanism: 188 * Embedded Group-to-RP mappings 190 * Dynamically learned mappings 192 * Static configuration. 194 * Other mapping method 196 o Embedded Group-to-RP mappings are special and always have the 197 highest priority. They cannot be overridden either by static 198 configuration or by dynamic Group-to-RP mappings. 200 o Dynamic mappings will override a static RP config if they have 201 overlapping ranges. However, it is possible to override dynamic 202 Group-to-RP mappings with static configurations, either by 203 filtering, or by configuring longer static group addresses that 204 override dynamic mappings when longest prefix matching is applied. 206 o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to 207 an entry learned for PIM-SM mode as stipulated by section 3.3 of 208 [RFC5059]. 210 o Dynamic group-to-RP mapping mechanisms are filtered at domain 211 boundaries or for policy enforcement inside a domain. 213 5. Common use cases 215 o Default static Group-to-RP mappings with dynamically learned 216 entries 218 Many network operators will have a dedicated infrastructure for the 219 standard multicast group range (224/4) and so might be using 220 statically configured Group-to-RP mappings for this range. In this 221 case, to support some specific applications, they might like to learn 222 Group-to-RP mappings dynamically using either BSR or Auto-RP 223 mechanism. In this case to select Group-to-RP mappings for these 224 specific applications, a longer prefix match should be given 225 preference over statically configured Group-to-RP mappings. For 226 example 239.100.0.0/16, an administratively scoped multicast address 227 range, could be learned for a corporate communications application. 228 Network operators may change the Group-to-RP mappings for these 229 applications more often and would need to be learned dynamically. 230 This is not an issue for IPv6 Multicast address ranges. 232 o Migration situations 234 Network operators occasionally go through a migration due to an 235 acquisition or a change in their network design. In order to 236 facilitate this migration there is a need to have a deterministic 237 behaviour of Group-to-RP mapping selection for entries learned using 238 BSR and Auto-RP mechanism. This will help in avoiding any unforeseen 239 interoperability issues between different vendor's network elements. 241 o Use by management systems 243 A network management station can determine the RP for a specific 244 group in a specific router by running this algorithm on the 245 Group-to-RP mapping table fetched using MIB objects. 247 6. Proposed algorithm 249 The following algorithm deterministically chooses between several 250 Group-to-RP mappings for a specific group. It also addresses the 251 above mentioned shortcomings in the existing mechanism. 253 1. If the Multicast Group Address being looked up contains an 254 embedded RP, the RP address extracted from the Group address is 255 selected as the Group-to-RP mapping. 257 2. If the Multicast Group Address being looked up is in the Source 258 Specific Multicast (SSM) range or is configured for Dense mode, 259 no Group-to-RP mapping is selected, and this algorithm 260 terminates. The fact that no Group-to-RP mapping has been 261 selected can be represented in the PIM-STD-MIB module by setting 262 the address type of the RP to 'unknown' as described in Section 263 8. 265 3. From the set of all Group-to-RP mapping entries, the subset 266 whose group prefix contains the multicast group that is being 267 looked up, is selected. 269 4. If there are no entries available, then the Group-to-RP mapping 270 is undefined and this algorithm terminates. 272 5. A longest prefix match is performed on the subset of Group-to-RP 273 Mappings. 275 * If there is only one entry available then that entry is 276 selected as the Group-to-RP mapping. 278 * If there are multiple entries available, we continue with the 279 algorithm with this smaller set of Group-to-RP Mappings. 281 6. From the remaining set of Group-to-RP Mappings we select the 282 subset of entries based on the preference for the PIM modes 283 which they are assigned. A Group-to-RP mapping entry with PIM 284 Mode 'BIDIR' will be preferred to an entry with PIM Mode 285 'PIM-SM' 287 * If there is only one entry available then that entry is 288 selected as the Group-to-RP mapping. 290 * If there are multiple entries available, we continue with the 291 algorithm with this smaller set of Group-to-RP Mappings 293 7. From the remaining set of Group-to-RP Mappings we select the 294 subset of the entries based on the origin. Group-to-RP mappings 295 learned dynamically are preferred over static mappings. If the 296 remaining dynamic Group-to-RP mappings are from BSR and Auto-RP 297 then the mappings from BSR is preferred. 299 * If there is only one entry available then that entry is 300 selected as the Group-to-RP mapping. 302 * If there are multiple entries available, we continue with the 303 algorithm with this smaller set of Group-to-RP Mappings. 305 8. If the remaining Group-to-RP mappings were learned through BSR 306 then the RP will be selected by comparing the RP Priority in the 307 Candidate-RP-Advertisement messages. The RP mapping with the 308 lowest value indicates the highest priority [RFC5059]. 310 * If more than one RP has the same highest priority value we 311 continue with the algorithm with those Group-to-RP mappings. 313 * If the remaining Group-to-RP mappings were NOT learned from 314 BSR we continue the algorithm with the next step. 316 9. If the remaining Group-to-RP mappings were learned through BSR 317 and the PIM Mode of the Group is 'PIM-SM' then the hash function 318 as defined in section 4.7.2 of [RFC4601] will be used to choose 319 the RP. The RP with the highest resulting hash value will be 320 selected. Please look at section 10 for consideration of hash 321 for BIDIR-PIM and BSR. 323 * If more than one RP has the same highest hash value we 324 continue with the algorithm with those Group-to-RP mappings. 326 * If the remaining Group-to-RP mappings were NOT learned from 327 BSR we continue the algorithm with the next step. 329 10. From the remaining set of Group-to-RP Mappings we will select 330 the RP with the highest IP address (numerically greater). This 331 will serve as a final tiebreaker. 333 7. Interpretation of MIB Objects 335 As described in [RFC5060] the Group-to-RP mapping information is 336 summarized in the pimGroupMappingTable. The precedence value is 337 stored in the 'pimGroupMappingPrecedence' object which covers both 338 the dynamically learned Group-to-RP mapping information as well as 339 the static configuration. For static configurations, the 340 'pimGroupMappingPrecedence' object uses the value of the 341 'pimStaticRPPrecedence' object from the pimStaticRPTable table. 343 The algorithm defined in this document does not use the concept of 344 precedence and therefore the values configured in the 345 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects in 346 the PIM-STD-MIB module [RFC5060] are not applicable to the new 347 algorithm. The objects still retain their meaning for 'legacy' 348 implementations, but since the algorithm defined in this document is 349 to be used in preference to that found in PIM-SM [RFC4601] and PIM- 350 STD-MIB [RFC5060], the values of these objects will be ignored on 351 implementations that support the new algorithm. 353 8. Clarification for MIB Objects 355 An implementation of this specification can continue to be managed 356 using the PIM-STD-MIB [RFC5060]. When a Group-to-RP mapping entry is 357 created in the pimGroupMappingTable with RP address type in the 358 pimGroupMappingRPAddressType object is set to unknown(0), and the PIM 359 Mode in the pimGroupMappingPimMode object is set to either ssm(2) or 360 dm(5) to represent group ranges for SSM or Dense mode. 362 Also, all the entries which are already included in the SSM Range 363 table in the IP Mcast MIB [RFC5132] are copied to the 364 pimGroupMappingTable. Such entries have their type in the 365 pimGroupMappingOrigin object set to configSsm(3), and the RP address 366 type in the pimGroupMappingRPAddressType object set to unknown(0) as 367 described above. 369 9. Use of dynamic Group-to-RP mapping protocols 371 It is not usually necessary to run several dynamic Group-to-RP 372 mapping mechanisms in one administrative domain. Specifically, 373 interoperation of BSR and Auto-RP is OPTIONAL. 375 However, if a router does receive two overlapping sets of Group-to-RP 376 mappings, for example from Auto-RP and BSR, then some algorithm is 377 needed to deterministically resolve the situation. The algorithm in 378 this document MUST be used on all routers in the domain. This can be 379 important at domain border routers, and is likely to avoid conflicts 380 under misconfiguration (when routers receive overlapping sets of 381 Group-to-RP mappings) and when configuration is changing. 383 An implementation of PIM that supports only one mechanism for 384 learning Group-to-RP mappings MUST also use this algorithm. The 385 algorithm has been chosen so that existing standard implementations 386 are already compliant. 388 10. Consideration for Bidirectional-PIM and BSR hash 390 BIDIR-PIM [RFC5015] is designed to avoid any data driven events. 391 This is especially true in the case of a source only branch. The RP 392 mapping is determined based on a group mask when the mapping is 393 received through a dynamic mapping protocol or statically configured. 395 Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based 396 on the algorithm defined in this document. It is RECOMMENDED that 397 network operators configure only one PIM-Bidir RP for each RP 398 Priority. 400 11. Filtering Group-to-RP mappings at domain boundaries 402 An implementation of PIM SHOULD support configuration to filter 403 specific dynamic mechanism for a valid group prefix range. For 404 example, it should be possible to allow an administratively scoped 405 address range, such as 239/8 range, for Auto-RP protocol but filter 406 out the BSR advertisement for the same range. Similarly it should be 407 possible to filter out all Group-to-RP mappings learned from BSR or 408 Auto-RP protocol. 410 12. Security Consideration 412 This document enhances an existing algorithm to deterministically 413 choose between several Group-to-RP Mappings for a specific group. 414 Different routers may select a different Group-to-RP Mapping for the 415 same group if the Group-to-RP Mappings learned in these routers are 416 not consistent. For example: let us assume that BSR is not enabled 417 in one of the routers and so it does not learn any Group-to-RP 418 Mappings from BSR. Now the Group-to-RP Mappings learned in this 419 router may not be consistent with other routers in the network, it 420 may select a different RP or may not select any RP for a given group. 421 Such situations can be avoided if the mechanisms used to learn Group- 422 to-RP Mappings are secure and consistent across the network. Secure 423 transport of the mapping protocols can be accomplished by using 424 authentication with IPsec as described in section 6.3 of [RFC4601]. 426 13. IANA Consideration 428 This draft does not create any namespace for IANA to manage. 430 14. Acknowledgements 432 This draft is created based on the discussion occurred during the 433 PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas, Yiqun Cai 434 and Toerless Eckert for providing useful comments. 436 15. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 442 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 443 Protocol Specification (Revised)", RFC 4601, August 2006. 445 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 446 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 447 January 2008. 449 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 450 Point (RP) Address in an IPv6 Multicast Address", 451 RFC 3956, November 2004. 453 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 454 "Bidirectional Protocol Independent Multicast (BIDIR- 455 PIM)", RFC 5015, October 2007. 457 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 458 "Bootstrap Router (BSR) Mechanism for Protocol Independent 459 Multicast (PIM)", RFC 5059, January 2008. 461 [RFC5132] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast 462 MIB", RFC 5132, December 2007. 464 Authors' Addresses 466 Bharat Joshi 467 Infosys Technologies Ltd. 468 44 Electronics City, Hosur Road 469 Bangalore 560 100 470 India 472 Email: bharat_joshi@infosys.com 473 URI: http://www.infosys.com/ 475 Andy Kessler 476 Cisco Systems, Inc. 477 425 E. Tasman Drive 478 San Jose, CA 95134 479 USA 481 Email: kessler@cisco.com 482 URI: http://www.cisco.com/ 484 David McWalter 486 Email: david@mcwalter.eu