117  SDN Controller Comparison

In 60 Seconds

Four major SDN controllers serve different needs: ONOS (carrier-grade, 1M+ flows/sec, Java), OpenDaylight (enterprise, modular, Java), Ryu (research/prototyping, Python, easy to learn), and Floodlight (mid-scale, Java, simple API). For IoT deployments under 1,000 devices, Ryu provides the fastest development cycle.

117.1 Learning Objectives

By the end of this chapter, you will be able to:

• Contrast Major Controllers: Evaluate OpenDaylight, ONOS, Ryu, and Floodlight across performance, scalability, and ecosystem criteria
• Benchmark Performance Metrics: Interpret throughput (flows/sec), scalability (device count), and latency characteristics for controller selection
• Justify Controller Selection: Recommend the appropriate controller for a given IoT deployment based on scale, team expertise, and HA requirements
• Estimate Deployment Resources: Calculate hardware requirements, learning curve investment, and total cost of ownership for each controller option

117.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• SDN Controller Architecture: Understanding controller components and message flow is essential for evaluating controller capabilities
• SDN Fundamentals and OpenFlow: Knowledge of OpenFlow protocol provides context for controller-switch interactions
• Networking Basics: Familiarity with network protocols helps understand controller feature sets

For Beginners: Why Different Controllers Exist

Think of SDN controllers like car manufacturers - each optimizes for different priorities.

Just as Toyota focuses on reliability, Tesla on innovation, and Ferrari on performance, SDN controllers have different design philosophies:

Controller	“Car” Equivalent	Optimized For
OpenDaylight	Swiss Army Knife	Maximum features, enterprise complexity
ONOS	Heavy-duty truck	Carrier-scale, high availability
Ryu	Go-kart	Learning, prototyping, simplicity
Floodlight	Sports car	Raw performance, speed

Which one should you learn first?

• Students/Researchers: Start with Ryu (Python, simple, great tutorials)
• Enterprise IT: Learn OpenDaylight (comprehensive, industry standard)
• Telecom/Smart City: Focus on ONOS (scales to 10K+ devices)
• Performance-critical: Consider Floodlight (fast packet processing)

The good news: All controllers speak OpenFlow, so concepts transfer between them. Learning one makes the others easier to understand.

Related Chapters

Deep Dives:

• SDN Controller Basics (Overview) - Index of all SDN controller topics
• SDN Controller Architecture - Internal components and message flow
• SDN APIs and Clustering - Northbound/southbound APIs and high availability

Protocols:

• SDN Fundamentals and OpenFlow - OpenFlow protocol basics
• Software Defined Networking - SDN overview

Learning:

• Simulations Hub - SDN simulation tools
• Network Design and Simulation - SDN testing

117.3 Controller Comparison Overview

Time: ~18 min | Difficulty: Intermediate | Unit: P04.C27.U02

Different controllers excel in different scenarios. Here is a comprehensive comparison of the four major open-source SDN controllers.

Figure 117.1: Comparison matrix with four SDN controllers (OpenDaylight, ONOS, Ryu, Floodlight) shown as columns and six evaluation criteria as rows

117.3.1 Quick Comparison Table

Feature	OpenDaylight	ONOS	Ryu	Floodlight
Primary Focus	Enterprise SDN	Carrier-grade telecom	Education/Research	Performance
Language	Java (OSGi)	Java	Python	Java
Complexity	High (steep learning)	Medium	Low (easiest)	Medium
Performance	200K-500K flows/sec	1M+ flows/sec	50K-100K flows/sec	300K-600K flows/sec
Scalability	1K-5K devices	10K+ devices	<1K devices	1K-3K devices
Clustering	Yes (Akka)	Yes (native)	Manual	Limited
Northbound API	REST, RESTCONF	REST, gRPC	REST (custom)	REST
GUI	DLUX web UI	ONOS web UI	Basic	Basic
Community	Large (Linux Foundation)	Large (ONF)	Active	Medium
Documentation	Extensive	Good	Excellent tutorials	Good
Learning Curve	Months	Weeks	Days	Weeks
Best IoT Use	Complex enterprise	Large-scale deployments	Prototyping/PoC	High-performance apps

