WO2023250218A1

WO2023250218A1 - Pce for distributing binding for protection

Info

Publication number: WO2023250218A1
Application number: PCT/US2023/032891
Authority: WO
Inventors: Huaimo Chen
Original assignee: Futurewei Technologies, Inc.
Priority date: 2022-09-29
Filing date: 2023-09-15
Publication date: 2023-12-28

Abstract

A method implemented by a controller configured to implement a path computation element (PCE) controller. The method includes transmitting a first message comprising binding information to a node for a segment routing (SR) path going through the node or receiving a second message comprising the binding information from the node for the SR path going through the node, where the binding information includes a binding segment identifier (SID) and a list of SIDs; transmitting a third message comprising binding protection information corresponding to the binding information to a protecting node, where the binding protection information includes the binding SID, the list of SIDs, and an identifier of the node; and instructing the protecting node to use the binding protection information to protect the binding SID of the failed node if the node fails.

Description

PCE for Distributing Binding for Protection

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional patent application number 63/411,340 filed September 29, 2022, by Futurewei Technologies, Inc., and titled “PCE for Distributing Binding for Protection,” which is incorporated by reference in its entirety.

TECHNICAL FIELD

[0002] The present application relates to network communication, and more specifically to distribution of binding segment identifiers (SIDs) and related information of a node for protecting the node.

BACKGROUND

[0003] Segment routing traffic engineering (SR-TE) is a technology that implements traffic engineering using segment routing. SR-TE supports the creation of explicit paths using segment lists comprising binding SIDs. An Internet Engineering Task Force (IETF) document entitled “Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks” by S. Sivabalan, et al., published March 2023 specifies how path computation element (PCE) may be used to distribute SR Policy to a node in a network. The SR Policy may comprise a binding which includes a binding SID and a path represented by a list of SIDs. For the node having the binding SID associated with the list of SIDs, the existing solution uses interior gateway protocol (IGP) extensions to advertise the binding SID associated with the list of SIDs to direct neighbors of the node.

SUMMARY

[0004] The present disclosure describes extensions to path computation element protocol (PCEP) for distributing information to a protecting node that may protect a failed node of a SR path. A PCE controller is used to distribute a binding to a node of the SR path or receives the binding from the node. The binding includes a binding SID and a path represented by a list of SIDs. In an embodiment, when a controller implementing PCEP (or simply, a PCE controller) sends the binding SID associated with the list of SIDs to the node or receives the binding SID associated with the list of SIDs from the node, the PCE controller uses PCEP extensions to also send the binding SID with the list of SIDs to direct neighbors of the node or upstream nodes of the node. For the SR path via the node with the binding SID, if the node fails, the neighboring node or the upstream node on the SR path uses the information to protect the binding SID of the failed node. Therefore, the PCEP extensions improve network reliability relative to current technology. [0005] A first aspect relates to a method implemented by a controller configured to implement a path computation element protocol (PCEP), the method comprising transmitting a first message comprising binding information to a node for a segment routing (SR) path going through the node or receiving a second message comprising the binding information from the node for the SR path going through the node, wherein the binding information includes a binding segment identifier (SID) and a list of SIDs; transmitting a third message comprising the binding protection information corresponding to the binding information to a protecting node, wherein the binding protection information includes the binding SID, the list of SIDs, and an identifier of the node; and instructing the protecting node to use the binding protection information to protect the binding SID of the failed node if the node fails.

[0006] Optionally, in any of the preceding aspects, another implementation of the aspect further comprises exchanging a capability of distributing the binding protection information with the protecting node in a PATH SETUP TYPE CAP ABILITY Type Length Value (TLV) with a Path Setup Type (PST) and a sub-TLV in an Open object of an Open message. [0007] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the PST comprises a value indicating that the controller supports the capability of binding protection information distribution.

[0008] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the sub-TLV is a binding protection information distribution capability sub-TLV, and wherein the sub-TLV comprises a type field, a length field, a reserved field, and a flags field.

[0009] Optionally, in any of the preceding aspects, another implementation of the aspect further comprising exchanging a capability of distributing the binding protection information with the protecting node using a PCECC-CAP ABILITY Sub-TLV comprised in a PATH SETUP TYPE CAP ABILITY TLV in an Open message

[0010] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the PCECC-CAP ABILITY Sub-TLV comprises a B flag field set to a value indicating that a path computation element protocol (PCEP) speaker supports the binding protection information distribution.

[0011] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first message is a path computation update request (PCUpd) message, and wherein the second message is a path computation label switched path (LSP) state report (PCRpt) message.

[0012] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the third message is a path computation update request (PCUpd) message.

[0013] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the PCUpd message comprises a request parameters (RP) object or stateful request parameters (SRP) object, and wherein the RP/SRP object comprises a PATH-SETUP-TYPE TLV with a Path Setup Type (PST) and a Node ID TLV comprising the identifier of the node. [0014] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the node ID TLV comprises an open shortest path first (OSPF) node ID TLV, an intermediate system to intermediate system (IS-IS) node ID TLV, a node traffic engineering (TE) node ID TLV, a node internet protocol version 4 (IPv4) address TLV, or a node internet protocol version 6 (IPv6) address TLV.

[0015] Optionally, in any of the preceding aspects, another implementation of the aspect further comprises transmitting a fourth message instructing the node to remove the binding information or receiving a fifth message from the node indicating that the binding information is removed from the node; and transmitting a sixth message instructing the protecting node to remove the binding protection information.

[0016] Optionally, in any of the preceding aspects, another implementation of the aspect further provides that each of the fourth message and the fifth message is a path computation update request (PCUpd) message comprising a TE-PATH-BINDING TLV with the binding SID and a R flag field set to 1, wherein the sixth message is a PCUpd message comprising the TE-PATH-BINDING TLV with the binding SID and the R flag field set to 1, an explicit route object (ERO) object with the SID list, and RP/SRP object with the identifier (ID) of the node.

[0017] Optionally, in any of the preceding aspects, another implementation of the aspect further provides that the binding protection information in the third message acts as an instruction.

