Abstract:
Technique for fast rerouting (FRR) of traffic in a communication network, from a working path comprising a link with its downstream node, to one or more backup paths concurrently providing link protection and node protection to the link and the downstream node; the method comprises enabling the downstream node to block forwarding of traffic, if received at the downstream node along the backup path(s), towards a more-down-stream node in the working path in case the more-down-stream node participates in providing node protection against a failure of the downstream node, the technique thereby prevents traffic duplication at the more-down-stream node and does not require distinguishing a link failure from a node failure.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to the field of data networking, more particularly to protecting logical paths in packet-switched communication networks, and specifically 
         [0002]    to providing fast reroute (FRR) protection concurrently against either link or node failures along such paths. 
         [0003]    The problem addressed by this invention is relevant for various types of networks and data protocols supporting fast reroute (FRR) protection; in the following description, for the sake of illustration, the inventive solution will be presented for multiprotocol label switching (MPLS) networks and for MPLS point to point and point-to-multipoint label switched paths. 
       BACKGROUND OF THE INVENTION 
     MPLS Technology 
       [0004]    MPLS is a new technology for fast delivery of packet-based traffic along pre-established logical paths called label switched paths (LSPs, a.k.a. tunnels). MPLS supports traffic engineering (TE) to optimize usage of network resources, and is designed to offer a reliable traffic delivery, with predictable quality of service (QoS) and guaranteed capacity (a.k.a., bandwidth). MPLS uses a notion called label to identify, classify and forward data over LSPs. 
         [0005]    A point-to-point (P2P) LSP delivers traffic from the access port(s) of a source (a.k.a., ingress) node (a.k.a., label switching router, LSR) downstream to the access port(s) of destination (a.k.a., egress) LSR. The LSP may traverse intermediate (a.k.a., transit) LSRs. Access ports can also be LSR-internal, i.e., the LSR can also generate traffic towards LSP. An LSR may serve as ingress node for one LSP and transit or egress for another. 
         [0006]      FIG. 1  illustrates a P2P LSP, that originates at ingress LSR 1 , traverses through transit LSR 2  (from port “a” to port “b”) and LSR 3 , and terminates at egress LSR 4 . The LSP path may be summarized as 1-2-3-4. 
         [0007]    A point-to-multipoint (P2MP) LSP delivers multicast traffic (such as IPTV) from ingress LSR (a.k.a., root) downstream to one or more egress LSRs (a.k.a., leaf, leaves). One example of P2MP LSP is shown in  FIG. 2 . It is a tree-and-branch structure, where traffic is replicated at transit branch points and then sent to the access port(s) at the leaves. This scheme is efficient in terms of link capacity consumption, as only one copy of the traffic is ever sent per branching link. Multiple copies (a.k.a., traffic duplication) per branch are forbidden, as they could crash the user application. 
         [0008]    With P2MP tunnels, any LSR may serve as both a transit and an egress (abbreviated transit&amp;leaf) LSR, in which case it forwards traffic both to its local access port(s), and to downstream LSRs. The point-to-point path to each specific leaf is called a sub-LSP. 
         [0009]      FIG. 2  illustrates a P2MP LSP. Multicast traffic gets on the LSP at a root LSR 1 , sent to a transit&amp;leaf LSR 2 , replicated towards a leaf LSR 3  and a transit LSR 4 . The traffic is forwarded by LSR 4  to a transit&amp;leaf LSR 5 , which in turn forwards it to a leaf LSR 6 . Each of the LSRs  2 ,  3 ,  5 ,  6  forwards the traffic also to the local access port(s). As illustrated by dotted lines, there are 4 sub-LSPs, with paths 1-2, 1-2-3, 1-2-4-5, and 1-2-4-5-6. 
         [0010]    Note that LSR 1  sends only one packet copy to LSR 2 , even though the link to LSR 2  carries 4 sub-LSPs. Similarly, LSR 2  sends one copy on the branch to LSR 3  and one copy on the branch to LSR 4 , even though the link to LSR 4  carries 2 sub-LSPs. 
         [0011]    Fast Reroute (FRR) and Point to Point (P2P) LSPs 
         [0012]    A major MPLS feature is the support of fast reroute (FRR). FRR is a mechanism for rapid traffic restoration upon a link or a node failure along the LSP path. With FRR, an interrupted traffic stream can be rerouted around a failed node/link within a time interval of sub-50 milliseconds, thereby minimizing impact on the traffic. 
         [0013]    The LSR upstream of the failure (a.k.a., point of local repair, PLR), redirects the traffic of the so-called working, LSP onto a pre-established (P2P) backup LSP (a.k.a., a bypass LSP), which reroutes around the failure. The backup LSP brings the traffic from the PLR to an LSR positioned downstream of the failure (a.k.a., a merge point, MP), after which the traffic returns to the working LSP. The MP is actually the egress LSR of the backup LSP. 
         [0014]    For the sake of simplicity, it will be assumed that the MP is the closest possible LSR downstream the failure point, counting from the PLR. Accordingly, with FRR link protection, the MP is PLR&#39;s next-hop (NHOP) LSR, i.e., the LSR at the far end of the protected link; in node protection the MP is PLR&#39;s next-next-hop (NNHOP) LSR, i.e. the LSR that is placed after the NHOP along the working LSP path (in a general case, it is not obligatory the neighbor of NHOP). The backup LSP may be capable of being shared, i.e. provide protection to multiple working LSPs, in which case it is known as Facility backup LSP. 
         [0015]    It will also be assumed that a failure of the protected link triggers both the link and the node protection mechanisms. This procedure is commonly in use and provides fast detection time, since the failure detection is based on rapid physical layer indications. Examples for such indications are: “loss of signal”, “signal quality degradation”, “remote alarm indication”. 
         [0016]    FRR protection should preferably be node protection FRR rather than link protection FRR, as the former provides better resiliency. The last hop of an LSP cannot be provided with node protection, i.e., no protection is possible when the egress LSR fails. A fully protected P2P LSP is a P2P LSP having assigned node protection at all its hops, except for the last hop, for which a link protection is assigned. 
         [0017]      FIG. 3  illustrates FRR configuration for the P2P working LSP of  FIG. 1 . This 
         [0018]    LSP is fully protected as follows: (1) B 1  (B 2 ) protects against the failure of LSR 2  (LSR 3 ), it originates at PLR LSR 1  (LSR 2 ) and terminates at NNHOP LSR 3  (LSR 4 ), respectively. The backup LSP path may include also transit LSRs, as illustrated for B 1  which traverses transit LSR 5  (2) Backup LSP B 3  protects against the failure of the link from LSR 3  to LSR 4 . It originates at PLR LSR 3  and terminates at MP NHOP LSR 4 . 
         [0019]    Node FRR Scenario: if LSR 2  (LSR 3 ) goes down, as detected by a Point of Local Repair LSR 1  (LSR 2 ) due to the failure of the outgoing link to LSR 2  (LSR 3 ), the PLR redirects the traffic to B 1  (B 2 ), that brings it to MP LSR 3  (LSR 4 ), respectively, after which the traffic returns to the working LSP. 
         [0020]    Link FRR Scenario: if the link LSR 3  to LSR 4  goes down, the PLR LSR 3  redirects the traffic to B 3 , that brings it to MP LSR 4 , after which the traffic is sent to the access port. 
         [0021]    Fast Reroute (FRR) and Point-to-Multipoint (P2MP) LSPs 
         [0022]    FRR is also applicable for a working P2MP LSP. To protect against a link failure, the PLR needs a single backup LSP towards NHOP. To fully protect a node, the PLR needs a backup LSP per NNHOP. When a backup LSP protects multiple sub-LSPs and FRR is activated, the PLR sends only one copy of the traffic over that backup LSP, thus avoiding traffic duplication. 
         [0023]    A fully protected sub-LSP is a sub-LSP assigned node protection at all hops, except for the last hop, for which it is assigned a link protection. A fully protected P2MP LSP is a P2MP LSP for which all the sub-LSPs are fully protected. 
         [0024]      FIG. 4 . illustrates FRR configuration for the working P2MP LSP of  FIG. 2 , wherein LSR 5  and LSR 6  of  FIG. 2  are removed and wherein LSR 4  becomes an egress LSR. FRR protection is organized as follows: (1) B 1  (B 2 ) protects against the failure of LSR 2 . It originates at PLR LSR 1 , traverses through a different network node marked LSR 6 , and terminates at NNHOP LSR 3  (LSR 4 ), respectively; (2) B 3  (B 4 ) protects against the failure of the link from LSR 2  to LSR 3  (LSR 4 ), it originates at PLR LSR 2  and terminates at MP NHOP LSR 3  (LSR 4 ), respectively. 
         [0025]    This working P2MP LSP is not fully protected because the sub-LSP to LSR 2  has no link protection at the last hop. 
         [0026]    Thus, if link LSR 1  to LSR 2  fails (LSR 2  stays up), no traffic will reach the access port of LSR 2 . 
         [0027]    Node FRR Scenario: if LSR 2  goes down, as detected by PLR LSR 1  via the failure of the link to LSR 2 , the PLR redirects the traffic to B 1  and B 2 , that brings it to MP LSR 3  and LSR 4 , respectively, after which the traffic is sent to the access ports. 
         [0028]    Link FRR Scenario: if the link LSR 2  to LSR 3  (LSR 4 ) goes down, PLR LSR 2  redirects the traffic to B 3  (B 4 ), that brings it to MP LSR 3  (LSR 4 ), after which the traffic is sent to the access ports. 
         [0029]    So far, backup LSPs were P2P LSPs. It is also possible to establish P2MP backup LSPs, as per draft-ietf-mpls-p2 mp-te-bypass-02.txt, to optimize protection bandwidth consumption. For example, in case of a node failure, the PLR would redirect the traffic onto a P2MP backup LSP, which would route a single traffic copy towards all NNHOPs. 
         [0030]      FIG. 5  illustrates FRR configuration for the working P2MP LSP of  FIG. 4 , with B 1  and B 2  replaced by P2MP backup LSP B 5 , to protect against the failure of LSR 2 . B 5  originates at PLR LSR 1 , traverses through LSR 6 , and terminates at NNHOPs LSR 3  and LSR 4 . The advantage of P2MP backup LSP is exemplified at link LSR 1  to LSR 6 , where B 5  consumes half as much protection bandwidth compared to the aggregated bandwidth of B 1  and B 2  of  FIG. 4 . 
         [0031]    This working P2MP LSP is not fully protected because the sub-LSP to LSR 2  has no link protection at the last hop. Thus, if link LSR 1  to LSR 2  fails (LSR 2  stays up), no traffic will reach the access port of LSR 2 . 
         [0032]    Node FRR Scenario: if LSR 2  goes down, as detected by PLR LSR 1  via (due to) the failure of the link to LSR 2 , the PLR redirects the traffic to B 5 , that brings it to MP LSR 3  and LSR 4 , after which the traffic returns to the working LSP. 
         [0033]    Link FRR Scenario: Same as for  FIG. 4 . 
         [0034]    Traffic Duplication Problem for FRR 
         [0035]    Assume that PLR has both the link and the node protection assigned towards the directly connected NHOP and NNHOP(s), respectively. Since it was assumed that FRR (both the link protection and the node protection mechanisms) is triggered based on link failure alone, this would result in the traffic duplication. This problem is referred hereafter as FRR duplication problem. 
         [0036]      FIG. 6 . illustrates a portion of a P2MP working LSP, flowing on path 1-2-3-4, where LSR 2  is a transit&amp;leaf node (it forwards traffic both to LSR 3  and to its own Access port). For this LSP to be fully protected, it ought to: (1) Protect transit&amp;leaf LSR 2 , e.g., via B 1 . This provides node protection for sub-LSPs whose LSR 2  is transit (2) Protect the link LSR 1  to LSR 2 , e.g., via B 2 . This provides link protection for the sub-LSP whose LSR 2  is leaf. 
         [0037]    Note that B 1  alone cannot make the LSP fully protected, because when the link LSR 1  to LSR 2  fails (and LSR 2  stays up), no traffic would reach the access port at LSR 2 . Likewise, B 2  alone is insufficient, being less resilient than the node protection. 
         [0038]    Case A: Link LSR 1  to LSR 2  goes down but LSR 2  stays up. Being unable to distinguish a link failure from a node failure, LSR 1  moves traffic to both B 1  and B 2 . LSR 3  receives two copies, one from LSR 2  and one from B 1 . 
         [0039]    Case B: P2P vs. P2MP Backup. The P2P backup LSPs may be replaced by P2MP backup LSP (not shown). This can improve the protection bandwidth efficiency, but the duplication problem will remain. 
         [0040]    Case C: Mixed Node and Link FRR. In the absence of node protection towards some of NNHOPs (if additional NNHOPs exist), they may benefit from link protection. The traffic duplication at LSR 3  remains. 
         [0041]    Case D: P2P vs. P2MP Working. The P2MP working LSP may be replaced by a P2P working LSP (say, there is no Access port in LSR 2 ). The problem of duplication remains. 
         [0042]    When summarizing the prevalence of the FRR duplication problem, one comes to a conclusion that it may occur invariably to P2P and P2MP working LSPs, with either P2P or P2MP backup LSPs. The main cause of traffic duplication is that PLR does not, based on the earlier assumption, distinguish a link failure from a node failure. 
         [0043]    A number of solutions have been proposed in the prior art to distinguish a link from a node failure, and thereby could avoid the described problem of traffic duplication. 
         [0044]    The PLR could implement mechanisms to distinguish between link and node failures. Upon link (node) failure, the PLR applies only link (node) protection, respectively, thus avoiding traffic duplication. Such an approach is classified as out of scope one in section 4.1.1 of draft-ietf-mpls-p2mp-te-bypass-02.txt: “The PLR needs to localize the failed elements in order to activate the P2MP Bypass Tunnel(s) protecting this element. Mechanisms through which this location is retrieved are out of the scope of this document.” 
         [0045]    A specific method for distinguishing a link failure from a node failure is proposed by draft-vasseur-mpls-linknode-failure-00.txt (also formulated in US2003233595). It is based on exchanging so-called “Hello” messages over an alternative path between the PLR and NHOP, for detecting when NHOP is not reachable. The author of that specific method proposes two schemes of behavior for the PLR upon link failure detection. Scheme 1, Step 1: assume a link failure occurred and switch traffic to the link protecting backup LSP. Step 2: if later it becomes clear (via Hellos) that the NHOP is down, move traffic to the node protecting backup LSP. Scheme 2, Step 1: assume a node failure occurred and switch traffic to the node protecting backup LSP. Step 2: if later it becomes clear (via Hellos) that the NHOP is up, move traffic to the link protecting backup LSP. 
         [0046]    The above method has the following disadvantages: (1) Performance: PLR and NHOP need to exchange Hello messages based on which a node failure is detected. These messages consume resources, and could create a performance burden on the PLR, especially if it has many protected links. (2) Detection Time: PLR should waist time for several Hello acknowledgements, plus a propagation delay from NHOP, before Step 2 can be executed. (3) Availability: A need for an alternate path to carry the Hellos between PLR and NHOP. Such a path is not always available. The backup LSP could carry the Hellos from PLR to NHOP but there is still a need for a path in the reverse direction. Such a complex backup path might also fail/not reliably deliver the Hellos, thereby causing false indications. 
         [0047]    A totally different approach is called for, i.e. an approach that would practically address the FRR duplication problem, while avoiding the potentially intolerable drawbacks discussed above. 
       OBJECT AND SUMMARY OF THE INVENTION 
       [0048]    The object of the present invention is to propose a fast reroute protection technique covering both link and node failures per hop along communication logical paths in general, and MPLS P2P and P2MP LSPs in particular. This method would address the FRR duplication problem while avoiding the disfavors of the prior art solutions. 
         [0049]    The Inventor&#39;s idea is to use backup LSP(s) to provide both link and node protection concurrently (thus initiating so-called Dual or concurrent FRR), while configuring a suitable blocking rule at the link protection merge point (the NHOP), to avoid traffic duplication that would otherwise occur with standard FRR. The proposed blocking rule says: prevent the traffic that arrives on a backup LSP participating in a Dual FRR backup configuration (hereafter and actually, on a dual FRR backup LSP), from forwarding it toward NNHOPs which are already protected against NHOP&#39;s failure. In other words, NHOP should not forward traffic, arriving via a Dual FRR backup LSP, to working sub-LSPs or P2P LSPs that are protected against NHOP&#39;s failure. 
         [0050]    The Dual FRR backup LSP(s) may comprise an ordinary backup LSP that provides at least link protection from PLR to NHOP. The ordinary backup LSP may either be P2P or P2MP backup LSP, where in the latter case it can also provide node protection. The concept of the invention has been described with reference to MPLS networks and using specific terms characteristic for indicating paths and nodes in such networks. However, the inventive method can be applied to other communication networks supporting fast reroute-like mechanisms, say to IP networks. 
         [0051]    Therefore, the general concept of the invention can be briefly defined as follows: 
         [0052]    A method for fast rerouting (FRR) of traffic in a communication network, from a working path comprising a link connecting a first node and a downstream second node, to one or more backup paths concurrently providing link protection and node protection to the link and the second node; the method comprises 
         [0000]    enabling the second node to block forwarding of traffic, if received at the second node along the backup path(s), towards a more-downstream third node in the working path in case the third node participates in providing node protection against a failure of the second node;
 
