WO2020210844A1

WO2020210844A1 - Preferred path routing fast reroute use of segment routing header

Info

Publication number: WO2020210844A1
Application number: PCT/US2020/038857
Authority: WO
Inventors: Stewart Bryant; Uma S. Chunduri; Toerless Eckert
Original assignee: Futurewei Technologies, Inc.
Priority date: 2019-06-20
Filing date: 2020-06-20
Publication date: 2020-10-15

Abstract

A method performed by a network element (NE) comprises detecting a failure in the first preferred path route (PPR); receiving a data packet, wherein the data packet comprises a first PPR identifier (PPR-ID) indicating the first PPR in an Internet Protocol (IP) header of the data packet; in response to detecting the failure: adding a fast reroute routing header (FRRH) to the data packet; transferring the first PPR identifier (PPR-ID) from the IP header of the data packet to the FRRH; updating the IP header of the data packet to include a second PPR-ID; and forwarding the data packet with the FRRH on a reroute path according to the second PPR-ID.

Description

Preferred Path Routing Fast Reroute Use of Segment Routing Header

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of U.S. Provisional Patent Application No. 62/864,301 filed June 20, 2019 by Stewart Bryant, et al ., and entitled“Preferred Path Routing Fast Reroute Use Of Segment Routing Header,” which is hereby incorporated by reference.

FIELD OF INVENTION

[0002] The present disclosure pertains to the field of preferred path routing in a network. More specifically, this disclosure relates to a preferred path routing method that uses a routing header for a fast re-route of a data packet through the network.

BACKGROUND

[0003] Conventional routing protocols commonly use Shortest Path routing algorithms in order to determine how to route packets in a network. A Shortest Path routing algorithm uses a metric to determine the“shortest” (or least-cost) path towards any given destination, and nodes along the path then base their forwarding decisions on the metric to route packets to their destination. However, a network operator may not want to use the least cost metric but, instead, may want to route packets on a path that offers the least possibility of loss, that provides the shortest delay, or that avoids a certain geography. These considerations led to the introduction of segment routing (SR).

[0004] In SR, packets are steered to a destination along a path by decomposing the path into a sequence of network segments. A segment may include an instruction that a node executes on a data packet in the network. Each network segment uses segment identifiers (SIDs) to uniquely identify the segment. A SID is an identifier associated with the segment. The SIDs are typically carried in the header of the packet. In an Internet Protocol version 6 (IPv6) data plane, a SID is a 128 bit IPv6 address that refers to the segment. As a result, encoding paths within the IPv6 data packet grows the packet length due to the additional octets of the SID(s) that are added. Thus, transmitting the packet introduces a network“tax” or overhead to each packet. This overhead can lead to issues where network bandwidth is a premium, as the overhead of the packet is relatively high in respect to the packet’s payload. The overhead can also lead to problems for cases that are highly sensitive to service level parameters. For instance, the overhead can lead to delays due to the additional time needed to send and receive longer packets. This makes SR detrimental to deployment for networking applications, such as networked augmented reality or virtual reality (AR/VR) applications, tactile applications, the Industrial Internet of Things (HOT), or 5G applications.

[0005] Another issue with the fast re-route methods in IPv6 networks is a suitable light-weight encapsulation. A normal encapsulation may include an IPv6 tunnel. An IPv6 packet has a header size of forty (40) bytes, and a tunnel header includes at least an additional eight (8) bytes when used. Additional octets are added to the packets to carry each SID. This method also adds a packet“tax” to the packets that are transmitted.

SUMMARY

[0006] A first aspect relates to a method performed by a network element (NE) in a network. The method includes detecting a failure in the first preferred path route (PPR); receiving a data packet, the data packet comprising a first PPR identifier (PPR-ID) indicating the first PPR in an Internet Protocol (IP) header of the data packet; in response to detecting the failure: adding a fast reroute routing header (FRRH) to the data packet; transferring the first PPR identifier (PPR-ID) from the IP header of the data packet to the FRRH; updating the IP header of the data packet to include a second PPR-ID; and forwarding the data packet with the FRRH on a reroute path according to the second PPR-ID.

[0007] The method provides an improved fast reroute technique in IPv6 networks to route a fast reroute data packet through a reroute path in a network that has a link failure or a node failure. The fast reroute data packet is an IPv6 data packet with the FRRH that is inserted into the data packet. The FRRH may be a segment routing header (SRH) or another routing header and includes data that is mapped from an IPv6 data packet. The fast reroute data packet adds minimal length to the FRRH, and thereby provides a compact method for implementing fast reroute. PPR between nodes or network elements in the network are predetermined by a controller prior to a link or node failure. The fast reroute technique uses a PPR as a reroute path to send a data packet in the network while the forwarding information database (FIB) is being updated thereby reducing or eliminating the number of data packets that are dropped or discarded. Using the fast reroute data packet increases the maximum transmission unit (MTU) of the network. The IPv6 data packet having the FRRH ensures that network elements or nodes in the network do not need to change the forwarding plane when the fast reroute (FRR) technique is implemented. Further, using the FRR technique increases security when forwarding the data packet within the network as malicious data packets with a reroute header that are injected at an edge node or network element in the network are rejected. The FRR technique also prevents a fast reroute data packet from exiting the network at an edge node or network element as a fast reroute data packet is reconstructed into a standard IPv6 data packet or dropped prior to exiting the network. Thus, the node or network element using the fast reroute technique is improved relative to current nodes in conventional FRR techniques as the fast reroute data packet uses a predetermined PPR as a reroute path to forward a compact data packet prior to the network re-converging thereby avoiding dropped data packets. As a practical matter, the improved routing method offers the user a better user experience when data packets are sent and received.

[0008] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first PPR-ID is an Internet Protocol version 6 (IPv6) address of a destination NE.

[0009] Optionally, in any of the preceding aspects, another implementation of the aspect provides retrieving the second PPR-ID from local storage.

[0010] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the data packet is an IP version 6 (IPv6) data packet.

[0011] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the second PPR-ID is a second destination IP version 6 address of a second network element in the reroute path.

[0012] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the NE is a point of local repair (PLR) NE.

[0013] Optionally, in any of the preceding aspects, another implementation of the aspect provides transferring a next header from the Internet Protocol (IP) header to the FRRH.

[0014] Optionally, in any of the preceding aspects, another implementation of the aspect provides updating the IP header of the data packet to include a second next header and an updated payload length including the FRRH length.

[0015] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the failure is between the NE and a second NE on the first PPR, wherein the reroute path connects the NE and the second NE, and wherein the step of forwarding the data packet with the FRRH on a reroute path according to the second PPR-ID avoids the failure.

[0016] Optionally, in any of the preceding aspects, another implementation of the aspect provides determining a repair topology of the network by the NE.

[0017] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH has at least 24 bytes of data.

[0018] Optionally, in any of the preceding aspects, another implementation of the aspect provides receiving the first PPR-ID and the second PPR-ID from a central entity or provisioned locally at the NE.

[0019] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH is a segment routing header (SRH).

[0020] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH is a routing header.

[0021] A second aspect relates to a method performed by a network element (NE) in a network. The method includes receiving a data packet with a fast reroute routing header (FRRH) on a reroute path; transferring a first preferred path route (PPR) identifier (PPR-ID) and a second next header from the FRRH to an Internet Protocol (IP) header of the data packet with the FRRH; removing the FRRH; updating a payload length and a hop limit in the IP header of the data packet and forwarding the data packet without the FRRH on a first PPR according to the first PPR-ID.

[0022] The method provides improved fast reroute techniques in IPv6 networks to route a fast reroute data packet through a reroute path in a network that has a link failure or a node failure. The fast reroute data packet includes a fast reroute routing header (FRRH). The fast reroute data packet adds minimal length to the FRRH, and thereby provides a compact method for implementing fast reroute. PPR between nodes or network elements in the network are predetermined by a controller prior to a link or node failure. The fast reroute technique uses a PPR as a reroute path to send a data packet in the network while the forwarding information database (FIB) is being updated thereby reducing or eliminating the number of data packets that are dropped or discarded. Using the fast reroute data packet increases the maximum transmission unit (MTU) of the network. The IPv6 data packet having the FRRH ensures that network elements or nodes in the network do not need to change the forwarding plane when the fast reroute (FRR) technique is implemented. Further, using the FRR technique increases security when forwarding the data packet within the network as malicious data packets with a reroute header that are injected at an edge node or network element in the network are rejected. The FRR technique also prevents a fast reroute data packet from exiting the network at an edge node or network element as a fast reroute data packet is reconstructed into a standard IPv6 data packet or dropped prior to exiting the network. Thus, the node or network element using the fast reroute technique is improved relative to current nodes in conventional FRR techniques as the fast reroute data packet uses a predetermined PPR as a reroute path to forward a compact data packet prior to the network re-converging thereby avoiding dropped data packets. As a practical matter, the improved routing method offers the user a better user experience when data packets are sent and received.

[0023] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first PPR-ID is an Internet Protocol version 6 (IPv6) address of a destination NE.

[0024] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the data packet with the FRRH is an IP version 6 (IPv6) data packet.

[0025] Optionally, in any of the preceding aspects, another implementation of the aspect provides receiving the data packet with the FRRH from a point of local repair (PLR) NE. [0026] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the IP header of the data packet without the FRRH comprises a second PPR-ID before transferring the first PPR-ID from the FRRH.

