An Introduction to Software-Defined Networking (SDN) and Its Architecture

Software-defined networking (SDN) aims to greatly simplify network control and management by leveraging network programmability to drive innovation. Typically, building computer networks relies on many network devices (such as switches, routers, firewalls, etc.) and embedded complex network protocols. Network engineers are responsible for configuring various policies, manually converting these high‑level policies into low‑level configuration commands to handle diverse network events and application scenarios.

SDN is a new networking paradigm that separates the hardware part that performs forwarding (e.g., dedicated packet‑forwarding engines) from the control‑decision part (such as protocols and control software). The concept of programmable networks was proposed as a way to promote network evolution, allowing the underlying interconnect infrastructure to be abstracted from the application layer; previously, control logic was tightly integrated into network devices (e.g., Ethernet switches), but now it becomes a logically centralized, accessible controller.

The SDN architecture also provides a set of application programming interfaces (APIs) that make the implementation of common network services—routing, multicast, security, access control, bandwidth management, traffic engineering, QoS, energy management, and various policy management—simpler. Logically, network intelligence in SDN is centralized in a software‑based controller (control plane), while network devices become simple packet‑forwarding devices (data plane) that can be programmed via open interfaces. One early implementation of such an open programming interface is OpenFlow.

By separating forwarding hardware from control logic, SDN simplifies the deployment of new protocols and applications, enables direct network virtualization and management, and allows various intermediate components to be integrated into software‑implemented control. Simplifying the network reduces forwarding hardware and the decision‑making controller, eliminating the need to implement policies and protocols in complex, distributed devices. The forwarding hardware consists of two parts:

1. A flow table containing flow entries; each flow entry consists of matching rules for the current flow and the specific actions to be taken.

2. A transport‑layer protocol used to securely communicate with the controller to deliver new records not present in the current flow table.

SDN/OpenFlow development

Although OpenFlow attracted great attention in the industry, it is worth noting that as early as 1995 the Open Signaling Working Group (OPENSIG) launched activities aimed at making ATM, Internet, and mobile networks more open, widespread, and programmable. The idea of programmable networks and separating the control plane from the data plane has a long history. This inspired later research such as NOX, a network operating system for OpenFlow networks; OpenFlow’s direct predecessor was Stanford’s SANE/Ethane project; the IETF Network Configuration Protocol (NETCONF) workgroup proposed NETCONF as a management protocol for modifying network device configurations.

Basic components of SDN

Deploying SDN requires basic components including SDN switches, SDN controllers, interfaces in the controller for communicating with forwarding devices, the typical southbound interface (OpenFlow), and the network application (northbound) interface. In SDN, because control logic and algorithms are offloaded to the controller, switches are generally represented as basic forwarding hardware that can be accessed via open interfaces. An OpenFlow switch includes a flow table that performs packet lookup and forwarding; each flow table in a switch stores a set of flow records.

The separated system in SDN can be likened to applications and operating systems on a computer platform; in SDN, the controller (i.e., network operating system) provides a programmable network interface, and by writing applications, one can perform control and management tasks and realize new functions.

SDN control is centralized; when writing applications, the network can be viewed as a single system, which simplifies policy execution and management, but the binding between the controller and the forwarding units must be continuously maintained. A controller acting as a network operating system must implement at least two interfaces: a southbound interface that supports communication between the controller and switches, and a northbound interface that provides programmable APIs for the controller and higher‑level policy applications and services.

Switch flow table and flow records

Each switch table, each flow, each port, and each queue maintains a counter. Counters wrap around without overflow bits; the diagram shows the required set of counters, and the duration indicates how long a flow exists in the switch’s flow table. Error fields include all explicitly defined errors: frame errors, over‑run, CRC errors, and other errors.

Controller northbound interface API

External management systems or network applications sometimes need to retrieve information from the lower network, or wish to control network behavior and policies, or controllers may need to communicate with each other. For example, an internal control application may need to reserve resources across different control domains; or a primary controller may need to share policy information with a backup controller. Unlike the southbound interface that provides communication between controller and switches, there is currently no widely accepted northbound interface standard; different application systems often adopt their own. One deep reason is that the northbound interface is entirely defined in software, while communication between controller and switches inevitably involves hardware implementation.

If we view the controller as a network operating system, it must have a clearly defined interface that allows applications to access underlying hardware (switches), interact with co‑existing applications, and use system services (such as topology discovery, forwarding, etc.) without requiring developers to understand the controller’s implementation details. Because multiple controllers exist, their application interfaces are still in early development, independent and incompatible.

Warm tip:

Please search “ICT_Architect” or scan the QR code below to follow the public account and get more exciting content.