Do you know the technical implementation of SDN？

FancyWang 0208 2021

Technical realization of SDN

Although different organizations and vendors have proposed different architectures and solutions for SDN, they all adhere to the core idea of SDN control and forwarding separation, and centralized control. Generally speaking, there are two main implementation schemes for SDN: one emphasizes network-centricity, and mainly uses the standard protocol OpenFlow to achieve control of network equipment,

which can be regarded as the control of traditional network equipment (switches, routers, etc.) Transformation and upgrade; the other is to use the host as the center and network overlay technology to realize network virtualization, and the application field is mainly the data center.

Network-centric realization

The core technology of Network Dominant SDN is OpenFlow technology. OpenFlow technology was first proposed by Stanford University in 2008. It is a communication protocol used to provide a data forwarding layer for network devices such as switches and routers ( Data Forwarding Plane) access control. OpenFlow aims to solve various bottlenecks encountered by the current architecture in the face of new network services and services based on the existing TCP/IP technical conditions and innovative network interconnection concepts. In 2009, the authoritative global technology business magazine "MIT Technology Review" rated the SDN technology based on OpenFlow as one of the top ten breakthrough technologies that year.

OpenFlow technology separates the control plane (Control Plane) and the data plane (Data Plane) of network devices to achieve flexible control of network traffic and provide a good platform for core network and application innovation. Its core idea is very simple. It transforms the data packet forwarding process that was originally completely controlled by the switch/router into an independent process completed by the control server (Controller) and the OpenFlow switch (OpenFlow Switch).

In other words, network equipment using OpenFlow technology can be deployed in a distributed manner and centrally controlled, so that the network has a software-definable form, which can be customized, quickly established, and new features and functions can be realized. ONF’s founding board member and Professor Scott Shenker of the University of California, Berkeley, commented very pertinently: “OpenFlow does not allow you to do things that you could not do on the Internet before, but it provides a programmable interface that allows you to make programming decisions.

What needs to happen on the network, how to route data packets, how to achieve load balancing, and how to perform access control. This versatility will indeed promote development."

Principles of OpenFlow Technology

The paper "OpenFlow: Enabling Innovation in Campus Networks" published by Professor Nick McKeown of Stanford University and others at the ACM SIGCOMM 2008 conference is the first choice for understanding the principles of OpenFlow technology. The OpenFlow switch specification, continuously revised and released by ONF, defines the basic components and functional requirements of the OpenFlow switch as a forwarding device, as well as the communication protocol used by the OpenFlow controller to interact with the switch. Therefore, we will combine this paper with the OpenFlow switch specification to elaborate on its technical principles.

The original intention of the OpenFlow paper is mainly to redesign the experimental environment of the campus Internet. On a purely experimental network, it is always difficult to have enough actual users or sufficiently complex network topology to test the performance and functions of the new protocol. One of the methods is to embed the experimental network running the new architecture and new protocol into the actual operating network , Use the real network environment to verify the feasibility and existing problems of the new protocol. Therefore, researchers have proposed an architecture in which the control layer and the forwarding layer are separated from each other in OpenFlow, which abstracts the control logic from the network equipment. Researchers can program it to implement new network protocols and topology without changing the network equipment itself.

The basic architecture of OpenFlow technology mainly includes OpenFlow switches, controllers, and communication channels for interaction between switches and controllers, as shown in Figure 4-9. The OpenFlow switch forwards the data packet according to the flow table, corresponding to the data forwarding layer; the controller is responsible for the generation and deletion of flow forwarding rules, corresponding to the control layer. The controller controls a single (or multiple) flow tables in the switch through the OpenFlow protocol interface, thereby achieving logically centralized control of the entire network.

1) The OpenFlow port is a network interface for transferring data packets between the OpenFlow processing process and the rest of the network. OpenFlow switches are logically connected to each other through OpenFlow ports. The OpenFlow port group may not be exactly the same as the network port provided in the switch hardware, because some hardware network interfaces may be disabled by OpenFlow, and the OpenFlow switch can also define additional ports.

OpenFlow data packets are received from the ingress port, processed by the OpenFlow pipeline, and then forwarded to an egress port. The ingress port is an attribute of the data packet. It runs through the entire OpenFlow pipeline and represents the port of the OpenFlow switch from which the data packet is received. The ingress port is used when matching packets. The OpenFlow pipeline can determine how data packets are sent to the outgoing port through outgoing actions, and it defines how the data packets are sent back to the network.

OpenFlow switches must support three types of OpenFlow ports: physical ports, logical ports, and reserved ports.

● Physical port, that is, the port that is physically visible on the device.

●Logical ports, logical ports abstracted by switches based on physical ports, such as logical ports implemented for functions such as tunnel or aggregation.

●Reserved ports. OpenFlow currently defines a total of 8 ports, ALL, CONTROLLER, TABLE, IN_PORT, ANY, LOCAL, NORMAL, and FLOOD, of which the latter 3 are non-essential ports, which are only used in the hybrid OpenFlow Switch (OpenFlow-hybrid Switch, which supports both The traditional network protocol stack and the Switch device of the OpenFlow protocol exist in the OpenFlow-only Switch.

2) As shown in Figure 4-10, the OpenFlow switch locally has one or more flow tables (Flow Table) and a group table (Group Table) to perform packet search and forwarding. Each flow table contains multiple flow entries, and each flow entry contains:

Figure 4-9 Basic architecture of OpenFlow Switch

Figure 4-10 OpenFlow switch

●Match field Match the data packet. Including Ingress Port, packet header, and optional metadata specified by the previous table.

●Priority The matching priority order of flow entries.

●Counter Update the count of matching packets.

●Instructions modify the action set or pipeline processing.

●Timeout The maximum time count or flow timeout time.

●Cookie opaque data value selected by the controller. It can be used by the controller to filter flow statistics, flow changes, or flow deletions. This value is not used when processing data packets.

After receiving the data packet, the switch starts to perform a lookup in the first flow table, and based on pipeline processing, it will also look up in other flow tables. The data matching field is extracted from the data packet.

The data matching field used to perform the search operation depends on the type of the data packet, and usually includes the header information of the data packet, such as the Ethernet source address or the IP destination address. In addition to the header data, it is also possible to perform matching operations on the ingress port and metadata. Metadata can be used to transfer information between flow tables in the switch. The match field indicates the current state of the data packet. If the header of the data packet is changed using Apply-Actions in the previous flow table, these changes will also be reflected in the match field.

Asterfusion Data Technologies is committed to providing enterprise users with services including technical consultation and one-stop deployment, and helping enterprise users enjoy the technological dividends brought by the Internet, open source, and open networks.