SDN architectures

Let's Not Kill SDN & NFV With Silos

The network is changing for the better, but there's a good chance we could squander the shift like so many similar opportunities throughout history.

The terms Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) have gone past the point of simply being buzzwords in the industry and are certain to reshape networking as we know it. Network vendors and operators across the globe are scrambling to make the most of the changing landscape, but in that scramble, there's a risk that we will repeat the mistakes of the past.

For too long, the industry has been siloed, with network designs and deployments revolving around specific vendor implementations. The networking industry resembles the computer industry of the early 1970s, where each vendor tightly controlled the software, hardware and peripherals, resulting in a proprietary, captive and expensive environment.

Predictability is seen as a bad character trait, but in networking it's where we need to head. While SDN and NFV have presented an opportunity to get there, some key ideas need to be brought forward.

First, achievement of the industry's -- particularly network operators’ -- aspirations for SDN and NFV depends on an expansive landscape of industry contributors and innovators. Establishment of a broad industry ecosystem is essential, not a series of disparate systems revolving around particular vendor implementations, forming competing siloes, and reducing operator choice.

Second, successful establishment of such an ecosystem requires embracing openness throughout the architecture.

Industry discussion -- when it comes to SDN in particular -- has largely centered on how network operators will benefit from ecosystem-based innovations, once fully harnessed. A software-driven network and application architecture, exposed through open interfaces, would create a virtual environment for innovation benefiting from a large pool of developers with diverse specialization areas.

This larger pool would in turn foster greater competition and through necessity, greater innovations as developers look for ways to set themselves apart. It can then be left to the network operators to pick and choose the most useful parts for their network, knowing full well they've been tested in the same environment in which they will be deployed.

It all sounds peachy, in theory. But motivating vendors and developers alike to agree on anything, including the standards from which they can build, has traditionally been virtually impossible in prior technological developments. Just head into any airport and check out the range of travel power adaptors -- from electrical sockets to chargers for smartphones -- to get a quick sense of just how differently we see things.

In the past we created technological advances behind closed doors. These ideas have been cut off from the rest of the world, including from those who could have provided additional stimulus and innovation. For the longest time, the "opportunity to participate" was limited to few vendors, or frequently, just one.

A prominent example would be 'closed' (unpublished or proprietary) inter-layer interfaces, better known as APIs. These typically restrict the scope of practical participation to a single vendor or, at the most, a select few within a consortium.

Can we really expect much in the way of competition-driven innovation when there are only a few horses in the race?

This closeted way of thinking has led to a series of "ego-systems" making up the networking industry. Despite claims of openness, a single vendor controls the "ego-system," resulting in limited multi-vendor interoperability and vendor-lock-in: The status quo is maintained.

The antithesis of the ego-system is the open, expansive ecosystem, where the gates are open in principle to all. An open ecosystem leverages open industry standards and works from the same foundations, ensuring those barriers remain lowered. Furthermore, no single vendor controls the open ecosystem.

The standards, the frameworks, the layers to the network of tomorrow, are already here. They just require rationalization from those within the industry to tie it all together, underpinned by broad collaboration and open source efforts.

OpenStack is one example of an open source effort that has flourished. It provides the framework for building open private and public clouds, and, broadly speaking, it's applicable to the application layer of the software-defined network.

Similar standards exist for the remaining layers of the network. OpenFlow will serve to stabilise and facilitate both SDN control layer and infrastructure layer programmability, while OpenDaylight has recently emerged as a key open source ecosystem and code base that facilitates widespread adoption of the critical SDN control layer.

These activities, along with other open source efforts, including the ONOS (Open Networking Operating System) initiative from ON.Labs, will help accelerate the adoption of SDN and NFV. ONOS is an open source distributed controller project, led by the principals from Stanford who pioneered OpenFlow, focused explicitly on highly-scalable SDN deployments.

Simply opening up the race to a greater number of innovators will offer network operators choice previously obtainable, and significant opportunity for differentiation.

The first step, of course, is getting vendors to somehow find a way to work together.

— Francois Locoh-Donou, Senior VP, Global Products Group, Ciena

Sign In