Two Faces of Distributed NFV

In the era of virtualization, greater distinctions may develop between carriers and the services they offer as network operators adopt unique approaches to common service delivery concepts.

One example of how different priorities can influence deployments can already be seen in the instance of Distributed NFV, one of the proofs of concept being considered by the ETSI NFV Industry Specifications Group (ISG).

The idea of Distributed NFV was first publicized by RAD Data Communications Ltd. -- not that surprising as it manufactures customer premises gear. But as a PoC, it is a multi-vendor effort including Cyan Inc. , which is providing orchestration, as well as security vendors Fortinet Inc. and Certes, whose functions are being virtualized. (See ESDN: RAD Rolls Out Distributed NFV Strategy and MWC Offers Peek at NFV Projects.)

So what is Distributed NFV? In this iteration of functions virtualization, some functionality is located at the customer premises on an X86 blade that, for the PoC purposes, is part of RAD's box, which serves as the network interface device. Having some programmability at the customer premises, rather than locating all the intelligence within the network's core, creates different service possibilities.

The PoC sponsor, CenturyLink Inc. (NYSE: CTL), looks at Distributed NFV as an opportunity to advance its managed services strategy, says James Feger, VP of Network Strategy and Development.

"One of our challenges as a company is getting the functionality into the customer suite or customer premises with requests for services and features rapidly changing," he tells Light Reading. By creating a virtual gateway or virtual network interface device (NID) at the customer premises, there is the potential of having a remote resource that becomes part of the virtual service environment and can be programmed with different settings as services change or evolve.

"So things we might want to host in our facilities and data centers and [central offices], like firewall services, could be augmented by having some of that at the premises," he notes. "It's just a matter of which locale makes more sense for that specific function. If you look at something like application awareness, for instance, it could make more sense to have that inside the customer premises versus having it northbound in the network."

From CenturyLink's perspective, the distributed NFV option complements a broader virtualization strategy -- but the jury is still out on what functions best at the edge versus the core, and thus the need for the PoC.

Masergy moving ahead
By contrast, Masergy Communications Inc. , a competitive service provider also focused on managed services, sees Distributed NFV as something it can deploy now, for the express purpose of eliminating most of the hassles it currently faces with maintaining CPE.

"The way we look at something like NFV is that our customers don't really care what the technology is," say Tim Naramore, CTO. "They are pushing us to eliminate all the local premises functions for them, as quickly as possible."

Masergy wants to use Distributed NFV to eliminate multiple discrete boxes at the customer premises, and create cloud-based control of most functions, to eliminate the need to maintain that gear and keep it certified and up-to-date for compliance purposes, Naramore says.

"Having intelligence in a device on the premises and the ability to load VMs [virtual machines] on that and run things opens up a new breed of things for customers," Naramore says. "And they are pushing us to do this."

Both Naramore and Feger say there are things that can't be virtualized and distributed for multiple reasons.

It can also be argued that distributing functions using a vendor box such as RAD's falls short of the virtualization goal of using off-the-shelf hardware in a more 'open' approach, but as Heavy Reading Senior Analyst Caroline Chappell notes, there are practical reasons for considering both options.

"It makes sense to use what you've got instead of putting something completely new in place," she says. "And the actual functions are running on an X86 blade on [RAD's] box. Presumably, you can add anything that can run on an X86."

Having a common orchestration layer may satisfy enough of the "open" requirements that, if pushed further, become impractical.

"We've seen some rowing back in terms of how 'open' all this environment can be," she notes. "There is an argument that the openness is coming from that fact you are using a common service orchestration layer."

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