SDN: Your Next Network

Software-defined networking is here, and it needs a plan. From you. Vendors are revamping product lines and buying up companies to get a stake in the SDN market, doing their best to tag themselves as hip to the biggest networking technology change since Ethernet.

IT teams shouldn't wait and watch the vendors. Just under half of 250 business technology pros with some knowledge of SDN in our InformationWeek Software-Defined Networking Survey say they're only somewhat familiar with this new approach to networking today. Those people aren't hopelessly behind yet--only 9% in our survey have SDN in production or testing. But given SDN's potential, it's time for IT organizations to start figuring out where this strategy might make sense for their companies. A good starting point is to look at the three main approaches to SDN today and start forming an opinion on which if any is most viable at your company.

Software-defined networking broadly means letting networking pros specify configurations in high-level languages, and those instructions tell routers and switches how to prioritize and manage traffic. Our survey finds that IT pros who've implemented or plan to have SDN think it will boost network utilization and efficiency (42%), automate more provisioning and management (35%), and improve security (32%). Almost 30% think it will lower costs, but that's far from a given at this point.

SDN should help IT more quickly provision network services that underpin business applications. It should allow more automation of networking, letting companies put more resources into innovation than day-to-day operations.

SDN could prove highly disruptive to the networking industry. One approach to SDN would overturn the current role that switches and other network devices play by turning them into fast but dumb (and inexpensive) machines that forward packets, while network intelligence would reside in a centralized controller.

This approach threatens dominant networking vendors such as Cisco Systems, which commands high prices for network switches. Cisco and others are pushing back by proposing SDN models that allows for more automation and flexibility without doing away with the switch's prominent role in determining optimal network pathways. SDN also opens the door for virtualization vendor VMware to become a force in the networking market. VMware pledged $1.26 billion in July to acquire startup Nicira, which makes software to build SDNs.

Get the full-length report on Understanding Software-Defined Networks

>> See all of our reports <<

One element that all of the SDN approaches share is the use of software interfaces such as APIs to provide more automation and enable orchestration of resources across multiple devices, such as switches, routers, firewalls, and load balancers. Such APIs should also spur the creation of applications for new network features and functions.

To help you chart a strategy, we'll explore three approaches to software-defined networking, then look at what's driving SDN and what's holding it back.

OpenFlow At The Core

The SDN approach that's most well known separates a network's forwarding and control planes, which typically reside in a switch, and moves the control plane to a separate device. This device, called a controller, calculates the best path through a network for particular workloads and programs the forwarding behavior of the switches (see diagram, below). The controller can be an appliance, a virtual machine, or a physical server.

A core concept of this approach to SDN is that the OpenFlow protocol is used between the network elements and an SDN controller to program the forwarding behavior of the switch. Thirty-three percent of survey respondents say they're very familiar or familiar with the OpenFlow protocol, and another 38% say they are somewhat familiar. The controller also has a northbound API, which is an interface for applications that want to use OpenFlow data. A number of vendors have announced their intention to ship OpenFlow-enabled switches, including Brocade, Cisco, Extreme Networks, Hewlett-Packard, and Juniper Networks.

The Open Networking Foundation (ONF), a nonprofit group that oversees the development of the OpenFlow protocol, advocates a controller-based architecture using OpenFlow. The foundation has more than 70 members, including telecom companies, Internet giants such as Google and Facebook, some of the world's largest network device manufacturers (including Cisco), and startups.

Though OpenFlow is the best-known interface, there are alternatives to it as the communications protocol between a controller and network devices. In addition to Java, C, Python, and REST APIs, the alternatives include the Extensible Messaging and Presence Protocol, the Network Configuration Protocol, and OpenStack from Rackspace and NASA. However, our survey shows that OpenFlow is closely associated with SDN.

