Commercial-Grade Controllers: ODL (text)

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

In this lesson, I'll talk about a commercial grade controller called OpenDaylight. I'll provide an overview of OpenDaylight, including a consortium of industry partners who are involved in the effort, as well as an overview of the OpenDaylight controller architecture.

Welcome back.

In this lesson, I'll talk about

a commercial grade controller called OpenDaylight.

I'll provide an overview of OpenDaylight, including

a consortium of industry partners who are

involved in the effort, as well as

an overview of the OpenDaylight controller architecture.

Also give a demonstration of the OpenDaylight controller in action.

Including showing the life of a packet

through a simple Mac learning switch application.

As well as the web interface to the OpenDaylight controller.

In doing so, I'll talk about essential OpenDaylight functions that you

need to implement to write a very basic OpenDaylight control application.

More information about OpenDaylight is available

on sdnhub.org, which is the source

of a lot of the information that I'm providing in this lesson.

[UNKNOWN] and [UNKNOWN] deserve a lot of

credit for putting together much of this material.

The OpenDaylight Consortium has heavy industry involvement and backing.

It's focussed on providing an open frame work for building on various

SDN and network function virtualization innovations

that are being developed across the industry.

The OpenDaylight controller is not limited to open flow innovations.

It supports many different south bound API's.

And perhaps no controller better illustrates the concept

that SDN is much, much broader than just OpenFlow.

Here's an illustration of the OpenDaylight controller release called Hydrogen.

At the very bottom of the architecture, we have OpenFlow enabled switches.

Open B switches, or software switches.

Maybe additional other virtual and physical

devices and other data plan elements.

It's important to note that these need be open flow switches.

In fact, when you look at the south bound interfaces, that the open daylight

controller supports, open flow is just one

south bound interface that it aims to support.

It also supports many other Southbound interfaces including Netcomf and

OVSCP, as well as more

conventional network management and configuration protocols.

In between the Southbound interface and the controller platform

itself, OpenDaylight provides what's called a service abstraction layer.

Which abstracts the southbound interfaces from the

modules that are provided by the controller platform.

This abstraction layer, or cell, is the main

difference between OpenDaylight and more open-flow centric controller platforms.

The controller platform implements various basic services on top of the cell.

And on top of the controller itself one can use the OpenDaylight REST API's to

write more complex network applications for orchestration and network services.

The OpenDaylight ecosystem has many moving parts.

The controller's written in Java.

Java was chosen as an enterprise-grade, cross-platform compatible language.

OpenDaylight uses Maven as a build system, and

we'll see that in action during the demonstration.

It also uses OSGI to allow the controller

to dynamically load bundles, automatically register dependencies and services.

And to exchange information across bundles.

We'll look at an example of how OSGI allows dynamic

loading of bundles in the demonstration of the Mac learning switch.

OpenDaylight provides Java interfaces for

event listening, specification and various patterns.

In the example that we'll look at, a packet will arrive.

At a particular switch will be sent to the

appropriate plugin that's managing the switch at the control log.

The plugin will parse the packet and

generate an event for the service abstraction layer.

The service abstraction layer dispatches the packet to modules that are

listening for data packet events using the iListenDataPacket interface.

These modules, such as an ARP Handler or a MAC Learning

Switch, handle the packet and send the packet out through the iDataPacketService.

SAL then dispatches the packet to the

modules that are listening for data packets.

And the controller will also send OpenFlow messages

to the appropriate switches such as flow modification directives.

Let's now have a look at the open

daylight controller running a simple Mac learning switch.

First going to start a simple three node mini-net topology.

With one switch.

We can see that with no controller, as before,

there's no connectivity between the host and the network.

I'm not going to install the tutorial code, using the Maven MVN tool.

In the end is the Maven command that compiles

the code based on the palm.xml file in that directory.

Maven resolves dependencies between pathogens.

And the code that we're using here depends on the open daylight controller package.

So, Maven will download the pre-compiled .jar

files from opendaylight.org, resolve dependencies, and so on.

This takes a while, but we can eventually run the command SS Tutorial to

see that our tutorial bundle running the Mac learning switch is in fact running.

Initially we started the controller running a hub.

Now I'll illustrate the power of OSGI's ability to dynamically load

bundles by changing the hub to a switch on the fly.

So I've changed the function of the control program from a hub to a switch.

And now I'll use Maven to dynamically reinstall the bundle.

You can see that once the switch bundle is reinstalled, the

the roundtrip times drop from milliseconds to less that one millisecond.

>> Open Daylight also provides a cool web interface to allow the operator

or programmer to see the network topology and the flows installed at each switch.

Like any controller.

The OpenDaylight controller has three essential types of code hotspots.

One for handling packet in messages or packet arrivals.

Another for parsing themselves as they arrive at the

controller, and a third for sending control messages to switches.

You can see in these code snippets that

there are several similarities between Beacon and OpenDaylight.

While the code itself here look similar, you should by now be noticing

that the above three types of functions are common to all controller platforms.

Here's the code and controller that illustrates

the main logic behind the Mac learning switch.

The logic is contained in the received data packet call back.

If the function of our controller is a hub, we simply flood the pack.

But as you recall, we changed the function from

a hub to a switch so we'll execute this branch.

The first thing that we do is decode the pack.

The control program then learns the source MAC address of the incoming pack.

If the outgoing port of the packet cannot be determined,

the control program simply floods the packet on all output ports.

Otherwise we install the corresponding rule in the flow table of

the switch, set the outgoing port, and then transmit the data packet.

Let's have a quick look at the program flow

function, which sets the match action entrance in the switch.

Here you can see, the program flow function.

Where we set the match type, and the corresponding actions.

And then modify the flow, on

the corresponding switch, using the AddFlow function.

Open Daylight provides many useful interfaces and bundles that

you may wish to use, ranging from things that track

hosts across the network, to keeping track of the

network's topology, to keeping track of various users and statistics.

Here are examples of some more user interfaces and bundles.

Including this that support the topology methods, modifying flows

in switches, and support for the web UI itself.

In summary, OpenDaylight is an industry backed effort

to develop a broader set of SDN solutions.

Perhaps more than other controller OpenDaylight illustrates that

SDN is just OpenFlow but it is possible to

integrate a broad set of southbound API's and provide

support for various types of cloud-based applications as well.

It's important to note, of course, that writing

a basic control program in OpenDaylight is very similar

to that of other controllers because there's a very

common set of basic functions that any controller provides.

And like packet arrivals, parsing of packets, and exchanging messages

with the switches themselves, the learning curve for OpenDaylight is significant.

But SDN Hub has a great starter kit, including a

virtual machine that I've used to show you this demonstration.

And that we've provided on the course website.

I strongly encourage you to check it out and play with it yourself.