117.4 OpenDaylight (ODL)

Overview: The most comprehensive open-source SDN controller with modular architecture.

117.4.1 Architecture

• Model-Driven Service Abstraction Layer (MD-SAL) for plugin ecosystem
• OSGi framework for dynamic module loading
• 50+ projects covering everything from OpenFlow to BGP

117.4.2 Strengths

• Feature-rich: Supports OpenFlow, NETCONF, BGP-LS, PCEP, and more
• Mature ecosystem: 100+ companies contributing
• Production-ready: Used by AT&T, China Mobile, Ericsson

117.4.3 Weaknesses

• Complexity: Steep learning curve (weeks to months)
• Resource-heavy: Requires 4GB+ RAM minimum
• Slower iteration: Feature releases take months

117.4.4 IoT Use Case

Enterprise campus with mixed devices (IoT sensors + traditional network gear) needing multi-protocol support.

117.4.5 Getting Started

# Download and run OpenDaylight
wget https://nexus.opendaylight.org/content/repositories/releases/...
tar -xvf distribution-karaf-*.tar.gz
cd distribution-karaf-*/bin
./karaf
# Controller runs on http://localhost:8181
# Default credentials: admin/admin

117.4.6 Resource Requirements

Component	Minimum	Recommended
RAM	4 GB	8+ GB
CPU	2 cores	4+ cores
Disk	10 GB	50+ GB
Java	OpenJDK 11+	OpenJDK 17

117.5 ONOS (Open Network Operating System)

Overview: Designed for carrier-grade scalability and high availability.

117.5.1 Architecture

• Distributed core with intent-based northbound interface
• Built-in clustering and state replication
• Optimized for large-scale deployments

117.5.2 Strengths

• Highest performance: 1M+ flow installations/second
• Best clustering: Native distributed architecture, sub-5s failover
• Intent-based: Applications express “what” not “how” (controller figures out implementation)

117.5.3 Weaknesses

• Less comprehensive: Focuses on core SDN (fewer protocols than ODL)
• Fewer tutorials: Smaller community than ODL
• Enterprise features: Some advanced features in proprietary extensions

117.5.4 IoT Use Case

Smart city with 10,000+ IoT devices requiring 99.99%+ uptime and dynamic traffic patterns.

117.5.5 Getting Started

# Download and run ONOS
wget https://repo1.maven.org/maven2/org/onosproject/onos-releases/...
tar -xzf onos-*.tar.gz
cd onos-*/bin
./onos-service start
# Access GUI at http://localhost:8181/onos/ui
# Default credentials: onos/rocks

117.5.6 Resource Requirements

Component	Minimum	Recommended
RAM	4 GB	16+ GB (cluster)
CPU	4 cores	8+ cores
Disk	10 GB	100+ GB
Java	OpenJDK 11+	OpenJDK 17

117.6 Ryu

Overview: Python-based controller focused on simplicity and education.

117.6.1 Architecture

• Component-based architecture with event-driven programming
• Minimalist design (just core SDN functions)
• Easy-to-understand codebase (~20K lines)

117.6.2 Strengths

• Easiest to learn: Python + simple API = quick prototyping
• Excellent docs: Best tutorials and examples among all controllers
• Lightweight: Runs on 512MB RAM

117.6.3 Weaknesses

• Single-threaded: Limited performance (50K flows/sec)
• No built-in HA: Must implement clustering manually
• Limited scalability: Best for <1000 devices

117.6.4 IoT Use Case

Research prototype or proof-of-concept for smart home (100-500 devices).

117.6.5 Getting Started

# Install Ryu
pip install ryu

# Run simple learning switch
ryu-manager ryu.app.simple_switch_13

# Write custom controller (just 20 lines!)
from ryu.base import app_manager
from ryu.controller import ofp_event

