Loading field map
Every network designer faces a deceptively simple question: where should the network's intelligence reside? Traditional networks embedded control logic—routing, switching, access control—directly into each device's firmware, making the network a collection of vertically integrated, vendor-specific black boxes. Changing how the network behaved required replacing hardware or waiting for proprietary software updates. Software-Defined Networking (SDN) emerged from the conviction that the control plane should be separated from the data plane and made programmable, allowing network behavior to be shaped by software running on general-purpose controllers. This separation opened the door to a series of architectural frameworks, each responding to the limitations of its predecessors while preserving the core promise of programmability.
The first concrete SDN framework was built around the OpenFlow protocol, which grew out of research at Stanford University (Ethane, SANE). OpenFlow gave network operators a standard way to program flow tables in switches and routers from a logically centralized controller. In this model, the controller maintains a global view of the network topology and state, and it installs forwarding rules on switches reactively (per flow) or proactively (pre-installed). The controller becomes the brain; switches become simple forwarding engines.
OpenFlow-Based SDN directly addressed the rigidity of traditional networks. Instead of configuring each device individually via vendor-specific command-line interfaces, an operator could write a single control application that dictated how traffic should be handled across the entire network. This made it possible to experiment with new routing protocols, traffic engineering policies, and security mechanisms without touching the hardware. However, the centralized controller introduced a scalability ceiling: as networks grew in size and traffic volume, a single controller became a bottleneck and a single point of failure. The framework also assumed that all switches would speak OpenFlow, which was rarely true in production environments.
Two frameworks emerged around 2010 to address the limitations of the original OpenFlow model, though they took very different approaches.
Distributed SDN replaced the single controller with a collection of cooperating controllers. These controllers could be arranged hierarchically (with a root controller coordinating regional controllers) or in a peer-to-peer fashion, each responsible for a portion of the network. The key challenge was maintaining a consistent, up-to-date global view across controllers—a problem of distributed state synchronization. Distributed SDN did not reject OpenFlow; rather, it refined the architecture by distributing the control plane while keeping the same southbound protocol. This framework made SDN viable for large-scale deployments such as data-center fabrics and wide-area networks (e.g., Google's B4). It coexists with the original OpenFlow model, offering a scalability upgrade without abandoning the centralized logic that makes programming the network straightforward.
Hybrid SDN took a different path. Recognizing that most existing networks were built from legacy equipment that did not support OpenFlow, Hybrid SDN allowed SDN-controlled devices to operate alongside traditional switches and routers. In a hybrid deployment, some traffic is handled by the SDN controller while the rest follows conventional distributed protocols (e.g., spanning tree, OSPF). The framework provides a migration path: operators can introduce SDN incrementally, starting with a few programmable switches and expanding as hardware is replaced. Hybrid SDN does not compete with OpenFlow or Distributed SDN; it narrows the scope of SDN to a transitional strategy. Today, it remains relevant in enterprise and campus networks where full SDN conversion is impractical.
While Distributed and Hybrid SDN addressed deployment challenges, a deeper architectural shift was taking place. The Network Operating System (NOS) framework abstracted the control plane into a platform that could run multiple control applications on top of a unified global view. Early examples include NOX (2008), followed by ONOS and OpenDaylight. A NOS provides northbound APIs that application developers use to express network policies, and southbound APIs that communicate with switches—OpenFlow being just one possible southbound protocol.
The NOS framework absorbed OpenFlow-Based SDN by treating the protocol as an implementation detail rather than the defining feature. Instead of writing a controller that directly manipulates flow tables, a NOS offers higher-level abstractions: a network graph, device inventory, intent-based interfaces (e.g., "connect host A to host B with 10 Gbps"). This made SDN more accessible to application developers who did not need to understand low-level forwarding mechanics. The NOS also naturally accommodated Distributed SDN: multiple NOS instances could coordinate to form a logically centralized but physically distributed control plane, as seen in ONOS's clustering model.
What distinguishes the NOS framework from earlier ones is its commitment to abstraction layers. It does not prescribe a specific controller architecture (centralized vs. distributed) or a specific southbound protocol; instead, it provides a common platform that can host different control strategies. This flexibility has made NOS the dominant framework in production SDN deployments, from service-provider networks to cloud data centers.
Today, all four frameworks remain active, but they occupy different roles. OpenFlow-Based SDN persists as a foundational reference and is still used in research testbeds and some production environments, though it has largely been absorbed into the NOS framework as one southbound protocol among many (alongside NETCONF, P4Runtime, etc.). Distributed SDN is the standard architecture for large-scale deployments: controllers like ONOS and OpenDaylight run in clusters, providing both scalability and fault tolerance. Hybrid SDN has narrowed to a transitional role, used primarily during network upgrades or in environments where legacy equipment must be retained.
The leading frameworks today—Network Operating Systems and Distributed SDN—agree on the core principles of control-data plane separation and programmability. They disagree on the degree of centralization: NOS frameworks often present a logically centralized view to applications, while Distributed SDN emphasizes physical distribution and eventual consistency. In practice, modern NOS implementations (e.g., ONOS) incorporate distributed controller clusters, blurring the line. The main tension now is between abstraction (NOS's northbound APIs) and performance (Distributed SDN's fine-grained control).
For a student, understanding these frameworks means seeing how each one refined the original SDN vision: OpenFlow proved the concept, Distributed SDN scaled it, Hybrid SDN made it practical, and Network Operating Systems turned it into a platform. The field continues to evolve, with extensions into SD-WAN, cloud-native networking, and intent-based systems, but the architectural debates that shaped these four frameworks still define the choices network architects make today.