[0027] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH has at least 24 bytes of data.

[0028] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH is a segment routing header (SRH).

[0029] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH is a routing header.

[0030] A third aspect relates to a network element. The network element includes a memory storing instructions; and a forwarding information database including data associated with a reroute path; and a processor configured to execute the instructions that cause the processor to be configured to detect a failure in the first preferred path route (PPR); receive a data packet, wherein the data packet comprises a first PPR identifier (PPR-ID) indicating the first PPR in an Internet Protocol (IP) header of the data packet; in response to detecting the failure: add a fast reroute routing header (FRRH) to the data packet based on detecting the failure; transfer the first PPR identifier (PPR-ID) from the IP header of the data packet to the FRRH; update the IP header of the data packet to include a second PPR-ID; and forward the data packet with the FRRH on a reroute path according to the second PPR-ID.

[0031] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first PPR-ID is an Internet Protocol version 6 (IPv6) address of a destination NE. [0032] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the instructions further cause the processor to retrieve the second PPR-ID from local storage.

[0033] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the data packet is an IP version 6 (IPv6) data packet.

[0034] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the second PPR-ID is a second destination IP version 6 address of a second network element in the reroute path.

[0035] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the NE is a point of local repair (PLR) NE.

[0036] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the instructions further cause the processor to transfer a next header from the Internet Protocol (IP) header to the FRRH.

[0037] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the instructions further cause the processor to update the IP header of the data packet to include a second next header and an updated payload length including the FRRH length.

[0038] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the failure is between the NE and a second NE on the first PPR, wherein the reroute path connects the NE and the second NE, and wherein the instructions to cause the processor to forward the data packet with the FRRH on the reroute path avoids the failure.

[0039] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the instructions further cause the processor to determine a repair topology of the network by the NE. [0040] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH has at least 24 bytes of data.

[0041] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the instructions further cause the processor to receive the first PPR-ID and the second PPR-ID from a central entity or provisioned locally at the NE.

[0042] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH is a segment routing header (SRH).

[0043] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH is a routing header.

[0044] A fourth aspect relates to a network element (NE). The NE includes a memory storing instructions; a forwarding information database including data associated with a preferred path route (PPR); and a processor configured to execute the instructions that cause the processor to be configured to receive a data packet with a fast reroute routing header (FRRH) on a reroute path; transfer a first preferred path route (PPR) identifier (PPR-ID) and a second next header from the FRRH to an Internet Protocol (IP) header of the data packet with the FRRH; remove the FRRH; update a payload length and a hop limit in the IP header of the data packet; and forward the data packet without the FRRH on a first PPR according to the first PPR-ID.

[0045] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first PPR-ID is an Internet Protocol version 6 (IPv6) address of a destination NE.

[0046] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the data packet with the FRRH is an IP version 6 (IPv6) data packet. [0047] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the instructions further cause the processor to receive the data packet with the FRRH from a point of local repair (PLR) NE.

[0048] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the IP header of the data packet without the FRRH comprises a second PPR-ID before transferring the first PPR-ID from the FRRH.

[0049] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH has at least 24 bytes of data.

[0050] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH is a SRH.

[0051] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the FRRH is a routing header.

[0052] A fifth aspect relates to non-transitory computer-readable medium. The non-transitory computer-readable medium is configured to store a computer program product comprising computer executable instructions that, when executed by a processor of a network element (NE) implemented in a network, cause the processor to execute the method of any one of the first aspects.

[0053] The non-transitory computer-readable medium provides an improved fast reroute technique in IPv6 networks to route a fast reroute data packet through a reroute path in a network that has a link failure or a node failure. The fast reroute data packet includes a fast reroute routing header (FRRH) that is inserted into the data packet. The fast reroute data packet adds minimal length to the FRRH, and thereby provides a compact method for implementing fast reroute. PPR between nodes or network elements in the network are predetermined by a controller prior to a link or node failure. The fast reroute technique uses a PPR as a reroute path to send a data packet in the network while the forwarding information database (FIB) is being updated thereby reducing or eliminating the number of data packets that are dropped or discarded. Using the fast reroute data packet increases the maximum transmission unit (MTU) of the network. The IPv6 data packet having the FRRH ensures that network elements or nodes in the network do not need to change the forwarding plane when the FRR technique is implemented. Further, using the FRR technique increases security when forwarding the data packet within the network as malicious data packets with a reroute header that are injected at an edge node or network element in the network are rejected. The FRR technique also prevents a fast reroute data packet from exiting the reroute path at an edge node or network element as a fast reroute data packet is reconstructed into a standard IPv6 data packet or dropped prior to exiting the network. Thus, the node or network element using the fast reroute technique is improved relative to current nodes in conventional FRR techniques as the fast reroute data packet uses a predetermined PPR as a reroute path to forward a compact data packet prior to the network re-converging thereby avoiding dropped data packets. As a practical matter, the improved routing method offers the user a better user experience when data packets are sent and received.

[0054] A sixth aspect relates to non-transitory computer-readable medium. The non-transitory computer-readable medium is configured to store a computer program product comprising computer executable instructions that, when executed by a processor of a network element (NE) implemented in a network, cause the processor to execute the method of any one of the second aspects.

[0055] The non-transitory computer-readable medium provides an improved fast reroute technique in IPv6 networks to route a fast reroute data packet through a reroute path in a network that has a link failure or a node failure. The fast reroute data packet includes a FRRH that is inserted into the data packet. The fast reroute data packet adds minimal length to the FRRH, and thereby provides a compact method for implementing fast reroute. PPR between nodes or network elements in the network are predetermined by a controller prior to a link or node failure. The fast reroute technique uses a PPR as a reroute path to send a data packet in the network while the forwarding information database (FIB) is being updated thereby reducing or eliminating the number of data packets that are dropped or discarded. Using the fast reroute data packet increases the maximum transmission unit (MTU) of the network. The IPv6 data packet having the FRRH ensures that network elements or nodes in the network do not need to change the forwarding plane when the FRR technique is implemented. Further, using the FRR technique increases security when forwarding the data packet within the network as malicious data packets with a reroute header that are injected at an edge node or network element in the network are rejected. The FRR technique also prevents a fast reroute data packet from exiting the reroute path at an edge node or network element as a fast reroute data packet is reconstructed into a standard IPv6 data packet or dropped prior to exiting the network. Thus, the node or network element using the fast reroute technique is improved relative to current nodes in conventional FRR techniques as the fast reroute data packet uses a predetermined PPR as a reroute path to forward a compact data packet prior to the network re-converging thereby avoiding dropped data packets. As a practical matter, the improved routing method offers the user a better user experience when data packets are sent and received.

[0056] A seventh aspect relates to a system in a network. The system includes a first network element (NE) on a preferred path route (PPR), wherein the first NE is configured to forward a data packet with a fast reroute routing header (FRRH) on a reroute path; and a second NE coupled to the first NE and configured to receive the data packet with the FRRH, wherein the PPR connects the first NE and the second NE, and wherein the first NE is configured to execute the method of any one of the first aspects.

[0057] Optionally, in any of the preceding aspects, another implementation of the aspect provides a third NE on the PPR, wherein a link connecting the first NE and the third NE fails.

[0058] Optionally, in any of the preceding aspects, another implementation of the aspect provides at least one other NE on the reroute path and coupled to the first NE and the second NE.

[0059] An eighth aspect relates to a system in a network. The system includes a first network element (NE) on a preferred path route (PPR), wherein the first NE is configured to forward a data packet with a fast reroute routing header (FRRH) on a reroute path; and a second NE coupled to the first NE and configured to receive the data packet with the FRRH, wherein the PPR connects the first NE and the second NE, and wherein the second NE is configured to execute the method of any one of the second aspects.

[0060] Optionally, in any of the preceding aspects, another implementation of the aspect provides a third NE on the PPR, wherein a link connecting the first NE and the third NE fails.

[0061] Optionally, in any of the preceding aspects, another implementation of the aspect provides at least one other NE on the reroute path and coupled to the first NE and the second NE.

[0062] A ninth aspect relates to a system in a network. The system comprises a first NE of any of the third aspects and a second NE of any one of the fourth aspects, and wherein the second NE is configured to receive the data packet from the first NE on the reroute path.

[0063] Optionally, in any of the preceding aspects, another implementation of the aspect provides a third NE on the first PPR, wherein the failure involves a link with the third NE. [0064] Optionally, in any of the preceding aspects, another implementation of the aspect provides at least one other NE on the reroute path and coupled to the first NE and the second NE.

[0065] For the purpose of clarity, any one of the foregoing embodiments may be combined with any one or more of the other foregoing embodiments to create a new embodiment within the scope of the present disclosure.

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

BRIEF DESCRIPTION OF THE DRAWINGS

[0067] For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0068] FIG. 1 is a schematic diagram illustrating a network that may utilize a fast re-route technique according to various embodiments of the disclosure.

[0069] FIG. 2A is a schematic diagram of an example of an IPv6 data packet header that may be utilized in a network according to various embodiments of the disclosure.

[0070] FIG. 2B is a schematic diagram of an example segment routing header that may be utilized in a network according to various embodiments of the disclosure.

