SR-MPLS TE Tunnel Creation
SR-MPLS TE Tunnel
Segment Routing MPLS traffic engineering (SR-MPLS TE) tunnels are created using the SR protocol based on TE constraints.
In Figure 1, a primary LSP is established along the path PE1->P1->P2->PE2, and a backup path is established along the path PE1->P3->P4->PE2. The two LSPs correspond to SR-MPLS TE tunnels with the same ID. Each LSP originates from the ingress, passes through transit nodes, and is terminated at the egress.
SR-MPLS TE tunnel creation involves tunnel configuration and establishment. Before SR-MPLS TE tunnel creation, IS-IS/OSPF neighbor relationships must be established between forwarders to implement network-layer connectivity, allocate labels, and collect network topology information. In addition, the forwarders need to send label and network topology information to a controller for path computation. If no controller is available, constrained shortest path first (CSPF) can be enabled on the ingress of the SR-MPLS TE tunnel to allow forwarders to compute paths using CSPF.
SR-MPLS TE Tunnel Configuration
SR-MPLS TE tunnel attributes must be configured before tunnel establishment. An SR-MPLS TE tunnel can be configured on a controller or a forwarder.
An SR-MPLS TE tunnel is configured on a controller.
The controller runs NETCONF to deliver tunnel attributes to a forwarder (as shown in Figure 2). The forwarder runs PCEP to delegate the tunnel to the controller for management.
An SR-MPLS TE tunnel is manually configured on a forwarder.
The forwarder delegates LSPs to the controller for management.
SR-MPLS TE Tunnel Establishment
If a service (for example, VPN) needs to be bound to an SR-MPLS TE tunnel, the tunnel can be established through the following process, as shown in Figure 2.
The controller uses SR-MPLS TE tunnel constraints and Path Computation Element (PCE) to compute a path that is similar to a common TE path. Based on the topology and adjacency labels, the controller combines the adjacency labels of the entire path into a label stack (that is, the path computation result).
If the depth of a label stack exceeds the maximum depth supported by forwarders, the label stack is unable to carry all the adjacency labels of the path. In this case, the controller needs to allocate multiple label stacks to carry the labels.
In Figure 2, the controller computes the PE1->P3->P1->P2->P4->PE2 path for an SR-MPLS TE tunnel. The path involves two label stacks <1003, 1006, 100> and <1005, 1009, 1010>, where label 100 is a stitching label and the others are all adjacency labels.
The controller delivers tunnel configurations and label stacks to forwarders through NETCONF and PCEP, respectively.
In Figure 2, the controller delivers label stacks as follows:- The controller delivers the label stack <1005, 1009, 1010> to the stitching node P1 and allocates the stitching label 100 to associate with the label stack.
- The controller delivers the label stack <1003, 1006, 100> to the ingress PE1, using 100 as the bottom label.
- The forwarders establish an SR-MPLS TE tunnel with a specific LSP based on the tunnel configurations and label stacks delivered by the controller.
An SR-MPLS TE tunnel does not support MTU negotiation. Therefore, the MTUs configured on nodes along the SR-MPLS TE tunnel must be the same. For a manually configured SR-MPLS TE tunnel, you can use the mtu command to manually configure the MTU under the tunnel. If you do not manually configure the MTU, the default MTU value is 1500 bytes. On the manual SR-MPLS TE tunnel, the smallest value in the following values takes effect: MTU of the tunnel, MTU of the outbound interface, and MPLS MTU of the outbound interface.