War in the SDN World: SR and Openflow

In the past two years, SDN technology has continued to blossom and bear fruit in the field of data center networks, becoming an important supporting technology for the next generation of networks. When it comes to SDN, OpenFlow must be mentioned, but SDN is not equal to OpenFlow. The relationship between SDN and OpenFlow is similar to the Internet not equal to the IP protocol, PSTN not equal to the No. 7 signaling, IMS not equal to SIP, and the WEB system not equal to the HTTP protocol. OpenFlow is the protocol for the controller in SDN to control the forwarding device. SDN builds a series of operating systems, software, compilers, peripheral frameworks and implementations around it, so Openflow is the foundation of all SDN network visions. However, this foundation is not solid. With the continuous application of SDN in data center networks, Openflow has also exposed some limitations of use and is not applicable to all situations, so SR technology has emerged.

[[234155]]

SR (Segment Routing) is a source routing mechanism used to optimize the network capabilities of IP MPLS. It can make the network more scalable and provide TE, FRR, MPLS VPN and other functions in a simpler way. SR was proposed by Cisco and has passed IETF standardization certification. Why does SR technology have growth opportunities?

This is because at the beginning of SDN, Openflow was used without exception to implement traffic forwarding and control application traffic in the network. However, Openflow does not abstract the network enough. The network status information in the core network equipment grows exponentially with the number of applications, and cannot be deployed on a large scale in the wide area network. In addition, the network controlled by Openflow often requires the controller to control multiple key devices in the path. As the number of transmission points in the network increases, each node in the network needs to maintain a large amount of path status information, which leads to difficulties in operation and maintenance, increased signaling pressure, poor scalability, and the application and network are still far apart. SR is lightweight and does not require a signaling protocol. It supports source routing and is flexible and can be integrated with ECMP. When SR is used as the transmission protocol, the SDN controller only needs to communicate with the Ingress PE (PE node of MPLS). The complete path information has been defined on the source router by carrying multiple labels. The network status information in the core network equipment is completely unrelated to the application services carried. With SR, data centers can easily select different paths for millions of applications on the source router while keeping the core devices without any application status.

This may sound a bit complicated. In fact, SR also uses a path label mechanism similar to MPLS, which optimizes the control plane. It uses IGP/BGP to distribute labels, and cancels the previous LDP/RSVP-TE. The data packet is "encoded" at the source router, and an ordered segment list is inserted in the header to indicate the forwarding path of the packet. SR technology simplifies the protocol, removes the complex LDP and RSVP-TE protocols, and extends the IGP protocol to replace the LDP and RSVP-TE protocols for label distribution. At the same time, the fast rerouting mechanism of the IGP protocol is used to support the loop-free backup calculation of Ti-LFA, which can achieve full topology link node protection. SR specifies the network path that the routing data packet must pass through through the label. Unlike MPLS, SR allocates a fixed, 32-bit label on each node. The label is fixed, not dynamic, similar to MPLS's L3VPN, which can make troubleshooting easier. The label and topology information are extended and propagated throughout the network through the routing protocol. SR does not use a label distribution protocol, thereby eliminating the obstacle that needs to be synchronized between the routing protocol and the label distribution protocol.

This inevitably reminds us of EVPN technology, which is an SDN application technology based on VXLAN. SR is not trying to take over EVPN's job, but it is indeed better than EVPN. First, VXLAN message overhead is too large, and SR with several layers of labels is 60~70 bytes smaller than VXLAN; second, the same MPLS forwarding plane is used, and there is no need to convert VXLAN to SR; third, SR and EVPN can coexist, SR+EVPN can implement EVPN's Type 2+Type5, L2/L3 IRB simultaneous forwarding, SR is a good supplement to EVPN, which is why many data centers are eager to introduce SR.

OpenFlow must load the forwarding table entries that enter the controller switch along the path from the source to the destination. SR is different from loose source routing, which only inserts the MPLS packet header at the source router. The SR program and MPLS label provide the source router path of the flow for each flow table, rather than allowing each flow to reach all switch entrances through the same path. In addition, the controller collects neighbor relationship information from all switches/routers and uses this information to make forwarding decisions. With SR, the controller can achieve flexible service scheduling and dynamic protection, enhancing the scalability of the controller. The SDN controller can centrally deploy end-to-end services to achieve protection path separation. When a fault occurs, the controller can use the dynamic protection of the IGP protocol to improve the self-healing ability of the network and minimize the impact of the fault on the service.

SR technology is a source routing technology, which is redesigned for SDN. It is easy to operate and has good scalability. Since it is a source routing technology, it has the attributes of source routing, requiring network devices to forward in the order in the forwarding table. If the forwarding next hop is not in the subnet directly connected to the network device, the data packet will be discarded, and the source host will receive a source routing failure ICMP message. The source routing technology checks the forwarding path of the network device. SR technology uses this feature to record the routing information along the way and complete the collection of network topology and status information. However, this technology has security risks and there are special source routing selection deception technologies. Some routers respond to source routing packets by using their specified routes and using their reverse routes to transmit reply data. This allows an intruder to obtain certain protected data through a special path in the name of a host. Therefore, when deploying SR technology in SDN, it is necessary to add security protection equipment to prevent the use of this mechanism to steal the forwarding path of confidential traffic, thereby achieving the purpose of attacking or stealing confidential data.

It seems that SR has a great trend of replacing OpenFlow, but from the current situation, SR is more in a theoretical research state, with occasional actual experiments or deployments, and is not common in real application networks. SR is further optimized based on MPLS technology, which is still a bit too complicated and only applicable to large data center deployments. It is not necessary at all in small data centers. Small data centers do not have so many applications, and no more calculations are required between the controller and OpenFlow. Simply sending some simple flow tables can handle the network, and it does not need to be so flexible. MPLS technology has also existed for many years and still exists as part of network technology. It is not suitable for all occasions, so SR technology also exists as an effective supplement to SDN. In the future, SR technology may become more and more important. It is not necessarily to replace OpenFlow. It takes time to test, and SR technology will not be all of SDN.