class SimpleController(app_manager.RyuApp):
    def __init__(self, *args, **kwargs):
        super(SimpleController, self).__init__(*args, **kwargs)

117.6.6 Resource Requirements

Component	Minimum	Recommended
RAM	512 MB	2 GB
CPU	1 core	2+ cores
Disk	1 GB	5 GB
Python	3.6+	3.9+

117.7 Floodlight

Overview: High-performance controller with focus on throughput.

117.7.1 Architecture

• Multi-threaded Java implementation
• Optimized packet processing pipeline
• RESTful API for integration

117.7.2 Strengths

• High throughput: 300K-600K flows/second
• Good performance/complexity ratio: Easier than ODL, faster than Ryu
• Active development: Big Switch Networks backing

117.7.3 Weaknesses

• Limited clustering: Not designed for large-scale distribution
• Smaller ecosystem: Fewer third-party modules than ODL
• Single-vendor focus: Less community diversity

117.7.4 IoT Use Case

Industrial IoT network requiring high packet processing rates (e.g., video surveillance with 500 cameras).

117.7.5 Getting Started

# Clone and build Floodlight
git clone https://github.com/floodlight/floodlight.git
cd floodlight
ant
java -jar target/floodlight.jar
# Access GUI at http://localhost:8080/ui/index.html

117.7.6 Resource Requirements

Component	Minimum	Recommended
RAM	2 GB	4+ GB
CPU	2 cores	4+ cores
Disk	5 GB	20 GB
Java	OpenJDK 8+	OpenJDK 11

Quick Check: Controller Characteristics

117.8 Controller Selection Guide

117.8.1 Decision Matrix

Requirement	Recommended Controller	Rationale
Learning/Education	Ryu	Python, simplest API, best tutorials
Prototype/PoC	Ryu or Floodlight	Quick setup, good performance
Enterprise deployment	OpenDaylight	Comprehensive features, multi-protocol
High availability critical	ONOS	Best clustering, carrier-grade reliability
High performance	ONOS or Floodlight	1M+ and 600K flows/sec respectively
Large scale (10K+ devices)	ONOS	Designed for scalability
Mixed network (IoT + legacy)	OpenDaylight	Supports most protocols
Cloud-native deployment	ONOS	Microservices architecture
On-premises/embedded	Ryu or Floodlight	Lightweight, lower resource usage

117.8.2 Example Selection Scenarios

1. Smart Home Startup (500 devices)

• Controller: Ryu
• Reason: Fast prototyping, Python integrates with IoT platforms (Home Assistant, OpenHAB)

2. Smart City (10,000 devices, 99.99% uptime)

• Controller: ONOS with 3-node cluster
• Reason: Scalability + high availability

3. Industrial Factory (2,000 devices, mixed protocols)

• Controller: OpenDaylight
• Reason: Needs OpenFlow + NETCONF + Modbus integration

4. Research Lab (100 devices, custom algorithms)

• Controller: Ryu
• Reason: Easy to modify, implement custom routing

117.9 Knowledge Check

Test your understanding of SDN controller characteristics.

Quiz: SDN Controller Selection

117.10 Worked Example: SDN Controller Selection for a Smart Warehouse

Scenario: A logistics company in Rotterdam operates a 50,000 m² automated warehouse with 200 AGVs (Automated Guided Vehicles), 1,500 inventory sensors (RFID readers + weight scales), 80 IP cameras, and 45 Wi-Fi access points. They are migrating from traditional networking to SDN and must choose a controller.

Requirements Analysis:

Requirement	Value	Implication
Total devices	1,825	Mid-scale (>1K rules out Ryu)
AGV rerouting latency	<50 ms (collision avoidance)	High flow install rate needed
New flows at peak (AGV path changes)	800 flows/sec (200 AGVs x 4 reroutes/sec)	Floodlight or ONOS
Protocols	OpenFlow only (greenfield)	No multi-protocol need
HA requirement	99.9% (warehouse runs 24/7)	Controller clustering mandatory
Engineering team SDN experience	1 engineer, 6 months experience	Steep learning curve is costly
Budget for controller infrastructure	EUR 15,000	Open-source preferred

