SDN architectures

CloudNFV Moves Quickly to Product Stage

The group of vendors that have come together under the moniker CloudNFV is turning its ideas about the operations and management of network functions virtualization (NFV) into deployable products much faster than expected in response to the needs of many of the dozen network operators that have seen CloudNFV demos, says the group's founder.

Veteran industry analyst Tom Nolle, president of CIMI Corp. and chief architect of the CloudNFV initiative, tells Light Reading that the group's "science project," which started as a potential proof of concept for the European Telecommunications Standards Institute (ETSI) NFV Industry Specifications Group (ISG), is being rapidly "productized" and should pop up in network operator labs in 2014. The initial products will take the form of component parts of an approach to managing virtualized functions alongside non-virtualized network functions and fitting the entire process into existing OSS/BSS architectures. (See Answering the NFV Management Challenge.)

"We had truthfully not thought about how we would sell it," says Nolle. But in meetings with operators, such as one held in Bad Homburg, Germany, in mid-October, the conversations moved very quickly from how CloudNFV's proposals were designed to how they could be implemented.

CloudNFV is a group of seven companies brought together by Nolle because they shared the view that virtualizing functions wasn't enough, believing that those functions should be incorporated into a private cloud environment. The group coalesced in mid-2013, unveiled itself in July and staged its first demo in October, a cloud-based implementation of IP Multimedia Subsystem. (See New Group Ties NFV to the Cloud.)

Nolle says the group is in "detailed discussions" with two Tier 1 network operators about "exploiting CloudNFV architecture and technology directly in their networks," and is talking to others about lab trials in the coming year. By January, the CloudNFV group will unveil the four "core operations interface modules" that will enable CloudNFV's architecture to be deployed and to be integrated into existing OSS/BSS.

