101
0/228
Loading content...
The SDN controller ecosystem encompasses dozens of implementations—from academic research projects to carrier-grade commercial platforms. Navigating this landscape requires understanding not just feature lists, but the architectural philosophies, target use cases, and community dynamics that shape each controller.
This page profiles the most significant SDN controllers in production today. We'll examine open-source giants like ONOS and OpenDaylight, commercial leaders like Cisco ACI and VMware NSX, and specialized controllers for specific domains. For each, we'll explore architecture, distinctive features, deployment patterns, and appropriate use cases.
By the end of this exploration, you'll understand the major players in the SDN controller market and have the context needed to evaluate controllers for specific deployment scenarios.
By the end of this page, you will understand the architectural approaches of major open-source controllers (ONOS, OpenDaylight), the positioning of commercial controllers (Cisco ACI, VMware NSX, Juniper Contrail), specialized controllers for specific use cases, and how to evaluate controllers against deployment requirements.
ONOS (Open Network Operating System) is a carrier-grade, distributed SDN controller designed for high availability, scalability, and performance. Developed initially by ON.Lab and now stewarded by the Open Networking Foundation (ONF), ONOS targets service provider and large enterprise deployments.
Architecture Overview
ONOS is built as a distributed system from the ground up:
Key Architectural Components
Intent Framework
ONOS's Intent Framework is a signature feature:
Deployment Characteristics
Target Use Cases
ONOS is the controller for CORD (Central Office Re-architected as a Datacenter) and SEBA (SDN-Enabled Broadband Access)—frameworks for bringing SDN and NFV to carrier access networks. If you're in the carrier space, ONOS with these profiles provides a complete solution for access network transformation.
OpenDaylight (ODL) is a modular, multi-protocol SDN controller developed under the Linux Foundation. Unlike ONOS's carrier focus, OpenDaylight targets enterprise and data center use cases with extensive multi-vendor integration.
Architecture Overview
OpenDaylight is built around the Model-Driven Service Abstraction Layer (MD-SAL):
Key Architectural Components
| Category | Key Features | Use Cases |
|---|---|---|
| Southbound Plugins | OpenFlow, NETCONF, OVSDB, BGP-LS, PCEP | Multi-vendor device management |
| Network Services | L2Switch, L3VPN, VTN, SFC | Enterprise connectivity |
| Intent/Policy | NIC, GBP (Group-Based Policy) | Intent-based networking |
| NFV Integration | VTN Manager, OVSDB, Service Chaining | Virtualized network functions |
| Network Visibility | Topology, Statistics, Inventory | Monitoring and analytics |
| Infrastructure | Clustering, AAA, DLUX UI | Production operations |
Model-Driven Architecture
OpenDaylight's model-driven approach has profound implications:
Deployment Characteristics
Target Use Cases
The ONOS vs ODL debate is longstanding. Generally: ONOS excels at carrier-scale, flow-heavy workloads with its distributed core; ODL excels at enterprise environments with diverse protocols and configuration-centric management. Both are capable of most SDN tasks—the right choice depends on your primary use case and existing expertise.
Cisco Application Centric Infrastructure (ACI) is a proprietary SDN solution for data center networks. Unlike open-source controllers that manage multi-vendor devices, ACI integrates deeply with Cisco Nexus 9000 switches to deliver a unified fabric.
Architecture Overview
ACI comprises three core components:
The system operates as an integrated whole—APIC doesn't just program switches, it manages the complete fabric lifecycle.
The Policy Model
ACI centers on an object-oriented policy model:
Intent-Based Networking in ACI
ACI operationalized intent-based networking before the term became popular:
Deployment Characteristics
Integration Ecosystem
ACI fits organizations that want a proven, integrated solution with vendor support and can commit to Cisco hardware. If you're building a new data center, have budget for premium solutions, and value operational simplicity over architectural flexibility, ACI delivers. Multi-vendor or budget-constrained environments should consider alternatives.
VMware NSX is a network virtualization platform that creates software-defined networks independent of physical infrastructure. Unlike traditional SDN controllers that manage physical switches, NSX virtualizes the entire network layer.
Architecture Overview
NSX operates at the hypervisor level:
Two Product Lines
The Overlay Model
NSX creates virtual networks using overlays:
| Feature | Capability | Benefit |
|---|---|---|
| Logical Switching | VXLAN/GENEVE overlay networks | Network isolation independent of physical topology |
| Logical Routing | Distributed and centralized tiers | Optimal east-west traffic, flexible north-south |
| Distributed Firewall | Per-VM/container stateful firewall | Micro-segmentation at workload level |
| Gateway Firewall | Edge-level inspection and filtering | Perimeter and inter-zone security |
| Load Balancing | L4-L7 load balancing at edge | Application delivery without separate appliances |
| VPN Services | IPSec, SSL VPN at edge | Secure connectivity without dedicated VPN |
| Container Networking | NCP for Kubernetes/OpenShift | Consistent networking across VMs and containers |
Micro-Segmentation
NSX's distributed firewall enables zero-trust security:
Multi-Cloud Support
NSX extends beyond on-premises:
Deployment Characteristics
NSX represents a different SDN approach than OpenFlow-based controllers. Instead of programming physical switches, NSX virtualizes networking entirely in software. Physical switches become simple L3 transport. This trades physical switch programmability for complete abstraction from hardware.
Beyond the major players, several specialized and emerging controllers deserve attention for specific use cases.
Juniper Contrail/Tungsten Fabric
Originally Juniper's SDN controller, now open-sourced as Tungsten Fabric:
Arista CloudVision
Arista's management and automation platform:
Nokia Nuage Networks
Nokia's SD-WAN and data center SDN platform:
| Controller | Primary Domain | Differentiator | Typical User |
|---|---|---|---|
| Tungsten Fabric | Telco/NFV | BGP-based, OpenStack native | Service providers |
| Arista CloudVision | Data Center | Streaming telemetry, EOS integration | High-performance DC |
| Nokia Nuage | SD-WAN + DC | End-to-end orchestration | Enterprise with branches |
| Apstra (Juniper) | Intent-Based DC | Multi-vendor intent networking | Multi-vendor data centers |
| Pluribus Netvisor | Distributed SDN | Fabric-wide distributed control | Campus + data center |
| Big Switch (Arista) | SDN Visibility | Big monitoring fabric | Security and monitoring |
Educational and Research Controllers
For learning and research, simpler controllers remain valuable:
Ryu Controller
Floodlight
POX
Faucet
The SDN controller market continues consolidating. Acquisitions (Big Switch → Arista, Contrail → Tungsten, Apstra → Juniper) reshape competitive dynamics. When evaluating controllers, consider not just current features but vendor stability, community health, and long-term roadmap alignment.
With multiple controller options available, comparative analysis helps clarify selection decisions. Let's examine how major controllers compare across critical dimensions.
Architecture Philosophy
Controllers differ in fundamental approaches:
These philosophies shape every aspect of operation—deployment complexity, integration patterns, and optimal use cases.
| Criterion | ONOS | OpenDaylight | Cisco ACI | VMware NSX |
|---|---|---|---|---|
| License | Apache 2.0 | EPL + Apache | Commercial | Commercial |
| Primary Language | Java | Java | Proprietary | Proprietary |
| Clustering | Atomix/Raft | Akka | Proprietary | Proprietary |
| Primary Southbound | OpenFlow, P4 | OpenFlow, NETCONF | OpFlex | Geneve/VXLAN |
| Multi-Vendor | Yes | Yes | No (Nexus only) | Yes (overlay) |
| Intent Support | Intent Framework | GBP | Contracts | Policy-based |
| Best For | Carrier, WAN | Enterprise DC | Cisco DC | VMware DC |
| Commercial Support | Limited | Vendor-backed | Cisco TAC | VMware Support |
Scale and Performance Characteristics
Integration Ecosystem
Operational Complexity
Feature comparison matrices don't capture everything. Equally important: quality of documentation, community responsiveness, upgrade stability, debugging tools, and integration depth. A controller with fewer features but better documentation and support may be more successful than a feature-rich but opaque alternative.
Selecting an SDN controller requires systematic evaluation against organizational requirements. This framework guides the selection process.
Step 1: Define Requirements
Before evaluating controllers, clarify needs:
Step 2: Filter by Hard Requirements
Eliminate options that cannot meet non-negotiable requirements:
Step 3: Evaluate Shortlist
For remaining candidates, evaluate:
Step 4: Total Cost Analysis
Calculate actual costs:
Step 5: Risk Assessment
Don't bet everything on initial selection. Start with a contained use case—a single data center, a specific application, a brownfield automation project. Learn from real deployment before committing organization-wide. Successful pilots justify broader investment; failed experiments teach lessons cheaply.
We've explored the major SDN controller implementations, examining their architectures, strengths, and appropriate use cases. Let's consolidate the key insights:
What's Next:
With knowledge of specific controllers, we'll complete this module by examining controller selection criteria in detail. We'll develop evaluation frameworks for matching controller capabilities to deployment requirements, enabling informed architectural decisions.
You now understand the major SDN controllers in the market—their architectures, positioning, and appropriate use cases. This knowledge provides the context for evaluating controllers against specific deployment requirements. Next, we'll synthesize this knowledge into a comprehensive controller selection methodology.