NFV (Network functions virtualization)

ESDN: RAD Rolls Out Distributed NFV Strategy

NEW YORK -- Ethernet & SDN Expo -- In the race to virtualize network functions and centralize control of software-defined networks, there is good reason to consider the value of keeping some intelligence in the most distributed locations, namely the customer premises.

That's the thinking behind the distributed Network Functions Virtualization (NFV) philosophy of access equipment vendor RAD Data Communications Ltd. , which debuted the strategy this week at ESDN in a presentation by Yuri Gittik, chief strategy officer. In order to deliver service assurance for Ethernet and other IP-based services, network operators need to retain some functionality at the customer premises, Gittik says.

Distribution of virtualized functions was originally part of the NFV thinking, but it has been overshadowed, Gittik told Light Reading in an interview. One of the early objectives of NFV is to make sure there is flexibility in assigning virtual network functions to hardware -- and some of those functions are best assigned to customer premises-based gear.

RAD had actually begun developing its strategy ahead of the announcement a year ago of the NFV working group within ETISI, Gittik told us, but was spurred on by NFV's development.

"Distributed NFV is not our invention but it has our attentiveness," he said.

In today's environment, vendor-specific routers are limited in functionality and expensive to track, service, and maintain, notes Gittik. There is the temptation in the NFV evolution to virtualize the functions of CPE and pull it into the network as software, running on relatively dumb -- and therefore low-cost –- end points. RAD's problem with that thinking is that it ignores the value of what should located on-premises, as an extension of NFV.

For example, loopback testing, security functions such as firewalls, WAN optimization, and traffic conditioning could be virtualized, but centralizing them in the network can degrade their performance and may wind up costing service providers more money in networking costs. These functions need to remain at the customer site.

"Virtualized functions that sit in the network may be saving IT resources, but those go together with network resources," Gittik explained. Centralizing critical functions will require greater network resources with high reliability, which could actually eat up the IT savings.

What makes more sense, according to Gittik, is to virtualize functions but locate them where it's most important, based on feasibility, performance, cost, and policy. For example, in some cases, corporate information needs to be hosted at a specific site, or regulatory rules require information be located within geographic boundaries.

Gittik feels the beauty of NFV is that it will enable this distributed model and create new efficiencies in the process.

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

sam masud 10/7/2013 | 3:34:48 PM
Re: Nothing new Is anyone other than RAD making the argument that some network functions need to be in customer premises as opposed to being centralized?
Carol Wilson 10/3/2013 | 5:45:35 PM
Re: Nothing new RAD's point is that NFV doesn't HAVE to mean migrating all those functions to a centralized place - it's possible to virtualize without centralizing. How do you do loopback testing unless there is some functionality in the CPE? Yes, the CPE is lower cost and lower function but it's not without intelligence.
dwx 10/3/2013 | 2:56:23 PM
Nothing new I don't get it.  

There have been CPE devices from vendors which do firewalling, wan acceleration, and other tasks for as long as there has been CPE devices.  And folks have been using x86 servers in the same role for decades.   Of course there will be instances where those types of devices are required on premise.  

True NFV is migrating those services to a more central or cloud virtualized platform where the premise equipment can be a very low cost CPE doing perhaps only an IPSEC tunnel to a gateway.   Today people deploy fairly expensive devices to do those functions for a customer with a 5-20Mbps circuit. You could probably run 200 firewall instances on a single x86 server in the "cloud" for that amount of traffic.  


DOShea 10/3/2013 | 12:17:55 PM
Virtualization centralization The question of how virtualized is too virtualized is already out there. Now, the question of how much centralization is too much joins it, and is sure to generate a lot of debate.
Sign In