Controller Scoring:

Criterion	Weight	Ryu	Floodlight	OpenDaylight	ONOS
Handles 1,825 devices	25%	1 (<1K limit)	5	5	5
800 flows/sec throughput	20%	2 (50K max, but single-threaded)	5 (600K/sec)	4 (200K/sec)	5 (1M/sec)
HA clustering	20%	1 (no native HA)	3 (manual)	4 (built-in)	5 (RAFT consensus)
Learning curve (1 engineer)	20%	5 (Python, days)	4 (Java, 2 weeks)	1 (months)	3 (weeks)
Cost (open-source + hardware)	15%	5	5	5	5
Weighted Score		2.55	4.55	3.60	4.55

Tie-Breaker: Floodlight vs ONOS

Both score 4.55. The deciding factors:

• Floodlight: Faster to learn (2 weeks vs 3-4 weeks), simpler architecture, adequate for 1,825 devices
• ONOS: Better HA (automatic RAFT failover), designed for 10K+ devices, more future-proof

Decision: ONOS – the warehouse plans to expand to 500 AGVs within 2 years, and ONOS’s native clustering provides automatic failover without custom engineering. The additional 2 weeks of learning time is a one-time cost; HA is a permanent operational benefit.

Deployment Architecture:

• 3-node ONOS cluster on 3 x Intel NUC (EUR 600 each = EUR 1,800 total)
• Each NUC: 6-core i5, 16 GB RAM, 256 GB SSD
• Controller-to-switch latency: <5 ms (all equipment in same building)
• Failover time: 1.2 sec (RAFT leader election)
• Annual operating cost: EUR 0 (ONOS is open-source, NUCs consume 25W each = EUR 197/year electricity)

Key Insight: Controller selection is driven by operational requirements, not raw performance. Ryu’s 50K flows/sec would technically handle 800 flows/sec – but its lack of HA means a single server failure stops all new AGV path updates, halting the warehouse. The “correct” controller is the one that matches your HA, scale, and team capability requirements simultaneously.

Putting Numbers to It

Controller Throughput vs. Operational Needs

A smart warehouse with 200 AGVs requires frequent path recalculations. Calculate required controller throughput:

Peak flow installation rate during shift change (200 AGVs simultaneously reroute to new zones):

• AGVs per event: 200
• Switches traversed per AGV path: average 4
• Flow rules per AGV: \(4 \times 2 = 8\) (bidirectional)
• Event duration: 30 seconds

\[R_{flow\_peak} = \frac{N_{AGVs} \times F_{rules}}{T_{duration}} = \frac{200 \times 8}{30} = 53.3 \text{ flow installs/second}\]

Controller capacity comparison:

• Ryu (single-threaded): 50,000 flows/sec → utilization = \(53.3 / 50{,}000 = 0.1\%\)
• ONOS (clustered): 1,000,000 flows/sec → utilization = \(53.3 / 1{,}000{,}000 = 0.005\%\)

Both have sufficient throughput, but ONOS provides availability: 3-node cluster survives 1 failure with \(T_{failover} = 1.2\) seconds. Warehouse downtime cost = $5,000/minute. Single Ryu failure lasting 10 minutes = $50,000 revenue loss.

TCO over 5 years: Ryu infrastructure = $3,000 (single VM). ONOS infrastructure = $5,400 (3 × $150/month VMs × 12 months × 5 years). Expected downtime cost difference: \(5 \times 10 \text{ min/year} \times \$5{,}000/\text{min} = \$250{,}000\) for Ryu vs. \(0.5 \times 1 \text{ min/year} \times \$5{,}000 = \$2{,}500\) for ONOS. ONOS saves $247,500 over 5 years despite higher infrastructure cost.

Interactive: Controller Throughput Estimator

Estimate required flow installation throughput for your IoT deployment.

viewof numAGVs = Inputs.range([10, 1000], {value: 200, step: 10, label: "Mobile devices (AGVs, robots)"})

