Overview of SDN Controllers (text)

by Sasha Shkrebets — last modified Mar 06, 2023 01:02 PM

In this lesson we will overview different SDN controllers. I'll try to give a basic understanding of each controller including the concepts behind the controller's design.

Welcome back.

In this lesson we will overview different SDN controllers.

I'll try to give a basic understanding of

each controller including the concepts behind the controller's design.

Its architecture and its programming model.

I'll also talk about the pros and cons of each controller to help you

figure out what controller might be best

suited to your needs for a particular situation.

And we'll talk about ideal situations for each controller.

There are many different SDN controllers, we'll talk about

the first four in this list in this lesson today.

Later in the course, we'll also explore some of

the other controllers listed here including pyretic and frenetic.

There are many considerations, when figuring out which controller to use.

One is the choice of programming language which can sometimes,

but not always affect the performance of the controller itself.

There's also how long it takes to figure out how to use the controller.

If you're trying to do something just quick and dirty for prototyping, then

you might want to use a controller with a much easier learning curve.

Another thing to consider is the user

base and the community support behind the controller.

Finally different controllers have different focuses in terms

of the south bound APIs that are supported.

The north bound API or the policy layer whether or

not their support for open stack or multi tenant cloud environments.

And whether or not the controller was

intended for use in education, research, or production.

Let's now take a look at the first four controllers in this list.

NOX was a first-generation OpenFlow controller.

It is open source, stable, and fairly widely used.

There are two flavors of NOX.

One, Nox-Classic, was the original NOX, and was implemented in C++ and Python.

It's no longer supported.

The new NOX is C++ only.

It has a fast and clean code base, and it's well maintained and supported.

You can find NOX at the URL at the bottom of the slide here.

In NOX, users implement control in C++.

NOX itself supports OpenFlow version 1.0, and a fork

of NOX called CPqD supports 1.1, 1.2, and 1.3.

In NOX the programmer writes a control program that registers for certain events.

Such as packet arrivals.

Or topology changes.

And the programmer than writes event

handlers that respond to those different events.

Might want to use NOX if you already know C++.

And you're willing to use low-level facilities and semantics of

OpenFlow, such as functions that directly modify the switch flow table.

Another good reason to use NOX is if you need good performance.

POX is essentially NOX in Python.

It currently supports only version 1.0.

An advantage of POX is that it's widely used, maintained

and supported and it's relatively easy to read and write code.

The main disadvantage of POX is performance.

POX is the main controller that we'll be using in this course.

Mainly because it has a relatively easy learning

curve relative to some of the other controllers.

And there are some interesting policy layers such

as Pyretic that are built on top of POX.

You might want to use POX if you already know or

can quickly learn Python and are not concerned about controller performance.

It's commonly used in research, for

experimentation and for demonstrations as well as

for learning concepts such as the concepts that we are learning in this course.

Ryu is an open source Python controller.

It supports all versions of OpenFlow from 1.0

to 1.4 as well as various mysteria extensions.

It also has OpenStack integration, in some sense

it aims to be an operating system for SDN.

And it's main advantages are the support for

all these versions of OpenFlow and it's OpenStack integration.

A disadvantage of Ryu with respect to some

of the other commercial grade controllers is performance.

Floodlight is an open-source Java controller that supports OpenFlow 1.0.

It's a fork from the Beacon Java OpenFlow controller.

And is maintained by Big Switch.

Some of the advantages include good

documentation and integration with the REST API.

It's also production level, and supports and

provides support for OpenStack and Multi-Tenant Clouds.

However, it has a fairly steep learning curve.

You might want to use Floodlight if you know Java, if you need production level

performance and support, or if you will use

the REST API to interact with the controller.

Another controller that is in active development is OpenDaylight.

The goal of the OpenDaylight project is to provide a common industrt supported

platform with a robust, extensible open source

codebase and common abstractions for northbound capabilities.

OpenDaylight has many advantages including widespread industry acceptance and

integration with OpenStack and other types of cloud applications.

However, it's extremely complex.

The documentation is rather poor.

And there's a very steep learning curve.

The complexity and steep learning curve of OpenDaylight are two reasons

that we're not using it as the main controller for this course.

However, I've added a lecture this year, to cover the basics

of OpenDaylight based on a tutorial that's being provided by SDN Hub.

We'll talk about that in the next lesson.

Another commercial great controller that's worth mentioning is HP VAN.

Both OpenDaylight and HP VAN were originally based on the source code of a

controller called Beacon, and hence have many

similarities both with Beacon and with each other.

You might want to use OpenDaylight if you know Java.

If you need production level performance and support.

If you need support for cloud applications, OpenStack and so forth.

If you need modular functions.

Such as the ability to plug different types of functionality

including both northbound and southbound functionality into the same controller.

Or if you need applications that

are already supported or implemented by vendors.

We'll talk a lot more about these modules, and

applications, that are supported by vendors, in the next lesson.

It's worth mentioning a library under development called LoxiGen.

Which actually generates OpenFlow language

specific bindings, for different controllers.

The idea is that one could provide a wire protocol description.

Of a control protocol.

And the output would be protocol specific bindings in different languages.

LoxiGen currently generates OpenFlow version 1.0 to 1.31 bindings in

C for Indigo, in Java for Floodlight, Python for OFTest.

And it also generates a binding for Wireshark and Lua.

In theory, one of the appeals of LoxiGen is

that it should support the evolvability of many different controllers.

As the OpenFlow wire protocol continues to evolve, in theory one can simply

use LoxiGen to upgrade the version of

the OpenFlow protocol that the controller supports.

In summary, there are a lot of different controllers.

And your choice of controller may depend

on your needs, your language, and so forth.

Thus far, we've focused mainly on the controller's support for

different Southbound API implementations such as different versions of OpenFlow.

However, it's worth noting that Southbound APIs

are becoming much broader than just OpenFlow.

And we'll talk about that more in the next lesson when we

talk about OpenDailight which supports a much broader range of Southbound APIs.

Later in the course we'll talk

about various controllers emerging support for different

kinds of Northbound APIs or policy layers that sit on top of these controllers.