CN103891215B - Fault detect in the end-to-end protection solution of multiprotocol label switching multicast label switched path - Google Patents

Abstract

In one aspect, the invention includes, in a root node on a label switched path, a computer program product comprising computer-executable instructions stored on a non-transitory medium, when executed by a processor, the root The node performs the following operations: together with at least one leaf node, it creates a fault detection session based on the first data plane with an inactive state on the first label switched path (LSP), and receives a predetermined number of notification messages from the leaf node , wherein the predetermined number of notification messages indicates that, when the second processor sends to the leaf node, a failure of the fault detection session based on the second data plane on the second LSP occurs; and upon receiving the predetermined number of notification messages After receiving the message, change the state of the fault detection session based on the first data plane occurring on the first LSP to inactive.

Description

Fault Detection in End-to-End Protection Solutions for Multiprotocol Label Switching and Multicast Label Switching Paths

Related Applications Cross Application

This application claims prior application to U.S. Provisional Application No. 61/545,897, filed October 11, 2011, entitled "Fault Detection in an End-to-End Protection Solution for Multiprotocol Label Switching Multicast Label Switching Paths" Priority, the contents of these earlier applications are incorporated herein by reference in their entirety.

Background technique

Point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) label-switched paths can be created in the network using the Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP). The set of LDP extensions used to create P2MP or MP2MP LSPs may be referred to as Multipoint LDP (mLDP), which is described in the Internet Engineering Task Force (IETF) titled "Label Distribution Protocol for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths". Extensions" are described in Request for Comments (RFC) 6388, the contents of which are incorporated herein by reference. Certain upstream label allocation (ULA) techniques are described in IETF RFC6389 entitled "MPLS Upstream Label Assignment for LDP", the contents of which are incorporated herein by reference.

Service providers continue to deploy real-time multicast applications in MPLS networks using mLDP. Clearly, there is a need to protect these real-time applications and minimize switchover time in the event of a failure. Current practices for securing business and advanced applications include precomputing and creating backup paths. Under this approach, once a failure is detected on the primary path, the control plane should be used to reroute traffic to the backup path. However, when a node on the first P2MP LSP fails, the delay for the second external network or client to determine the failure and switch to the second egress node receiving traffic may be longer. This delay may be unacceptable in some systems, for example, for real-time services such as Internet Protocol (IP) Television (IPTV).

Contents of the invention

In one aspect, the invention includes a computer program product in a root node on a secondary label switched path, comprising computer-executable instructions stored on a non-transitory medium, when executed by a processor, the root The node performs the following operations: together with at least one leaf node, creates a first data plane-based fault detection session with an inactive state on the first label switched path (LSP); receives a predetermined number of notification messages from the leaf node , wherein the predetermined number of notification messages indicates that, when the second processor sends to the leaf node, a failure of the fault detection session based on the second data plane on the second LSP occurs; and upon receiving the predetermined number of notification messages After receiving the message, change the state of the fault detection session based on the first data plane occurring on the first LSP to active.

In another aspect, the present invention includes that, in a leaf node of a network including a plurality of label switched paths, a network component includes a processor for creating a first label switched path ( A fault detection session based on the first data plane on the LSP), wherein the fault detection session based on the first data plane has an active state and is used to create a fault detection session based on the second data that occurs on the second LSP together with the second head node A fault detection session for a plane, wherein the fault detection session based on the second data plane has an inactive state; and after a trigger event occurs, a notification message is sent to the second head node, wherein the notification message indicates that the fault occurred at the Transmission failure on an LSP.

In yet another aspect, the present invention includes a method in a network system comprising a plurality of label switched paths having at least one leaf node, the method for switching a first LSP to a second LSP following a failure in a first LSP The transmission of the LSP includes: creating a first LSP, creating a fault detection session based on a first data plane between a first head node on the first LSP and at least one leaf node, wherein the fault detection based on a data plane A session message indicating that the first LSP is active; creating a second LSP; receiving an indication indicating that the first LSP has failed, wherein the indication includes not receiving at least one data plane-based message from the first head node a failure detection session message; and sending a notification message from the leaf node to a second head node indicating that the first LSP has failed.