[0071] FIG. 2C is a schematic diagram illustrating an example of an IPv6 data packet that may be utilized in a network according to various embodiments of the disclosure.

[0072] FIG. 2D is a schematic diagram illustrating an example of an IPv6 data packet that may be utilized in a network according to various embodiments of the disclosure. [0073] FIG. 2E is a schematic diagram illustrating an example of an IPv6 data packet that may be utilized in a network according to various embodiments of the disclosure.

[0074] FIG. 3 is a method for implementing an IP fast re-route in a network according to various embodiments of the disclosure.

[0075] FIG. 4 is a schematic diagram illustrating a network element in a network according to various embodiments of the disclosure.

[0076] FIG. 5 is a schematic diagram illustrating a means for routing according to various embodiments of the disclosure.

[0077] FIG. 6 is a method for implementing an IP fast re-route in a network according to various embodiments of the disclosure.

DETAILED DESCRIPTION

[0078] It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure 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 modified within the scope of the appended claims along with their full scope of equivalents.

[0079] As noted above, conventional fast reroute (FRR) techniques add additional labels or SIDs to a data packet in order to steer the packet over a reroute path during a link or node failure. As used in the disclosure, a reroute path may be a repair path between NEs in the network that is implemented during FRR. These labels or identifiers are generally IPv6 addresses, which add additional octets of data to a data packet in the reroute path. The additional overhead or packet “tax” leads to an impact on the maximum transmission unit, and congestion. Conventional methods also require data plane changes to on-path routers within a reroute path.

[0080] Disclosed herein is an improved FRR technique that forwards a fast reroute data packet through a reroute path in a network that has a link failure or a node failure. The data packet includes a fast reroute routing header (FRRH) that is inserted into an IPv6 data packet. The FRRH adds minimal length to the IPv6 data packet, thereby providing a compact method for implementing FRR on a traffic engineered or preferred path.

[0081] Nodes or network elements along a preferred path route (PPR) transmit IPv6 data packets between nodes and between egress and destination nodes. The PPR is predetermined by a controller or locally provisioned by the operator on one of the nodes and flooded to the rest of the nodes in the network. Further, reroute paths/routes between nodes or network elements in the network are also predetermined by a controller or locally provisioned by the operator on one of the nodes prior to a link or node failure. The FRR technique selects an alternate PPR as a reroute path on which to send a data packet in the network while the forwarding information database (FIB) is being updated thereby reducing or eliminating the number of data packets that are dropped or discarded.

[0082] Using a smaller FRRH with the data packet increases the maximum transmission unit (MTU) of the network. The IPv6 data packet having the FRRH ensures that network elements or nodes in the network do not need to change the forwarding plane when the FRR technique is implemented. Further, using the FRR technique increases security when forwarding the IPv6 data packet having the FRRH within the network. For instance, data packets at an ingress node (an edge node or network element) in the reroute path should not include a segment routing header (SRH). If they do, they are flagged as malicious data packets. The PLR node may be configured to reject these malicious data packets.. The FRR technique also prevents a FRR data packet from exiting the reroute path as the FRR data packet is reconstructed into a standard IPv6 data packet or dropped prior to exiting the network at an edge node or network element. Thus, the node or network element using the FRR technique is improved relative to current nodes in conventional FRR techniques. As the fast reroute data packet uses a predetermined PPR as a reroute path to forward a compact data packet prior to the network re-converging, the FRR avoids dropping data packets. As a practical matter, the improved routing method offers the user a better user experience when data packets are sent and received.

[0083] FIG. 1 is a schematic diagram illustrating a network 100 (also referred to herein as an “area,”“autonomous system (AS)” or“domain”) configured to implement a fast re-route (FRR) technique using a fast reroute routing header (FRRH) to productively forward a data packet to a destination node over a reroute path in accordance with various embodiments of the disclosure.

[0084] Network 100 may be an IPv6 network. In embodiments, FRR is implemented using an IPv6 data packet and inserting a FRRH in the IPv6 data packet to change it into a fast reroute data packet. The fast reroute data packet may be an IPv6 data packet. The fast reroute data packet is forwarded on a reroute path based on a link failure or a node failure in a PPR. In embodiments, fields from the IPv6 data packet are mapped to the fast reroute data packet prior to forwarding the fast reroute data packet on the reroute path. In embodiments, the fast reroute data packet is an IPv6 data packet and adds a preferred path routing identifier (PPR-ID) of an IP destination address and a second PPR-ID of network element in the reroute path.

[0085] In embodiments, the FRR technique may forward the fast reroute data packet in network 100 using the FRR technique when a link failure or a node failure is detected. In embodiments, the fast reroute data packet is forwarded when a link failure or node failure is detected and prior to the network converging. As used herein, convergence is a state where all nodes/network elements in network 100 have the same topological information about the network in which they operate and have updated their forwarding information databases (FIBs) accordingly. In embodiments, the fast reroute data packet may be transmitted or forwarded on a reroute path by a repairing node towards another network element or node in network 100 that is not a destination node or network element of the original PPR. PPR is used interchangeably to refer to a route in the present disclosure. While the disclosure refers to forwarding a single IPv6 data packet or a single fast reroute data packet herein, it is to be appreciated that a plurality of IPv6 data packets or fast reroute data packets may be transmitted or forwarded in network 100 using the methods described herein.

[0086] As shown in FIG. 1, network 100 comprises a central entity 101 (also referred to herein as a“controller”) and multiple network elements (NEs) 109-121. As shown in FIG. 1, central entity 101 is directly connected to NE 109 in network 100 by a central entity-to-NE link 103. The NEs 109-121 are indirectly connected to central entity 101 through NE 109 and central entity-to- NE link 103. In other embodiments, central entity 101 may be directly coupled to each or some of the NEs 109-121 via central entity-to-NE links similar to central entity-to-NE link 103. Central entity-to-NE link 103 may be wired links, wireless links, or interfaces interconnecting one or more of the NEs 109-121 with central entity 101. In embodiments, central entity 101 may determine the network topology of network 100 using advertisements received from each NE 109-121 in network 100. In embodiments, central entity 101 may be a Path Computation Element (PCE), a Software Defined Network Controller (SDNC), or an Application Layer Traffic Optimization (ALTO) server. PCE is described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 8281, entitled“Path Computation Element Communication Protocol (PCEP) Extensions for PCE- Initiated LSP Setup in a Stateful PCE Model,” by E. Crabbe, dated December 2017, which is incorporated by reference herein in its entirety. SDNC is described in the IETF RFC 8402, entitled “Segment Routing Architecture,” by C. Filsfils, dated July 2018. ALTO server is described in the IETF RFC 7285, entitled“Application Layer Traffic Optimization (ALTO) Protocol,” by R. Alimi, dated September 2014, which is incorporated by reference herein in its entirety. In embodiments, central entity 101 may determine the network topology through any other conventional configuration techniques.

[0087] NEs 109-121 (also referred to herein as“nodes”) may be routers, bridges, virtual machines, network switches, or logical devices. NEs 109-121 may be interconnected by links 105A-105S between NE 109 and NE 121. In embodiments, links 105A-105S may be wired links, wireless links, or interfaces interconnecting each of NE 109-121. Each link 105A-105S may be associated with two unidirectional metrics, or a weight associated with transmitting IPv6 data packets across links 105A-105S or fast reroute data packets across links 105A-105S. Each unidirectional metric may be the same metric in both directions or different metrics in either direction. For example, the unidirectional metric for links 105A-105S may be a cost associated with a time to transmit an IPv6 data packet across link 105A-105S, a distance that the IPv6 data packet is transmitted across, a physical cost of transmitting a IPv6 data packet across link 105A- 105S, a bandwidth proportion in transmitting a IPv6 data packet across link 105A-105S, a number of intermediary NEs present on link 105A-105S between two end nodes, etc. In embodiments, the unidirectional metrics in either direction may be used to compute a PPR path between a source NE and a destination NE in network 100. In other embodiments, a PPR path may be generated by omitting a NE from the PPR path where the PPR path and the shortest path are congruent. NEs 109-121 may be configured to perform switching and routing for forwarding the IPv6 data packet disclosed herein. In embodiments, NE 109 and NE 121 may be headend or edge NEs positioned at an edge of network 100.

[0088] For discussion and clarity in the present disclosure, NE 109 may be an ingress or source NE that forwards traffic (e.g., control packets and IPv6 data packets) received from a network (not shown) outside network 100 such as, for example, an Ethernet to NE 121. NE 121 may be an egress NE or destination NE on a PPR. In embodiments, the central entity 101 may generate one or more paths for forwarding an IPv6 data packet between NE 109 and NE 121 using the network topology of network 100. The paths may be a shortest path 122, PPR 124, or reroute path 126 based on a routing policy. PPR 124 and reroute path 126 (also referred to herein as a“Non- Shortest Path”) refer to custom paths that are created based on one or more application or service requirements. In embodiments, reroute path 126 may be determined based on a repair topology of network 100. Further, reroute path 126 may be used when a link failure or node failure is detected. In embodiments, the reroute path 126 may be predetermined by central entity 101. Each route may be independent of all other routes in network 100. In an example shown in FIG. 1, shortest path 122 is a path from source NE 109 to destination NE 121 that identifies a path identified by (NE 109, NE 110, NE 111, NE 112, and NE 121 }. In embodiments, PPR 124 identifies a path (NE 109, NE 113, NE 114, NE 115, NE 116, and NE 121 } comprising PPR-ID A for a prefix (or destination address) of NE 121. PPR 124 may be signaled by any NE in PPR 124 whereby a PPR- ID may be included in a data packet that is sent by any NE in PPR 124.

