Patent Description:
Data is transmitted over a network in data packets. Data packets typically include a header that includes information that is used to route the data packet from a source to a destination. Segment routing (SR) is a type of source routing used for transmitting data packets. When using SR, a data source chooses a path, sometimes referred to as a tunnel, and encodes the path into a header of a data packet. The path includes a plurality of nodes and links between the nodes. The nodes include routers, switches, or other devices capable of routing packets in a network. Links may be identified as segments from one node to another node. A list of segments that the data packet will travel across during transit from a source to a destination is included in a header of each data packet. Segments are identified in the header of the data packet by a segment identifier (SID). An example of SR path protection is described in document <CIT>.

A first aspect relates to a method for source routing ingress protection by a border gateway protocol (BGP) controller, the method comprising receiving a path computation request; calculating a first path from a first ingress node to an egress node; calculating a second path from a second ingress node to the egress node; transmitting a first message using BGP, the first message comprising the first path to the first ingress node; and transmitting a second message using BGP, the second message comprising the second path and an ingress protection indicator to the second ingress node. The ingress protection indicator comprises a segment routing, SR, ingress protection sub-type-length-value, sub-TLV, or some other indicator indicating that the second path is for ingress protection.

The method provides techniques that establish protections for an ingress node using BGP.

It should be noted that speaking strictly, a path is a physical item while a path route is information that describes the path. More loosely, and commonly, the term path may be used to refer to one or both of the actual path or the path route information. The context of its use should make clear what is being discussed. Accordingly, subsequent uses of the term "path" should be understood to include both possibilities.

By transmitting a second message using BGP, the second message comprising the second path and an ingress protection indicator to the second ingress node, protections are provided for an ingress node using BGP.

In a first implementation form of the method according to the first aspect as such, the first message comprises a plurality of segment identifiers of the first path, and wherein the second message comprises another plurality of segment identifiers of the second path.

In a second implementation form of the method according to the first aspect as such, the SR ingress protection sub-TLV comprises a primary ingress address sub-sub-TLV indicating an address of the first ingress node.

In a third implementation form of the method according to the first aspect as such, the SR ingress protection sub-TLV further comprises a service sub-sub-TLV comprising either a service label of a service carried on the first path or a service identifier of the service.

In a fourth implementation form of the method according to the first aspect as such, the SR ingress protection sub-TLV further comprises a traffic sub-sub-TLV comprising a description of traffic carried on the first path.

In a fifth implementation form of the method according to the first aspect as such, the second message comprises a flag, the flag instructing the second ingress node to set an entry for the second path in a forwarding information base (FIB) to an active state.

In a sixth implementation form of the method according to the first aspect as such, the first ingress node and the second ingress node are connected to a traffic source
A second aspect relates to a method for source routing ingress protection by a network node, the method comprising receiving a message using border gateway protocol (BGP) comprising a path and an ingress protection indicator; creating an entry in a forwarding information base (FIB) based on the message; and setting a state of the entry based on the message, the state comprising either active or inactive. The ingress protection indicator comprises a segment routing, SR, ingress protection sub-type-length-value, sub-TLV, or some other indicator indicating that the second path is for ingress protection.

In a first implementation form of the method according to the second aspect as such, the method further comprises transmitting traffic associated with the path when the state is set to active.

In a second implementation form of the method according to the second aspect as such, the method further comprises dropping traffic associated with the path when the state is set to inactive.

In a third implementation form of the method according to the second aspect as such, the method further comprises detecting a primary ingress node failure; and setting, responsive to the primary ingress node failure, the state to active.

A third aspect relates to network node for source routing ingress protection, wherein the network node is configured to implement the method according to the first aspect or any implementation thereof.

A fourth aspect relates to network node for source routing ingress protection, wherein the network node is configured to implement the method according to the second aspect or any implementation thereof.

It should be understood at the outset that, although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence.

The ingress node is a key component of the SR tunnel because the whole path/tunnel may depend on the ingress node to add the source route into the packets to be transported by the tunnel. In some approaches, ingress protection may be provided in a path computation element (PCE) protocol based network. However, there is currently no mechanism for protecting the ingress node (also referred to herein as an ingress) of the SR tunnel in a border gateway protocol (BGP) based network. BGP based networks currently use a different protocol for ingress protection. The embodiments disclosed herein provide protections for the ingress node of the SR tunnel in a BGP based network.

