Source: | Hardware and Software IntegrationAuthor: | ChaobowxEditor’s Note: Although the upper-level network protocols can be dazzling, the underlying hardware and software processing can actually be simply divided into three parts:

1. Hardware and Software Interface: Completes the interaction of network data packets between CPU software and NIC hardware, such as EFA.

2. Network Packet Processing: Completes the processing of network protocols and pure hardware network packet processing, such as the Barefoot PISA processing engine; network packet processing may occur either before or after the hardware and software interface.

3. High-Performance Networking, primarily responsible for the transmission of network data packets within the network. For example, RDMA/SRD, etc.

Among these, network packet processing is the core part. Initially, network packet processing was entirely ASIC-based, which was non-programmable. With the rise of SDN, it gradually achieved programmable control plane via Openflow, and data plane programmability through P4 and the DSA architecture supporting P4 processing engines.Software Defined Networking: From Openflow to P4-DSASDN extends from the control plane to the data plane:

• The most important protocol for the control plane is Openflow, and OVS is an open-source virtual switch that supports the Openflow protocol;

• The data plane is programmed using the P4 language, enabling user-defined network protocol processing.

1. Concept of Software Defined Networking

The traditional network architecture can no longer meet the needs of enterprises, operators, and end-users. The SDN (Software Defined Network) proposed by the ONF (Open Networking Foundation) will change the current architecture. By adopting the SDN architecture, enterprises and operators gain unprecedented programmability, automation, and network control capabilities, enabling them to build a highly scalable and flexible network to adapt to their constantly changing business needs.

SDN is a new network architecture that separates the control plane from the data plane and makes it directly programmable. This change in the control plane, from previously tightly coupled specific network devices to now being closer to computing devices, allows the underlying network infrastructure to become a general abstraction for upper-level applications and network services, making the network a logical or virtual entity.

As shown in Figure 1, the logical hierarchy of the SDN architecture is depicted. The control part of the network is logically centralized in the software-implemented SDN controller, which maintains a global view of the network. The entire network resembles a single logical switch containing applications and policy mechanisms. Utilizing SDN, enterprises and operators can control the entire network from a logical point, free from vendor restrictions, thus simplifying network design and operations. The SDN architecture also allows network devices to be as simple and general as possible, no longer needing to understand, process, and implement a multitude of network protocols, but rather just needing to receive instructions dynamically from the SDN controller.

Figure 1: SDN Architecture

Network operations engineers can configure this simple network abstraction just like software programming, rather than relying on manual coding to configure a large number of distributed network devices. Meanwhile, due to the centralized intelligent management and control of the SDN controller, network operations engineers can change network behavior in real-time and deploy new network applications and services in a short period. By centralizing the network state at the control layer, network operations can rely on dynamic automated software programs to flexibly configure, manage, deploy security policies, and optimize network resources. They can write these programs directly without waiting for device vendors to implement them in a closed software environment.

In addition to abstracting the network, SDN supports a series of APIs used to implement general network services, including routing, multicasting, security, access control, bandwidth management, energy utilization, any form of policy management, and customized services for business objectives. For example, SDN can implement unified control policies between wireless and wired networks in campus networks. Moreover, SDN allows for the entire network to be managed through intelligent services and adaptive systems. The ONF is researching open APIs that can manage devices from multiple vendors, opening a door to on-demand allocation of network resources, service adaptive systems, true network virtualization, and secure cloud services. The open API between the SDN control layer and application layer allows commercial applications to run on top of the network abstraction, fully utilizing the services and capabilities of the network without needing to concern themselves with the details of network implementation. In summary, SDN allows networks to be “application agnostic” and “application customizable”, while applications do not need to be “network aware” or “network capacity aware”. Only with complete logical separation between the two can computing, storage, and network resources be truly optimized.

2. Programmability of the Network Control Plane: Openflow

OpenFlow is the first standardized communication interface defined between the control plane and data plane in the SDN architecture, allowing direct access to and manipulation of the data plane of network devices (such as switches and routers, whether physical or virtual). The open interface of the data plane makes current network devices configurable in parameters. OpenFlow is akin to the instruction set of a CPU, with the protocol specifying the basic primitives for programming the data plane of network devices.

The OpenFlow protocol must be implemented on both sides of the interface between network devices and SDN control software, using the concept of Flow to identify network traffic based on predefined rule matches. The SDN control software can statically or dynamically program these rules. IT management can define how traffic traverses network devices based on parameters such as usage patterns, applications, and cloud resources. Since OpenFlow allows network programming on a per-flow basis, the OpenFlow-based SDN architecture can provide finer-grained network control, enabling the network to respond in real-time to application-level, user-level, and session-level changing demands.

The OpenFlow protocol is a key driver of SDN and is the only SDN standard protocol that allows direct manipulation of device data planes. Initially applied in Ethernet, OpenFlow-based switching can expand to more application instances. OpenFlow-based SDN can be deployed on existing networks, whether physical or virtual. Network devices that support OpenFlow forwarding can also perform traditional forwarding, allowing enterprises and operators to gradually introduce OpenFlow-based SDN, even in multi-vendor device environments.

