Patent Description:
BIER mechanisms provide optimized forwarding of multicast data packets through a BIER domain. BIER domains may not require the use of a protocol for explicitly building multicast distribution trees. Further, BIER domains may not require intermediate nodes to maintain any per-flow state. BIER is described in further detail in Internet Engineering Task Force (IETF) document Request for Comments (RFC) <NUM> entitled "<NPL>. "<NPL>, discloses procedures and PCEP protocol extensions for using the PCE as the central controller for BIER. "<NPL>, discloses protection methods for the BIER-TE architecture. "<NPL>, discloses extensions to Path Computation Element (PCE) Communication Protocol (PCEP) for protecting the ingress of a BIER-TE path.

Traffic Engineering (TE) is the process of steering traffic across to a telecommunications network to facilitate efficient use of available bandwidth between a pair of routers. Bit Index Explicit Replication (BIER) Traffic/Tree Engineering (BIER-TE) is described in IETF document "<NPL>.

The disclosed aspects/embodiments provide techniques that allow a path computation element (PCE) to set up ingress protection for a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) domain. In order to facilitate the techniques, the present disclosure provides extensions to type length values (TLVs) and sub-TLVs and a new path computation element protocol (PCEP) object, each of which are carried in PCEP messages. Using the extensions and/or the new PCEP object, packet routing within the BIER-TE domain is improved relative to existing techniques.

The invention relates to a method implemented by a path computation element, PCE, according to claim <NUM> and corresponding PCE claim <NUM>. Dependent clams disclose preferred embodiments of the invention.

Existing techniques for fast protection for a BIER-TE path (a. , a point to multipoint (P2MP) path, a BIER-TE P2MP path, a BIER-TE tunnel, or variations thereof) have drawbacks. For example, existing solutions are limited to protecting the transit nodes and links of the BIER-TE path and, as such, are unable to provide fast protection for the ingress node. Because the ingress node adds the bit positions for the BIER-TE path into the header of every packet to be transported along the BIER-TE path, the ingress node is critical.

Disclosed herein are techniques that allow a path computation element (PCE) to set up ingress protection for a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) domain. In order to facilitate the techniques, the present disclosure provides extensions to type length values (TLVs) and sub-TLVs and a new path computation element protocol (PCEP) object, each of which are carried in PCEP messages. Using the extensions and/or the new PCEP object, packet routing within the BIER-TE domain is improved relative to existing techniques.

<FIG> is a schematic diagram of a BIER-TE topology <NUM> including a BIER-TE domain <NUM>. The BIER-TE domain <NUM> may be part of a larger BIER-TE domain (not shown). As such, the BIER-TE domain <NUM> may be referred to herein as a BIER-TE sub-domain. The BIER-TE domain <NUM> comprises a plurality of network nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. While seven network nodes <NUM>-<NUM> are shown in the BIER-TE domain <NUM>, more or fewer nodes may be included in practical applications.

Each of the network nodes <NUM>-<NUM> is a bit forwarding router (BFR). Some of the network nodes, namely the network nodes <NUM>, <NUM>, <NUM> and <NUM>, are disposed at an edge of the BIER-TE domain <NUM>. The network nodes <NUM>, <NUM>, <NUM> and <NUM> receiving multicast packets from outside the BIER-TE domain <NUM> may be referred to as an ingress BFR (BFIR). The network nodes <NUM>, <NUM>, <NUM> and <NUM> transmitting multicast packets out of the BIER-TE domain <NUM> may be referred to as an egress BFR (BFER). Depending on the direction of multicast packet traffic, each of the network nodes <NUM>, <NUM>, <NUM> and <NUM> may function as a BFIR or a BFER.

The network nodes <NUM> and <NUM> are in communication with a network node referred to as a first customer edge (CE1) <NUM>. In the illustrated embodiment, the CE1 <NUM> is a source. The 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 <NUM> is in communication with a second customer edge (CE2) <NUM> and the network node <NUM> is in communication with a third customer edge (CE3) <NUM>. As such, packets received from the CE1 and routed through the BIER-TE domain <NUM> may eventually be delivered to the CE2 <NUM> and/or the CE3 <NUM> for consumption by the consumer.