[0018] A second aspect relates to a controller configured to implement a path computation element protocol (PCEP), comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to transmit a first message comprising binding information to a node for a segment routing (SR) path going through the node or receive a second message comprising the binding information from the node for the SR path going through the node, wherein the binding information includes a binding segment identifier (SID) and a list of SIDs; transmit a third message comprising binding protection information corresponding to the binding information to a protecting node, wherein the binding protection information includes the binding SID, the list of SIDs, and an identifier of the node; and instruct the protecting node to use the binding protection information to protect the binding SID of the failed node if the node fails.

[0019] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the one or more processors are further configured to exchange a capability of distributing the binding protection information with the protecting node in a PATH SETUP TYPE CAP ABILITY type length value (TLV) with a Path Setup Type (PST) and a sub-TLV in an Open object of an Open message.

[0020] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the PST comprises a value indicating that the PCE supports the capability of binding protection information distribution.

[0021] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the sub-TLV is a binding protection information distribution capability sub-TLV, and wherein the sub-TLV comprises a type field, a length field, a reserved field, and a flags field.

[0022] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the one or more processors are further configured to exchange a capability of distributing the binding protection information with the protecting node using a PCECC-CAP ABILITY Sub-TLV comprised in a PATH SETUP TYPE CAP ABILITY TLV in an Open message.

[0023] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the PCECC-CAP ABILITY Sub-TLV comprises a B flag field set to a value indicating that a path computation element protocol (PCEP) speaker supports the binding protection information distribution.

[0024] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first message is a path computation update request (PCUpd) message, and wherein the second message is a path computation label switched path (LSP) state report (PCRpt) message.

[0025] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the third message is a path computation update request (PCUpd) message.

[0026] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the PCUpd message comprises a request parameters (RP) object or stateful request parameters (SRP) object, and wherein the RP/SRP object comprises a PATH-SETUP-TYPE TLV with a Path Setup Type (PST) and a Node ID TLV comprising the identifier of the node.

[0027] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the node ID TLV comprises an Open Shortest Path First (OSPF) Node ID TLV, an Intermediate System to Intermediate System (IS-IS) Node ID TLV, a Node Traffic Engineering (TE) node ID TLV, a Node internet protocol version 4 (IPv4) address TLV, or a Node internet protocol version 6 (IPv6) address TLV.

[0028] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the one or more processors are further configured to transmit a fourth message instructing the node to remove the binding information or receive a fifth message from the node indicating that the binding information is removed from the node; and transmit a sixth message instructing the protecting node to remove the binding protection information.

[0029] Optionally, in any of the preceding aspects, another implementation of the aspect provides that each of the fourth message and the fifth message is a path computation update request (PCUpd) message comprising a TE-PATH-B INDING TLV with the binding SID and a R flag field set to 1 , and wherein the sixth message is a PCUpd message comprising the TE-PATH-BINDING TLV with the binding SID and the R flag field set to 1, an explicit route object (ERO) with the SID list, and RP/SRP object with the identifier (ID) of the node.

[0030] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the binding protection information in the third message acts as an instruction.

[0031] A third aspect relates to a non-transitory computer readable medium comprising a computer program product for use by a controller configured to implement a path computation element protocol (PCEiP), the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium that, when executed by one or more processors, cause the controller to execute the method of the first aspect.

[0032] A fourth aspect relates to a controller configured to implement a path computation element protocol (PCEP), comprising: means for transmitting a first message comprising binding information to a node for a segment routing (SR) path going through the node or receiving a second message comprising the binding information from the node for the SR path going through the node, wherein the binding information includes a binding segment identifier (SID) and a list of SIDs; means for transmitting a second message comprising binding protection information corresponding to the binding information to a protecting node, wherein the binding protection information includes the binding SID, the list of SIDs, and an identifier of the node; and means for instructing the protecting node to use the binding protection information to protect a binding SID of the failed node if the node fails. [0033] 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.

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

BRIEF DESCRIPTION OF THE DRAWINGS

[0035] 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.

[0036] FIG. 1 is a schematic diagram illustrating a network according to an embodiment of the present disclosure.

[0037] FIG. 2A is a schematic diagram illustrating a format of a binding SID (BSID) distribution protection capability sub-TLV according to an embodiment of the present disclosure.

[0038] FIG. 2B is a schematic diagram illustrating a format of a PATH- SETUP-TYPE- CAP ABILITY TLV according to an embodiment of the present disclosure.

[0039] FIG. 3 is a schematic diagram illustrating a format of a PCECC-CAP ABILITY Sub- TLV according to an embodiment of the present disclosure.

[0040] FIG. 4 is a schematic diagram illustrating a format of a PATH-SETUP-TYPE TLV according to an embodiment of the present disclosure.

[0041] FIG. 5A is a schematic diagram illustrating a format of an OSPF node ID TLV according to an embodiment of the present disclosure. [0042] FIG. 5B is a schematic diagram illustrating a format of an IS-IS node ID TLV according to an embodiment of the present disclosure.

[0043] FIG. 5C is a schematic diagram illustrating a format of a TE node ID TLV according to an embodiment of the present disclosure.

[0044] FIG. 5D is a schematic diagram illustrating a format of a Node IPv4 address TLV according to an embodiment of the present disclosure.

[0045] FIG. 5E is a schematic diagram illustrating a format of a Node IPv6 address TLV according to an embodiment of the present disclosure.

[0046] FIG. 6A is a schematic diagram illustrating a format of an RP Object with PATHSETUP-TYPE and Node ID TLVs according to an embodiment of the present disclosure.

[0047] FIG. 6B is a schematic diagram illustrating a format of an SRP Object with PATH- SETUP-TYPE and Node ID TLVs according to an embodiment of the present disclosure.

[0048] FIG. 7 is a flowchart of an embodiment of a method according to an embodiment of the present disclosure.

[0049] FIG. 8 is a schematic diagram illustrating a network element according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

[0050] It should be understood at the outset that, although illustrative implementations 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.