the method thereby prevents traffic duplication at the third node and does not require distinguishing a link failure from a node failure.
 
         [0053]    In MPLS networks, the working path is usually called a working LSP, the first node in the described concept can be called a point of local repair PLR, and the second downstream node can be called a next hop node NHOP. The farther downstream node(s) of the working path, including the third node, are usually called next-next hop nodes NNHOPs. Using these terms, the method can be then formulated more specifically. 
         [0054]    A method for fast rerouting of traffic (for example, by performing a Fast Reroute FRR mechanism) in a communication network (for example, in an MPLS network), from a working communication path (for example, a working LSP) comprising a first node (called a point of local repair PLR), a link connecting the first node and a second downstream node (called a net hop node NHOP), and one or more third nodes (called next-next hop nodes NNHOPs) positioned downstream to said second node along the working path; the method comprises: 
         [0055]    pre-provisioning of one or more point to point (P2P) or point to multipoint (P2MP) backup paths (such as backup LSPs) in the network, concurrently providing link protection against failure of said link and node protection against failure of said second node (NHOP), thereby ensuring so-called Dual (concurrent) FRR for said link and said second node; 
         [0056]    providing said second node (NHOP) with a blocking rule enabling to block forwarding of traffic, if received at NHOP via said one or more pre-provisioned backup paths (backup LSPs), towards a specific third node out of said one or more third nodes (NNHOPs) in case when said specific third node (NNHOP) participates in providing node protection to said second node (NHOP); the method thereby prevents traffic duplication at said third node (NNHOP) in case the traffic is rerouted by the first node (PLR) to the backup path(s), and does not require distinguishing a link failure from a node failure at the PLR or any other node. 
         [0057]    The blocking rule can be formulated in a different manner. Namely, the blocking rule 
         [0000]    a) blocks forwarding the traffic received at NHOP via said one or more backup paths, towards those third nodes NNHOPs out of said one or more third nodes, which participate in node protection to the NHOP for the particular working LSP, while
 