One of the implications of the ONF-backed approach is the likelihood that switches and routers would become low-cost commodities, which could potentially cut costs for companies that adopt this approach. While vendors such as Cisco and HP have downplayed the dumb-switch concept, companies such as Dell, IBM, and NEC are more supportive of it. For instance, NEC sells both a controller and switches that support OpenFlow. IBM has also released a line of switches that support OpenFlow, and partnered with NEC to make sure IBM switches work with NEC's controller. A startup called Big Switch Networks is also developing a controller that supports OpenFlow.

The disagreement on the relative role of the controller and the network elements between members of the same class of products is one of the many factors driving the confusion that surrounds SDN.

Our survey respondents aren't convinced SDN will result in a dumbing down of switches and routers: just 29% say it will, 37% say it won't, and a third don't know.

When evaluating SDN, IT organizations need to take a position on this question of the switch's role. Is reducing the relative value of switches and routers a desired outcome of implementing SDN? An acceptable outcome? An unacceptable outcome? The position that an IT organization takes will influence which vendors they consider using and which ones they should avoid.

The primary advantages of the ONF approach to SDN is that it is based on industry-standard protocols and has growing vendor support and momentum. It may also reduce costs because switches would become single-function commodity devices.

However, one disadvantage of this approach is that vendors are just in the early stages of implementing OpenFlow, which means interoperability among vendors isn't assured.

An example of that lack of interoperability can be seen back in the diagram below: The northbound interface shown on the previous page isn't standardized. This means any company or vendor that writes an application to communicate with a controller has to ensure that the application works with APIs from myriad controller vendors. Note that the Open Network Foundation recently announced an initiative intended to make it easier for application providers to use various APIs.

Other possible downsides include the fact that companies would have to rearchitect their networks to incorporate the controller-based system. However, our survey suggests this may not be a significant barrier. Of those with or planning to have SDN in production, 88% are moderately to completely willing to make significant changes to get SDN benefits.

Two Competing Visions Of SDN

While the ONF approach is most commonly associated with SDN, there are two other emerging visions for software-driven networks. The second approach also separates the control and forwarding planes, but it does so by leveraging a virtual switch such as Cisco's Nexus 1000v, VMware's DVS or IBM's DVS 5000v. In this approach, the virtual switch functions as a forwarding engine that is programmed by a device that is separate from the virtual switch. This functionality is used as part of an overlay network that rides on top of the existing network infrastructure using protocols such as Virtual Extensible LAN or Network Virtualization using GRE.

This approach may appeal to existing customers of Cisco and VMware--the dominant vendors in the networking and server virtualization markets, respectively. However, it's only applicable for hypervisor-based virtual switches, not physical switches. In addition, support for functionality such as VXLAN and NVGRE is only now emerging.

The third approach uses direct programmatic interfaces via APIs into network devices, which are broadly defined to include devices that operate at Layers 2 through 7 of the OSI-defined network stack. In this case, the control and forwarding planes aren't separated, nor is the control plane centralized.

Many network vendors, including Cisco, are adopting this approach. This summer, Cisco announced that as part of its SDN approach it will offer APIs into multiple Cisco platforms, including its IOS, IOS XR, IOS XE, and NX-OS operating systems. Cisco says this will allow for tight integration with software applications and provide better control of the network infrastructure.

Along with Cisco, Arista, Extreme Networks, and Juniper Networks all provide direct access to their platforms via APIs.

One advantage of this approach is that it enables very detailed access and control when it comes to network devices. It also avoids the interoperability shortcomings that are associated with the OpenFlow protocol. Because this approach doesn't rely on a centralized controller, it also avoids the availability and security problems that can be associated with a controller-based architecture (that is, if the controller dies, so does the ability to move traffic through the network).

On the downside, this approach is vendor-specific. In a multivendor network environment, this approach would result in "islands of control" whereby the operator would have differing levels of control of the network equipment based on the provider of that equipment.

Drivers Of SDN Deployment

IT teams don't want to implement an SDN just for the sake of changing the network. What they want to do is solve one or more problems and/or find new ways to add value to the business. "If I were to go to a business unit manager and say that I need $3 million to implement OpenFlow and that will allow me to centralize the control plane of my network, they would kick me out of their office," says an infrastructure portfolio architect for a multinational professional services organization.

