Tungsten Fabric (TF) represents a fundamentally different approach to SDN—rather than controlling physical switches via OpenFlow, it provides cloud-native overlay networking for virtualized and containerized workloads. Originally developed by Juniper Networks and now part of the Linux Foundation Networking umbrella, Tungsten Fabric has become the go-to SDN solution for organizations building private clouds, Kubernetes platforms, and multi-cloud architectures where software-defined overlays matter more than physical infrastructure control.

This is part of our comprehensive SDN Controller Comparison Guide, where we evaluate leading open-source SDN controllers—though Tungsten Fabric serves a distinct use case compared to OpenFlow-based controllers like ONOS, ODL, and Faucet.

Tungsten Fabric at a Glance

What Tungsten Fabric Does Best:

• Overlay networking for VMs and containers
• Multi-tenant isolation and security
• OpenStack and Kubernetes native integration
• Service Function Chaining for NFV
• Multi-cloud consistent networking
• Microservices-based scalability and resilience

Architecture Deep Dive

Tungsten Fabrics architecture is composed of two major software components: TF vRouter and TF Controller.

Modularity and Extensibility

TF microservice-based architecture allows developing particular services based on the performance requirement and increasing load. Also, microservices by nature are modular which makes the maintenance and extensibility of the platform easy whilst isolating the failure of services from each other.

Scalability

Interfaces

Telemetry

Analytics nodes extract usable telemetry information form infrastructure. The data can then be normalised to the common format and the output is sent via the Kafka service into a Cassandra database. This data can be used in a multitude of ways operationally, from problem solving to capacity planning. Redis uses the data for generating graphs and running queries. The Redis pod is deployed between the analytics pod and the Web UI pod.

Resilience and Fault Tolerance

The modular architecture of Tungsten Fabric makes it resilient against failure, with typically several controllers/pods running on several servers for high availability. Also, the failure of a service is isolated, so it does not affect the whole system. The API and Web GUI services are accessed through a load balancer. The load balancer can allow pods to be in different subnets.

Programming Language

TF supports C++, Python, Go, Node.js.

Community

TF was first associated with Juniper but is now supported under the Linux Foundation Networking umbrella and boasts a large developer and user community.

Conclusion

SDN Controller Comparisons:

Faucet represents the convergence of modern DevOps practices with SDN—a lightweight, YAML-configured controller that treats network infrastructure like server clusters. With a score of 69.3% in our comprehensive evaluation, Faucet’s configuration-as-code approach and container-friendly architecture make it ideal for organizations embracing CI/CD pipelines, GitOps workflows, and infrastructure automation at scale.

This is part of our comprehensive SDN Controller Comparison Guide, where we evaluate 6 leading open-source controllers across 13 technical criteria.

Faucet at a Glance

What Faucet Does Best:

• YAML-based configuration (version control friendly)
• Lightweight and containerized deployment
• CI/CD and GitOps integration
• Built-in telemetry (Prometheus/InfluxDB)
• Production-ready despite simplicity

Architecture Deep Dive

As shown in the figure below, architecturally, each Faucet instance has two connections to the underlying switches. One for control and configuration updates, the other (Gauge) is a read-only connection specifically for gathering, collating and transmitting state information for processing elsewhere using Influxdb or Prometheus.

Modularity and Extensibility

Python based controllers provide a well-defined API for developers to change the way components are managed and configured.

Adding functionality to Faucet is achieved through modifying the systems that make use of its Northbound interfaces. 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 the SDN directly.

Scalability

Faucet is designed to be deployed at scale such that each instance is close to the subset of switches under its control. Each instance of Faucet is self-contained and can be deployed directly to server hardware or through containers, moving the administration back into well understood areas of automation.

Due to the lightweight nature of the code and the smaller control space for each instance, no clustering is required – each instance is completely idempotent and concerns itself with only what it is configured to control.

Interfaces

Telemetry

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.

Resilience and Fault Tolerance

Faucet has no inbuilt clustering mechanism, instead relying on external tools to maintain availability. 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 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

Faucet is written in Python.

Community

Faucet has an active community developing the framework and it is well supported.

Conclusion

SDN Controller Comparisons:

OpenDayLight (ODL) stands as the most pervasive open-source SDN controller platform, with a score of 84.5% in our comprehensive evaluation and the largest community support in the market. Designed from the outset as a foundation for commercial solutions, ODL excels in cloud integration scenarios, particularly with OpenStack, Kubernetes, OPNFV, and ONAP—making it the de facto choice for telco cloud and NFV environments.

This is part of our comprehensive SDN Controller Comparison Guide, where we evaluate 6 leading open-source controllers across 13 technical criteria.

OpenDayLight at a Glance

What OpenDayLight Does Best:

• Largest open-source SDN community and ecosystem
• Native integration with cloud platforms and orchestrators
• Most extensive plugin and project ecosystem
• Model-driven architecture with YANG support
• Production-proven in telco NFV deployments

Architecture Deep Dive

ODL consists of 3 layers:

Modularity and Extensibility

Built-in mechanisms provided by ODL simplify the connection of code modules. The controller takes advantage of OSGi containers for loading bundles at runtime, allowing a very flexible approach to adding functionality.

Scalability

ODL uses a model-based approach, which implies a global, in-memory view of the network is required to perform logic calculations. ODL’s latest release further advances the platform’s scalability and robustness, with new capabilities supporting multi-site deployments for geographic reach, application performance and fault tolerance.

Interfaces

Telemetry

At a project level, ODL has limited telemetry related functionality. With the latest development release, there are moves toward providing northbound telemetry feeds, but they are in early design and not likely to be ready for production in the short term.

Resilience and Fault Tolerance

ODL fault tolerance mechanism is similar to ONOS, with an odd number of SDN controllers required to provide fault tolerance in the system. 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 controllers – while ONOS focuses on eventually consistent, ODL focuses on high availability.

Programming Language

From a language perspective, ODL is written in Java.

Community

ODL is the second of the SDN controllers under the Linux Foundation Networking umbrella. This project has the largest community support of all open source SDN controllers in the market, with several big-name companies actively involved with development.

Conclusion

SDN Controller Comparisons:

The Open Network Operating System (ONOS) consistently ranks as the top-rated open-source SDN controller for Communication Service Provider networks. With a score of 92% in our comprehensive evaluation, ONOS excels in API extensibility, production-ready scalability, and the unique ability to support transitions from legacy “brown field” networks to SDN “green field” deployments.

This is part of our comprehensive SDN Controller Comparison Guide, where we evaluate 6 leading open-source controllers across 13 technical criteria.

ONOS at a Glance

What ONOS Does Best:

• Extensive southbound and northbound API support
• Intent-based networking framework
• Production-grade horizontal scalability
• Geographic redundancy for SD-WANs
• Native BGP routing for multi-site coordination

Architecture Deep Dive

ONOS is designed as a three-tier architecture as follows:

Modularity and Extensibility

ONOS has built-in mechanisms for connecting/disconnecting components while the controller is running. This allows a very flexible approach to adding functionality to the controller.

Scalability

ONOS is designed specifically to horizontally scale for performance and geo-redundancy across small regions.

Interfaces

Telemetry

Telemetry feeds are available through pluggable modules that come with the software, with Influx DB and Grafana plug-ins included in the latest release.

Resilience and Fault Tolerance

ONOS has a very simple administration mechanism for clusters with native commands for adding and removing members.

The Open Network Operating System provides 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.

Programming Language

ONOS is written in Java.

Community

The Open Network Operating System is supported under the Linux Foundation Networking umbrella and boasts a large developer and user community.

Conclusion

SDN Controller Series Guide:

Ryu (pronounced “ree-yooh,” meaning “flow” in Japanese) represents a fundamentally different approach to SDN controllers—rather than a complete platform, it’s a component-based framework that provides building blocks for creating custom SDN solutions. With a score of 73.2% in our comprehensive evaluation, Ryu’s Python-based architecture and well-defined APIs make it the preferred choice for academic research, rapid prototyping, and developers who need complete flexibility to build exactly the SDN controller they envision.

This is part of our comprehensive SDN Controller Comparison Guide, where we evaluate 6 leading open-source controllers across 13 technical criteria.

Ryu at a Glance

What Ryu Does Best:

• Component-based framework for building custom controllers
• Well-defined Python APIs for rapid development
• Popular in academic research and education
• OpenStack Neutron integration (historical significance)
• Low barrier to entry for Python developers

Understanding Ryu: Framework vs. Platform 

The Fundamental Difference:

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. It provides software components with well defined API that make it easy for developers to create new network management and control applications. Ryu means “flow” in Japanese and is pronounced “ree-yooh”.

Platform vs. Framework:

What Ryu Provides:

Core Components:

• OpenFlow protocol library (1.0 – 1.5)
• Event-driven application framework
• Network topology discovery
• Basic switching applications (as examples)
• NETCONF/OF-Config libraries
• REST API framework
• Packet parsing libraries

What You Build:

• Custom routing algorithms
• Specific network applications
• High availability mechanisms
• Telemetry and monitoring
• Integration with other systems
• Business logic for your network

The Toolbox Metaphor:

Think of Ryu like a woodworking toolbox:

• Saw (OpenFlow library): Tool to interact with switches
• Hammer (Event framework): Tool to respond to network events
• Measuring tape (Topology discovery): Tool to understand network structure
• Sandpaper (Packet libraries): Tool to process packets