[0089] In embodiments, central entity 101 may determine the network topology of network 100 including a repair topology using advertisements received from each NE 109-121 in network 100. Interior Gateway Protocol (IGP) uses a form of a“hello” protocol between immediate neighboring NEs to form adjacencies and advertise connected NEs and links to the entire process through a flooding process. In embodiments, the routes/paths in network 100 may be determined based on a metric, such as, for example, a cost or weight associated with each link on the path, a number of NEs on the path, a number of links on the path, an operator selected path, bandwidth, etc. In embodiments, central entity 101 may determine routes/paths such as the shortest path 122, PPR 124, and reroute path 126, which is an alternate PPR between nodes. In embodiments, the central entity 101 may determine routes/paths in network 100 using an interior gateway protocol (IGP) for exchanging routing information and/or state information among NEs 109-121.

[0090] In embodiments, central entity 101 may determine route information between a source NE 109 and destination NE 121. In embodiments, the route information includes a PPR-identifier (PPR-ID). The PPR-ID, which is also referred to herein as an“NSP forwarding ID” (NSPF-ID), identifies the PPR and one or more preferred path routing-path description elements (PPR-PDEs). The PPR-PDEs, which are also referred to herein as“path IDs”, describe each of the nodes/NEs on the PPR in sequential order. A PPR can be described as a Strict-PPR path or a Loose-PPR path. In a Strict-PPR path, all NEs/links on a PPR are described with IPv6 addresses for the IP data plane. In a Loose-PPR path, only some of the NEs/links from source to destination are described. In embodiments, the NE 109 may be configured to implement routing using Open Shortest Path First (OSPF) Version 2 (OSPFv2) protocol, OSPFv3 protocol, IS-IS protocol, or direct SDN controller based on network implementations. PPR using IS-IS is described in Internet Engineering Task Force (ETF) Internet Draft, entitled“Preferred Path Routing (PPR) in IS-IS,” by U. Chunduri, dated March 8, 2020, which is incorporated by reference herein in its entirety. PPR using OSPF is also described in in Internet Engineering Task Force (ETF) Internet Draft, entitled“Preferred Path Routing (PPR) in OSPF,” by U. Chunduri, dated May 16, 2019, which is incorporated by reference herein in its entirety. A separate PPR-ID is required for every possible route, even if one route is just a subset of another route with the same destination. A full-mesh connectivity between N nodes may need N² routes and N² PPR-IDs. To minimize the amount of routing information that is needed and to allow scalability, a routing tree or graph may be used in the control plane, which is described in IETF Internet Draft, entitled“Preferred Path Route Graph Structure,” by U. Chunduri, dated March 8, 2020, which is incorporated by reference herein in its entirety.

[0091] Central entity 101 may send the PPR information to headend NE 109 or NE 121 in network 100. In embodiments, NE 109 or NE 121 in network 100 may be configured to store the routing information and advertise PPRs received from central entity 101. In embodiments, PPR may be advertised by sending an advertisement comprising the PPR-ID, identifying the PPR, to all other NEs 109-121 in network 100. Each NE 109-121 that receives the advertisement first determines whether it is identified in the PPR-PDEs for one or more of the advertised PPRs. A PPR-PDE may be topological or non-topological elements and is stored in a locally stored forwarding information base database (FIB) to indicate a next hop (another NE, link, or segment) by which to forward the IPv6 data packet. If the NE is identified in the PPR-PDEs for the PPR-ID, then NEs 109-121 update the locally stored FIB with an entry for the PPR-ID to indicate that IPv6 data packets are be forwarded to the destination along the PPR identified by the PPR-ID instead of the IGP computed shortest path. The central entity can define a few PPR from NE 109 to NE 121 that deviate from the shortest path based on other network characteristic requirements as requested by an application or service. For example, the network characteristics or performance requirements may include bandwidth, jitter, latency, throughput, error rate, etc. In embodiments, an alternate PPR may be used as a reroute path/route to a destination node/NE. The alternate PPRs may be used as a repair strategy predetermined prior to detecting a link failure or a node failure. In embodiments, the reroute path may be identified by a PPR-ID and an IPv6 data packet forwarded along the reroute path includes the PPR-ID. In embodiments, the PPR-ID may be a 16 byte IP destination address in the IPv6 data plane.

[0092] While network 100 includes central entity 101 configured to determine and send PPR path information to NE 109 or 121 in a centralized approach, the NE 109 or 121 may receive the routing information through other sources as well. For instance, an operator can configure one of NE 109 or 121 in network 100 to include and store the routing information. In this case, NE 109 or 121 is still configured to send advertisements including the routing information to all other NEs 109-121 in network 100. In embodiments in which network 100 does not implement an IGP flooding mechanism, central entity 101 may be a controller that is connected to every NE 109-121 in network 100. In this embodiment, central entity 101 is manually configured to send advertisements including the routing information to all NEs 109-121 in network 100 instead of just sending the advertisement to the single NE 109 or 121.

[0093] Each NE in network 100 continually monitors links and nodes in network to detect a link failure to a neighbor node or a node failure in a neighbor NE. The link or node failure may be detected using loss-of-light, using bidirectional forwarding detection (BFD), or using“fast Hellos.” In embodiments, a repair strategy where a data packet may be routed over an alternate path (also known as a reroute path) to route data packets may be determined in advance before a link failure or node failure is detected. If the NE detects a link failure or node failure to the next hop, the NE (also known as“point of local repair (PLR) node”) may select a reroute path from several alternate routes based on one or more policies to reroute data packets over links 105A-105P. The reroute path may be selected prior to the data packet arriving at the PLR node. When the PLR node receives a data packet and there is a failure along the packets path (such as along a PPR), it determines the next hop towards the next NE as described in the routing description and sends the packet as a fast reroute data packet over a reroute path to the next NE. In embodiments, the PLR node may use alternate PPR that may be used as reroute paths during FRR. The reroute path may be selected prior to receiving the IPv6 data packet and before the network re-converges. The reroute path may be identified by a PPR-ID, which is an IPv6 address. The alternate routes/paths are identified by different PPR-IDs that identify paths to NEs within network 100. In embodiments, these alternate paths may be precomputed at NEs 109-121 using the IGP flooding mechanism described above prior to invocation of FRR. In embodiments, the alternate paths may define a strict-PPR or a Loose-PPR in network 100. Each node/NE at an endpoint of the reroute path is a point of local repair (PLR) node/NE. The PLR node/NE is a repairing node for FRR. For instance, using the example of reroute PPR 126 in FIG. 1, PLR NE is NE 113.

[0094] In embodiments, during implementation of FRR upon detecting a link or node failure in network 100, a PLR node/NE may modify an incoming IPv6 data packet by inserting a FRRH to generate an outgoing IPv6 data packet (also referred to as fast reroute data packet). An example of an incoming IPv6 data packet is shown in FIG. 2A and an example of fast reroute data packet is shown in FIG. 2C. In embodiments, PLR NE 113 may insert a FRRH to the incoming IPv6 data packet and update the IP header of the IPv6 packet header prior to forwarding it along the reroute path 126. Reroute path may have an identifier as PPR-ID B. PPR-ID B is an IPv6 address of the destination node in reroute path 126. The FRRH includes a Segment List field[0] comprising a segment identifier 0 (SID0). The SID0 is an IPv6 address of a destination NE. In embodiments, the SID0 is an IPv6 destination address of NE 121, which is the original destination address for the data packet on PPR 124, using the PPR 124. The original destination address may also be referred to as an outer IPv6 destination address. In embodiments, the IPv6 header of the incoming IPv6 data packet is changed by adding an IPv6 destination address of NE 114. In embodiments, the SIDO field of the FRRH includes the outer IPv6 destination address. The SIDO is an IPv6 address and is PPR-ID A. PPR-ID B is an identifier for reroute path 126 from NEs {NE 113, NE 117, NE 118, and NE 115} for a prefix (e.g., IPv6 address) of NE 115. In embodiments, PPR-ID A is an identifier for PPR 124 from nodes/NEs {NE 109, NE 113, NE 114, NE 115, NE 116, AND NE 121 } .

[0095] When the fast reroute data packet arrives at NE 115, the fast reroute data packet is deconstructed and fields from the fast reroute data packet are mapped to fields in an IPv6 data packet to reconstruct an IPv6 data packet from the fast reroute data packet. In embodiments, Segment List field[0], which has SIDO as the outer IPv6 destination address, is extracted and inserted into the IPv6 header of the fast reroute data packet. The reconstructed IPv6 packet is sent to NE 121 on PPR 124, which is the original destination E of PPR 124.

