The continued buzz over software-defined networking (SDN) is creating the usual “specification creep”, where so many things are claimed to be part of an SDN strategy that we lose sight of what such a strategy would be able to accomplish and what it might look like. This seems like a good time to summarize those points, with links to current market issues.
First, SDN has two three “flavors”; loose construction, strict construction, and no construction. Loose SDN means that software control over network behavior, including segmentation of address space and traffic control, can be exercised by manipulating current protocols and devices. Strict SDN means that the adaptive behavior of current devices is eliminated in favor of central control, creating forwarding paths by explicitly setting forwarding-table entries. No-construction SDN means that the SDN is simply an overlay that segments address space but doesn’t involve network devices at all.
Second, central control of network services (“strict construction”) demands that the topology and state of the network be reflected back to the control point, or proper decisions on forwarding and traffic management cannot be made. There are no mechanisms for this in the current standards, and it’s reasonable to assume that “probes” or “monitoring” could provide much of this information. However, the control paths themselves have to be established in some way, which creates a “boot-from-bare-iron” problem for strict-construction SDN that’s still to be resolved. How can you command a device to set up paths without paths to carry the commands?
Third, it is HIGHLY UNLIKELY that strict-construction SDN could scale to a large global network. At the least, we’d have to conceptualize the network as a series of SDN domains where SDN principles were obeyed within the domain but where something else (perhaps even BGP) controlled the boundary interactions. SDN is an “intranet”, so it works best inside something where there’s high traffic to generate a lot of traffic engineering benefits, but not a lot of ROUTES that would stress central control. Inside a cloud is great, and so is inside a CDN or even a metro area. Metro, in fact, is likely the secret sweet spot for early SDN deployment.
Fourth, adherence to OpenFlow is not a useful test for SDN compliance at this point in time. OpenFlow is far from sufficient to create/define an SDN with adequate functionality. You have to define an SDN by its northbound interfaces—what does the SDN let the applications do to define the network? Segmentation, security, traffic management, quick response to failures…all of these capabilities have to be available to software or we’re cutting the benefit case and eroding the value proposition.
The real structure of the SDN has three layers—the “Cloudifier” that presents an SDN virtual network interface to things like a cloud computing management API (OpenStack’s Quantum, for example), the “Topologizer” that sits at the bottom and collects information about the network itself, and “SDN Central” that maps services to the top based on conditions below. OpenFlow simply provides a command conduit between SDN Central and the lower devices. It’s all this stuff that a vendor SDN strategy has to provide, not just OpenFlow support. Put into this perspective, we can see vendor strategies largely dividing into three camps.
The first camp says “SDN is real and I want a piece of the action”, and this means quickly creating the functionality of those three critical SDN layers and exercising that functionality through existing network interfaces and protocols. Why? First, because we can’t fork-lift our way into SDN. Nobody will go. Second, because vendors don’t obsolete their own equipment, they migrate it. We can make a three-layer SDN cake control OpenFlow devices in the future, but they can also control current devices in the present. Even where OpenFlow is supported on those devices, it’s likely the network would work better if SDN were applied in loose-construction form while those devices dominate.
The second camp consists of those who are actually looking at OpenFlow as the heart of SDN. One sub-group of this camp is focusing on controlling devices without specific regard for how the software decides what it wants done. The three layers of the mandatory SDN cake have to be provided by some unspecified partner. The other sub-group is simply SDN-washing. They do OpenFlow and say they have an SDN strategy.
The final camp comprises those who contain/bound SDN application to contain the issues of our three layers. They may be data center players, or metro players, or optical/SDN players, but the common point is that they’re limiting the impact of the general lack of development in our three-layer critical SDN structure by limiting the scope of deployment.
What makes a “good” SDN strategy then? The answer in my book is a solution that starts with our third camp, defining a market entry point for their SDN that’s first one where incremental deployment is likely and second that can showcase benefits quickly. This must then be extended with an ARCHITECTURE for SDN that creates our three-layer cake and lets it be extended using strict-construction principles to “intranet” SDNs and by loose-construction principles to global networks.
Who has this? Nobody, yet, or at least nobody that’s articulating it in public. I think Cisco is aiming for this market, and from the recent announcement of a stealth SDN startup partner, Alcatel-Lucent is likely doing the same thing. For the other network vendors, we simply don’t have enough information. Ericsson has arresting metro-SDN capability they inexplicably won’t talk about. Huawei and Juniper have an architecture they don’t seem to be applying to any products, and NSN has been largely quiet. Startups like Big Switch and Plexxi have components of the solution that need to be framed as part of a larger story; they’re an SDN intranet looking for something to be “inter” with. If Cisco or Alcatel-Lucent (or both) manage to put the intranet-plus-architecture story into play, they will put tremendous pressure on their less-articulate competition. That may be what Cisco’s Chambers means when he said that Juniper might face unexpected SDN headwinds.
We’ll likely see some real SDN progress in 2013, but for sure we’re going to see more SDN obfuscation. Let’s try hard not to lose sight of the SDN mission and value proposition in the marketing melee.