A brief comparison of two SR-TE implementation methods

1. Brief description of background technology

Regarding the several stages that IP forwarding technology has gone through, I have briefly sorted them out below based on my superficial understanding.

Initially, IP packets are forwarded according to the forwarding table constructed by the routing protocol. The routing protocol addresses the destination address, establishes the RIB table by learning the topology and link status of the entire network, and writes the next hop of the path with the smallest metric value to the destination route into the FIB table (load balancing for next hops with the same metric value). Relying on routing protocol forwarding, each hop router in the middle of the path will search the local FIB table for forwarding. The forwarding path of business traffic in the network can only be forwarded according to the optimal path (the path with the smallest metric value), and the path cannot be pre-programmed and accurately controlled.

Based on the original forwarding technology, MPLS technology, as a 2.5-layer technology, uses the LDP protocol to allocate labels to network segments, establish a label forwarding table, and replace three-layer routing forwarding with label forwarding, thereby improving forwarding efficiency.

In order to solve the problem that traditional IP router protocols can only forward packets along the optimal path (the path with the smallest metric value) and cannot accurately plan the forwarding path, RSVP-TE tunnel technology was developed based on MPLS. RSVP-TE did represent the development direction of advanced productivity for a certain period of time and has been widely used in certain scopes and scenarios. RSVP-TE can perform explicit path planning and implement bandwidth resource reservation, but the RSVP-TE control plane is complex, the configuration is also complex, and the state maintenance consumption performance does not support ECMP. In summary, RSVP-TE is too heavy and too complex to fully adapt to large-scale applications in large wide area networks.

SR-TE still retains and utilizes MPLS labels (SRv6 is not discussed in this article), extends the routing protocol to support the distribution of SR labels, eliminates the LDP protocol, and the Segment List in the packet header directly contains the path information. The path can be controlled at the head node, and there is no need for a lot of state maintenance like RSVP-TE. In summary, SR is more suitable for large-scale traffic engineering scenarios in large WANs, and is also more suitable for SDN's requirements for centralized control of network service traffic forwarding paths.

This article briefly discusses the comparison between Tunnel Interface and SR Policy, two implementation methods for establishing and controlling SR-TE paths, and examines the aspects in which the SR Policy method has greater advantages and improvements over the Tunnel Interface method.

2. Advantages and improvements of SR Policy compared with Tunnel Interface

SR-TE is divided into two implementation modes, SR Tunnel Interface and SR Policy, or two systems. Let me first state the conclusion. SR Policy is indeed a rising star. Cisco was the first to propose this concept and related technical standards. In a relatively short period of time, routers from mainstream manufacturers have all begun to support SR Policy.

Tunnel Interface is a tunnel interface, which is a virtual connection between two network elements. Therefore, SR-TE of Tunnel Interface is similar to traditional LSP technology, which imports service traffic in the form of virtual interface. The path of Tunnel Interface can be issued and changed from CLI or PCEP/Netconf of SDN southbound interface, and finally mapped to an actual tunnel and tunnel path configuration on the head node router.

SR Policy defines a network policy, but this policy includes the carrying requirements and forwarding path of a service flow. SR Policy is determined by the (head-end, color, end-point) triple. The source of SR Policy can be CLI or the southbound interface BGP/PCEP/Netconf of SDN.

Currently, BGP for SR Policy is a SDN southbound interface that is developing rapidly and widely used in the industry. For related standards, please refer to draft-ietf-idr-segment-routing-te-policy-08 (Advertising Segment Routing Policies in BGP). A detailed introduction to SR Policy is not the focus of this article. This article will simply summarize the advantages and improvements of SR Policy compared to Tunnel Interface.

2.1.SR Policy is more flexible in diverting business traffic

SR-TE in Tunnel Interface mode is essentially a tunnel interface at the network level. The import and diversion of related service traffic needs to be implemented with the help of traditional PBR. In MPLS-VPN scenarios, VPN traffic can be directly overlaid on SR-TE in Tunnel Interface mode. In this case, the tunnel of Tunnel Interface replaces the LDP forwarding tunnel.

BGP for SR Policy can realize automatic traffic diversion based on service traffic. As shown in Figure 1, the End-point sets the color to Red based on the Community value of BGP route 1.1.1.0/24, and the Head-end learns the NLRI with the set color value through the BGP protocol. The SR Policy is issued to the head-end device. The BSID of this SR Policy is 4001. For the traffic with the color Red, the preferred Candidate path is set to SID-LIST<16002,16004>. According to this SR Policy, the head-end device forwards the traffic related to the color Red to 1.1.1.0/24 according to the BGP route and complies with the SR Policy with BSID 4001, and pushes the corresponding SID label stack into the data header. The intermediate router completes the forwarding according to the SID label stack path pushed by the head-end. Therefore, the SR-TE diversion of the SR Policy is completed automatically, and PBR does not need to be configured.

2.2. SR Policy is more flexible to achieve differentiated services

Using QOS policies for differentiated services and guarantees is a traditional method, but it is limited by the 8 levels of DSCP. In addition, differentiated services are implemented through the QOS guarantee of hop-by-hop forwarding devices. It is impossible to bind business traffic and bearer paths and implement differentiated services by optimizing paths.

2.2.1.SR Policy sets the color value to map the service carrying requirements to the tunnel capabilities

