A Segment Routing (SR) label switched path (LSP) is a label forwarding path that is established using SR and guides data packet forwarding through a prefix or node SID. Segment Routing-MPLS best effort (SR-MPLS BE) refers to the mode in which an IGP runs the shortest path first (SPF) algorithm to compute an optimal SR LSP.
The establishment and data forwarding of SR LSPs are similar with those of LDP LSPs. SR LSPs have no tunnel interfaces.
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.
Table 1 describes the process of prefix label-based LSP creation on the network shown in Figure 1.
Step |
Device |
Operation |
---|---|---|
1 |
D |
An SRGB is configured on device D and a prefix SID is configured on the loopback interface of device D for forwarding entry generation and delivery. Device D then encapsulates the SRGB and prefix SID into a Link State packet (LSP), for example, IS-IS Router Capability TLV-242 that contains the SR-Capabilities sub-TLV, and floods the LSP across the network through an IGP. After receiving the LSP, other devices on the network parse the LSP to obtain the prefix SID advertised by device D, and calculate label values based on their own SRGBs as well as OuterLabel values based on the SRGBs advertised by the next hops. They then, based on IGP-collected topology information, calculate label forwarding paths and generate forwarding entries accordingly. |
2 |
C |
Device C parses the LSP to obtain the prefix SID advertised by device D and calculates a label value based on its local SRGB [36000–65535] through the following formula: Label = Start value of the SRGB + Prefix SID value. Here, the start value of the SRGB is 36000, and the prefix SID value is 100. Therefore, the label value is 36100 (36000 + 100). Based on IS-IS topology information, device C calculates the OuterLabel value through the following formula: OuterLabel = Start value of the SRGB advertised by the next hop + Prefix SID value. Here, the next hop is device D, which advertises the SRGB [16000–65535]. Therefore, the OuterLabel value is 16100 (16000 + 100). |
3 |
B |
The calculation process on device B is similar to that on device C. In this example, the label value is 26100 (26000 + 100), and the OuterLabel value is 36100 (36000 + 100). |
4 |
A |
The calculation process on device A is also similar to that on device C. In this example, the label value is 20100 (20000 + 100), and the OuterLabel value is 26100 (26000 + 100). |
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 2, inter-area prefix SID advertisement is required.
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.
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.
Table 2 describes the process of data forwarding on the network shown in Figure 3.
Step |
Device |
Operation |
---|---|---|
1 |
A |
After receiving a data packet, node A adds label 26100 to the packet and then forwards the packet. |
2 |
B |
After receiving the labeled packet, node B swaps label 26100 with label 36100 and then forwards the packet. |
3 |
C |
After receiving the labeled packet, node C swaps label 36100 with label 16100 and then forwards the packet. |
4 |
D |
Node D removes label 16100 and then forwards the packet along the corresponding route. |
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 3, 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 3.
Label Type |
Description |
MPLS EXP (QoS) on the Egress |
MPLS TTL on the Egress |
Remarks |
---|---|---|---|---|
Explicit-null label |
PHP is not supported, and the egress assigns an explicit-null label to the penultimate hop. In an IPv4 scenario, the explicit-null label value is 0. |
The MPLS EXP field is reserved, so that QoS is supported. |
MPLS TTL processing is normal. |
Label resources on the egress are saved. If E2E services carry QoS attributes to be carried in the EXP field in a label, an explicit-null label can be used. |
Implicit-null label |
PHP is supported, and the egress assigns an implicit-null label to the penultimate hop. The implicit-null label value is 3. If an implicit-null label is assigned to a node, the node pops the label in the received packet, instead of replacing the top label with this label. After receiving the packet, the egress directly forwards it over IP or based on the next label. |
There is no MPLS EXP field in the packet received by the egress, so QoS is not supported. |
There is no MPLS TTL field in the packet received by the egress, so copying the MPLS TTL value to the IP TTL field is not supported. |
The forwarding burden on the egress is reduced, and forwarding efficiency is improved. |
Non-null label |
PHP is not supported, and the egress assigns a common label to the penultimate hop. |
The MPLS EXP field is reserved, so that QoS is supported. |
MPLS TTL processing is normal. |
Using a non-null label consumes a large number of resources on the egress and is therefore not recommended. This type of label can be used to differentiate services by label on the egress. |