Each of the network nodes <NUM>-<NUM> has one or more neighbor nodes. As used herein, a neighbor node refers to a network node that is only one hop away from the network node. For example, network node <NUM> has three neighbor nodes in <FIG>, namely network node <NUM>, network node <NUM>, and network node <NUM>. Indeed, each of network node <NUM>, network node <NUM>, and network node <NUM> is only one hop away from network node <NUM>.

The network nodes <NUM>-<NUM> in <FIG> are coupled to, and communicate with each other, via links <NUM>. The links <NUM> may be wired, wireless, or some combination thereof. In an embodiment, each of the links <NUM> may have a cost. The cost of each of the links <NUM> may be the same or different, depending on the BIER-TE network and conditions therein.

The BIER domain <NUM> is controlled by a network controller <NUM>. In an embodiment, the network controller <NUM> is a path computation element (PCE). A PCE is a system component, application, or network node capable of determining and finding a suitable route for conveying data (e.g., packets) through a network between a source and a destination. In order to control the BIER-TE domain <NUM>, in one embodiment, the network controller <NUM> is in communication with each of the network nodes therein, namely network nodes <NUM>-<NUM>. That is, the network controller <NUM> is able to exchange messages with the network nodes <NUM>-<NUM>. In another embodiment, the network controller <NUM> is in communication with each of the network edge nodes (i.e., BFIRs or BFERs) therein, namely network nodes <NUM>, <NUM>, <NUM> and <NUM>. That is, the network controller <NUM> is able to exchange messages with the network nodes <NUM>, <NUM>, <NUM> and <NUM>.

In an embodiment, a path computation client (PCC) is running on one or more of the network nodes <NUM>-<NUM>, CE1 <NUM>, CE2 <NUM>, and/or CE3 <NUM>. A PCC is a client application or component configured to request that the PCE perform a path computation. For example, the PCC may request that the PCE calculate a BIER-TE path.

In the illustrated embodiment of <FIG>, a primary BIER-TE path (as shown by bold arrows) extends from network node <NUM>, which is the primary ingress node, to network node <NUM> and network node <NUM>, which are the egress nodes. A backup BIER-TE path (as shown by bold dashed arrows) extends from network node <NUM>, which is the backup ingress node, to network node <NUM> and network node <NUM>, which are the egress nodes. The primary BIER-TE path and the backup BIER-TE path are each configured to transport traffic (e.g., multicast packets) from the CE1 <NUM>.

In normal operations, the CE1 <NUM> sends multicast packets to network node <NUM>, which is the primary ingress node. The network node <NUM> encapsulates the packets with a BIER-TE header, which includes an encoding of the primary BIER-TE path from the network node <NUM> to network node <NUM> and to network node <NUM>. In an embodiment, the BIER-TE header includes bit positions for forward connected adjacencies.

When network node <NUM> fails, the CE1 <NUM> sends multicast packets to the network node <NUM>, which is the backup ingress node. The network node <NUM> encapsulates the packets with a BIER-TE header, which includes an encoding of the backup BIER-TE path from the network node <NUM> to network node <NUM> and to network node <NUM>. In an embodiment, the BIER-TE header includes bit positions for forward connected adjacencies.

To support BIER-TE ingress protection, the network controller <NUM> sends information to network node <NUM>. Such information includes, for example, the backup BIER-TE path and other information (e.g., the backup BIER-TE path, an address of a primary ingress node, a description of the multicast traffic, the service, etc.) as will be discussed in detail herein.

Using the embodiment of <FIG> as an example, three different cases involving the failure of the network node <NUM> are considered. In a first case, the CE1 <NUM> is responsible for detecting the failure of the network node <NUM>. Before any failure is detected, the CE1 <NUM> sends multicast packets to the network node <NUM>. In this embodiment, the network node <NUM>, which is the backup ingress node, is ready to encapsulate packets with the backup BIER-TE path. After the CE1 <NUM> detects the failure of the network node <NUM>, the CE1 <NUM> sends multicast packets to the network node <NUM>. The network node <NUM> then encapsulates the packets with the BIER-TE path since the network node <NUM> is ready.

In a second case, the network node <NUM> is responsible for detecting the failure of the network node <NUM>. Before any failure is detected, the CE1 <NUM> sends multicast packets to both the network node <NUM> and the network node <NUM>. In this embodiment, the network node <NUM> drops the packets. After the network node <NUM> detects the failure of the network node <NUM>, the CE1 <NUM> sends multicast packets to the network node <NUM>. The network node <NUM> then encapsulates the packets with the BIER-TE path since the network node <NUM> is ready.

