Basic Concepts

Segment Classification

Figure 1-2494 shows prefix, adjacency, and node SID examples.

Figure 1-2494 Prefix, adjacency, and node SID examples

In general, a prefix SID identifies a destination address, and an adjacency SID identifies a link for outgoing data packets. The prefix and adjacency SIDs are similar to the destination IP address and outbound interface in conventional IP forwarding, respectively. In an IGP area, devices propagate their node and adjacency SIDs using extended IGP messages, so that any device in the area can obtain information about the other devices.

Combining prefix (node) and adjacency SIDs in sequence can construct any network path. Every hop on a path identifies the next hop based on the top SID in the label stack. SID information is stacked in sequence at the top of the data header. If the top SID identifies another node, the receive node forwards the data packet to that node in ECMP mode. If the top SID identifies the local node, the receive node removes the top SID and proceeds with the follow-up procedure.

Prefix, adjacency, and node SIDs can either be used separately or be combined. They are mainly used in the following three modes:

Prefix SID

A prefix SID-based forwarding path is computed by an IGP using the SPF algorithm. In Figure 1-2495, node Z is the destination node, and its prefix SID is 100. After the prefix SID is propagated using an IGP, all the other nodes in the IGP area learn the prefix SID of node Z and then run SPF to compute their shortest paths (with the minimum cost) to node Z.

Figure 1-2495 Prefix SID-based forwarding path

If equal-cost paths exist on the network, ECMP can be implemented. If no equal-cost paths exist, link backup can be implemented. Therefore, prefix SID-based forwarding paths are not fixed, and the ingress cannot control the entire packet forwarding path.

Adjacency SID

In Figure 1-2496, an adjacency SID is allocated to each adjacency on the network, and a segment list with multiple adjacency SIDs is defined on the ingress, so that any strict explicit path can be specified. This mode facilitates SDN implementation.

Figure 1-2496 Adjacency SID-based forwarding path

Each adjacency SID corresponds to a device interface. If the adjacency corresponding to an adjacency SID fails, only end-to-end protection can be implemented. After local protection is configured for adjacency SIDs, the SIDs carry a protection flag. During path computation, the controller can select an adjacency SID with the protection flag and compute a backup path for the adjacency SID. In this way, when the adjacency corresponding to the adjacency SID fails, traffic can be rapidly switched to the backup path.

Adjacency SID + Node SID

In Figure 1-2497, adjacency and node SIDs are combined to forcibly include a specific adjacency on a path. Based on node SIDs, nodes can run SPF to compute the shortest path or establish multiple paths to load-balance traffic. In this situation, paths are not strictly fixed, and therefore, they are also called loose explicit paths.

Figure 1-2497 Adjacency SID + node SID-based forwarding path

SR Forwarding Mechanism

SR can be directly used in the MPLS architecture, without requiring any changes to the forwarding plane. SIDs are encoded as MPLS labels, and the segment list is encoded as a label stack. The segment to be processed is at the stack top. Once a segment is processed, the corresponding label is removed from the label stack.

SR based on the MPLS forwarding mechanism is also called SR-MPLS.

SR Label Conflicts and Handling Rules

Prefix SIDs are manually configured on different devices, which may result in label conflicts. Label conflicts are classified as prefix conflicts or SID conflicts. A prefix conflict indicates that the same prefix is associated with different SIDs, whereas a SID conflict indicates that the same SID is associated with different prefixes.

IS-IS TLV Extensions for SIDs

Prefix-SID Sub-TLV

The Prefix-SID sub-TLV carries IGP prefix SID information. Figure 1-2498 shows the format of this sub-TLV.

Figure 1-2498 Prefix-SID sub-TLV format

Table 1-1019 Fields in the Prefix-SID sub-TLV

Field	Length	Description
Type	8 bits	Unassigned. The recommended value is 3.
Length	8 bits	Packet length.
Flags	8 bits	Flags field. Figure 1-2499 shows the format of this field. Figure 1-2499 Flags field In this field: R: re-advertisement flag. If this flag is set, the prefix to which the prefix SID is attached may be imported from another protocol or propagated by a node of another level (for example, from IS-IS Level 1 to Level 2). N: node SID flag. If this flag is set, the prefix SID refers to the node identified by the prefix. Generally, this flag is set if a loopback interface address is configured as the prefix SID. P: no-PHP flag. If this flag is set, penultimate hop popping (PHP) is disabled so that the penultimate node does not remove the label of the egress before sending the packet to the egress. E: explicit-null flag. If this flag is set, the explicit-null label function is enabled, requiring the upstream neighbor to replace the prefix SID with a prefix SID that has an explicit null value before forwarding the packet. V: value flag. If this flag is set, the prefix SID carries a value, instead of an index. By default, the flag is not set. L: local flag. If this flag is set, the value or index carried in the prefix SID is of local significance. By default, the flag is not set. When computing the outgoing label for a packet destined for a prefix, a node must consider the P and E flags in the prefix SID advertised by the next hop, regardless of whether the optimal path to the prefix SID passes through the next hop. When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a reachability advertisement originated by another IS-IS speaker, the local node must set the P flag and clear the E flag in relevant prefix SIDs. The following behavior is associated with the settings of P and E flags: If the P flag is not set, any upstream neighbor of the prefix SID originator must remove the prefix SID. This is equivalent to the PHP mechanism used in MPLS forwarding. The MPLS EXP bits of the prefix SID are also cleared. In addition, if the P flag is not set, the received E flag is ignored. If the P flag is set, then: If the E flag is not set, any upstream neighbor of the prefix SID originator must keep the prefix SID on top of the stack. This is useful when, for example, the originator of the Prefix-SID must stitch the incoming packet into a continuing MPLS LSP to the final destination. If the E flag is set, any upstream neighbor of the prefix SID originator must replace the prefix SID with a prefix SID having an explicit null value. In this mode, MPLS EXP bits can be reserved. If the originator of the prefix SID is the final destination for the related prefix, the packet with original EXP bits can be received. MPLS EXP bits can be used for QoS services.
Algorithm	8 bits	Algorithm that is used. 0: shortest path first (SPF) algorithm 1: strict SPF algorithm, which is not supported currently
SID/Index/Label (variable)	Variable	This field contains either of the following information based on the V and L flags: 4-octet index defining the offset in the SID/label space. In this case, the V and L flags cannot be set. 3-octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V and L flags must be set.

Adj-SID Sub-TLV

The Adj-SID sub-TLV is an optional sub-TLV carrying IGP adjacency SID information. Figure 1-2500 shows the format of this sub-TLV.

Figure 1-2500 Adj-SID sub-TLV format

Table 1-1020 Fields in the Adj-SID sub-TLV

Field	Length	Description
Type	8 bits	Unassigned. The recommended value is 31.
Length	8 bits	Packet length.
Flags	8 bits	Flags field. Figure 1-2501 shows the format of this field. Figure 1-2501 Flags field In this field: F: address family flag. 0: IPv4 1: IPv6 V: value flag. If the flag is set, the Adj-SID carries a label value. By default, the flag is set. L: local flag. If the flag is set, the value or index carried by the Adj-SID has local significance. By default, the flag is set. S: set flag. If the flag is set, the Adj-SID refers to a set of adjacencies. P: persistent flag. If the flag is set, the Adj-SID is persistently allocated, for example, the Adj-SID remains unchanged regardless of a device restart or interface flapping.
Weight	8 bits	Weight of the Adj-SID for the purpose of load balancing.
SID/Index/Label (variable)	Variable	This field contains either of the following information based on the V and L flags: 3-octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V and L flags must be set. 4-octet index defining the offset in the SID/label space. In this case, the V and L flags cannot be set.

A designated intermediate system (DIS) is elected as a medium during IS-IS communications on a LAN. On the LAN, a node only needs to advertise one adjacency to the DIS and obtain all adjacency information from the DIS, without the need to exchange adjacency information with other nodes.

When SR is used, each node needs to advertise the Adj-SID of each of its neighbors. On the LAN, each node advertises only an IS-IS Extended IS reachability TLV-22 to the DIS and encapsulates the set of Adj-SIDs (for each of its neighbors) inside a newly defined sub-TLV: LAN-Adj-SID sub-TLV. This sub-TLV contains the set of Adj-SIDs assigned by a node to each of its LAN neighbors.

