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

COMMENTS Add Comment
Page 1 / 2   >   >>
Technica34376 5/14/2015 | 5:27:37 AM
InterOperability gradually moving towards one standard Francois - do share the same view.

Yes, traditionally, but at slow pace the interoperability which is one aspect / outcome of SDN has been gradually progressing competitively, to keep up the product's agility to adapt.

This however, is per vendor choice. The progress is for sure happening in interoperability, but a single framework adaptability for non-legacy products will surely win the bid.

As rightly said by you, when we get vendor and development community and the marketing communiting come with the new openness - thats the beginning.
Francois Locoh-Donou 10/31/2014 | 2:25:39 PM
Thanks everyone for the good points We at Ciena feel strongly about the need for broad industry collaboration, and the success of these efforts depends on vendors embracing open industry standards. Until we can accomplish this, we will be significantly challenged to deliver on the promise of SDN and NFV.
ross.halgren 10/30/2014 | 5:17:07 PM
Another lesson from history - CTI Francois - This is an excellent article and I couldn't agree with you more. Another similar lesson from Telecomms Switching history can be drawn from the 1990s with the evolution of Computer Telephony Integration (CTI) using APIs for PBXs.

Initially, these APIs were closed to each PBX vendor, but API standards started to emerge such as  TAPI, CSTA or TSAPI. It would have been nice to have one standard, however, once again, a silos-mentality on a global scale would have been partly the reason for there being three standards.

Ross Halgren

Haltec Enterprises Pty Ltd
DHagar 10/29/2014 | 4:01:58 PM
Re: The Biggest Obstacle is Culture cjantz,  great remarks and insights.  That is exactly the thinking that needs to go into an eco-system.  Not everything needs to be the same, there are different designs for different purposes and values.  Your outline provides a solid framework that can truly develop a "workable" system.
cjanz 10/29/2014 | 2:55:32 PM
Re: The Biggest Obstacle is Culture APIs are part of the picture but not the entirety.  Ultimately what the industry needs is an ecosystem framework that works on two levels: a "technical" level, and a "commercial" one.  On a technical level, it must be possible to construct software, and collective software and hardware systems, from the evolving contributions and innovations of many players.  On a commercial level, it must make sense for industry participants broadly to support a framework that permits this: they must, generally, perceive opportunities as well as risks, or they will prefer to defend old models.  Open systems featuring strong industry support through open source efforts - buttressed by emerging open interface standards among the major forming system "layers" - respond best to this "techno-commercial" imperative by presenting opportunities for all players.  Whether they come from hardware or software legacies they have the chance to compete for value at any point or layer of the new software-plus-hardware system.  It is particularly important to note that this "new system" consists of software and hardware layers that do not map one-to-one to any existing ones.  Convergence – the breaking of old technology siloes – is a key feature of each forming layer, and programmability is a key attribute of the converging infrastructure layer.  So it's important to distinguish transitional steps that individual vendors and operators can take, like leveraging existing or provisional interface structures, from the end game that needs to remain the rallying point. - Chris Janz, Ciena
DHagar 10/28/2014 | 6:57:25 PM
Re: The Biggest Obstacle is Culture smkinoshita, I fully agree.  Unless there is a major drive for collaboration, the small advantages from technology alignments won't overcame the barriers to true change from silos.  I like Francois' comment on shifting from ego-systems to eco-systems.  That may be the biggest change requirement of all.
dwx 10/28/2014 | 6:18:00 PM
Re: optical vs. IP Well it really depends on how you define SDN.   I don't expect the vendors to particularly build all of the intelligence around how a network is orchestrated and programmed.  I expect them to give open access to the network elements or an intermediate controller so intelligent applications can do so.  

OpenDaylight is actually very good in how they have layered and made accessible through abstraction different areas.  So topology data could be gathered using a legacy protocol or something newer but is abstracted so a higher layer application doesn't care about whether the topology data came via different methods.  That's where the data models come into play.  Ciena is using ODL for the basis of their controller and its elements, which is a good step but then Cisco and Juniper are using their own in-house controllers which are completely different.   Maybe that's the point of the original post. 

GMPLS/RSVP-TE as an optical control plane protocol is very successful, but as an interoperable one not so much.  The real reason is there just wasn't demand for it from customers and operators.  The operational silos of transport and routing kept it that way.  Now with multi-layer SDN we may be left with "IP/MPLS" and "transport" controllers. :) 
VictorRBlake 10/28/2014 | 1:13:06 PM
Re: optical vs. IP dwrk,

If the ask for for a REST or RESTful API for provisioning -- that's a far easier task than SDN. That could be done with existing technologies and products. I thing we had a go at this with Tag switching, then RSVP / GMPLS in the OTN -- but those tried to go beyond the optical UNI into the NNI and so faltered.

Is what we (at least you and I and perhaps the author) are really asking for something like ELMI for the OTN if it is inband -- or EVEN EASIER just a published REST or RESTful API for circuit orders ? If so, apart from ONF, couldn't the author and his company Ciena -- get the ball rolling by publising their API. It seems to me that has no dependency on SDN.

[email protected] 10/28/2014 | 12:49:02 PM
Re: Biggest Obstacle is Culture And I believe some are addressing that cultural change with gusto and enthusiasm -- others, not so.

As soon as operators start talking about their 'vendor neutral' strategies, then we'll know something is up in both the demand and supply chains. 
dwx 10/28/2014 | 12:35:03 PM
Re: optical vs. IP Yes I found it interesting the call for open standards is coming from the leadership of a traditional transport equipment vendor where no vendors interoperate with each other.   I don't think the article is calling for that either, it's calling for standardized APIs into closed networks.  I'm okay with that at this point, the real key is standardized data models to gather data from and program the underlying network and not having to do it differently for different vendors.  I should be able to use the same API call to create a circuit over a Ciena network as an ALU or Infinera network.   We are only at this point however because of the lack of those equipment vendors in pushing for, adopting existing standards, and making sure they are interoperable.  SDN is the holy grail of punting device-level interoperabilityover the fence.   

Right now vendors are forced to develop their own data models and APIs while standards are hashed out, but the key is for customers to drive them to adopt standards when they reach maturity.  

Openflow isn't a key enabling technology at any network layer really, it hasn't seen any real adoption or serious development due to its numerous shortcomings.  I don't believe it will be in the future either.   Most operators don't want a centralized network model, and the reality is the control plane components in a distributed network add very little cost compared to other network components.   


Page 1 / 2   >   >>
Sign In