NFV Evolution Versus Revolution

Dec 23, 2013 by Prayson Pate

Today's Virtualized Network Functions (VNFs) are somewhat limited in number and variety.  Furthermore, many of these VNFs are fairly simple and evolutionary adaptations of todays’ dedicated network appliances.  This is a good start on the road to Network Functions Virtualization (NFV), but it is not enough.  True progress will require a revolutionary approach.

Overture’s Ramesh Nagarajan has recently written in this space about some of the changes that will be required in VNFs, including elasticity, reliability and management. He also touched on how VNFs can be combined to create new services.  This blog will expand on those topics.

Decomposition

One of the first steps on the path to revolution is the decomposition of network element functionality into a set of lower level functions.  For example, a typical CPE router today may include functions such as VPN, firewall, security, access control and WAN optimization in addition to basic routing.  These functions need to be separated out into their own VNFs to allow the optimum construction of new services.

Cloudification

The next step toward revolution is to “cloudify” the VNFs by adapting them for deployment in modern datacenter infrastructure.  This means re-targeting to run inside a virtual machine, support for elasticity or horizontal scaling, separation of compute and storage functions and modification of licensing to support an on-demand pay-as-you-go-model.  These modifications will enable the VNFs to be optimally deployed and composed into higher level services that can optimally use the underlying cloud resources.

Relocation

The final step towards revolution is the ability to relocate network functions to the optimum location in the network.  The definition of optimum will vary by service and service provider, but the competing requirements will be similar.  They include:

  • Cost and availability of resources: servers will be cheaper and more plentiful in a data center than in a central office or customer site.
  • Available bandwidth: the metro edge has less bandwidth than the core of the network.  Placing a function in a data center or at the customer site may minimize the needed bandwidth in different scenarios.
  • Latency: Some applications are very sensitive to latency or latency variation, while others are fairly insensitive.  The ability to relocate functions to meet the latency requirements of various services will enable the efficient creation of new services.

The Result – A Service Revolution!

Once VNFs have been created in a modular, cloudified and relocatable fashion, it will be possible to rapidly create and deploy new revenue generating services that achieve the dream of NFV: innovative services, built from an ecosystem of best-of-breed software components, running on standard cloud infrastructure.

About the Author

Prayson Pate is SVP of Engineering and Chief Technologist at Overture, where he is also a co-founder. Prayson is a technology evangelist with a proven track record leading teams and delivering products. Since 1983 he has been building Carrier Ethernet and telecom products for service providers and network operators around the world - both as an individual developer and as a leader of development teams. Prayson spends much of his time driving adoption of Overture's new Ensemble Open Service Architecture, which includes aspects of automation, virtualization, SDN and NFV. He has a BSEE from Duke, an MSECE from NC State and is the holder of nine US patents.
 
Follow Prayson on twitter: @praysonpate
 
Tags: Cloud, SDN, NFV

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
By submitting this form, you accept the Mollom privacy policy.
To prevent automated spam submissions leave this field empty.