Figure 1-2502 shows the format of the LAN-Adj-SID sub-TLV.

Figure 1-2502 LAN-Adj-SID sub-TLV format

SID/Label Sub-TLV

The SID/Label sub-TLV contains a SID or an MPLS label. It is a part of the SR-Capabilities sub-TLV.

Figure 1-2503 shows the format of the SID/Label sub-TLV.

Figure 1-2503 SID/Label sub-TLV format

SID/Label Binding TLV

The SID/Label Binding TLV, which applies to SR and LDP interworking scenarios, can be used to advertise prefix-to-SID mappings.

Figure 1-2504 shows the format of the SID/Label Binding TLV.

Figure 1-2504 SID/Label Binding TLV format

Table 1-1022 Fields in the SID/Label Binding TLV

Field	Length	Description
Type	8 bits	Unassigned. The recommended value is 1.
Length	8 bits	Packet length.
Flags	8 bits	Flags field. +-+-+-+-+-+-+-+-+ |F|M|S|D|A| | +-+-+-+-+-+-+-+-+
Range	16 bits	Range of addresses and their associated prefix SIDs.
Prefix Length	8 bits	Prefix length.
Prefix	Variable	Prefix.
SubTLVs	Variable	Sub-TLVs, for example, the SID/Label sub-TLV.

IS-IS TLV Extensions for SR Capabilities

SR-Capabilities Sub-TLV

SR requires each node to advertise its SR capabilities and the range of global SIDs (or global indexes). To meet this requirement, the SR-Capabilities sub-TLV is defined and inserted into the IS-IS Router Capability TLV-242 for transmission. The SR-Capabilities sub-TLV can be propagated only within the same IS-IS level and must not be propagated across IS-IS levels.

Figure 1-2505 shows the format of the SR-Capabilities sub-TLV.

Figure 1-2505 SR-Capabilities sub-TLV format

Table 1-1023 Fields in the SR-Capabilities sub-TLV

Field	Length	Description
Type	8 bits	Unassigned. The recommended value is 2.
Length	8 bits	Packet length.
Flags	8 bits	Flags field. Figure 1-2506 shows the format of this field. Figure 1-2506 Flags field In this field: I: MPLS IPv4 flag. If the flag is set, SR-MPLS IPv4 packets received by all interfaces can be processed. V: MPLS IPv6 flag. If the flag is set, SR-MPLS IPv6 packets received by all interfaces can be processed.
Range	24 bits	SRGB range. For example, the originating node advertises SR-Capabilities of the following ranges: SR-Capability 1: range: 100; SID value: 100 SR-Capability 2: range: 100; SID value: 1000 SR-Capability 3: range: 100; SID value: 500 The receiving nodes concatenate the ranges in the received order and build the SRGB as follows: SRGB = [100, 199] [1000, 1099] [500, 599] Different indexes may span multiple ranges. Index 0 indicates label 100. ... Index 99 indicates label 199. Index 100 indicates label 1000. Index 199 indicates label 1099. ... Index 200 indicates label 500. ...
SID/Label Sub-TLV (variable)	Variable	For details, see SID/Label Sub-TLV. The SID/Label sub-TLV contains the first value of the involved SRGB. When multiple SRGBs are configured, ensure that the SRGB sequence is correct and the SRGBs do not overlap.

SR Local Block Sub-TLV

The SR Local Block sub-TLV contains the range of labels that a node has reserved for local SIDs. Local SIDs are used for adjacency SIDs, and may also be allocated by components other than the IS-IS protocol. For example, an application or a controller may instruct the node to allocate a specific local SID. Therefore, in order for such applications or controllers to know what local SIDs are available on the node, it is required that the node advertises its SR local block (SRLB).

Figure 1-2507 shows the format of the SR Local Block sub-TLV.

Figure 1-2507 SR Local Block sub-TLV format

A node advertising the SR Local Block sub-TLV may also have other label ranges, outside the SRLB, for its local allocation purposes that are not advertised in the SRLB. For example, it is possible that an adjacency SID is allocated using a local label, which is not part of the SRLB.

Opaque LSA Header Format

Figure 1-2508 Opaque LSA header format

Figure 1-2509 shows the format of the OSPFv2 Extended Prefix TLV.

Figure 1-2509 Format of the OSPFv2 Extended Prefix TLV

Figure 1-2510 shows the format of the OSPFv2 Extended Link TLV.

Figure 1-2510 Format of the OSPFv2 Extended Link TLV

Table 1-1028 describes OSPFv2 extensions for SR.

SR-Algorithm TLV

A node may use different algorithms to calculate reachability to other nodes or to prefixes attached to these nodes. Examples of these algorithms are SPF and various SPF variant algorithms. The SR-Algorithm TLV allows the node to advertise the algorithms that the node is currently using.

Figure 1-2511 shows the format of the SR-Algorithm TLV.

Figure 1-2511 SR-Algorithm TLV format

SID/Label Range TLV

The SID/Label Range TLV is used to advertise multiple SIDs or labels at a time, or a SID or label range.

Figure 1-2512 shows the format of the SID/Label Range TLV.

Figure 1-2512 SID/Label Range TLV format

SR Local Block TLV

The SR Local Block TLV contains the range of labels reserved by a node for local SIDs. Local SIDs are used for adjacency SIDs, and may also be allocated by other components. For example, applications or controllers may instruct a node to allocate a special local SID. The node must therefore advertise its SR local block (SRLB) so that these applications or controllers can learn what local SIDs are available on the node.

Figure 1-2513 shows the format of the SR Local Block TLV.

Figure 1-2513 Format of the SR Local Block TLV

SRMS Preference TLV

The SRMS Preference TLV advertises the priority of the SR mapping server as which the local node functions. The TLV is used in Sr mapping server election. Figure 1-2514 shows the format of the SRMS Preference TLV.

Figure 1-2514 SRMS Preference TLV format

SID/Label Sub-TLV

The SID/Label Sub-TLV contains a SID or an MPLS label. Figure 1-2515 shows the format of the SID/Label Sub-TLV.

Figure 1-2515 SID/Label Sub-TLV format

Prefix SID Sub-TLV

The Prefix-SID Sub-TLV carries IGP-Prefix-SID information in the format shown in Figure 1-2516.

Figure 1-2516 Prefix-SID Sub-TLV format

Table 1-1034 Fields in the Prefix-SID Sub-TLV

Field	Length	Description
Type	16 bits	TLV type value.
Length	16 bits	Packet length.
Flags	8 bits	Flags field. Figure 1-2517 shows its format. Figure 1-2517 Flags field The meaning of each flag is as follows: NP: no-PHP flag. If this flag is set, PHP is disabled so that the penultimate node sends a labeled packet to the egress. M: Mapping server flag. If the flag is set, a SID is advertised by a mapping server. E: explicit-null flag. If this flag is set, the explicit null label function is enabled. An upstream neighbor must replace an existing label with an explicit null label before forwarding a packet. V: value flag. If this flag is set, a prefix SID carries a value, instead of an index. By default, the flag is not set. L: local flag. If this flag is set, the value or index carried in a prefix SID is of local significance. By default, the flag is not set. When computing the outgoing label for a packet destined for a prefix, a node must consider the NP and E flags in the prefix SID advertised by the next hop. This is necessary regardless of whether the optimal path to the prefix SID passes through the next hop. The following behavior is related to P and E flags: If the NP flag is not set, any upstream node of the prefix SID producer must strip off the prefix SID, which is similar to PHP in MPLS forwarding. The MPLS EXP bit is also cleared. In addition, if the P flag is not set, the received E flag is ignored. If the NP flag is set, the following situations occur: If the E flag is not set, any upstream node of the prefix SID producer must reserve the prefix SID on the top of the label stack. This method is used in path stitching. For example, a prefix SID producer may use this label to forward a packet to another MPLS LSP. If the E flag is set, any upstream node of the prefix SID producer must replace the prefix SID label with an explicit null label. In this mode, the MPLS EXP flag is retained. If the prefix SID producer is the destination, the node can receive the original MPLS EXP field value. The MPLS EXP flag can be used in QoS services.
Reserved	8 bits	Reserved field.
MT-ID	8 bits	Multi-topology ID.
Algorithm	8 bits	Algorithm: 0: shortest path first (SPF) algorithm 1: strict SPF algorithm, which is not supported currently
SID/Index/Label (variable)	Variable length	This field contains either of the following information based on the V and L flags: 4-byte label offset value within the SID/label range. In this case, V and L flags are not set. 3-byte local label: The 20 rightmost bits are a label value. In this case, the V and L flags must be set.

