Networks can be virtualized, just like servers, storage, or entire data centers. The technology is based on developments at Stanford University, and today, the Open Networking Foundation is continuing the work with new projects. Proprietary implementations are also available from major vendors.

The principle is always the same: The physical hardware and software are separated, and functions previously cast in hardware are implemented in the software. The rewards of software-defined networking (SDN) are greater flexibility and a loosening of vendor tie-in.

Providers and enterprises need to design and leverage technologies (e.g., remote, mobile, cloud and Internet of Things (IoT), edge computing, virtual reality, containers, microservices, and service meshes) for flexibility. The idea is to provide connections or change quality of service (QoS) in minutes, rather than months. Users want additional functionality, such as enhanced security, on demand and only for specific data streams, time periods, or routes and no longer want to book and pay for these services combined.

SDN Layer Model

The SDN approach requires a departure from hardware-based thinking. In addition to the separation of software and hardware, network virtualization primarily means the separation of data and control paths. Several higher levels are implemented in the network, from which the underlying switches and routers (Layers 2 and 3 according to the network model) and their connections and qualities of service can be controlled. The aim here is to provide optimum conditions for all data and streams crossing the network and effectively keep unwanted intruders away from the data packets in transport.

In SDN infrastructures, the applications lie above a control layer in the context of network function virtualization (NFV). The basic standard for open SDN networking, OpenFlow, only allows the definition of a data pipeline (i.e., the path over which a particular data packet or stream flows). However, NFV means that additional specific network functions can be provided as applications on the network – and in a vendor-agnostic and decentralized way.

These applications can run on bare metal, in containers, and on virtual machines, which involves, for example, granting access rights, firewalling, encryption, and much more. SDN also includes two interfaces. The northbound application programming interface (API) sits between the control and application layers, whereas the southbound API sits between the control and infrastructure layers.

OpenFlow at the Beginning

The driving force behind the efforts to develop virtualized and open network structures (i.e., SDN) always has been the major providers and cloud hyperscalers. These parties joined forces in 2011 to form the Open Networking Foundation (ONF) because their businesses suffered the most from the lack of flexibility in earlier networking constructs, with hardware zoos and high maintenance and personnel costs.

The ONF now has more than 200 members, and they are no longer exclusively providers. The Foundation continues to provide impetus for the further development of SDN by initiating and realizing projects for new technical implementations. It also cooperates with the Open Compute Project (OCP), among others.

The initial ideas for the OpenFlow interface, the first SDN standard, came from Stanford University, where a preliminary version was presented as early as 2008. Version 1.0 was released in December 2009. The interface allows an SDN controller to reach beyond routers and switches, which was previously impossible.

SDN is controlled in infrastructures by OpenFlow with OpenFlow-compliant SDN controllers implemented in hardware or software. OpenFlow has subsequently been implemented by the major cloud providers. ONF also developed a standard for an open virtual switch. Important application areas of the open SDN standard include infrastructure as a service (IaaS), wherein SDN technology facilitates rapid scaling. Additionally, loads can be efficiently assigned to existing resources (e.g., those not currently needed can be switched off). Finally, SDN technology facilitates the definition of and compliance with service-level agreements.

Stratum Switching Operating System

The phase during which ONF focused on OpenFlow is now over. With the entrance of the new Stratum project, the organization announced back in March 2018 its departure from OpenFlow as the SDN lead technology. Whereas OpenFlow served as an interface to the forwarding layer and the router operating system, Stratum is intended to merge pipeline definition, configuration, and operation (Figure 1).

Figure 1: Stratum runs as an operating system directly on the switching infrastructure.© Open Networking Foundation

Stratum defines a silicon-independent, lightweight switching operating system for SDNs. The first version was launched in 2019 with a minimal but ready-to-use distribution for white-box switches. Stratum opens access to various innovative SDN interfaces, such as P4Runtime and OpenConfig. All told, these interfaces make it easier to integrate arbitrary systems into provider networks.

The current version of Stratum is 20.06. Certified switches are currently available from APS Networks and Edgecore. Chips that support Stratum include the Broadcom Tomahawk and Trident2, the Intel Tofino switch, and Barefoot Networks, which Intel acquired in 2019 and abandoned in 2023. Non-certified supporting switches are available from Dell, Delta, Inventec, Quanta Cloud Technology (QCT), and Stordis.

The certified Edgecore AS7712-32X, for example, can be rack mounted and provides line-rate switching. The device supports up to 32 connections at 40 or 100GbE (aka GigE), 64 connections at 50GbE, or 128 connections at 10 and 25GbE. The device is suitable as a top-of-the-rack switch or as a spine switch for connecting different spines.