Software-Defined Networking Definition = Still Don't kNow

As hot as software-defined networking is, we're still speculating about SDN's definition. There are good reasons that's the case.

You can't talk about networking today without software-defined networking (SDN) coming up. But it seems everyone has their own definition of SDN and how it should be accomplished. Who's in charge when it comes to the subject of SDN? And what exactly is it? A presentation from Infinera Corp., a vendor of optical gear, says that, depending upon one's perspective, the acronym SDN could stand for any one of four things:

Software-Defined Network, the choice of the Stanford folks who developed the popular OpenFlow protocol

Software-Driven Network, which is how the optical vendor sees it

Self-Defined Network, possibly the preferred term for marketing departments

Still Don't kNow, a view held by many techies

Strange, isn't it, that, as hot as SDN is, we're still speculating or kidding about its definition. I think there are two reasons for that. One is that if SDN, as in software-defined network, means decoupling of control and planes, then that's really changing the way networks have been built (meaning with proprietary boxes). Moreover, the success of SDN will be felt in cloud services, enterprise datacenters, service provider networks, and to enable more bandwidth for (OK, here's another buzzword) big data.

Speaking of buzzwords, until SDN came along, the focus was on network fabrics to address the challenge of the growing number of connections needed in the virtualized datacenter. Analyst Lee Doyle notes on SearchSDN that there are three strategies when it comes to the relationship between network fabrics and SDN:

In one camp, the SDN architecture and network fabric technology would be purchased from separate vendors and would operate independently with some interaction...

At the other end of the spectrum, SDN would be fully integrated with the physical network fabric, with both being provided as a joint product or architecture from the same vendor. Suppliers offering this model include incumbents, such as Cisco, Juniper and SDN startup Plexxi...

In between the two extremes, suppliers such as IBM, Dell, NEC and HP will offer data center networking solutions where SDN software is linked to, but not dependent on, the underlying network fabric.

Fortunately, there are standards organizations to straighten these things out. A group known as Question 21 (Q.21), within the ITU-T Study Group13, is developing a framework to "clarify the SDN concept, problem space and terminology." The IRTF (Internet Research Task Force), a parallel organization to the better known and standards-making IETF is looking at SDN from a research perspective.

Earlier this year, ETSI set up the Industry Specification Group for Network Functions Virtualization (NFV) to see how network appliances that provide services such as Network Address Translation, firewall, etc., can be virtualized into software running on servers. NFV can live with or without SDN, sort of like network fabrics. Also, let's not forget the Open Networking Foundation, which is not a standards organization but whose OpenFlow is the de facto solution for communications between the control and data planes.

In light of the above, when it comes to SDN one might be tempted to ask who's in charge. Actually, I will take that a step further. Given that with SDN we're possibly talking nothing less than a complete makeover of the network (something that's not going to happen overnight), I would not be surprised to see other industry groups spring up to address specific SDN-related issues.

jgherbert, I think you hit the nail on the head with your analysis. I guess the crux of it is that SDN is possible, but extremely difficult --at least at the moment -- unless you're Google or a similar company that is all about networking. For a run-of-the-mill business that uses a network just to get things done, thay most likely will not have the expertise or the foresight to figure out the issues you mention. What do you think is the best way for IT departments to learn about the new technology, especially when a lot of them are understaffed and may not have lots of time to devote to it?

To be fair, SDN is in use today; just ask Google. However, what's coming to the fore now is the consumerization (or productization) of SDN, in a variety of forms. What I'm not seeing yet are good, fully functioned, well-abstracted controllers that will deliver the promised land in terms of 'hands off' network control. But I have no doubt that they are coming. The related challenge is that there are so many approaches - both for overlay and underlay - there's no one solution in any case. Finding individual use cases for elements of a software defined network isn't so difficult, but finding the right solution for an entire data center is another thing. Assuming, that is, that there's a single solution. I suspect in actual fact we'll end up mixing and matching various elements based on our needs, and we'll end up with more than one management solution that may or may not talk to each other ;)

I was talking to a network systems integrator the other day who was telling me about some good use cases for SDN and how it could help conserve resources in health care, for instance. When I asked for more specific examples, however, he seemed shocked and said, "Oh, no one is actually doing this yet; it's just theoretical!" Note to self: Don't listen to the hype machine :)

Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.