These and other features will be more clearly understood from the following detailed description, taken in conjunction with the accompanying drawings and claims.

Description of drawings

For a more complete understanding of the present invention, reference is now made to the following brief description taken in conjunction with the drawings and detailed description, wherein like reference numerals refer to like parts.

Figure 1 depicts a schematic diagram of an embodiment of a label switching system;

Figure 2 depicts a flowchart of an embodiment of a fault detection method in an end-to-end protection solution for MPLS multicast LSP (mLSP);

Figure 3 depicts an embodiment of an example network prior to failure of the head node on the primary LSP;

Figure 4 depicts an embodiment of an example network when a master node on a master LSP fails;

Figure 5 depicts an embodiment of an example network following a failure of a primary node on a primary LSP;

FIG. 6 depicts a typical general-purpose network component suitable for implementing one or more embodiments of the disclosed components.

detailed description

It should be understood at the outset that although an exemplary implementation of one or more embodiments is provided below, the systems and/or methods disclosed herein may be implemented by various other known or existing techniques. The invention should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be limited within the scope of the appended claims and their equivalents. Modify within the complete scope of the object.

The current control-plane-based signaling mechanisms for fault detection are complex and slow, typically taking about a second to perform fault detection. The present invention introduces a simple and fast signaling mechanism based on the data plane between the head node and the tail end node of the multicast LSP. The working of the mechanism of the present invention is similar to a heartbeat, for example, pulse detection information for the master LSP and the slave LSP from the head node to the leaf node. When the heartbeat of the main LSP is interrupted, the system can send a notification to the tree head of the backup LSP, and the backup traffic forwarding can be started through the backup LSP. Once the tail-end node receives the backup traffic on the backup LSP, the tail-end node may notify the head node of the failed former primary LSP that the switchover has occurred. When the head node of the primary LSP before the failure occurs receives the switchover notification, it stops forwarding traffic along the previous primary LSP, thereby completing the switchover. The data plane based signaling mechanism can also indicate the number of failed leaves on the main tree.

Figure 1 depicts an embodiment of a label switching system 100 in which multiple P2P LSPs and P2MP LSPs can be created between at least some components. The P2P LSP and P2MP LSP can be used to transmit data traffic, such as routing using packets and packet labels. The label switching system 100 may include a label switching network 101, which may be a packet switching network using packets or frames for data transmission along network paths or routes. The packet can be routed or switched along the path, creating a label switching protocol such as MPLS or Generalized MPLS (GMPLS).

The label switching network 101 may include a plurality of edge nodes, and the plurality of edge nodes include a first ingress node 111 , a second ingress node 112 , a plurality of first egress nodes 121 and a plurality of second egress nodes 122 . When the P2MP LSP in the label switching network 101 includes ingress and egress edge nodes, the first ingress node 111 and the second ingress node 112 may be called root nodes or head nodes, and the first egress node 121 and the second egress node 122 may be called It is a leaf node or a tail node. In addition, the label switching network 101 may include a plurality of internal nodes 130, and the internal nodes may communicate with each other or with edge nodes. Additionally, the first ingress node 111 and the second ingress node 112 may communicate with a source node 145 in a first external network 140 , such as an Internet Protocol (IP) network, which may be coupled to the label switched network 101 . Additionally, the first egress node 121 and the second egress node 122 may communicate with a destination node 150 or other network 160 . In this way, the first ingress node 111 and the second ingress node 112 can transmit data, such as data packets, from the external network 140 to the destination node 150 .

In one embodiment, edge nodes and internal nodes 130 (collectively referred to as network nodes) may be any device or component that supports packet transmission over label switching network 101 . For example, the network nodes include switches, routers, or various combinations of such devices. Each network node may include a receiver for receiving packets from other network nodes, a processor or other logic for determining which network nodes to send those packets to, and a transmitter for transmitting those packets to the other network nodes . In some embodiments, at least some of the network nodes may be LSRs that may be used to modify or update labels of packets transmitted in the label switched network 101 . Further, at least some of the edge nodes may be label edge routers (LERs), which may be used to insert or remove labels of packets transmitted between the label switching network 101 and the external network 140 .

