Disclaimer: The opinions expressed in this article represent my own and not those of my employer. At work, I am an unbiased person that is trying to find the unique value proposition in any product that can help my employer's business.

I was amused to read about a recent survey of North American enterprises seeking to deploy SDN -- nearly 49% of the surveyed enterprises did not know what it means. (Musing: I wonder now whether the IDC experts defined SDN before querying enterprises for their share of the expected $360 million SDN expenditure for 2013 for their survey). This confusion is understandable. There is not one uniform definition for SDN, especially when a vendor describes their SDN solution. I speak from my experience of having been a contributor to the momentum starting with my role at Stanford and also from my experience working for a large carrier interested in SDN. At my privileged vantage point, where I get to look deeper into many a SDN solution, I meet with several SDN vendors. Almost all meetings start with them saying: “Let us tell you about our definition/perspective of SDN”.

This article is an attempt to track the different meanings and possibly take a stab at an uniform taxonomy and nomenclature.

One of the popular form of questions that folks ask after my SDN tutorials is: “Is XYZ an instance of SDN?”. Among other things, the “XYZ” has been: 1) Cisco Nexus 1000v, 2) JunOS SDK, 3) IPInfusion, 4) Linux IPtables. It brings back fond memories of the other fun exercise I used to have in graduate school of “Is ABC an instance of the end-to-end principle?” While the literal meaning of the phase “software-defined networking” is very generic and can include all above listed “XYZ”s, it is not necessarily what the phrase was originally meant to represent.

When Kate Greene (from MIT Tech Review) picked that term to represent the activities around OpenFlow at Stanford University, SDN began representing a network architecture where the control plane is decoupled from the data plane. In even more basic terms, the forwarding state is managed by the control plane and is decoupled from the data plane. This is what many of us in the community started seeing as the fundamentally new paradigm (Note: It is arguable that there have been similar split architectures in the past, but none with the sustained traction of SDN), even though almost all networking vendors build their products using software written in high-level programming languages and already had a clear separation between control and data planes within their product. So, when asked if something is SDN, I usually answered based on whether the network intelligence or state (which includes details such as topology, network workload, policies) is co-located with the data plane or not. That original definition could find solutions from some fabric vendors, like ConteXtream and Pluribus Networks, as not representing SDN. But, of course, the definition of SDN has broadened and is still broadening. In my view, the SDN definition looks like a ball of mixed play-doh.

• Broadening 1: Around the time, two years ago, when a particular virtual overlay networks-networking vendor rebranded their products to be based on SDN, the dam gates had opened and all new-age non-traditional networking solutions started being considered to be SDN-based. Overlay Networks by creating tunnels in the data plane is considered SDN, irrespective of whether the state was decoupled from the data plane.
• Broadening 2: Using open-source software in the firmware (e.g., Pica8 Xorplus, Quagga) or data plane of networking hardware (e.g., NetFPGA) is considered disruptive and also SDN. Naturally, the trend of the day was for anyone using Open vSwitch (OVS) to also consider their work SDN-based, even if they really had no decoupled control plane.
• Broadening 3: The Open Networking Foundation (ONF) was formed to standardize the open control API that was core to the SDN vision at that time. Open Networking, then, became synonymous with Software-defined Networking, although legacy vendors that did not embrace the “openness” (in API or code or technology) had solutions that resembled the original SDN definition.
• Broadening 4: Network design where one or more p-switches and v-switches work together to form a single policy front started being considered to be SDN too, irrespective of whether there is a decoupled control plane. The main reasoning behind this was that the solutions are considered to use a logically centralized control plane, even if the control plane was co-located with the data plane elements.
• Broadening 5: Why leave OpenStack (which I consider as management plane) out of this?! Most vendors building OpenStack products with network management also joined the SDN bandwagon. Extensible management planes that had multi-vendor support and worked cross-domain was born. It was the time for management plane software to become sexy again, but under the new name of “Orchestration”.
• Broadening 6: Solutions offering Network-as-a-service as their value proposition was considered SDN-based. VPN services have existed for many years, yet they suffered long customer creation time and poor orchestration. Making connectivity more flexible and dynamic, through a centralized mgmt/control plane, is considered disruptive (and consequently, SDN-based) in today’s mobile world where workload is often running in the cloud.

There were other common perceptions that have come and gone. You must have certainly heard the oft-used phrase “OpenFlow is SDN, but SDN is not OpenFlow”. This is certainly true, although it doesn’t say much to define SDN. I have met folks for whom SDN was synonymous with OpenFlow, or SDN was synonymous with Nicira, or SDN was synonymous with Network Virtualization (NV), or SDN subsumed the orthogonal effort on NFV. This incorrect view will (hopefully) change over time.

Although many of the speakers at the Open Networking Summit in April 2013 urged the community to stick to a purist definition of SDN, I suspect that the broadened definition is here to stay. SDN users find it best to classify the solutions or approaches, rather than shun solutions for its deviation from the purist view.

Today, most customers classify SDN solutions based on the deployment models (See Gartner’s brief on that). But, this is insufficient in clearly conveying the value. As a community, we should arrive at a clearer taxonomy for SDN solutions and their different aspects. It probably is too late for the Architecture Framework working group of the ONF to take charge in defining SDN. Maybe the Market Education group can evangelize an uniform definition. Here’s the tagging scheme that I (wearing my customer-hat) use to categorize products or solutions from SDN vendors, along with some examples that I see today (Caveats: 1. Products evolve, 2. the author is human):

It is certainly possible to slice the SDN pie in other ways: including based on value-proposition, control plane placement, or data plane placement. As an attempt to push for a consistent nomenclature for vendors and customers to use, I present one that works for me. By the classification I use, a product from one vendor (e.g., Nuage Networks) may span multiple categories, or another vendor (e.g., Pertino) may not have a clear fit within the SDN domain (mostly due to my lack of understanding of their positioning).

In a recent article, Mike Fratto asked “Who cares?” with regards to the definition of SDN. As far as I can tell, Venture Capitalists and Entrepreneurs used to be the biggest community that cared, because SDN had a disruptive feel to it and there seemed to be a new multi-billion dollar market in the making. Much of that market seems sufficiently addressed by several incumbents or SDN startups. I agree with Mike and others in that enterprises do not (and should not, rightly so) care whether a product is SDN-based. Enterprises only care about the new value proposition offered; it truly does not matter whether the underlying technology is based on OpenFlow, SDN or neither.

I’ll leave you with one of my favorite trick questions: If I were to run an OpenFlow Controller within the firmware of each commodity hardware switch to control its data plane, would that be considered SDN? Hmm...