NFV (Network functions virtualization)

Building NFV on the Best Thinking

In exploring the latest news from the CloudNFV group, one particular facet of their approach caught my eye. Although they came together to build on the proofs of concept approach established by the European Telecommunications Standards Institute (ETSI) NFV Industry Specification Group, the technology companies who comprise CloudNFV are making a concerted effort to capitalize on the work already done by other organizations, namely the TM Forum , the Internet Engineering Task Force (IETF) , and OpenDaylight (See: CloudNFV Moves Quickly to Product Stage and New Group Ties NFV to the Cloud.)

Perhaps because CloudNFV is focused on helping service providers introduce network functions virtualization (NFV) into their existing networks, and thus interfacing with existing network management systems and services, the group is more active in connecting with previous work done by these other groups to more quickly move NFV forward.

For example, CloudNFV is assuming NFV is going to use software-defined networking to talk to the legacy network, and it is choosing to use OpenDaylight's software-defined networking (SDN) controller for its initial implementation of something it is calling a service model handler. The service model handler takes abstract descriptions of specific requirements and converts them into a command for either a virtual or physical network element, depending on which is being used.

According to CloudNFV Chief Architect Tom Nolle, the president of the CIMI Corp. consultancy, the group also tapped "the best thinking" of the IETF and the TM Forum to support the Active Resource and Active Contract concepts. (See: Answering the NFV Management Challenge.)

Active Resource is based on the IETF's infrastructure to application information exposure spec, known as I2AEX, Nolle says, and no, I'm not going to explain that further because this is a blog, not a white paper. And Active Contract draws on a Forum spec call GB942.

"GB942 basically says that in an automated OSS/BSS environment, the service automation processes are exercised through the intermediary of the contract because the contract records the resource commitments," Nolle explains. In CloudNFV's world, when a service is provisioned, the Active Contract contains bindings between the service and its resources, which can be legacy or virtualized.

CloudNFV also draws elsewhere on the Forum's Information Framework, known as SID.

Nolle acknowledges that others are doing similar work to the CloudNFV but not going about it in the same way. The group he leads is also reaching out to vendors, such as Alcatel-Lucent (NYSE: ALU), offering to integrate its approach into what other folks are doing, but hasn't yet received a response. (See: Collaboration Fever Overtakes SDN/NFV.)

I know there are other vendor-created consortia or ecosystems exploring how to incorporate what legacy systems have done prior -- I'm interested to know if anyone else is looking in similar directions to the CloudNFV group. What other options exist to blend the legacy and the virtual in a practical and efficient way?

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

TomNolle 12/3/2013 | 8:09:25 AM
Re: Moral of the story The NFV ISG has a similar goal; they're trying to identify standards to guide NFV deployment and not define new ones.  It takes too long to get something standardized and even longer to get a new standard implemented!

We're particularly interested in harnessing the SDN work, which is why Open Daylight is so important.  CloudNFV issued a Call for Contribution on the Open Daylight Service Model Handler, and if anyone out there is interested in participating in this key part of the project please let me know!  Service Model Handlers are the bridge between NFV-modeled services and both network and cloud infrastructure, so it would be great experience and exposure.
DOShea 12/2/2013 | 9:14:58 PM
Moral of the story I guess the lesson here is don't re-invent the wheel, right? A basic lesson, but one that some standards groups may have not paid attention to. In trying to position their new technology, they sometimes fail to consider how much tie-in to legacy standards and systems is necessary.
Sign In