[0096] Benefits of using a FRRH in a fast reroute data packet include obtaining a compact IPv6 data packet to forward along a reroute path during a link failure or node failure and minimizing the packet“tax” to network 100. The fast reroute data packet also is a convenient solution to forwarding a data packet prior to the network reconverging. A PLR NE in a the reroute path may forward the fast reroute data packet to another PLR node/NE downstream of the link or node failure without needing to change the data plane for NEs participating in forwarding the data packet on the reroute path. In embodiments, the FRRH may include a SIDO having a prefix of an IPv6 destination address or a destination address. In embodiments, SIDO includes an outer IPv6 destination address of an endpoint node/NE in PPR in an IPv6 data plane. As the 16 byte IPv6 address is inserted into a SID in the FRRH, the FRR technique using the FRRH adds 24 bytes (or more, for example, if the address or other parts of the header are larger) to the encapsulated IPv6 data packet thereby minimizing a maximum transmission unit (MTU) forwarded during the FRR technique. Conventional FRR techniques add significantly more bytes for each segment or node to the data packet. An IPv6 data packet with a FRRH is shown below in FIG. 2C.

[0097] In operation, an IPv6 data packet may be forwarded from NE 109 over network 100 towards destination NE 121 over PPR 124. In embodiments, PPR 124 is identified by PPR-ID A. In embodiments, an IPv6 address for destination NE 121 is PPR-ID A that is an identifier of PPR 124. In embodiments, the IPv6 data packet may be forwarded over PPR 124. The IPv6 data packet includes a PPR-ID A for PPR 124 of (NE 109, NE 113, NE 114, NE 115, NE 116, and NE 121 } for a prefix of NE 121. When a NE in PPR 124 receives the IPv6 data packet, for instance, NE 113 in PPR 124, NE 113 may perform a lookup on its locally stored FIB to determine the next PPR-PDE associated with PPR-ID. After determining the next hop, NE 113 forwards the IPv6 data packet to the next hop based on the PPR-PDE indicated in the locally stored FIB. For instance, NE 113 may forward the IPv6 data packet to NE 114. In this way, each NE 109-121 in the network may be configured to forward IPv6 data packets on PPR 124 identified by PPR-ID A to destination NE 121.

[0098] However, in some instances, the IPv6 data packet may experience a link or node failure in network 100. In embodiments, all NEs 109-121 may detect link or node failures at any time. For instance, a link failure 107 at link 105F between NE 113 and NE 114 or a node failure at NE 114 in PPR 124 may cause the IPv6 data packet to be discarded at NE 113 when the network has not re-converged. For instance, the IPv6 data packets may micro-loop back and eventually be discarded if the time-to-live is exhausted. The micro looping may further cause network congestion. To address this failure, NE 113 may use a reroute path that is predetermined for each NE 109-121 in network 100. The FRR technique may generate a reroute path prior to re- convergence of network 100 in anticipation of a failure. In embodiments, using FRR techniques described in the present disclosure, NE 113 inserts a FRRH between the IPv6 header and the payload in the IPv6 data packet to construct a fast reroute data packet. In embodiments, the constructed fast reroute data packet may be IPv6 data packet 240 that is shown In FIG. 2C. In embodiments, the repair strategy may be to select a reroute path 126 whereby NE 113 may forward the fast reroute data packet to a NE that is a few hops away from destination NE 121. In the example shown in FIG. 1, the FRR may use reroute path 126 with PPR-ID B on a path {NE 113, NE 117, NE 118, and NE 115}.

[0099] When the fast reroute data packet arrives at NE 115 based on the IPv6 address of PPR- ID B, NE 115 may reconstruct an IPv6 data packet by deconstructing fast reroute data packet. The IPv6 data packet for PPR 124 is constructed by mapping fields from fast reroute data packet to IPv6 data packet and removing additional fields. The IPv6 data packet, for example IPv6 data packet 290, may be reconstructed by removing the FRRH and mapping fields from the fast reroute data packet to fields of IPv6 data packet to obtain a reconstructed IPv6 data packet with an IPv6 data packet header and an IPv6 Payload field. In an example, the reconstructed IPv6 data packet may be IPv6 data packet 290 (FIG. 2E). A hop limit of the reconstructed IPv6 data packet may be decremented appropriately. Therefore, the IPv6 data packet entering the reroute path is substantially the same as the IPv6 data packet exiting the reroute path with the exception of an update to the hop-limit. At NE 115, the IPv6 data packet is forwarded along the path identified in the Destination Address field after reconstructing IPv6 data packet 290 (FIG. 2D).

[00100] The FRR technique disclosed herein ensures that a data packet is routed using minimum size of a FRRH in conjunction with PPR when a link failure or a node failure in the network is encountered and provides a compact method of implementing FRR in an IPv6 network. Using the FRRH and inserting an IPv6 address of an inner IP destination address (IPv6 destination address of a NE in reroute path) keeps the data packet size to 24 bytes, which allows for an increase in the maximum transmission unit (MTU) of the network and a decrease in dropped packets while the network reconverges. Adding the FRRH to an IPv6 data packet ensures that NEs that implement the FRR technique do not need a change the forwarding plane in different routing protocols. The FRR technique maintains security of the network against malicious actors that could use segment routing techniques as an attack vector. For instance, as the data packet with the PPR-ID is kept within the reroute path, the FRR technique is not advertised to an outside network. Further, data packets entering an ingress node of a reroute path may be inspected to determine they do not contain a routing header, for example, a SRH. If the data packets entering the network have a routing header, these data packets are rejected. Using a data packet with a FRRH and implementing the FRR technique disclosed herein prevents the data packet from being routed outside the repair domain as the packets are converted back to their original format or dropped at the end of the reroute path.

[00101] FIG. 2A depicts a diagram illustrating an example of IPv6 data packet 200 received at node in a PPR in network 100 in accordance with various embodiments of the disclosure. In embodiments, the node may be NE 113 in PPR 124 of network 100. The diagram shown in FIG. 2A is an IPv6 data packet 200 showing at least a portion of the fields that are included in IPv6 data packet. IPv6 data packet includes IPv6 Header 202 and IPv6 Payload 203. IPv6 Header 202 includes Version field 204, Traffic Class field 205, Flow Label field 206, Payload Length field 208, Next Header field 210, Hop Limit field 212, Source Address field 213, and Destination Address field 214. Each field in IPv6 Header 202 may carry a length that may be assigned by the Internet Assigned Numbers Authority (IANA). Version field 204 is a 4-bit field that is used to identify the IP version. Traffic Class field 205 is an 8-bit field is used for traffic management. Flow Label field 206 is a 20-bit field that may be used by a source to label sequences of packets for which it requests special handling by the IPv6 NEs, such as non-default quality of service or“real time” service. Payload Length field 208 is a 16-bit integer to indicate a length of the rest of the packet following the IPv6 Header 202. Next Header field 210 is an 8-bit field that specifies the type of extension header in IPv6 Payload field 203 that immediately follows IPv6 Header 202. For instance, Next Header field 210 may specify a transport layer protocol used by IPv6 Payload 203. In some examples, Next Header field 210 may include a value that indicates the protocol used such as Transmission Control Protocol (TCP) or routing information such as segment routing. Hop Limit field 210 is an 8-bit field that indicates the number of hops to forward the packet to its destination. This field is decremented by 1 by each node that forwards the packet. Source Address field 213 is a 16 byte IP address of the originator of the packet, for instance, an IP address of NE 109. Destination Address field 214 is a 16 byte IP address of destination NE 121. In embodiments, Destination Address 214 is PPR-ID A, which identifies PPR 124. In embodiments, PPR-ID A is an IPv6 address of destination NE 121. IPv6 Payload field 203 includes optional extension headers that include option fields examined by all nodes, option fields that are examined only at the destination node, routing information, or the like.

[00102] FIG. 2B depicts a diagram illustrating an example of a SRH 220 used to encode information for a FRR technique in accordance with various embodiments of the disclosure. The diagram shown in FIG. 2B is a SRH 220 showing at least a portion of the fields included in SRH 220, which is described in Internet Engineering Task Force (ETF) Internet Draft, entitled“IPv6 Segment Routing Header (SRH),” by C. Filsfils, dated June 13, 2019. SRH 220 includes Next Header field 222, Hdr Ext Len field 224, Routing Type field 226, Segments Left field 228, Last Entry field 230, Flags field 232, Tag field 234, and Segment List[0] 236. Next Header field 222 is the first extension header used to indicate the protocol used in later extension headers and identifies the type of header immediately following the SRH 220. Hdr Ext Len field 224 is an 8-bit field to indicate the length of Segment List field 236. Routing Type field 226 indicates the routing header used in SRH 220. In embodiments, Routing Type 226 may have a value of 4. However, values other than 4 may also be contemplated in this disclosure. Segments Left field 228 may indicate a number of route segments remaining. For instance, Segments Left field 228 indicates a number of explicitly listed segments to be visited in the reroute path before reaching a destination node. In embodiments, Segments Left field 228 is 1 for a single hop to a destination NE. Segment List[0] field 236 is a first segment that includes the first SID, which in an IPv6 data plane, is a 128 bit IPv6 address of a NE. In embodiments, SID0 is PPR ID A. SRH 220 is described in Internet Engineering Task Force (IETF) Internet Draft, entitled“IPv6 Segment Routing Header (SRH),” by C. Filsfils, dated June 13, 2019, which is incorporated by reference herein in its entirety.

