Open source sdn controllers comparison

Open Source SDN Controllers
Comparison
By Yashaswi Jain

Legacy Network and SDN
• There was a great increase in the demand for network services from the mid-2000s, which forced enterprises
to build larger and larger networks. But the product innovation was still dominated by proprietary vendor
architectures. Also scaling and operation of the network is always problematic and expensive at the same time
interoperability of the different proprietary devices in a multivendor environment has been painful.
• Once You buy a piece of networking equipment, you don’t really have the freedom to re-program it. You can
buy a router/switch from Cisco/juniper and it would come with whatever protocol it supports and what s what
you can run. And these companies don’t give you access to do modification because they don’t want you to
come to them for support if your network melts down because of the modification you did.
• IT compute infrastructure has totally transformed is the last 2 decades, using the power of orchestration,
programmability, and automation now we can set up a server farm with thousands of computing resources in
a matter of hours. We can add or remove the capacity to compute on the fly and automatically. Vertical and
horizontal scaling, the update of the patches and a lot more can be done with minimal manual involvement
• But at the same time there has been no major change in the way network operates, yes indeed networks have
become more advance and capable to provide various new services but the same has made the network more
and more complex and difficult & expensive to operate.

SDN & SDN Controller
Software-defined terminology has given a new way to manage and operate the network. With SDN
network operators has more control in their hands, now one does not have to buy a network product which is a
bundle of hardware and software. Now we can buy open white box hardware, have an open operating system
like Ubuntu installed on it, and develop our own network applications to execute the different network functions.
Also by segregation of the control plane and data place has given the flexibility to have centralized control, which
also enables us to orchestrate the entire network.
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 centralized component – an SDN Controller.
There are many SDN controllers exist, following are the most popular Open Source SDN controllers in industry
and academia :
OpenDayLight (ODL)
Open Network Operating System (ONOS)
Ryu
OpenKilda
Faucet

SDN Controller Comparison
It is a bit difficult to do a comparison between the SDN Controllers as each one has been created for
different use cases, But still, we can compare the controllers against the following criteria:
Interfaces
 Northbound API support
 Southbound API support
Programming Language
Architecture
Modularity and Extensibility
Scalability
 Cluster Scalability
 Architectural Scalability
Telemetry
Resilience and Fault Tolerance
Community

OpenDayLight (ODL)
I will start with the most popular SDN controller “OpenDayLight (ODL)”. The OpenDayLight project is
focused on network programmability. ODL is a modular, open platform that allows customization and automation
of the network of any size and scale. It is also focused on Software Defined LAN (SD-LAN) and Cloud integration
space. This was designed as a foundation for the commercial solution to address various use cases in existing
network environments. OpenDayLight has been integrated into other open-source SDN/NFV orchestration and
management solutions such as OpenStack, Kubernetes, OPNFV, and ONAP which are very popular platforms in
telco environments.
INTERFACES
 Southbound: It supports a large list of Southbound interfaces including OpenFlow, P4, NETCONF, SNMP, BGP,
RESTCONF, and PCEP.
 Northbound: ODL offers the largest set of northbound interfaces with gRPC and RESTful APIs. The northbound
interfaces supported by ODL include OSGi for applications in the same address space as the controller and the
standard RESTful interface. DLUX is used to represent Northbound interfaces visually to ease integration and
development work.
PROGRAMMING LANGUAGE
• ODL is written in Java.

OpenDayLight (ODL)
ARCHITECTURE
ODL consists of 3 layers:
• Southbound plugins to communicate
with the network devices
• Core Services that can be used by
means of Service Abstraction Layer
(SAL) which is based on OSGi to help
components going in and out of the
controller while the controller is
running
• Northbound interfaces (e.g.
REST/NETCONF) that allow operators to
apply high-level policies to network
devices or integration of ODL with
other platforms

OpenDayLight (ODL)
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.
Cluster Scalability
 ODL contains internal functionality for maintaining a cluster, AKKA as a distributed datastore shares the current
