As an industry, networking has always been very dependent on standards. One big reason is the desire of operators (like all buyers) to avoid vendor lock-in. Standards tend to help make boxes interchangeable, which reduces vendors’ power to control modernization and evolution. SDN and NFV are “standards-based” technologies, so you might think they’d continue this trend. They might in fact accelerate operator choice, but for reasons a lot more complicated.
Of the two technology revolutions in networking that we hear about today, SDN is the most “traditional” because it’s aimed specifically at creating a service behavior set and not at hosting the stuff that does that. Packets go from Point A to Point B in SDN because they got forwarded along a path, and that pretty much describes what happens today in legacy networks. The difference with SDN lies in how that path is decided.
Adaptive behavior, meaning dynamic discovery of topology/connectivity, is the basis for path determination today. A router expert once told me that about 80% of router code was related to path determination, and what SDN would do is pull that logic out of devices and send it to a central control point where paths were analyzed and imposed on the network (via OpenFlow).
If path determination is the thing most impacted by SDN you’d probably think that early SDN applications focused on where it was the biggest part of the problem, but that’s not been the case. SDN so far has deployed more in the data center where path cost differences are negligible and where failure of devices and paths is rare compared with the WAN. SDN has really been driven by the need to explicitly control connectivity, particularly in multi-tenant applications.
What has SDN done to hardware? Despite all the white-box talk, not as much as many thought. The early applications have actually been more overlay-network-oriented, where we build tunnels and routes on top of traditional (usually Ethernet) connectivity. Some SDN architectures (like the original Nicira) were designed from the first to ride on legacy connectivity not displace it. This may change over time, though, because if connectivity management is ceded to higher layers, then the data center switches are just transport devices, harder to differentiate. So that gives operators more choices, right?
Actually it doesn’t. The cheaper a box is, the less differentiated it is, the harder it is to drive new player opportunities. Nobody wants to fund a startup in a space where everything looks like everything else. So where SDN is really driving operator choice is more in the software, a network area that’s only now emerging as important.
NFV is even more complicated. First and foremost, NFV separates software (in the form of embedded features or “firmware” or “network operating systems”) from hardware, which allows the underlying platform to be commoditized. Software, left on its own, is now free to innovate. The theory has always been that virtual functions hosted on commodity hardware would lower the total cost of ownership, and broaden operator choices by preventing proprietary lock-in.
It’s hard to say that will happen. Two virtual functions are interchangeable based on a bunch of qualifiers. They have to run on the same thing, do the same thing, expose the same interfaces, and be managed in the same way. If we have a service chain created to build vCPE, for example, the elements in the chain are interchangeable if all these criteria are met and any one element can be switched out for a competitive brand. Many think this is one of the goals of NFV specifications, but it’s not.
NFV does not dictate any service data plane interface, any functionality, or any management interface. Given that, vCPE created by chaining three functions wouldn’t predefine any set of interface standards to conform to. It would be a happy accident if we had three or four providers of individual virtual functions (VNFs) that could be freely substituted for one another.
What this would mean is that NFV might actually promote vendor lock-in at one level and reduce it at the level below. Software features have enough range of motion in implementation that vendors would be able to develop ecosystems of VNFs that worked well together but didn’t easily accommodate substitutions for individual functions. They would be able to pick from commodity platforms, though, right?
Perhaps. NFV is a new world, and the NFV specifications are not broad enough to define every piece of it. Operators realize that all NFV implementations are not going to be equal, end-to-end, and in fact that not all will even be able to make the business case. The NFV vendors often provide VNFs, platforms to host stuff, operations and management and orchestration. All these work within the ecosystem the vendor offers, but we already know that you can’t be sure you could substitute one VNF for another. You can’t substitute one MANO for another either, and it doesn’t appear you can substitute even Virtual Infrastructure Managers. If you buy an NFV ecosystem, you’re buying a single vendor or a vendor and specific partners.
Before you take this as doom and gloom, let me say that the long-term prospects for an open and efficient NFV implementation are very good. What we see now in NFV, and even in SDN to a degree, is a growing-pain problem. Whether it would even have been possible to standardize NFV fully, to make every piece interchangeable, is debatable. We certainly didn’t do it. That means that we’re going to have a bunch of implementations out there, each presenting a unique slant on the value proposition for NFV. The ones that get the best traction will become the focus of more partnerships, be expanded more by new product features, and will define the shape of the NFV future. The others will die off.
You can see some of this already. Alcatel-Lucent offers NFV in a sense as a carrier to mobile evolution. HP offers a broad ecosystem of partners with useful VNFs, and Oracle offers an operations-slanted vision. The differences in implementation are way more subtle than the positioning (which for some vendors is still too subtle) and the early-market drive that the vendor hopes to harness.
What will actually create an open NFV ecosystem, though, is the “service agility” driver. In order to create agile services that can be efficiently operationalized, operators will need to assemble services from little functional blocks that can be stitched together using deployment automation tools. As I’ve suggested in prior blogs, these blocks will each be “black boxes” or “intent models” representing features disconnected from implementation specifics.
The standards for interconnection in NFV will be shaped by the operators themselves when they build their service libraries. It’s just that the early winners among NFV vendors will be in a better position to help do the shaping.