ALLPCB
Introduction
With the widespread deployment of 5G, cloud computing, and gigabit broadband, traditional network architectures face significant challenges. The growth of large-scale data centers raises higher requirements for network virtualization and resource management. Software-Defined Networking (SDN) provides a programmable network architecture with simple policy rules, high visibility, and virtualization capabilities, making it a key technology for addressing traditional network limitations and supporting large data centers. The SDN controller, as the network control plane's representative, manages network policies and flows to ensure stable operation.
1. SDN and Controller Overview
Software-Defined Networking (SDN) was proposed by the Clean-Slate research group at Stanford University as a new network architecture and one way to implement network virtualization. Its core idea is to separate the control plane from the data plane to enable flexible traffic control and more intelligent network behavior. SDN reduces dependence on specialized hardware by using direct programming to manage configuration, control, and upgrades.
Fig 1. Typical SDN architecture
The SDN controller represents the control plane and functions as the network brain. As a central component of the SDN architecture, the controller centrally manages network policies and traffic. It can improve resource utilization, shorten service deployment cycles, and increase operational efficiency. The controller can also provide unified security policies and top-down protection for the network.
2. SDN Controller Evolution
SDN controllers have evolved from early NOX controllers to modern enterprise-grade controllers, with steadily increasing functionality and capability. Two main development paths are observable: open-source projects led by communities such as OpenDaylight (ODL) and ONOS, and commercial controller products exemplified by Orion.
First-generation controllers: NOX was the first OpenFlow controller, developed by Nicira and released as open source in 2008. NOX established an early model for later controllers. It was initially written in C++, which increased the development cost for SDN applications. A later branch, POX, was implemented in Python but had architectural and performance limitations that led to its replacement by newer controllers.
General-purpose SDN control platforms: As device vendors entered the SDN controller market, requirements grew more complex. OpenDaylight (ODL) emerged as a vendor-backed open-source controller. ODL supports multiple southbound protocols beyond OpenFlow, including NETCONF and OVSDB. Its emergence marked a shift from single-protocol controllers to multi-protocol, extensible, and distributed controller platforms.
Over several years, competition among controllers intensified. The ODL community, supported by device vendors, became a leading open-source project. ONOS, also using an OSGi-like architecture but targeting service providers, gained market share through strong performance. Commercial and closed-source frameworks also competed, and in 2013 Google reported ONIX as achieving near-optimal bandwidth utilization in its deployments.
Cloud-native SDN controllers: As more services move to the cloud and large data centers scale, controllers increasingly integrate with cloud management platforms. Modern controllers incorporate AI techniques and intent-based networking for more intelligent and user-friendly operation. Open-source platforms such as ODL and ONOS have focused on automated and intelligent operation. Google's Orion adopts microservices and reconciliation principles with large-scale distributed deployment to control production networks at scale.
3. Main Controllers and Key Technologies
Active open-source controllers include OpenDaylight, ONOS, Ryu, and POX. Representative closed-source controllers include Orion, as well as vendor products such as HP VAN and Cisco DNA Center.
Each controller has distinct strengths. The following sections describe several mainstream controllers and their key technologies and functions.
3.1 OpenDaylight (ODL)
OpenDaylight (ODL) is an open-source SDN controller hosted by the Linux Foundation and was launched in 2013. It uses a community-driven development model with major contributions from device vendors. ODL aims to provide a general, programmable SDN controller that supports multiple hardware and software platforms for flexible, extensible network control.
3.1.1 Architecture
ODL is developed on the OSGi framework and uses the MD-SAL (Model-Driven Service Abstraction Layer) to model and manage southbound protocols, decoupling devices and protocols. The controller supports multiple southbound transport protocols. Core plugins provide data storage, configuration management, traffic and QoS management, and monitoring and debugging. ODL exposes northbound interfaces such as RESTful APIs to support third-party applications.
3.1.2 Core Concepts
Model-driven: ODL represents device configuration and state as YANG data models, providing a unified description of device attributes, configuration, and state. Based on YANG, ODL exposes standard RESTful APIs for controller-device communication. This model-driven approach enables multi-protocol support, plugin extensibility, and programmability.
OSGi: ODL uses OSGi for modular development, making it easier to add or remove features. The Karaf runtime provides a robust base for high availability and reduces development complexity.
YANG: YANG is a lightweight data modeling language defining hierarchical data structures. ODL uses YANG to distinguish configuration from state and to provide extensibility. As standardized models have proliferated, YANG has become a mainstream data description language across standards bodies, vendors, and operators.
3.1.3 Typical Modules
AAA: Authentication, Authorization, and Accounting provide access control, policy enforcement, and auditing for resource usage, forming a basic security framework for the controller.
BGP and PCEP: Typical application modules include BGP and PCEP plugins. The BGP plugin implements BGP protocol functions and BGP-based services. PCEP (Path Computation Element Protocol) enables communication between PCC and PCE for MPLS and GMPLS path contexts. The PCEP plugin supplies essential services for PCE-based controllers and supports Active Stateful PCE functions, which are core to many PCE-enabled SDN solutions.
Controller core: The controller module is a Java-based model-driven controller using YANG for system and application modeling. It provides a platform for other OpenDaylight applications and depends on MD-SAL, NETCONF, and RESTCONF modules.
MD-SAL: The Model-Driven Service Abstraction Layer is a message-bus-inspired, extensible middleware component that provides messaging and data storage based on user-defined data and interface models. MD-SAL defines common layers, data model building blocks, and messaging patterns to support inter-application communication.
NETCONF module: NETCONF is an XML-based management protocol for device configuration and monitoring. ODL's NETCONF module supports NETCONF as both a northbound server and a southbound plugin, and provides tools for simulating NETCONF devices and conducting client tests.
3.2 ONOS
ONOS is an open-source SDN network operating system primarily targeted at service providers and enterprise backbones. The ONOS community includes major service providers, high-end network vendors, and research organizations, with support from standardization groups.
3.2.1 Architecture
ONOS is a distributed architecture composed of an APP layer, northbound APIs, a distributed core, and southbound interfaces. The distributed core ensures high reliability, scalability, and stability. Northbound APIs provide abstractions for graphical and management interfaces. The pluggable southbound abstraction allows ONOS to support both OpenFlow and traditional devices by hiding device and protocol differences.
3.2.2 Core Concepts
SDN operating system: An operating system requires resource management, user isolation, abstracted services and resources, security mechanisms, and efficient service usage. ONOS provides these OS-like capabilities, making it more than a simple controller; it functions as an SDN operating system.
Software modularity: ONOS offers a modular framework similar to a software OS, simplifying development, debugging, maintenance, and upgrades. Its SOA-like framework supports full lifecycle management for components, including dynamic loading and unloading.
Unified network model: ONOS abstracts network resources and elements into a unified model, enabling interoperable third-party SDN applications and supporting flexible service coordination and low-cost innovation.
3.2.3 Typical Components
REST API: Open northbound abstractions facilitate application and plugin development on ONOS.
Functional components: ONOS provides a unified model for network resources and elements to aid service development.
Cluster: ONOS cluster communication supports gossip and Raft algorithms. The cluster provides partition fault tolerance and elastic scalability. If a node fails, other nodes take over control of its network elements; when a node recovers, load balancing restores control. ONOS hides distributed mechanisms behind service interfaces to simplify application development.
3.3 Orion (Google)
Orion is Google’s second-generation controller, described in the paper "Orion: Google's Software-Defined Networking Control Plane." Orion had been running in production for several years at the time of publication. Compared with Google’s first-generation controller Onix, Orion features full independent development, a microservices architecture for higher stability, and agile development for faster iteration.
3.3.1 Architecture
Orion is a microservices-based application following a reconciliation-driven model, conceptually similar to Kubernetes. The architecture separates network applications, a core layer of controller services, and the OpenFlow protocol stack on devices. The core layer provides common functions such as the NIB database, configuration, topology, and flow management, with each module implemented as a microservice.
In Orion deployments, routers run only an OpenFlow protocol stack, with traditional protocol functions implemented in the controller, representing a full SDN approach.
3.3.2 Core Concepts
Intent-driven: For large production networks, high-level intents are more stable and less error-prone than detailed procedural instructions. Orion is designed to translate and refine operator intents into device-level OpenFlow primitives, using an intent-to-primitive translation chain.
Distributed logical controller: Orion implements a logically centralized controller with distributed, in-memory state representations and appropriate consistency levels across loosely coordinated microservice applications to achieve high performance.
3.3.3 Typical Design Features
Microservices framework: Orion adopts a Kubernetes-like microservices architecture that decomposes network functions into independent services, simplifying development, deployment, and maintenance. Microservices are a key direction for future SDN controllers.
Intent and ground-truth reconciliation: Intents may originate from multiple sources. The controller coordinates and refines these intents step by step until they become machine-executable configurations, following the principle of specifying the desired end state rather than the procedural steps required to reach it.
4. Conclusion
This overview summarizes SDN controller evolution and key design directions, providing reference points for in-house controller development. Some network operators and operations centers have developed internal SDN controllers and trialed open-source controllers such as OpenDaylight in production services. There is an ongoing trend toward evolving in-house controllers into microservice-based, distributed architectures that enable faster iteration, improved stability, and higher operational efficiency for cloud-era mobile and fixed networks.