<FIG> is an embodiment of a network diagram <NUM> illustrating nodes and segments in a tunnel with a backup ingress node. The edge nodes <NUM> and <NUM> are configured to operate using BGP protocol and maybe configured as ingress nodes. An edge node refers to a node that is on the edge of a provider network. For example, provider network <NUM> includes edge node <NUM>, edge node <NUM>, edge node <NUM>, edge node <NUM>, and edge node <NUM>. Intermediate nodes in the provider network <NUM> include nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. A customer edge node <NUM> provides data to the provider network <NUM> for routing to a receiving customer edge node <NUM>. Links <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> connect devices for communication purposes. The links <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be wired (e.g., physical) or wireless and may communicate using various communication protocols. In other embodiments, any number of edge nodes, intermediate nodes, and segments/links may be present in a network.

Some edge nodes may be configured as ingress nodes or backup ingress nodes. To protect against failure of a primary ingress node, a backup ingress node may be selected and configured for ingress protection. In this example, edge node <NUM> is configured as the primary ingress node and edge node <NUM> is configured as the backup ingress node. A backup ingress node for a tunnel may be off-tunnel or on-tunnel. An off-tunnel backup ingress node refers to a backup ingress node that is not on the SR tunnel (e.g., edge node <NUM> is off-tunnel regarding an SR tunnel from edge node <NUM> to edge node <NUM>). An on-tunnel backup ingress node refers to a backup ingress that is on the SR tunnel (e.g., node <NUM> is on the SR tunnel from edge node <NUM> to edge node <NUM>). The terms SR tunnel and SR path may be interchangeable in the embodiments disclosed herein.

A BGP controller <NUM> may compute a backup path after creation of a primary path (e.g., the SR path from edge node <NUM> to edge node <NUM> via node <NUM>, node <NUM>, and node <NUM>) through a network. The backup path may be from edge node <NUM> to edge node <NUM> via a downstream node (e.g., node <NUM> or node <NUM>) of the edge node <NUM>. The downstream node is part of a primary SR tunnel (e.g., the SR tunnel from edge node <NUM> to edge node <NUM> via node <NUM>, node <NUM>, and node <NUM>). The backup path may satisfy given constrains if any constraints are given, for example Quality of Service (QoS), number of hops, shortest path, etc..

The BGP controller <NUM> may create a backup SR tunnel from the backup ingress node (e.g., edge node <NUM>) to the downstream node (e.g., node <NUM>, node <NUM>, or node <NUM>) to the egress node (edge node <NUM>) by allocating a list of segment identifiers (SIDs) or labels for the backup SR tunnel segment along the backup path. The BGP controller <NUM> may also store the list for the backup SR tunnel and associate the list with the primary ingress (edge node <NUM>) of the primary SR tunnel.

In an embodiment, nodes <NUM>, <NUM>, <NUM> and edge node <NUM> have node-SIDs <NUM>, <NUM>, <NUM> and <NUM> respectively, and links <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> have adjacency-SIDs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, respectively. The foregoing SIDs are merely examples of possible SIDs, any other type or length of identifier may be used. A tunnel may be defined by a list of SIDs. Any combination of node SIDs and/or link SIDs may be used. In one example, the path from edge node <NUM> to node <NUM> to node <NUM> to node <NUM> to edge node <NUM> for the primary SR tunnel is an explicit path satisfying a set of constraints, but not a shortest path from edge node <NUM> to edge node <NUM>. In an embodiment, the list of SIDs for the primary SR tunnel {<NUM>, <NUM>, <NUM>, <NUM>} may be allocated and sent to edge node <NUM> by BGP controller <NUM>. For packets imported into the primary SR tunnel, edge node <NUM> may add {<NUM>, <NUM>, <NUM>} to the packet header and send the packet to node <NUM> through link <NUM>. In an embodiment, the BGP controller <NUM> computes a backup path from edge node <NUM> to node <NUM> to node <NUM> to node <NUM> to edge node <NUM> satisfying the constraints. The BGP controller <NUM> sends the backup path having the segment list {<NUM>, <NUM>, <NUM>, <NUM>} to the edge node <NUM>. In another embodiment, the BGP controller <NUM> computes a backup path from edge node <NUM> to node <NUM> to node <NUM> to node <NUM> to edge node <NUM> satisfying the constraints. The BGP controller <NUM> sends the backup path having the segment list {<NUM>, <NUM>, <NUM>, <NUM>} to the edge node <NUM>.

