Internet DRAFT - draft-asati-pim-multicast-routing-blackhole-avoid

draft-asati-pim-multicast-routing-blackhole-avoid



PIM Working Group                                           Rajiv Asati  
Internet Draft                                             Mike McBride 
Intended status: Informational                            Cisco Systems 
Expires: January 2009                                      July 6, 2008 
                                    
 
                                      
                   Multicast Routing Blackhole Avoidance  
         draft-asati-pim-multicast-routing-blackhole-avoid-00.txt 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 

   This Internet-Draft will expire on January 6, 2007. 

Copyright Notice 

   Copyright (C) The IETF Trust (2008). 

    

    

    

    
 
 
 
Asati & McBride        Expires January 6, 2009                 [Page 1] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

Abstract 

   This document specifies a mechanism to avoid blackholing of IP 
   Multicast traffic due to the disruption of multicast tree during the 
   time when the RPF neighbor is yet to become the PIM neighbor. Such 
   scenario is possible during the topology change (e.g. link UP) in an 
   IP network that employs PIM-SM (or SSM) as the multicast routing 
   protocol and a unicast routing protocol (including static routing). 

    

Conventions used in this document 

   In examples, "C:" and "S:" indicate lines sent by the client and 
   server respectively. 

   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 RFC2119 [RFC2119]. 

    

Table of Contents 

    
   1. Introduction...................................................3 
   2. Problem Details................................................3 
      2.1. Root-cause................................................4 
   3. Solution.......................................................5 
      3.1. Solution Detail...........................................6 
      3.2. Make-before-Break.........................................7 
   4. Other Solutions................................................8 
   5. Interoperability Considerations................................8 
   6. Security Considerations........................................8 
   7. IANA Considerations............................................8 
   8. Conclusions....................................................9 
   9. Acknowledgments................................................9 
   10. References...................................................10 
      10.1. Normative References....................................10 
      10.2. Informative References..................................10 
   Author's Addresses...............................................10 
   Intellectual Property Statement..................................10 
   Disclaimer of Validity...........................................11 
    
    


 
 
Asati & McBride        Expires January 6, 2009                 [Page 2] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

1. Introduction 

   A Multicast distribution tree, as identified by the corresponding 
   multicast route e.g. (S,G), (*,G), provides a pre-determined path for 
   distributing the multicast traffic from the source (or RP) to the 
   receivers through a set of routers.  

   PIM-SM [RFC4601] is a multicast routing protocol that uses the 
   information from the underlying unicast routing information base (or 
   its derivative) to determine the reverse path for the multicast 
   distribution tree (be it a source tree (S,G) or shared tree (*,G)) 
   and establishes the tree on that path. Specifically, the unicast 
   routing information base (or its derivative) information is utilized 
   to determine the next-hop neighbor and interface, commonly referred 
   to as RPF neighbor and RPF interface respectively in PIM-SM 
   [RFC4601], for the source of (S,G) or RP of (*,G). 

   PIM-SM [RFC4601] specifies that the PIM Join/Prune message for a 
   multicast tree must be sent to the RPF neighbor on the RPF interface 
   to join or prune a multicast tree. It also specifies that the PIM 
   Join/Prune message must be sent to or received from only PIM 
   neighbors. This means that the PIM neighbor relationship must be 
   established with the RPF neighbor on the RPF interface prior to 
   transmitting the PIM Join/Prune message after the link UP event. This 
   ensures that the PIM neighbor becomes capable of processing the PIM 
   Join/Prune messages and joining/pruning a multicast distribution 
   tree.  

   However, such assumption also opens up the possibility of multicast 
   traffic getting blackholed for brief time period after the link UP 
   event when the PIM neighbor relationship MAY take a little longer to 
   get established. This document describes this problem and proposes a 
   solution for that.  

    

2. Problem Details 

    
   Multicast distribution trees built using PIM-SM [RFC4601] in an IP 
   network may experience an outage for brief period following the link 
   UP event. The figure 1 and 2 below are used to explain this problem. 

    



 
 
Asati & McBride        Expires January 6, 2009                 [Page 3] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

   +------------------------------------------------+ 
   |                                                | 
   |   Source----R1------R2------R3------Receiver   | 
   |                                                | 
   +------------------------------------------------+ 
    
                 Figure 1 Topology prior to R1-R3 link Up 

    

   +------------------------------------------------+ 
   |                                                | 
   |   Source----R1------R2------R3------Receiver   | 
   |              \              /                  | 
   |               \------------/                   | 
   |                                                | 
   +------------------------------------------------+ 
    
                   Figure 2 Topology after R1-R3 link Up 

    

   After the (R1-R3) link Up event, the unicast routing may likely 
   converge quite fast and update the unicast routing information base 
   to make use of that link. This may trigger the RPF neighbor 
   calculation at router R3 for the particular multicast route(s). The 
   determination of new RPF neighbor (R1, say) for a particular 
   multicast route may further trigger an update of the multicast route 
   in the multicast routing information base. This further triggers the 
   PIM module to send PIM Prune message to the current RPF neighbor (R2, 
   say) and PIM Join message to the new RPF neighbor (R1, say).  

   However, per PIM-SM [RFC4601], if the RPF neighbor is not yet the PIM 
   neighbor, then the PIM Join should not be sent to that neighbor. Even 
   if the PIM Join was sent (by R3, say), then the upstream router (R1, 
   say) may not process the PIM Join/Prune message until the downstream 
   router is known as the PIM neighbor. This means that the multicast 
   tree may be disrupted on R1-R3 link for some time until PIM neighbor 
   relationship is established on R1-R3 link and PIM Join is sent and 
   processed.  

    