SDN state and allows for controllers to failover in the event of a cluster partition
 As a cluster grows, however, communication and coordination activities rapidly increase, limiting performance
gains per additional cluster member
Architectural Scalability
 ODL includes native BGP routing capabilities to coordinate traffic flows between the SDN islands
 Introduction of OpenDaylight into OpenStack provided multi-site networking while boosts networking
performance

OpenDayLight (ODL)
TELEMETRY
 ODL has limited telemetry related functionality. With the latest development release, there are moves toward
providing northbound telemetry feeds, but they are in the early design and not likely to be ready for
production in the short term.
RESILIENCE AND FAULT TOLERANCE
 An odd number of SDN controllers required to provide fault tolerance in the system. In the event of a master
node failure, a new leader would be selected to take control of the network. The mechanism of choosing a
leader focuses on high availability.
COMMUNITY
 ODL is 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.

Open Network Operating System (ONOS)
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
“brownfield” networks to SDN “greenfield” networks. This enables exciting new capabilities, and disruptive
deployment and operational cost points for network operators. It also supports the YANG model which enables
vendors to write their applications against this model. The scalability of ONOS makes it highly available and
resilient against failure which increases the customer user experience.
INTERFACES
 Southbound: It supports OpenFlow, P4, NETCONF, TL1, SNMP, BGP, RESTCONF, and PCEP.
 Northbound: ONOS offers a large set of northbound interfaces with gRPC and RESTful APIs.
 GUI: The ONOS GUI is a single-page web-application, providing a visual interface to the Open Network
Operating System controller (or cluster of controllers).
 Intent-based framework: ONOS has the implementation of the inbuilt Intent-based framework. By abstracting
a network service into a set of criteria a flow should meet, the generation of the underlying OpenFlow (or P4)
configuration is handled internally, with the client system specifying only what the functional outcome should
be.
• ODL is written in Java.

ARCHITECTURE
ONOS is designed as a three-tier
architecture as follows:
 Tier 1 comprises of modules related to
protocols which communicate with the
network devices (Southbound in the
figure)
 Tier 2 composes of the core of ONOS
and provides network state without
relying on any particular protocol
 Tier 3 comprises of applications, ONOS
apps, which use network state
information presented by Tier 2

 ONOS has built-in mechanisms for connecting/disconnecting components while the controller is running. This
allows a very flexible approach to add functionality to the controller.
SCALABILITY
 ONOS is designed specifically to horizontally scale for performance and geo-redundancy across small regions.
 The cluster configuration is simple, with new controllers being able to join and leave dynamically, giving
flexibility over time.
 The Atomix distributed datastore, which prioritizes data consistency, should reduce the outages caused by
cluster partitioning as all hosts are guaranteed to have the correct data.
 As a cluster grows, however, communication and coordination activities rapidly increase, limiting performance
gains per additional cluster member.
 ONOS includes native BGP routing capabilities to coordinate traffic flows between the SDN islands.
 There are several documented instances of ONOS (e.g. ICONA, SDN-IP) being used successfully in a geo-
redundant architecture for controlling large scale SD-WANs.

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.
 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 control of the network.
COMMUNITY
 The Open Network Operating System is supported under the Linux Foundation Networking umbrella and
boasts a large developer and user community.

Ryu SDN Controller
Ryu is a very different SDN controller. Ryu is more of 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. It is
very popular in academia and has been used in OpenStack as a Network controller.
INTERFACES
 Southbound: It supports multiple southbound protocols like OpenFlow, NETCONF, OF-Config, and partial
support of P4
 Northbound: Offer RESTful APIs only
 Ryu is written in Python.

Ryu SDN Controller
ARCHITECTURE
A Ryu SDN controller composes of these
components:
 Southbound interfaces allow
communication of SDN switches and
controllers
 Its core supports limited applications
(e.g. Topology discovery, Learning
switch) and libraries
 External applications can deploy
network policies to data planes via
well-defined northbound APIs such as
REST

Ryu SDN Controller
 Ryu is structured differently from other solutions in that it provides a simple supporting infrastructure that