After receiving the segment list from the BGP controller <NUM>, edge node <NUM> may create a forwarding entry, which adds {<NUM>, <NUM>, <NUM>} into a header of a packet to be carried by the primary SR tunnel when the primary ingress node fails. Edge node <NUM> may send the packets to node <NUM> through link <NUM> when edge node <NUM> fails. The BGP controller <NUM> may compute an alternative backup path (edge node <NUM> to node <NUM> to node <NUM> to node <NUM> to edge node <NUM>) from the backup ingress node (edge node <NUM>) satisfying constraints. This backup path has a segment list {<NUM>, <NUM>, <NUM>, <NUM>} and may be sent to the backup ingress node (edge node <NUM>). After receiving the segment list from the BGP controller <NUM>, edge node <NUM> may create a forwarding entry, which adds {<NUM>, <NUM>, <NUM>} into a header of a packet to be carried by the primary SR tunnel. Edge node <NUM> may then send the packet to node <NUM> through link <NUM> when edge node <NUM> fails.

In another embodiment, the path for the primary SR tunnel is a shortest path from the primary ingress (edge node <NUM>) to node <NUM> plus a shortest path from node <NUM> to an egress node (edge node <NUM>). In the case where shortest path is desired, SIDs for the nodes may be used in the path list rather than SIDs for the links. In this case, the list of SIDs for the primary SR tunnel {<NUM>, <NUM>} is sent to edge node <NUM> by BGP controller <NUM>. In an embodiment, after receiving the list, edge node <NUM> creates a forwarding entry which adds {<NUM>, <NUM>} into a packet to be transported by the SR tunnel. Because no links are identified in the forwarding entry, the shortest path between the edge node <NUM> and node <NUM> (SID <NUM>) and the shortest path between node <NUM> and edge node <NUM> (SID <NUM>) may be selected.

To compute the backup SR tunnel, the BGP controller <NUM> computes a shortest path from the backup ingress node (edge node <NUM>) to the downstream node <NUM> without going through the primary ingress (edge node <NUM>). In an embodiment, the cost of each link along SR tunnel is <NUM> while the cost of any other link may be <NUM>, and there is a shortest path from edge node <NUM> to node <NUM> without edge node <NUM> (e.g., edge node <NUM> to node <NUM> to node <NUM> is a shortest path). This shortest path may have the same segment list {<NUM>, <NUM>}, and the BGP controller <NUM> may send the list to the backup ingress node (edge node <NUM>). After receiving the list from BGP controller <NUM>, edge node <NUM> may create a forwarding entry, which adds {<NUM>, <NUM>} into the packet to be transported by the SR tunnel when edge node <NUM> fails. Edge node <NUM> may then send the packet along the shortest path to node <NUM> via node <NUM> when edge node <NUM> fails.

In some embodiments, the BGP controller <NUM> may send any combination of the following to the backup ingress node (e.g., edge node <NUM>): <NUM>) an internet protocol (IP) address or other identifier of the primary ingress node; <NUM>) a traffic description, which describes the traffic that the primary SR tunnel carries; <NUM>) a service SID/Label if any, which indicates the service, such as a Virtual Private Network (VPN) service, that the primary SR tunnel transports; and/or <NUM>) information needed for creating a backup SR tunnel, the backup SR tunnel including a backup SR tunnel segment list from the backup ingress node to the egress node of the primary SR tunnel. In one embodiment, the information needed for creating a backup SR tunnel is the backup path from the backup ingress node to the primary egress node and the segment list for the backup path.

