Software-defined networking (SDN): history, architecture, and uses

Informatec Digital » Resources » Software-defined networking (SDN): history, architecture, and uses

Software-defined networking (SDN) has completely changed the way communications infrastructures are designed, deployed, and managed . What was once a rigid framework of physical equipment and manual configurations can now be managed almost like code, with much greater speed, flexibility, and visibility into what is happening in every corner of the network.

This new approach didn't emerge from nowhere: it's the result of decades of research and several technological milestones , from the active networks of the 90s to the standardization of OpenFlow and the creation of a complete ecosystem of controllers, APIs, and applications. Let's take a step-by-step look at how we got here, what problems SDN solves, how it works internally, and in what real-world scenarios it's being used today.

Origin and history of software-defined networks (SDN)

The story of SDN begins about 20 years ago, at the dawn of the commercial internet , when the success of the global network made it clear that communications infrastructures needed to be able to be modified and evolve much more easily. From then on, three major stages can be distinguished that paved the way for what we now call SDN.

The first stage corresponds to active networks (approximately 1995-2000) . The idea was to open the network to programming, similar to how a PC is programmed, but applied to each communication node. To achieve this, an API was defined in the network devices that exposed resources such as computing power, storage, packet queues, and processing functions, allowing code to be loaded that applied custom behaviors to specific traffic flows.

This approach clashed with the view of those who argued that the only way for the internet to scale and remain functional was to keep the network as simple as possible. Even so, the active networking program spurred key advances: reduced computational costs, improvements in programming languages, the rise of virtual machines , and, above all, the idea that the network could be treated as a programmable platform and not just a collection of closed boxes.

An important catalyst of that era was the support of agencies such as DARPA, which launched the Active Networks Program , active from the mid-90s to the early 2000s. Although active networks never achieved mass deployment, they sowed concepts that would later be fundamental to SDN: programmable functions in the network, resource virtualization, and a unified view of different devices (firewalls, IDS, NAT, etc.).

With the turn of the decade and the explosive growth in traffic, the second phase began, focused on the separation of the control plane and the data plane (2001-2007) . Traditional routers and switches combined control logic (route selection, routing protocols) and the data plane (actual packet forwarding) in the same device, making it very difficult to debug errors, adjust traffic engineering, or introduce new services.

To deal with this scenario, operators began implementing packet forwarding on specialized hardware , while control remained more separate, and at the same time they sought ways to manage increasingly large and complex networks, with services such as VPNs and other advanced features. From this emerged two lines of innovation: on the one hand, open interfaces between control and forwarding, such as ForCES (IETF) or Netlink on Linux; on the other, architectures with centralized logical control, such as RCP, SoftRouter, or the PCE protocol, which allowed routing decisions to be made with a global view.

The third stage arrived with Project 4D and the subsequent Ethane , which crystallized the idea of ​​a central logic controller with four clearly defined planes: data (packet processing according to rules), discovery (collection of topological and traffic information), dissemination (installation of processing rules), and decision (global policies translated into specific rules). Ethane, deployed in real-world environments such as Stanford University, contributed an extremely simple switch design that would become the basis of what we now know as OpenFlow.

Meanwhile, the experimentation ecosystem was also advancing: infrastructures like PlanetLab and Emulab, projects like GENI and the European FIRE program, and Stanford's Clean Slate Program fostered large-scale testing of alternative network architectures. It was in this environment that OpenFlow emerged as a practical way to expose switch forwarding capabilities to an external controller using a standard API.

A significant industry milestone was Avaya's 2014 demonstration , which combined Shortest Path Bridging with OpenStack to build software-defined networks with minimal manual configuration. And, gradually, thanks to simple firmware updates, many commercial switches began supporting OpenFlow without requiring hardware changes.

Problems of traditional networks that SDN solves

Conventional networks, based almost exclusively on individually configured physical equipment , are reaching their limits in the face of current needs from businesses, service providers, and end users. Their main Achilles' heel is the complexity accumulated over the years.

To cover all possible scenarios, the industry has been adding increasingly specific network protocols that solve particular problems (security, efficiency, redundancy, etc.), but these are usually designed in isolation. The result is a tangled web of mechanisms that must be coordinated manually, without a common abstraction layer to simplify the whole.

