In-Depth

Prepare Your Shop for Software-Defined Networking

Virtual networks are the future of your datacenter. Here's what you need to know about implementing SDN.

• By Brien Posey
• 10/01/2013

Over the last few years, several new technologies have completely changed IT as we know it. The two most transformative technologies have been server virtualization and cloud services.

While virtualization continues to penetrate the IT fabric, not all servers are virtualized, and it's still early days for cloud services. However, these technologies together are rapidly changing the way IT infrastructure is deployed. And there's an emerging technology on the scene that promises to hasten server virtualization and the use of cloud services to facilitate datacenter consolidation. That new technology is software-defined networking (SDN), and it's poised to dramatically transform IT.

Only the most progressive shops are using SDN in some form today, but it's rapidly gaining traction -- and if it's not in use in your organization, it might be on the horizon. If you're an IT pro in any capacity, it's important to understand what SDN is, what it isn't and, most important, how to ensure network decisions you make today will migrate to this new architecture in the coming years.

A Web search on SDN renders an ambiguous set of definitions. It seems to mean different things to different people. Many different vendors offer SDN solutions, but the actual offerings and their capabilities can differ widely from one vendor to the next. SDN is best described as a way of separating the data plane from the network-control plane programmatically, thereby moving control of the network away from switches and routers and giving control to a network server (which is often referred to as a controller).

Programmatic Packet Routing
Physical routers and switches perform two main tasks. First, they make high-level packet-routing decisions. Second, they perform packet forwarding based on those decisions. These functions have traditionally been performed at the hardware level.

When SDN is implemented programmatically, these two functions are separated from one another. The switch or router still performs the actual packet forwarding, but the decision-making process is removed from the hardware device. Instead, the decision-making process is handed off to a centralized server that acts as a controller. This allows additional intelligence to be added to the decision-making process.

The actual way in which these types of capabilities are implemented varies depending on the SDN technology that's being used. Some technologies rely on encapsulation, whereas others are based on the use of proprietary control protocols. Like any new technology, broad adoption of SDN will require multi-vendor interoperability facilitated by standard protocols.

OpenFlow Protocol
The most dominant SDN standard is currently the Open Networking Foundation (ONF) OpenFlow protocol. Virtually every major network and systems hardware and software supplier, as well as services and cloud provider, is a member of the ONF -- including founding-member Microsoft and its key technology partners. The ONF announced the first commercial OpenFlow deployments two years ago.

OpenFlow moves the network decision-making process to a server that acts as a controller. Of course, the decision-­making process would do little good without a way to actually move packets across the network. As such, the controller uses the OpenFlow protocol to send instructions to the physical networking hardware -- but this can only occur if the networking hardware is OpenFlow-aware.

The advantage to using this approach is it provides a more comprehensive view of the network. On a typical network, each device acts as an independent entity. Devices have their own configurations and policies. OpenFlow allows network devices to be centrally managed. It also makes it possible to build appli­cations that treat the network as a single, cohesive entity rather than as a complex collection of individual devices. By doing so it becomes possible to make more intelligent routing decisions because the application can view the network as a whole and use collective routing in place of legacy point-to-point routing algorithms. This concept of globally configuring and managing network devices becomes especially important in large-scale deployments. Some of today's datacenters are so large that it's nearly impossible to manually monitor or diagnose problems with individual networking components.

Keep in mind that OpenFlow doesn't automatically solve the management and monitoring problems often found in large environments. OpenFlow is merely a protocol. It's ultimately up to developers to write software that takes advantage of the groundwork laid by OpenFlow.

Network Virtualization vs. SDN
There are some who view network virtualization as a type of SDN. Although this viewpoint has some validity, I see virtual networking as a subset of SDN.

Some might be quick to point out that virtual networking technologies such as the Hyper-V Virtual Switch aren't based on OpenFlow. But it's important to remember that although OpenFlow is currently the dominant SDN standard, the use of OpenFlow is not an absolute requirement for SDN. The broad definition for SDN could easily include any networking technology that separates the data plane from the network-control plane by way of an API.

Your Path to SDN
As interesting as the science and mechanics behind SDN are, none of that matters much unless there's a compelling business case for adopting it in your datacenter. So with that in mind, what is the place of SDN in the enterprise?