In a third case, the CE1 <NUM> and the network node <NUM> are both responsible for detecting the failure of the network node <NUM>. Before any failure is detected, the CE1 <NUM> sends multicast packets to the network node <NUM>. After the CE1 <NUM> and/or the network node <NUM> detects the failure of the network node <NUM>, the CE1 <NUM> sends multicast packets to the network node <NUM>. The network node <NUM> then encapsulates the packets with the BIER-TE path since the network node <NUM> is ready.

In order to implement the three different cases, the network controller <NUM> sends the PCC operating on the network node <NUM> the backup BIER-TE path, the address of the primary ingress, a description of the traffic carried by the BIER-TE path, and a service label or service ID carried by the BIER-TE path. The network controller <NUM> also sends the PCC operating on the CE1 <NUM> instructions for implementing the three cases noted above. The network controller <NUM> is able to send this information using one or more TLVs, sub-TLVs, and/or object bodies, as discussed further below.

<FIG> is a schematic diagram of a BIER-TE-Path_Ingress_Protection_Capability sub-TLV <NUM> according to an embodiment of the disclosure. In an embodiment, the BIER-TE-Path_Ingress_Protection_Capability sub-TLV <NUM> is included in a Path_Setup_Type_Capability TLV of an open message. In an embodiment, the Path_Setup_Type_Capability TLV includes a path setup type (PST) field with a value to be assigned by the Internet Assigned Numbers Authority (IANA). In an embodiment, the value indicates that the path is a BIER-TE path (e.g., the backup BIER-TE path).

The BER-TE-Path_Ingress_Protection_Capability sub-TLV <NUM> comprises a type field <NUM>, a length field <NUM>, a reserved field <NUM>, and a flags field <NUM>. The type field <NUM> is <NUM> bits and the value in the type field <NUM> is to be assigned by the IANA. The length field <NUM> is <NUM> bits. In an embodiment, the value in the length field <NUM> is <NUM> to indicate that <NUM> bytes is the total length of the remainder of the sub-TLV, excluding the type and length fields <NUM>, <NUM>. The reserved field <NUM> is <NUM> bits. In an embodiment, the reserved field <NUM> is set to zero by the sender of the BIER-TE-Path_Ingress_Protection_Capability sub-TLV <NUM> and ignored by the receiver of the BIER-TE-Path_Ingress_Protection_Capability sub-TLV <NUM>.

The flags field <NUM> includes one or more flags, such as the D flag <NUM>. The D flag <NUM> is set to a first binary value (e.g., <NUM>) to indicate that the network node is able to quickly detect a failure of the network node adjacent to the network node. The D flag <NUM> is also set to a second binary value (e.g., <NUM>) when the network node is unable to quickly detect the failure of the network node adjacent to the network node. For example, when the network node <NUM> is able to quickly detect the failure of the network node <NUM>, the D flag <NUM> is set to a value of <NUM>.

<FIG> is a schematic diagram of a Path Computation Element (PCE) for a Central Controller (PCECC) Capability sub-TLV <NUM> according to an embodiment of the disclosure. In an embodiment, the PCECC Capability sub-TLV <NUM> is included in a Path_Setup_Type_Capability TLV of an open message.

The PCECC Capability sub-TLV <NUM> comprises a type field <NUM>, a length field <NUM>, and a flags field <NUM>. The type field <NUM> is <NUM> bits and the value in the type field <NUM> is set to one to indicate that the sub-TLV <NUM> is a PCECC Capability sub-TLV and the length of the PCECC Capability sub-TLV <NUM> is <NUM> octets. The length field <NUM> is <NUM> bits. In an embodiment, the value in the length field <NUM> is <NUM> to indicate that flags field <NUM> is <NUM> bits.

The flags field <NUM> includes one or more flags, such as the P flag <NUM> and the L flag <NUM>. The P flag <NUM> (for ingress protection) is set to a first binary value (e.g., <NUM>) to indicate that the PCEP speaker supports and is willing to handle the PCECC instructions for ingress protection. The bit is set to <NUM> by both a PCC and a PCE for the PCECC ingress protection instruction download/report on a PCEP session.

