Loading learning content...
Not all SDN controllers are created equal. The term "SDN controller" encompasses a spectrum of architectural approaches—from single-instance centralized controllers suitable for small networks to globally distributed systems managing continent-spanning infrastructure.
Understanding controller types isn't merely academic classification. The choice of controller architecture fundamentally shapes network behavior: how quickly failures are detected and remediated, how policy consistency is maintained, how the system scales as networks grow, and what operational complexity organizations must manage.
This page classifies SDN controllers along multiple dimensions, explaining the architectural principles, trade-offs, and appropriate use cases for each type. By the end, you'll understand why hyperscalers use different controllers than enterprises, and why campus networks make different architectural choices than data centers.
By the end of this page, you will understand the primary classification dimensions for SDN controllers (centralized vs. distributed, physical vs. logical), the architectural patterns each type employs, the trade-offs between simplicity and scalability, and guidelines for matching controller type to deployment requirements.
SDN controllers can be classified along several orthogonal dimensions. Understanding these dimensions provides a framework for analyzing any controller's architecture.
Dimension 1: Physical Deployment
How many controller instances exist?
Dimension 2: Logical Architecture
How does the control plane appear to the network and applications?
Dimension 3: Decision Authority
Where are forwarding decisions made?
| Classification | Description | Example Use Case |
|---|---|---|
| Physically Centralized | Single controller instance, single location | Lab, small campus, proof of concept |
| Physically Clustered | Multiple instances, single site, shared state | Enterprise data center, medium campus |
| Physically Distributed | Multiple instances, multiple sites | Multi-site enterprise, WAN, cloud provider |
| Logically Centralized | Appears as single controller to network | Most SDN deployments |
| Logically Distributed | Separate control domains, explicit boundaries | Multi-tenant, federated networks |
| Hierarchical | Layered controllers with delegation | Large-scale WANs, carrier networks |
The most important distinction is between logical and physical organization. A logically centralized controller may be physically distributed across multiple instances—appearing to applications and switches as a single entity while actually running on a cluster. This pattern combines the programming simplicity of centralization with the resilience of distribution.
The centralized controller represents the purest expression of SDN principles: a single point of control with complete network visibility and authority. All forwarding decisions flow from this central brain.
Architecture Characteristics
In a centralized architecture:
Operational Flow
When Centralized Works Well
Centralized controllers are appropriate when:
High Availability in Centralized Designs
Even "centralized" production deployments typically include redundancy:
This is still logically centralized—one controller is active at any time—but physically provides redundancy.
Critics often dismiss SDN as 'putting all eggs in one basket.' This misunderstands the architecture. Even single-instance controllers maintain installed flows during failure—switches don't stop forwarding. New flows cannot be programmed, but existing traffic continues. Combined with active/standby and graceful degradation, centralized controllers provide robust production capabilities for appropriately-sized networks.
Distributed controllers scale SDN to networks beyond single-controller capacity by running multiple controller instances that share responsibility while presenting a unified logical view.
Architecture Characteristics
Distributed controller architectures exhibit:
Distribution Strategies
Distributed controllers employ various strategies for dividing work:
Partitioned: Each controller manages a disjoint set of switches. Simple but requires coordination for cross-partition paths.
Replicated: All controllers maintain complete state. Any can handle any request. Strong consistency requires coordination overhead.
Hierarchical: Multiple layers—leaf controllers manage local domains, root controller coordinates global policies.
Flat Distributed: Peer controllers with eventual consistency. Lower coordination overhead, accepts temporary inconsistencies.
Consistency Models in Distributed Controllers
The CAP theorem applies to SDN controllers: during network partitions, systems must choose between consistency and availability. Different controllers make different choices:
Strong Consistency
Eventual Consistency
Monotonic Consistency
| Aspect | Strong Consistency | Eventual Consistency |
|---|---|---|
| Write Latency | Higher (consensus required) | Lower (local commit) |
| Read Freshness | Always current | May be stale |
| Availability During Partition | May refuse writes | Continues operating |
| Complexity | Simpler application logic | Must handle conflicts |
| Throughput | Bounded by consensus | Scales more easily |
| Use Case | Critical state (policy, security) | Telemetry, statistics |
Ownership and Work Distribution
Distributed controllers must decide which instance handles each switch:
The Mastership Concept
Many controllers use mastership: each switch has a single master controller at any time:
This pattern localizes responsibility while maintaining global coordination capability.
Distributed controllers inherit all the complexity of distributed systems: network partitions, split-brain scenarios, consensus overhead, state synchronization latency, and debugging difficulty. The complexity cost is real—only pay it when scale demands it. Many organizations deploy clustered-but-centralized controllers and never actually need full distribution.
Hierarchical controllers organize control in layers, with local controllers managing domains and higher-level controllers coordinating across domains. This architecture suits large, geographically distributed networks.
Architecture Characteristics
Two-Tier Example
Leaf Controllers: Each manages a single site (data center, campus, branch)
Root Controller: Coordinates across leaf controllers
Google's B4 Example
Google's B4 WAN is a canonical hierarchical SDN deployment:
Ten sites with hundreds of switches each are managed as ten aggregated domains. The central traffic engineering system sees inter-site links and demand; site controllers handle intra-site forwarding. This separation of concerns enables global optimization while maintaining site autonomy.
Abstraction Between Tiers
The key to hierarchical scaling is appropriate abstraction:
This abstraction reduces state at upper tiers from potentially millions of flows to dozens of domain interfaces.
Hierarchical SDN closely mirrors carrier network architecture: Access networks connect to aggregation, aggregation connects to core. Each layer optimizes for its scale and requirements. SDN hierarchies apply the same principle to control—not because carriers invented it, but because it's the natural response to multi-scale network management.
Real-world SDN deployments rarely fit pure architectural categories. Hybrid controllers combine elements of centralized and distributed architectures, often with local intelligence in switches. These pragmatic designs balance SDN benefits with operational realities.
Type 1: Centralized Control + Local Fallback
The controller provides centralized policy and path computation, but switches maintain default behavior for common traffic:
Type 2: Distributed Controllers + Logical Centralization
Multiple controller instances operate as a cluster, appearing as one to applications:
| Pattern | Description | Best For |
|---|---|---|
| Control + Default | Controller programs exceptions; switch handles defaults | Networks with predictable traffic patterns |
| Cluster + Logical Single | Clustered instances presenting unified API | HA requirements without distribution complexity |
| SDN + Traditional | SDN for overlay/policy; traditional for underlay | Brownfield deployments with existing infrastructure |
| SDN + Segment Routing | Controller programs SR paths; network executes | WAN traffic engineering with minimal state |
| Multi-Controller Federation | Independent controllers with defined handoff | Multi-vendor or organizational boundaries |
Type 3: SDN Overlay with Traditional Underlay
A common enterprise pattern separates SDN control from physical network management:
This approach is especially popular for brownfield deployments where replacing physical network control is impractical.
Type 4: Segment Routing Integration
Segment Routing (SR) shifts some intelligence back to the network while preserving SDN benefits:
SR-MPLS and SRv6 integrate with SDN controllers for traffic engineering while avoiding OpenFlow's flow table limitations.
Pure SDN—where every forwarding decision comes from a central controller—exists mainly in academic papers and small labs. Production networks blend SDN with traditional approaches, smart switches with central coordination, and multiple control planes. The goal is network improvement, not architectural purity.
SDN controllers exist across the spectrum from community-driven open source to fully proprietary commercial products. This distinction significantly impacts capabilities, support, and total cost of ownership.
Open Source Controllers
Community and foundation-backed controllers offer:
Major Open Source Controllers:
| Aspect | Open Source | Commercial |
|---|---|---|
| Licensing Cost | Free (typically Apache/EPL) | Per-device or per-feature licensing |
| Support | Community + optional paid | Vendor SLA and dedicated support |
| Road Map Control | Community-driven | Vendor-controlled |
| Customization | Full source access | APIs only (typically) |
| Integration Effort | Significant (DIY) | Fewer (vendor-provided) |
| Ecosystem | Open APIs, multi-vendor | May lock into vendor ecosystem |
| Certification | Industry certifications rare | Common (FIPS, etc.) |
| Time to Value | Longer (integration needed) | Faster (turnkey solutions) |
Commercial Controllers
Vendor-backed controllers offer:
Major Commercial Controllers:
The Middle Ground
Many controllers exist between pure open source and proprietary:
Organizations must evaluate total cost: license fees, integration effort, operational expertise, and support requirements all factor into the real cost of any controller.
'Free' open source controllers require engineering investment: integration, testing, hardening, and ongoing maintenance. Commercial controllers include these costs in license fees. The right choice depends on your organization's engineering capacity, time constraints, and strategic priorities. Neither option is inherently cheaper—just differently structured.
Controller selection depends on network requirements, operational capabilities, and strategic context. There's no universally correct choice—only appropriate choices for specific situations.
Decision Framework
Evaluate these dimensions when selecting controller architecture:
Scale Requirements
Availability Requirements
Operational Maturity
| Scenario | Recommended Type | Rationale |
|---|---|---|
| Lab/Development | Single centralized (Floodlight/Ryu) | Simplicity, quick setup, learning friendly |
| Small Enterprise (<100 switches) | Centralized with HA | Manageable scale, simple operations |
| Large Campus (100-1000 switches) | Clustered distributed | Scale with availability guarantees |
| Multi-Site Enterprise | Hierarchical or federated | Site autonomy with global coordination |
| Carrier/WAN | Hierarchical with strong HA | Scale and regulatory requirements |
| Hyperscale Data Center | Custom distributed | Extreme scale, custom requirements |
| Cloud Provider | Multi-domain with abstractions | Multi-tenant, extreme scale |
The most common controller selection mistake is over-engineering. Organizations deploy fully distributed controllers for 50-switch networks that would be perfectly served by a simple HA pair. Start with the simplest architecture that meets requirements. You can always add complexity—removing it is much harder.
We've explored the spectrum of SDN controller architectures, from simple centralized designs to complex distributed hierarchies. Let's consolidate the key insights:
What's Next:
Now that we understand controller types, we'll examine the interfaces that connect controllers to the network ecosystem. Northbound APIs connect applications to controllers; southbound APIs connect controllers to devices. Understanding these APIs is essential for both using and developing SDN applications.
You now understand the major types of SDN controller architectures—centralized, distributed, hierarchical, and hybrid—along with their trade-offs and appropriate use cases. This knowledge enables informed architectural decisions for SDN deployments. Next, we'll explore the APIs that enable controller communication.