Adj-SID Sub-TLV

The Adj-SID Sub-TLV is an optional sub-TLV carrying IGP adjacency SID information. Figure 1-2518 shows the format of this sub-TLV.

Figure 1-2518 Adj-SID Sub-TLV format

Table 1-1035 Fields in the Adj-SID Sub-TLV

Field	Length	Description
Type	16 bits	TLV type value.
Length	16 bits	Packet length.
Flags	8 bits	Flags field. Figure 1-2519 shows its format. Figure 1-2519 Flags field The meaning of each flag is as follows: V: Value/Index flag. If this flag is set, an Adj-SID carries a label value. If this flag is not set, an Adj-SID carries a relative index. L: Local/Global flag. If this flag is set, the Adj-SID value or index is of local significance. If this flag is not set, the Adj-SID value or index is of global significance. G: group flag. If this flag is set, an Adj-SID is an adjacency group. P: permanent label. If this flag is set, an Adj-SID is a permanently assigned SID, which is unchanged, regardless of a device restart or interface flapping.
Reserved	8 bits	Reserved field.
MT-ID	8 bits	Multi-topology ID.
Weight	8 bits	Weight. The Adj-SID weight is used for load balancing.
SID/Index/Label (variable)	Variable length	This field contains either of the following information based on the V and L flags: 3-byte local label: The 20 rightmost bits are a label value. In this case, the V and L flags must be set. 4-byte label offset value within the SID/label range. In this case, V and L flags are not set.

LAN Adj-SID Sub-TLV

In SR scenarios, each node needs to advertise the Adj-SID of each of its neighbors. On a broadcast, NBMA, or mixed network, the LAN-Adj-SID Sub-TLV is used to send SID/label information to non-DR devices.

Figure 1-2520 shows the format of the LAN-Adj-SID Sub-TLV. Compared with the Adj-SID Sub-TLV, the LAN Adj-SID Sub-TLV has an additional Neighbor ID field, which represents the router ID of the device that advertises the LAN Adj-SID Sub-TLV.

Figure 1-2520 LAN-Adj-SID Sub-TLV format

BGP EPE

Figure 1-2521 BGP EPE networking

On the network shown in Figure 1-2521, ASBR1 and ASBR3 are directly connected through two physical links. An EBGP peer relationship is established between ASBR1 and ASBR3 through loopback interfaces. ASBR1 runs BGP EPE to assign the Peer-Node SID 28001 to its peer (ASBR3) and to assign the Peer-Adj SIDs 18001 and 18002 to the physical links. For an EBGP peer relationship established between directly connected physical interfaces, BGP EPE allocates a Peer-Node SID rather than a Peer-Adj SID. For example, on the network shown in Figure 1-2521, BGP EPE allocates only Peer-Node SIDs 28002, 28003, and 28004 to the ASBR1-ASBR5, ASBR2-ASBR4, and ASBR2-ASBR5 peer relationships, respectively.

Peer-Node SIDs and Peer-Adj SIDs are effective only on local devices. Different devices can have the same Peer-Node SID or Peer-Adj SID. Currently, BGP EPE supports IPv4 EBGP peers, IPv4 IBGP peers, and BGP confederations.

Traffic Statistics Collection

On the network shown in Figure 1-2521, ASBR1 has two Peer-Adj SIDs (18001 and 18002) to ASBR3, one Peer-Node SID (28001) to ASBR3, and one Peer-Node SID (28002) to ASBR5. You can collect statistics about the traffic forwarded over the segment list containing the specified EPE SID. For example, statistics about the traffic forwarded over the outbound interface to which SID 18001 (from ASBR1 to ASBR3) points can be collected. You can also collect statistics about the traffic forwarded to a specified peer. For example, statistics about all traffic forwarded through EPE SIDs from ASBR1 to ASBR3 can be collected, including statistics about all traffic forwarded through BGP EPE SIDs 18001, 18002, and 28001.

BGP EPE is typically used to orchestrate SIDs at inter-AS egresses. Collecting traffic statistics using BGP EPE facilitates monitoring egress traffic in an AS.

Fault Association

On the network shown in Figure 1-2522, intra-AS SR-MPLS TE tunnels are deployed for AS 65001, and SBFD for SR-MPLS TE tunnel is configured. BGP EPE is configured among ASBR1, ASBR2, and ASBR3.

Two inter-AS SR-MPLS TE tunnels are deployed between CSG1 and ASBR3. The tunnels are orchestrated using intra-AS SIDs and inter-AS BGP SIDs. If a BGP EPE link between ASBRs fails, CSG1, the ingress of the SR-MPLS TE tunnel, cannot detect the failure, and therefore a traffic black hole may occur.

Currently, two methods are available for you to solve the preceding problem:

1. If a link between ASBR1 and ASBR3 fails, BGP EPE triggers SBFD for SR-MPLS TE tunnel in the local AS to go down. This enables the ingress of the SR-MPLS TE tunnel to rapidly detect the failure and switch traffic to another normal tunnel, such as tunnel 2.
2. If a link between ASBR1 and ASBR3 fails, ASBR1 pops the BGP EPE label from the received SR packet and searches the IP routing table based on the destination address of the packet. In this way, the packet may be forwarded to ASBR3 through the IP link ASBR1-ASBR2-ASBR3. This method applies when no backup inter-AS SR-MPLS TE tunnels exist on the network.

1. You can select either method as needed. Selecting both of the methods is not allowed.
2. The preceding methods are also supported if all the links corresponding to a BGP Peer-Set SID fail.

Figure 1-2522 BGP EPE fault association

BGP-LS

Inter-AS E2E SR-MPLS TE tunnels can be established by manually specifying explicit paths, or they can be orchestrated by a controller. In a controller-based orchestration scenario, intra- and inter-AS SIDs are reported to the controller using BGP-LS. Inter-AS links must support TE link attribute configuration and reporting to the controller. This enables the controller to compute primary and backup paths based on link attributes. BGP EPE discovers network topology information and allocates SID information. BGP-LS then packages this information into the Link network layer reachability information (NLRI) field and reports it to the controller. Figure 1-2523 and Figure 1-2524 show Link NLRI formats.

Figure 1-2523 Link NLRI format for Peer-Node and Peer-Adj SIDs advertised by BGP-LS

Figure 1-2524 Link NLRI format for Peer-Set SIDs advertised by BGP-LS

Table 1-1036 Link NLRI fields

Field	Description
NLRI	Network layer reachability information. It consists of the following parts: LocalDescriptor: local descriptor, which contains a local router ID, a local AS number, and a BGP-LS ID RemoteDescriptor: remote descriptor, which contains a peer router ID and a peer AS number LinkDescriptor: link descriptor, which contains addresses used by a BGP session
LinkAttribute	Link information. It is a part of the Link NLRI. Peer-Node SID: Peer-Node SID TLV Peer-Adj SID: Peer-Adj SID TLV Peer-Set SID: Peer-Set SID TLV Administrative Group: link management group attribute Max Link BW: maximum link bandwidth Max Reservable Link BW: maximum reservable link bandwidth Unreserved BW: remaining link bandwidth Shared Risk Link Group: SRLG

A Peer-Node SID TLV and a Peer-Adj SID TLV have the same format. Figure 1-2525 shows the format of the Peer-Node SID TLV and Peer-Adj SID TLV.

Figure 1-2525 Peer-Node SID TLV and Peer-Adj SID TLV format

Table 1-1037 Peer-Node SID TLV and Peer-Adj SID TLV fields