The L flag <NUM> is set to a first binary value (e.g., <NUM>) to indicate that the PCEP speaker will support and is willing to handle the PCECC instructions for label download. The bit is set to <NUM> by both a PCC and a PCE for the PCECC label download/report on a PCEP session.

<FIG> is a schematic diagram of a BIER-TE-Path_Ingress_Protection TLV <NUM> according to an embodiment of the disclosure. In an embodiment, the BIER-TE-Path_Ingress_Protection TLV <NUM> is included in a path computation label switched path (LSP) initiate request (PCInitiate) message.

The BIER-TE-Path_Ingress _Protection TLV <NUM> comprises a type field <NUM>, a length field <NUM>, a reserved field <NUM>, a flags field <NUM>, and a sub-TLVs field <NUM>. The type field <NUM> is <NUM> bits and the value in the type field <NUM> is to be assigned by the IANA. The length field <NUM> is <NUM> bits. The value of the length field <NUM> is variable. In an embodiment, the value in the length field <NUM> is set to indicate the total length of the remainder of the TLV, excluding the type and length fields <NUM>, <NUM>.

The reserved field <NUM> is <NUM> bits. In an embodiment, the reserved field <NUM> is set to zero by the sender of the BIER-TE-Path_Ingress_Protection TLV <NUM> and ignored by the receiver of the BIER-TE-Path_Ingress_Protection TLV <NUM>. The flags field <NUM> includes one or more flags, such as the A flag <NUM>. The A flag <NUM> is set to a first binary value (e.g., <NUM>) to request a PCC to let the forwarding entry for the backup BIER-TE path be active always. When the network node on which the PCC is running receives the PCECC Capability sub-TLV <NUM> with the P flag bit <NUM> set to <NUM>, the network node sets the forwarding entry for the backup BIER-TE path in the forwarding table to <NUM>. Once the forwarding entry is set, the network node is ready to use or uses the backup BIER-TE path to forward multicast packet traffic. The sub-TLVs field <NUM> is configured to carry any optional sub-TLVs.

<FIG> is a schematic diagram of a Primary Ingress Internet Protocol version <NUM> (IPv4) Address sub-TLV <NUM> according to an embodiment of the disclosure. In an embodiment, the Primary Ingress IPv4 Address sub-TLV <NUM> is carried in the sub-TLVs field <NUM> of the BIER-TE-Path_Ingress_Protection TLV <NUM>.

The Primary Ingress IPv4 Address sub-TLV <NUM> comprises a type field <NUM>, a length field <NUM>, and a primary ingress IPv4 Address field <NUM>. The type field <NUM> is <NUM> bits and the value in the type field <NUM> is to be assigned by the IANA. The length field <NUM> is <NUM> bits. In an embodiment, the value in the length field <NUM> is <NUM> to indicate that the primary ingress IPv4 Address field <NUM> is <NUM> bits. The primary ingress IPv4 Address field <NUM> contains the address of the primary ingress node. For example, the primary ingress IPv4 Address field <NUM> may include the address of network node <NUM> in <FIG>.

<FIG> is a schematic diagram of a Primary Ingress Internet Protocol version <NUM> (IPv6) Address sub-TLV according to an embodiment of the disclosure. In an embodiment, the Primary Ingress IPv6 Address sub-TLV <NUM> is carried in the sub-TLVs field <NUM> of the BIER-TE-Path_Ingress_Protection TLV <NUM>.

The Primary Ingress IPv6 Address sub-TLV <NUM> comprises a type field <NUM>, a length field <NUM>, a primary ingress IPv6 Address field <NUM>. The type field <NUM> is <NUM> bits and the value in the type field <NUM> is to be assigned by the IANA. The length field <NUM> is <NUM> bits. In an embodiment, the value in the length field <NUM> is <NUM> to indicate that the primary ingress IPv6 Address field <NUM> is <NUM> bits. The primary ingress IPv6 Address field <NUM> contains the IPv6 address of the primary ingress node. For example, the primary ingress IPv6 Address field <NUM> may include the IPv6 address of network node <NUM> in <FIG>.

<FIG> is a schematic diagram of a Service Label sub-TLV <NUM> according to an embodiment of the disclosure. In an embodiment, the Service Label sub-TLV <NUM> is carried in the sub-TLVs field <NUM> of the BIER-TE-Path_Ingress _Protection TLV <NUM>.

