NFV Needs SDN

Oct 28, 2013 by Prayson Pate

The idea of Network Function Virtualization (NFV) is separate from that of Software Defined Networking (SDN).  However, for NFV to achieve its full potential, it can’t be limited to converting appliances to software.  NFV needs the principles of SDN to succeed.

 

Function Virtualization is a Start, but it is Not Enough

Converting a network appliance to an equivalent implementation in software will definitely provide some benefits:

  • Virtualization eases deployment for services because there is no need to roll a truck to install an appliance
  • Virtualization creates the ability to only pay for services when they are actually deployed
  • Virtualization reduces the cost of the underlying hardware

The improvements enumerated above reflect the basic benefits of NFV.  However, they don’t address the larger issues that service providers are facing.  An interesting data point is the recent “SDN and NFV Strategies: Global Service Provider Survey” (Infonetics, July 8, 2013, reproduced with permission).  On page 4 it describes one of the biggest factors driving operator interest in SDN (emphasis added):

Global view of the network for provisioning across multi-vendor networks and multiple layers: Rather than relying on each vendor’s management system to view the status of traffic and equipment in their networks, carriers want to use SDN to make all types of equipment from various vendors visible, manageable, and controllable so that services and virtual networks can be easily created and deployed across the entire network. The fine-grained control offered by SDN will enable carriers to run their networks more efficiently and minimize the amount of equipment they need, thus reducing capex costs. In addition, the visibility and management capabilities of SDN will give carriers a better view of what individual subscribers or groups of subscribers are doing and the opportunity to provide them with a higher quality of experience based on subscription level, all on an automated basis.

These surveyed service providers see value in SDN in terms of provisioning and control that eases the creation and activation of new services.  The natural conclusion to draw from this is that the real value of NFV will only be achieved when the benefits listed above are compounded by the following:

  • Ability to effectively control NFV using APIs to tie into centralized control or orchestration
  • Re-engineering of virtualized functions to enabling scaling or elasticity
  • Creation of new services built on virtualized building blocks

What does this Mean for NFV?

As described above, NFV needs SDN to achieve optimum construction and deployment of services.  What specific requirements does this put on NFV?

  • First, virtualization of functions should be implemented to comply with standard virtualized platforms i.e. VMs and packages such as OpenStack.  This ensures ease of deployment and orchestration.
  • Next, functions should be deconstructed or disaggregated to identify where the choke points are for scaling and resiliency.  Otherwise, they can't be deployed in a scalable cloud-based manner.
  • The virtualized functions should be designed to support clean machine-machine interfaces for config and control to ensure they can be integrated into an overall end-user service.
  • Finally, the virtualized functions and orchestration must be tied into a controlling application to implement a software-defined and controlled network and/or service.

Synergy!

Both NFV and SDN bring interesting capabilities to the telco service table.  However, they are most valuable when they are combined in the mixing bowl of scalable and on-demand cloud technologies.  Such combinations unleash service creation, activation and assurance for forward-looking service providers.

 

Follow the discussion and post a comment on LinkedIn HERE.

About the Author

Prayson Pate is Chief Technologist and co-founder at Overture. 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
 

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.