But Ryu doesn’t tell you what to build. You decide whether you’re building a simple birdhouse (learning switch) or a complex cabinet (production router).

Architecture Deep Dive

A Ryu SDN controller composes of these components:

Modularity and Extensibility

Ryu is structured differently from other solutions in that it provides simple supporting infrastructure that users of the platform must write code to utilise as desired. While this requires development expertise, it also allows complete flexibility of the SDN solution.

Scalability

Ryu does not have an inherent clustering ability and requires external tools to share the network state and allow failover between cluster members.

Interfaces

Telemetry

Ryu doesn’t provide any telemetry functionality. This needs to be provided via external tools.

Resilience and Fault Tolerance

Ryu has no inbuilt clustering mechanism, instead relying on external tools to maintain availability. 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.

Fault tolerance can be provided by Zookeeper for monitoring the controllers in order to detect controller’s failure and sharding state between cluster members.

Programming Language

Ryu is written in Python.

Community

An active community developing the framework, it is a well supported and targeted controller.

Conclusion

SDN Controller Comparisons:

OpenKilda is a production-proven SDN controller developed by Telstra to solve the unique challenges of managing a globally distributed network spanning multiple continents. With a score of 71.5% in our comprehensive evaluation, OpenKilda’s distributed architecture and built-in telemetry capabilities make it uniquely suited for networks where latency, geographic distribution, and operational visibility are critical concerns.

This is part of our comprehensive SDN Controller Comparison Guide, where we evaluate 6 leading open-source controllers across 13 technical criteria.

OpenKilda at a Glance 

What OpenKilda Does Best:

• Distributed control plane for global networks
• Built-in end-to-end telemetry and monitoring
• Independent horizontal scaling of components
• Production-proven at scale
• Solves latency challenges in geographically distributed networks

The OpenKilda Story: Built for Global Scale

Why OpenKilda Exists:

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.

The Global Network Challenge:

Traditional centralized SDN controllers face critical limitations when managing networks that span continents:

Latency Issues:

• Centralized controller in one region creates latency for distant switches
• Flow setup times increase with geographic distance
• Network convergence slows in distributed topologies
• Real-time decision-making becomes impractical

Scale Bottlenecks:

• Single controller cluster can’t scale indefinitely
• Processing intensive operations (PCE, telemetry) impact control plane
• Coordination overhead increases exponentially with cluster size

Operational Visibility:

• Extracting meaningful telemetry from global infrastructure
• Correlating events across time zones and regions
• Capacity planning for intercontinental links
• Troubleshooting multi-region issues

Telstra’s Solution:

OpenKilda was purpose-built to address these challenges for the Pacnet infrastructure—a global submarine cable network connecting Asia, Australia, and the Americas.

Design Principles:

1. Distribute Control: Place controllers near switches to minimize latency
2. Decouple Processing: Separate control plane from compute-intensive operations
3. Telemetry First: Build comprehensive monitoring into the architecture
4. Horizontal Scale: Enable independent scaling of each component
5. Production Ready: Design for 24/7 operation from day one

Architecture Deep Dive

The Architecture of OpenKilda is shown in the figure below:

Modularity and Extensibility

OpenKilda is built on several well-supported open-source components to implement a decentralised, distributed control plane, backed by a unique, well-designed cluster of agents to drive network updates as required. The modular nature of the architecture lends itself to being reasonably easily added new features.

Scalability

OpenKilda is able to scale process intensive profiling and decision-making functionality horizontally and independently of the control plane.

Interfaces

Telemetry

Extracting usable telemetry from the infrastructure was a core design principle of OpenKilda, so one output from the Storm agents is streams of time-series data, collected by a Hadoop backed, OpenTSDB data store. This data can be used in a multitude of ways operationally, from problem management to capacity planning.

Resilience and Fault Tolerance

OpenKilda has no inbuilt clustering mechanism, instead relying on external tools to maintain availability. 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.

Programming Language

OpenKilda is written in Java.

Community

While the functionality of OpenKilda in its intended space is promising, community support is still being cultivated, leaving much of the development and maintenance burden on its current users, with feature velocity slow. OpenKilda needs your support – chat with us to get involved.

Conclusion

SDN Controller Comparisons:

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.

Product Rating

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

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.

SDN Controller Comparisons:

Non-Restricted Frameworks and Languages 

Unlike many traditional platform-as-a-service offerings, Kubernetes provides much greater flexibility for the types of applications supported. Kubernetes does not restrict application frameworks, supported languages or distinguish services from applications. If an application can run in a container, it should run on Kubernetes, making Kubernetes the container orchestration platform of choice for modern applications. 

We also support other Container Orchestration platforms in addition to Kubernetes – including Docker, Cloudify, Kolla-Ansible, Murano and more. Check out our supported technologies or chat with our Solutionauts to find out the best orchestration platform for your requirements.