The Service Label sub-TLV <NUM> comprises a type field <NUM>, a length field <NUM>, a zero field <NUM>, and a service label field <NUM>. The type field <NUM> is <NUM> bits and the value in the type field <NUM> is to be assigned by the IANA. The length field <NUM> is <NUM> bits. In an embodiment, the value in the length field <NUM> is <NUM> to indicate that <NUM> bytes is the total length of the remainder of the sub-TLV, excluding the Type and Length fields <NUM>, <NUM>. The zero field <NUM> is <NUM> bits. In an embodiment, the zero field <NUM> is set to zero by the sender of the Service Label sub-TLV <NUM> and ignored by the receiver of the Service Label sub-TLV <NUM>.

The service label field <NUM> is <NUM> bits and includes a value that identifies a service. The service identified by the value in the service label field <NUM> may be, for example, a virtual private network (VPN). Other types of services may be identified in practical applications.

<FIG> is a schematic diagram of a Service Identifier (ID) sub-TLV <NUM> according to an embodiment of the disclosure. In an embodiment, the Service ID sub-TLV <NUM> is carried in the sub-TLVs field <NUM> of the BIER-TE-Path_Ingress _Protection TLV <NUM>.

The Service ID sub-TLV <NUM> comprises a type field <NUM>, a length field <NUM>, and a service ID field <NUM>. The type field <NUM> is <NUM> bits and the value in the type field <NUM> is to be assigned by the IANA. The length field <NUM> is <NUM> bits. In an embodiment, the value in the length field <NUM> is <NUM> or <NUM> to indicate that the service ID field <NUM> is either <NUM> bytes or <NUM> bytes, respectively.

The service ID field <NUM> is <NUM> or <NUM> octets and includes a value (e.g., a service ID) that identifies a service. The service identified by the value in the service ID field <NUM> may be, for example, a VPN. Other types of services may be identified in practical applications.

<FIG> is a schematic diagram of a BIER-TE-Path_Ingress-Protection Object Body <NUM> according to an embodiment of the disclosure. The BIER-TE-Path_Ingress-Protection Object Body <NUM> has a new object type (TBDt) for BIER-TE ingress protection and is based on a central controller instructions (CCI) object. The BIER-TE-Path_Ingress-Protection Object Body <NUM> is used by the PCE (e.g., network controller <NUM>) to specify the forwarding instructions (e.g., label information) to the PCC. In an embodiment, the BIER-TE-Path_Ingress-Protection Object Body <NUM> is included in a path computation LSP state report (PCRpt) message, a path computation LSP update request (PCUpd) message, or a PCInitiate message.

The BIER-TE-Path_Ingress-Protection Object Body <NUM> comprises a central controller identifier (CC-ID) field <NUM>, a reserved field <NUM>, a flags field <NUM>, and an optional TLV field <NUM>. The CC-ID field <NUM> is <NUM> bits and contains a PCEP-specific identifier for the CCI information. A PCE creates a CC-ID for each instruction. The value in the CC-ID field <NUM> is unique within the scope of the PCE and is constant for the lifetime of a PCEP session.

The reserved field <NUM> is <NUM> bits. In an embodiment, the reserved field <NUM> is set to zero by the sender of the BIER-TE-Path_Ingress-Protection Object Body <NUM> and ignored by the receiver of the BIER-TE-Path_Ingress-Protection Object Body <NUM>.

The flags field <NUM> includes one or more flags, such as the B flag <NUM> and the D flag <NUM>. The B flag <NUM> is set to a first binary value (e.g., <NUM>) to instruct the traffic source (e.g., network node <NUM>) to send the traffic to both the primary ingress node (e.g., network node <NUM>) and the backup ingress node (e.g., network node <NUM>). The D flag <NUM> instructs the traffic source to detect the failure of the primary ingress node and to switch the traffic to the backup ingress when the traffic source detects the failure. The optional TLV field <NUM> may include a primary ingress TLV, a backup ingress TLV, and/or a multicast flow specification TLV.

<FIG> is a schematic diagram of a Backup Ingress IPv4 Address TLV <NUM> according to an embodiment of the disclosure. In an embodiment, the Backup Ingress IPv4 Address TLV <NUM> is carried in the optional TLV field <NUM> of the BIER-TE-Path_Ingress-Protection Object Body <NUM>.