[0051] The present disclosure describes extensions to path computation element protocol (PCEP) for distributing information to a protecting node that may protect a failed node. A PCE controller is used to distribute a binding to a node or receive the binding from the node. The binding includes a binding SID and a path represented by a list of SIDs. In an embodiment, when a controller implementing PCEP (or simply, a PCE controller) sends a binding SID associated with a list of SIDs to a node or receives the binding SID associated with the list of SIDs from the node, the PCE controller uses PCEP extensions to also send the binding SID with the list of SIDs to direct neighbors or upstream nodes of the node. For an SR path via the node with the binding SID, if the node fails, the protecting node (e g., an upstream neighboring node) on the SR path uses the information to protect the binding SID of the failed node. Therefore, the PCEP extensions improve network reliability relative to current technology. To perform the above actions, the disclosed embodiments describe various extensions to PCEP using TLV and sub-TLV structures for representing the information for binding SID protection. The disclosed embodiments can be deployed in any router, switch, and controller, which are used by service providers around the world.

[0052] FIG. 1 is a schematic diagram illustrating a network topology 100 of a network 102 according to an embodiment of the present disclosure. The network 102 receives a packet from a content source (or a customer edge) 104. The content source 104 may be a network node, a server, a data center, or other telecommunications device configured to receive and respond to requests for content. The network 102 comprises a plurality of network nodes (or simply, nodes) 106, 108, 110, 112, 114, 116, 118, and 120. While eight network nodes 106-120 are shown in the network 102, more or fewer nodes may be included in practical applications. [0053] Each of the network nodes 106-120 may comprise a router, switch, or other telecommunications device configured to receive, route, store, and transmit packets. Some of the network nodes, namely the network nodes 106, 116, 118, and 120 are disposed at an edge of the network 102. The network nodes 106, 116, 118, and 120 receiving multicast packets from outside the network 102 may be referred to as an ingress network node (or simply, an ingress node). The network nodes 106, 116, 118, and 120 transmitting multicast packets out of the network 102 may be referred to as an egress network node (or simply, an egress node). Depending on the direction of multicast packet traffic, each of the network nodes 106, 116, 118, and 120 may function as an ingress network node or an egress network node. The network nodes 108, 110, 112, and 114 forwarding multicast packets in the network 102 may be referred to as a transit network node.

[0054] The network nodes 106 and 116 are in communication with a first customer edge (CE1) 104. In the illustrated embodiment, the CE1 104 is a content source. The content source (e.g., a server, a data center, etc.) is configured to store information or data (e.g., media files, web pages, etc.) and deliver such information or data to a consumer upon request. The network node 118 is in communication with a second customer edge (CE2) 122, and the network node 120 is in communication with a third customer edge (CE3) 124. As such, packets received from CE1 104 and transmitted through the network 102 may eventually be delivered to CE2 122 and/or CE3 124 for consumption by the consumer.

[0055] The customer edges 104, 122, and 124, and network nodes 106-120 in FIG. 1 are coupled to, and communicate with each other, via links 150. The links 150 may be wired, wireless, or some combination thereof. In an embodiment, each of the links 150 may have a cost. The cost of each of the links 150 may be the same or different, depending on the network topology 100 and the conditions therein. [0056] For ease of reference, the various network nodes have been given a letter and number designation in FIG. 1. For example, the content source 104 is designated CE1, the network nodes 106-120 are designated PEI, Pl to P4, PE2 to PE4, and so on. In an embodiment, the network 102 is controlled by a controller 160 configured to implement PCEP (or simply, a PCE controller). In normal operations, the PCE controller 160 controls the network 102 (e.g., manages each of the network nodes) through a control channel (e.g., a PCEP session) established between the PCE controller 160 and one or more of the network nodes. The PCE controller 160 sends instructions to the network nodes through the control channel to, for example, establish a tunnel traversing the network 102 and stores the instructions and/or a current status of the network 102 in a database after receiving the status from a node in the network 102.

[0057] In an embodiment, the PCE controller 160 may define a SR policy and advertise the SR policy with a SR path/tunnel to the ingress node of the SR path/tunnel in the network 102. The SR policy may carry a binding SID of a node. The SR path/tunnel includes the binding SID. The PCE controller 160 may send the binding information (or simply, binding) to the node or receive the binding information from the node. The binding information comprises the binding SID (BSID) and a path represented by a list of SIDs. In an embodiment, the PCE controller 160 may transmit a first message 170 comprising the binding information to a node (e.g., P2) for the SR path/tunnel going through the node. The PCE controller 160 may further send an indication to the node for replacing the binding SID with the list of SIDs when the node receives a packet with the binding SID. Thus, after the PCE controller 160 distributes the binding to the node, the node forwards the packet with the binding SID according to a first SID in the list. The node replaces the binding SID in the packet with the list of SIDs and forwards the packet using the Forwarding Information Base (FIB) entry for the top SID (i.e., the first SID) in the packet. In an embodiment, the first message 170 is a Path Computation Update Request (PCUpd) message. The PCUpd message comprises the binding SID and the list of SIDs associated with the binding SID. The binding SID is in the TE-PATH-B INDING TLV in the label switched path (LSP) object of the message. The list of SIDs is in the explicit route object (ERO) of the message. An Internet Engineering Task Force (IETF) document entitled “Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks” by S. Sivabalan, et al., published March 2023 specifies how path computation element (PCE) specifies the TE-PATH- B INDING TLV in the LSP object.

[0058] As shown in FIG. 1, the node P2 has four direct neighboring nodes Pl, P4, P3, and PE3. In an embodiment, direct means only one hop away. In an embodiment, the PCE controller 160 further transmits a second message 180 comprising binding protection information (or simply, binding protection or binding for protection) corresponding to the binding information to each possible protecting nodes of node P2 such as node P2’s neighbors Pl, P4, P3 and PE3.