[00103] In embodiments, other types of FRRH may be used instead of SRH 220 in accordance with various embodiments of the present disclosure. In embodiments, the FRRH may be FRRH 244, which may include a portion of the fields from SRH 220. In embodiments, FRRH 244 may have the same fields as Next Header field 222, Hdr Ext Len field 224, Routing Type field 226, Segments Left field 228, and Segment List[0] field 236. FRRH 244 may use similar lengths and values in these fields as SRH 220. Any routing header, including FRRH 244, may be controlled by a fixed number of fields as defined in Internet Engineering Task Force (IETF) Request for Comments, entitled“Internet Protocol, Version 6 (IPv6) Specification,” by S. Deering, dated July 2017, which is incorporated by reference herein in its entirety. Additional fields may also be used based on the requirements of network 100 (FIG. 1). FRRH 244 may also be contemplated for use with other routing headers, which are described in https://www.iana.org/assignments/ipv6- parameters/ipv6-parameters.xhtml, dated April 20, 2020.

[00104] FRRH 244 may provide additional benefits over other conventional methods of FRR when a null PPR-ID is formed in an IPv6 data packet. The additional benefit may apply when an IPv6 data packet is received at NE 113 with a null PPR-ID in the routing header. In case of Segment List[0] with a SIDO in SRH 220, implementing FRR at the PLR node using the PPR-ID may cause fragmentation issues when a routing header is inserted between the IPv6 header and the payload. An advantage of using a FRRH 244 in the same example for network 100 is, as the packet arrives at the PLR (NE 113) for a FRR, the null PPR-ID in the FRRH 244 may be replaced with a current Destination Address field 252. Further, the PPR-ID of the reroute path 126 is kept in the Destination Address field 252 when the data packet is emitted at NE 113. This insertion may not cause fragmentation issues when inserting the FRRH 244 into the IPv6 data packet.

[00105] FIG. 2C depicts a diagram illustrating an example of an IPv6 data packet 240 that includes a SRH 220 in accordance with various embodiments of the disclosure. For instance, the diagram shown in FIG. 2C is fast reroute data packet that is created from an IPv6 data packet 200 (shown in FIG. 2A) with a portion of the fields from SRH 220 (FIG. 2B) inserted as a FRRH (also referred to as IPv6 data packet with a FRRH). IPv6 data packet 240 shows at least a portion of the fields from IPv6 data packet 200 but includes a portion of the fields from SRH 220 and mappings from IPv6 data packet 200. IPv6 data packet 240 is generated during the FRR technique when a faulty link or a faulty node is detected in network 100. As shown in FIG. 2C, IPv6 data packet 240 includes IPv6 Header 242, FRRH 244, and IPv6 Payload 270. IPv6 Header 242 includes Payload Length field 246, Next Header field 248, Hop Limit field 250, and Destination Address field 252. Payload Length field 246 has a value that is incremented to represent the length of the FRRH that is appended to IPv6 data packet 240. For instance, Payload Length field 246 includes an original length of 16-bits and an incremental increase in length of 24 bytes for the length of FRRH 244. Next Header field 248 includes information to indicate a routing header following the IP v6 Header 242 (such as the FRRH 244 or the SRH 220). Hop Limit field 250 is decremented by 1 as the IPv6 data packet arrives at the PLR node to encapsulate the IPv6 data packet 200. Destination Address field 252 includes PPR-ID of PPR 126. For instance, Destination Address field 252 is a 128-bit IPv6 address of NE 115, which indicates the NE that the IPv6 data packet 240 will traverse to complete the repair in network 100.

[00106] FRRH 244 includes Next Header field 254, Hdr Ext Len field 256, Routing Type field 258, Segments Left field 260, Last Entry field 262, Flags field 264, Tag field 266, and Segment List[0] field 268. Next Header field 210 is mapped to Next Header field 254 of IPv6 packet 200 (FIG. 2A). In embodiments, Next Header field 254 is a Transmission Control Protocol (TCP) type. Hdr Ext Len field 256 includes 20 bytes of data. In embodiments, Hdr Ext Len field 256 includes 4 bytes of the Hdr Ext Len field 224 and 16 bytes of the IPv6 address of Destination Address field 214. Routing Type field 258 is mapped to the Routing Type field 226. In embodiments, Routing Type field 258 may have a value of 4. However, values other than 4 may also be contemplated in this disclosure. Segments Left field 260 may indicate a number of route segments remaining. In embodiments, Segments Left field 260 is 1 to indicate SID (or IPv6 destination address) for destination NE 115 of reroute path 126. Last Entry field 262 includes an index of the last element of Segment List field 268. Flags field 264 may be include a value of 0 as this field is not yet defined. Tag field 266 tags an IPv6 data packet as part of a class or group of packets. In an example, Tag field 266 is 0 when an IPv6 data packet is transmitted. Segment List[0] field 268 is mapped to the PPR-ID of the destination address for the original IPv6 data packet. For instance, Segment List[0] may include a 128 bit IPv6 address of NE 121. Segment List[0] field 268 includes a SID, which may be IPv6 destination address. For instance, Segment List[0] may include a 128 bit IPv6 address ofNE 121.

[00107] FIG. 2D depicts a diagram illustrating an example that shows a portion of the fields in an IPv6 data packet 290 that is reconstructed from mapping fields in a fast reroute data packet, for example, from IPv6 data packet 240 in accordance with various embodiments of the disclosure. In embodiments, IPv6 data packet 240 is constructed using values and data that are obtained by mapping fields from IPv6data packet 240 in network 100. In embodiments, the IPv6 data packet 290 is an IPv6 data packet without a FRRH 244. IPv6 data packet 240 may be a fast reroute data packet 240 with the FRRH 244. The reconstruction is performed when the IPv6 data packet 240 (FIG. 2C) is received on PPR 126. Further, a portion of the fields from FRRH 244 is mapped to an IPv6 data packet 290. As shown in FIG. 2D, IPv6 data packet 290 includes IPv6 Header 291 and IPv6 Payload 292. IPv6 Header 291 includes Payload Length field 293, Next Header field 294, Hop Limit field 295, and Destination Address field 296. Further, the Payload Length field 293 has a value that is decremented by the size of the FRRH 244, which represents the length of FRRH 244 that is removed from IPv6 data packet 290. In embodiments, Payload Length field 293 is decremented by 24 bytes. Next Header field 294 is mapped to Next Header field 254. For instance, information from Next Header field 254 is inserted into Next Header field 294. Hop Limit field 295 is decremented by 1 to represent the hop that the fast reroute IPv6 data packet 240 has performed. Further, Destination Address field 296 is changed to the IPv6 address in Segment List[0] 268, which includes the IPv6 address of PPR-ID A. PPR-ID A is the outer IPv6 destination address of IPv6 data packet 200 from Destination Address field 214. Further, FRRH 244 is removed from fast reroute IPv6 data packet 240. The IPv6 data packet 290 after reconstruction is shown in FIG. 2E. The IPv6 data packet 290 may be forwarded on PPR 124 after reconstruction using the IPv6 destination address of NE 121.

[00108] FIG. 3 is an embodiment of a method 300 for implementing FRR by a NE (e.g., NE 109). The method may be performed after an IPv6 data packet is received by NE 109 on a PPR, for instance, PPR 124 (FIG. 1). The method 300 improves a FRR technique when a broken link or route is detected in a network and the FRR technique is implemented. The FRR technique constructs a data packet with a fast reroute routing header and inserts it into the IPv6 data packet. The data packet with the FRRH is inserted into a reroute path to forward the data packet with the FRRH to a downstream node/NE so that it can productively be forwarded to its original destination NE. In embodiments, the reroute path is reroute path 126. The FRR technique minimizes the impact on a maximum transmittable unit in forwarding the IPv6 data packet with the FRRH so as to provide a lower encapsulation“tax” during FRR and eliminates dropped packets in the network as the network re-converges. Also, method 300 improves FRR without changing on-path routers (e.g., nodes/NE). Therefore, as a practical matter, the FRR technique improves the performance of NEs in the network and the overall network, which leads to a better user experience.

[00109] At step 302, the NE detects a link failure or a node failure in the network. In embodiments, the NE detects a link failure to a neighbor NE in a PPR or a node failure of a neighbor NE in the PPR.

[00110] At step 304, the NE receives an IPv6 data packet. The IPv6 data packet contains a PPR-ID indicating the PPR in an IP header of the data packet. In embodiments, the IPv6 data packet containing the PPR-ID is forwarded along the PPR that is identified.

[00111] At step 306, in response to detecting a failure, the NE: adds a fast rerouting header (FRRH) to the data packet, transfers the first PPR-ID to the FRRH, update the IP header to include a second PPR-ID, and forward the data packet with the FRRH. In embodiments, the reroute path is an alternate PPR that is locally stored in NE. The reroute path is identified by a unique PPR-ID within network 100. The unique PPR-ID may be a 128 bit IPv6 address. The reroute path may be used for FRR. The NE creates aIPv6 data packet with a fast rerouting header (FRRH). In embodiments, the NE creates the IPv6 data packet with the FRRH based on detecting the failure. In embodiments, the NE transfers a PPR-ID from the IP header of the IP v6 data packet to the FRRH. The NE may also update the IP header of the IPv6 data packet to include a second PPR- ID, a second next header, and an updated payload length including the FRRH. The first PPR-ID is an IPv6 address of a destination NE. The first PPR-ID is an identifier of the first PPR. NE may also transfer a next header from the Internet Protocol (IP) header to the FRRH and update the IP header of the IPv6 data packet to increase the payload length. In embodiments, the FRRH may be a SRH or a routing header and has 24 bytes of data. In other embodiments, the FRRH may have more than 24 bytes of data. The NE forwards the IPv6 data packet with the FRRH on a reroute path. In embodiments, the NE forwards the IPv6 data packet on the reroute path according to the second PPR-ID. In embodiments, the second PPR-ID is a second destination IPv6 address of a second network element in the reroute path.