The Backup Ingress IPv4 Address TLV <NUM> comprises a type field <NUM>, a length field <NUM>, and a backup ingress IPv4 Address field <NUM>. The type field <NUM> is <NUM> bits and the value in the type field <NUM> is to be assigned by the IANA. The length field <NUM> is <NUM> bits. In an embodiment, the value in the length field <NUM> is <NUM> to indicate that the backup ingress IPv4 Address field <NUM> is <NUM> bits. The backup ingress IPv4 Address field <NUM> contains the IPv4 address of the backup ingress node. For example, the backup ingress IPv4 Address field <NUM> may include the IPv4 address of network node <NUM> in <FIG>.

<FIG> is a schematic diagram of a Backup Ingress IPv6 Address TLV <NUM> according to an embodiment of the disclosure. In an embodiment, the Backup Ingress IPv6 Address TLV <NUM> is carried in the optional TLV field <NUM> of the BIER-TE-Path_Ingress-Protection Object Body <NUM>.

The Backup Ingress IPv6 Address TLV <NUM> comprises a type field <NUM>, a length field <NUM>, and a backup ingress IPv6 Address field <NUM>. The type field <NUM> is <NUM> bits and the value in the type field <NUM> is to be assigned by the IANA. The length field <NUM> is <NUM> bits. In an embodiment, the value in the length field <NUM> is <NUM> to indicate that the backup ingress IPv6 Address field <NUM> is <NUM> bits. The backup ingress IPv6 Address field <NUM> contains the IPv6 address of the backup ingress node. For example, the backup ingress IPv6 Address field <NUM> may include the IPv6 address of network node <NUM> in <FIG>.

<FIG> is a method <NUM> implemented by a network controller (e.g., network controller <NUM>) configured to control the BIER-TE domain <NUM> according to an embodiment of the disclosure. The method <NUM> may be performed by the network controller to establish ingress protection for a BIER-TE path from an ingress node to egress nodes.

In block <NUM>, the network controller sends a first path computation element protocol (PCEP) message to a network node in the BIER-TE domain. The first PCEP message includes a first path setup type capability TLV. In block <NUM>, the network controller receives a second PCEP message from the one or more network nodes. The second PCEP message includes a second path setup type capability TLV. The second path setup type capability TLV comprises an ingress protection capability sub-TLV containing a first flag. The first flag is set to a first binary value to indicate that the network node is able to detect a failure of an adjacent network node.

In an embodiment, the first PCEP message is an open message. The first path setup type capability TLV includes a first central controller (PCECC) sub-type length value (sub-TLV) containing a second flag. The second flag is set to the first binary value to indicate that the PCE supports and is willing to handle PCECC-based central controller instructions for ingress protection.

In an embodiment, the first path setup type capability TLV includes a path setup type (PST) containing a first value that indicates the path setup type capability TLV is for a BIER-TE path.

In an embodiment, the network node includes a backup ingress node of the BIER-TE domain or a customer edge (CE). The second PCEP message is an open message. The second path setup type capability TLV contains the first value.

In an embodiment, the second path setup type capability TLV contains a second central controller (PCECC) sub-type length value (sub-TLV) including a third flag. The third flag is set to the first binary value to indicate that the network node supports and is willing to handle PCECC-based central controller instructions for ingress protection.

In an embodiment, the method <NUM> further comprises determining that the network node will be responsible for detecting the failure of the adjacent network node based on the first binary value of the first flag in the second PCEP message from the network node. That is, the method <NUM> includes the PCE determining whether to implement the first case, the second case, or the third case described above.

In an embodiment, the network nodes comprises a backup ingress node, and the method <NUM> further comprises sending a third PCEP message (e.g., a PCInitiate message) to the backup ingress node. The third PCEP message includes an ingress protection TLV containing: a fourth flag (e.g., the A flag) set to the first binary value to request that a forwarding entry for a backup BIER-TE path be active always; and a service sub-TLV including a service label or a service identifier. This embodiment corresponds to the first case described above.

In an embodiment, the network node comprises a backup ingress node, and the method <NUM> further comprises sending a third PCEP message to the backup ingress node. The third PCEP message includes an ingress protection TLV. The ingress protection TLV contains a fourth flag (e.g., the A flag) set to a second binary value to request that the backup ingress node detect the failure of a primary ingress node and to let a forwarding entry for a backup BIER-TE path be active when the primary ingress node fails. The ingress protection TLV also contains service sub-TLV including a service label or a service identifier. The ingress protection TLV further contains primary ingress sub-TLV including a primary ingress address. This embodiment corresponds to the second case and the third case described above.