[0059] In an embodiment, the binding protection information comprises the binding SID, the list of SIDs, and an identifier (ID) of the node P2. The PCE controller 160 may further send an instruction to the protecting nodes of node P2 (such as Pl, P4, P3 and PE3) to instruct the protecting nodes to use the binding protection information to protect the binding SID of the failed node if the node fails. In an embodiment, the second message 180 is a PCUpd message. The PCUpd message comprises the binding SID, the list of SIDs associated with the binding SID, and the identifier (ID) of the node P2. The binding SID is in the TE-PATH-BINDING TLV with the LSP object of the message. The list of SIDs is in the ERO object of the message. The identifier (ID) of the nodeP2 and the instruction are in the Request Parameters (RP) object or Stateful Request Parameters (SRP) object (RP/SRP) of the message. [0060] In FIG. 1, assume that node P2 fails (e.g., node failure) or a link connected to node P2 fails (e.g., link failure), which makes it appear that node P2 fails. If this occurs, suppose that a protecting node (e.g., an upstream neighbor as point-of-local-repair (PLR)) such as Pl, P4, P3, and PE3) of the node has the corresponding binding protection information for protecting the binding SID of the node. The binding protection information includes the binding SID, the list of SIDs, and an identifier of the node. After the upstream neighbor as PLR (such as Pl, P4, P3 and PE3) detects the failure of the node, the protecting node protects the binding SID of the failed node for a packet received with the node SID of the failed node. The protecting node pops the node SID, replaces the binding SID in the packet with the list of SIDs and forwards the packet towards the top SID (i.e., the first SID) as per the instructions received from the PCE controller 160. Thus, the packet does not go through the failed node.

[0061] In an embodiment, there is one protecting node of a node for an SR path going through the node. This one protecting node is an upstream neighbor node of the node. For example, in FIG. 1, assume that an SR path is from ingress node PEI to egress node PE4 via nodes Pl, P2 and P3 (i.e., PE1->P1->P2->P3->PE4), and is represented by node SID of PEI (SID-PEI), node SID of Pl (SID-P1), node SID of P2 (SID-P2), and binding SID (BSID) of P2 (BSID-P2). The binding SID BSID-P2 is associated with a SID list comprising node SID of P3 (SID-P3) and node SID of PE4 (SID-PE4). In an embodiment, the PCE controller 160 sends an LSP Initiate Request (PCInitiate) message comprising the SR path/tunnel to the ingress node PEI. The SR path is represented by SID-PEI, SID-P1, SID-P2, and BSID-P2. The PCE controller 160 further sends the binding to the node P2 in a first PCUpd message. The first PCUpd message comprises the binding SID BSID-P2 and the SID list comprising SID-P3 and SID-PE4. The PCE controller 160 sends the binding protection information to the upstream neighbor node Pl of node P2 on the SR path in a second PCUpd message. The second PCUpd message comprises the binding SID BSID- P2, the SID list comprising SID-P3 and SID-PE4, and the identifier (ID) of node P2. If node P2 fails, the upstream neighbor node Pl of node P2 along the SR path detects the failure. The node Pl as a protecting node protects the binding SID of the failed node P2 using the binding protecting information received. For a packet received with the node SID of the failed node P2 (SID-P2). The protecting node P 1 pops the node SID (SID-P2), replaces the binding SID (BSID-P2) in the packet with the list of SIDs <SID-P3, SID-PE4> and forwards the packet towards the top SID (i.e., the first SID SID-P3) as per the instructions received from the PCE controller 160. Thus, the packet does not go through the failed node P2. The packet is sent to node P3, which sends the packet to the egress node PE4.

[0062] In an embodiment, there are two protecting nodes of a node for an SR path going through the node. One protecting node is an upstream neighbor node of the node, and the other protecting node is an upstream node of the node, wherein the SR path includes node SID of the upstream node or an adjacent SID for an adjacency to the upstream node. For example, in FIG. 1, assume that an SR path is from ingress node PEI to egress node PE4 via nodes P2 and P3 (i.e., PE1->P2- >P3->PE4) and node Pl is on the shortest path from node PEI to node P2, and is represented by node SID of PEI (SID-PEI), node SID of P2 (SID-P2), and binding SID (BSID) of P2 (BSID-P2). The binding SID BSID-P2 is associated with a SID list comprising node SID of P3 (SID-P3) and node SID of PE4 (SID-PE4). There are two protecting nodes of node P2 for the SR path: node Pl and node PEI . In an embodiment, the PCE controller 160 sends an LSP Initiate Request (PCInitiate) message comprising the SR path/tunnel to the ingress node PEI. The SR path is represented by SID-PEI, SID-P2, and BSID-P2. The PCE controller 160 further sends the binding to the node P2 in a first PCUpd message. The first PCUpd message comprises the binding SID BSID-P2 and the SID list comprising SID-P3 and SID-PE4. The PCE controller 160 sends the binding protection information to each of the two protecting nodes (i.e., Pl and PEI) in a second PCUpd message. The second PCUpd message comprises the binding SID BSID-P2, the SID list comprising SID-P3 and SID-PE4, and the identifier (ID) of node P2. If node P2 fails and before IGP converges on the failure, the upstream neighbor node Pl of node P2 along the SR path detects the failure. The node Pl as a protecting node protects the binding SID of the failed node P2 using the binding protecting information received. For a packet received with the node SID of the failed node P2 (SID-P2). The protecting node Pl pops the node SID (SID-P2), replaces the binding SID (BSID-P2) in the packet with the list of SIDs <SID-P3, SID-PE4> and forwards the packet towards the top SID (i.e., the first SID SID-P3) as per the instructions received from the PCE controller 160. Thus, the packet does not go through the failed node P2. The packet is sent to node P3, which sends the packet to the egress node PE4. If node P2 fails and after IGP converges on the failure, the upstream node PEI of node P2 along the SR path knows the failure since there is no route to node SID of node P2. The node PEI as a protecting node protects the binding SID of the failed node P2 using the binding protecting information received. For a packet to be sent with the node SID of the failed node P2 (SID-P2), the protecting node PEI pops the node SID (SID-P2), replaces the binding SID (BSID-P2) in the packet with the list of SIDs <SID-P3, SID-PE4> and forwards the packet towards the top SID (i.e., the first SID SID-P3). Thus, the packet does not go through the failed node P2. The packet is sent to node P3, which sends the packet to the egress node PE4. [0063] The disclosed embodiments provide an efficient solution using extensions to PCEP for distributing the binding protection information to protecting nodes that may protect the failed node. For an SR path via the node with the binding SID, if the node fails, the protecting node on the SR path uses the information to protect the binding SID of the failed node. Thus, extensions to PCEP may resolve the issue of traffic being dropped at a node because of a failed node along the SR path and improve network reliability.