Label switched network 101 may include a first P2MP LSP 105 that may be created to multicast data traffic from first external network 140 to destination node 150 or other network 160 . The first P2MP LSP 105 may include a first ingress node 111 and at least some first egress nodes 121 . The first P2MP LSP 105 is shown in FIG. 1 by a solid arrowed line. Generally, to protect the first P2MP LSP 105 against link or node failure, the label switching network 101 may include a second P2MP LSP 106 , and the P2MP LSP 106 may include a second ingress node 112 and at least some second egress nodes 122 . The second P2MP LSP 106 is shown in FIG. 1 by a dashed arrowed line. Each second egress node 122 may be paired with the first egress node 121 in the first P2MP LSP 105 . The second P2MP LSP 106 also includes some of the same or completely different internal nodes 130 . The second P2MP LSP106 can provide a backup path leading to the first P2MP LSP105, which can be used to forward traffic from the first external network 140 to the first P2MP LSP105 or the second P2MP LSP106 when a network component of the P2MP LSP105 fails, such as forwarded to the egress node 123.

When a component of a P2MP LSP 105 fails, rerouting traffic via the corresponding second P2MP LSP 106 may result in delays in traffic delivery. Even when the traffic carried by the second P2MP LSP 106 is the same as that of the first P2MP LSP 105, when a network component of the first P2MP LSP 105 fails, the first P2MP LSP 105 or the second P2MP LSP 106 is used to determine the failure and switch to the backup of the transport traffic The latency of the path may be longer. In some systems this delay may be unacceptable, eg for real-time services such as IPTV.

Fig. 2 depicts a flowchart of an embodiment of a fault detection method in an end-to-end protection solution of MPLS mLSP. Process 200 may begin at 201 by creating master and slave LSPs. For example, the first ingress node 111 in FIG. 1 can create a first P2MP LSP 105 between the first ingress node 111 and the egress node 123, and the second ingress node 112 can create a P2MP LSP between the second ingress node 112 and the egress node 123. Second P2MP LSP 106.

As shown in 203, a data plane-based fault detection session, which is also referred to as a heartbeat herein, may be created on LSP1 and LSP2. A data plane based fault detection session may include multiple messages transmitted at predetermined time intervals to (a) inform downstream nodes which LSP is active and/or primary and (b) verify path continuity. In one embodiment, the data plane-based fault detection sessions of LSP1 and LSP2 may include two separate unidirectional fault detection (UFD) sessions with control message tags set to active and inactive, respectively. UFD is a subset of the Bidirectional Forwarding Detection (BFD) protocol used to detect MPLS LSP data plane failures, and can generally utilize the same protocol as traditional BFD. Design BFD for the exit node (for example, the first entry node 111 in Figure 1) to detect the disconnection of the exit node (for example, the exit node 123 in Figure 1), and provide the entry node with some optional mechanisms to track connectivity. Under the UFD protocol, the ingress node does not need or receive a response message. The BFD and UFD protocols are known in the prior art, additional information for which is taken from IETF RFC5880 entitled "Bidirectional Forwarding Detection (BFD)", the content of which is incorporated herein by reference.

LSP1 and LSP2 can be created independently or simultaneously in a certain order. Once the relevant LSPs are created, LSP heartbeats can also be created individually or simultaneously in any order, which is the UFD session in the embodiment of FIG. 2 . For example, in another embodiment, the heartbeat of LSP2 is not created until a failure of LSP1 is detected. When the heartbeat of LSP2 is established, one or more leaf nodes can receive heartbeats from LSP1 and LSP2. For example, in FIG. 1 , the egress node 123 may receive a heartbeat from the first ingress node 111 on the first LSP 105 , and may also receive a heartbeat from the second ingress node 112 on the second LSP 106 .