OpenFlow-based SDN has been deployed on many network devices, bringing benefits to enterprises and operators such as:

• Centralized management and control of network devices from different vendors;

• Through a universal API, abstracting the underlying network details as a system and application calling interface, thereby enhancing the network’s automation management capabilities;

• Accelerating the innovation speed of deploying new services and functions in the network, without the need to configure each device as in the past or wait for vendors to release new products;

• A universal programming environment available for operators, enterprises, third-party software vendors, and network users, providing more opportunities for differentiation across the industry chain;

• Improving network reliability and security through automated centralized network device management, unified deployment strategies, and fewer configuration errors;

• Finer-grained network control, capable of implementing simple, clear, and broad control policies at the session level, user level, device, and application level;

• Network applications can utilize centralized network state information, allowing network behavior to closely align with user needs, thus providing a better end-user experience.

3. Openflow Case: Open Virtual Switch (OVS)

OVS (Open Virtual Switch) is an open-source software switch licensed under Apache 2. OVS aims to implement a production environment switch platform, supporting standard management interfaces and opening forwarding functions for program extension and control. OVS is particularly suitable for use as a virtual switch in VM environments, aiming to support distribution across multiple physical servers while exposing standard control and visibility interfaces to the virtual network layer.

The latest version of OVS supports the following features:

• A standard 802.1Q VLAN model with trunk and access ports;

• NIC binding on upstream switches, supporting or not supporting LACP;

• Enhanced visibility through NetFlow, sFlow(R), and mirroring;

• QoS (Quality of Service) configuration and policies;

• Geneve, GRE, VxLAN, STT, and LISP tunnels;

• 802.1ag connection fault management;

• OpenFlow 1.0 and numerous extensions;

• Transactional configuration database supporting C and Python;

• High-performance forwarding module based on the Linux kernel.

As shown in Figure 2, OVS is divided into three layers:

• Management Layer: i.e., ovs-dpctl, ovs-vsctl, ovs-ofctl, ovsdb-tool.

• Business Logic Layer: i.e., vswitchd, ovsdb.

• Data Processing Layer: i.e., datapath.

Figure 2: OVS Architecture

For a specific server where OVS is located, the management layer is remote control. The business logic layer consists of user-space applications, while the data processing layer consists of kernel-space applications. OVS mainly includes the following modules and features:

• ovs-vswitchd: A daemon that implements switching functionality, working with the Linux kernel module to achieve flow-based switching;

• ovsdb-server: Provides lightweight database query services. It stores all configuration information for OVS, including interfaces, flow tables, VLANs, etc. The ovs-vswitchd queries its configuration information;

• ovs-dpctl: Datapath control. Used to configure the switch kernel module and control forwarding rules;

• ovs-vsctl: A utility for querying and updating the configuration of the ovs-vswitchd.

• ovs-appctl: A utility for sending commands to running OVS daemons.

Open vSwitch also provides several tools:

• ovs-ofctl: A utility for querying and controlling OpenFlow switches and controllers.

• ovs-pki: A utility for creating and managing the public key infrastructure of OpenFlow switches.

• ovs-testcontroller: A simple OpenFlow controller that may be useful for testing (though not suitable for production).

• A patch for tcpdump that allows it to parse OpenFlow messages.

4. Programmability of the Network Data Plane: P4-DSA

In the previous sections, we introduced SDN and OpenFlow, discussing many advantages of OpenFlow. However, as SDN technology continues to develop, some limitations of OpenFlow have gradually been discovered. The biggest limitation is that OpenFlow is not protocol-independent; it can only define flow table entries based on existing protocols.

The OpenFlow interface was initially simple, only abstracting a single rule table, and could only match on twelve specific packet header fields (such as MAC address, IP address, payload protocol type, TCP/UDP port, etc.). Over the past few years, protocol standards have evolved to become increasingly complex, with the number of fields increasing to 41 by OpenFlow 1.4. In summary, it supports matching on more header areas and multi-level rule tables, allowing switches to expose more of their capabilities to the controller.

With the increase in new packet header fields, there is no sign of this trend ending. Rather than continually expanding the OpenFlow protocol standard, future switches should support flexible mechanisms for packet parsing and header field matching, allowing controller applications to utilize these capabilities of switches through a common open interface.

P4 (Programming Protocol-Independent Packet Processors) is a high-level language aimed at programming the network data plane. Figure 3 illustrates the relationship between P4 and existing protocol interfaces. P4 is used to configure switches, telling them how to process data packets. Existing protocol interfaces (such as OpenFlow) are responsible for sending forwarding tables to fixed-function switches.

P4 raises the abstraction level of network programming and can serve as a common interface between controllers and switches. Future OpenFlow protocols should allow controllers to