Carrier SDN

Collaboration Fever Overtakes SDN/NFV

The CloudNFV group lifted its veils this week, naming five vendors involved in its ecosystem, in addition to the CIMI Corp. consultancy headed by Tom Nolle.

The group has been very open about its approach, and now about its members, each of whom fulfills a different function. But its announcement is reason to review whether ecosystem creation and other forms of collaboration have become a key step in the development of new virtualization technology for the telecom network.

There are already other ecosystem efforts, such as Cyan Inc. 's Blue Orbit ecosystem focused on software defined networking and the Metaswitch Networks Project Clearwater, aimed at open collaboration around IMS for virtualized data centers; as well as the OpenDaylight effort around SDN. (See Cyan Builds an SDN Club, IMS Gets Some Open-Source Love, and What Open Daylight Really Wants to Do).

And those are in addition to the original collaborative efforts, OpenStack for virtualization and the Open Networking Foundation 's OpenFlow effort for SDNs. Oh, yeah, and the European Telecommunications Standards Institute (ETSI) network functions virtualization (NFV) working group.

All of these efforts, as well as individual vendor initiatives such as Alcatel-Lucent's Cloudband, are aimed at speeding deployment of disruptive virtualization technology, but at some point, do vendor ecosystems and collaborative efforts become competing efforts and self-defeating propositions?

It's all too easy to be cynical, once you've seen how well-meaning efforts to transform massive telecom networks always seem to come up short of their lofty goals. But I think there are clear indications that some the collaboration efforts we are seeing have a chance to put the pedal to the metal on virtualization, for a couple of key reasons.

Here's the first: There are clearly defined goals and deliverables for some groups -- I'd put CloudNFV at the top of this list. Its six vendors -- Overture Networks Inc. , Qosmos , EnterpriseWeb LLC , Dell Inc., 6WIND , and a vendor to be named later -- each is playing a specific role in delivering on an approach to NFV that is clearly laid out but the group collectively is promising to support open interfaces that prevent vendor lock-in.

Any group without similarly defined goals, an established timetable, and a commitment to openness becomes suspect.

The second key reason I think these ecosystem/collaboration efforts could pay off in delivering virtualization to market faster is that SDN/NFV touch every segment of the network and any effort to push forward without acknowledging that is doomed to failure. The alternative to collaboration among many different vendors is allowing a handful of large vendors to exercise control, and that approach, by definition, limits the freedom and threatens the openness of the final solutions.

Can these collaborative efforts become vendor promotional? Absolutely. Will all of them succeed, or accomplish what they have promised the market? Probably not, and likely there will be duplication of effort. But they stand a good chance of contributing to how virtualization ultimately plays out in the greater telecom network, and I doubt we've seen the last of them.

— Carol Wilson, Editor-at-Large, Light Reading

Shantanu Bhattacharya 9/6/2013 | 1:59:49 AM
Collaboration in SDN-NFV front Deep level of engagement and collaborations at all fronts needed to reap the maximum bebefit of SDN and NFV. Telecom operations need them at the soonest to optimize operation and cost.
Dredgie 8/20/2013 | 12:55:03 PM
Re: Catch the fever I guess the point is that a large number of carriers across the spectrum and select vendors are working together to realize and deliver on the promise of NFV. Not unprecedented, but pretty rare. The ISG is not a standards body. They don't create protocols or define APIs. They are developing requirements and architecture specifications for the hardware and software infrastructure required to support virtualized functions, as well as guidelines for developing these network functions. They are trying to incorporate existing virtualization technologies and prevailing standards while reaching out to the appropriate standards bodies, committees and WGs (IETF, ONF, TMF) when they identify gaps. Joining the ISG also doesn't require being an ETSI member, so its pretty much open to anyone.

NFV does include elements of data center SDN, of course, triggered by the NFV orchestrator when it determines network topology changes are required to meet service demands. CloudNFV will use openstack APIs for this and other orchestration requirements in their PoC.
Marc Cohn 8/20/2013 | 9:54:36 AM
Industry collab will lead to true openness Network Function Virtualization and Software Defined Networking momentum continues to grow, propelled by strong end-user demand for methods to better monetize and optimize network operations.  However, there is no doubt a tradeoff between time-to-market and the degree of openness is required for this to be achieved.

Long-time standards participants would no doubt agree that the standards process necessitates compromise, collaboration and diversity of opinion - all of which make the process take time and the technical outcome sub-optimum (vs. a proprietary solution). While we applaud the objectives of the vendor-driven initiatives to accelerate adoption for NFV and SDN, such efforts to not achieve the expansive openness required for these broad initiatives.

Both the ETSI NFV Industry Specification Group (ISG) and the Open Networking Foundation are stressing early implementations to encourage adoption, but in a truly open and collaborative forum. With more than 100 members in each group, including the world's leading Network Operators, both the NFV ISG and ONF are making great strides while encouraging (not circumventing) openness.

(Full disclosure: I am an active participant in the ONF and the Ciena delegate to the ETSI NFV ISG)
sam masud 8/19/2013 | 1:46:20 PM



Does the issue of "open" apply to NFV? My understanding is that NFV is about virtualizing certain network functions by having them ported from closed boxes to COTS servers, whereas open, at least  as applied to SDN, is generally taken to mean a separation of data forwarding from control--which then requires an open API like OpenFlow between the controller and the switch.
@mbushong 8/19/2013 | 10:42:45 AM
Re: Catch the fever I wonder a bit what "commitment to openness" means practically. Open is likely to vague to be actionable. Generally, open is used interchangeably for standards-based, interoperable, interchangeable, open access, and open source. These all have meaningfully different definitions with significantly different benefits.

And where these bodies are concerned, I would guess than a sixth definition might prove most useful: open meaning transparent.

One of the issues that has dogged some of the early SDN bodies is the lack of transparency into how things are organized and how decisions are made. Bodies that realize this are likely in a better position to stay transparent and potentially win better favor with the user community.

I love that the industry is collaborating more. I believe it will end in better solutions, but I agree that a lot of the efforts will not take off. I like NFV and OpenDaylight. I wonder which others will also make a solid run at it.

-Mike Bushong (@mbushong)

JimTheodoras 8/16/2013 | 5:24:03 PM
Catch the fever Carol,

Of all the fevers I can think of, this is a good one to catch (and spread). The "magic" of SDN/NFV can only be realized through true "openness". As you clearly highlight, any organization without a clear commitment to openness is indeed suspect.
Sign In