Field	Length	Description
Type	16 bits	TLV type.
Length	16 bits	Packet length.
Flags	8 bits	Flags field used in a Peer-Adj SID TLV. Figure 1-2526 shows the format of this field. Figure 1-2526 Flags field In this field: V: value flag. If this flag is set, an Adj-SID carries a label value. By default, the flag is set. L: local flag. If this flag is set, the value or index carried by the Adj-SID has local significance. By default, the flag is set.
Weight	8 bits	Weight of the Peer-Adj SID, used for load balancing purposes.
Reserved	16 bits	Reserved field.
SID/Label/Index (variable)	Variable length	This field contains either of the following information based on the V and L flags: A 3-octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V and L flags must be set. A 4-octet index defining the offset in the Segment Routing global block (SRGB).

SR LSP Creation

SR LSP creation involves the following operations:

• Devices report topology information to a controller (if the controller is used for LSP creation) and are allocated with labels.

• The devices compute paths.

SR LSPs are created primarily based on prefix labels. Specifically, the destination node runs an IGP to advertise a prefix SID. After receiving a packet carrying the SID, forwarders parse the packet to obtain the SID and compute label values based on their own SRGBs. Then, based on the IGP-collected topology information, each node runs the SPF algorithm to compute a label forwarding path, and delivers the computed next hop and OuterLabel information to the forwarding table to guide data packet forwarding.

Figure 1-2527 Prefix label-based LSP creation

Table 1-1038 describes the process of prefix label-based LSP creation on the network shown in Figure 1-2527.

SR LSP Creation Across IGP Areas

The following uses IS-IS as an example to describe how to create an SR LSP across IGP areas. IS-IS packets can be flooded only within an area. Therefore, to create an SR LSP across IGP areas on the network shown in Figure 1-2528, inter-area prefix SID advertisement is required.

Figure 1-2528 SR LSP creation across IGP areas

DeviceA and DeviceD are deployed in different areas, all devices run IS-IS, and SR is deployed. It is required that an SR LSP be established from DeviceA to DeviceD.

An SRGB is configured on DeviceD, and a prefix SID is configured on DeviceD's loopback interface. DeviceD generates and delivers forwarding entries, encapsulates the SRGB and prefix SID into an LSP (for example, IS-IS Router Capability TLV-242 that contains the SR-Capabilities sub-TLV), and floods the LSP across the network. After receiving the LSP, DeviceC parses the LSP to obtain the prefix SID, calculates and delivers forwarding entries, and leaks the prefix SID and prefix to the Level-2 area. Similarly, DeviceB parses the LSP to obtain the prefix SID, calculates and delivers forwarding entries, and leaks the prefix SID and prefix to the Level-1 area. DeviceA also parses the LSP to obtain the prefix SID, uses IS-IS topology information and the Dijkstra algorithm to compute an LSP, and generates an LSP forwarding entry.

Data Forwarding

Similar to MPLS, SR involves three types of label operations: push, swap, and pop.

• Push: When a packet enters an SR LSP, the ingress adds a label between the Layer 2 and IP headers of the packet or adds a new label on top of the existing label stack.

• Swap: When a packet is forwarded within the SR domain, the corresponding node uses the label allocated by the next hop to replace the top label according to the label forwarding table.

• Pop: When a packet leaves the SR domain, the corresponding node searches for the outbound interface according to the top label in the packet and then removes the top label.

Figure 1-2529 Prefix label-based data forwarding

Table 1-1039 describes the process of data forwarding on the network shown in Figure 1-2529.

PHP, MPLS QoS, and TTL

Because the outermost label in a packet is useless for the egress, penultimate hop popping (PHP) can be enabled to remove the label on the penultimate node, thereby relieving the burden on the egress. After receiving the packet, the egress directly forwards it over IP or based on the next label.

PHP is configured on the egress. On the network shown in Figure 1-2529, PHP is not enabled. Therefore, although node C is the penultimate hop of the involved SR tunnel, the packet sent from node C to node D still carries an SR label that is used to reach node D. However, if PHP is enabled, the packet sent from node C to node D does not carry any SR label.

Enabling PHP affects both the MPLS QoS and TTL functions on the egress. For details, see Table 1-1040.

SR-MPLS TE Advantages

SR-MPLS TE tunnels are capable of meeting the requirements for rapid development of software-defined networking (SDN), which Resource Reservation Protocol-TE (RSVP-TE) tunnels are unable to meet. Table 1-1059 describes the comparison between SR-MPLS TE and RSVP-TE.

Related Concepts

Label Stack

A label stack is an ordered set of labels used to identify a complete LSP. Each adjacency label in the label stack identifies a specific adjacency, and the entire label stack identifies all adjacencies along the LSP. During packet forwarding, a node searches for the corresponding adjacency according to each adjacency label in the label stack. The node then removes the label before forwarding the packet. After all the adjacency labels in the label stack are removed, the packet traverses the entire LSP and reaches the destination node of the involved SR-MPLS TE tunnel.

Stitching Label and Stitching Node

If a label stack exceeds the maximum depth supported by forwarders, the label stack is unable to carry the adjacency labels of the entire LSP. In this case, the controller needs to allocate multiple label stacks to the forwarders and a special label to an appropriate node to stitch these label stacks, thereby implementing segment-by-segment forwarding. The special label is called a stitching label, and the appropriate node is called a stitching node.

The controller allocates a stitching label to the stitching node and places the label at the bottom of the label stack. After a packet is forwarded to the stitching node, according to the association between the stitching label and label stack, the node replaces the stitching label with a new label stack to further guide forwarding.

Static Route

SR LSPs do not have tunnel interfaces. As such, you can configure a static route with a specified next hop, based on which the route recurses to an SR LSP.

The static routes of SR-MPLS TE tunnels work in the same way as common static routes. When configuring a static route, set the outbound interface of the route to an SR-MPLS TE tunnel interface so that traffic transmitted over the route can be steered into the SR-MPLS TE tunnel.

Tunnel Policy

By default, VPN traffic is forwarded over LDP LSPs, not SR LSPs or SR-MPLS TE tunnels. If forwarding VPN traffic over LDP LSPs does not meet VPN traffic requirements, a tunnel policy needs to be used to steer the VPN traffic into an SR LSP or SR-MPLS TE tunnel.

Currently, the supported tunnel policies are tunnel select-seq and tunnel binding. Select either of them as needed.

• Tunnel select-seq: This policy can change the type of tunnel selected for VPN traffic. An SR LSP or SR-MPLS TE tunnel is selected as a public tunnel for VPN traffic based on the prioritized tunnel types. If no LDP LSPs are available, SR LSPs are selected by default.

• Tunnel binding: This policy binds a specific destination address to an SR-MPLS TE tunnel for VPN traffic to guarantee QoS.

Auto Route

In auto route mode, an SR-MPLS TE tunnel participates in IGP route computation as a logical link, and the tunnel interface is used as an outbound interface of the involved route. Currently, the forwarding adjacency mode is supported, enabling a node to advertise an SR-MPLS TE tunnel to its neighboring nodes so that the SR-MPLS TE tunnel will be used in global route calculation and can be used by both the local node and other nodes.

PBR

PBR allows nodes to select routes based on user-defined policies, which improves traffic security and balances traffic. On an SR network, PBR enables IP packets that meet filter criteria to be forwarded over specific LSPs.

Similar to IP unicast PBR, SR-MPLS TE PBR is also implemented by defining a set of matching rules and behaviors through if-match clauses and apply clauses (the outbound interface is set to the involved SR-MPLS TE tunnel interface), respectively. If packets do not match PBR rules, they are forwarded in IP forwarding mode; if they match PBR rules, they are forwarded over specific tunnels.

SBFD Principles

Figure 1-2590 SBFD Principles

SBFD Return Packet Forwarding over a Tunnel

In an SBFD for SR-MPLS scenario, the packet from an SBFD initiator is forwarded to an SBFD reflector along an SR-MPLS LSP, and the return packet from the SBFD reflector is forwarded to the SBFD initiator along a multi-hop IP path or an SR-MPLS tunnel. If the return packet is forwarded along the shortest multi-hop IP path, multiple SR-MPLS LSPs may share the same SBFD return path. In this case, if the SBFD return path fails, all SBFD sessions go down, causing service interruptions. Services can recover only after the SBFD return path converges and SBFD goes up again.