[0064] In an embodiment, after the PCE controller 160 sends the binding information to node P2, when the PCE controller 160 removes the binding information from node P2 through sending a third message to node P2 or receives a fourth message from node P2 indicating that the binding information is removed from node P2, the PCE controller 160 removes the corresponding binding protection information from each protecting node such as neighbor of node P2 through sending a fifth message to the protecting node. In an embodiment, each of the third message and fourth message is a PCUpd message, wherein the PCUpd message comprises the TE-PATH-BINDING TLV with the binding SID and a R flag field set to 1. The fifth message is a PCUpd message, wherein the PCUpd message comprises the TE-PATH-BINDING TLV with the binding SID and the R flag field set to 1, the ERO object with the SID list, and RP/SRP object with the identifier (ID) of the node P2 and the instruction.

[0065] In an embodiment, after PCE sends the binding information to node P2, when the PCE controller 160 changes the binding information in node P2 through sending a fifth message to node P2 to remove the binding information from node P2 and sending a sixth message with the changed binding information to node P2, the PCE controller 160 changes the corresponding binding protection information in each protecting node such as neighbor of node P2 through sending a seventh message to the protecting node to remove the corresponding binding protection information from the protecting node and sending an eighth message with the changed corresponding binding protection information to the protecting node. The fifth message is the same as or similar to the third message. The sixth message is similar to the first message. The seventh message is the same as or similar to the fourth message. The eighth message is similar to the second message.

[0066] FIGS. 2A-2B are schematic diagrams illustrating Type-Length- Value (TLV) and sub- TLV structures used to indicate capability of distributing binding for protection according to an embodiment of the present disclosure. In an embodiment, a path computation client (PCC) may run on each node in the network 102. The PCE controller 160 runs on a server as a controller to communicate with PCCs. The PCE controller 160 and the PCCs work together to distribute the binding protection information about a binding SID on a node to the possible protecting nodes for protecting the binding SID of the node if the node fails. When the PCE controller 160 and a PCC running on a network node establish a PCEP session between them, the PCE controller 160 and the PCC running on the node (PCC node for short) exchange capabilities of binding protection information distribution in Open messages. An Open message includes an Open object. The Open object comprises a PATH SETUP TYPE CAP ABILITY TLV with Path Setup Type (PST) and a plurality of sub-TLVs including a binding protection information distribution capability (BSID- D) sub-TLV.

[0067] FIG. 2A represents a format of BSID-D sub-TLV 200A comprising parameters/fields used for binding protection information distribution. The format of BSID-D sub-TLV 200 A comprises a type field 202, a length field 204, a reserved field 206, and a flags field 208. In an embodiment, the type field 202 comprises a value to be determined (TBD2) and to be assigned by IANA. The length field 204 comprises a value of 4. The reserved field 206 is 2 octets. The reserved field is set to zero (0) on transmission and ignored on receipt. The flags field 208 is 2 octets. The flags field is set to zero (0). [0068] FIG. 2B represents a format of PATH SETUP TYPE CAP ABILITY TLV 200B comprising a Path Setup Type (PST) field 210 and a sub-TLVs field 212. In an embodiment, the PST field 210 comprises a value that indicates that the PCC node is capable of receiving and processing the binding protection information about a binding SID on a node from the PCE controller 160 for protecting the binding SID of the node (e.g., node P2) if the node (e.g., node P2) fails. The sub-TLVs field 212 comprising a BSID-D sub-TLV 200 A as shown in FIG. 2A.

[0069] In an embodiment, a PCC node, which supports the capability of binding protection information distribution, sends the PCE controller 160 an Open message comprising a PATH SETUP TYPE CAP ABILITY TLV with Path Setup Type (PST) = TBD1 and a BSID-D sub-TLV. In an embodiment, PST = TBD1 indicates that the PCC node is capable of receiving and processing the binding protection information about a binding SID on a node from the PCE controller 160 for protecting the binding SID of the node if the node fails.

[0070] In an embodiment, the PCE controller 160, which supports the capability of binding protection information distribution, sends a PCC node an Open message comprising a PATH SETUP TYPE CAP ABILITY TLV with Path Setup Type (PST) = TBD1 and a BSID-D sub-TLV. In an embodiment, PST = TBD1 indicates that the PCE controller 160 supports the capability of binding protection information distribution.

[0071] In an embodiment, when both a PCC node and the PCE controller 160 support the capability of binding protection information distribution, each of the Open messages sent by the PCC node and the PCE controller 160 contains a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST = TBD1 and a BSID-D sub-TLV. [0072] In an embodiment, when the PCE controller 160 receives an Open message without a PATH- SETUP-TYPE-CAPABILITY TLV comprising PST = TBD1 from a PCC node, then the PCE controller 160 does not send the PCC node any binding protection information.

[0073] In an embodiment, when a PCC node receives an Open message without a PATH- SETUP-TYPE-CAPABILITY TLV comprising PST = TBD1 from the PCE controller 160, then the PCC node does ignore any binding protection information from the PCE controller 160.

[0074] FIG. 3 is a schematic diagram illustrating a format of PCECC-CAP ABILITY Sub-TLV 300 according to an embodiment of the present disclosure. In another embodiment, when PCE as a central controller (PCECC) is used, a PCC node (e.g., a protecting node such as neighbor node) and PCE exchange capability of binding protection information distribution using PCECC- CAP ABILITY Sub-TLV 300 which is included in the PATH SETUP TYPE CAP ABILITY TLV in an Open message.

