Light into the Darkness

Virtualization has now reached the world of network management, and it's no longer just for server farms. Network nodes like switches and routers are increasingly migrating into the abstract IT world, which smooths the path for centralized and extremely flexible network management. The open source project OpenDaylight is the de facto standard for software-defined networking, and this article introduces you to the structure based on a sample scenario.

Google and Facebook provide examples of the need to manage data streams on networks in a targeted way. The legacy network architecture was unable to manage the high-volume data streams; or, you might say the task of managing hundreds or even thousands of network nodes was beyond the capability of the existing software tools at the time. Software-defined networking (SDN) is a new approach to designing, integrating, and operating networks that makes these networks just as easy to handle as virtualized servers. The basis for this is abstracting the control plane and the data plane.

Control Plane vs. Data Plane

Understanding these two layers is a precondition for meaningfully deploying and implementing SDN. To better understand the approach, you can consider the example of a schedule for public transport. Before bus drivers start their routes, they need a plan of which routes to drive and when they need to be where. Although the bus is still at the depot, the routing center knows which bus will be operating on which route to reach its assigned goal.

In other words, it's all about preplanning. This is exactly what the control plane is all about, and the procedure works similarly on the network. Planning involves, for example, defining static routes. The network nodes need to learn how to handle other networks and how to connect to them. They need a plan!

Now, the network nodes (i.e., the routers and switches) know how to communicate with other networks. Then, the first data packet arrives, which is where the data plane enters the game. It handles the transport of the data packets using the routes defined previously in the control plane, much like a bus driver. The difference from legacy nodes is that each node has its own data plane and control plane. In practical terms, this means that if you have 15 switches connected on a network, the administrator needs to program the control plane of each switch separately so that all the data traffic reaches its target across multiple nodes.

Distinguishing between the data and control plane makes it possible to bundle and manage the network's intelligence in a central system and transfer it en bloc to the nodes involved, which then act in line with the settings you configure. It is important for the devices to be connected, but physically they can be distributed all over the world.

The setup makes it possible to take a holistic view of the data traffic and to optimize. This means that the complexity of the infrastructure becomes secondary – not superfluous, just more flexible and easier to manage. After all, despite all of this virtualization, you still need physical connections between physical computers.

Flexible Communication Protocol

To distribute the central configuration to the physical or virtual level, you need an equally flexible communication protocol. OpenFlow has established itself as the standard for SDN. This protocol allows access to the forwarding layer of a switch or router, which the administrator uses to program the hardware that controls the data traffic. This approach makes comprehensive and complex traffic management possible, which is exactly what you need in virtualized environments and cloud environments.

Because of the central significance of OpenFlow, it is also a part of OpenDaylight. OpenDaylight in turn is a software project formed by a group of IT companies that came together in 2013 with the aim of promoting SDN. The companies wanted to develop a uniform basis for further IT virtualization.

Everyone Understands OpenFlow

For OpenDaylight to be able to talk to network devices as a control plane, the devices need to understand OpenFlow. This makes it essential to deploy switches and routers that work with this protocol. At the same time, this step is the first obstacle to planning. If you are installing a greenfield site, the devices do not necessarily all need to originate from the same manufacturer, but they do all need to support OpenFlow.

To save money, administrators can deploy components by different manufacturers, thereby achieving the best possible performance for their investment. Each device can be addressed in the same way using OpenFlow, but if you have an existing zoo of devices, you will need to do the math to find out whether buying new OpenFlow-capable devices to leverage the benefits of SDN is actually worthwhile.

For the sake of completeness, I will point out that there are intermediate solutions in SDN; overlay and hybrid models allow for partial use of the existing hardware and smooth the path of migration through gateways, for example.

Mininet Provides the Virtual Network Structure

To test OpenDaylight, you need a number of switches and hosts. Mininet [1] gives you a flexible approach for simulating these devices to create a virtual network infrastructure of OpenFlow-capable nodes. Further steps involve installing OpenDaylight as the control plane and then configuring it.

Mininet is available as a prebuilt virtual machine in OFV format and can thus be launched on any popular virtualization host. To illustrate the example, I will be launching the file, which weighs in at around 1GB, on VMware Workstation. It is important to use a Mininet installation from August 2014 or later, because this version will support OpenFlow 1.3 out of the box.