b) allows forwarding said traffic towards remaining third nodes out of said one or more third nodes NNHOPs, wherein the remaining third nodes do not participate in node protection to the NHOP for the particular working LSP.
 
         [0058]    In view of the above method, one pre-provisioned backup path (LSP) may provide the link protection while another pre-provisioned one may provide the node protection to achieve the Dual FRR for the link between the PLR and the NHOP and for the NHOP itself. Alternatively, one backup path (P2MP LSP) could provide both link and node protection concurrently. 
         [0059]    As has been mentioned above in the Summary, an ordinary backup LSP may either be P2P or P2MP backup LSP; in the latter case it can provide both the link and the node protection. 
         [0060]    There is further provided a management entity in a communication network, adapted to pre-provision one or more backup paths for a working path to provide concurrent link and node fast reroute protection of said working path, the management entity being also adapted to produce instructions and blocking rules for nodes of the network for implementing the proposed method. The entity can be a management system such as an element (node) management system, a network management system or a combination of the both. Instructions and blocking rules can be transmitted via a signaling protocol. 
         [0061]    According to a yet a further aspect of the invention, there is provided a network node comprising hardware and/or software means with modified functions which would enable operation of the network node as a modified PLR node or as a modified NHOP node of a working path, according to the new proposed technique and depending on a specific configuration of the working path. 
         [0062]    For example, the hardware/software means of the network node can be designed for: 
         [0063]    receiving management and/or signaling instructions, pre-provisioning concurrent FRR link and node protection backup paths, and setting flags to enable functioning of said network node as the PLR node; 
         [0064]    communicating with the PLR using management and/or signaling instructions, analyzing the flags, storing and implementing the blocking rule, thereby enabling functioning of said network node as the NHOP node. 
         [0065]    According to an additional aspect of the invention, there is also provided a software product comprising software implementable instructions and/or data for carrying out the above-described method. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0066]    The principle of the invention is described and illustrated with reference to the following non-limiting examples of MPLS network fragments, in which: 
           [0067]      FIG. 1  (prior art) schematically illustrates a point to point (P2P) working LSP. 
           [0068]      FIG. 2  (prior art) schematically illustrates a point to multipoint (P2MP) working LSP. 
           [0069]      FIG. 3  (prior art) schematically illustrates a PTP working LSP for which backup LSPs are pre-provisioned for possible Fast Reroute (FRR). 
           [0070]      FIG. 4  (prior art) schematically illustrates a P2MP working LSP for which backup LSPs are pre-provisioned for performing Fast Reroute (FRR). 
           [0071]      FIG. 5  (prior art) schematically illustrates a P2MP working LSP for which a P2MP 
           [0072]    Backup LSP is pre-provisioned for performing Fast Reroute (FRR). 
           [0073]      FIG. 6  (prior art) is one example schematically illustrating how a traffic duplication problem occurs when performing FRR while not distinguishing a link from a node failure. 
           [0074]      FIG. 7   a, b, c  are examples illustrating how the traffic duplication problem can be resolved by applying the proposed inventive method of Dual FRR to various combinations of working LSP and backup LSPs (P2P and P2MP). 
           [0075]      FIG. 8  is another example illustrating how the proposed Dual FRR principle can be applied to yet another combination of a working and backup LSPs. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0076]      FIG. 7   a  illustrates a Dual FRR configuration for the basic case of  FIG. 6 , where B 2  serves as a Dual FRR backup LSP whose egress LSR is NHOP. 
         [0077]    Link failure FRR Scenario (covers Case A mentioned in the description to  FIG. 6 ): If the protected link LSR 1  to LSR 2  goes down but LSR 2  stays up, PLR LSR 1  would switch traffic to both B 1  and B 2 , not distinguishing a link from a node failure. Traffic arriving on B 1  to NNHOP LSR 3  returns to the working LSP towards LSR 4 . 
         [0078]    When traffic arrives on B 2  to NHOP LSR 2  (B 2 &#39;s egress LSR), NHOP avoids forwarding traffic to NNHOP LSR 3 , as the latter is protected against the NHOP&#39;s failure, and sends it only to the access port of LSR 2 . In other words, NHOP avoids forwarding to sub-LSPs going in the direction of LSR 3 , as they have node protection at PLR LSR 1 . Thus, LSR 3  receives traffic only from B 1 , and duplication is avoided. 
         [0079]    Node failure FRR Scenario: If LSR 2  goes down, description is the same as above, except that NHOP is anyway down and cannot cause traffic duplication. 
         [0080]      FIG. 7   b  illustrates a Dual FRR configuration using a P2MP Dual FRR backup LSP B 3 , where NHOP and NNHOP serve as its leaf and transit&amp;leaf LSRs, respectively. 
         [0081]    Link failure FRR Scenario (covers Case A): If the protected link LSR 1  to LSR 2  goes down but LSR 2  stays up, PLR LSR 1  would switch traffic to B 3 , not distinguishing a link from a node failure. Traffic arriving on B 3  to NNHOP LSR 3  returns to the working LSP towards LSR 4 . Since NNHOP LSR 3  is a transit &amp; leaf LSR for B 3 , traffic also continues on B 3  towards LSR 2 . 
         [0082]    NHOP LSR 2  (B 3 &#39;s leaf) avoids forwarding traffic to NNHOP LSR 3 , as the latter is protected against the NHOP&#39;s failure, so NHOP sends the traffic only to the access port. In other words, NHOP avoids forwarding traffic to sub-LSPs going in the direction of LSR 3  as they have node protection assigned at PLR LSR 1  (say, PLR informs NHOP about that via signaling, or the blocking rule is manually configured on NHOP). Thus, LSR 3  receives traffic only from B 3 , and duplication is avoided. 
         [0083]    Node failure FRR Scenario: If LSR 2  goes down, description is the same as above, except that NHOP is anyway down and cannot cause traffic duplication. 
         [0084]      FIG. 7   c  illustrates an example of a Dual FRR configuration using a P2MP Dual FRR backup LSP B 4 , where both NHOP and NNHOP serve as its leaves. 
         [0085]    Link failure FRR Scenario (covers Case A): If the protected link LSR 1  to LSR 2  goes down but LSR 2  stays up, PLR LSR 1  would switch traffic to B 4 , which would deliver the traffic to both NNHOP LSR 3  and NHOP LSR 2 . Traffic arriving to NNHOP LSR 3  returns to the working LSP towards LSR 4 . 
         [0086]    NHOP LSR 2  (B 4 &#39;s leaf) avoids forwarding traffic to NNHOP LSR 3 , as the latter is protected against failure of the former, and sends the traffic only to the access port of LSR 2 . Thus, LSR 3  receives traffic only from B 4 , and duplication is avoided. 
         [0087]    Node failure FRR Scenario: If LSR 2  goes down, description is the same as above, except that NHOP is anyway down and cannot cause traffic duplication. 
         [0088]    Case D. The working LSP can lie referred to as P2P LSP if the access port at LSR 2  were removed (see a reservation in  FIG. 8   a ). Thus, traffic arriving to NHOP LSR 2  on B 2 , B 3  or B 4  (see  7   a ,  7   b ,  7   c  respectively) is just discarded, avoiding the traffic duplication at LSR 3 . 
         [0089]      FIG. 8  illustrates an advanced case of the Dual FRR. A portion of a P2MP LSP is flowing from LSR 1  to transit&amp;leaf LSR 2 , where traffic splits towards LSR 3 , LSR 4 , transit&amp;leaf LSR 5 , and LSR 6 . Traffic also continues from LSR 3 /LSR 5 /LSR 6  to LSR 7 /LSR 8 /LSR 9 , respectively. FRR protection is as follows: B 5  provides link protection towards LSR 2  and LSR 4  (how link protection is provided towards LSR 4  is described below) and node protection towards LSR 3 , LSR 5 , and LSR 6 . 
         [0090]    Link failure FRR Scenario (covers cases A,B,C): If the protected link LSR 1  to LSR 2  goes down but LSR 2  stays up, PLR LSR 1  would switch traffic to B 5 , not distinguishing a link from a node failure. Traffic arriving on B 5  to NNHOP LSR 3  (LSR 6 ) returns to the working LSP towards LSR 7  (LSR 9 ), respectively. Since LSR 6  is a transit&amp;leaf LSR for B 5 , traffic also continues on B 5  towards LSR 5 . 
         [0091]    Traffic arriving on B 5  to NNHOP LSR 5  is sent to the access port and also returns to the working LSP towards LSR 8 . Since NNHOP LSR 5  is a transit&amp;leaf LSR for B 5 , traffic also continues on B 5  towards LSR 2 . 
         [0092]    NHOP LSR 2  (B 5 &#39;s leaf) avoids forwarding traffic to NNHOPs LSR 3 /LSR 5 /LSR 6 , as they are protected against its failure, and sends it only to the Access port and LSR 4 . In other words, NHOP avoids forwarding to sub-LSPs going in the direction of LSR 3 /LSR 5 /LSR 6  as they have node protection (against failure of LSR 2 ), assigned at PLR LSR 1 . Thus, NNHOPs LSR 3 /LSR 5 /LSR 6  receive traffic only from B 5 , and the traffic duplication is avoided. Note that LSR 4  gets a copy of the traffic from LSR 2  (i.e., NHOP does not block forwarding to LSR 4  of the traffic received along B 5 , since LSR 4  is not protected against failure of LSR 2 ) and benefits from link protection, which would be impossible without the Dual FRR mechanism. 
         [0093]    Mixed P2P and P2MP Backup: P2P backup LSP B 6  could replace B 5  in providing FRR node protection towards NNHOP LSR 3 . Traffic arriving on B 6  to NNHOP LSR 3  returns to the working LSP towards LSR 7 , while NHOP LSR 2  avoids forwarding traffic to NNHOP LSR 3 , as LSR 3  is protected against LSR 2 &#39;s failure. 
         [0094]    Node failure FRR Scenario: If LSR 2  (NHOP) goes down, description is the same as above, except that NHOP is anyway down and cannot cause traffic duplication. NNHOP LSR 4  will not get a copy of the traffic, and this is normal because LSR 4  is originally not protected against the failure of LSR 2 . 
         [0095]    In the general case, the proposed method allows configuring a blocking rule for sub-LSPs of the working LSP (i.e., for branches of the main working LSP, see  FIG. 8  where traffic splits towards LSR 3 , LSR 4 , transit&amp;leaf LSR 5 , and LSR 6  being all NNHOP nodes). For the working sub-LSPs, having the assigned node protection by ordinary or dual FRR backup LSPs, this blocking rule will prevent duplication of the traffic, when PLR applies the concurrent link and node FRR. 
         [0000]    In particular, the blocking rule at NHOP can be applied only to sub-LSPs which have the assigned node protection at PLR, while not applying the blocking rule to other sub-LSPs which thus can benefit from link protection when the link from PLR to NHOP fails. The method thereby allows supporting concurrent link and node protection on per LSP basis. 
         [0096]    As can be seen from the above two exemplary embodiments, the proposed invention meets its objectives. It resolves the FRR duplication problem while eliminating the prior art disadvantages: (1) Performance: No need for Hello exchange to detect a node failure; as the PLR does not distinguish between link and node failures (2) Detection Time: PLR triggers link and node FRR upon link failure, this can be done very fast based on physical layer indications (3) Availability: no need for an alternate path, as there, are no Hellos to exchange. 
         [0000]    Realization. The Dual FRR method can be implemented by either static or dynamic provisioning. The static provisioning could be achieved using either central and/or local management entity. The Dual FRR configuration implementation could include: 
         [0097]    (a) Dual FRR flag per backup LSP hop: enabled at NHOP for any Dual FRR backup LSP protecting the link from PLR to NHOP. 
         [0098]    (b) Dual FRR flag per working sub-LSP (or P2P LSP) hop: enabled at NHOP for any working sub-LSP (or P2P LSP) which is protected at PLR against NHOP&#39;s failure. 
         [0099]    NHOP then applies the blocking rule when both (a) and (b) are enabled, i.e., when traffic whose Dual FRR flag is enabled according to rule (b) is received on backup LSP whose Dual FRR flag is enabled according to rule (a). 
         [0100]    The dynamic provisioning can be achieved via MPLS signaling protocol such as RSVP (French title of the protocol, that translates “Please Respond”). For instance: 
         [0101]    (1) Dual FRR flag per backup LSP: may be indicated by PLR via a dedicated RSVP object or flag. The flag will be read (recognized) by the NHOP and used accordingly. 
         [0102]    (2) Dual FRR flag per working sub-LSP: may be based on the so-called Record Route object, with which PLRS indicate that a sub-LSP has assignment for node protection. Thus, if a sub-LSP has node protection at PLR, NHOP would enable the Dual FRR flag. 
         [0103]    The blocking rule would then be applied similarly to the static provisioning. 
         [0104]    The mentioned flags are “put on” or “enabled” at the NHOP owing to information obtained from the PLR, thus allowing the NHOP to analyze the flags and make the blocking decision. 
         [0105]    Each node should be provided with local software and/or hardware means for executing instructions including the blocking rule and the abovementioned flags, which are set on or off based on a configuration received via static and/or signaling-based mechanisms. 
         [0106]    It should be appreciated that other combinations of working and backup paths can be created in a practical network being an MPLS or a non-MPLS one, and that other practical implementations can be proposed for realizing the proposed concept of avoiding traffic duplication when utilizing the FRR mechanism.