If SBFD return packet forwarding over a tunnel is supported:

• The SBFD packet sent by the initiator carries the binding SID of the SR-MPLS TE tunnel on the reflector. If the SR-MPLS TE tunnel has primary and backup LSPs, the SBFD packet also carries the Primary/Backup LSP flag.
• When constructing a loopback packet, the reflector adds the binding SID carried in the SBFD packet sent by the initiator to the loopback SBFD Echo packet. In addition, depending on the Primary/Backup LSP flag carried in the SBFD packet, the reflector determines whether to steer the loopback SBFD Echo packet to the primary or backup LSP of the SR-MPLS TE tunnel. This ensures that the SBFD session status reflects the actual link status. In real-world deployment, make sure that the forward and reverse tunnels share the same LSP.

In an inter-AS SR-MPLS TE tunnel scenario, if SBFD return packets are forwarded over the IP route by default, the inter-AS IP route may be unreachable, causing SBFD to go down. In this case, you can configure the SBFD return packets to be forwarded over the SR-MPLS TE tunnel.

SBFD State Machine on the Initiator

The initiator's SBFD state machine has only two states (up and down) and therefore can only switch between these two states. Figure 1-2591 shows how the SBFD state machine works.

Figure 1-2591 SBFD state machine on the initiator

• Initial state: The initiator sets the initial state to Down in an SBFD packet to be sent to the reflector.
• Status migration: After receiving a looped packet carrying the Up state, the initiator sets the local status to Up. After the initiator receives a looped packet carrying the Admin Down state, the initiator sets the local status to Down. If the initiator does not receive a packet looped by the reflector before the timer expires, the initiator also sets the local status to Down.
• Status holding: When the initiator is in the Up state and receives a looped packet carrying the Up state, the initiator remains the local state of Up. When the initiator is in the Down state and receives a looped packet carrying the Admin Down state or receives no packet after the timer expires, the initiator remains the local state of Down.

Typical SBFD Applications

SBFD for SR-MPLS BE (SR LSP) and SBFD for SR-MPLS TE are typically used in SBFD for SR-MPLS scenarios.

SBFD for SR-MPLS BE

Figure 1-2592 shows a scenario where SBFD for SR-MPLS BE is deployed. Assume that the SRGB range for all the PEs and Ps in Figure 1-2592 is [16000–16100]. The SR-MPLS BE path is PE1->P4->P3->PE2.

With SBFD enabled, if a link or a P device on the primary path fails, PE1 rapidly detects the failure and switches traffic to another path, such as the VPN FRR protection path.

Figure 1-2592 SBFD for SR-MPLS BE networking

SBFD for SR-MPLS TE LSP

Figure 1-2593 shows a scenario where SBFD for SR-MPLS TE LSP is deployed. The primary LSP of the SR-MPLS TE tunnel from PE1 to PE2 is PE1->P4->P3->PE2, which corresponds to the label stack {9004, 9003, 9005}. The backup LSP is PE1->P1->P2->PE2.

Figure 1-2593 SBFD for SR-MPLS TE LSP networking

After SBFD is configured, PE1 rapidly detects a failure and switches traffic to a backup SR-MPLS TE LSP once a link or P on the primary LSP fails.

SBFD for SR-MPLS TE Tunnel

SR-MPLS TE Policy Model

Figure 1-2594 shows the SR-MPLS TE Policy model. One SR-MPLS TE Policy can contain multiple candidate paths with the preference attribute. The valid candidate path with the highest preference functions as the primary path of the SR-MPLS TE Policy, and the valid candidate path with the second highest preference functions as the hot-standby path.

A candidate path can contain multiple segment lists, each of which carries a Weight attribute. Each segment list is an explicit label stack that instructs a network device to forward packets. Multiple segment lists can work in load balancing mode.

Figure 1-2594 SR-MPLS TE Policy model

BGP SR-MPLS TE Policy Extension

+------------------+
|    NLRI Length   | 1 octet
+------------------+
|   Distinguisher  | 4 octets
+------------------+
|   Policy Color   | 4 octets
+------------------+
|     Endpoint     | 4 or 16 octets
+------------------+

The NLRI containing SR-MPLS TE Policy information is carried in a BGP Update message. The Update message must carry mandatory BGP attributes and can also carry any optional BGP attributes.

SR-MPLS TE Policy SAFI NLRI: <Distinguisher, Policy Color, Endpoint>
Attributes:
   Tunnel Encaps Attribute (23)
      Tunnel Type: SR-MPLS TE Policy
          Binding SID
          Preference
          ...
          Policy Name      
          Policy Candidate Path Name
          Segment List
              Weight
              Segment
              Segment
              ...
          ...

The Tunnel-Type TLV consists of the following sub-TLVs.

Preference Sub-TLV

Figure 1-2595 shows the format of the Preference Sub-TLV.

Figure 1-2595 Preference Sub-TLV

Policy Name Sub-TLV

The Policy Name Sub-TLV is used to attach a name to an SR-MPLS TE Policy. It is optional. Figure 1-2596 shows its format.

Figure 1-2596 Policy Name Sub-TLV

Table 1-1063 describes the fields in the Policy Name Sub-TLV.

Policy Candidate Path Name Sub-TLV

The Policy Candidate Path Name Sub-TLV is used to attach a name to an SR-MPLS TE Policy's candidate path. It is optional. Figure 1-2597 shows its format.

Figure 1-2597 Policy Candidate Path Name Sub-TLV

Table 1-1064 describes the fields in the Policy Candidate Path Name Sub-TLV.

Binding SID Sub-TLV

Figure 1-2598 shows the format of the Binding SID Sub-TLV.

Figure 1-2598 Binding SID Sub-TLV

Table 1-1065 Fields in the Binding SID Sub-TLV

Field	Length	Description
Type	8 bits	TLV type.
Length	8 bits	Packet length. It does not contain Type and Length fields. Available values are as follows: 2: No binding SID is contained. 6: An IPv4 binding SID is contained.
Flags	8 bits	Flags field. The encoding format is as follows: Figure 1-2599 Flags field S: S-Flag encoding the Specified-BSID-only behavior
Binding SID	32 bits	Binding SID of the SR-MPLS TE Policy. The following figure shows the format. Figure 1-2600 Binding SID The Label field indicates a label that occupies 20 bits. The other field occupies 12 bits and is not in use currently.

Segment List Sub-TLV

Figure 1-2601 shows the format of the Segment List Sub-TLV.

Figure 1-2601 Segment List Sub-TLV

Table 1-1066 Fields in the Segment List Sub-TLV

Field	Length	Description
Type	8 bits	TLV type.
Length	16 bits	Packet length.
sub-TLVs	Variable length	Sub-TLVs that contain the optional Weight Sub-TLV and zero or more Segment Sub-TLVs. Figure 1-2602 shows the format of the Weight Sub-TLV. Figure 1-2602 Weight Sub-TLV The meaning of each field is as follows: Type: TLV type of 8 bits Length: TLV length of 8 bits Flags: flags of 8 bits (not in use currently) Weight: weight value of a segment list. Figure 1-2603 shows the format of the Segment Sub-TLV. Figure 1-2603 Segment Sub-TLV in the form of MPLS label The meaning of each field is as follows: Type: TLV type of 8 bits Length: TLV length of 8 bits Flags: flags of 8 bits (not in use currently) Label: label value of 24 bits TC: traffic class of 3 bits S: bottom of stack of 1 bit TTL: TTL value of 8 bits

Extended Color Community

Figure 1-2604 shows the format of the Extended Color Community.

Figure 1-2604 Extended Color Community

MTU for SR-MPLS TE Policy

If the actual forwarding path of an SR-MPLS TE Policy involves different physical link types, the links may support different MTUs. If this is the case, the headend must implement MTU control properly to prevent packets from being fragmented or discarded during transmission. Currently, no IGP/BGP-oriented MTU transmission or negotiation mechanism is available. You can configure MTUs for SR-MPLS TE Policies as needed.

MBB and Delayed Deletion for SR-MPLS TE Policies

SR-MPLS TE Policies support make-before-break (MBB). With the MBB function, a forwarder can establish a new segment list before removing the original one during a segment list update. In the establishment process, traffic is still forwarded through the original segment list, preventing packet loss upon a segment list switchover.