In the Tunnel Interface scenario, differentiated services are implemented. Different Tunnel Interface tunnels (low-latency tunnels, high-security tunnels, etc.) are established based on different service traffic carrying requirements between two points, and service traffic is introduced into the corresponding SR-TE through PBR at the head node. When service traffic needs to be optimized, it can be achieved by changing the tunnel path or the tunnel that carries the traffic.

In SR Policy, different bearer requirements are represented by color. Color does not represent a specific tunnel, but a collection of tunnels with a certain bearer capacity. For example, RED represents a low-latency service requirement, and Green represents a service requirement with low latency but high bandwidth guarantee. Color values ​​are not limited to the 8 levels of DSCP, and more guarantee levels can be achieved. To some extent, color becomes an intermediary between service bearer requirements and actual tunnels. Service traffic does not directly define the mapping relationship with specific tunnels, but only expresses its own bearer requirements and associates them with the SR Policy of the corresponding color.

In the differentiated service guarantee scenario of SR Policy, the destination address represents the service traffic, and the same service carrying requirement is marked with the same color. SR Policy binds the service carrying requirement and the tunnel guarantee level through the destination address + color. When the service carrying requirement changes, the color value in the SR Policy can be directly changed. In other words, because an SR Policy defines both the color and the actual segment list path, the SR Policy is consistent in implementing differentiated services and traffic path optimization because the color value is defined.

2.2.2.SR Policy can realize differentiated services based on VPN internal service routing

In MPLS-VPN transmission scenarios, it is difficult to distinguish different service routes within the VPN and transmit them to different SR-TE tunnels.

In the MPLS-VPN bearer scenario, SR Policy can color different routes in the VPN with different colors, thereby meeting the differentiated bearer requirements for different service flows in the same VPN. In other words, the characteristics of the SR Policy technology itself determine that SR Policy does not distinguish between bare IP scenarios and MPLS-VPN scenarios, and can carry out differentiated bearer based on different service routes, regardless of whether the route is a public network route or a private network route in the VPN.

With the advancement of 5G commercialization, the corresponding network services will inevitably develop rapidly. Faced with more complex business carrying requirements, SR Policy with more refined carrying capabilities will undoubtedly be more useful.

2.3.SR Policy supports ECMP/WECMP

2.3.1.SR Policy is more flexible and supports primary and backup paths

Tunnel Interface can realize primary and backup paths. The primary path carries traffic, and the backup path takes over the traffic when the primary path fails. The primary path and the backup path are established and maintained separately.

As shown in 2, an SR Policy can have multiple candidate paths. Different candidate paths have different Perference values ​​to represent different priorities. The primary and backup paths of the SR Policy are implemented through different candidate paths. The high-priority path is the primary path, and the low-priority path is the backup path. Therefore, the SR Policy can not only implement one primary and one backup, but also one primary and multiple backups. The control of all primary and backup paths of the SR Policy is implemented in one policy, which simplifies management and improves efficiency.

2.3.2.SR Policy supports ECMP/WECMP

The Tunnel Interface mode does not support ECMP/WECMP, which greatly limits the scalability of the Tunnel Interface.

The definition of SR Policy is very flexible. As shown in Figure 2, there can be multiple Segment List paths in a Candidate Path. Each Segment List has its own weight value. If the Weight values ​​are the same, ECMP forwarding is performed between different Segment List paths according to load balancing; if the Weight values ​​are different, WECMP forwarding is performed between different Segment List paths according to load balancing based on weights. The implementation of ECMP and WECMP capabilities has greatly improved the carrying efficiency and carrying capacity.

2.4. SR Policy is more flexible and can implement path programming, which is more in line with the development of SDN

Tunnel Interface implementation method: The southbound interface of network SDN is mainly based on PCEP. Whether it is PCC-initiated to establish a Tunnel Interface tunnel and then hosted to the controller, or the controller PCE-initiated to establish a tunnel and directly send the path, after the forwarding path is sent, the final implementation on the device must be converted into the actual tunnel and tunnel path configuration.

Regarding the implementation of SR Policy, the southbound interface of SDN can be PCEP or BGP for SR Policy. The interface is more flexible for the SDN controller. The tunnel path is directly carried in the SR Policy. After being sent to the device, the head-end device directly encapsulates the data packet according to the Segment List in the Policy and pushes the labels in the corresponding order. It does not need to be converted into the actual tunnel and tunnel path configuration on the device. It is also lighter and easier to implement for the device.

In the SDN control scenario of SR Policy, the controller calculates the corresponding bearer path according to different service bearer requirements, and uses end-point+Color as the key value to bind a BSID (Binding SID), and then sends it to the head-end router. The head-end router automatically directs the service traffic to the corresponding Candidate Path of the SR Policy corresponding to the BSID and then forwards it. The BSID of an SR Policy is the BSID of the preferred Candidate Path.

In short, SR Policy can achieve complete separation of the control plane and the SR forwarding plane, making it easier to implement service forwarding path programming and centralized controller control.

3. Summary

Tunnel Interface is essentially a tunnel technology, while SR Policy completely surpasses tunnel technology. It encapsulates all network functions in SR Policy, such as forwarding path, load sharing, and bearer level, and can be abstracted into a BSID for APP or controller to call.

About the author: Xiong Xuetao is the network operation and maintenance director of Beijing 21Vianet Broadband Data Center Co., Ltd. He has nearly 20 years of experience working in operators and Internet companies. He has extensive project experience in the field of ultra-large-scale data center networking and operator-level wide area networks. He graduated from the School of Communication Engineering of Xidian University and holds a master's degree in engineering from South China University of Technology.