idnits 2.17.1 draft-ietf-pim-group-rp-mapping-08.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 (December 28, 2010) is 4866 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 1, 2011 D. McWalter 7 December 28, 2010 9 PIM Group-to-RP Mapping 10 draft-ietf-pim-group-rp-mapping-08.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 1, 2011. 44 Copyright Notice 46 Copyright (c) 2010 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. 84 It is critical that each router select the same 'RP' for a specific 85 multicast group address. This is even true in the case of Anycast RP 86 for redundancy. This RP address may correspond to a different 87 physical router but it is one logical RP address and must be 88 consistent across the PIM domain. This is usually achieved by using 89 the same algorithm to select the RP in all the PIM routers in a 90 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 MIB module also defines an algorithm 101 that can be applied to the data contained in the 102 'pimGroupMappingTable' to determine Group-to-RP mappings. However, 103 this algorithm is not completely deterministic, because it includes 104 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 in 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) 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. 201 o Dynamic group-to-RP mapping mechanisms are filtered at domain 202 boundaries or for policy enforcement inside a domain. 204 5. Common use cases 206 o Default static Group-to-RP mappings with dynamically learned 207 entries 209 Many network operators will have a dedicated infrastructure for the 210 standard multicast group range (224/4) and so might be using 211 statically configured Group-to-RP mappings for this range. In this 212 case, to support some specific applications, they might like to learn 213 Group-to-RP mappings dynamically using either BSR or Auto-RP 214 mechanism. In this case to select Group-to-RP mappings for these 215 specific applications, a longer prefix match should be given 216 preference over statically configured Group-to-RP mappings. For 217 example 239.100.0.0/16, an administratively scoped multicast address 218 range, could be learned for a corporate communications application. 219 Network operators may change the Group-to-RP mappings for these 220 applications more often and would need to be learned dynamically. 221 This is not an issue for IPv6 Multicast address ranges. 223 o Migration situations 225 Network operators occasionally go through a migration due to an 226 acquisition or a change in their network design. In order to 227 facilitate this migration there is a need to have a deterministic 228 behaviour of Group-to-RP mapping selection for entries learned using 229 BSR and Auto-RP mechanism. This will help in avoiding any unforeseen 230 interoperability issues between different vendor's network elements. 232 o Use by management systems 234 A network management station can determine the RP for a specific 235 group in a specific router by running this algorithm on the 236 Group-to-RP mapping table fetched using SNMP MIB objects. 238 6. Proposed algorithm 240 The following algorithm addresses the above mentioned shortcomings in 241 the existing mechanism: 243 1. If the Multicast Group Address being looked up contains an 244 embedded RP, RP address extracted from the Group address is 245 selected as Group-to-RP mapping. 247 2. If the Multicast Group Address being looked up is in the Source 248 Specific Multicast (SSM) range or is configured for Dense mode, 249 no Group-to-RP mapping is selected, and this algorithm 250 terminates. The fact that no Group-to-RP mapping has been 251 selected can be represented in the PIM-STD-MIB module by setting 252 the address type of the RP to 'unknown' as described in Section 253 8. 255 3. From the set of all Group-to-RP mapping entries, the subset 256 whose group prefix contains the multicast group that is being 257 looked up, is selected. 259 4. If there are no entries available, then the Group-to-RP mapping 260 is undefined and this algorithm terminates. 262 5. A longest prefix match is performed on the subset of Group-to-RP 263 Mappings. 265 * If there is only one entry available then that is selected as 266 Group-to-RP mapping. 268 * If there are multiple entries available, we continue with the 269 algorithm with this smaller set of Group-to-RP Mappings. 271 6. From the remaining set of Group-to-RP Mappings we select the 272 subset of entries based on the preference for the PIM modes 273 which they are assigned. A Group-to-RP mapping entry with PIM 274 Mode 'BIDIR' will be preferred to an entry with PIM Mode 275 'PIM-SM' 277 * If there is only one entry available then that is selected as 278 Group-to-RP mapping. 280 * If there are multiple entries available, we continue with the 281 algorithm with this smaller set of Group-to-RP Mappings 283 7. From the remaining set of Group-to-RP Mappings we select the 284 subset of the entries based on the origin. Group-to-RP mappings 285 learned dynamically are preferred over static mappings. If the 286 remaining dynamic Group-to-RP mappings are from BSR and Auto-RP 287 then the mappings from BSR is preferred. 289 * If there is only one entry available then that is selected as 290 Group-to-RP mapping. 292 * If there are multiple entries available, we continue with the 293 algorithm with this smaller set of Group-to-RP Mappings. 295 8. If the remaining Group-to-RP mappings were learned through BSR 296 then the RP will be selected by comparing the RP Priority in the 297 Candidate-RP-Advertisement messages. The RP mapping with the 298 lowest value indicates the highest priority [RFC5059]. 300 * If more than one RP has the same highest priority value we 301 continue with the algorithm with those Group-to-RP mappings. 303 * If the remaining Group-to-RP mappings were NOT learned from 304 BSR we continue the algorithm with the next step. 306 9. If the remaining Group-to-RP mappings were learned through BSR 307 and the PIM Mode of the Group is 'PIM-SM' then the hash function 308 will be used to choose the RP. The RP with the highest 309 resulting hash value will be selected. Please look at section 310 10 for consideration of hash for BIDIR-PIM and BSR. 312 * If more than one RP has the same highest hash value we 313 continue with the algorithm with those Group-to-RP mappings. 315 * If the remaining Group-to-RP mappings were NOT learned from 316 BSR we continue the algorithm with the next step. 318 10. From the remaining set of Group-to-RP Mappings we will select 319 the RP with the highest IP address. This will serve as a final 320 tiebreaker. 322 7. Interpretation of MIB Objects 324 The algorithm defined in this document does not use the concept of 325 precedence and therefore the values configured in the 326 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects of 327 the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060] 328 are not applicable to the new algorithm. The objects still retain 329 their meaning for 'legacy' implementations, but since the algorithm 330 defined in this document is to be used in preference to that found in 331 PIM-SM [RFC4601] and PIM-STD-MIB [RFC5060], the usage of these fields 332 will decline as implementations are upgraded to support the new 333 algorithm. 335 8. Clarification for MIB Objects 337 An implementation of this specification can continue to be managed 338 using the PIM-STD-MIB [RFC5060]. When a Group-to-RP mapping entry is 339 created in the pimGroupMappingTable with RP address type in the 340 pimGroupMappingRPAddressType object is set to unknown(0), and the PIM 341 Mode in the pimGroupMappingPimMode object is set to either ssm(2) or 342 dm(5) to represent group ranges for SSM or Dense mode. 344 Also, all the entries which are already included in the SSM Range 345 table in the IP Mcast MIB [RFC5132] are copied to the 346 pimGroupMappingTable. Such entries have their type in the 347 pimGroupMappingOrigin object set to configSsm(3), and the RP address 348 type in the pimGroupMappingRPAddressType object set to unknown(0) as 349 described above. 351 9. Use of dynamic group-to-rp mapping protocols 353 It is not usually necessary to run several dynamic Group-to-RP 354 mapping mechanisms in one administrative domain. Specifically, 355 interoperation of BSR and Auto-RP is OPTIONAL. 357 However, if a router does receive two overlapping sets of Group-to-RP 358 mappings, for example from Auto-RP and BSR, then some algorithm is 359 needed to deterministically resolve the situation. The algorithm in 360 this document MUST be used. This can be important at domain border 361 routers, and is likely to improve stability under misconfiguration 362 and when configuration is changing. 364 An implementation of PIM that supports only one mechanism for 365 learning Group-to-RP mappings MUST also use this algorithm. The 366 algorithm has been chosen so that existing standard implementations 367 are already compliant. 369 10. Consideration for Bidirectional-PIM and BSR hash 371 BIDIR-PIM [RFC5015] is designed to avoid any data driven events. 372 This is especially true in the case of a source only branch. The RP 373 mapping is determined based on a group mask when the mapping is 374 received through a dynamic mapping protocol or statically configured. 376 Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based 377 on the algorithm defined in this document. It is RECOMMENDED that 378 network operators configure only one PIM-Bidir RP for each RP 379 Priority. 381 11. Filtering Group-to-RP mappings at domain boundaries 383 An implementation of PIM SHOULD support configuration to block 384 specific dynamic mechanism for a valid group prefix range. For 385 example, it should be possible to allow an administratively scoped 386 address range, such as 239/8 range, for Auto-RP protocol but block 387 the BSR advertisement for the same range. Similarly it should be 388 possible to filter out all Group-to-RP mappings learned from BSR or 389 Auto-RP protocol. 391 12. Security Consideration 393 This document enhances an existing algorithm to deterministically 394 choose between several group-to-rp mappings for a specific group. 395 The updated algorithm will not completely prevent the possibility of 396 different routers selecting different group-to-rp mappings for the 397 same group. Such situations can be avoided if various mechanisms 398 used to learn group-to-rp mappings are secure and consistent across 399 the network. 401 13. IANA Consideration 403 This draft does not create any namespace for IANA to manage. 405 14. Acknowledgements 407 This draft is created based on the discussion occurred during the 408 PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas, Yiqun Cai 409 and Toerless Eckert for providing useful comments. 411 15. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 417 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 418 Protocol Specification (Revised)", RFC 4601, August 2006. 420 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 421 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 422 January 2008. 424 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 425 Point (RP) Address in an IPv6 Multicast Address", 426 RFC 3956, November 2004. 428 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 429 "Bidirectional Protocol Independent Multicast (BIDIR- 430 PIM)", RFC 5015, October 2007. 432 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 433 "Bootstrap Router (BSR) Mechanism for Protocol Independent 434 Multicast (PIM)", RFC 5059, January 2008. 436 [RFC5132] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast 437 MIB", RFC 5132, December 2007. 439 Authors' Addresses 441 Bharat Joshi 442 Infosys Technologies Ltd. 443 44 Electronics City, Hosur Road 444 Bangalore 560 100 445 India 447 Email: bharat_joshi@infosys.com 448 URI: http://www.infosys.com/ 450 Andy Kessler 451 Cisco Systems, Inc. 452 425 E. Tasman Drive 453 San Jose, CA 95134 454 USA 456 Email: kessler@cisco.com 457 URI: http://www.cisco.com/ 459 David McWalter 461 Email: david@mcwalter.eu