[0075] The PCECC-CAP ABILITY Sub-TLV 300 comprises a type field 302, a length field 304, and a flags field 306 including a B flag field 308 and a L flag field 310. In an embodiment, the type field 302 comprises a value of 1. The length field 304 comprises a value of 4. The B flag field 308 is defined for binding SID protection. The B flag field 308 set to a value (e.g., 1) by a PCEP speaker (PCE or PCC) that indicates that the PCEP speaker supports and is willing to handle the PCECC based central controller instructions for binding SID protection. The B flag field 308 set to 1 by both a PCC node and a PCE controller for downloading/reporting the PCECC binding SID protection instruction on a PCEP session.

[0076] In an embodiment, after sending the binding information to P2, the PCE controller 160 sends the corresponding binding protection information to each protecting node (such as each neighbor) of the node P2 in a PCEP message. In an embodiment, the PCEP message is a Path Computation LSP Update Request (PCUpd) message. The PCUpd message comprises a request parameters (RP) object or stateful PCE request parameters (SRP) object, and a LSP object with a BSID of P2 (i.e. a node to be protected) and an ERO object with the SID list associated with the BSID. The RP/SRP object includes PATH- SETUP-TYPE TLV and node ID TLV comprising an identifier of the protected node.

[0077] FIG. 4 is a schematic diagram illustrating a format of PATH- SETUP-TYPE TLV 400 according to an embodiment of the present disclosure. The format of PATH- SETUP-TYPE TLV 400 comprises a type field 402, a length field 404, a reserved field 406, and a PST field 408. In an embodiment, the type field 402 comprises a value of 28. The length field 404 comprises a value of 4. The PST field 408 with a value PST = TBD1 indicates binding protection information for a binding SID of a node. The Reserved field 406 is set to zero (0) on transmission and ignored on receipt.

[0078] FIG. 5A is a schematic diagram illustrating a format of OSPF node ID TLV 500A according to an embodiment of the present disclosure. In one embodiment, the node ID TLV is an OSPF Node ID TLV 500A. The OSPF Node ID TLV 500A comprises a type field 502, a length field 504, and a Node ID field 506. In an embodiment, the type field 502 comprises a value (TBDa) to be assigned by IANA. The length field 504 comprises a value of 4 indicating the length of the TLV excluding the type field 502 and the length field 504. The Node ID field 506 is 4 octet and comprises an OSPF node (or router) ID of the node.

[0079] FIG. 5B is a schematic diagram illustrating a format of IS-IS node ID TLV 500B according to an embodiment of the present disclosure. In one embodiment, the node ID TLV is an IS-IS Node ID TLV 500B. The IS-IS Node ID TLV 500B comprises a type field 510, a length field 512, and a Node ID field 514. In an embodiment, the type field 510 comprises a value (TBDb) to be assigned by IANA. The length field 512 comprises a value of 6 indicating the length of the TLV excluding the type field 510 and the length field 512. The Node ID field 514 is 6 octet and comprises IS-IS system (or node) ID of the node.

[0080] FIG. 5C is a schematic diagram illustrating a format of TE node ID TLV 500C according to an embodiment of the present disclosure. In one embodiment, the node ID TLV is a TE Node ID TLV 500C. The TE Node ID TLV 500C comprises a type field 520, a length field 522, and a Node ID field 524. In an embodiment, the type field 520 comprises a value (TBDc) to be assigned by IANA. The length field 522 comprises a value of 4 indicating the length of the TLV excluding the type field 520 and the length field 522. The Node ID field 524 is 4 octets and comprises TE node (or router) ID of the protected node (e.g., node P2).

[0081] FIG. 5D is a schematic diagram illustrating a format of Node IPv4 address TLV according to an embodiment of the present disclosure. In one embodiment, the node ID TLV is a node IPv4 address TLV 500D. The node IPv4 address TLV 500D comprises a type field 530, a length field 532, and a Node address field 534. In an embodiment, the type field 530 comprises a value (TBDd) to be assigned by IANA. The length field 532 comprises a value of 4 indicating the length of the TLV excluding the type field 530 and the length field 532. The Node address field 534 is 4 octets and comprises an IPv4 address of the node. The IPv4 address is used as the ID of the protected node (e.g., node P2).

[0082] FIG. 5E is a schematic diagram illustrating a format of node IPv6 address TLV according to an embodiment of the present disclosure. The node IPv6 address TLV 500E comprises a type field 540, a length field 542, and a Node address field 544. In an embodiment, the type field 540 comprises a value (TBDe) to be assigned by IANA. The length field 542 comprises a value of 16 indicating the length of the TLV excluding the type field 540 and the length field 542. The Node address field 544 is 16 octets and comprises an IPv6 address of the node. The IPv6 address is used as the ID of the protected node (e g., node P2).

[0083] FIG. 6A is a schematic diagram illustrating a format 600A of RP Object with PATHSETUP-TYPE and Node ID TLVs according to an embodiment of the present disclosure. In an embodiment, a RP object comprises a TLVs field 602 including a PATH- SETUP-TYPE TLV with PST = TBD1 and a Node ID TLV. The node ID TLV comprises an identifier of the protected node. The node ID TLV comprises an Open Shortest Path First (OSPF) Node ID TLV, an Intermediate System to Intermediate System (IS-IS) Node ID TLV, a Node Traffic Engineering (TE) node ID TLV, a Node internet protocol version 4 (IPv4) address TLV, or a Node internet protocol version 6 (IPv6) address TLV as described in FIGS. 5A-5E.

[0084] FIG. 6B is a schematic diagram illustrating a format 600B of SRP Object with PATH- SETUP-TYPE and Node ID TLVs according to an embodiment of the present disclosure. In an embodiment, an SRP object comprises a TLVs field 604 including a PATH- SETUP-TYPE TLV with PST = TBD1 and the Node ID TLV.