2.1. Root-cause 

   Firstly, after the link UP event, the PIM neighbor adjacency 
   establishment on a link may take longer than the total time taken to 
 
 
Asati & McBride        Expires January 6, 2009                 [Page 4] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

   establish the unicast routing neighbor adjacency on that link, 
   determine the new RPF neighbor, if any, and update the corresponding 
   multicast route entry(s). The larger time-period may be due to any of 
   the reasons such as - 

   1) PIM is misconfigured or not configured. 

   2) PIM Hellos are not exchanged immediately after the link UP. 

   3) PIM Hello is sent, but not received after the link UP. 

   4) PIM module experienced a software issue. 

    

   Secondly, a multicast routing entry is updated with the new RPF 
   neighbor information as soon as that information becomes available 
   after the unicast routing convergence. There is no check for the RPF 
   neighbor being the PIM neighbor prior to this update. This is really 
   what causes the disruption in multicast tree. 

    

3. Solution 

   It may be somewhat obvious from section 2.1 that one may attempt to  
   solve the 1st problem, but it is difficult to solve for all of the 
   scenarios. However, it is very much possible to sufficiently solve 
   the 2nd problem, and that will automatically bypass the 1st one.  

   The solution is somewhat simple and straight-forward - replace the 
   current RPF neighbor with the new RPF neighbor for a multicast 
   routing entry ONLY if the new RPF neighbor is determined to be the 
   PIM neighbor. This means that the logic is infused to not propagate 
   the new RPF neighbor information to the multicast routing information 
   base unless the RPF neighbor is listed in the PIM neighbor database. 
   If the RPF neighbor is not listed in the PIM neighbor database, then 
   the PIM adjacency establishment procedure i.e. send PIM hello etc. 
   must be initiated.  

   This means that the forwarding mroute entry may be left intact until 
   the PIM neighbor adjacency is established with the RPF neighbor on 
   the RPF interface. While this may keep the multicast distribution 
   tree from taking advantage of the changed topology i.e. new link for 
   brief time period, it ensures that the multicast distribution tree is 
   not disrupted unnecessarily and the multicast traffic is not 
   blackholed. 
 
 
Asati & McBride        Expires January 6, 2009                 [Page 5] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

   An advantage with this solution is that the proposed changes are 
   local to a router.  

    

3.1. Solution Detail 

   One may construct the state machine to be the modified as following 
   (please refer to figure 2) - 

   After the (R1-R3) link Up event, the unicast routing convergence 
   triggers the RPF neighbor calculation at router R3 for the particular 
   multicast route(s). After the RPF neighbor is determined, a check is 
   inserted whether the RPF neighbor is also the PIM neighbor on R1-R3 
   link by looking up the PIM neighbor database 

   If such a check returns a positive match, then the corresponding 
   multicast route in the multicast routing information base is(are) 
   updated with the new RPF neighbor (R1, say) information. This further 
   triggers the PIM module to send PIM Join message to the new RPF 
   neighbor (R1, say), and PIM Prune message to the current RPF neighbor 
   (R2, say).  

   If such a check returns a negative match, then the multicast route in 
   the multicast routing information base is(are) NOT updated with the 
   new RPF neighbor (R1, say) information, and no PIM Join/Prune 
   messages are generated as a result. This results in the multicast 
   distribution tree continuing to use the old RPF neighbor information 
   and avoiding the multicast traffic blackholing. 

   The state machine may continue to check for RPF neighbor being the 
   PIM neighbor either regularly or wait for the trigger, so that when 
   the RPF neighbor indeed becomes the PIM neighbor, the check returns a 
   positive match for the multicast routes to be updated as explained 
   above. 

    

   In summary, the multicast routing sequence would be as follows - 

   1) New RPF neighbor is determined after the unicast routing 
      convergence 

   2) Check whether the new RPF neighbor is also PIM neighbor on the 
      RPF interface 


 
 
