Vendors and Carriers Work to Define Software-Defined Networks

Carl Weinschenk

Software-defined networks (SDNs) are getting a lot of attention. That certainly is understandable: SDNs hold the promise of doing many things that would take some of the pressure off increasingly hard-pressed carrier networks.

The road to the SDN future is a long one, however. But it is a road that carriers and vendors have started traversing. “There certainly is a lot of buzz,” said Omar Sultan, the senior manager of data center solutions for Cisco. “We are starting to see companies begin to deliver on some of that potential.”

Essentially, there are two ways to confront the great increase in data to be trafficked and the reality that a higher percentage is business-critical and time-sensitive. One is to throw more bandwidth and other resources at the problems. Adding capacity is great too, but it is in limited simply because there is only so much bandwidth to add and that simply increasing capacity doesn’t always make things faster, more secure or, in other ways, meet increasing expectations.

The other way of meeting the challenges is to greatly increase the efficiency of the resources that already exist. SDNs fit squarely into this category. Like many big ideas, the concept behind SDNs is fairly simple. Very roughly, combining the data and management plane is akin to using a map to find directions while driving. Separation of the data (i.e., the passengers) and the management plane (figuring out how to get to the destination) can be conceptualized as the use of a GPS device for directions in this broad example.

SDNs build on this separation with standardization-enabling management gear from different vendors to interoperate. A third characteristic of SDNs is that all or many of the management functions are consolidated on one “pane of glass,” or management console. Thus, experts say, SDNs build efficiencies in at least three ways: separating data and its management, creating interoperability between management tools from different vendors and consolidating control in one place.

All of these attributes enable networks to react more flexibly and quickly to variables, including changes in the nature of the traffic — from a preponderance of emails to a domination by video, for instance — and disruptions by outages or other problems. Managers can more easily change how the network runs as the priorities or goals of the service provider or customer change. If, for instance, a distributed denial of service (DDoS) attack is mounted against a company, the CISO may decide to change security policies, at least until the storm passes.

It is difficult to overestimate the benefits such a transition will bring — or the difficulty of doing it. “I look at it as the next generation networking,” said Lee Doyle, the general manager of IDC’s networking practice. “Previously programmability was challenging at best.” In May, Doyle and IDC released research that said that the SDN market will grow from a value of $200 million next year to $2 billion in 2016.

That’s quite a bit of growth, though it is from a relatively modest base. The main — but by no means only — driver of the growth is an initiative from the Open Networking Foundation, a consortium that is pushing OpenFlow, a set of standards meant to address the monstrously complex task of making SDNs real.

Dan Pitt, the executive director of the Open Networking Foundation (ONF), said that the OpenFlow initiative deals with the set of commands that is used in this restructured environment. The centralization of control, he said, offers a “very convenient” way to determine the best path for which to send packets based on policy, security, traffic engineering and any number of other criteria. However, once those decisions are made at “command central,” a method providing marching (or trafficking) orders to the various switches and other network elements, that’s where OpenFlow comes in, he said.


The key is letting all the vendors do this using the same approach. “You need to get the [information] from the controller to the switches,” Pitt said. “OpenFlow is the standard form of that protocol.”

OpenFlow is one piece of the puzzle. The bottom line is that SDNs are a massive undertaking that restructures both the technology and, to a great extent, the businesses that provide that technology.

It is safe to say that very significant challenges exist on the technical, business and political level. For instance, when Cisco spelled out its vision for SDNs at Cisco Live in mid-June, some of commentary in the media suggested that the company was slanting its definition to favor the tools and capabilities that it already has deployed within networks. There is nothing inherently wrong with that. It shows, however, that translating a broad concept into a set of standards is difficult from the political and financial as well as technical points of view.

Doyle said that there are essentially three meta groups working on SDNs: the network incumbents such as Cisco, startups and the academic community. There certainly is overlap between the three. But, clearly, the agendas will be spun in somewhat different directions. The bottom line is that drive to SDNs still is ramping up. “We’re in the very early days in terms of customer adoption,” Doyle said. “It’s still the bleeding edge. It’s still in the hype cycle.”

Common sense says that SDNs are a hugely promising area. Some of the most important work is going on now as different groups try to tweak the definition in their favor. “Part of the challenge is that the whole concept is a definitional battle field,” said Cisco’s Sultan. “It is a loosely defined and used phrase. If you talk to five vendors about SDNs, you get six definitions.”

Sultan said that incremental adoption over a long period of time is likely. He points to the industry’s experience with virtualization as a likely guide. That technique — which also drives efficiency in the hardware and software that already is deployed — has had a gradual ramp-up and now is seen as a vital tool by most organizations. The gradual adoption of SDNs is likely, he said, and points to the fact that more standards organization — such as the Internet Engineering Task Force (IETF) and the International Telecommunication Union (ITU) — are becoming engaged. “The key part is that we still are very early in the process,” Sultan said. “We’re only a year or 18 months into this.”



Add Comment      Leave a comment on this blog post
Dec 12, 2012 2:04 PM Jose Vildarraz Jose Vildarraz  says:
I think there is a defy in SDN, Hardware and sw layers definition, interoperability, timing on delivering value, timing until the information is valuable, and integration with the propietary valuable Big Data. Reply
Dec 7, 2013 7:46 PM Eamon Walsh Eamon Walsh  says:
The benefits of SDN are now coming into the spotlight, and surprisingly, they include solutions that don't use OpenFlow, he wrote. Nispel outlined three attributes that he believes comprise an SDN architecture: a centralized point of management and control, a programmable environment, and an open API infrastructure. He then questioned if the OpenDaylight project will be the northbound API, or if there will be more than one. Cool video that speaks directly to how open flow is helping to fuel SDN adoption. http://www.youtube.com/watch?v=WuvKBd4jyA0 Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


 
Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making

SOA

SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data