SDN and the future of networking
New Networks
Generally speaking, the IT infrastructure is responsible for three tasks: processing, storing, and transporting data. The IT landscape was fairly static in the time before the virtualization of x86 computers. Planning and implementing changes or upgrades takes months or even years, from ordering, to delivering, and physically installing new hardware. This arduous process has changed radically with the arrival of VMware [1], KVM [2], and Hyper-V[3], because virtualization makes it easy to jump-start new computers.
New computers nearly always require an IP address and network integration. In the past, the configuration, along with physical dismantling and installation and wiring, used to take hours at best, but more like days. Equivalent tasks take a matter of minutes or even seconds in the virtual world.
The network infrastructure has to deal with this dynamic, but traditional approaches and concepts are much too slow to keep up. In addition, other developments, such as the emergence of smartphones and Bring Your Own Device (BYOD) [4] technologies, have added additional complications, requiring the integration and management of devices that appear as if out of nowhere and then disappear again.
At the same time, certain connections need to work immediately, securely, and reliably (see the "But of course!" box). The number of examples of the need to find new methods for managing networks could go on and on. A key factor in all solutions is the abstraction of the network hardware, which has led to the development of SDN [5].
But of Course!
Your network is one – of usually several – defense lines for the infrastructure or the entire IT landscape. What opportunities or risks does SDN carry in this context?
Centralizing configuration information allows for the easy detection of events on the network. Anomalies, such as attacks or simple spying, are thus easier to identify. SDN also makes it easier to study the effects of changes on the network. For instance, you can study the impact of a new blocking policy on the overall traffic much better with SDN. Approaches such as Moving Target Defense (MTD) [13] are also easier to implement using the more centralized control logic.
As a reminder: MTD involves hiding the attack target again and again or at least changing its position. Dynamic diversions using new or moving honeypots are also possible thanks to SDN.
A watchful eye must be kept on the data that enters or leaves the SDN controller. Which rules and guidelines change the network and which detailed information and statistical data go beyond the scope of the infrastructure? These questions apply in a stricter manner if the associated interfaces are available to many groups, such as application developers.
The Story So Far
The focus of this article is on IP-based networks containing a number of autonomous systems – typically switches, routers, and firewalls. These devices receive, process, and distribute data packages; they analyze the origin and destination and consult tables and rules before forwarding.
For this arrangement to work, these systems must be familiar with the network topology (at least to a certain extent). The role and position of a device on the network are directly related. One of these factors changing has a direct impact on the other. Computer virtualization means you can reposition a device on the network in next to no time – and you can modify both the position and role of the device.
But that's not all. The network has evolved over time. The Internet Engineering Task Force (IETF) [6] makes sure this evolution happens in a controlled manner, developing a number of protocols to spice up simple control logic. These upgrades often only address a specific task and operate in isolation.
The growing number of these standards, coupled with the vendor-specific optimizations and software dependencies, has significantly increased the complexity of today's networks. They have also lost almost all flexibility. Structural changes are risky and constitute a medium-sized project.
March Separately, Network Together
The basic idea of SDN is nearly ten years old and hails from Stanford University. At the time, Martin Casando described the idea of separating data flow and the associated control logic in his doctoral thesis [7]. He and his supervisors Nick McKeown and Scott Shenker are seen as the fathers of SDN. Casando, McKeown, and Shenker founded a company called Nicira Networks, which now belongs to VMware and is the basis of NSX [8].
Put more generally, the idea of SDN is separating configuration and infrastructure (Figure 1). Literature uses the terms control plane and data plane for these layers. The infrastructure plane includes devices such as firewalls, switches, or routers. But in an SDN, the control logic in them is significantly limited or non-existent in extreme cases. This control logic is, instead, the responsibility of the control plane. The stupid network devices make do with much simpler firmware. Freed from thinking, they focus on forwarding data packages.
The intelligence is in the control plane, which you can imagine as a correspondingly potent computer with control software. You specify the guidelines for receiving, processing, and forwarding data packages. For this system to work, the control logic and network devices need to communicate with each other. The interfaces should be well-known and standardized so that any manufacturer can easily set them up. OpenFlow [9] plays a pioneering role in standardizing the configuration.
Experience has shown that there also needs to be a kind of supervisor that supports the development of interfaces but also intervenes if things are going in the wrong direction. Open Networking Foundation (ONF) [10] has performed this task for SDN for over five years. Google, Facebook, Microsoft, Deutsche Telekom, Verizon, and Yahoo are the real heavyweights as founding members of ONF.
On the Plus Side
In addition to the previously mentioned benefits, SDN leads to a significantly lower dependence on hardware manufacturers – the brain is indeed in the control plane. The decoupling of the network hardware's life cycles and the logical topology is also advantageous. Standardized interfaces open up new hardware-agnostic automation possibilities.
You simply need to define a new policy in the control plane. This policy transmits the necessary information to the end devices. The separation of the control logic allows its centralization. This way you can easily get an overall picture of your network. The information that was distributed over perhaps hundreds of devices in the pre-SDN era is now available at one point in the best case.
The actual highlight is yet to come: SDN introduces an abstraction that makes the network easier to understand. In the past, IT departments had to break down a business process into routing tables and firewall rules. Network information was distributed across all sorts of devices. Consumers (business processes) and service providers (network administrators) spoke completely different languages.
However, with SDN, the application understands the topology (Figure 2) and can react to changes or even initiate them. Recent descriptions of SDN introduce the term application plane for this feature.
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.