idnits 2.17.1 draft-asati-pim-multicast-routing-blackhole-avoid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 397. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (July 6, 2008) is 5773 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PIM Working Group Rajiv Asati 2 Internet Draft Mike McBride 3 Intended status: Informational Cisco Systems 4 Expires: January 2009 July 6, 2008 6 Multicast Routing Blackhole Avoidance 7 draft-asati-pim-multicast-routing-blackhole-avoid-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 6, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document specifies a mechanism to avoid blackholing of IP 42 Multicast traffic due to the disruption of multicast tree during the 43 time when the RPF neighbor is yet to become the PIM neighbor. Such 44 scenario is possible during the topology change (e.g. link UP) in an 45 IP network that employs PIM-SM (or SSM) as the multicast routing 46 protocol and a unicast routing protocol (including static routing). 48 Conventions used in this document 50 In examples, "C:" and "S:" indicate lines sent by the client and 51 server respectively. 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC2119 [RFC2119]. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Problem Details................................................3 61 2.1. Root-cause................................................4 62 3. Solution.......................................................5 63 3.1. Solution Detail...........................................6 64 3.2. Make-before-Break.........................................7 65 4. Other Solutions................................................8 66 5. Interoperability Considerations................................8 67 6. Security Considerations........................................8 68 7. IANA Considerations............................................8 69 8. Conclusions....................................................9 70 9. Acknowledgments................................................9 71 10. References...................................................10 72 10.1. Normative References....................................10 73 10.2. Informative References..................................10 74 Author's Addresses...............................................10 75 Intellectual Property Statement..................................10 76 Disclaimer of Validity...........................................11 78 1. Introduction 80 A Multicast distribution tree, as identified by the corresponding 81 multicast route e.g. (S,G), (*,G), provides a pre-determined path for 82 distributing the multicast traffic from the source (or RP) to the 83 receivers through a set of routers. 85 PIM-SM [RFC4601] is a multicast routing protocol that uses the 86 information from the underlying unicast routing information base (or 87 its derivative) to determine the reverse path for the multicast 88 distribution tree (be it a source tree (S,G) or shared tree (*,G)) 89 and establishes the tree on that path. Specifically, the unicast 90 routing information base (or its derivative) information is utilized 91 to determine the next-hop neighbor and interface, commonly referred 92 to as RPF neighbor and RPF interface respectively in PIM-SM 93 [RFC4601], for the source of (S,G) or RP of (*,G). 95 PIM-SM [RFC4601] specifies that the PIM Join/Prune message for a 96 multicast tree must be sent to the RPF neighbor on the RPF interface 97 to join or prune a multicast tree. It also specifies that the PIM 98 Join/Prune message must be sent to or received from only PIM 99 neighbors. This means that the PIM neighbor relationship must be 100 established with the RPF neighbor on the RPF interface prior to 101 transmitting the PIM Join/Prune message after the link UP event. This 102 ensures that the PIM neighbor becomes capable of processing the PIM 103 Join/Prune messages and joining/pruning a multicast distribution 104 tree. 106 However, such assumption also opens up the possibility of multicast 107 traffic getting blackholed for brief time period after the link UP 108 event when the PIM neighbor relationship MAY take a little longer to 109 get established. This document describes this problem and proposes a 110 solution for that. 112 2. Problem Details 114 Multicast distribution trees built using PIM-SM [RFC4601] in an IP 115 network may experience an outage for brief period following the link 116 UP event. The figure 1 and 2 below are used to explain this problem. 118 +------------------------------------------------+ 119 | | 120 | Source----R1------R2------R3------Receiver | 121 | | 122 +------------------------------------------------+ 124 Figure 1 Topology prior to R1-R3 link Up 126 +------------------------------------------------+ 127 | | 128 | Source----R1------R2------R3------Receiver | 129 | \ / | 130 | \------------/ | 131 | | 132 +------------------------------------------------+ 134 Figure 2 Topology after R1-R3 link Up 136 After the (R1-R3) link Up event, the unicast routing may likely 137 converge quite fast and update the unicast routing information base 138 to make use of that link. This may trigger the RPF neighbor 139 calculation at router R3 for the particular multicast route(s). The 140 determination of new RPF neighbor (R1, say) for a particular 141 multicast route may further trigger an update of the multicast route 142 in the multicast routing information base. This further triggers the 143 PIM module to send PIM Prune message to the current RPF neighbor (R2, 144 say) and PIM Join message to the new RPF neighbor (R1, say). 146 However, per PIM-SM [RFC4601], if the RPF neighbor is not yet the PIM 147 neighbor, then the PIM Join should not be sent to that neighbor. Even 148 if the PIM Join was sent (by R3, say), then the upstream router (R1, 149 say) may not process the PIM Join/Prune message until the downstream 150 router is known as the PIM neighbor. This means that the multicast 151 tree may be disrupted on R1-R3 link for some time until PIM neighbor 152 relationship is established on R1-R3 link and PIM Join is sent and 153 processed. 155 2.1. Root-cause 157 Firstly, after the link UP event, the PIM neighbor adjacency 158 establishment on a link may take longer than the total time taken to 159 establish the unicast routing neighbor adjacency on that link, 160 determine the new RPF neighbor, if any, and update the corresponding 161 multicast route entry(s). The larger time-period may be due to any of 162 the reasons such as - 164 1) PIM is misconfigured or not configured. 166 2) PIM Hellos are not exchanged immediately after the link UP. 168 3) PIM Hello is sent, but not received after the link UP. 170 4) PIM module experienced a software issue. 172 Secondly, a multicast routing entry is updated with the new RPF 173 neighbor information as soon as that information becomes available 174 after the unicast routing convergence. There is no check for the RPF 175 neighbor being the PIM neighbor prior to this update. This is really 176 what causes the disruption in multicast tree. 178 3. Solution 180 It may be somewhat obvious from section 2.1 that one may attempt to 181 solve the 1st problem, but it is difficult to solve for all of the 182 scenarios. However, it is very much possible to sufficiently solve 183 the 2nd problem, and that will automatically bypass the 1st one. 185 The solution is somewhat simple and straight-forward - replace the 186 current RPF neighbor with the new RPF neighbor for a multicast 187 routing entry ONLY if the new RPF neighbor is determined to be the 188 PIM neighbor. This means that the logic is infused to not propagate 189 the new RPF neighbor information to the multicast routing information 190 base unless the RPF neighbor is listed in the PIM neighbor database. 191 If the RPF neighbor is not listed in the PIM neighbor database, then 192 the PIM adjacency establishment procedure i.e. send PIM hello etc. 193 must be initiated. 195 This means that the forwarding mroute entry may be left intact until 196 the PIM neighbor adjacency is established with the RPF neighbor on 197 the RPF interface. While this may keep the multicast distribution 198 tree from taking advantage of the changed topology i.e. new link for 199 brief time period, it ensures that the multicast distribution tree is 200 not disrupted unnecessarily and the multicast traffic is not 201 blackholed. 203 An advantage with this solution is that the proposed changes are 204 local to a router. 206 3.1. Solution Detail 208 One may construct the state machine to be the modified as following 209 (please refer to figure 2) - 211 After the (R1-R3) link Up event, the unicast routing convergence 212 triggers the RPF neighbor calculation at router R3 for the particular 213 multicast route(s). After the RPF neighbor is determined, a check is 214 inserted whether the RPF neighbor is also the PIM neighbor on R1-R3 215 link by looking up the PIM neighbor database 217 If such a check returns a positive match, then the corresponding 218 multicast route in the multicast routing information base is(are) 219 updated with the new RPF neighbor (R1, say) information. This further 220 triggers the PIM module to send PIM Join message to the new RPF 221 neighbor (R1, say), and PIM Prune message to the current RPF neighbor 222 (R2, say). 224 If such a check returns a negative match, then the multicast route in 225 the multicast routing information base is(are) NOT updated with the 226 new RPF neighbor (R1, say) information, and no PIM Join/Prune 227 messages are generated as a result. This results in the multicast 228 distribution tree continuing to use the old RPF neighbor information 229 and avoiding the multicast traffic blackholing. 231 The state machine may continue to check for RPF neighbor being the 232 PIM neighbor either regularly or wait for the trigger, so that when 233 the RPF neighbor indeed becomes the PIM neighbor, the check returns a 234 positive match for the multicast routes to be updated as explained 235 above. 237 In summary, the multicast routing sequence would be as follows - 239 1) New RPF neighbor is determined after the unicast routing 240 convergence 242 2) Check whether the new RPF neighbor is also PIM neighbor on the 243 RPF interface 245 3) If it is not, then initiate the PIM neighbor establishment 246 procedure by sending PIM Hellos etc. on the new RPF interface 248 4) If it is, then update the multicast forwarding entry by replacing 249 the old RPF neighbor (and interface) information with the new RPF 250 neighbor (and interface) information 252 5) Send the PIM Join message for the related multicast routes (S,G 253 or *,G). 255 6) Send the PIM Prune message to the old RPF neighbor for the 256 related multicast routes (S,G or *,G) 258 3.2. Make-before-Break 260 This solution also paves the way for true make-before-break behavior 261 for multicast forwarding if the PIM join for a particular mroute (*,G 262 or S,G) is sent to the new RPF neighbor after establishing the PIM 263 neighbor relationship, but before updating the related multicast 264 forwarding entry. This increases the likelihood that the upstream RPF 265 neighbor would have updated its multicast forwarding entry and 266 started sending the multicast traffic downstream. Of course, the 267 traffic would not get forwarded by the downstream router (thanks to 268 RPF check failure) until the multicast forwarding entry is updated 269 with the new RPF neighbor. This almost ensures that the multicast 270 traffic is available on the new path before switching the RPF 271 interface of the multicast forwarding entry. 273 The multicast routing sequence for make-before-break can be 274 summarized as below - 276 1) New RPF neighbor is determined after the unicast routing 277 convergence 279 2) Check whether the new RPF neighbor is also PIM neighbor on the 280 RPF interface 282 3) If it is not, then initiate the PIM neighbor establishment 283 procedure by sending PIM Hellos etc. on the new RPF interface 285 4) If it is, then send the PIM Join message for the related 286 multicast routes (S,G or *,G). 288 5) Update the multicast forwarding entry by replacing the old RPF 289 neighbor (and interface) information with the new RPF neighbor 290 (and interface) information 292 6) Send the PIM Prune message to the old RPF neighbor for the 293 related multicast routes (S,G or *,G) 295 It is envisioned that an implementation may provide a configuration 296 option to enable the make-before-break functionality. Also note that 297 this section refers to section 4.5.7 of RFC4601. 299 4. Other Solutions 301 There are number of other approaches to solve this issue, however, 302 they all attempt to solve the 1st problem as explained in the section 303 2.1. 305 1. Ignore the PIM hello - This doesn't solve the issue completely. 306 What if the PIM module is malfunctioning on the upstream router. 308 2. Triggered PIM Hello - This doesn't solve the issue completely, 309 what if the PIM hellos are not received by the remote router. 310 Speeding up Hellos may also penalize the processing resources at 311 the router. 313 3. Multi-topology - A non-PIM solution that shifts the problem to a 314 different topology, which becomes responsible for maintaining the 315 PIM operation. 317 5. Interoperability Considerations 319 This mechanism introduces no interoperability issue since the changes 320 are local to the router. 322 6. Security Considerations 324 None. 326 7. IANA Considerations 328 None. 330 8. Conclusions 332 IPTV deployment using multicast for Broadcast Video delivery desires 333 multicast sub-second convergence and resiliency since the broadcast 334 video such as MPEG video is loss intolerant. Hence, it is imperative 335 to eliminate any unnecessary multicast traffic outage (blackholing) 336 during the IP network topology changes such as Link UP event. The 337 root-cause of the blackholing problem, as clarified in this document, 338 lies in the PIM protocol. 340 Although there are non-PIM solutions, having a PIM based solution 341 that is simple, straight-forward, easier to implement and that 342 requires no interoperability is the goal of this document. The simple 343 change to the PIM state machinery, as proposed in this document, 344 would prevent blackholing of multicast data. 346 9. Acknowledgments 348 TBD. 350 This document was prepared using 2-Word-v2.0.template.dot. 352 10. References 354 10.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 [RFC4601] Fenner B., Handley M., Holbrook H., and Kouvelas I., 360 "Protocol Indpendent Multicast - Sparse Mode (PIM-SM): 361 Protocol Specification (Revised)", RFC 2601, August 2006. 363 10.2. Informative References 365 Author's Addresses 367 Rajiv Asati 368 Cisco Systems, 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 369 Email: rajiva@cisco.com 371 Mike McBride 372 Cisco Systems, 121 Theory, IRVINE, CA, 92617-3045 373 Email: mmcbride@cisco.com 375 Intellectual Property Statement 377 The IETF takes no position regarding the validity or scope of any 378 Intellectual Property Rights or other rights that might be claimed to 379 pertain to the implementation or use of the technology described in 380 this document or the extent to which any license under such rights 381 might or might not be available; nor does it represent that it has 382 made any independent effort to identify any such rights. Information 383 on the procedures with respect to rights in RFC documents can be 384 found in BCP 78 and BCP 79. 386 Copies of IPR disclosures made to the IETF Secretariat and any 387 assurances of licenses to be made available, or the result of an 388 attempt made to obtain a general license or permission for the use of 389 such proprietary rights by implementers or users of this 390 specification can be obtained from the IETF on-line IPR repository at 391 http://www.ietf.org/ipr. 393 The IETF invites any interested party to bring to its attention any 394 copyrights, patents or patent applications, or other proprietary 395 rights that may cover technology that may be required to implement 396 this standard. Please address the information to the IETF at 397 ietf-ipr@ietf.org. 399 Disclaimer of Validity 401 This document and the information contained herein are provided on an 402 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 403 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 404 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 405 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 406 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 407 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 409 Copyright Statement 411 Copyright (C) The IETF Trust (2008). 413 This document is subject to the rights, licenses and restrictions 414 contained in BCP 78, and except as set forth therein, the authors 415 retain all their rights. 417 Acknowledgment 419 Funding for the RFC Editor function is currently provided by the 420 Internet Society.