When an organization wants to enforce consistent policies across its entire network—for example, determining who can access which resources—administrators have to modify hundreds or thousands of devices . Something as simple as adding a new virtual machine can involve changes to numerous access control lists (ACLs) scattered throughout the environment, with the risk of human error and delays of hours.

Lack of scalability is another serious problem. The rise of data centers, user growth, and increased traffic necessitate adding more and more devices. Each additional piece of equipment means more configuration, more management, and more potential points of failure. Keeping all of this aligned with business needs becomes a Herculean task.

From an economic standpoint, organizations suffer from a heavy reliance on manufacturers' product cycles . If new network functionality is needed, simply updating software is often insufficient: organizations must wait for the vendor to release the appropriate model, for internal certifications to be completed, for the equipment to be acquired, for deployment to occur—a process that can take years and stifle innovation.

To make matters worse, recent trends further complicate the picture: much more heterogeneous traffic patterns are emerging , with machine-to-machine flows, distributed databases, microservices, and users connecting from anywhere with mobile phones, tablets, and laptops. The workload for administrators is increasing as they try to protect sensitive data while the traditional network perimeter is virtually disappearing.

Added to this is the growth of cloud services (SaaS, IaaS, PaaS) , which demand rapid provisioning, dynamic scaling of computing, storage, and networking, as well as more sophisticated security requirements. The rise of big data demands massive bandwidth and transport capacity across thousands of servers that traditional networks cannot always keep up with.

What is SDN really and how does it solve it?

SDN emerges as a new architecture designed to provide flexibility, centralized control, and programmability to the network, shifting complexity to the software and removing it from the hardware. It's no longer about managing each device individually, but about defining the desired network behavior from a higher logical layer.

The key principle is the separation of the control plane and the data plane . The data plane is responsible for moving packets at high speed between endpoints; the control plane decides how and where those packets should travel, applying policies, routes, and rules. In SDN, these planes are decoupled, and control is concentrated in one or more logical controllers.

A well-defined interface is established between the two, usually through a standard protocol like OpenFlow . Thanks to this interface, the controller can install, modify, or delete forwarding rules on switches and routers, which then behave as programmable devices rather than closed systems. OpenFlow is not the only possible protocol, but it is the most widespread and has become the de facto standard.

Above the controllers, SDN applications use northbound APIs to express what behavior they need from the network : prioritizing certain traffic, segmenting departments, load balancing, improving quality of service, reacting to a denial-of-service attack, etc. The controller translates these high-level requests into concrete forwarding rules that are applied in the data plane.

In other words, SDN transforms the network into a platform where applications and services can be developed as if they were pure software , disregarding the details of each equipment model or low-level protocol. This abstraction facilitates automation, reduces errors, and allows for much faster adaptation to changes in demand.

SDN Architecture: Controllers, APIs, and Key Components

A typical SDN network is structured into several logical layers and well-differentiated components. At its heart is the SDN controller , which acts as the network's brain, gathering information from the data plane and implementing application decisions.

The controller maintains an abstract view of the network: topology, capabilities of each device, traffic statistics, link states, etc. With this information, and relying on plug-in modules that can be activated or deactivated (inventory management, statistics collection, security modules, load balancing, etc.), it makes decisions and communicates them to the devices through the southbound API, usually OpenFlow or other protocols such as OVSDB or Cisco OpFlex.

Data plane devices—physical switches, virtual switches, routers—implement what the ONF calls an SDN Datapath : a set of forwarding engines and traffic processing functions exposed logically. Within each datapath is a Control Interface Processing Agent (CDPI agent) that receives instructions from the controller and translates them into rules in flow tables or specific hardware actions.

At the top of the architecture are the SDN applications . These are programs that communicate with the controller via Northbound APIs (NBIs) and express business or technical needs: IP address management (IPAM), service orchestration, quality of service (QoS) control, DoS attack defense systems, advanced analytics tools, etc. Each application contains its own logic and one or more NBIs to interact with the controller.

Between these blocks lies the Control-to-Data Plane Interface (CDPI) , which is responsible for providing programmability over forwarding, advertising device capabilities, exposing statistics, and notifying events. Controllers implement drivers for this interface, and devices implement agents, so each driver/agent pair establishes a specific relationship between the physical infrastructure and the applications.

