Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software-Defined Networking Definition = Still Don't kNow

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.