SR-MPLS TE Policies also support delayed deletion. With a segment list deletion delay being configured for an SR-MPLS TE Policy, if the SR-MPLS TE Policy has a segment list with a higher preference, a segment list switchover may be performed. In this case, the original segment list that is up can still be used and is deleted only when the delay expires. This prevents traffic interruptions during the segment list switchover.

Delayed deletion takes effect only for up segment lists (including backup segment lists) in an SR-MPLS TE Policy. If seamless bidirectional forwarding detection (SBFD) detects a segment list failure or does not obtain the segment list status, the segment list is considered invalid and then immediately deleted without any delay.

Related Concepts

Background

Conventional loop-free alternate (LFA) requires that at least one neighbor be a loop-free next hop to a destination, and RLFA requires that at least one node be connected to the source and destination nodes without traversing the failure point. In contrast, Topology-Independent Loop-Free Alternate (TI-LFA) uses an explicit path to represent a backup path, achieving higher FRR reliability without imposing topology constraints.

Assume that packets need to be forwarded from DeviceA to DeviceF on the network shown in Figure 1-2618. If the extended P space and Q space do not intersect, RLFA requirements are not met. Consequently, no backup path (also called a remote LDP LSP) can be computed using RLFA. If the link between DeviceB and DeviceE fails, DeviceB forwards the packets to DeviceC. However, DeviceC is not a Q node and therefore cannot directly forward the packets to the destination address. In this situation, DeviceC must recompute a path. Because the cost of the link between DeviceC and DeviceD is 100, DeviceC considers that the optimal path to DeviceF passes through DeviceB. Consequently, DeviceC forwards the packets back to DeviceB, resulting in a loop and forwarding failure.

Figure 1-2618 RLFA networking

TI-LFA can be used to solve the preceding problem. On the network shown in Figure 1-2619, if the link between DeviceB and DeviceE fails, DeviceB adds new path information (node SID of DeviceC and adjacency SID for the C-D adjacency) to the packets based on TI-LFA FRR backup entries. This ensures that the packets can be forwarded along the backup path.

Figure 1-2619 TI-LFA networking

TI-LFA FRR Principles

On the network shown in Figure 1-2620, PE1 and PE3 are source and destination nodes, respectively, and link costs are configured. This example assumes that P1 fails.

TI-LFA provides both link and node protection.

• Link protection: protects traffic traversing a specific link.

• Node protection: protects traffic traversing a specific node.

  During protection path computation, node protection takes precedence over link protection. If a node protection path has been computed, no link protection path will be computed. However, if no node protection path has been computed, a link protection path will be computed.

Figure 1-2620 Typical TI-LFA networking

The following uses node protection as an example to describe how to implement TI-LFA. Assume that traffic travels along the PE1 -> P1 -> P3 -> PE3 path on the network shown in Figure 1-2620. To prevent traffic loss caused by P1 failures, TI-LFA computes the extended P space, Q space, post-convergence SPT to be used after P1 fails, backup outbound interface, and repair list, and then generates backup forwarding entries.

TI-LFA FRR Forwarding

After a TI-LFA backup path is computed, if the primary path fails, traffic is switched to the backup path, preventing packet loss.

Assume that a packet carrying the prefix SID 16100 of PE3 needs to be forwarded from PE1 to PE3 over the PE1 -> P1 -> P3 -> PE3 path shown in Figure 1-2621. When the primary next hop P1 fails, TI-LFA FRR is triggered, switching traffic to the backup path.

Figure 1-2621 Forwarding over a TI-LFA FRR backup path

The process of forwarding a packet over a TI-LFA FRR backup path is as follows:

1. PE1 encapsulates a label stack into the packet based on the repair list, using P2's node label 100 as the outer label and the P2-to-P4 adjacency label 9204 as the inner label.
2. After receiving the packet, PE2 searches its label forwarding table according to the outer label 100 and then forwards the packet to P2.
3. After receiving the packet, P2 searches its label forwarding table according to the outer label. Because P2 is the egress node, it removes the label 100 to expose the label 9204, which is an adjacency SID allocated by P2. As such, P2 finds the corresponding outbound interface according to the label 9204, removes the label, and then forwards the remaining packet content to P4.
4. After receiving the packet, P4 searches its label forwarding table according to the outer label 16100 and then forwards the packet to P3.
5. After receiving the packet, P3 searches its label forwarding table according to the outer label 16100 and then forwards the packet to PE3.
6. After receiving the packet, PE3 searches its label forwarding table according to the outer label and determines that the label 16100 is a local label. Therefore, PE3 removes the label. As 16100 is the bottommost label, PE3 performs further packet processing according to IP packet header information.

TI-LFA FRR Usage Scenarios

Advantages of TI-LFA FRR

Anycast SID

The same SID advertised by all routers in a group is called an anycast SID. On the network shown in Figure 1-2627, DeviceD and DeviceE both reside on the egress of an SR area, in which all devices can reach the non-SR area through either DeviceD or DeviceE. Therefore, the two devices can back up each other. In this situation, DeviceD and DeviceE can be configured in the same group and advertise the same prefix SID, the so called anycast SID.

The next hop of the anycast SID is DeviceD, which has the smallest IGP cost in the router group. DeviceD is called the optimal node that advertises the anycast SID, and the other device in the group is a backup node. If the primary next-hop link or direct neighbor of DeviceD fails, traffic can reach an anycast SID device through a protection path. The anycast SID device can be the source that has the same primary next hop or another anycast source. When VPN traffic is forwarded over an SR LSP, the same VPN label must be configured for anycast.

Figure 1-2627 Anycast SID

Anycast FRR

Anycast FRR allows multiple nodes to advertise the same prefix SID. Common FRR algorithms can only use the SPT to compute a backup next hop. This applies to scenarios where a route is advertised by a single node instead of multiple nodes.

When a route is advertised by multiple nodes, these nodes must be converted to a single node before a backup next hop is computed for a prefix SID. Anycast FRR constructs a virtual node to represent the multiple nodes that advertise the same route and uses the TI-LFA algorithm to compute a backup next hop to the virtual node. The anycast prefix SID inherits the backup next hop from the virtual node. This solution does not involve any modification of the algorithm for computing the backup next hop. It retains the loop-free trait so that no loop occurs between the computed backup next hop and the primary next hop of the pre-convergence peripheral node.

Figure 1-2628 IGP FRR networking in a scenario where multiple nodes advertise the same route

As shown in Figure 1-2628(a), the cost of the link from DeviceA to DeviceB is 5, and that of the link from DeviceA to DeviceC is 10. DeviceB and DeviceC advertise the same route 10.1.1.0/24. TI-LFA FRR is enabled on DeviceA. Because DeviceA does not meet TI-LFA requirements, it cannot compute a backup next hop for the route 10.1.1.0/24. To address this issue, TI-LFA FRR with multiple nodes advertising the same route can be used.

As shown in Figure 1-2628(b), this function is implemented as follows:

1. A virtual node is constructed between DeviceB and DeviceC and connected to both devices over links. The cost values of the links from DeviceB and DeviceC to the virtual node are both 0, whereas those of the links from the virtual node to DeviceB and DeviceC are both infinite.
2. The virtual node advertises a prefix of 10.1.1.0/24. This means that the route is advertised by a single node.
3. DeviceA uses the TI-LFA algorithm to compute a backup next hop to the virtual node. The route 10.1.1.0/24 inherits the computation result. On the network shown in Figure 1-2628(b), DeviceA computes two links to the virtual node. The primary link is from DeviceA to DeviceB, and the backup link is from DeviceA to DeviceC.

SR-MPLS Local Microloop Avoidance in a Traffic Switchover Scenario

In a traffic switchover scenario, a local microloop may be formed when a node adjacent to the failed node converges earlier than the other nodes on the network. On the network shown in Figure 1-2629, TI-LFA is deployed on all nodes. If node B fails, node A undergoes the following process to perform convergence for the route to node C:

1. Node A detects the failure and enters the TI-LFA FRR process, during which node A inserts the repair list <105, 16056> into the packet to direct the packet to the TI-LFA-computed P node (node E). So the packet is forwarded to the next-hop node D first and the SIDs encapsulated into the packet are <105, 16056, 103>.
2. After performing route convergence, node A searches for the route to node C and forwards the packet to the next-hop node D through the route. In this case, the packet does not carry any repair list and is directly forwarded based on the node SID 103.
3. If node D has not yet converged when receiving the packet, node A is considered as the next hop of the route from node D to node C. As a result, node D forwards the packet back to node A, which in turn causes a microloop between the two nodes.

Figure 1-2629 SR-MPLS local microloop in a traffic switchover scenario

According to the preceding convergence process, the microloop occurs when node A converges, quits the TI-LFA FRR process, and then implements normal forwarding before other nodes on the network converge. The issue is that node A converges earlier than the other nodes, so by postponing its convergence, the microloop can be avoided. As TI-LFA backup paths are loop-free, the packet can be forwarded along a TI-LFA backup path for a period of time. Node A can then wait for the other nodes to complete convergence before quitting the TI-LFA FRR process and performing convergence, thereby avoiding the microloop.

Figure 1-2630 SR-MPLS local microloop avoidance in a traffic switchover scenario

After microloop avoidance is deployed on the network shown in Figure 1-2630, the convergence process is as follows:

1. After node A detects the failure, it enters the TI-LFA FRR process, encapsulating the repair list <105, 16056> into the packet and forwarding the packet along the TI-LFA backup path, with node D as the next hop.
2. Node A starts the timer T1. During T1, node A does not respond to topology changes, the forwarding table remains unchanged, and the TI-LFA backup path continues to be used for packet forwarding. Other nodes on the network converge properly.
3. When T1 expires, other nodes on the network have already converged. Node A can now converge and quit the TI-LFA FRR process to forward the packet along a post-convergence path.

The preceding solution can protect only a PLR against microloops in a traffic switchover scenario. This is because only a PLR can enter the TI-LFA FRR process and forward packets along a TI-LFA backup path. In addition, this solution applies only to single point of failure scenarios. In a multiple points of failure scenario, the TI-LFA backup path may also be adversely affected and therefore cannot be used for packet forwarding.

SR-MPLS Local Microloop Avoidance in a Traffic Switchback Scenario

Besides traffic switchover scenarios, microloops may also occur in traffic switchback scenarios. The following uses the network shown in Figure 1-2631 as an example to describe how a microloop occurs in a traffic switchback scenario. The process is as follows:

1. Node A sends a packet to destination node F along the path A->B->C->E->F. If the B-C link fails, node A sends the packet to destination node F along the post-convergence path A->B->D->E->F.
2. After the B-C link recovers, a node (for example, node D) first converges.
3. When receiving the packet sent from node A, node B has not yet converged and therefore still forwards the packet to node D along the pre-recovery path, as shown in Figure 1-2631.
4. Because node D has already converged, it forwards the packet to node B along the post-recovery path, resulting in a microloop between the two nodes.

Traffic switchback does not involve the TI-LFA FRR process. Therefore, delayed convergence cannot be used for microloop avoidance in such scenarios.

Figure 1-2631 SR-MPLS local microloop in a traffic switchback scenario

According to the preceding process, a transient loop occurs when node D converges earlier than node B during recovery. Node D is unable to predict link up events on the network and so is unable to pre-compute any loop-free path for such events. To avoid loops that may occur during traffic switchback, node D needs to be able to converge to a loop-free path.

On the network shown in Figure 1-2632, after node D detects that the B-C link goes up, it computes the D->B->C->E->F path to destination node F.

Since the B-C link up event does not affect the path from node D to node B, it can be proved that the path is loop-free.

Topology changes triggered by a link up event affect only the post-convergence forwarding path that passes through the link. As such, if the post-convergence forwarding path from node D to node B does not pass through the B-C link, it is not affected by the B-C link up event. Similarly, topology changes triggered by a link down event affect only the pre-convergence forwarding path that passes through the link.

A loop-free path from node D to node F can be constructed without specifying the path from node D to node B. Similarly, because the path from node C to node F is not affected by the B-C link up event, it is definitely loop-free. In this scenario, only the path from node B to node C is affected. Given this, to compute the loop-free path from node D to node F, only a path from node B to node C needs to be specified. According to the preceding analysis, a loop-free path from node D to node F can be formed only by inserting the node SID of node B and the adjacency SID that instructs packet forwarding from node B to node C into the post-convergence path of node D.

Figure 1-2632 SR-MPLS local microloop avoidance in a traffic switchback scenario

After microloop avoidance is deployed, the convergence process is as follows:

1. After the B-C link recovers, a node (for example, node D) first converges.
2. Node D starts the timer T1. Before T1 expires, node D computes a microloop avoidance segment list <102, 16023> for the packet destined for node F.
3. When receiving the packet sent from node A, node B has not yet converged and therefore still forwards the packet to node D along the pre-recovery path.
4. Node D inserts the microloop avoidance segment list <102, 16023> into the packet and forwards the packet to node B.

   Although the packet is sent from node B to node D and then back to node B, no loop occurs because node D has inserted the segment list <102, 16023> into the packet.

5. According to the instructions bound to the node SID 102 and the adjacency SID 16023, node B forwards the packet to node C through the outbound interface specified by the adjacency SID and then removes the outer label 16023.
6. According to the node SID 106, node C forwards the packet to destination node F along the shortest path.

As previously described, node D inserts the microloop avoidance segment list <102, 16023> into the packet, avoiding loops.

When T1 of node D expires, other nodes on the network have already converged, allowing node A to forward the packet along the post-convergence path A->B->C->E->F.

SR-MPLS Remote Microloop Avoidance in a Traffic Switchover Scenario

In a traffic switchover scenario, a remote microloop may also occur between two nodes on a packet forwarding path if the node close to the failure point converges earlier than one farther from the point. The following uses the network shown in Figure 1-2633 as an example to describe how a remote microloop occurs in a traffic switchover scenario. The process is as follows:

1. After detecting a C-E link failure, node G first converges, whereas node B has not yet converged.
2. Nodes A and B forward the packet to node G along the path used before the failure occurs.
3. Because node G has already converged, it forwards the packet to node B according to the next hop of the corresponding route, resulting in a microloop between the two nodes.

Figure 1-2633 SR-MPLS remote microloop in a traffic switchover scenario

To minimize computation workload, a network node typically pre-computes a loop-free path only when a directly connected link or node fails. That is, no loop-free path can be pre-computed against any other potential failure on the network. Given this, the microloop can be avoided only by installing a loop-free path after node G converges.

As previously mentioned, topology changes triggered by a link down event affect only the pre-convergence forwarding path that passes through the link. Therefore, if the path from a node to the destination node does not pass through the failed link before convergence, it is absolutely not affected by the link failure. According to the topology shown in Figure 1-2633, the path from node G to node D is not affected by the C-E link failure. Therefore, this path does not need to be specified for computing a loop-free path from node G to node F. Similarly, the path from node E to node F is not affected by the C-E link failure, and therefore does not need to be specified, either. Because only the path from node D to node E is affected by the C-E link failure, you only need to specify the node SID 104 of node D and the adjacency SID 16045 identifying the path from node D to node E to determine the loop-free path, as shown in Figure 1-2634.

Figure 1-2634 SR-MPLS remote microloop avoidance in a traffic switchover scenario

After microloop avoidance is deployed, the convergence process is as follows:

1. After detecting a C-E link failure, node G first converges.
2. Node G starts the timer T1. Before T1 expires, node G computes a microloop avoidance segment list <104, 16045> for the packet destined for node F.
3. When receiving the packet sent from node A, node B has not yet converged and therefore still forwards the packet to node G along the path used before the failure occurs.
4. Node G inserts the microloop avoidance segment list <104, 16045> into the packet and forwards the packet to node B.

   Although the packet is sent from node B to node G and then back to node B, no loop occurs because node G has inserted the segment list <104, 16045> into the packet.

5. According to the instruction bound to the node SID 104, node B forwards the packet to node D.
6. According to the instruction bound to the adjacency SID 16045, node D forwards the packet to node E through the outbound interface specified by the SID and then removes the outer label 16045.
7. According to the node SID 106, node E forwards the packet to destination node F along the shortest path.