In an embodiment, the network node comprises a CE, and the method <NUM> further comprises sending a fourth PCEP message (e.g., PCRpt, PCUpd, or PCInitiate message) to the CE. The fourth PCEP message includes an ingress protection object body containing a fifth flag (e.g., the D flag in the BIER-TE-Path_Ingress-Protection Object Body <NUM>) and a sixth flag (e.g., the B flag). The fifth flag is set to the first binary value to instruct the CE to detect the failure of a primary ingress node and to switch traffic to a backup ingress node when the CE detects the failure. The sixth flag is set to a second binary value. This embodiment corresponds to the first case and the third case described above.

In an embodiment, the network node comprises a CE, and the method <NUM> further comprises sending a fourth PCEP message to the CE. The fourth PCEP message includes an ingress protection object body containing a fifth flag and a sixth flag. The fifth flag is set to a second binary value, and the sixth flag is set to the first binary value to instruct the CE to send traffic to both a primary ingress node and a backup ingress node. This embodiment corresponds to the second case described above.

<FIG> is a schematic diagram of a network apparatus <NUM> (e.g., a network controller, a network node, etc.). The network apparatus <NUM> is suitable for implementing the disclosed embodiments as described herein. The network apparatus <NUM> comprises ingress ports/ingress means <NUM> (a. , upstream ports) and receiver units (Rx)/receiving means <NUM> for receiving data; a processor, logic unit, or central processing unit (CPU)/processing means <NUM> to process the data; transmitter units (Tx)/transmitting means <NUM> and egress ports/egress means <NUM> (a. , downstream ports) for transmitting the data; and a memory/memory means <NUM> for storing the data. The network apparatus <NUM> may also comprise optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress ports/ingress means <NUM>, the receiver units/receiving means <NUM>, the transmitter units/transmitting means <NUM>, and the egress ports/egress means <NUM> for egress or ingress of optical or electrical signals.

The processor/processing means <NUM> is implemented by hardware and software. The processor/processing means <NUM> 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 <NUM> is in communication with the ingress ports/ingress means <NUM>, receiver units/receiving means <NUM>, transmitter units/transmitting means <NUM>, egress ports/egress means <NUM>, and memory/memory means <NUM>. The processor/processing means <NUM> comprises a BIER-TE module <NUM>. The BIER-TE module <NUM> is able to implement the methods disclosed herein. The inclusion of the BIER-TE module <NUM> therefore provides a substantial improvement to the functionality of the network apparatus <NUM> and effects a transformation of the network apparatus <NUM> to a different state. Alternatively, the BIER-TE module <NUM> is implemented as instructions stored in the memory/memory means <NUM> and executed by the processor/processing means <NUM>.

The network apparatus <NUM> may also include input and/or output (I/O) devices or I/O means <NUM> for communicating data to and from a user. The I/O devices or I/O means <NUM> 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 <NUM> may also include input devices, such as a keyboard, mouse, trackball, etc., and/or corresponding interfaces for interacting with such output devices.

Claim 1:
A method (<NUM>) implemented by a path computation element (<NUM>), PCE, configured to control a Bit Index Explicit Replication Traffic/Tree Engineering, BIER-TE, domain (<NUM>), the method being characterized in comprising:
sending (<NUM>) a first path computation element protocol, PCEP, message to a network node in the BIER-TE domain, wherein the first PCEP message includes a first path setup type capability type length value, TLV, and wherein the network node comprises a backup ingress node in the BIER-TE domain;
receiving (<NUM>) a second PCEP message from the network node, wherein the second PCEP message includes a second path setup type capability TLV comprising an ingress protection capability sub-TLV, wherein the ingress protection capability sub-TLV contains a first flag, and wherein the first flag is set to a first binary value to indicate that the network node is able to detect a failure of an adjacent network node; and
sending a third PCEP message to the backup ingress node, wherein the third PCEP message includes an ingress protection TLV containing:
a fourth flag set to a second binary value to request that the backup ingress node detect the failure of a primary ingress node and to let a forwarding entry for a backup BIER-TE path be active when the primary ingress node fails;
a service sub-TLV including a service label or a service identifier; and
a primary ingress sub-TLV including a primary ingress address.