By using a data plane based fault detection session protocol, leaf nodes in the system can be used to expect to receive periodic heartbeats from the root node of the LSP. A leaf node may detect failure by not receiving a predetermined number of expected heartbeats from the root node.

As shown in 205, after the failure detection, the leaf node may send a traffic failure notification on LSP1 to the root node of LSP2. For example, in FIG. 1 , if egress node 123 detects a heartbeat interruption from first ingress node 111 on first LSP 105 , egress node 123 may send a traffic failure notification to second ingress node 112 . As shown in 207, after receiving the traffic failure notification on LSP1, the root node of LSP2 may start to forward the traffic on LSP2 to the leaf node and set the state of the related heartbeat to active. For example, in FIG. 1, if the second ingress node 112 receives a traffic failure notification on the LSP 105 from the egress node 123, the second ingress node 112 may send its own The UFD tag is set to active. As shown in 209, when the leaf node detects that the heartbeat state on the secondary LSP changes, the leaf node can ignore the traffic from LSP1 and can notify the root node of LSP1 that LSP1 fails and the traffic is forwarded to LSP2. For example, in FIG. 1 , if the egress node 123 detects that the UFD tag of the second ingress node 112 changes from inactive to active, the egress node 123 may send a switching notification to the first ingress node 111 . As shown in 211, after receiving the notification, the root node of LSP1 may set its heartbeat status to inactive and stop forwarding traffic to the leaf nodes, thereby completing the switchover. For example, in FIG. 1 , if the first ingress node 111 receives a handover notification from the egress node 123 , the first ingress node 111 may set its UFD label inactive for transmission on the LSP 105 .

Figures 3, 4 and 5 depict one embodiment of an example network before, during and after failure of the head node on the primary LSP. The networks shown in FIGS. 3-5 may be similar to the network shown in FIG. 1 . The tree of FIG. 3 starts with an external transmission source 300 , for example an IPTV input, which can be used to transmit data through an ingress node 302 . Ingress node 302 may divide the data into two paths. The main path, LSP 1340 can start from the root 304 (PE1) (also referred to herein as the head node, root node or tree head), and can transmit data to the leaf node 310 (PE2 , PE3, PE4, and PE5), this article also becomes the end node. A slave path, LSP 2350 , may start from root 314 (PE1') and may be used to transmit data to leaf nodes 310 (PE2, PE3, PE4, and PE5) through nodes 316 (P3) and 318 (P4). The leaf nodes 310 (PE2, PE3, PE4, and PE5) may serve as egress nodes, eg, transmit data to an external transmission destination 320 that may be output as IPTV. As shown, the network nodes contained within LSP1 340 and LSP2 350 may be distinct and disjoint from each other. Likewise, LSP1340 and LSP2350, but not both at the same time, generally transmit data to the external transmission destination 320 . In Figure 3-5, LSP1340 is the active LSP, and LSP2350 is the backup LSP. FIG. 4 depicts the embodiment of FIG. 3 in which root 304 fails. FIG. 5 depicts the embodiment of FIG. 4 switching to the LSP2350. In Figure 5, root 314 (PE1') is the head node of the new primary LSP 2350 as described below.