[0085] FIG. 7 is a flowchart of an embodiment of a method 700 implemented by a controller configured to implement a path computation element protocol (PCEP), according to an embodiment of the present disclosure. In block 702, the PCE controller 160 transmits a first message comprising binding information to a node for a segment routing (SR) path going through the node or receive a second message comprising the binding information from the node for the segment routing (SR) path going through the node, wherein the binding information includes a binding segment identifier (SID) and a list of SIDs. In an embodiment, the first message is a Path Computation Update request (PCUpd) message and the second message is a Path Computation label switched path (LSP) State Report (PCRpt) message. [0086] In block 704, the PCE controller 160 transmits a third message comprising binding protection information corresponding to the binding information to a protecting node, wherein the binding protection information includes the binding SID, the list of SIDs, and an identifier of the node. In an embodiment, the PCE controller 160 further exchanges a capability of distributing the binding protection information with the protecting node in a PATH SETUP TYPE CAP ABILITY TLV with a Path Setup Type (PST) and a sub-TLV in an Open object of an Open message. In an embodiment, the PST comprises a value indicating that the PCE controller 160 supports the capability of binding protection information distribution. In an embodiment, the sub-TLV is a binding protection information distribution capability sub-TLV, wherein the sub-TLV comprises a type field, a length field, a reserved field, and a flags field.

[0087] In an embodiment, the PCE controller 160 further exchanges a capability of distributing the binding protection information with the protecting node using a PCECC-CAP ABILITY Sub- TLV comprised in a PATH SETUP TYPE CAP ABILITY TLV in an Open message. In an embodiment, the first message is a path computation update request (PCUpd) message, the second message is a path computation label switched path (LSP) state report (PCRpt) message, and the third message is a path computation update request (PCUpd) message. In an embodiment, the PCUpd message comprises a request parameters (RP) object or stateful request parameters (SRP) object, wherein the RP/SRP object comprises a PATH- SETUP-TYPE TLV with a Path Setup Type (PST) and a Node ID TLV comprising the identifier of the node, and wherein the node ID TLV comprises an Open Shortest Path First (OSPF) Node ID TLV, an Intermediate System to Intermediate System (IS-IS) Node ID TLV, a Node Traffic Engineering (TE) node ID TLV, a Node internet protocol version 4 (IPv4) address TLV, or a Node internet protocol version 6 (IPv6) address TLV. [0088] In block 706, the PCE controller 160 instructs the protecting node to use the binding protection information to protect the binding SID of the failed node if the node fails. In an embodiment, the binding protection information acts as an instruction.

[0089] FIG. 8 is a schematic diagram illustrating a network apparatus 800 according to an embodiment of the present disclosure. The network apparatus 800 is suitable for implementing the disclosed embodiments as described herein. The network apparatus 800 comprises ingress ports/ingress means 810 (a.k.a., upstream ports) and receiver units (Rx)/receiving means 820 for receiving data; a processor, logic unit, or central processing unit (CPU)/processing means 830 to process the data; transmitter units (Tx)/transmitting means 840 and egress ports/egress means 850 (a.k.a., downstream ports) for transmitting the data; and a memory/memory means 860 for storing the data. The network apparatus 800 may also comprise optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress ports/ingress means 810, the receiver units/receiving means 820, the transmitter units/transmitting means 840, and the egress ports/egress means 850 for egress or ingress of optical or electrical signals.

[0090] The processor/processing means 830 is implemented by hardware and software. The processor/processing means 830 may be implemented as one or more CPU chips, 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/processing means 830 is in communication with the ingress ports/ingress means 810, receiver units/receiving means 820, transmitter units/transmitting means 840, egress ports/egress means 850, and memory/memory means 860. The processor/processing means 830 comprises a PCE module 870. The PCE module 870 is able to implement the methods disclosed herein. The inclusion of the PCE module 870 therefore provides a substantial improvement to the functionality of the network apparatus 800 and effects a transformation of the network apparatus 800 to a different state. Alternatively, the PCE module 870 is implemented as instructions stored in the memory/memory means 860 and executed by the processor/processing means 830.

[0091] The network apparatus 800 may also include input and/or output (I/O) devices or I/O means 880 for communicating data to and from a user. The I/O devices or I/O means 880 may include output devices such as a display for displaying video data, speakers for outputting audio data, etc. The I/O devices or I/O means 880 may also include input devices, such as a keyboard, mouse, trackball, etc., and/or corresponding interfaces for interacting with such output devices.

[0092] The memory/memory means 860 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/memory means 860 may be volatile and/or non-volatile and may be readonly memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and/or static random-access memory (SRAM).

[0093] While several embodiments have been provided in the present disclosure, it may 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 disclosure 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.

[0094] 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 may be made without departing from the spirit and scope disclosed herein.

Claims

1. A method implemented by a controller configured to implement a path computation element protocol (PCEP), the method comprising: transmitting a first message comprising binding information to a node for a segment routing (SR) path going through the node or receiving a second message comprising the binding information from the node for the SR path going through the node, wherein the binding information includes a binding segment identifier (SID) and a list of SIDs; transmitting a third message comprising binding protection information corresponding to the binding information to a protecting node, wherein the binding protection information includes the binding SID, the list of SIDs, and an identifier (ID) of the node; and instructing the protecting node to use the binding protection information to protect the binding SID of the failed node if the node fails.

2. The method of claim 1 , further comprising exchanging a capability of distributing the binding protection information with the protecting node in a PATH SETUP TYPE CAP ABILITY type length value (TLV) with a Path Setup Type (PST) and a sub-TLV in an Open object of an Open message.

3. The method of any of claims 1-2, wherein the PST comprises a value indicating that the controller supports the capability of binding protection information distribution.

4. The method of any of claims 1-3, wherein the sub-TLV is a binding protection information distribution capability sub-TLV, and wherein the sub-TLV comprises a type field, a length field, a reserved field, and a flags field.