In some embodiments, the backup ingress node (e.g., edge node <NUM>) creates a forwarding entry in a forwarding information base (FIB) after receiving the above information. The forwarding entry may be used to: <NUM>) import packets/traffic into the backup SR tunnel according to the traffic description for the primary SR tunnel; <NUM>) push the service SID/Label (if any) into each of the packets to be imported into the backup SR tunnel; <NUM>) push the list of SIDs/Labels for the backup SR tunnel into each of the packets to be imported into the backup SR tunnel; and/or <NUM>) send the packet to the direct downstream node of the backup ingress node along the backup SR tunnel.

The backup ingress node (e.g., edge node <NUM>) may send the BGP controller <NUM> a report to confirm that the protection is available for the primary ingress node (e.g., edge node <NUM>) after the forwarding entry is created successfully. The BGP controller <NUM> may record the status of the primary ingress node (e.g., edge node <NUM>) of the primary SR tunnel regarding ingress protection according to the confirmation received from the backup ingress node (e.g., edge node <NUM>).

In a further example, a primary SR tunnel exists between a primary ingress node and a primary egress node through one or more downstream transit nodes. A backup ingress node may be computed or configured to protect the failure of the primary ingress node. A source node (the source of the traffic, e.g., customer edge node <NUM>)) may be connected to the primary ingress node (e.g., edge node <NUM>) and the backup ingress node (e.g., edge node <NUM>).

In an embodiment, the source node (e.g., customer edge node <NUM>) sends the traffic to the primary ingress node for the primary SR tunnel in normal operations. The primary ingress node imports the traffic into the tunnel transporting the traffic to its destination. If the primary ingress node fails, the source node switches the traffic to the backup ingress node (e.g., edge node <NUM>) after detecting the failure. A forwarding entry in the FIB on the backup ingress node imports the traffic into the backup SR tunnel transporting the traffic to its destination.

In another embodiment, the source node sends the traffic to the primary ingress node for the primary SR tunnel. The primary ingress node imports the traffic into the tunnel transporting the traffic to the destination. The source node also sends the traffic to the backup ingress node, which drops the traffic in normal operations through setting the corresponding forwarding entry in the FIB to be inactive. If the primary ingress node fails, the backup ingress node sets the corresponding forwarding entry in the FIB to be active and begins to import the traffic into the backup SR tunnel. The active forwarding entry in the FIB on the backup ingress node imports the traffic into the backup SR tunnel.

The BGP controller <NUM> may send ingress protection information to the backup ingress node using a BGP UPDATE message. The UPDATE message includes a network reliability reachability information (NLRI) portion with a tunnel encapsulation attribute of type set to <NUM>, where the attribute of type <NUM> comprises tunnel encapsulation attribute type-length-values (TLVs). The tunnel encapsulation attribute TLV is set to tunnel type <NUM>, indicating a SR policy TLV that includes a number of sub-TLVs. A SR path ingress protection sub-TLV is present in the SR policy sub-TLVs. The SR path ingress protection sub-TLV may include several sub-sub-TLVs. The sub-sub TLVs may include one or more of a primary ingress sub-sub-TLV, a service identifier (ID) sub-sub-TLV, or a traffic description sub-sub-TLV.

<FIG> is a diagram of an embodiment of a NLRI <NUM>. The NLRI <NUM> includes an <NUM>-bit NLRI length field, a <NUM>-bit distinguisher field, a <NUM>-bit color field, and an endpoint field that is either <NUM> bytes for an IPv4 address or <NUM> bytes for an IPv6 address of the endpoint.

<FIG> is a diagram of an embodiment of a tunnel encapsulation attribute <NUM>. The tunnel encapsulation attribute comprises an <NUM>-bit attributes flags field, an <NUM>-bit attribute type field, a <NUM>-bit length field, and a TLVs field. The attribute flags may be set as follows. Bit <NUM> is the optional bit. The optional bit indicates whether the attribute is optional or well-known if it is set to <NUM> or <NUM> respectively. Bit <NUM> is the transitive bit. The transitive bit indicates whether the attribute is transitive or non-transitive if it is set to <NUM> or <NUM>, respectively. Bit <NUM> is the partial bit. The partial bit indicates whether the attribute is partial or complete if it is set to <NUM> or <NUM> respectively. Bit <NUM> is the extended length bit. The length is either b or <NUM> bits (i.e. <NUM> or <NUM> octets) if it is set to <NUM> or <NUM> respectively.