Nolle notes that the network operators are clear that they are aiming to reduce operating costs, as well as improve flexibility, by deploying virtualized assets and are not targeting capex reductions: That echoes comments made in public forums earlier this year. But opex savings means integration of virtualized functions with existing operating systems and networks, since it will be a long time before everything is virtualized. (See Carriers Say SDN Won't Save Capex.)

"They wanted integration not just into their OSS and BSS but also their order management and service management practices," Nolle says. CloudNFV was already a "super set" of the ETSI group's definition of NFV, because it include end-to-end recognition and integration with legacy components, Nolle adds, and those weren't mandates for the ISG. But operators wanted even more than what the CloudNFV group had planned to deliver and those additional capabilities are being created in the four integration components being launched in January.

The four components include: a node builder, since CloudNFV considers each individual function to be a node; a service builder, which can take the nodes and create retail functions from them; a deployment manager; and a service operations manager (more on all of this to come in future articles).

With these four requirements, the basic CloudNFV architecture can be linked into real network operations, Nolle says. (You can read more about that architecture here).

The next step is to take these new developments back to operators and get their feedback, since the changes were made at their behest, he adds.

CloudNFV will continue to work with existing groups such as the ISG, and with the TM Forum : In fact it has issued a call for collaboration and sponsorship to the NFV ISG for participation in one or more of its proofs of concept and is proposing more than a dozen specific points of validation and augmentation areas based on its current work, Nolle says. The group is also reviewing an application to the TMF for a Catalyst demonstration at its event in Nice next June. (See TM Forum Sees Catalyst Role in NFV .)

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

C Chappell 11/28/2013 | 1:01:09 PM
cloudNFV Moves Quickly to Product Stage Sounds pretty cool - and just the level of abstraction needed to manage the two consistently. I look forward to hearing more.
TomNolle 11/28/2013 | 12:35:45 PM
Re: CloudNFV Moves Quickly to Product Stage Wow, that's a good question, and I hope I can answer it effectively here!  If I don't please feel free to contact me directly; my email is on the CloudNFV website.

Our vision of "derived operations" means that all management data is first extracted and stored ("Active Resource") in a structureless way, by which I mean that the data is associated with the resources that source it but not to any specific interpretive model.  However, when you define either resources or services, you can define a Management Visualizer for each structure within your definition (for a service, every component, which means legacy-based and VNF-based since it would be a best practice to define primitive components which we call "Nodes" so as to support only one deployment model within them).  That Visualizer relates the variables you elect to use to define operations at this particular point with the variables in Active Resource.  We know what variables those are becuae we record the "binding" when we provision the service--again whether it's legacy or NFV.

When you define a Visualizer, you can define management in traditional terms, meaning you can make either legacy devices or virtual functions "look" like legacy devices.  You can also make them both look like NFV elements, or like something that's neither of the two.  The expression of the management variables is totally in control of the service architect or resource/opearations specialist (depending on whether the Visualizer is in Active Contract or Active Resource).  So (I hope) to answer your question, you can use any paradigm that's workable to manage any combination of legacy and NFV resources using CloudNFV.
C Chappell 11/28/2013 | 9:23:41 AM
CloudNFV Moves Quickly to Product Stage I echo Ray's applause for CloudNFV and how quickly it has achieved an ecosystem-based implementation of the NFV MANO architecture, aligning this with TMF terminology, concepts and models. This is exciting - and helpful - stuff. I'd like to understand, though, how management of VNFs co-exists with PNFs (physical network functions). If I've understood rightly - and I may not have - at service (product) orchestration level (which, as Tom points out, sits above the NFV MANO stack and is currently the domain of existing B/OSS where service orders are captured), a technology-neutral product (service) may be decomposed into customer-facing services, resources and finally packages, any of which, at this stage of the market, might be a mix of VNFs and PNFs. During this decomposition-for-fulfilment process, VNFs are fulfilled and subsequently managed in a cloud-oriented way, which is well-described in the CloudNFV white paper. The paper points out that in the cloud world, 'there are no meaningful MIBS': indeed, FCAPS can be done completely differently in a cloud environment, which is pleasing to some operators who want to rid their architectures (eventually) of EMS/NMS and the cost they represent altogether. PNFs, on the other hand, still need to be managed using existing OSS (with the continuing opex and integration cost this entails). Does CloudNFV envisage the VNF and PNF management domains sitting side by side, meeting at the end-to-end product orchestration level ,or is there an integration that allows PNFs and VNFs at package/individual level to be managed together, in the same system? CloudNFV says that 'networks of mixed physical devices and virtual functions can be supported providing that a management system integration with the EMS/NMS/SMS of the device is available', but does that integration take place at product orchestration level in the OSS or lower down in the NFV MANO stack, eg at VNF Manager level?  
TomNolle 11/27/2013 | 3:02:56 PM
Re: New pace for NFV You're likely correct; we started off as a small group of people with a very focused objective and that's allowed us to progress quickly.  We have tried to be open, though, and we run a LinkedIn group for those who want to participate in some way.  About 20 companies have requested to become "Integration Partners" and link with us, and two have been approved and have joined in (Metaswitch's Project Clearwater IMS is our use case and Mellanox's 40G NICs and perhaps some other technology form a key part of our Active Data Center strategy).  Nobody has really given us/me any flak about "demanding" to join, though a few vendors have been miffed by our refusal to quickly approve their participation.  We're admitting companies who can extend the framework in some clearly useful way and whose inclusion doesn't stress our resourcing and our ability to keep to our schedule.
DOShea 11/27/2013 | 2:50:01 PM
Re: New pace for NFV I'm guessing the streamlined nature of this group is one of the things that has allowed it to move quickly. Are there other companies requesting or even demanding to be part of CloudNFV at this point?
TomNolle 11/27/2013 | 10:44:31 AM
Re: New pace for NFV I think that's the critical point, Carol.  We have, as a community, accepted the notion that NFV's value comes from opex and not from capex.  However, realizing an opex value proposition means managing NFV elements inside a broader service context.  How, buried in that context, does the early NFV deployment make any dent?  We need to know that.  We also need to know how we can make NFV work in current management systems without locking us into those systems, because if we are locked into current practices we have no savings in opex to look forward to.

Carol Wilson 11/27/2013 | 9:54:31 AM
Re: New pace for NFV Tom,

That blend of new and old seems to be the critical point here. Everyone insists there is no "big bang" in telecom, and as you point out, building an entirely separate parallel framework is expensive and hard to scale. 

To it's interesting to see discussion of exactly how to integrate the new virtualized network functions and software-defined networks with the existing BSS/OSS.
TomNolle 11/27/2013 | 9:20:07 AM
Re: New pace for NFV Thanks, Ray!  I think that what we're seeing now is an indication that NFV and SDN both have to evolve to a kind of product-ecosystem stage.  Operators who want opex savings from new technologies surely realize that we're not going to make operations better on a large scale with SDN- or NFV-specific changes because we can't roll out a complete network using either of those technologies except over a period of years.

The TMF's operations model has the advantage of being technology-neutral, and if we can make that work for NFV and SDN we can modernize management end to end and not just in little SDN or NFV islands.
[email protected] 11/27/2013 | 8:40:06 AM
New pace for NFV This goes to show just how the promise and potential of NFV and SDN is accelerating the pace of demand and development and, because it doesn't involve the development of new hardware, that accelerated pace can be achieved! This group hasn't even been in existence for 6 months yet!

Whatever the outcome, Tom is to be appluaded for his efforts in driving this.
Sign In