Because the IT community has so many different inter­-pretations of SDN and definitions for what qualifies as SDN technology, the benefits and implementation implications will vary as well. Enterprise IT decision makers often look to SDN to increase bandwidth utilization or ensure latency-sensitive packets are delivered in the most efficient manner possible. Some organizations also deploy SDN as a multi-tenancy solution for isolating certain types of network traffic from one another.

Network Abstraction
All too often, virtual networking is viewed primarily as a technology for connecting virtual servers to a physical network. I tend to think of virtual networking as a form of SDN, and SDN is all about network abstraction, so in my view there are at least three aspects to virtual networking that really take advantage of this abstraction.

The first aspect is virtual networking technologies (such as those found in Microsoft Hyper-V) let you create network segments that exist only at the software level. For example, if you wanted to create a backbone segment between three virtual servers that reside on a common host, you could create a private virtual switch. A private virtual switch provides communications between the connected VMs, but doesn't provide communications with the parent partition. More important, a private virtual switch isn't bound to a physical network adapter, which means the network segment is completely isolated from the physical network. The benefits to creating a private virtual switch are security (because packets never traverse the physical network) and scalability (because packets can be sent from one VM to another without regard to the impact on the physical network).

A second way virtual networks benefit from abstraction is they make it much easier to deal with multi-tenancy. Virtual networking makes it possible to create a series of logical networks that share the same physical networking hardware, but remain isolated from one another. This ability is critical to keeping multi-tenant environments secure.

The third approach in which virtual networks can take advantage of abstraction is through the use of extensible virtual switches. Ever since Microsoft first introduced Hyper-V, external virtual switches have been the mechanism that linked VMs to the physical network. But the problem with Hyper-V Virtual Switches is they've historically functioned like a network black box. There was previously no good way to see into a virtual switch. The techniques used to manage the physical network were ineffective when it came to managing the virtual network.

When Microsoft released Windows Server 2012 last year, the company set out to solve this problem by making the Hyper-V Virtual Switch extensible. This makes it possible for third-party vendors to use an API to develop code that allows a Hyper-V Virtual Switch to be managed in the same way as a physical switch. Doing so blurs the line between the physical and virtual networks, at least from a manageability standpoint.

The Big Picture
Although the extensibility features and the level of abstraction provided by Hyper-V Virtual Switches are helpful, SDN is much larger than virtual networking. So what benefits does SDN offer outside of those that are specific to network virtualization?

SDN serves primarily as a way to simplify management and establish a greater degree of control over your network. It's also designed to allow your networking infrastructure to become much more dynamic and flexible.

The main reason why SDN is so important is networking lags behind server technology in terms of flexibility. For example, server virtualization and related technologies make it very easy to deploy thousands of new VMs in a very short period of time. However, the problem with doing so is these new VMs have an impact on the network. That extra activity might take a network administrator days to provision the network resources needed to adequately handle the workload created by all these new VMs.

It probably isn't every day an organization creates thousands of new VMs. Even so, it's worth noting companies like Microsoft and VMware Inc. offer self-service VM-provisioning mechanisms that make it frighteningly easy for an authorized user to create new VMs on a whim.

As a result, servers are no longer static. VMs can be created, deleted or migrated on a moment's notice. When appropriately used, SDN can allow the network to dynamically adapt to these sorts of changes. In fact, companies such as Google Inc. have used SDN as a way of achieving a higher VM density by making more efficient use of the available bandwidth.

Start Planning Now
In spite of the benefits of SDN, most organizations aren't yet ready to commit to a programmatic SDN implementation (excluding virtual networking). Even so, SDN is something you should start thinking about today, even if you have no immediate implementation plans.

The reason is simple: networking hardware such as switches and routers tend to have a much longer useful life than other types of computer hardware. For instance, a server might only have a useful life of three to five years, whereas a network switch might have a useful life of eight years or more.

Because switches and routers are longer-term and more substantial IT investments, it's important to purchase network­ing hardware that will meet your needs for years to come, even as technology evolves. With that in mind, it's prudent to ensure any switches or routers you purchase in the future are OpenFlow-aware.

SDN has tremendous potential but the technology is still emerging. Although it'll probably be a few years before SDN goes mainstream, you should evaluate future networking hardware purchases on their ability to work with SDN standards such as OpenFlow.