In addition to these three main layers, the ONF identifies a management and administration layer that covers more static tasks: resource allocation to clients, basic configuration of physical equipment, credential management, and associations between logical and physical entities. These tasks are typically managed outside the dynamic traffic control cycle.

North and South interfaces, and flow programming models

The southbound API connects the controller to the hardware or data paths . OpenFlow was the first widely adopted interface: it defines how the controller installs entries in the switches' flow tables, how it collects statistics, how events such as mismatched packets are reported, and so on. Other alternatives, such as Cisco OpFlex, propose different models, but with the same basic idea of ​​allowing a central element to influence device behavior.

The northbound API allows applications to communicate with the controller and receive an abstract view of the network. There isn't a standard as well-established as OpenFlow: there are many proposals and libraries located at different layers of the stack (REST, gRPC, specific SDKs, intent-based models, etc.), and it is precisely because of this diversity that the ONF has placed great emphasis on defining best practices and converging towards compatible approaches.

At the operational level, controllers can follow a proactive, reactive, or hybrid model to implement flow rules on devices. In the reactive approach, the switch queries the controller when it receives a packet that doesn't match any entry in its table; the controller responds with instructions and, if necessary, creates a new rule for similar future packets.

In the proactive model, the controller pre-installs rules for expected traffic flows , similar to how traditional routing tables are populated. This minimizes real-time queries and reduces the latency of initial communications. Many real-world deployments combine both models, being reactive to unpredictable traffic and proactive for well-known flows.

The true strength of SDN lies in the programmability provided by these open APIs . Thanks to them, it's possible to dynamically adjust routes based on load, prioritize critical traffic, automate response to failures or security incidents, and even allow applications themselves to negotiate the conditions they need with the network (bandwidth, maximum latency, redundancy level, etc.).

Use cases of programmability in SDN

To illustrate the concept of network programmability, three major use cases are often discussed to demonstrate how SDN is leveraged in practice . The first is fine-tuning of traffic flows: with protocols like OpenFlow, the controller can decide, almost on the fly, which paths certain types of traffic should follow, balancing load across links, avoiding congestion, or applying stricter security policies where necessary.

The second major case lies in advanced application support . Instead of the network being blind to what applications are doing, they can expose their requirements (for example, low latency for voice or video, high bandwidth for certain transfers, strict isolation between clients), and the controller adapts the configuration to meet them. Furthermore, automated deployments—especially in cloud and massive virtualization environments—allow for the rapid deployment of new services without an administrator having to manually change parameters.

The third key element is the automation of network operations . In a well-designed SDN scenario, the network can react autonomously to many events: if a link goes down, routes are recalculated; if a suspicious traffic pattern appears, blocking rules or redirection to analysis systems are applied; if a new application is launched, the network automatically allocates resources. The administrator's role shifts from simply "changing commands" to defining high-level policies and ensuring compliance.

Advantages of SDN for organizations

The value proposition of SDN translates into a series of very clear advantages for companies and service providers . One of the most notable is centralized management: from the controller, access policies, security rules, traffic priorities, and service provisioning can be defined for the entire network, without having to manage each device individually or depend on each manufacturer's specific interface.

In terms of scalability, SDN offers tremendous agility. Administrators can add or remove virtual appliances, segment networks, connect branch offices or data centers , and adjust routes in near real-time, often integrated with cloud orchestration platforms. All of this is achieved with minimal impact on the underlying physical infrastructure, which remains a relatively stable substrate.

Another important advantage is the comprehensive visibility into network behavior . By centralizing information in the controller or a domain of coordinated controllers, a complete picture of performance, bottlenecks, active flows, and potential threats is obtained. This visibility facilitates not only day-to-day operations but also capacity planning and early problem detection.

From an economic perspective, SDN helps reduce both CAPEX and OPEX. On the one hand, it allows for the reuse of much of the existing hardware , since many switches can enable SDN functions with simple firmware updates. On the other hand, automation decreases the time staff spend on repetitive configuration tasks, reduces human error, and simplifies maintenance and upgrades.

The last major set of benefits relates to innovation and speed of response . By decoupling hardware and software, organizations can create new services, experiment with different business models, or adapt the network to new requirements (hybrid cloud, IoT, edge computing, big data) without being tied to the product launch schedule of a specific manufacturer.