5. The method of claim 1 , further comprising exchanging a capability of distributing the binding protection information with the protecting node using a PCECC-CAP ABILITY Sub-TLV comprised in a PATH SETUP TYPE CAP ABILITY TLV in an Open message.

6. The method of claim 5, wherein the PCECC-CAP ABILITY Sub-TLV comprises a B flag field set to a value indicating that a PCEP speaker supports the binding protection information distribution.

7. The method of claim 1, wherein the first message is a path computation update request (PCUpd) message, and wherein the second message is a path computation label switched path (LSP) state report (PCRpt) message.

8. The method of claim 1, wherein the third message is a path computation update request (PCUpd) message.

9. The method of claim 8, wherein the PCUpd message comprises a Request Parameters (RP) object or Stateful Request Parameters (SRP) object, and wherein the RP/SRP object comprises a PATH- SETUP-TYPE TLV with a Path Setup Type (PST) and a Node ID TLV comprising the identifier of the node.

10. The method of any of claims 8-9, wherein the node ID TLV comprises an Open Shortest Path First (OSPF) Node ID TLV, an Intermediate System to Intermediate System (IS-IS) Node ID TLV, a Node Traffic Engineering (TE) node ID TLV, a Node internet protocol version 4 (IPv4) address TLV, or a Node internet protocol version 6 (IPv6) address TLV.

11. The method of any of claims 1-10, further comprising: transmitting a fourth message instructing the node to remove the binding information or receiving a fifth message from the node indicating that the binding information is removed from the node; and transmitting a sixth message instructing the protecting node to remove the binding protection information.

12. The method of claim 11, wherein each of the fourth message and the fifth message is a path computation update request (PCUpd) message comprising a TE-PATH-B INDING TLV with the binding SID and a R flag field set to 1, and wherein the sixth message is a PCUpd message comprising the TE-PATH-BINDING TLV with the binding SID and the R flag field set to 1, an explicit route object (ERO) object with the SID list, and RP/SRP object with the identifier (ID) of the node.

13. The method of claim 1 , wherein the binding protection information in the third message acts as an instruction.

14. A controller configured to implement a path computation element protocol (PCEP), comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to: transmit a first message comprising binding information to a node for a segment routing (SR) path going through the node or receive a second message comprising the binding information from the node for the SR path going through the node, wherein the binding information includes a binding segment identifier (SID) and a list of SIDs; transmit a third message comprising binding protection information corresponding to the binding information to a protecting node, wherein the binding protection information includes the binding SID, the list of SIDs, and an identifier of the node; and instruct the protecting node to use the binding protection information to protect the binding SID of the failed node if the node fails.

15. The controller of claim 14, wherein the one or more processors further configured to exchange a capability of distributing the binding protection information with the protecting node in a PATH SETUP TYPE CAP ABILITY type length value (TLV) with a Path Setup Type (PST) and a sub-TLV in an Open object of an Open message.

16. The controller of any of claims 14-15, wherein the PST comprises a value indicating that the

PCE supports the capability of binding protection information distribution.

17. The controller of any of claims 14-16, wherein the sub-TLV is a binding protection information distribution capability sub-TLV, and wherein the sub-TLV comprises a type field, a length field, a reserved field, and a flags field.

18. The controller of claim 14, wherein the one or more processors further configured to exchange a capability of distributing the binding protection information with the protecting node using a PCECC-CAP ABILITY Sub-TLV comprised in a PATH SETUP TYPE CAP ABILITY TLV in an Open message.

19. The controller of claim 18, wherein the PCECC-CAP ABILITY Sub-TLV comprises a B flag field set to a value indicating that a PCEP speaker supports the binding protection information distribution.

20. The controller of claim 14, wherein the first message is a path computation update request (PCUpd) message, and wherein the second message is a path computation label switched path (LSP) state report (PCRpt) message.

21. The controller of claim 14, wherein the third message is a path computation update request (PCUpd) message.

22. The controller of claim 21, wherein the PCUpd message comprises a Request Parameters (RP) object or Stateful Request Parameters (SRP) object, and wherein the RP/SRP object comprises a PATH-SETUP-TYPE TLV with a Path Setup Type (PST) and a Node ID TLV comprising the identifier of the node.

23. The controller of any of claims 21-22, wherein the node ID TLV comprises an Open Shortest Path First (OSPF) Node ID TLV, an Intermediate System to Intermediate System (IS-IS) Node ID TLV, a Node Traffic Engineering (TE) node ID TLV, a Node internet protocol version 4 (IPv4) address TLV, or a Node internet protocol version 6 (IPv6) address TLV.

24. The controller of any of claims 14-23, wherein the one or more processors are further configured to: transmit a fourth message instructing the node to remove the binding information or receive a fifth message from the node indicating that the binding information is removed from the node; and transmit a sixth message instructing the protecting node to remove the binding protection information.

25. The controller of claim 24, wherein each of the fourth message and the fifth message is a path computation update request (PCUpd) message comprising a TE-PATH-BINDING TLV with the binding SID and a R flag field set to 1, and wherein the sixth message is a PCUpd message comprising the TE-PATH-BINDING TLV with the binding SID and the R flag set to 1, an explicit route object (ERO) object with the SID list, and RP/SRP object with the identifier (ID) of the node.

26. The controller of claim 14, wherein the binding protection information in the third message acts as an instruction.

27. A non-transitory computer readable medium comprising a computer program product for use by a controller configured to implement a path computation element protocol (PCEP), the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium that, when executed by one or more processors, cause the controller to execute the method in any of claims 1-13.

28. A controller configured to implement a path computation element protocol (PCEP), comprising: means for transmitting a first message comprising binding information to a node for a segment routing (SR) path going through the node or receiving a second message comprising the binding information from the node for the SR path going through the node, wherein the binding information includes a binding segment identifier (SID) and a list of SIDs; means for transmitting a third message comprising binding protection information corresponding to the binding information to a protecting node, wherein the binding protection information includes the binding SID, the list of SIDs, and an identifier of the node; and means for instructing the protecting node to use the binding protection information to protect the binding SID of the failed node if the node fails.