[00112] FIG. 4 is a schematic diagram of Fast Reroute Device 400 in network 100 according to various embodiments of the disclosure. In embodiments, Fast Reroute Device 400 may be implemented as any one of NEs 109-121 or central entity 101. Fast Reroute Device 400 is suitable for implementing the disclosed embodiments as described herein. The Fast Reroute Device 400 comprises ingress ports 410 and receiver units (Rx) 420 for receiving data; a processor, logic unit, or central processing unit (CPU) 430 to process the data; transmitter units (Tx) 440 and egress ports 450 for transmitting the data; and a memory 460 for storing the data. The Fast Reroute Device 400 may also comprise optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress ports 410, the receiver units 420, the transmitter units 440, and the egress ports 450 for egress or ingress of optical or electrical signals.

[00113] The processor 430 is implemented by hardware and software. The processor 230 may be implemented as one or more central processing unit (CPU) and/or graphics processing unit (GPU) chips, logic units, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 430 is in communication with the ingress ports 410, receiver units 420, transmitter units 440, egress ports 450, and memory 460. The processor 430 comprises a routing module 470. The routing module 470 is implemented by the processor 430 to execute the steps of method 300 and instructions for implementing various embodiments described herein. For instance, the routing module 470 implements, processes, prepares, or provides the various routing and forwarding functions. The inclusion of the routing module 470 therefore provides a substantial improvement to the functionality of the video coding device 400 and effects a transformation of the video coding device 400 to a different state. Alternatively, the routing module 470 is implemented as instructions stored in the memory 460 and executed by the processor 430. In embodiments, the Fast Reroute Device 400 is a non-transitory computer-readable medium configured to store a computer program product comprising computer executable instructions that, when executed by the processor 430, cause the processor 430 to implement the steps of method 300. For example, the routing module 470 is configured to forward an encapsulated IPv6 data packet 250 on a reroute path identified by PPR-ID B. The inclusion of the encapsulated IPv6 data packet 250 also provides an improvement to the functionality of the Fast Reroute Device 400 and other device in network 100 by minimizing the packet tax of forwarding IPv6 data packets for IPFRR. The routing module 470 also effects a transformation of Fast Reroute Device 400 to a different state. Alternatively, the routing module 470 is implemented as instructions stored in the memory 460.

[00114] The Fast Reroute Device 400 may also include input and/or output (I/O) devices 480 for communicating data to and from a user. The I/O devices 480 may include output devices such as a display for displaying video data, speakers for outputting audio data, etc. The I/O devices 480 may also include input devices, such as a keyboard, mouse, trackball, etc., and/or corresponding interfaces for interacting with such output devices.

[00115] The memory 460 comprises one or more disks, tape drives, and solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory 460 may be volatile and/or non-volatile and may be read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and/or static random-access memory (SRAM).

[00116] The processor 230 may be implemented by hardware and software. The processor 230 may be implemented as one or more central processing unit (CPU) and/or graphics processing unit (GPU) chips, logic units, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 230 is in communication with the ports 220, Tx/Rx 210, and memory 260. The service group module 235 is implemented by the processor 230 to execute the steps of methods 700 and 800 and the instructions for implementing various embodiments discussed herein. In embodiments, the NE 200 is a non-transitory computer-readable medium configured to store a computer program product comprising computer executable instructions that, when executed by the processor 230, cause the processor to implement the steps of methods 700 and 800. For example, the service group module 235 is configured to forward advertisements 165 to only NEs 104-112 in a service group 130A-B identified in the advertisements 165. The inclusion of the service group module 235 provides an improvement to the functionality of the NE 200. The service group module 235 also effects a transformation of NE 200 to a different state. Alternatively, the service group module 235 is implemented as instructions stored in the memory 260.

[00117] The memory 260 comprises one or more of disks, tape drives, or solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory 260 may be volatile and non-volatile and may be read-only memory (ROM), random- access memory (RAM), ternary content-addressable memory (TCAM), and static random-access memory (SRAM).

[00118] It is understood that by programming and/or loading executable instructions onto the Fast Reroute Device 400, at least one of the processor 430 and/or memory 460 are changed, transforming the Fast Reroute Device 400 in part into a particular machine or apparatus, e.g., a multi-core forwarding architecture, having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules. Decisions between implementing a concept in software versus hardware typically hinge on considerations of stability of the design and numbers of units to be produced rather than any issues involved in translating from the software domain to the hardware domain. Generally, a design that is still subject to frequent change may be preferred to be implemented in software, because re-spinning a hardware implementation is more expensive than re-spinning a software design. Generally, a design that is stable that will be produced in large volume may be preferred to be implemented in hardware, for example in an ASIC, because for large production runs the hardware implementation may be less expensive than the software implementation. Often a design may be developed and tested in a software form and later transformed, by well-known design rules, to an equivalent hardware implementation in an ASIC that hardwires the instructions of the software. In the same manner as a machine controlled by a new ASIC is a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions may be viewed as a particular machine or apparatus.

[00119] FIG. 5 is a schematic diagram of embodiments of a means for fast rerouting 500. In embodiments, the means for fast rerouting 500 is implemented in a network apparatus 502 (e.g., a network element 109-121 or central entity 101). The network apparatus 502 includes receiving means 501. The receiving means 501 is configured to receive an IPv6 data packet or to receive a data stream to route to a destination network element. The network apparatus 502 includes transmission means 507 coupled to the receiving means 501. The transmission means 507 is configured to transmit or forward the IPv6 data packet or data stream to another network element.

[00120] The network apparatus 502 includes a storage means 503. The storage means 503 is coupled to at least one of the receiving means 501 or the transmission means 507. The storage means 503 is configured to store instructions. The network apparatus 502 also includes processing means 505. The processing means 505 is coupled to the storage means 503. The processing means 505 is configured to execute the instructions stored in the storage means 503 to perform the methods disclosed herein. [00121] FIG. 6 is an embodiment of a method 600 for implementing FRR by a NE (e.g., NE 115). The method may be performed after an IPv6 data packet with a fast reroute routing header (FRRH) is received by the NE on a reroute path, for instance, reroute path 126 (FIG. 1). The method 600 improves a FRR technique when a broken link or route is detected in a network and the FRR technique is implemented. The FRR technique constructs an IPv6 data packet without a fast rerouting header (FRRH). The data packet without the FRRH is sent on a PPR in order to forward the IPv6 data packet without the FRRH to a downstream NE and be productively forwarded to its original destination NE. In embodiments, the PPR is PPR 124. The FRR technique minimizes the impact on a maximum transmittable unit in forwarding the IPv6 data packet without the FRRH so as to provide a lower encapsulation“tax” during FRR and eliminates dropped packets in the network as the network re-converges. Also, method 600 improves FRR without changing on-path routers (e.g., nodes/NE). Therefore, as a practical matter, the FRR technique improves the performance of NEs in the network and the overall network, which leads to a better user experience.

[00122] At step 602, the NE receives a data packet with a FRRH on a reroute path. For instance, the NE receives the data packet with the FRRH from a point of local repair (PLR) NE. In embodiments, the data packet with the FRRH is an IPv6 data packet with the FRRH 290 as shown In FIG. 2E. In embodiments, the IPv6 data packet with the FRRH comprises an IP header and a Payload. The FRRH may include at least 24 bytes of data. In embodiments, the FRRH may be a SRH or a routing header.

[00123] At step 604, the NE transfers a first PPR-ID and a next header into an IP header of the IPv6 data packet with the FRRH. For instance, the NE updates a first PPR-ID and a next header from the FRRH into the IP header of the IPv6 data packet with the FRRH. The first PPR-ID may be an IPv6 address of a destination NE of a PPR. The NE updates the IP header of the data packet with the FRRH. In embodiments, the NE updates the IP header of the data packet with the FRRH to include a payload length and a hop limit.

[00124] At step 606, the NE removes the FRRH . In embodiments, the NE removes the FRRH from the IPv6 data packet with the FRRH by deleting the FRRH.

[00125] At step 608, the NE updates a payload length and a hop limit in the IP header. In embodiments, the NE decrements the size of the payload length field by the size of the FRRH. In embodiments, the hop limit field is decremented by 1 to represent the hop that the IPv6 data packet with the FRRH has performed.

[00126] At step 610, the NE forwards the IPv6 data packet without the FRRH on a PPR. In embodiments, the NE forwards the IPv6 data packet without the FRRH according to the first PPR- ID. The steps 602 to 610 may be done in a different manner than indicated.

[00127] While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

[00128] In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. 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. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.

Claims

CLAIMS What is claimed is:

1. A method performed by a network element (NE) on a first preferred path route (PPR) in a network, comprising:

detecting a failure in the first preferred path route (PPR);