In other words, it only makes sense to implement SDN if it results in a measurable and significant improvement of the IT infrastructure and operations. "If I go to management with a plan to implement SDN and reduce the number of network administrators from 20 to 10 and to reduce provisioning time from two weeks to four days, they will at least listen to me," the infrastructure architect says.

Those anticipated improvements are reflected in the most common benefits IT will use to sell SDN to business partners: a more efficient and flexible network that improves delivery speed, cited by two-thirds of respondents planning to have SDN or that have it. Only half cite hardware cost savings, reflecting the uncertainty of SDN to deliver cheaper networking.

No Easy Cost Savings

It's not at all clear that cost savings anticipated with a controller-based SDN model will appear. Where IT teams anticipate those cost savings, it's in large part because dumbed-down switches will be cheaper than conventional switches. But given the current state of the market, the deployment of SDN won't result in dumber switches and routers for at least the next two years. That follows in part because it will take a new generation of merchant silicon to build fully functional, highly scalable OpenFlow-enabled devices.

And even if fully functional OpenFlow devices were available, the vast majority of IT organizations would adopt them over time and most likely would implement them only in part of their infrastructure. That's because IT organizations seldom swap out one infrastructure for another in a single move, particularly with a new technology.

It's also possible that the cost savings of commodity switches will be eaten up by the costs of centralized controllers. In fact, when we asked survey respondents to anticipate the impact of SDN on switch and router markets in 2015, the second-highest response was that costs would simply shift to controllers and software.

In addition, some IT organizations are likely to adopt SDN in a hybrid model, in which some control plane functionality is centralized and the remaining functionality remains distributed within switches. Depending upon how much control functionality is centralized, this scenario may not result in switches with significantly less functionality; in fact, this scenario may result in switches that require additional functionality to handle new applications written for an SDN-enabled network.

Inhibitors To SDN Deployment

IT organizations that are evaluating SDNs need to understand the availability and scalability characteristics of the particular SDN designs that they're evaluating.

One of the concerns with a controller-based approach to SDN is availability; that is, what happens if the central controller goes down? Another is scalability; that is, how many packets, call setups, processes, or flows can one controller support? To respond to those concerns, several vendors, including Big Switch, NEC, and Vello, support a clustering of their controllers. While that approach can mitigate availability and scalability concerns, it still leaves open what happens if the network elements somehow lose their ability to communicate with the centralized controller cluster. One network design option that addresses this concern is to implement a redundant link between the controller and each switch.

Another factor that limits the deployment of SDN is that there is no widely agreed-upon model for how SDN and OpenFlow-enabled networks will interface with existing network management platforms and troubleshooting tools. IT organizations that are evaluating SDNs need to have a solid plan for how they will manage and troubleshoot those networks.

We asked our survey respondents to indicate the primary inhibitors to their companies' adoption of SDN in the next two years. Their top three responses reflect a typical factor in an emerging technology market: product immaturity and confusion. The top response was the immaturity of current products.

However, the second-highest response was "confusion and lack of definition" in vendor strategies. Such confusion is understandable: As we've laid out, there are at least three viable approaches that can rightfully be considered software-defined networking.

Interoperability is also a concern. At present, any IT organization that tries to take an SDN controller and connect it to three or four vendors' OpenFlow switches would either fail or would, at a minimum, spend a lot of time and resources working with the vendors to make those devices work together because the OpenFlow protocol is still so new.

Given such growing pains, IT organizations may decide to wait and see how SDN develops. But vendors aren't waiting. They are trying to define SDN in a manner that best suits their own interests.

There are significant differences in the various approaches to SDN, so IT must make the effort to determine which one will yield the most benefit. The fact is, SDN has the potential to make your next network more flexible, more automated, and easier to manage. That's certainly worth the effort.

Jim Metzler is an analyst and industry consultant at Ashton Metzler and Associates. You can write to us at [email protected].

InformationWeek: Oct. 8, 2012 Issue

Download a free PDF of InformationWeek magazine
(registration required)