Disadvantages and challenges of SDN networks

SDN is not a panacea and also brings challenges that must be kept in mind when designing and operating these types of networks. One of the most frequently cited is the potential vulnerability of the controller: by concentrating so much logic and decision-making, it becomes a critical point whose failure or compromise can bring down the entire system.

This necessitates the deployment of high availability, redundancy, and failover mechanisms , as well as very strict access controls. Denial-of-service (DDoS) attacks against the controller, for example, must be mitigated with sufficient capacity to prevent the network from becoming "blind" to critical events.

Another challenge is the potential increase in latency and complexity as the number of devices and flows grows. If the controller has to manage too many interactions with the data plane, it can become overloaded. A well-designed SDN architecture should distribute functions, maintain some control in the distributed elements when it makes sense (for example, for fast recovery from local failures), and scale controllers horizontally.

In terms of security, while SDN offers improved visibility, it also lacks some mechanisms that were previously integrated into traditional routers, switches, or physical firewalls. It is essential to protect communications between controllers, applications, and devices, ensure authenticity and integrity, and design a robust policy environment that allows for verification that policies are applied exactly as intended.

Furthermore, it is critical to establish processes for network forensics : detailed event logging, change traceability, and the ability to reconstruct what happened in the event of an incident. All of this must coexist with the inherent dynamism of SDN, preventing security from becoming a bottleneck while also ensuring no vulnerabilities remain.

Roles of the ONF and other actors in the SDN ecosystem

The Open Networking Foundation (ONF) plays a fundamental role in the evolution of SDN. It is an organization driven by end users (operators, large corporations) with the goal of promoting the adoption of software-defined networks through open standards and collaborative processes.

The ONF has been responsible for defining, maintaining, and evolving the OpenFlow standard , which was the first recognized SDN standard and remains a core element in many architectures. But its work goes beyond that: it leads working groups that analyze requirements for commercial deployments, propose new interfaces, data models, and terminology, and foster a multi-vendor ecosystem.

In parallel, technology companies and equipment manufacturers have developed their own SDN platforms and hybrid approaches. Some, such as solutions based on logically centralized controllers like Ciena's Blue Planet, combine centralized functions (end-to-end visibility, policies, bandwidth) with distributed capabilities across network elements for fault recovery, local monitoring, or security.

This hybrid approach reflects a practical reality: not all control has to be put on the central controller, and it is convenient for certain rapid reaction mechanisms to remain close to the traffic, while the more complex intelligence and orchestration are managed in a centralized and programmable manner.

SDN, network virtualization, and real-world use cases

In many organizations, SDN is adopted in conjunction with network virtualization techniques to create overlay networks on top of the existing physical infrastructure. These virtual networks can segment different environments (production, development, distinct customers) by leveraging the same underlying hardware, or they can interconnect multiple physical networks as if they were a single logical entity.

This approach is especially powerful when integrated with cloud computing services such as SaaS, IaaS, and PaaS . The software-defined network is coordinated with orchestration platforms so that the entire provisioning cycle—virtual machines, storage, network, security—is performed consistently, quickly, and automatically, often through APIs.

In large enterprises and operators, SDN is used to build smarter corporate WANs , where traffic between headquarters, data centers, and public clouds is finely managed. Google, for example, has been using SDN for years to interconnect its global data centers and has collaborated with the ONF in defining new control interfaces beyond OpenFlow.

In the data center environment, SDN is a key component for achieving rapid and efficient scaling : enabling a new data center to become operational in hours and network resources to be provisioned in minutes. It also facilitates the deployment of large-scale IoT environments, managing thousands of distributed devices and sensors without overwhelming complexity.

Finally, SDN is part of a broader trend toward software-defined infrastructure , where not only the network but also storage (SDS) and other resources are controlled from logical control planes, independent of the specific hardware. This gives organizations greater portability, agility, and the ability to move workloads between the cloud and on-premises as needed.

With all this historical, technical and practical background, SDN is consolidating itself as a different way of understanding networks: closer to the world of software, focused on automation and programmability, and capable of responding to the challenge of traffic growth, the cloud, big data and IoT without forcing an indefinite multiplication of hardware or operational complexity.