In this example, the attribute type is set to <NUM>, indicating a tunnel encapsulation attribute. <FIG> is a diagram of an embodiment of a tunnel encapsulation attribute TLV <NUM> found in the TLV field of the tunnel encapsulation attribute <NUM>. The tunnel encapsulation attribute TLV <NUM> includes a <NUM>-bit tunnel type field, a <NUM>-bit length field, and a sub-TLVs field. <FIG> is a diagram of an embodiment of a sub-TLV <NUM> format. The sub-TLV <NUM> includes an <NUM>-bit sub-TLV type field, a <NUM>-bit or <NUM>-bit length field, and a variable field with size determined by the length field.

<FIG> is a diagram of an embodiment of a SR tunnel ingress protection sub-TLV <NUM>. The SR tunnel ingress protection sub-TLV <NUM> may be part of a tunnel encapsulation attribute TLV <NUM>. The SR tunnel ingress protection sub-TLV <NUM> includes an <NUM>-bit type field, a variable-length length field, an <NUM>-bit flags field, and a variable length sub-sub-TLVs field. The flags field may include an 'A' flag of <NUM> bit. While 'A' is used here, the flag may be named or identified in other ways. When the A flag is set to <NUM>, this requests that a backup ingress node set the forwarding entry for the backup SR path to Active in a forwarding information base (FIB) or BGP table. When the A flag is set to <NUM>, this requests that a backup ingress node set the forwarding entry for the backup SR path to inactive initially and to make the entry active after detecting the failure of the primary ingress node of the primary SR path. The sub-sub-TLVs field may contain a number of sub-sub-TLVs, for example one or more of a service sub-sub TLV, a primary-ingress sub-sub-TLV, and/or a traffic description sub-sub-TLV.

<FIG> is a diagram of an embodiment of a primary ingress address sub-sub-TLV for IP version <NUM> (IPv4) <NUM>. The primary ingress address sub-sub-TLV for IPv4 <NUM> includes an <NUM>-bit type field, an <NUM>-bit length field, and a <NUM>-bit (<NUM>-byte) primary ingress address field for the IPv4 address of the primary ingress node, e.g., edge node <NUM>.

<FIG> is a diagram of an embodiment of a primary ingress address sub-sub-TLV for IP version <NUM> (IPv6) <NUM>. The primary ingress address sub-sub-TLV for IPv6 <NUM> includes an <NUM>-bit type field, an <NUM>-bit length field, and a <NUM>-bit (<NUM>-byte) primary ingress address field for the IPv6 address of the primary ingress node, e.g., edge node <NUM>.

A service sub-sub TLV may contain a service ID or label, e.g., a VPN label, to be added into a packet to be carried by a SR path/tunnel. The service sub-sub TLV may have two formats, one where the service is identified by a label and another where the service is identified by a service ID of <NUM> or <NUM> bits. <FIG> is a diagram of an embodiment of a service label sub-sub-TLV <NUM>. The service label sub-sub-TLV <NUM> includes an <NUM>-bit type field, an <NUM>-bit length field, a <NUM>-bit zero pad, and a <NUM>-bit service label field. <FIG> is a diagram of an embodiment of a <NUM>-bit service ID sub-sub-TLV <NUM>. The <NUM>-bit service ID sub-sub-TLV <NUM> includes an <NUM>-bit type field, an <NUM>-bit length field, and a <NUM>-bit (<NUM>-byte) service ID field. <FIG> is a diagram of an embodiment of a <NUM>-bit service ID sub-sub-TLV <NUM>. The <NUM>-bit service ID sub-sub-TLV <NUM> includes an <NUM>-bit type field, an <NUM>-bit length field, and a <NUM>-bit (<NUM>-byte) service ID field. When there is a service sub-sub-TLV in the SR path ingress protection sub-TLV, the ID or label in the service sub-sub-TLV will be included in the forwarding entries of data to be sent over the backup path. When a packet is imported into a backup path using the forwarding entries, the service ID or label is pushed first and then the sequence of segments represented in a segment list sub-TLV.