viewof reroutesPerSec = Inputs.range([1, 20], {value: 4, step: 1, label: "Path changes per device per second"})

viewof switchesPerPath = Inputs.range([2, 10], {value: 4, step: 1, label: "Average switches per path"})

viewof eventDuration = Inputs.range([5, 120], {value: 30, step: 5, label: "Peak event duration (seconds)"})

flowRulesPerDevice = switchesPerPath * 2
peakFlowRate = (numAGVs * flowRulesPerDevice) / eventDuration
ryuUtil = (peakFlowRate / 50000) * 100
floodlightUtil = (peakFlowRate / 600000) * 100
onosUtil = (peakFlowRate / 1000000) * 100

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;">
<p><strong>Peak flow installation rate:</strong> ${peakFlowRate.toFixed(1)} flows/second</p>
<p><strong>Controller utilization:</strong></p>
<ul style="margin: 0.25rem 0;">
<li>Ryu (50K/s): ${ryuUtil.toFixed(3)}% ${ryuUtil > 80 ? "-- OVERLOADED" : ""}</li>
<li>Floodlight (600K/s): ${floodlightUtil.toFixed(4)}%</li>
<li>ONOS (1M/s): ${onosUtil.toFixed(4)}%</li>
</ul>
<p style="margin-top: 0.5rem; font-size: 0.9em; color: #7F8C8D;">All controllers have sufficient throughput. Choose based on HA requirements and team expertise, not raw performance.</p>
</div>`

117.11 Concept Relationships

Concept	Relationship to SDN Controllers	Importance
Flow Throughput	Controller capacity determines max flow installations per second; limits network scale	Critical - bottleneck for large IoT deployments
Clustering Support	High availability mechanism; enables automatic failover during controller failures	High - production requirement for 99.99% uptime
Programming Language	Determines development speed and ecosystem integration; Python vs Java tradeoff	Medium - impacts team productivity
Learning Curve	Time investment required to become proficient; days (Ryu) to months (OpenDaylight)	High - affects time-to-deployment
Scalability Limits	Maximum devices/switches manageable; Ryu <1K, ONOS 10K+	Critical - determines deployment size limits

Match the Controller to Its Strength

Order the Controller Selection Process

Key Concepts

• SDN (Software-Defined Networking): An architectural approach separating the network control plane (routing decisions) from the data plane (packet forwarding), centralizing control in a software controller for programmable network management
• Control Plane: The network intelligence layer making routing and forwarding decisions, centralized in an SDN controller rather than distributed across individual switches as in traditional networking
• Data Plane: The network forwarding layer physically moving packets based on rules installed by the control plane — in SDN, this is the switch hardware executing OpenFlow flow table entries
• OpenFlow: The foundational SDN protocol enabling communication between an SDN controller and network switches, allowing the controller to install, modify, and delete flow table entries that govern packet forwarding
• SDN Controller: The centralized network operating system providing a global view of the network topology and programming switch forwarding behavior through southbound APIs (OpenFlow) and exposing northbound APIs to applications
• OpenDaylight (ODL): A Linux Foundation open-source SDN controller platform with modular architecture, YANG-based data modeling, and support for OpenFlow, NETCONF, OVSDB, and BGP southbound protocols
• ONOS: Open Network Operating System — a distributed, high-availability SDN controller designed for carrier-grade networks with intent-based northbound API and built-in multi-controller clustering
• Floodlight: A lightweight open-source OpenFlow controller written in Java, suitable for academic research and small deployments due to its simplicity and REST API accessibility
• Intent-Based Networking: An SDN abstraction where applications specify desired network outcomes (low-latency path between A and B) rather than specific forwarding rules, with the controller translating intents to flow rules

Common Pitfalls

1. Using a Research Controller in Production

Deploying Floodlight or POX (research controllers) for production IoT networks. Research controllers lack enterprise features: no clustering, limited scalability, no production-grade authentication, and minimal vendor support. Use ONOS or OpenDaylight for production workloads.

2. Not Benchmarking Controller Flow Installation Rate

Deploying an SDN controller without measuring its flow installation throughput (flows/second). An ONOS controller cluster can install 100,000+ flows/second; a single Floodlight instance may handle 5,000/second. IoT networks with burst device connectivity events can saturate under-dimensioned controllers.

3. Treating All Controllers as Interchangeable

Assuming you can switch from OpenDaylight to ONOS at any time without architectural changes. Controllers differ in APIs, data models, clustering mechanisms, and ecosystem integrations. Changing controllers requires significant rework — choose carefully based on long-term requirements.

4. Ignoring Controller Community and Support Lifecycle

Selecting an SDN controller based solely on current features without considering community health and support lifecycle. Some academic controllers are unmaintained. Verify active community contributions, recent releases, and vendor support availability before production commitment.

Label the Diagram

💻 Code Challenge

117.12 Summary

Key Takeaways:

1. Four major controllers serve different needs: OpenDaylight (enterprise complexity), ONOS (carrier-grade scale), Ryu (education/prototyping), Floodlight (performance)
2. Performance varies significantly: From Ryu’s 50K flows/sec to ONOS’s 1M+ flows/sec
3. Scalability matters for IoT: ONOS handles 10K+ devices; Ryu limited to <1K
4. Language impacts adoption: Python (Ryu) for rapid prototyping; Java (others) for production
5. Learning curve investment: Days (Ryu) to months (OpenDaylight) depending on controller complexity

Controller Selection Cheat Sheet:

Need	Choose	Why
Learning SDN	Ryu	Simple, Python, great tutorials
Production IoT	ONOS	Scale, HA, performance
Multi-protocol	OpenDaylight	Most comprehensive
Fast prototyping	Ryu/Floodlight	Quick setup, good docs

117.13 See Also

• SDN Controller Architecture - Internal components and message flow within controllers
• SDN APIs and Clustering - Northbound/southbound APIs and high availability setup
• SDN Controller Basics - Overview of all controller topics and comparison
• SDN Analytics and Implementations - Advanced use cases and deployment patterns
• Software Defined Networking - SDN fundamentals and architectural principles

For Kids: Meet the Sensor Squad!

Choosing an SDN controller is like choosing the right vehicle for a road trip!

117.13.1 The Sensor Squad Adventure: The Controller Showdown

The Sensor Squad needed a new brain for their growing network, and four candidates showed up for the job interview!

First came Ollie the OpenDaylight – a huge toolbox on wheels. “I can do EVERYTHING!” Ollie said. “I speak every language, I have every gadget, and I work for the biggest companies!” But Max the Microcontroller whispered, “Ollie is amazing, but it takes months to learn all those tools!”

Next was Oscar the ONOS. “I’m built for BIG jobs,” Oscar announced. “I can manage 10,000 sensors at once, and if I fall down, my twin brother takes over in less than a second!” Sammy the Sensor was impressed. “Perfect for our whole smart city!”

Then Ryu the Python Snake slithered in. “I’m simple and friendly! You can learn to use me in just a few days, and I fit in tiny spaces!” Lila the LED loved Ryu. “Perfect for our school project!”

Finally, Flo the Floodlight zoomed in like a race car. “I’m FAST! I can process 600,000 instructions every second!” Bella the Battery nodded. “Great for our video cameras that send lots of data!”

The Sensor Squad realized: there’s no single “best” controller – you pick the one that fits YOUR mission!

117.13.2 Key Words for Kids

Word	What It Means
SDN Controller	The “brain” software that manages all network switches from one place
Scalability	How many devices the controller can manage (100 vs 10,000)
Learning Curve	How long it takes to learn to use something (days vs months)

117.14 What’s Next

If you want to…	Read this
Study SDN controller architecture details	SDN Controller Architecture
Learn about SDN APIs and clustering	SDN APIs and High Availability
Explore SDN OpenFlow protocol	OpenFlow Protocol
Review SDN fundamentals	SDN Fundamentals and OpenFlow
Study SDN production best practices	SDN Production Best Practices