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.