<FIG> is a diagram of an embodiment of a Forward Equivalent Class (FEC) sub-sub-TLV <NUM> which describes the traffic to be imported into the backup SR tunnel and is an IP prefix. The FEC sub-sub-TLV <NUM> includes an <NUM>-bit type field, an <NUM>-bit length field, an <NUM> bit IP prefix length field, and a variable-length IP prefix field.

<FIG> is a diagram of an embodiment of an interface index sub-sub-TLV <NUM>. The interface index sub-sub-TLV <NUM> indicates the interface from which the traffic is received and imported into the backup SR tunnel. The interface index sub-sub-TLV <NUM> includes an <NUM>-bit type field, an <NUM>-bit length field, and a <NUM>-bit (<NUM>-byte) interface index field. <FIG> is a diagram of an embodiment of an interface IP address sub-sub-TLV <NUM> that indicates an IP address of the interface from which the traffic is received and imported into the backup SR tunnel. The interface IP address sub-sub-TLV <NUM> includes an <NUM>-bit type field, an <NUM>-bit length field, and either a <NUM>-bit or <NUM>-bit IP address field for an IPv4 address or an IPv6 address respectively.

<FIG> is a flow diagram of an embodiment of a method <NUM> for BGP ingress protection at a BGP controller. The method <NUM> begins at block <NUM> when a BGP controller receives a path computation request. The path computation request may be received from an application that is providing data traffic, a system operator, or some other entity.

The method <NUM> continues at block <NUM> when the BGP controller calculates a first path from a first ingress node to an egress node. The first path may traverse a network where the first ingress node and egress node are edge nodes of the network. In addition to the first ingress node and egress node, the first path may include any number of additional nodes which may be referred to as downstream nodes, e.g., downstream of the first ingress node. The first ingress node may receive data traffic for transmission via the first path from a customer edge node or some other source of data traffic.

At block <NUM>, the BGP controller may determine a second ingress node to act as a backup ingress node. The second ingress node is configured to receive data traffic from the same source as the first ingress node. In this configuration, both the first ingress node and the second ingress node may receive data traffic from the same source for transmission to the egress node. In some cases, the source may transmit the data traffic to both the first ingress node and the second ingress node substantially simultaneously or may transmit to only the first ingress node and then to only the second ingress node if the first ingress node fails.

At block <NUM>, the BGP controller may calculate a second path from the second ingress node to the egress node. The second ingress node is an edge node of the network. The second path may include at least a portion of the first path. For example, the second path may be from the second ingress node to one of the downstream nodes of the first path. From the downstream node, the second path would follow the first path.

At block <NUM>, the BGP controller may transmit a first message including the first path to the first ingress node. The first message may be a BGP UPDATE message that includes the first path. The first path in the first message may be identified by a list of links that data traffic should traverse in order to reach the egress node. In another case, the first path may be identified by a list of nodes that the data traffic should traverse in order to reach the egress node. The lists may be segment lists where nodes and segments are identified by SIDs.

At block <NUM>, the BGP controller may transmit a second message including the second path and an ingress protection indicator to the second ingress node. The second message may be a BGP UPDATE message with the second path and a SR tunnel ingress protection sub-TLV, e.g., SR tunnel ingress protection sub-TLV <NUM>. The second path in the second message may be identified by a list of links that data traffic should traverse in order to reach the egress node. In another case, the second path may be identified by a list of nodes that the data traffic should traverse in order to reach the egress node. The lists may be segment lists where nodes and segments are identified by SIDs. The ingress protection indicator may be the SR tunnel ingress protection sub-TLV or some other indicator indicating that the second path is for ingress protection.

<FIG> is a flow diagram of an embodiment of a method <NUM> for BGP ingress protection at a secondary ingress node. The method <NUM> begins at block <NUM> when an edge node receives a message comprising a path and an ingress protection indicator. The path may indicate a path used for a tunnel between a backup ingress node and an egress node. The message may be a BGP UPDATE message with the path and a SR tunnel ingress protection sub-TLV, e.g., SR tunnel ingress protection sub-TLV <NUM>. The path in the message may be identified by a list of links that data traffic should traverse in order to reach the egress node. In another case, the second path may be identified by a list of nodes that the data traffic should traverse in order to reach the egress node. The lists may be segment lists where nodes and segments are identified by SIDs. The ingress protection indicator may be the SR tunnel ingress protection sub-TLV or some other indicator indicating that the path is for ingress protection.