receiving a data packet, wherein the data packet comprises a first PPR identifier (PPR-ID) indicating the first PPR in an Internet Protocol (IP) header of the data packet;

in response to detecting the failure:

adding a fast reroute routing header (FRRH) to the data packet;

transferring the first PPR identifier (PPR-ID) from the IP header of the data packet to the FRRH;

updating the IP header of the data packet to include a second PPR-ID; and forwarding the data packet with the FRRH on a reroute path according to the second PPR-ID.

2. The method according to claim 2, wherein the first PPR-ID is an Internet Protocol version 6 (IPv6) address of a destination NE.

3. The method according to any one of claims 1 to 2, further comprising retrieving the second PPR-ID from local storage.

4. The method according to any one of claims 1 to 3, wherein the data packet is an IP version 6 (IPv6) data packet.

5. The method according to any one of claims 1 to 4, wherein the second PPR-ID is a second destination IP version 6 address of a second network element in the reroute path.

6. The method according to any one of claims 1 to 5, wherein the NE is a point of local repair (PLR) NE.

7. The method according to any one of claims 1 to 6, further comprising transferring a next header from the Internet Protocol (IP) header to the FRRH.

8. The method according to any one of claims 1 to 7, further comprising updating the IP header of the data packet to include a second next header and an updated payload length including the FRRH length.

9. The method according to any one of claims 1 to 8, wherein the failure is between the NE and a second NE on the first PPR, wherein the reroute path connects the NE and the second NE, and wherein the step of forwarding the data packet with the FRRH on a reroute path according to the second PPR-ID avoids the failure.

10. The method according to any one of claims 1 to 9, further comprising determining a repair topology of the network by the NE.

11. The method according to any one of claims 1 to 10, wherein the FRRH has at least 24 bytes of data.

12. The method according to any one of claims 1 to 11, further comprising receiving the first PPR-ID and the second PPR-ID from a central entity or provisioned locally at the NE.

13. The method according to any one of claims 1 to 12, wherein the FRRH is a segment routing header (SRH).

14. The method according to any one of claims 1 to 12, wherein the FRRH is a routing header.

15. A method performed by a network element (NE) in a network, comprising:

receiving a data packet with a fast reroute routing header (FRRH) on a reroute path;

transferring a first preferred path route (PPR) identifier (PPR-ID) and a second next header from the FRRH to an Internet Protocol (IP) header of the data packet with the FRRH;

removing the FRRH;

updating a payload length and a hop limit in the IP header of the data packet; and forwarding the data packet without the FRRH on a first PPR according to the first PPR-ID.

16. The method according to claim 15, wherein the first PPR-ID is an Internet Protocol version 6 (IPv6) address of a destination NE.

17. The method according to any one of claims 15 to 16, wherein the data packet with the FRRH is an IP version 6 (IPv6) data packet.

18. The method according to any one of claims 15 to 17, further comprising receiving the data packet with the FRRH from a point of local repair (PLR) NE.

19. The method according to any one of claims 15 to 18, wherein the IP header of the data packet without the FRRH comprises a second PPR-ID before transferring the first PPR-ID from the FRRH.

20. The method according to any one of claims 15 to 19, wherein the FRRH has at least 24 bytes of data.

21. The method according to any one of claims 15 to 20, wherein the FRRH is a segment routing header (SRH).

22. The method according to any one of claims 15 to 20, wherein the FRRH is a routing header.

23. A network element (NE) in a network, comprising:

a memory storing instructions;

a forwarding information database including data associated with a reroute path; and a processor configured to execute the instructions, which cause the processor to be configured to:

detect a failure in a first preferred path route (PPR); receive a data packet, wherein the data packet comprises a first PPR identifier (PPR-ID) indicating the first PPR in an Internet Protocol (IP) header of the data packet; in response to detecting the failure:

add a fast reroute routing header (FRRH) to the data packet;

transfer the first PPR identifier (PPR-ID) from the IP header of the data packet to the FRRH;

update the IP header of the data packet to include a second PPR-ID; and forward the data packet with the FRRH on a reroute path according to the second PPR-ID.

24. The NE according to claim 23, wherein the first PPR-ID is an Internet Protocol version 6 (IPv6) address of a destination NE.

25. The NE according to any one of claims 23 to 24, wherein the instructions further cause the processor to retrieve the second PPR-ID from local storage.

26. The NE according to any one of claims 23 to 25, wherein the data packet is an IP version 6 (IPv6) data packet.

27. The NE according to any one of claims 23 to 26, wherein the second PPR-ID is a second destination IP version 6 address of a second network element in the reroute path.

28. The NE according to any one of claims 23 to 27, wherein the NE is a point of local repair (PLR) NE.

29. The NE according to any one of claims 23 to 28, wherein the instructions further cause the processor to transfer a next header from the Internet Protocol (IP) header to the FRRH.

30. The NE according to any one of claims 23 to 29, wherein the instructions further cause the processor to update the IP header of the data packet to include a second next header and an updated payload length including the FRRH length.

31. The NE according to any one of claims 23 to 30, wherein the failure is between the NE and a second NE on the first PPR, wherein the reroute path connects the NE and the second NE, and wherein the instructions to cause the processor to forward the data packet with the FRRH on the reroute path avoids the failure.

32. The NE according to any one of claims 23 to 31, wherein the instructions further cause the processor to determine a repair topology of the network by the NE.

33. The NE according to any one of claims 23 to 32, wherein the FRRH has at least 24 bytes of data.

34. The NE according to any one of claims 23 to 33, wherein the instructions further cause the processor to receive the first PPR-ID and the second PPR-ID from a central entity or provisioned locally at the NE.

35. The NE according to any one of claims 23 to 34 wherein the FRRH is a segment routing header (SRH).

36. The NE according to any one of claims 23 to 34, wherein the FRRH is a routing header.

37. A network element (NE) in a network, comprising:

a memory storing instructions; and

a forwarding information database including data associated with a preferred path route (PPR); and

a processor configured to execute the instructions, which cause the processor to be configured to:

receive a data packet with a fast reroute routing header (FRRH) on a reroute path; transfer a first preferred path route (PPR) identifier (PPR-ID) and a second next header from the FRRH to an Internet Protocol (IP) header of the data packet with the FRRH;

remove the FRRH;

update a payload length and a hop limit in the IP header of the data packet; and forward the data packet without the FRRH on a first PPR according to the first

PPR-ID.

38. The NE according to claim 37, wherein the first PPR-ID is an Internet Protocol version 6 (IPv6) address of a destination NE.

39. The NE according to any one of claims 37 to 38, wherein the data packet with the FRRH is an IP version 6 (IPv6) data packet.

40. The NE according to any one of claims 37 to 39, wherein the instructions further cause the processor to receive the data packet with the FRRH from a point of local repair (PLR) NE.

41. The NE according to any one of claims 37 to 40, wherein the IP header of the data packet without the FRRH comprises a second PPR-ID before transferring the first PPR-ID from the

FRRH.

42. The NE according to any one of claims 37 to 41, wherein the FRRH has at least 24 bytes of data.

43. The NE according to any one of claims 37 to 42, wherein the FRRH is a SRH.

44. The NE according to any one of claims 37 to 42, wherein the FRRH is a routing header.

45. A non-transitory computer-readable medium configured to store a computer program product comprising computer executable instructions that, when executed by a processor of a network element (NE) implemented in a network, cause the processor to execute the method of any one of claims 1 to 14.

46. A non-transitory computer-readable medium configured to store a computer program product comprising computer executable instructions that, when executed by a processor of a network element (NE) implemented in a network, cause the processor to execute the method of any one of claims 15 to 22.

47. A system in a network, comprising:

a first network element (NE) on a preferred path route (PPR), wherein the first NE is configured to forward a data packet with a fast reroute routing header (FRRH) on a reroute path; and

a second NE coupled to the first NE and configured to receive the data packet with the FRRH, wherein the PPR connects the first NE and the second NE, and wherein the first NE is configured to execute the method of any one of claims 1 to 14.

48. The system according to claim 47, further comprising a third NE on the PPR, wherein a link connecting the first NE and the third NE fails.

49. The system according to any one of clams 47 to 48, further comprising at least one other NE on the reroute path and coupled to the first NE and the second NE.

50. A system in a network, comprising: a first network element (NE) on a preferred path route (PPR), wherein the first NE is configured to forward a data packet with a fast reroute routing header (FRRH) on a reroute path; and

a second NE coupled to the first NE and configured to receive the data packet with the FRRH, wherein the PPR connects the first NE and the second NE, and wherein the second NE is configured to execute the method of any one of claims 15 to 22.

51. The system according to claim 50, further comprising a third NE on the PPR, wherein a link connecting the first NE and the third NE fails.

52. The system according to any one of claims 50 to 51, further comprising at least one other NE on the reroute path and coupled to the first NE and the second NE.

53. A system in a network comprising a first NE of any of Claims 23-36 and a second NE of any of Claims 37-44, wherein the second NE is configured to receive the data packet from the first NE on the reroute path.

54. The system according to claim 53, further comprising a third NE on the first PPR, wherein the failure involves a link with the third NE.

55. The system according to any one of claims 53 and 54, further comprising at least one other NE on the reroute path and coupled to the first NE and the second NE.