In part one of this series on software-defined networking, we discussed how multicore processing has enabled the performance necessary for software-centric networks. In part two, we examined the role of network-centric software in network integration. In this final part, we look at how to tell whether software-defined networking standards are truly open and interoperable.
The rise of software-centric networking will shift the burden of innovation from equipment vendors to developer communities, but for that to happen, developers and users will have to ensure that software-defined networking standards are truly open and interoperable.
Until now, vendors have had the major advantage of closed control -- or the ability to selectively ignore or extend standards to maintain market dominance. Yet for a developer community, standards matter greatly. They are the glue that gives developers a common language and ties their extensions to other systems for integration.
Ending the cycle of hardware-centric networking and vendor lock-in
The networking industry has gone through cycles of standardization/consolidation followed by innovation/fragmentation. Each cycle of innovation is too rapid for standards to catch up, so the industry fragments, with proprietary solutions dominating. Then as the technology matures, consolidation and standardization follow. For end users this cycle can be very frustrating because during the most innovative phase, they have to choose vendors and become locked in.
Software-centric networks can break this dependency by separating core functions from the innovation edge. Since the hardware is fairly commoditized and the innovation happens in software, the vendor can architecturally separate the two. The core functions -- such as routing, forwarding, inspection, etc. -- can be exposed through an API to extension software that implements features that are more fluid and less standardized. Thus, the extension or innovative feature that is implemented in software does not depend on the slower-changing core software and hardware. As long as the API is a suitably abstract and stable interface that hides architectural hardware and release differences, then the software innovation layer can evolve independently. In fact, the innovation could should be implemented by third parties, systems integrators or even the end users themselves.
The signs of truly open software-defined networking standards
To get all these benefits, the end user must be able to evaluate the “standard” interfaces and protocols presented by a software-centric network stack and decide whether they are in fact standards. Here are three litmus tests to determine truly open software-defined networking standards:
Open: A standard is only a standard if it is open, documented and free. That means no royalties, no licenses and no NDAs in order to access and build on top of that standard. If you need to jump through hoops to get the “standard,” then it is either proprietary or will become obsolete through are instance- and implementation-agnostic. TCP/IP, for example, interoperates whether it is running on a supercomputer, a smartphone, a 20-year-old FORTRAN implementation or Ruby on Rails. If the platform, legacy architecture, vendor implementation details, hardware details or other such factors “leak” through to the standard, then the standard is too tightly coupled to be broadly adopted.
Broadly adopted: The third litmus test is a quick-and-dirty evaluation of the previous two. If a standard is adopted by two or more companies that are locked in fierce competition with each other, then it is a real standard. Competitors won’t usually adopt standards that are tightly coupled to their mortal enemy's architecture or closed to outsiders. If a company is pushing a standard and doesn’t care whether its competitor uses it or not, then it is not really interested in making it a standard.
With software-centric networks, standardization can be concentrated where it needs to be: in the interface between cutting-edge innovation and stable, commoditized legacy systems. That’s the part of the architecture where innovator’s dilemma occurs for vendors and where lock-in occurs for customers. Software-centric networks push that boundary up and out of the hardware, making it possible to add a layer of innovation by third parties. That’s good news for end users who have suffered enough whiplash from the cycle of innovation and standardization that is so prevalent in the network industry.