Asati & McBride        Expires January 6, 2009                 [Page 6] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

   3) If it is not, then initiate the PIM neighbor establishment 
      procedure by sending PIM Hellos etc. on the new RPF interface 

   4) If it is, then update the multicast forwarding entry by replacing 
      the old RPF neighbor (and interface) information with the new RPF 
      neighbor (and interface) information  

   5) Send the PIM Join message for the related multicast routes (S,G 
      or *,G).  

   6) Send the PIM Prune message to the old RPF neighbor for the 
      related multicast routes (S,G or *,G) 

    

3.2. Make-before-Break  

   This solution also paves the way for true make-before-break behavior 
   for multicast forwarding if the PIM join for a particular mroute (*,G 
   or S,G) is sent to the new RPF neighbor after establishing the PIM 
   neighbor relationship, but before updating the related multicast 
   forwarding entry. This increases the likelihood that the upstream RPF 
   neighbor would have updated its multicast forwarding entry and 
   started sending the multicast traffic downstream. Of course, the 
   traffic would not get forwarded by the downstream router (thanks to 
   RPF check failure) until the multicast forwarding entry is updated 
   with the new RPF neighbor. This almost ensures that the multicast 
   traffic is available on the new path before switching the RPF 
   interface of the multicast forwarding entry.   

   The multicast routing sequence for make-before-break can be 
   summarized as below - 

   1) New RPF neighbor is determined after the unicast routing 
      convergence   

   2) Check whether the new RPF neighbor is also PIM neighbor on the 
      RPF interface 

   3) If it is not, then initiate the PIM neighbor establishment 
      procedure by sending PIM Hellos etc. on the new RPF interface 

   4) If it is, then send the PIM Join message for the related 
      multicast routes (S,G or *,G).  



 
 
Asati & McBride        Expires January 6, 2009                 [Page 7] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

   5) Update the multicast forwarding entry by replacing the old RPF 
      neighbor (and interface) information with the new RPF neighbor 
      (and interface) information 

   6) Send the PIM Prune message to the old RPF neighbor for the 
      related multicast routes (S,G or *,G) 

   It is envisioned that an implementation may provide a configuration 
   option to enable the make-before-break functionality. Also note that 
   this section refers to section 4.5.7 of RFC4601. 

    

4. Other Solutions 

   There are number of other approaches to solve this issue, however, 
   they all attempt to solve the 1st problem as explained in the section 
   2.1. 

   1. Ignore the PIM hello - This doesn't solve the issue completely. 
      What if the PIM module is malfunctioning on the upstream router.  

   2. Triggered PIM Hello - This doesn't solve the issue completely, 
      what if the PIM hellos are not received by the remote router. 
      Speeding up Hellos may also penalize the processing resources at 
      the router. 

   3. Multi-topology - A non-PIM solution that shifts the problem to a 
      different topology, which becomes responsible for maintaining the 
      PIM operation. 

    

5. Interoperability Considerations 

   This mechanism introduces no interoperability issue since the changes 
   are local to the router. 

    

6. Security Considerations 

   None. 

7. IANA Considerations 

   None. 
 
 
Asati & McBride        Expires January 6, 2009                 [Page 8] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

8. Conclusions 

   IPTV deployment using multicast for Broadcast Video delivery desires 
   multicast sub-second convergence and resiliency since the broadcast 
   video such as MPEG video is loss intolerant. Hence, it is imperative 
   to eliminate any unnecessary multicast traffic outage (blackholing) 
   during the IP network topology changes such as Link UP event. The 
   root-cause of the blackholing problem, as clarified in this document, 
   lies in the PIM protocol.  

   Although there are non-PIM solutions, having a PIM based solution 
   that is simple, straight-forward, easier to implement and that 
   requires no interoperability is the goal of this document. The simple 
   change to the PIM state machinery, as proposed in this document, 
   would prevent blackholing of multicast data.   

    

9. Acknowledgments 

   TBD. 

   This document was prepared using 2-Word-v2.0.template.dot. 
























 
 
Asati & McBride        Expires January 6, 2009                 [Page 9] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

10. References 

10.1. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC4601] Fenner B., Handley M., Holbrook H., and Kouvelas I., 
             "Protocol Indpendent Multicast - Sparse Mode (PIM-SM): 
             Protocol Specification (Revised)", RFC 2601, August 2006. 

10.2. Informative References 

    

Author's Addresses 

   Rajiv Asati 
   Cisco Systems, 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 
   Email: rajiva@cisco.com  
    

   Mike McBride 
   Cisco Systems, 121 Theory, IRVINE, CA, 92617-3045   
   Email: mmcbride@cisco.com 
    
    

Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 


 
 
Asati & McBride        Expires January 6, 2009                [Page 10] 

Internet-Draft  draft-asati-pim-multicast-routing-blackhole   July 2008 
    

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   ietf-ipr@ietf.org. 

Disclaimer of Validity 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

Copyright Statement 

   Copyright (C) The IETF Trust (2008). 

   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

    

















 
 
Asati & McBride        Expires January 6, 2009                [Page 11]