As previously described, node G inserts the microloop avoidance segment list <104, 16045> into the packet, avoiding loops.

When T1 of node G expires, other nodes on the network have already converged, allowing node A to forward the packet along the post-convergence path A->B->D->E->F.

SR-MPLS Remote Microloop Avoidance in a Traffic Switchback Scenario

The following uses the network shown in Figure 1-2633 as an example to describe how a remote microloop occurs in a traffic switchback scenario. The process is as follows:

1. After the C-E link recovers, node B first converges, whereas node G has not yet converged.
2. Node B forwards the packet to node G.
3. Because node G has not yet converged, it still forwards the packet to node B along the pre-recovery path, resulting in a microloop between the two nodes.

To avoid the microloop, start the timer T1 on node B. Then, before T1 expires, node B inserts the node SID of node G and the adjacency SID identifying the path between nodes G and C into the packet destined for node F to ensure that the packet can be forwarded to node C. In this way, node C can forward the packet to destination node F according to the node SID 106 along the shortest path.

Microloop Avoidance for Common IP Routes

The preceding microloop avoidance functions mainly apply to SR-MPLS routes carrying prefix SIDs. In addition to those routes, common IP routes that do not carry prefix SIDs may also encounter loops during unordered IS-IS convergence. To address this issue, microloop avoidance for common IP routes is introduced.

This function is implemented in the same way as microloop avoidance for SR-MPLS routes. Specifically, during IP forwarding, an SR-MPLS label stack is added to packets on convergence nodes, so that the packets are forwarded over a strict path within a period of time. After IS-IS convergence is completed, the packets are switched to the shortest path for forwarding, thereby effectively avoiding microloops.

Microloop Avoidance in a Scenario Where Multiple SR-MPLS Nodes Advertise the Same Route

The following uses Figure 1-2635 as an example to describe how microloop avoidance is implemented in a scenario where multiple SR-MPLS nodes advertise the same route.

Nodes C and F import the same SR-MPLS route carrying a prefix SID. After detecting a B-C link fault, a node (for example, node B) first completes convergence, whereas node A has not yet converged. Node A forwards a packet to node B along the path used before the fault occurs. Because node B has completed convergence, it forwards the packet to node A according to the next hop of the corresponding route, resulting in a microloop between the two nodes.

Figure 1-2635 Microloop avoidance in a scenario where multiple SR-MPLS nodes advertise the same route

To address the preceding issue, use the microloop avoidance function that applies to scenarios where multiple nodes advertise the same route. When the preferred destination node of the packet sent to 10.10.10.10/32 is changed from node C to node F but the convergence path from node B to node E does not change, the timer T1 can be started on node B. Before T1 expires, the node SID of node E and the adjacency SID between nodes E and F are added to the packet destined for node F to ensure that the packet can be forwarded to node F.

SR-MPLS BE Ping

On the network shown in Figure 1-2636, PE1, P1, P2, and PE2 all support SR-MPLS. An SR-MPLS BE tunnel is established between PE1 and PE2.

Figure 1-2636 SR-MPLS BE ping/tracert

SR-MPLS BE Tracert

SR-MPLS TE Ping

On the network shown in Figure 1-2637, PE1, P1, and P2 all support SR-MPLS. An SR-MPLS TE tunnel is established between PE1 and PE2. The devices assign adjacency labels as follows:

• PE1 assigns the adjacency label 9001 to the PE1-P1 adjacency.
• P1 assigns the adjacency label 9002 to the P1-P2 adjacency.
• P2 assigns the adjacency label 9005 to the P2-PE2 adjacency.

Figure 1-2637 SR-MPLS TE ping/tracert

SR-MPLS TE Tracert

MPLS in UDP Fundamentals

As shown in Figure 1-2638, the controller manages both the DCNs and DCI WAN. Each gateway (GW) sends a request to the controller to establish an end-to-end optimal path, and the controller then returns path computation results to the GW. SR-MPLS is deployed on the DCNs to simplify network deployment and management. In addition, traffic needs to traverse the MANs and DCI WAN so that DCN A and DCN B can communicate with each other. The DCI WAN is newly built and supports SR. However, the MANs are legacy networks and do not support SR. For this reason, SR-MPLS traffic cannot be forwarded on the MANs.

Figure 1-2638 Typical usage scenario of MPLS in UDP

MPLS in UDP is a DCN overlay technology that encapsulates MPLS or SR-MPLS packets into UDP packets, allowing the packets to traverse some networks that do not support MPLS or SR-MPLS. MPLS in UDP solves the problem of bearer protocol conversion between the DCN and WAN and unifies the tunnel protocols run on the DCN and WAN.

To prevent attacks initiated using invalid UDP packets, MPLS in UDP supports source IP address (the address of an MPLS-in-UDP tunnel ingress) verification. The packets are accepted only when the source IP address verification succeeds. Otherwise, the packets are discarded. In Figure 1-2638, source IP address verification can be enabled on DCI-PE1, which is the egress of an MPLS-in-UDP tunnel. After DCI-PE1 receives an MPLS-in-UDP packet, it verifies the source IP address of the packet according to the configured rule, improving transmission security.

If a device serves as the egress nodes of different MPLS-in-UDP tunnels, a valid source IP address list must be configured based on specified local IP addresses.

MPLS in UDP6 Fundamentals

As shown in Figure 1-2639, SR-MPLS is deployed on the cloud backbone network, which is connected to a DCN through an IPv6 fabric network.

MPLS in UDP6 is a DCN overlay technology that encapsulates MPLS or SR-MPLS packets into UDP6 packets, allowing the packets to traverse some networks that do not support MPLS or SR-MPLS.

Figure 1-2639 Typical usage scenario of MPLS in UDP6

MPLS in UDP/MPLS in UDP6 Packet Encapsulation Format

Figure 1-2640 shows the packet encapsulation format used in MPLS in UDP/MPLS in UDP6.

Figure 1-2640 MPLS in UDP/MPLS in UDP6 packet encapsulation format

Manual Configuration + PCEP Delegation

On the network shown in Figure 1-2643, labels are allocated on the device side and advertised through an IGP SR extension. Network topology and label information is collected through BGP-LS. An explicit path is manually configured on forwarders to establish an SR-MPLS TE tunnel. If the explicit path is configured in strict label stack mode, controller-based path computation is not required. If it is configured in other modes, the controller to which the associated tunnel can be delegated needs to perform path computation through PCEP and deliver information about the path label stack to the forwarders to guide data forwarding.

Figure 1-2643 Manual configuration + PCEP delegation

Controller-based Path Computation + PCEP Delegation

On the network shown in Figure 1-2644, labels are allocated on the device side and advertised through an IGP SR extension. Network topology and label information is collected through BGP-LS and then sent to the controller for SR tunnel path computation. After computing such a path, the controller delivers associated information through NETCONF. In this mode, the tunnel can be delegated to the controller, which then delivers information about the path label stack through PCEP to forwarders to guide data forwarding.

Figure 1-2644 Controller-based path computation

DCI services on the network are carried over an L3VPN in per-tenant per-VPN mode. Within each DC, tenants are isolated, and the DC gateway accesses the L3VPN through a VLAN sub-interface. Tenants' VPN services are carried over the primary and backup SR-MPLS TE paths.

Service Overview

Future networks will be 5G oriented. Transport networks need to be adjusted to meet 5G requirements for network simplification, low latency, and SDN and network functions virtualization (NFV) implementation. E2E SR-MPLS TE can carry VPN services through a complete inter-AS tunnel, which greatly reduces networking and O&M costs and meets carriers' requirement for unified O&M.

Networking Description

Figure 1-2645 illustrates the typical application of inter-AS E2E SR-MPLS TE on a transport network. The overall service model of the network is EVPN over SR-MPLS TE, with an E2E SR-MPLS TE tunnel as the transmission channel and EVPN as the data service model. Being oriented to 5G, this network features simplified solutions, protocols, and tunnels, as well as unified reliability solutions. With the help of a network controller, this network can quickly respond to upper-layer service requirements.

Figure 1-2645 Application of inter-AS E2E SR-MPLS TE on a transport network

Service Deployment