Referring to Figures 3-5, operation of the system may begin with tree heads 304 and 314 creating LSPs and data plane based fault detection sessions, also known as heartbeats, between head nodes 304, 314 and leaf nodes 310. In the embodiments of Figures 3-5, the heartbeat is a UFD session, but other data plane-based fault detection session protocols are allowed. Once heartbeats are transmitted on LSP1 340 and LSP2 350 , the head nodes 304 and 314 can simultaneously send heartbeats to the leaf node 310 continuously, and the leaf node 310 may receive the heartbeats sent by the head nodes 304 and 314 continuously. The root 304 (PE1) can transmit heartbeats in an active state, for example, by sending a UFD message to the leaf node 310 together with an active label set on the LSP 1340 . The root 314 (PE1') can send a heartbeat in an inactive state, for example, by sending a UFD message to the leaf node 310 together with the inactive label set on the LSP2350. Blocks 201 and 203 in the figure generally describe these operations.

If internal node 306 (P1) fails, as depicted in FIG. 4, leaf node 310 may not receive UFD messages from tree head 304 (PE1). When the leaf node 310 does not receive a predetermined number of UFD messages during the UFD session, the leaf node 310 may classify the non-reception as a path failure and send a notification message to the tree head, whose UFD messages are still received by the leaf node 310 . Block 205 in FIG. 2 generally describes this operation. The number of unreceived UFD messages required to trigger a notification message can be selected according to the required system sensitivity, which is also determined by demand. Sensitive systems may be at risk of sending false notifications. A less sensitive system could lead to a risk of lagging failure response times. In one embodiment, a single unreceived UFD message at a single leaf node 310 may trigger a notification message; in another embodiment, 2-10 unreceived UFD messages may be required. In other embodiments, more than 10 unreceived UFD messages at the leaf node 310 may be required to trigger sending of the notification message.

When the root 314 (PE1') receives a predetermined number of notification messages from the leaf nodes 310, the root 314 (PE1') may start forwarding traffic. The number of notification messages required to trigger traffic forwarding can be selected based on the desired system sensitivity, which is also determined by requirements. Sensitive systems may be at risk of starting traffic forwarding on false notification messages. Less sensitive systems risk additional response time lags. In one embodiment, a single notification message may trigger forwarding, while in another embodiment, 2-10 notification messages may be required. In other embodiments, more than 10 notification messages from leaf nodes 310 are required to trigger traffic forwarding. Other embodiments may require at least one notification message from two or more leaf nodes 310 . The root 314 (PE1') can start forwarding by sending a UFD message with an active label on the LSP2 350 to the leaf node 310. Block 207 in Figure 2 generally describes these operations. Once root 314 (PE1') starts forwarding on LSP2 350 and leaf node 310 detects LSP2350 heartbeat state from inactive to active, any leaf node 310 still receiving traffic from LSP1340 can discard packets from LSP1340 and utilize the packet from LSP2350 Bag.

Once the leaf node 310 receives the heartbeat from inactive to active on the LSP2 350 , the leaf node 310 may send a notification message to the previously active head node, ie, the root 304 (PE1) where the switchover occurred. Block 209 in FIG. 2 generally describes the operation of detecting a heartbeat state change on a previously inactive LSP and sending a handover notification to the root node of the previously active LSP. Once triggered, for example, the leaf node 310 sends a notification of a switching message, the root 304 (PE1) will stop forwarding traffic on the LSP1340, and change the state of the heartbeat of the LSP1340 to inactive. Block 211 in FIG. 2 generally describes these operations. In one embodiment, a single handover notification message received by root 304 (PE1) may trigger stop forwarding, while in another embodiment, 2-10 handover notification messages may be required. In other embodiments, more than 10 notification messages from leaf nodes 310 are required to stop traffic forwarding. Other embodiments may require at least one notification message from two or more leaf nodes 310 .

Because the solution leverages the data plane rather than the control plane, fault recovery times can be measured in milliseconds rather than seconds. The fault recovery time under the present invention may depend on several factors, including but not limited to, the cycle of UFD messages, the cycle number of unreceived UFD messages required to trigger leaf nodes to issue notifications, and the transmission traffic of triggering backup LSP head nodes to proceed The number of leaf node notifications required to change, the number of nodes required to provide notifications to trigger the transmission traffic of the backup LSP head node to change, the time to receive the UFD message sent by the backup LSP head node with the updated status label, and trigger the handover message Informs the number of such UFD messages required, and the time required to receive the handover message at the primary LSP head node and to complete the handover. The fault repair time can be adjusted arbitrarily according to the needs of the application. Where a faster fault repair time is desired, the fault repair time may be less than about 200 milliseconds, less than about 100 milliseconds, or less than about 10 milliseconds. In the case where the priority of fault detection accuracy is relatively high, a longer fault repair time may be allowed to obtain multiple fault indications. False error messages and frequent switchovers are acceptable in situations where failure recovery time is a high priority.

The network components described above may be implemented on any general-purpose network components, such as those described in FIGS. 1 and 3-5, that have sufficient processing power, storage resources, and network throughput capabilities to handle the necessary workload thereon. FIG. 6 illustrates a typical general-purpose network component 1000 suitable for implementing one or more embodiments of the components disclosed herein. Network component 1000 includes a processor 1002 (which may be referred to as a central processing unit or CPU) in communication with storage devices including: secondary storage 1004, read only memory (ROM) 1006, random access memory ( RAM) 1008 , input/output (I/O) devices 1010 , and network connection devices 1012 . Processor 1002 may be implemented as one or more CPU chips, or may be part of one or more application specific integrated circuits (ASICs) and/or digital signal processors (DSPs).

Secondary storage device 1004 typically consists of one or more disk drives or erasable programmable ROM (EPROM) and is used for non-volatile storage of data. Secondary storage 1004 may be used to store programs that are loaded into RAM 1008 when those programs are selected for execution. ROM 1006 is used to store instructions and possibly data that are read during program execution. ROM 1006 is a non-volatile storage device that typically has a small storage capacity relative to the larger storage capacity of secondary storage 1004 . RAM 1008 is used to store volatile data and possibly to store instructions. Both ROM 1006 and RAM 1008 typically have faster access speeds than secondary storage 1004 .

The present invention discloses at least one embodiment, and changes, combinations and/or modifications made by persons of ordinary skill in the art to the embodiments and/or the features of the embodiments are within the scope of the present disclosure. Alternative embodiments resulting from combining, combining, and/or omitting features of the described embodiments are also within the scope of the invention. It should be understood that the present invention has explicitly set forth numerical ranges or limitations, and such explicit ranges or limitations should be included within the above ranges or limitations (such as from about 1 to about 10 including 2, 3, 4, etc.; greater than A range of 0.10 includes iteration ranges or limits of similar magnitude within 0.11, 0.12, 0.13, etc.). For example, whenever a numerical range having a lower limit R1 and an upper limit Ru is disclosed, any number falling within the range is specifically disclosed. Specifically, the following numbers within the stated range are specifically disclosed: R=Rl+k*(Ru-Rl), where k is a variable from 1% to 100% in 1% increments, i.e., k is 1% , 2%, 3%, 4%, 5%, ..., 50%, 51%, 52%, ..., 95%, 96%, 97%, 98%, 99% or 100%. Furthermore, any numerical range defined by the two R values defined above is also hereby disclosed. Unless otherwise stated, the term "about" indicates a range of ±10% of the numerical value that follows. The use of the term "optional" with respect to an element of a claim indicates that the element may be "required" or "not required", both of which are within the scope of the claim. The use of broader terms such as "comprising", "comprising" and having "should be understood as providing support for narrower terms such as "consisting of", "consisting essentially of" and "consisting substantially of" . Accordingly, the scope of protection is not limited by the foregoing description but is defined by the claims that follow, that scope including all equivalents of the subject matter of the claims. Each and every claim is incorporated into the specification as a further disclosure, and the claims are embodiments of the invention. The discussion of a reference in this disclosure is not an admission that it is prior art, especially any reference with a publication date after the priority date of this application's earlier filing. The disclosures of all patents, patent applications, and publications cited in this application are hereby incorporated by reference herein, providing exemplary, procedural, or other details supplementary to the present invention.

Although several embodiments have been provided herein, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the invention. The examples of the invention are to be regarded as illustrative rather than restrictive, and the invention is not limited to the details given in this text. For example, various elements or components may be combined or incorporated in another system, or certain features may be omitted or not implemented.

Furthermore, techniques, systems, subsystems and methods described and illustrated in various embodiments as discrete or separate may be combined or merged with other systems, modules, techniques or methods without departing from the scope of the present invention. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Examples of other changes, substitutions, and changes can be ascertained by those skilled in the art without departing from the spirit and scope of the disclosure herein.

Claims (20)

1. A method for fault detection in the root node on the second label switched path LSP, the root node on the second LSP performs the following operations: creating a fault detection session based on the second data plane with an inactive state occurring on the second LSP with at least one leaf node; receiving a predetermined number of notification messages from the leaf node, wherein the predetermined number of notification messages indicate that when the root node on the first LSP sends to the leaf node, the first data plane-based failure of the failure detection session; and After receiving the predetermined number of notification messages, changing the state of the fault detection session based on the second data plane occurring on the second LSP to active. 2. The method according to claim 1, wherein the fault detection session based on the second data plane is a unidirectional fault detection UFD session. 3. The method according to claim 1, wherein the predetermined number of notification messages is 1 to 10. 4. The method of claim 1, wherein the time between receiving the first notification message of the predetermined number of notification messages and changing state is less than 200 milliseconds. 5. In a leaf node of a network including multiple label switched paths, a network component comprising: A processor for: creating, together with the first head node, a first data plane-based fault detection session that occurs on the first label switched path LSP, wherein the first data plane-based fault detection session indicates an activation state of the first LSP; creating a second data plane based failure detection session with a second head node on a second LSP, wherein the second data plane based failure detection session indicates an inactive state of the second LSP; and Sending a notification message to the second head node after the triggering event occurs, wherein the notification message indicates a transmission failure occurring on the first LSP. 6. The network component of claim 5, wherein the processor is further configured to receive a status update on the second data plane based fault detection session updating the status of the second LSP to active. 7. The network component according to claim 6, wherein the processor is further configured to send a handover status message to the first head node indicating a status change of the second LSP. 8. The network component of claim 7, wherein the processor is further configured to receive a handover update updating the status of the first LSP to inactive. 9. The network component of claim 6, wherein the processor is further configured to ignore traffic of the first LSP after receiving a status update. 10. The network component of claim 6, wherein the processor is further configured to send additional notification messages after a trigger event at predetermined intervals until a status update is received. 11. The network component according to claim 5, wherein the fault detection session based on the first and second data planes is a unidirectional fault detection UFD session. 12. The network component according to claim 11, wherein the trigger event is not receiving a predetermined number of UFD messages on the first LSP after the creation of the fault detection session of the first data plane. 13. The network component of claim 12, wherein the predetermined number is from 1 to 10. 14. In a network system comprising a plurality of label switched paths with at least one leaf node, a method for switching transmission from a first LSP to a second LSP after a failure occurs in a first label switched path LSP, characterized in In, including: creating said first LSP; A fault detection session based on the first data plane is established between the first head node on the first LSP and the at least one leaf node, wherein the fault detection session message based on the first data plane indicates that the first LSP is active; creating said second LSP; receiving an indication that the first LSP has failed, wherein the indication includes not receiving at least one of the first data plane-based failure detection session messages from the first head node; and sending a notification message from the at least one leaf node to a second head node on the second LSP indicating that the first LSP has failed. 15. The method according to claim 14, further comprising creating a fault detection session based on a second data plane between a second head node on the second LSP and the at least one leaf node, wherein The second data plane-based fault detection session message indicates that the second LSP is inactive. 16. The method of claim 15, further comprising: forwarding traffic along the second LSP in response to the notification message from the leaf node; and sending the second data plane based failure detection session message indicating that the second LSP is active in response to the notification message from the leaf node. 17. The method according to claim 16, further comprising sending a handover notification message to the first head node indicating that the handover occurs after the fault detection based on the first data plane. 18. The method according to claim 17, further comprising sending the first data plane-based fault detection session message indicating that the first LSP is inactive. 19. The method of claim 16, wherein the time between sending a notification message and sending the second data plane based fault detection session message indicating that the second LSP is active is less than 200 milliseconds. 20. The method according to claim 14, further comprising sending a notification message to the first head node indicating that handover has occurred.