One of the ironies of the emerging industry of software-defined networking (SDN) is that the various competing SDN architectures are distinguished from one another by just how software-defined they actually are.

Some vendors have a clear interest in maintaining their strongholds on physical networking appliances. It’s why earlier this year, Cisco advanced OpFlex as an alternative protocol to OpenFlow. OpFlex serves as software that defines a network, all right, so long as that network consists of physical switches — the product that continues to butter Cisco’s proverbial bread.

The alternative concept is a software controller, running on commodity hardware, that controls a network of software. Until late last month, Brocade — now Cisco’s biggest competitor in all of networking — didn’t actually have an SDN controller of its own. Its Vyatta line of network functions virtualization (NFV) components relied upon a reference architecture called OpenDaylight — open source components that lacked one critical element that only a vendor could provide: the capability to interface with components from other vendors.

Pursuing OpenDaylight
Brocade's been building its SDN and open source abilities, with the notable purchase of Vyatta - creator of an ambitious open source virtual router called vRouter - in 2012. Alongside Vyatta's Kelly Herrell, Brocade has been building a team of open source SDN experts, and distinguished engineer Tom Nadeau (pictured) came from Juniper early in 2014 to become Brocade's open source chief.

"We’re supporting, on a selected basis, the major elements from the router/switch vendors as well," said Nadeau, in an interview with DatacenterDynamics.  "And that is actually quite unique. I don’t think anybody is actually doing that, whether it be any of the OpenDaylight controllers or any of the proprietary controllers — things like VMware, Contrail, etc."

In an SDN, the controller is the gateway between the network-at-large (or the Internet) and the architecture of the internal network. It’s past this gateway where you don’t think you’re in Kansas anymore: where a door opens into a completely different and unexpected world. Being software-defined, the network from this point on can be programmed to take whatever shape is most expedient for the applications in the system that make use of the network.

It’s the least net-neutral architecture in the world, in that it places priorities on heavier workloads that consume higher bandwidths. It does precisely what advocates of an "open Internet" do not want done in the network-at-large: bends the rules to suit one kind of traffic. But since it’s all done internally, what happens in the SDN stays in the SDN.

Comparing the magic
But just like the differences between an L. Frank Baum story and a Roald Dahl story in a very similar vein, the similarities between SDN architectures disappear the deeper you get into them. And this is where the danger lies. With the controller being the central arbiter not only of traffic but the inner world in which the traffic resides, any vendor with an eye on securing its market share can create a world for itself that’s reliant upon its own appliances, making them no longer easily replaceable. This is the argument raised against Cisco’s OpFlex.

On the other hand, the argument against Brocade’s approach is twofold: First, a complete reliance upon industry standards — which is Brocade’s tack with producing essentially an enhanced OpenDaylight controller — could be a ride on a very slow train. NFV may appear to be evolving out of nowhere, but as you may recall, the Web looked that way in 1996. Now the speed of Web standards development could be eclipsed by the common millipede.

Second, x86 processors have yet to prove themselves as fast at handling very high traffic throughput as proprietary switches. Say what you will about a Cisco switch’s rigidity, but it does exactly what it’s designed to do. There’s a solid argument in favor of letting the x86 CPU handle arbitration and deterministic logic, while passing the job of executing policy to dedicated ASICs.

Brocade’s Nadeau counters these arguments with a metaphor borrowed from the magic-starved world of investment.

"We very much enable a cap-and-growth strategy for operators," he tells us.  "We have several customers now, one of which is a tier-1 telco service provider. This very large network supports a major wireless carrier, a major business carrier, and a major interconnection carrier. They’ve selected us, for starters, to run and manage their business network, which as you might expect is composed of physical hardware.

"Rather than deploying more expensive, purpose-built hardware, their strategy now is to virtualize their customer edge endpoints using Vyatta vRouters," Nadeau continues. "So that already is the start of the transition of the network, the cap-and-growth strategy. They’re able to seamlessly cap-and-grow that portion of the network in terms of physical versus virtual elements."

Teaching telcos to provision
Any such strategy will have an immediate impact on how a telco or service provider provisions its customers and manages its operations support systems, even with cap-and-growth. This customer chose to implement the Network Configuration Protocol (Netconf), coupled with data models written using the Yang language, to automate the provisioning process across multiple network layers.

"So when the SDN controller is introduced into this network," he goes on, "what we’ll be doing is basically acting as a conduit between all of those Netconf devices, and plug into their OSS northbound. The controller offers REST [representational state transfer] APIs that are fully exposed; and with fully exposed services and elements going to the controller, we can plug directly into the provisioning system at the operator. As long as the translation between their existing APIs and the controller are taken care of, that is exactly a seamless transition point. And from there, it’s a launching pad to accelerate programmability of the network. They’re going to deploy applications in the network that no longer have to talk through the OSS to get at a network element, but instead talk through the controller."

It’s a transition that can take place throughout the entire network in incremental, controlled stages. Rather than dividing the transition by topological segments, creating realms of the network with portals that lead to unexplained territories, the transition is divided by time. And for each time increment, all elements of the network remain interoperable. The old OSS can be offloaded in planned stages, and can be phased out when the network has evolved to a state where it’s no longer required.

The difference between vendors’ SDN/NFV architectures will directly correlate to the evolutionary paths of communications centers. What they become in ten years’ time may be determined by the purchasing strategies you make today.