Title of Invention: Explicit Backups and Fast Re-Route Mechanisms For Preferred Path Routes in a Network Abstract: A method implemented by a network element (NE) in a network, comprising receiving, by the NE, an advertisement comprising preferred path route (PPR) information and backup PPR information, the PPR information describing a PPR between a source and a destination in the network, the backup PPR information describing a backup PPR between the source and the destination, the PPR information comprising a PPR identifier (PPR-ID) and a plurality of PPR description elements (PPR-PDEs) each representing an element on the PPR, updating, by the NE, a local forwarding database to include the PPR information and the backup PPR information in association with a destination address of the destination, and transmitting, by the NE, a data packet based on the backup PPR information instead of the PPR information in response to an element on the PPR being unavailable due to a failure of an element along the PPR. Detailed Description: CROSS-REFERENCE TO RELATED APPLICATIONS The present application is a continuation of International Patent Application PCT/US2019/025635 filed Apr. 3, 2019 by Futurewei Technologies, Inc. and claims the benefit of U.S. Provisional Patent Application No. 62/666,946 filed May 5, 2018, by Alvaro Retana, et. al., and entitled “Explicit and Preferred Fast Re-Route Alternatives for Preferred Path Routes (PPR),” which is incorporated herein by reference as if reproduced in their entireties. FIELD OF INVENTION The present disclosure pertains to the field of preferred path routing. In particular, the present disclosure relates to provisioning backup loop free alternative paths and backup end-to-end preferred path routes (PPRs) for an original PPR. BACKGROUND In a network implementing source routing, a controller that has knowledge of a complete topology of the underlying network can program an ingress node of the network with a custom path that certain traffic has to travel to reach a destination. This custom path may not necessarily be the shortest path between the ingress node and the destination and may be programmed based on traffic engineering or business requirements. An ingress node in the network may use a separate flow classification technique to associate certain traffic flow with a custom path (e.g., a source and/or destination addresses/or transport layer port information). In a network implementing segment routing (SR), packets are steered through the network using segment identifiers (SIDs) that uniquely identify segments in the network. A segment may include one or more nodes, interfaces, and links between two nodes in the network. The SIDs are typically carried in the header of the packet. Currently there are two data planes that use segment routing to provision custom paths in a network—Segment Routing (SR) Multi-Protocol Label Switching (MPLS) (SR-MPLS) and SR-Internet Protocol (IP) Version 6 (IPv6) (SR-IPv6). In SR-MPLS, each segment is encoded as a label, and an ordered list of segments are encoded as a stack of labels in the header of the packet. Similarly, in SR-IPv6, each segment is encoded as an IPv6 address within a segment routing header (SRH). SUMMARY According to a first aspect of the present disclosure, there is provided a method implemented by a network element (NE) in a network, comprising receiving, by the NE, an advertisement comprising preferred path route (PPR) information and backup PPR information, the PPR information describing a PPR between a source and a destination in the network, the backup PPR information describing a backup PPR between the source and the destination, the PPR information comprising a PPR identifier (PPR-ID) and a plurality of PPR description elements (PPR-PDEs) each representing an element on the PPR, updating, by the NE, a local forwarding database to include the PPR information and the backup PPR information in association with a destination address of the destination, and transmitting, by the NE, a data packet based on the backup PPR information instead of the PPR information in response to an element on the PPR being unavailable due to a failure of an element along the PPR. In a first implementation of the method according to the first aspect, the backup PPR information comprises a backup PPR-PDE describing a backup element on the PPR, wherein transmitting the data packet based on the backup PPR information comprises transmitting the data packet to the backup element instead of a next element on the PPR in response to determining that the next element on the PPR is unavailable. In a second implementation of the method according to the first aspect or any preceding implementation of the first aspect, a PPR-PDE describing the NE and included in the plurality of PPR-PDEs comprises a flag indicating that the backup element is described in the backup PPR-PDE. In a third implementation of the method according to the first aspect or any preceding implementation of the first aspect, the local forwarding database is updated to include a plurality of PPR-PDEs in association with the destination address of the destination and a backup PPR-PDE in association with a PPR-PDE describing the NE. In a fourth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the method further comprises determining, by the NE, that a next element on the PPR is unavailable, searching, by the NE, the local forwarding database for a backup PPR-PDE describing a backup element for the next element on the PPR, and transmitting, by the NE, the data packet to the backup element instead of the next element on the PPR. In a fifth implementation of the method according to the first aspect or any preceding implementation of the first aspect, a backup element comprises at least one of a link, another NE, or a segment adjacent to the NE. In a sixth implementation of the method according to the first aspect or any preceding implementation of the first aspect, a next element comprises at least one of a link, another NE, or a segment adjacent to the NE. In a seventh implementation of the method according to the first aspect or any preceding implementation of the first aspect, an attribute associated with a resource reserved on the PPR matches an attribute associated with a resource reserved on the backup PPR. In an eighth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the local forwarding database is updated to include the PPR information and the backup PPR information only in response to determining that the NE is identified in one of the PPR-PDEs. In a ninth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the local forwarding database is updated to include the PPR information and the backup PPR information regardless of whether the NE is identified is identified in one of the PPR-PDEs. In a tenth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the advertisement comprises a flag set to indicate that the PPR-ID identifies a loose PPR between the source and the destination, and wherein the plurality of PPR-PDEs describes a subset of NEs on the PPR. In an eleventh implementation of the method according to the first aspect or any preceding implementation of the first aspect, in response to determining that the element on a path between two NEs of the loose PPR is unavailable, the method further comprises searching, by the NE, the local forwarding database for a backup PPR-PDE describing a backup element for a next element on the PPR, and transmitting, by the NE, the data packet to the backup element instead of the next element on the PPR. In a twelfth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the backup PPR information comprises a backup PPR-ID identifying the backup PPR, and wherein the local forwarding database includes a plurality of backup PPR-PDEs representing elements on the backup PPR. In a thirteenth implementation of the method according to the first aspect or any preceding implementation of the first aspect, wherein updating the local forwarding database to include the PPR information and the backup PPR information in association with the destination address of the destination comprises updating the local forwarding database to indicate that the data packet comprising the PPR-ID should be forwarded to a next element as indicated by one of a plurality of PPR-PDEs representing elements on the backup PPR in response to a next element on the PPR being unavailable. In a fourteenth implementation of the method according to the first aspect or any preceding implementation of the first aspect, further comprising determining, by the NE, that a next element on the PPR is unavailable, searching, by the NE, the local forwarding database for a backup PPR-ID describing the backup PPR, updating, by the NE, the data packet to include the backup PPR-ID instead of the PPR-ID, and transmitting, by the NE, the data packet along the backup PPR instead of the next element on the PPR. In a fifteenth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the backup PPR information includes a backup PPR-ID identifying the backup PPR and a backup PPR-PDE describing a backup element on the PPR. In a sixteenth implementation of the method according to the first aspect or any preceding implementation of the first aspect, further comprising determining, by the NE, that a next element on the PPR is unavailable, transmitting, by the NE, the data packet to a backup element instead of the next element on the PPR in response to the local forwarding database storing a backup PPR-PDE describing the backup element for the next element on the PPR, and transmitting, by the NE, the data packet along the backup PPR in response to the local forwarding database not storing the backup PPR-PDE describing the backup element for the next element on the PPR and in response to the local forwarding database storing a backup PPR-ID describing a backup PPR. In a seventeenth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the PPR information includes a flag indicating that the data packet should not be rerouted in response to the element on the PPR being unavailable. In an eighteenth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the PPR information includes a flag indicating that the data packet should be rerouted to a preconfigured loop free alternative (LFA) path in response to the element on the PPR being unavailable. In a nineteenth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the PPR is determined based on a network characteristic requested by the source. In a twentieth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the advertisement is received from at least one of a second NE in the network or a central entity of the network. In a twenty-first implementation of the method according to the first aspect or any preceding implementation of the first aspect, the PPR-ID is at least one of a Multi-Protocol Label Switching (MPLS) label, a segment identifier (SID), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address. According to a second aspect of the present disclosure, there is provided an NE implemented in a network. The NE comprises a receiver configured to receive an advertisement comprising preferred path route (PPR) information and backup PPR information, the PPR information describing a PPR between a source and a destination in the network, the backup PPR information describing a backup PPR between the source and the destination, the PPR information comprising a PPR identifier (PPR-ID) and a plurality of PPR description elements (PPR-PDEs) each representing an element on the PPR, a processor coupled to the receiver and configured to update a local forwarding database to include the PPR information and the backup PPR information in association with a destination address of the destination, and a transmitter coupled to the processor and configured to transmit a data packet based on the backup PPR information instead of the PPR information in response to an element on the PPR being unavailable due to a failure on an element of the PPR. According to a third aspect of the present disclosure, there is provided a non-transitory 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 receive an advertisement comprising preferred path route (PPR) information and backup PPR information, the PPR information describing a PPR between a source and a destination in the network, the backup PPR information describing a backup PPR between the source and the destination, the PPR information comprising a PPR identifier (PPR-ID) and a plurality of PPR description elements (PPR-PDEs) each representing an element on the PPR, update a local forwarding database to include the PPR information and the backup PPR information in association with a destination address of the destination, and transmit a data packet based on the backup PPR information instead of the PPR information in response to an element on the PPR being unavailable due to a failure on an element of the PPR. According to a fourth aspect of the present disclosure, there is provided an apparatus comprising a means for receiving an advertisement comprising preferred path route (PPR) information and backup PPR information, the PPR information describing a PPR between a source and a destination in the network, the backup PPR information describing a backup PPR between the source and the destination, the PPR information comprising a PPR identifier (PPR-ID) and a plurality of PPR description elements (PPR-PDEs) each representing an element on the PPR, a means for updating a local forwarding database to include the PPR information and the backup PPR information in association with a destination address of the destination, and a means for transmitting a data packet based on the backup PPR information instead of the PPR information in response to an element on the PPR being unavailable due to a failure on an element of the PPR. 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. 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 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. FIG. 1 is a diagram illustrating a network configured to implement preferred path routing according to various embodiments of the disclosure. FIG. 2 is a diagram illustrating the network configured to implement backup PPRs and fast re-route mechanisms in the control plane according to various embodiments of the disclosure. FIG. 3 is an embodiment of an NE in the network configured to implement preferred path routing according to various embodiments of the disclosure. FIG. 4 is a diagram illustrating a portion of the PPR information and backup PPR information that is sent to the NEs in the network in the control plane when a backup element is used as a backup PPR according to various embodiments of the disclosure. FIG. 5 is a diagram illustrating the use of a backup element in the data plane when a link along the PPR fails or is unavailable according to various embodiments of the disclosure. FIG. 6 is a diagram illustrating the use of a backup element in the data plane when an NE along the PPR fails or is unavailable according to various embodiments of the disclosure. FIG. 7 is a diagram illustrating the use of a backup element in the data plane when a link along a loose PPR fails or is unavailable according to various embodiments of the disclosure. FIG. 8 is a diagram illustrating a portion of the PPR information and backup PPR information that is sent to the NEs in the network in the control plane when a backup end-to-end PPR is used as the backup PPR according to various embodiments of the disclosure. FIG. 9 is a diagram illustrating the use of a backup end-to-end PPR in the data plane when an element along the PPR fails or is unavailable according to various embodiments of the disclosure. FIG. 10 is a diagram illustrating a portion of the PPR information and backup PPR information that is sent to the NEs in a network in the control plane when a backup end-to-end PPR tree is used as the backup PPR according to various embodiments of the disclosure. FIG. 11 is a diagram illustrating the use of a backup end-to-end PPR tree in the data plane when an element along the PPR fails or is unavailable according to various embodiments of the disclosure. FIG. 12 is a diagram illustrating a portion of the PPR information and backup PPR information that is sent to the NEs in the network in the control plane when both a backup element and a backup end-to-end PPR is used as the backup PPR according to various embodiments of the disclosure. FIG. 13 is a diagram illustrating the use of both a backup element and a backup end-to-end PPR in the data plane when an element along the PPR fails or is unavailable according to various embodiments of the disclosure. FIG. 14 is a method for implementing backup PPRs and fast re-route mechanisms according various embodiments of the disclosure. FIG. 15 shows an apparatus for implementing backup PPRs and fast re-route mechanisms according various embodiments of the disclosure. DETAILED DESCRIPTION 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. Existing mechanisms for determining end-to-end path failures in a network implementing source routing are slow, causes more cases for micro-loops, and excessively cumbersome. In addition, existing mechanisms for fast re-routing and provisioning backup paths do not implement backup paths that satisfy the original traffic engineering (TE) parameters that were used to provision the original end-to-end path. Disclosed herein are various embodiments directed to provisioning a backup PPR between a source and destination based on attributes defining a TE parameter or network characteristic of an original PPR. In an embodiment, traffic may be re-routed through the backup PPR when an element on the original PPR cannot be reached or is no longer available. In an embodiment, PPR information describing the original PPR and backup PPR information describing the backup PPR is sent to one or more NEs in the network. In various embodiments, the backup PPR may be implemented as a backup element, a backup end-to-end PPR, or a backup end-to-end PPR tree. FIG. 1 is a diagram illustrating a network 100 (also referred to herein as a “domain” or “subnetwork”) configured to implement preferred path routing according to various embodiments of the disclosure. The network 100 comprises a source 170, a destination 180, a central entity 171 (also referred to herein as a “controller”), two areas 150A and 150B, and central entity-to-area links 146 and 147. The source 170 is connected to network 100 via a source-to-domain link 172, and the destination 180 is connected to network 100 via a destination-to-domain link 173. In an embodiment, the central entity 171 may be a network or domain controller that maintains a topology of the network 100 to craft paths (both shortest paths 145 and PPRs 120) between edge NEs 101-113 in the network 100, as will be further described below. In an embodiment, the central entity is substantially similar to a Path Computation Element (PCE), which is further 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. In an embodiment, the central entity 171 may be substantially similar to a Software Defined Network Controller (SDNC), which is further described in the IETF RFC 8402 entitled “Segment Routing Architecture,” by C. Filsfils, dated July 2018. In an embodiment, the central entity 171 may be substantially similar to an Application Layer Traffic Optimization (ALTO) server, which is further described in the IETF RFC 7285, entitled “Application Layer Traffic Optimization (ALTO) Protocol,” by R. Alimi, dated September 2014. Areas 150A-B are subnetworks within the network 100 that may be associated with a specific geographic area or building. Each of areas 150A-B may be operated by a different operator or service provider. As shown by FIG. 1, area 150A comprises elements 101-107, 113, 122-128, and 135-137 (e.g., NEs 101-107 and 113 interconnected by links 122-128 and 135-137). Area 150B comprises elements 106-112 and 128-134 (e.g., NEs 106-112 interconnected by links 128-134). As shown by FIG. 1, areas 150A-B both share two NEs 106-107 and link 128. NEs 106-107 and link 128 may be configured to operate within both areas 150A-B using a packet forwarding protocol implemented by both areas 150A-B. In an embodiment, NEs 101-113 (also referred to herein as “nodes”) may be a topological devices (or physical devices), such as a router, a bridge, a network switch, or a logical device configured to perform switching and routing using the preferred path routing mechanisms disclosed herein. In an embodiment, one or more of the NEs 101-113 may be non-topological NEs, such as, for example, a function, context, service, or a virtual machine. In an embodiment, NEs 101-112 may be headend nodes or edge nodes positioned at an edge of the network 100, and NE 113 is an intermediary node positioned between one or more other NEs in network 100. For example, NE 101 may be an ingress node at which packets are received (either from a source or another NE from another network/domain), and NE 110 may an egress node from which traffic is transmitted (either to a destination or another NE in another network/domain). While NEs 101-112 are shown in FIG. 1 as headend nodes, it should be appreciated that NEs 101-112 may otherwise be an intermediate node (e.g., similar to NE 113) or any other type of NE. Although only thirteen NEs 101-113 are shown in FIG. 1, it should be appreciated that the network 100 shown in FIG. 1 may include any number of NEs. In an embodiment, the central entity 171 and NEs 101-113 are configured to implement various packet forwarding protocols, such as, but not limited to, Multi-Protocol Label Switching (MPLS), Segment Routing-MPLS (SR-MPLS), Internet Protocol (IP) Version 4 (IPv4), IP Version 6 (IPv6), Next Generation Explicit Routing (NGER), or Big Packet Protocol. In an embodiment, each area 150A and 150B may be configured to implement a different packet forwarding protocol. For example, NEs 101-107 and 113 in area 150A are configured to implement MPLS, while NEs 106-112 in area 150B are configured to implement IPv6. In such an embodiment, NEs 106 and 107, which are shared between the two areas 150A-B, may be configured to implement both packet forwarding protocols to ensure proper data transmission between areas 150A-B. The links 122-137 may be wired or wireless links or interfaces interconnecting each of the NEs 101-113 together. The central entity-to-area links 146-147 are also wired or wireless links or interfaces interconnecting at least one of the NEs 101-113 within an area 150A-B to the central entity 171. As described above, the source 170 is connected to network 100 via a source-to-domain link 172, and the destination 180 is connected to network 100 via a destination-to-domain link 173. The source-to-domain link 172 and the destination-to-domain link 173 may be wired or wireless links or interfaces interconnecting each of the source 170 and the destination 180 to an NE 101 and NE 110, respectively, of the network 100. In operation, the central entity 171 is configured to determine one or more shortest paths 145 between two edge NEs 101-113 in the network 100 and one or more PPRs 120 between two edge NEs 101-112 in the network 100. A shortest path 145 refers to a path between two NEs 101 and 110 (ingress NE 101 and egress NE 110) or between a source 170 and destination 180 that is 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, etc. In an embodiment, a shortest path 145 may be computed for a destination using a Dijkstra's Shortest Path First (SPF) algorithm. A PPR 120 (also referred to herein as a Non-Shortest Path (NSP)) refers to a custom path between an ingress NE 101 and an egress NE 110 or between a source 170 and destination 180 that is determined based on an application or server request. In an embodiment, the PPR 120 deviates from the shortest path 145. However, the PPR 120 may also be the same as the shortest path 145. In an embodiment, the central entity 171 is configured to determine the PPR 120 based on attributes specified for the PPR 120. As will be further described below, an attribute specified for the PPR 120 may be a TE parameter, network characteristics, or service requirement that is associated with a resource to be reserved on the PPR 120. In an embodiment, the attribute may include a bandwidth requirement, a maximum burst size, a latency requirement, a minimum jitter, a minimum error rate, a required throughput, etc. In an embodiment, reserving resources on the NEs 101-113 and links 122-137 of the PPR 120 according to the attributes specified for the PPR 120 ensures that data packets being transmitted along the PPR 120 satisfy a certain Quality of Service (QoS) parameter set by the source 170 of the PPR 120 or an operator of the network 100. In an embodiment, a source 170, or an ingress NE 101, transmits a request to the central entity 171 to compute a PPR 120 between the source 170 and the destination 180 (or between the ingress NE 101 and the egress NE 110) according to a particular attribute. In another embodiment, the attributes for a particular PPR 120 may be preconfigured at the central entity 171 by an operator or service provider of the network 100. In an embodiment, the central entity 171 is configured to determine the sequence of elements along PPR 120 according to the attribute requested. The PPRs 120 and the shortest paths 145 may each comprise a sequential ordering of one or more elements 101-113 and 122-137 (e.g., NEs 101-113 and links 122-137) in the network 100. As shown in FIG. 1, the shortest path 145 between ingress NE 101 and egress NE 110 includes the following elements: NE 101, link 122, NE 102, link 123, NE 103, link 127, NE 107, link 130, NE 108, link 131, NE 109, link 132, and NE 110. As described above, the shortest path 145 between ingress NE 101 and egress NE 110 is based on metrics of each of the elements 101-113 and 122-137 in the network 100. In contrast, the PPR 120 between ingress NE 101 and egress NE 110 includes the following elements: NE 101, link 124, NE 104, link 125, NE 105, link 126, NE 106, link 135, NE 112, link 134, NE 111, link 133, and NE 110. In an embodiment, the central entity 171 determines the elements on the PPR 120 based on an attribute, such as, bandwidth, latency, or burst size, of each of one or more of the elements (NE 101, link 124, NE 104, link 125, NE 105, link 126, NE 106, link 135, NE 112, link 134, NE 111, link 133, and NE 110) on PPR 120. After the central entity 171 determines the PPR 120 based on the attribute, the central entity 103 transmits PPR information describing the PPR 120 to a headend or ingress NE 101-112 in each area 150A-B of network 100. For example, the central entity 171 transmits PPR information describing the PPR 120 implemented in area 150A to NE 103 via central entity-to-area link 146. Similarly, the central entity 171 transmits PPR information describing the PPR 120 implemented in area 150B to NE 110 via central entity-to-area link 147. In an embodiment, the PPR information includes information that describes the PPR 120. The PPR information may include, for example, a PPR-identifier (ID) identifying the PPR 120. In an embodiment, the PPR-ID includes a single label, address, or ID identifying the PPR 120. For example, when the network 100 implements SR-MPLS, the PPR-ID may be an MPLS label or an SID identifying a PPR. When the network 100 implements SRv6, the PPR-ID may be an SRv6 SID identifying a PPR. When the network 100 implements IPv4, the PPR-ID may be an IPv4 address or prefix identifying a PPR. Similarly, when the network 100 implements IPv6, the PPR-ID may be an IPv6 address or prefix identifying a PPR. The PPR information also includes multiple PPR-path description elements (PDEs) describing one or more elements (NE 101, link 124, NE 104, link 125, NE 105, link 126, NE 106, link 135, NE 112, link 134, NE 111, link 133, and NE 110) or segments including one or more of the elements on the PPR 120. In an embodiment, each of the PPR-PDEs includes a label, address, or ID of one or more of the elements 101, 124, 104, 125, 105, 126, 106, 135, 112, 134, 111, 133, and 110 or segments including one or more of the elements on the PPR 120. In an embodiment, the PPR-PDEs include a sequential ordering of MPLS labels, IPV6 addresses, or IPv4 addresses that specify the actual path (e.g., one or more of the elements 101, 124, 104, 125, 105, 126, 106, 135, 112, 134, 111, 133, and 110 on the PPR 120) toward a destination address of the egress NE 110 or the destination 180 (also referred to herein as a “prefix”). In an embodiment, each of the PPR-PDEs may also define whether the element being described is a topological NE or a non-topological NE. In various embodiments, two types of PPRs 120 may be described by the PPR-PDEs, a strict PPR 120 and a loose PPR 120. In a strict PPR 120, every single NE (NE 101, NE 104, NE 105, NE 106, NE 112, NE 111, and NE 110) along the PPR 120 is specified or described in its own PPR-PDE. In a loose PPR 120, certain elements 101, 124, 104, 125, 105, 126, 106, 135, 112, 134, 111, 133, and 110 (also referred to herein as “hops”) along a PPR 120 may be skipped such that only a subset of the elements 101, 124, 104, 125, 105, 126, 106, 135, 112, 134, 111, 133, and 110 along a PPR 120 is specified or described in its own PPR-PDE. When loose PPRs 120 are described by the PPR-PDEs, the NEs along the path use shortest path routing in between elements that are not explicitly specified in a PPR-PDE (i.e., to reach the next topological PDE of the loose PPR 120). The PPR information may include several other descriptive elements, which are further described in Patent Cooperation Treaty (PCT) Application No. PCT/US2019/015419, entitled “Advertising and Programming Preferred Path Routes using Interior Gateway Protocols,” by Uma S. Chunduri, et. al., and filed on Jan. 28, 2019 (hereinafter referred to as the “PPR Patent”). The PPR information may also include one or more attributes associated with a resource to be reserved on the PPR 120. As described above, the attribute refers to a TE parameter network characteristic that should be satisfied when reserving a resource on the PPR 120. Examples of attributes specified for a PPR 120 may include bandwidth, burst size, latency, and lifetime, which is further described in PCT Application No. PCT/US2019/______, entitled “Resource Reservation and Maintenance for Preferred Path Routes in a Network,” by Uma S. Chunduri, et. al., and filed on XXX (hereinafter referred to as the “Attributes Patent”). In one embodiment, the PPR information includes a flag that indicates whether all the NEs 101-113 in the network 100 should store the PPR information or whether only the NEs 101-113 identified in a PPR-PDE of the PPR information should store the PPR information. For example, suppose the flag in the PPR information indicates that all the NEs 101-113 in the network 100 should store the PPR information. In this case, after receiving the PPR information from the central entity 171, the NEs 103 and 110 update a local forwarding database to include an entry including the PPR information for a destination address corresponding to the egress NE 110 or the destination 180. In an embodiment, the local forwarding database is updated by adding another entry for a particular destination ID or address of the egress NE 110 or the destination 180. The new entry includes at least one of the PPR-ID, each of the PPR-PDEs corresponding the PPR-ID, an ID or address of the next element 101, 124, 104, 125, 105, 126, 106, 135, 112, 134, 111, 133, or 110 on the PPR 120 to which to forward a data packet, and/or the one or more attributes specified for the PPR 120. In this embodiment, NEs 103 and 110 are configured to update the local forwarding database to include the PPR information relative to a destination address of the egress NE 110 or the destination 180 regardless of whether the NE 103 or 110 is identified in a PPR-PDE of the PPR information. In contrast, suppose the flag in the PPR information indicates that only the NEs 101-113 identified in a PPR-PDE of the PPR information should store the PPR information. In this case, after receiving the PPR information, NEs 103 and 110 first determine whether the NEs 103 and 110 are identified in a PPR-PDE of the PPR information. When a PPR-PDE does not identify the NE 103 or 110, NEs 103 and 110 ignore the PPR information. However, when a PPR-PDE identifies the NE 103 or 110, the NE 103 or 110 updates a local forwarding database to include an entry including the PPR information for a destination address corresponding to the egress NE 110 or the destination 180. After receiving the PPR information and updating a local forwarding database, the NEs 103 and 110 send (or flood) an advertisement including the PPR information to all of the other NEs 101-113 in the respective area 150A-B of network 100 using the underlying Interior Gateway Protocol (IGP) of the respective area 150A-B. The advertisement including the PPR information may be encoded and flooded through the respective area 150A-B using an IGP, such as, for example, Open Shortest Path First (OSPF) Version 2 (OSPFv2), OSPF Version 3 (OSPFv3), Intermediate System—Intermediate System (IS-IS), or direct SDN. For example, after receiving the PPR information, the NE 103 transmits (or floods) the PPR information to NEs 101-102, 104-107, and 113 in area 150A according to the IGP implemented by area 150A. Similarly, after receiving the PPR information, NE 110 transmits (or floods) the PPR information to NEs 106-109 and 111-112 in area 150B according to the IGP implemented by area 150B. In an embodiment, each of the receiving NEs 101-102, 104-107, 106-109, and 111-112 either updates the local forwarding database to include the PPR information or ignores the PPR information. The decision as to whether to update the local forwarding database or ignore the PPR information is based on whether the flag in the PPR information indicates that all the NEs 101-113 update a local forwarding database or that only the NEs 101-113 identified in a PPR-PDE of the PPR information are to update the local forwarding database. In the data plane, NEs 101-113 receive data packets that include a PPR-ID, for example, in a header of the data packet. Each of the NEs 101-113 obtains the PPR-ID from the data packet, and then performs a look up on the local forwarding database to obtain the PPR-PDEs corresponding to the PPR-ID in the data packet. The PPR-PDEs corresponding to the PPR-ID include labels, addresses, or IDs of one or more next elements (e.g., NEs 101-113 or links 122-137) on the PPR 120. For example, ingress NE 101 may receive a data packet comprising a PPR-ID in a header of the data packet. The ingress NE 101 extracts the PPR-ID from the data packet and searches the local forwarding database for one or more PPR-PDEs corresponding to the PPR-ID. The PPR-PDEs stored in association with the PPR-ID indicates that the next element (or next hop) along which to transport the data packet is NE 104. For example, a PPR-PDE identifying the next element may include a label, address, or ID of NE 104. The ingress NE 103 then transmits the data packet to NE 104 along link 124. NEs 104, 105, 106, 112, and 113 on the PPR 120 are configured to forward data packets along the PPR 120 in a similar fashion. In network 100, when a failure occurs on a link 122-137 on a shortest path 145 or a PPR 120, each of the NEs 101-113 first signal the failure to other NEs 101-113 in the area 150A-B or the network 100 via the underlying IGP. In the event of a failure on a link 122-137, the NEs 101-113 are also typically configured to transmit data packets along a loop free alternate (LFA) path 143 that is pre-configured at the NEs 101-113. A LFA path 143 refers to an alternative path through the network 100 which is different from the PPR 120 and the shortest path 145. The LFA path 143 is computed to reduce the packet loss that occurs when routers converge after topology changes due to a failure on a link 122-137 or a failure of an NE 101-113 on a path. The LFA path 143 is an alternative path by which NE 105 may transmit packets when a failure 161 occurs at link 126 that interconnects NE 105 and 106. As shown in FIG. 1, the LFA path 143 includes NE 105, link 136, NE 113, link 137, NE 107, link 130, NE 108, link 131, NE 109, link 132, and NE 110. NE 105 is configured to detect the failure 161 and automatically redirects data packets through the LFA path 143 instead of link 126. The different variations of an LFA path 143, such as a remote-LFA (RLFA), RLFA with directed forwarding (DLFA), and Topology Independent LFA (TI-LFA), is further described in the Network Working Group (NWG) Internet Draft Document, entitled “Topology Independent Fast Reroute using Segment Routing,” by A. Bashandy, et. al., dated Oct. 4, 2018. In some cases, data packets comprising the PPR-ID and intended to be transmitted along the PPR 120 may also be redirected along the LFA path 143 instead of the PPR 120. However, the LFA path 143 is pre-configured at NE 105, and may not satisfy the same attributes that the original PPR 120 satisfied. For example, PPR 120 may have been provisioned according to an attribute that specified a maximum bandwidth permitted on a link 122-137 along the PPR 120. However, the links 136, 137, 130, 131, and link 132 along the LFA 143 may not satisfy the same maximum bandwidth attribute that the links 124, 125, 126, 135, 134, and 133 along PPR 120 satisfied. Therefore, data packets comprising PPR-ID cannot be effectively redirected along the LFA path 143 when a failure occurs on an element of the PPR 120. The embodiments disclosed herein are directed to advertising and programming backup PPR information regarding backup PPRs that may satisfy substantially the same attributes of the original PPR 120. In an embodiment, the central entity 171 determines the PPR 120 and backup PPR information describing a backup PPR that should be used when an element on the PPR 120 fails or is unavailable. The backup PPR information includes information regarding a backup element by which to redirect data packets when an element on the PPR 120 fails or is unavailable. The backup PPR information may also include information regarding an end-to-end backup PPR that should be used when an element on the PPR 120 fails or is unavailable. The central entity 171 may send the backup PPR information along with the original PPR information to a headend NE 101-112 such that the headend NE 101-112 floods the area 150A-B with the original PPR information with the original PPR information and the backup PPR information. FIG. 2 is a diagram illustrating the network 200 configured to implement backup PPRs and fast re-route mechanisms in the control plane according to various embodiments of the disclosure. The network 200 shown in FIG. 2 is similar to network 100 shown in FIG. 1, except that in network 200, when a failure 161 occurs on link 126, NE 105 redirects data packets with the PPR-ID along the backup PPR 205, instead of the LFA path 143. As shown by FIG. 2, the backup PPR 205 extends from NE 105, link 136, NE 113, link 138, and back to NE 112, which is on the original PPR 120. In the embodiment show in FIG. 2, the backup PPR 205 converges with the original PPR 120 at NE 112 such that the original PPR 120 resumes at NE 105 and proceeds along link 134, NE 111, link 133, and egress NE 110. In another embodiment, and as will be further described below, the backup PPR 205 may not converge with the original PPR 120, but may instead include a sequence of other NEs 101-113 in the network 200 that may be used to reach the egress NE 110. In an embodiment, the backup PPR 205 satisfies the same or substantially the same attributes as the original PPR 120. As described above, the central entity 171, which has knowledge of the underlying topology of the network 200, determines the PPR 120 according to a request received from an application or service. In one embodiment, the request includes the attributes that are to be satisfied by the PPR 120. In another embodiment, the operator of the network 200 may input the attributes to the central entity 171 such that the central entity 171 determines the PPR 120 based on the attributes. After determining the sequence of elements (e.g., NE 101, link 124, NE 104, link 125, NE 105, link 126, NE 106, link 135, NE 112, link 134, NE 111, link 133, and NE 110) on the PPR 120, the central entity 171 generates PPR information 210 describing the PPR 120. In an embodiment, PPR information 210 includes the PPR-ID 215, PPR-PDEs 220, and one or more attributes 225. As described above, the PPR-ID 215 is a label, address, or ID that uniquely identifies the PPR 120. The PPR-PDEs 220 include information describing one or more of the elements (e.g., NE 101, link 124, NE 104, link 125, NE 105, link 126, NE 106, link 135, NE 112, link 134, NE 111, link 133, and NE 110) on the PPR 120. The attributes 225 refer to network characteristics or TE parameters by which a certain resource on the PPR 120 is reserved. In an embodiment, the attributes 225 are enforced by one or more elements 101, 124, 104, 125, 105, 126, 106, 135, 112, 134, 111, 133, and 110 on the PPR 120 to ensure that the PPR 120 satisfies certain QoS parameters. In an embodiment, the central entity 171 also determines the backup PPR 205 for the PPR 120 that satisfies the same attributes as PPR 120. After determining the sequence of elements (e.g., NE 105, link 136, NE 113, link 138, and NE 112) on the backup PPR 205, the central entity 171 generates the backup PPR information 230 describing the backup PPR 205. In one embodiment, the backup PPR information 230 includes one or more backup PPR-PDEs 240 describing a backup element (NE 113 and/or links 136 and 138) on the backup PPR 205. The backup PPR-PDE 240 may also include an address, label, or ID identifying the backup element on the backup PPR 205. In one embodiment, the backup PPR information 230 includes a backup PPR-ID 235 that uniquely identifies the backup PPR 205. The backup PPR-ID 235 may also be an address, label, or ID that identifies the backup PPR 205. In one embodiment, the backup PPR information 230 includes both the backup PPR-ID 235 and one or more backup PPR-PDEs 240. In an embodiment, the backup PPR information 230 also includes backup PPR flags 245, which may a bit that indicates a type of backup path to use when an element on the PPR 120 fails or is unavailable. In an embodiment, the backup PPR information 230 includes a backup PPR flag 245, or bit, indicating whether a backup end-to-end PPR should be used to redirect data packets comprising the PPR-ID 215 when a failure occurs on the PPR 120. In an embodiment, the backup PPR information 230 includes a backup PPR flag 245, or bit, indicating whether a backup end-to-end PPR tree should be used to redirect data packets comprising the PPR-ID 215 when a failure occurs on the PPR 120. In an embodiment, the backup PPR flag 245 may also indicate whether a backup element should be used to redirect data packets comprising the PPR-ID 215 when a failure occurs on the PPR 120. The backup PPR flag 245 may also indicate whether an LFA path 143 should be used to redirect data packets comprising the PPR-ID 215 when a failure occurs on the PPR 120. The backup PPR flag 245 may also indicate that data packets comprising the PPR-ID 215 should be dropped and not redirected when a failure occurs on the PPR 120. After the central entity 171 generates the PPR information 210 and the backup PPR information 230, the central entity 171 transmits the PPR information 210 and the backup PPR information 230 to a headend NE 101-112 in each area 150A-B of network 200. As shown in FIG. 2, the central entity 171 may transmit the PPR information 210 and the backup PPR information 230 to headend NE 103 in area 150A via central entity-to-area link 146. Similarly, the central entity 171 may transmit the PPR information 210 and the backup PPR information 230 to headend NE 110 via central entity-to-area link 147. In an embodiment, the headend NE 103 in area 150A floods (e.g., transmits) the PPR information 210 and the backup PPR information 230 to the other NEs 101-102, 104-107, and 113 in area 150A. For example, NE 103 transmits the PPR information 210 and the backup PPR information 230 to neighboring NEs 102 and 107. NE 102 transmits the PPR information 210 and the backup PPR information 230 to neighboring NE 101, and NE 107 transmits the PPR information 210 and the backup PPR information 230 to neighboring NE 106. In this way, the PPR information 210 and the backup PPR information 230 is flooded through the area 150A. Similarly, the headend NE 110 floods the PPR information 210 and the backup PPR information 230 to the other NEs 106-109 and 111-112 in the area 150B. As described above, the PPR information 210 may include a flag indicating whether every single NE 101-113 should update the local forwarding database to include the PPR information 210 and the backup PPR information 230. Alternatively, the PPR information 210 may include a flag indicating whether only the NEs 101-113 identified in the PPR-PDEs 220 and/or backup PPR-PDEs 240 should update the local forwarding database to include the PPR information 210 and the backup PPR information 230. Updating the local forwarding database to include the PPR information 210 and the backup PPR information 230 includes adding an entry in the local forwarding database corresponding to the destination (e.g., destination address of the destination 180 or the address of egress NE 110). The entry includes the PPR information 210 and the backup PPR information 230. After updating the local forwarding database to include the PPR information 210 and the backup PPR information 230, the relevant NEs 101-113 are programmed to implement fast re-routing mechanisms for PPR 120 using the backup PPR information 230. In an embodiment, the backup PPR information 230 may include information regarding a backup PPR 205 consisting of a backup element, such that data packets including the PPR-ID 215 should be redirected to the backup
{'application_number': '<application-reference appl-type="utility">\n<document-id>\n<country>US</country>\n<doc-number>17083039</doc-number>\n<date>20201028</date>\n</document-id>\n</application-reference>', 'publication_number': '<publication-reference>\n<document-id>\n<country>US</country>\n<doc-number>20210051092</doc-number>\n<kind>A1</kind>\n<date>20210218</date>\n</document-id>\n</publication-reference>', 'source_file': './application/2021/ipa210218.xml', 'source_data': 'USPTO-Application'}