If you aren't intimately familiar with software defined networking, don't fret. Only 10% of 450 IT practitioners at a recent Network World event raised their hands when asked if they understand SDN. But if the emerging technology lives up to its promise to redefine networking as we know it, there is no time like the present to dig in and learn more.
Proponents argue that, among other advances, SDN will centralize and simplify control of the network, make networks programmable and more agile, and create opportunities for policy-driven supervision and more automation. In short, SDN will help networks keep up with the speed of change made possible by the virtualization of other data center resources and provide the perfect complement to cloud computing.
But challenges remain. Many of the vendor cheerleaders, after all, are tiny startups. While the incumbents seem to have joined in the chanting, only time will tell if they are serious about change or simply paying lip service while working behind the scenes to scuttle advances so they can get back to business as usual.
That said, most industry pundits say the SDN movement has momentum now and, even though we're still in the early goings, there won't be any stopping this train. Now it is just a question of where we end up going, how long it takes to get there, and how different the coach looks when it finally arrives.
"There is a fundamental transition happening now because the status quo is not sustainable," says Nick Lippis, a longtime industry observer and co-founder of the Open Networking User Group (ONUG), an SDN user group he formed with Fidelity Investments. "The cost to operate networks is too high and growing too fast and you can't find enough people to manage these things anymore. It's time for change."
It's telling, for example, that the SDN movement is being led by users. The organization championing the cause is the Open Networking Foundation (ONF), whose board members include Microsoft, Yahoo, Facebook, Goldman Sachs, Google, Verizon and Deutsche Telecom.
Jim Metzler, vice president of consultancy Ashton Metzler & Associates, notes that standards bodies are typically staffed by vendors (usually grouped into three camps -- those pushing the standard, those simply watching and those actively trying to slow down the effort), so the fact that SDN is being pushed by buyers greatly enhances its chance of success.
What's driving this is operational costs, not capital costs. In fact, some say the capital costs are irrelevant."
— Nick Lippis, co-founder of the Open Networking User Group (ONUG)
Broadly speaking, SDN makes change possible by separating the network control plane from the data plane, meaning control of the network is pried out of the devices that forward the packets and is centralized on a server called a controller. Rather than the classic approach of each network device principally worrying about adjacent devices and forwarding traffic based on that knowledge, centralizing intelligence makes it possible to see the network end-to-end and make smarter, big picture decisions, and when it comes time to make network changes, you can touch the network once instead of having to update each link in the chain. [Click here for more.]
The ONF has specified the OpenFlow protocol as the open standard way controllers communicate with and control OpenFlow-compliant network devices.
"OpenFlow allows, for the first time, an external control plane to abstract the entire underlying network fabric so that fabric is universally addressable and all topology and state information is commonly managed," says Jason Matlof, vice president of marketing at Big Switch, a poster child of the SDN movement. "Today every device has its own control plane, manages it own state, has its own policy definitions, its own configuration and has to be managed through its own CLI. Once you have all that information centrally managed in an SDN controller, it enables you to build apps to program the network as a universal element. So this eliminates the complexity and static nature of traditional networks."
Given the early stage of SDN development, there are, of course, different takes on the definition of SDN. Metzler writes in Network World: "The definition of SDN that is currently emerging focuses somewhat less on decoupling and more on providing programmatic interfaces into network equipment, whether or not there is a separation of the control and forwarding planes. A minor reason for this shift in focus is because Cisco recently announced that as part of its SDN offerings, it will provide APIs into multiple platforms they provide." [Also see: "What is software defined networking?"]
"SDN is not equivalent to OpenFlow," says Lee Doyle, principal analyst at Doyle Research. "SDN is much broader than that. As long as you have APIs and can program the devices, it can be SDN, but it might be proprietary."
Regardless of definition, suffice it to say the broad aim is the same -- to simplify networking and to catch up to the pace of change made possible by the adoption of technologies such as cloud computing and virtual servers.
Regarding the latter, the oft-cited problem today is you can spin up 1,000 virtual machines in minutes but it will take you two more weeks to bend the network into shape to support that new environment. SDN is designed to remove the network as the bottleneck in this fluid new world.
Which gives rise to the question about the difference between software defined networking and virtual networks, terms that are used interchangeably by some and referenced as distinct notions by others.
Matlof views virtual networks as a data center thing, a way to set up virtual tunnels between virtual server elements in the data center, and views virtual networks as just one application for SDNs. In fact, he calls virtual networks the first killer app for SDN, and Big Switch has rolled out a product to address the need. But ultimately he says a true SDN should be able to do that as well as control physical devices that support the OpenFlow protocol.
Nicira, which, besides Big Switch, was one of the other SDN early birds to spring out of the Stanford labs where SDN was conceived, is focused primarily on virtual networks, what some call overlay networks. That made it a good fit for the king of the virtual machine world, VMware, which shelled out $1.2 billion to acquire Nicira in 2012.
But aren't companies that are focused primarily on virtual networks artificially constraining their opportunity? Lippis says, "If you look at the number of virtual ports to physical ports, there are more virtual ports now and the number is growing a lot faster than physical ports, so [VMware/Nicira] believes they're focused on the high-growth part of the market."
Ultimately, however, SDNs will need to span the virtual and the physical if buyers are to realize the biggest return, and they will need to span the data center and the WAN.
Early ONF backer Google, for example, has already deployed an SDN WAN backbone that is paying dividends.
"The biggest advantage is being able to get better utilization out of our existing lines," says Google Principal Engineer Amin Vahdat. "The state-of-the-art in the industry is to run your lines at 30% to 40% utilization, and we're able to run our wide area lines at close to 100% utilization, just through careful traffic engineering and prioritization. In other words, we can protect the high-priority traffic in the case of failures with elastic traffic that doesn't have any strict deadline for delivery." [For a full interview with Vahdat see: "Google's software defined/OpenFlow backbone drives WAN links to 100% utilization."]
Of course few organizations have the resources that Google does (it built the devices used to control that backbone), so much of the focus today is, in fact, in the data center.
Mark Leary, chief analyst at The First Tracks, says one of the earliest benefits of SDN will be simplifying networks. "Consolidating around a central control structure allows for greater automation. That's where you can see a lot of immediate impact."
But how do you get there from here given the huge investments in legacy gear?
"Incremental adoption is the key for success," Leary says. "The beauty of some SDN solutions is they are compartmentalized. You can drop them into some part of your network to reduce complexity and see immediate benefit. And then once you've expanded on that and finished simplifying the overall structure, SDN is about improving the dynamics, by, for example, allowing the network to adapt to load."
Lippis says one benefit mentioned by many early adopters at the first ever ONUG SDN users group meeting in Boston was network visualization. "What some companies are doing is using low-cost 10 Gigabit Ethernet switches with OpenFlow interfaces to connect mirror ports on data devices to analytic service nodes. That drastically lowers the cost to gather traffic and, since the costs are lower, gives you the ability to tap into more places so you get a larger view."
The beauty of some SDN solutions is they are compartmentalized. You can drop them into some part of your network to reduce complexity and see immediate benefit."
— Mark Leary, chief analyst at The First Tracks (www.thefirsttracks.com)
Lippis adds, however, that a lot of the early vision about SDN's role is being put forward by vendors that are just guessing what people will use it for. "It's not until SDN is in the hands of IT architects that real use cases will start to emerge."
Consider early user Indiana University. It didn't want to pay $100,000-$200,000 for a load balancer that could sit on the school's 10Gbps Internet trunk and parse out traffic to multiple intrusion detection systems for analysis, so it got creative.
"We saw this was an obvious use case for SDN and OpenFlow," says Steve Wallace, executive director of InCNTRE, the Indian Center for Network Translational Research and Education. He says they hired a couple of grad students to develop software for an OpenFlow controller that instructs a $40,000 OpenFlow-enabled switch to handle the load balancing task and have been reaping the benefits ever since. [See a full Q&A with Wallace.]
Cost savings, in fact, is one of the potential benefits of SDN. Undoubtedly other organizations will discover more SDN niche applications that deliver savings, and longer-term simplification of the network is expected to lower opex costs, but it is less clear if SDN also results in reduced capex costs.
In an article about SDN in The Economist (yes, The Economist, showing just how far this stuff is spreading), Chris Weitz of Deloitte Consulting was quoted as saying "firms using SDN can save up to 50% on their networking bills ... some of the savings [coming] from cutting out 'carbon middleware,' as network engineers jokingly refer to themselves, and from buying more basic -- and thus cheaper -- hardware."
The hardware can get cheaper, the rationale goes, because with SDN the smarts are embodied in software and shifted to the centralized controller.
But is capex the problem that needs fixing?
"I think what's driving this is operational costs, not capital costs," Lippis says. "In fact, some say the capital costs are irrelevant. They say, 'If someone gave me $2 million worth of equipment for free, I couldn't take it because I can't afford to manage it.' So if the equipment costs zero they're not going to take it, and they won't take it if it's really expensive, so the vendors really have to deal with the operational piece of this."
Over a three-year period, capital costs represent 25% of networking total cost of ownership, Lippis says. "So it's already a relatively small number, and if it goes to 12% because SDN makes it possible to use lower cost equipment, is that a big deal?"
Leary adds that simplification doesn't necessarily equate with low cost. "Leonardo da Vinci once said, 'Simplicity is the ultimate sophistication.' Just because something is simple doesn't mean it's not incredibly sophisticated underneath. As the network becomes simple, the network devices and controllers grow that much more sophisticated."
What's more, suppliers will be scrambling to differentiate themselves regarding usability, manageability, performance, capacity, etc., Leary says, so it isn't like SDN just results in networks built using a bunch of cheap, white label boxes.
That said, the real magic may ultimately be in the applications that can fly these SDN networks. Things like traffic engineering, network monitoring and even security controls become apps that run on SDN controllers.
But the ONF hasn't yet specified northbound APIs for these apps. So, while it should be possible to mix and match controllers and switches that support the ONF's southbound OpenFlow API, the SDN applications available to you today will be dependent on the type of controller you employ. Ultimately the industry needs to standardize the northbound connections to provide interoperability.