At block <NUM>, the edge node may create an entry in a forwarding information base (FIB). The entry may be set to active or inactive based on a flag or other indicator in the message received at block <NUM>. Block <NUM> is a decision point for steps to be taken when the entry is active or when the entry is not active. If the entry is set to active, at block <NUM>, the edge node will transmit any traffic associated with the path along the path identified in the message. The edge node may determine the traffic is associated with the path based on a description of the type of traffic associated with the path included in the message. The entry may be set to active when a traffic source or customer edge node, e.g., customer edge node <NUM>, that is providing data for transmission along the path is configured to detect a failure in a primary ingress node, e.g., ingress node <NUM>. In this case, the traffic source or customer edge node begins transmitting the traffic to the backup ingress node, e.g., edge node <NUM>, when a failure is detected at the primary ingress node.

If the entry is not set to active, at block <NUM>, the edge node will drop any traffic associated with the path identified in the message. At decision point block <NUM>, the edge node may detect that the primary node has failed. The edge node may receive link state messages. A link-state message may indicate that the primary ingress node has failed. In another case, the edge node may receive some other message indicating that the primary ingress node has failed. If the edge node determines that the primary edge node has failed, the edge note may set the entry in the FIB to active at block <NUM> and begin transmitting any traffic associated with the path along the path identified in the message at block <NUM>. In these cases, the traffic source or customer edge node may transmit the data to both the primary ingress node and backup ingress node substantially simultaneously, or the traffic source or customer edge node begins transmitting the traffic to the backup ingress node when a failure is detected at the primary ingress node.

<FIG> is a schematic diagram of an electronic device <NUM> according to an embodiment of the disclosure. The electronic device <NUM> is suitable for implementing the disclosed embodiments as described herein. The electronic device <NUM> comprises ingress ports <NUM> and receiver units (Rx) <NUM> for receiving data; a processor, logic unit, or central processing unit (CPU) <NUM> to process the data; transmitter units (Tx) <NUM> and egress ports <NUM> for transmitting the data; and a memory <NUM> for storing the data. The electronic device <NUM> may also comprise optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress ports <NUM>, the receiver units <NUM>, the transmitter units <NUM>, and the egress ports <NUM> for egress or ingress of optical or electrical signals.

The processor <NUM> is implemented by hardware and software. The processor <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 <NUM> is in communication with the ingress ports <NUM>, receiver units <NUM>, transmitter units <NUM>, egress ports <NUM>, and memory <NUM>. The processor <NUM> comprises a path routing module <NUM>. The path routing module <NUM> implements the disclosed embodiments described above. For instance, the path routing module <NUM> implements, processes, parses, prepares, or provides the various path routing. The inclusion of the path routing module <NUM> therefore provides a substantial improvement to the functionality of the device <NUM> and effects a transformation of the device <NUM> to a different state. Alternatively, the path routing module <NUM> is implemented as instructions stored in the memory <NUM> and executed by the processor <NUM>.

The memory <NUM> comprises one or more disks, tape drives, and solid-state drives and may be used as an overflow 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 <NUM> may be volatile and/or non-volatile and may be read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), and/or static random-access memory (SRAM).

Claim 1:
A method for source routing ingress protection by a controller (<NUM>), the method comprising:
receiving (<NUM>) a path computation request;
calculating (<NUM>) a first path from a first ingress node to an egress node;
calculating (<NUM>) a second path from a second ingress node to the egress node;
transmitting (<NUM>) a first message using border gateway protocol, BGP, the first message comprising the first path to the first ingress node; and
transmitting (<NUM>) a second message using BGP, the second message comprising the second path and an ingress protection indicator to the second ingress node, the ingress protection indicator comprising a segment routing, SR, ingress protection sub-type-length-value, sub-TLV, or some other indicator indicating that the second path is for ingress protection.