users of the platform must write code to utilize 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.
 External tools such as Zookeeper distribute the desired state. Extra instances of the controller can be started
independently as long as the backing configuration remains identical.
 While Ryu supports high availability via a Zookeeper component, it does not yet support a co-operative cluster
of controllers..

Ryu SDN Controller
TELEMETRY
 Ryu doesn’t provide any telemetry functionality. This needs to be provided via external tools.
 Ryu has no inbuilt clustering mechanism, instead of 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 to detect the controller’s failure
and sharding state between cluster members.
COMMUNITY
 An active community developing the framework, it is a well-supported and targeted controller.

OpenKilda SDN Controller
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. it may not be suitable for geo-redundant environment or segment routing due to the lack of
BGP and MPLS tagging.
INTERFACES
 Southbound: It supports OpenFlow
 Northbound: Offer RESTful APIs only, which are limited compared to ONOS and ODL
 OpenKilda is written in Java.

ARCHITECTURE
 Structurally, OpenKilda uses the
Floodlight software to interact with
switches using OpenFlow, but pushes
decision making functionality into
other parts of the stack.
 Kafka is used as a message bus for the
telemetry from the Floodlight and
feeds information into an Apache
Storm based cluster of agents for
processing.
 Storm passes the time-series data to
OpenTSDB for storing and analyzing.
 Neo4j is a graph analysis and
visualization platform.

 OpenKilda is built on several well-supported open-source components to implement a decentralized,
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 to new
features.
SCALABILITY
 OpenKilda is able to scale process-intensive profiling and decision-making functionality horizontally and
independently of the control plane.
 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.
 BGP is currently not implemented and may need to be developed.

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.
 OpenKilda has no inbuilt clustering mechanism, instead of 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.
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.

Faucet SDN Controller
Faucet is 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, neighbour
discovery, and switching algorithms) to vendor independent server-based software, versus traditional router or
switch embedded firmware, where those functions are easy to manage, test, and extend with modern systems
management best practices and tools. Faucet is configured via a YAML file, which makes it a suitable option for
CI/CD and testing environments.
INTERFACES
 Southbound: It supports OpenFlow v1.3 as a southbound protocol and has support for features such as VLANs,
IPv4, IPv6, static and BGP routing, port mirroring, policy-based forwarding, and ACLs matching.
 Northbound: YAML configuration files track the intended system state instead of instantaneous API calls,
requiring external tools for dynamically applying the configuration. However, it does open the SDN to
administration by well-understood CI/CD pipelines and testing apparatus.
 Faucet is written in Python.

ARCHITECTURE
 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.

 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 by 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.
 Faucet contains no intrinsic clustering capability and requires external tools such as Zookeeper to distribute state
if this is desired. 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.
 BGP is currently not implemented and may need to be developed.

TELEMETRY
 Faucet can export telemetry into Influxdb, Prometheus or flat text log files. While Prometheus saves data
locally, it can also be federated, allowing centralized event aggregation and processing, while maintaining a
local cache to handle upstream processing outages and maintenance.
• Faucet has no inbuilt clustering mechanism, instead of 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.
COMMUNITY
 Faucet has an active community developing the framework and it is well supported.

CONCLUSION
I this presentation i have compared only 4 open source SDN controllers, there are many more
controllers in the marker proprietary and open source both. There are lot of innovation happening in controllers,
and the good things is most of the innovation is driven by service provider and there requirements. And healthy
competition is good for the innovation and by looking at these I can see in near future there will be a very
different network and it is today. There has been lot of talk about intelligent network, programmable network
and intent based network, I think it is still long way to go as Network is very different than IT compute
infrastructure but future looks promising.
Thank You
Yashaswi Jain
Reference
Sdxcentral.com , thenewstack.io, aptira.com, injoit.org, researchgate.net

Open source sdn controllers comparison

More Related Content

What's hot (20)

Similar to Open source sdn controllers comparison (20)

Recently uploaded (20)

Open source sdn controllers comparison