The Software Defined Networking (SDN) technology landscape has evolved quickly over the last two years. Due to the developing nature of the SDN controller space, there is a plethora of software available for use.
The core concept of Software Defined Networking is separating the intelligence and control (e.g. routing) from forwarding elements (i.e. switches) and concentrating the control of the network management and operation in a logically centralised component – an SDN Controller. We’ve discussed this topic in more detail here.
This comprehensive guide compares the maturity of the most popular Open Source SDN controllers in industry and academia including: the Open Network Operating System (ONOS), OpenDayLight (ODL), OpenKilda, Ryu, Faucet and Tungsten Fabric. Our team of Solutionauts have used Software Defined Networking controllers for many different use cases, including Traffic Engineering, Segment Routing, Integration and Automated Traffic Engineering.
Controller Comparison Summary
Based on our evaluation across 13 weighted criteria, we’ve scored each SDN controller to help you identify the best fit for your network infrastructure and requirements. Each design has different use cases as usage depends not only on the capability matrix, but also on the cultural fit of the organisation and the project.
| Criterion | Weight | ONOS | ODL | OK | Ryu | Faucet |
| OpenFlow Support | 20.0 | 20.0 | 19.0 | 12.0 | 20.0 | 20.0 |
| Northbound API support | 20.0 | 20.0 | 20.0 | 12.0 | 16.0 | 8.0 |
| Southbound API support | 10.0 | 10.0 | 10.0 | 6.0 | 8.0 | 8.0 |
| Programming Language | 5.0 | 4.0 | 4.0 | 4.5 | 4.5 | 4.5 |
| Core Components features / services | 5.0 | 4.5 | 4.5 | 3.5 | 2.0 | 3.5 |
| Native Clustering Capabilities | 10.0 | 9.0 | 7.0 | 10.0 | 2.0 | 5.0 |
| Typical Architecture | 3.0 | 2.7 | 2.4 | 2.7 | 2.4 | 2.7 |
| Horizontal Scalability | 5.0 | 3.5 | 3.0 | 4.5 | 1.0 | 4.0 |
| Vertical Scalability | 5.0 | 3.5 | 3.0 | 5.0 | 4.5 | 0.5 |
| Extensibility | 2.0 | 1.8 | 1.6 | 1.8 | 1.8 | 1.6 |
| Community Size & Partnerships | 5.0 | 4.5 | 4.5 | 1.0 | 4.5 | 3.5 |
| Resilience and Fault Tolerance | 5.0 | 4.0 | 3.0 | 4.5 | 4.0 | 4.5 |
| Operations Support | 5.0 | 4.5 | 2.5 | 4.0 | 2.5 | 3.5 |
| Weighted Score | 100 | 92 | 84.5 | 71.5 | 73.2 | 69.3 |
Product Rating
| Rank | Product | Score |
| 1 | ONOS | 92.0% |
| 2 | ODL | 84.5% |
| 3 | Ryu | 73.2% |
| 4 | OK | 71.5% |
| 5 | Faucet | 69.3% |
Understanding Our Evaluation Criteria
We evaluated each SDN controller against the following assessment criteria to provide a comprehensive comparison that addresses real-world deployment considerations.
Architecture
As with most platforms, there are trade-offs to be considered when comparing a centralised, tightly coupled control plane to a decentralised, scalable and loosely coupled alternative SDN controller.
Centralised architectures such as ONOS and ODL tend to be easier to maintain and confer lower latency between the tightly coupled southbound API, PCE and Northbound APIs. However, as the scale increases, centralised controllers can become a bottleneck. In an SD-WAN context this can increase control plane latency but can be mitigated in a distributed architecture.
Distributed architectures such as OpenKilda and Faucet are generally more complex to maintain and deploy but can allow the platform to scale more effectively. By decoupling the processing of PCE, Telemetry and Southbound interface traffic, each function can be scaled independently to avoid performance bottlenecks. Additionally, specialised tools to handle big datasets, time series databases or path computation at scale become viable without adversely impacting southbound protocol performance.
Ryu is different to the other options, although having a core set of programs that are run as a ‘platform’, it is better thought of as a toolbox, with which SDN controller functionality can be built.
Modularity and Extensibility
The modularity of each controller is governed by the design focus and programming languages. Platforms such as ONOS and ODL have built-in mechanisms for connecting code modules, at the expense of centralising processing to each controller. These two Java-based controllers take advantage of OSGi containers for loading bundles at runtime, allowing a very flexible approach to adding functionality.
Python based controllers such as Ryu provide a well-defined API for developers to change the way components are managed and configured.
Adding functionality to Faucet and OpenKilda is achieved through modifying the systems that make use of their northbound interfaces, such as the Apache Storm cluster or equivalent. This provides the added flexibility of using different tools and languages depending on the problem being solved. Additionally, increasing the complexity of northbound interactions does not negatively impact on the SDN directly.
Scalability
Of the options being considered, only ONOS and ODL contain internal functionality for maintaining a cluster. Each of these platforms is backed by a distributed datastore that shares the current SDN state and allows for controllers to failover in the event of a cluster partition. As new releases of each of the controllers emerge, this functionality looks to be evolving.
OpenKilda approaches cluster scalability in a modular way. While Floodlight is used as a southbound interface to the switch infrastructure, responsibility for PCE and telemetry processing is pushed northward into a completely separate Apache Storm based cluster. Each Floodlight instance is idempotent, with no requirement to share state. The Apache Storm cluster is by design horizontally scalable and allows throughput to be increased by adding nodes.
Both Ryu and Faucet contain no intrinsic clustering capability and require external tools such as Zookeeper to distribute a desired state. With both of these platforms, extra instances of the controller can be started independently as long as the backing configuration remains identical. PCE functionality for these controllers could be pushed down to the instance in the form of modules, or implemented in a similar manner to OpenKilda, backed by a processing cluster of choice.
As the scale of the SDN grows, it becomes untenable for a single localised cluster to handle the load from every switch on the network. Leaving aside geographic distribution of the controllers, breaking the network into smaller logical islands decreases the need for a single southward looking cluster to be massively scalable. With this design, coordination between the islands becomes critical and while a centralised view of the network is still required, the absence of PCE and telemetry processing should not affect data plane stability once flows are configured.
Ryu, Faucet, ODL and ONOS all look to scale in this way by including native BGP routing capabilities to coordinate traffic flows between the SDN islands. Universal PCE and telemetry processing will need to be developed for each of these cases with OpenKilda providing a working reference architecture for achieving this. Due to the state of the documentation for OpenKilda, the BGP will need to be developed.
Interfaces
Considering future compatibility requirements for southbound control, ONOS, ODL and Ryu include protocols beyond just OpenFlow. P4, Netconf and OF-Config could enable additional switch hardware options moving forward should it be required.
The northbound API turns out to be one of the key differentiators between the platforms on offer. ONOS and ODL offer the largest set of northbound interfaces with gRPC and RESTful APIs (among others) available, making them the easiest to integrate. Ryu and OpenKilda offer limited RESTful compared to ONOS and ODL. Faucet takes a completely different approach to applying changes, relying on configuration files to track intended system state instead of instantaneous API calls. This approach will require external tools for dynamically applying configuration but does open the SDN to administration by well-understood CI/CD pipelines and testing apparatus.
Telemetry
One of the primary problems with maintaining an SDN is extracting and using any available telemetry to infer system state and help remediate issues. On this front, ODL lacks functionality, with telemetry still being an experimental module in the latest upstream version. ONOS has modules available to allow telemetry to be used through Grafana or InfluxDB.
Faucet can export telemetry into Influxdb, Prometheus or flat text log files. While Prometheus saves data locally, it can also be federated, allowing centralised event aggregation and processing, while maintaining a local cache to handle upstream processing outages and maintenance.
OpenKilda uses Storm which provides a computation system that can be used for real-time analytics. Storm passes the time-series data to OpenTSDB for storing and analysing. Neo4j, a graph analysis and visualisation platform and provided the PCE functionality initially.
Ryu doesn’t provide any telemetry functionality. This needs to be provide via external tools.
Resilience and Fault Tolerance
The ONOS and ODL platforms implement native clustering as part of their respective offerings. ONOS and ODL provide fault tolerance in the system with an odd number of SDN controllers. In the event of master node failure, a new leader would be selected to take the control of the network. The mechanism of choosing a leader is slightly different in these two controllers, while ONOS focuses on eventually consistent ODL focuses on high availability.
The remaining controllers (OpenKilda, Ryu and Faucet) have no inbuilt clustering mechanism, instead relying on external tools to maintain availability. This simplifies the architecture of the controllers and releases them from the overhead of maintaining distributed databases for state information. High availability is achieved by running multiple, identically configured instances, or a single instance controlled by an external framework that detects and restarts failed nodes.
For Ryu, fault tolerance can be provided by Zookeeper for monitoring the controllers in order to detect controller’s failure and sharding state between cluster members. For Faucet in particular, which is designed to sit in a distributed, shared SDN and be controlled by static configuration files, restarting a controller is a quick, stable exercise that has no reliance on upstream infrastructure once the configuration is written.
Programming Language
ONOS, ODL and OpenKilda are written in Java, for which development resources are abundant in the market, with good supporting documentation and libraries available. While using Java should not be seen as a negative, Java processes can tend to be heavyweight and require resource and configuration management to keep them lean and responsive.
Ryu and Faucet are written in Python, a well-supported language and has an active community developing the framework. The documentation is concise and technical, aimed at developers to maximise the utility of the system. Python is not a fast language and has inherent limitations due to both the dynamic type representations being used and limited multi-threaded capabilities (when compared with Java, Golang or C++).
Community
Both ODL and ONOS benefit from large developer and user communities under the Linux Foundation Networking banner. Many large international players are involved in the development and governance of these projects, which could add to the longevity and security over time. A possible downside is, as with any large project, there are many voices trying to be heard and stability can be impacted by feature velocity. This has occurred with similar projects such as OpenStack in the immediate past.
OpenKilda is a small but active community which can limit the supportability, velocity and features of the platform. OpenKilda needs your support – chat with us to get involved.
Between these two extremes are RYU and Faucet. Both are well supported, targeted controllers. Due to the emerging nature of the field, both options look to have a bright future, with a simpler, streamlined approach to change submission and testing.
Detailed SDN Controller Reviews
Each SDN controller has unique strengths and ideal use cases. Below are our detailed technical evaluations of each platform, including architecture deep-dives, scalability analysis, and real-world implementation considerations.
Open Network Operating System (ONOS)
Quick Summary:
- Score: 92.0%
- Best For: Communication Service Providers, SD-WAN deployments
- Architecture: Distributed, three-tier
- Key Strength: Extensive API support and production-ready scalability
- Programming Language: Java
- Community: Linux Foundation Networking
ONOS is designed to be distributed, stable and scalable with a focus on Service Provider networks. The Open Network Operating System is the only SDN controller platform that supports the transition from legacy “brown field” networks to SDN “green field” networks. This enables exciting new capabilities, and disruptive deployment and operational cost points for network operators.
Read the complete ONOS deep-dive →
Key highlights:
- Supports extensive list of northbound and southbound APIs
- YANG model support enables vendor-agnostic application development
- High availability and resilience with native clustering
- Modularity allows easy customization and maintenance
- Intent-based framework simplifies flow management
OpenDayLight (ODL)
Quick Summary:
- Score: 84.5%
- Best For: Cloud integration, SD-LAN, telco environments with OpenStack/ONAP
- Architecture: Modular, three-layer with OSGi
- Key Strength: Largest community support, extensive integration options
- Programming Language: Java
- Community: Linux Foundation Networking (largest community)
OpenDaylight is a modular open platform for customising and automating networks of any size and scale. The OpenDaylight Project arose out of the SDN movement, with a clear focus on network programmability. It was designed from the outset as a foundation for commercial solutions that address a variety of use cases in existing network environments.
Read the complete OpenDayLight deep-dive →
Key highlights:
- Most pervasive open-source SDN controller in market
- Extensive northbound and southbound API support
- Integrated into OpenStack, Kubernetes, OPNFV, and ONAP
- Model-based approach with OSGi for runtime modularity
- Strong multi-site deployment capabilities
OpenKilda
Quick Summary:
- Score: 71.5%
- Best For: Global distributed networks, production telemetry at scale
- Architecture: Distributed, decentralized with Apache Storm
- Key Strength: End-to-end flow telemetry, proven at global scale
- Programming Language: Java
- Community: Small but active (Telstra-developed)
OpenKilda is a Telstra developed OpenFlow based SDN controller currently being used in production to control the large Pacnet infrastructure. It has been shown to be successful in a distributed production environment. Designed to solve the problem of implementing a distributed SDN control plane with a network that spans the Globe, OpenKilda solves the problem of latency while providing a scalable SDN control & data-plane and end-to-end flow telemetry.
Read the complete OpenKilda deep-dive →
Key highlights:
- Production-proven in Telstra’s global network
- Distributed architecture with independent horizontal scaling
- Built-in telemetry processing with OpenTSDB and Neo4j
- Modular cluster scalability with Apache Storm
- Note: BGP/MPLS support may need development for some use cases
Ryu
Quick Summary:
- Score: 73.2%
- Best For: Academic research, custom SDN development, OpenStack integration
- Architecture: Component-based framework (toolbox approach)
- Key Strength: Complete flexibility for custom solutions
- Programming Language: Python
- Community: Active development community
Ryu is a very different proposition to the other options being put forward. Although boasting a core set of programs that are run as a ‘platform’, Ryu is better thought of as a toolbox, with which SDN controller functionality can be built. Ryu is a component-based software defined networking framework that provides software components with well defined API that make it easy for developers to create new network management and control applications.
Read the complete Ryu deep-dive →
- Toolbox approach offers complete development flexibility
- Multiple southbound protocols (OpenFlow, NETCONF, OF-Config, P4)
- Popular in academic research environments
- Used in OpenStack as network controller
- Requires development expertise but allows custom solutions
Faucet
Quick Summary:
- Score: 69.3%
- Best For: CI/CD pipelines, lightweight deployments, container environments
- Architecture: Lightweight, distributed with YAML configuration
- Key Strength: Configuration-as-code approach, simple deployment
- Programming Language: Python
- Community: Active and well-supported
Built on top of Ryu, Faucet is a lightweight SDN Controller adding a critical northbound function for operations teams. Faucet is a compact open source OpenFlow controller, which enables network operators to run their networks the same way they do server clusters. Faucet moves network control functions (like routing protocols, neighbor discovery, and switching algorithms) to vendor independent server-based software, where those functions are easy to manage, test, and extend with modern systems management best practices and tools.
Read the complete Faucet deep-dive →
Key highlights:
- YAML configuration enables CI/CD integration
- Lightweight and easily containerized
- Built-in telemetry with Prometheus/InfluxDB
- Ideal for distributed, shared SDN environments
- Quick, stable restart with no upstream dependencies
Choosing the Right SDN Controller for Your Network
Selecting the appropriate SDN controller depends on your specific use case, existing infrastructure, team expertise, and organizational requirements. Here are our recommendations based on common scenarios.
By Use Case
Communication Service Providers (CSP)
- Recommended: ONOS (1st choice), OpenDayLight (2nd choice)
- Why: Extensive API support, production-ready scalability, support for legacy network transition, large vendor ecosystem
Cloud & Virtualization Environments
- Recommended: OpenDayLight, Tungsten Fabric
- Why: Native integration with OpenStack, Kubernetes, ONAP; proven in telco cloud deployments
Global/Distributed Networks
- Recommended: OpenKilda, Faucet
- Why: Distributed architecture handles global latency, independent scaling of components
Development & Research
- Recommended: Ryu, Faucet
- Why: Flexibility for custom development, active academic communities, lower barrier to entry
CI/CD & DevOps Environments
- Recommended: Faucet
- Why: YAML-based configuration, lightweight deployment, version control friendly
By Technical Requirements
Need Native Clustering? → ONOS or OpenDayLight
Need Extensive Telemetry? → OpenKilda or Faucet
Need Maximum API Flexibility? → ONOS or OpenDayLight
Need Lightweight Deployment? → Faucet or Ryu
Need Production Support? → ONOS or OpenDayLight (largest communities)
BONUS: Tungsten Fabric for Cloud-Native Networks
For organizations moving toward cloud-native infrastructure, Tungsten Fabric offers SDN capabilities specifically designed for cloud-grade networks.
With the current IT market, organisations are moving towards migrating their old infrastructure to the Cloud and cloudifying every part of their infrastructure. Tungsten Fabric can be a suitable choice for cloud builders and cloud-native platform engineers. It has been first associated with Juniper but now is under the Linux Foundation umbrella.
Key Features:
- Microservices-based architecture with Docker containers
- Integration with private/public clouds, Kubernetes, VMs, and bare metal
- Horizontal scalability of individual service roles
- Built-in telemetry with Kafka and Cassandra
- Supports C++, Python, Go, Node.js
Best For: Cloud builders, cloud-native platform engineers, multi-cloud deployments
Deep Dive Into Tungsten Fabric
Next Steps: Implementation Support
Ready to implement an SDN controller solution? Our team of Solutionauts has extensive experience deploying and managing SDN controllers for Traffic Engineering, Segment Routing, Integration and Automated Traffic Engineering across Communication Service Providers, government agencies, and enterprise networks.
Contact us to discuss:
- SDN controller selection and evaluation
- Architecture design and implementation
- Migration from legacy networks
- Integration with existing infrastructure
- Training and ongoing support
- Architecture
- Modularity and Extensibility
- Scalability
- Cluster Scalability
- Architectural Scalability
- Interfaces
- Northbound API support
- Southbound API support
- Telemetry
- Resilience and Fault Tolerance
- Programming Language
- Community
It is important to understand the motivations behind the available platforms. Each design has different use cases as usage depends not only on the capability matrix, but also on the cultural fit of the organisation and the project.
Our team of Solutionauts have used Software Defined Networking controllers for many different use cases, including: Traffic Engineering, Segment Routing, Integration and Automated Traffic Engineering.
Over the next few days, we will be comparing, rating and evaluating each of the most popular Open Source SDN controllers in use today. This comparison will be useful for organisations to help them select the right SDN controller for their platform which match their network design and requirements.
