Abstract:
A system, method and apparatus for adapting operation of a router configured to receive commonly sourced traffic via primary and secondary Upstream Multicast Hop (UMH) links, wherein the secondary path is cached for a predetermined period of time to avoid data loss upon restoration of the primary path.

Description:
FIELD OF THE INVENTION 
       [0001]    The invention relates to the field of communication networks such as multi-protocol label switching (MPLS) networks and, more particularly but not exclusively, to point to multipoint (P2MP) traffic path management. 
       BACKGROUND 
       [0002]    Multicast Only Fast Re-Route (MoFRR) is an enhancement to multicast routing protocols such as Protocol Independent Multicast (PIM), Multi-point Label Distribution Protocol (mLDP) and so on. An implementation of MoFRR is described in more detail in Internet Engineering Task Force (IETF) Network Working Group draft document dated Mar. 9, 2012 and entitled “draft-karan-mofrr-02” (hereinafter “Karan”). Briefly, on a PIM enabled edge router having multicast receivers, MoFRR logic determines a primary Upstream Multicast Hop (UMH) and a secondary UMH and joins the tree via both simultaneously. Data packets are received over the primary and secondary paths. Only the packets from the primary UMH are accepted and forwarded down the tree, the packets from the secondary UMH are discarded. The UMH determination is different for PIM and mLDP. 
         [0003]    When a failure is detected on the path to the primary UMH, a repair occurs by changing the secondary UMH into the primary and the primary into the secondary. Since the repair is local it is performed very quickly, thereby greatly improving convergence times in the event of node or link failures on the path to the primary UMH. 
         [0004]    Unfortunately, when a link or node on the path towards the multicast source is restored, normal PIM or mLDP functions may result in a traffic loss. 
       SUMMARY 
       [0005]    Various deficiencies in the prior art are addressed by systems, methods and apparatus for adapting operation of a router configured to receive commonly sourced traffic via primary and secondary Upstream Multicast Hop (UMH) links, wherein the secondary path is cached for a predetermined period of time to avoid data loss upon restoration of the primary path. 
         [0006]    One embodiment may be used at, illustratively, a router configured to receive commonly sourced traffic via a first link associated with a primary path Upstream Multicast Hop (UMH) and a second link associated with a secondary path UMH, wherein in response to detecting a primary path error, adapting a forwarding plane to forward traffic associated with the secondary path UMH and caching the secondary path UMH as a primary path UMH; and in response to detecting a primary path restoration, starting a timer and adapting the forwarding plane to continue forwarding traffic associated with the secondary path UMH until the occurrence of the expiry of the timer or the arrival of traffic from the primary path UMH. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which: 
           [0008]      FIG. 1  depicts an exemplary network benefiting from the various embodiments; 
           [0009]      FIG. 2  depicts a simplified representation of an exemplary network benefiting from the various embodiments; 
           [0010]      FIG. 3  depicts a flow diagram of a method according to one embodiment; and 
           [0011]      FIG. 4  depicts a high-level block diagram of a computer suitable for use in performing functions described herein. 
       
    
    
       [0012]    To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. 
       DETAILED DESCRIPTION 
       [0013]    Various embodiments will be described within the context of a provider edge (PE) router operating as a merge point router to join a multicast tree via two upstream paths; preferably divergent upstream paths to ensure thereby maximum redundancy. Generally speaking, the merge point router typically only accepts and forwards on one of the upstream paths at the time in order to avoid duplicate packet forwarding. The selection of the primary and secondary UMH is done by MoFRR logic and normally based on unicast routing to find loop free candidates. The various operations described herein are also applicable to multicast routing. It will be appreciated by those skilled in the art that the various embodiments described herein are applicable to other types of networks, network topologies, protocols and the like. 
         [0014]    The various embodiments will generally be described using functionality discussed within the IETF Draft Document of Mar. 9, 2012 entitled draft-karan-mofrr-02 (hereinafter “Karan”), which is incorporated herein by reference in its entirety). The inventors also contemplate that the various embodiments are applicable to many other protocols and techniques such as described in various other IETF documents, versions of the Karan document and so on, as will be appreciated by those skilled in the art. 
         [0015]      FIG. 1  depicts a high-level block diagram of a communication network architecture benefiting from various embodiments. Specifically, the exemplary architecture  100  of  FIG. 1  includes a communication network (CN)  105 , illustratively a Multi-Protocol Label Switching (MPLS) network, and at least one network management system (NMS)  120  operative to, illustratively, route traffic between a source Customer Edge (CE) router CE-S  130 -S and a destination CE router CE-D  130 -D via one or both of primary and secondary label switched paths (LSPs); namely, primary path P and secondary path S, each of which is associated with a respective control plane. As depicted, one or more NMSs  120  are operative to control a plurality of routers  110  forming the CN  105  in a manner supporting at least two control planes; namely, a plurality of Provider Edge (PE) routers  110 - 1  through  110 - 4 , and a plurality of core routers  110 -X 1  and  110 -X 2 . It will be noted that while only four PE routers are depicted, the CN  105  may include many more PE routers. Similarly, while only two core routers are depicted, the CN  105  may include many more core routers. The representation of the CN  105  is simplified for purposes of this discussion. 
         [0016]    The one or more NMSs  120  are network management systems adapted for performing the various management functions described herein and are adapted to communicate with nodes of CN  105 . The NMSs  120  may also be adapted to communicate with other operations support systems (e.g., Element Management Systems (EMSs), Topology Management Systems (TMSs), and the like, as well as various combinations thereof). 
         [0017]    The NMSs  120  may be implemented at a network node, network operations center (NOC) or any other location capable of communication with the CN  105  and various elements related thereto. The NMS  120  may support user interface capabilities to enable one or more users to perform various network management, configuration, provisioning or control related functions (e.g., enter information, review information, initiate execution of various methods as described herein and the like). Various embodiments of the NMS  120  are adapted to perform functions as discussed herein with respect to the various embodiments. The NMS  120  may be implemented as a general purpose computing device or specific purpose computing device, such as described below with respect to  FIG. 3 . 
         [0018]    As depicted in  FIG. 1 , a traffic stream (e.g., a video or other data stream) is communicated from a source Customer Edge (CE) router CE-S  130 -S to a destination CE router CE-D  130 -D via each of primary and secondary label switched paths (LSPs); namely, primary path P and secondary path S. Primary path P originates at PE  110 - 1 , traverses the core of CN  105  and terminates at PE  110 - 3 . Secondary path S originates at PE  110 - 2 , traverses the core of CN  105  and terminates at PE  110 - 3 . These paths may comprise disjoint paths. In normal operation, traffic from primary path P is forwarded by PE  110 - 3  to the CE router  130 -S, while traffic from secondary path S is dropped by PE  110 - 3 . 
         [0019]      FIG. 2  depicts a simplified representation of an exemplary network benefiting from the various embodiments. Specifically,  FIG. 2  depicts a multicast source  130 -S delivering common traffic toward a provider edge (PE) router  240  via each of a primary network plane  220 - 1  and a secondary network plane  220 - 2 . The PE router  240  forwards traffic to a receiver  250  from one of the primary network plane  220 - 1  or secondary network plane  220 - 2 . 
         [0020]    Also depicted in  FIG. 2  is a primary path Upstream Multicast Hop (UMH)  230 - 1  (P 1 ) and a secondary path UMH  230 - 2  (P 2 ). The primary path UMH  230 - 1  and secondary path UMH  230 - 2  provide unicast routes by which the PE router  240  may reach the multicast source  130 -S. Specifically, the unicast route has P 1  as the primary next hop and P 2  as the LFA next hop. 
         [0021]    PE router  240  is configured to join the primary path UMH  230 - 1  and secondary path UMH  230 - 2  via a PIM (S,G) join. Illustratively, as per the MoFRR procedures described in the Karan document, the PE router  240  sends a PIM (S,G) join to both of the next hops P 1  and P 2 . 
         [0022]    In a steady state mode of operation (no primary network plane failure), the PE router  240  receives traffic from the primary next hop  230 - 1  via link L 1 , and from the Loop Tree Alternate (LFA) next hop  230 - 2  via link L 2 . The traffic from the primary next hop  230 - 1  (i.e., P 2 ) is forwarded to the receiver  250 , while the traffic from the LFA next hop  230 - 2  (i.e., P 2 ) is dropped. That is, in a steady-state multicast traffic received by the PE router  240  from the primary network plane  220 - 1  is forwarded to the receiver  250 , while the same multicast traffic received by the PE router  240  from the secondary network plane  220 - 2  is dropped. In response to a failure in the primary network plane  220 - 1 , the traffic from the primary network plane  220 - 1  is dropped and the traffic from the second or network plane  220 - 2  is forwarded to the receiver. 
         [0023]    If the link L 1  fails, Protocol Independent Multicast (PIM) at the PE router  240  will quickly detect this failure via Bi-directional Forwarding Detection (BFD) or some other mechanism. The PE router  240  will, via PIM , reprogram the forwarding plane to start accepting traffic arriving on link L 2 . Subsequently, any interior gateway protocols (IGPs) such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), Border Gateway Protocol (BGP) and the like will run a Shortest Path First (SPF) calculation to determine a backup path, selecting P 2  as the new primary next hop. Since PIM has already modeled P 2  as a primary next hop, the new route need not result in any PIM protocol actions. 
         [0024]    When the link L 1  is restored, IGP will again run a SPF calculation and include L 1  as the primary next hop. However since IGP does not compute the LFA next hops along with the primary next hop, the new unicast route will only have L 1  as the primary next hop; that is, there will be no LFA next hop. When PIM receives this route, it would take the protocol action of sending a (S,G) join to primary next hop P 1  and (S,G) prune to the old next hop P 2  (this next hop is removed by the IGP). 
         [0025]    This action of PIM in response to link L 1  restoration may result in a traffic loss. Specifically, traffic may be lost during the time it takes for the PIM (S,G) join to traverse hop by hop in the primary network plane  220 - 1  and reach the multicast source  130 -S, and the time it takes for the multicast traffic to start flowing through the primary network plane  220 - 1  and arrive at the PE  240 . Depending on the network topology, the traffic might take many seconds to arrive at the PE. This loss of traffic defeats the primary purpose of the MoFRR LFA feature, which is to avoid excessive traffic losses. Various embodiments described herein are operative to reduce or remove such traffic loss. 
         [0026]    Specifically, various embodiments operate to cache (for a hold-time period) the next hop that the route table manager has marked for deletion and continue to accept multicast traffic from that next hop. The old next hop will become a LFA next hop or it will be deleted by PIM. The old next hop will be deleted if (A) the SPF calculation does not select the old next hop; or (B) the hold timer expires. 
         [0027]      FIG. 3  depicts a flow diagram of a method according to one embodiment. Specifically, the method  300  of  FIG. 3  depicts various control plane processes invoked by, illustratively, PE router  240  in response to a failure and subsequent restoration associated with the primary network plane  220 - 1 . 
         [0028]    At step  310 , PE router  240  sends PIM (S,G) joins to both the when and P 2 ; where P 1  is the primary next hop connected by Link L 1  to primary network plane  220 - 1  and P 2  is the LFA next hop connected by link L 2  to secondary network plane  220 - 2 . 
         [0029]    At step  320 , traffic is flowing in a steady state and that the PE router  240  receives multicast traffic from both P 1  and P 2 , forwards the P 1  traffic toward the receiver  250  and drops the P 2  traffic. 
         [0030]    At step  330 , in response to detecting a link L 1  error (generically, a failure associated with network plane  220 - 1 ) the PE router  240  begins forwarding the P 2  traffic toward the receiver  250  and dropping/ignoring any P 1  traffic. Referring to box  335 , at the PE router  240  PIM programs a forwarding plane to start accepting traffic from next hop P 2 . 
         [0031]    At step  340 , restoration of link L 1  is detected (generically, a failure associated with network plane  220 - 1  has been corrected such that a multicast path supported by network plane  220 - 1  is restored). Referring to box  345 , IGP submits the unicast route with P 1  as the next hop for SPF calculation. In addition, PE router  240  PIM performs the following steps: 
         [0032]    (1) cache the old next hop (i.e., P 2 ); 
         [0033]    (2) start a hold timer; 
         [0034]    (3) send a join to the new next hop P 1 ; and 
         [0035]    (4) program the forwarding plane to continue accepting traffic from potential next hop P 2 . 
         [0036]    At step  350 , if traffic from primary next hop P 1  arrives at PE router  240  prior to the expiry of the hold timer started at step  340 , then P 1  traffic is forwarded to the receiver  250  while P 2  traffic is dropped. Referring to box  355 , PE router  240  PIM performs the following steps: 
         [0037]    (1) reprogram the forwarding plane entry to stop accepting traffic from the LFA next hop P 2  and only accept traffic from primary next hop P 1  by a link L 1 ; and 
         [0038]    (2) drop the cash of the old next hop P 2 . 
         [0039]    At step  360 , if traffic from primary next hop P 1  arrives at PE router  240  prior to the expiry of the hold timer started at step  340 , then P 1  traffic is forwarded and P 2  traffic is dropped. 
         [0040]    At step  370 , if there is a selection (e.g., via IGP) of a new LFA path that is different than P 2 , then P 2  traffic is dropped. 
         [0041]    In the embodiments discussed herein, caching the secondary path UMH as a primary path UMH and starting the timer are performed in response to a detection of restoration of link L 1  (e.g., at step  340 ). In various other embodiments, one or both of caching the secondary path UMH as a primary path UMH and starting the timer may be performed in response to detecting a link L 1  error (e.g., at step  330 ). Additional timers may also be used within the context of the various embodiments. 
         [0042]    Thus, the method  300  of  FIG. 3  contemplates various embodiments which are invoked in response to a failure of a link L 1  while multicast traffic is arriving at the PE  240  via link L 2  from next hop P 2 . If link L 1  comes back up (restored), IGP will submit the unicast route with P 1  as the next hop. IGP has not computed the LFA path yet. In such a situation wherein the LFA path did not come in the unicast route, PIM caches the old primary next hop (P 2 ) and treats it as the LFA path. PIM s a hold-timer and hold this next hop till the hold-timer expires. PIM performs various protocol operations such as sending a join to the new next hop P 1 , as well as programming the forwarding entry of the forwarding table to send the first packet that arrives on link L 1  to the protocol. In addition, PIM also programs the forwarding plane to continue accepting traffic from next hop P 2 . When the traffic from primary next hop P 1  begins arriving at the PE  240 , PIM will take the action of reprogramming the forwarding plane entry to stop accepting traffic from the LFA next hop P 2  and only accept traffic from primary next hop P 1  on link L 1 . 
         [0043]    At a first time t1, in response to the primary path failure, PIM may perform the protocol operation of sending a join to the new next hop P 1 ; PIM will program the forwarding plane entry to send the first packet that arrives on link L 1  to the protocol (while continuing to accept traffic from next hop P 2 ). 
         [0044]    At a second time t2, in response to receiving traffic from restored primary next hop P 1 , PIM will reprogram the forwarding plane entry to stop accepting traffic from the LFA next hop P 2  and only accept traffic from primary next hop P 1  on link L 1 . 
         [0045]    Between the first time t1 and second time t2, several scenarios may occur, as noted below: 
         [0046]    In one scenario, where IGP is unable to calculate an LFA path, PIM will never hear from IGP. In this scenario, the hold-timer will expire and PIM will remove the cached next hop P 2 . If the traffic from P 1  was received before the hold-timer expiry, there will be no traffic loss. 
         [0047]    In another scenario, where IGP computes an LFA path that happens to be a path different than P 2 , PIM will remove P 2  and send a join to the new LFA path. If the traffic from P 1  was received before removing the LFA path P 2 , there will be no traffic loss. 
         [0048]    In still another scenario, which is also the most likely scenario, IGP finds P 2  as the new LFA path, and PIM disables the hold-timer and take no further action. There will be no traffic loss in this scenario as well. 
         [0049]      FIG. 4  depicts a high-level block diagram of a computing device, such as a processor in a telecom network element, suitable for use in performing functions described herein such as those associated with the various elements described herein with respect to the figures. 
         [0050]    As depicted in  FIG. 4 , computing device  400  includes a processor element  403  (e.g., a central processing unit (CPU) and/or other suitable processor(s)), a memory  404  (e.g., random access memory (RAM), read only memory (ROM), and the like), a cooperating module/process  405 , and various input/output devices  406  (e.g., a user input device (such as a keyboard, a keypad, a mouse, and the like), a user output device (such as a display, a speaker, and the like), an input port, an output port, a receiver, a transmitter, and storage devices (e.g., a persistent solid state drive, a hard disk drive, a compact disk drive, and the like)). 
         [0051]    It will be appreciated that the functions depicted and described herein may be implemented in hardware and/or in a combination of software and hardware, e.g., using a general purpose computer, one or more application specific integrated circuits (ASIC), and/or any other hardware equivalents. In one embodiment, the cooperating process  405  can be loaded into memory  404  and executed by processor  403  to implement the functions as discussed herein. Thus, cooperating process  405  (including associated data structures) can be stored on a computer readable storage medium, e.g., RAM memory, magnetic or optical drive or diskette, and the like. 
         [0052]    It will be appreciated that computing device  400  depicted in  FIG. 4  provides a general architecture and functionality suitable for implementing functional elements described herein or portions of the functional elements described herein. 
         [0053]    It is contemplated that some of the steps discussed herein may be implemented within hardware, for example, as circuitry that cooperates with the processor to perform various method steps. Portions of the functions/elements described herein may be implemented as a computer program product wherein computer instructions, when processed by a computing device, adapt the operation of the computing device such that the methods and/or techniques described herein are invoked or otherwise provided. Instructions for invoking the inventive methods may be stored in tangible and non-transitory computer readable medium such as fixed or removable media or memory, and/or stored within a memory within a computing device operating according to the instructions. 
         [0054]    Although various embodiments which incorporate the teachings of the present invention have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings. Thus, while the foregoing is directed to various embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. As such, the appropriate scope of the invention is to be determined according to the claims.