To start, you'll need to install Maven, JRE, and JDK. OpenDaylight needs these packages to operate. Then, download the OpenDaylight Karaf distribution [2]. This is a packetized release that provides the full feature scope. You now have everything you need for your SDN lab. Next, you'll need to create a small network topology with three clients and a switch. To be able to do so, launch Mininet at the command line as follows:

sudo mn --topo single,3 --controller remote

The --topo parameter defines the topology with three individual computers. The --controller remote parameter states that the control plane is external to Mininet. Otherwise, Mininet will provide both the data plane and control plane in its own environment. Now, your test lab for commissioning OpenDaylight is ready and simulating a small network without a control plane.

Adding Features as Modules

Mininet will notify you of the missing controller when launched, outputting a message reading Unable to contact the remote controller at 127.0.0.1:6633. In other words, the control plane is missing. Just to confirm this, try to ping host h3 from host h1. You will see a message telling you that the host is not reachable. The reason for this is that switch S1 does not have a control plane. As I mentioned previously, the control plane handles the routing of the data packets. Because this is still missing, the data plane – represented by switch S1 – has no idea how to distribute the packets.

In this example, I'm launching OpenDaylight on the same virtual machine as Mininet. In production, you will want to run OpenDaylight on a dedicated computer. At this point, OpenDaylight does not perform any other tasks because the system features need to be loaded individually. Each feature is a module written in Java; you can also program your own features to extend the system. As of this writing, OpenDaylight comes with 158 features. I will be configuring OpenDaylight at the command line; this means installing and loading the required features as follows:

feature:install odl-base-all odl-aaa-authn odl-restconf \
  odl-nsf-all odl-adsal-northbound odl-mdsal-apidocs \
  odl-l2switch-switch odl-dlux-all

It can take awhile for the system to provide this functionality. To check whether the control plane is connected with the data plane, you can ping host h3 from h1 again.

Network Analysis with OpenFlow

For a more comprehensive test and to evaluate OpenDaylight's capabilities, you can build a more extensive Mininet as follows:

sudo mn --topo tree,3 --controller remote

The tree parameter lets you create a topology with three trees consisting of a total of eight hosts and seven switches. Again, you need to install the required features to manage all seven switches, with OpenDaylight acting as the control plane. You can then use the pingall command in Mininet to ping each host from each host. The first return packet takes about 800ms; all subsequent packets are returned far more quickly (<20ms). This is because it initially takes some time for OpenDaylight to analyze the network with OpenFlow, discover the paths between the hosts, and store them in its network plan.

Convenient Web Interface

Of course, the objective of SDN is to manage routing centrally on the network, thus supporting configuration across multiple network nodes. Because this is a difficult task at the command line, the project also comes with a web interface known as DLUX. DLUX runs as a feature or module; it was enabled in the previous installation with odl-dlux-all.

You can type http://<IP_address>:8181/dlux/index.html to log on via the web interface. On the start page, the system shows the topology of the network structure that it has identified (Figure 1). You should see all the nodes registered on the network. Mousing over a host or switch pops up a tool tip with more information. To enter a static route, change to the Network menu item and click Static Routes (Figure 2). In the dialog, you can then enter the name, network, netmask, and hop count.

The Subnets tab lets you create various subnets, and you can also specify the Gateway IP (Figure 3). The central settings help you create rules for the data traffic that OpenDaylight then distributes to all nodes involved via OpenFlow. You don't need to worry about which switches are connected to which device. OpenDaylight as the control plane takes care of all that.

Conclusions

SDN breaks with the typical network and data traffic paradigm. Abstracting the data plane from the control plane allows totally new approaches in the implementation of the infrastructure. Thanks to centralized management, administrators can respond quickly to changing requirements and control the data traffic across many devices independent of the physical location.

Major IT corporations have cooperated on OpenDaylight and – based on the OpenFlow protocol – created a solution that allows administrators to combine arbitrary hardware, which they can then manage using OpenDaylight as the control plane. The implementation as a Java application and modularization through features make it possible to implement SDN in a targeted way to reflect the current network requirements.

Even though OpenDaylight is very easy to set up and manage, migrating to SDN or setting up a new SDN environment is a task that is not to be taken lightly. Before embarking on such a project, the stakeholders need to investigate the benefits and drawbacks for their in-house IT services and network infrastructure. Beyond this, it makes sense to call in experts at an early stage. Taking the next steps toward SDN means ditching traditional approaches and thinking outside of the box. Once you have this kind of atmosphere in place, OpenDaylight can be a very flexible solution for setting up your SDN and making any necessary modifications quickly and easily on the fly.