Dialogic Blog

The Role of MANO in Moving Real-time Multimedia Apps to NFV

by Thomas Schroer

Jan 29, 2016 12:16:34 PM

nfv_mano_orchestration.jpg

Previously, I talked about the challenges of NFV. This post describes how MANO and VNFs work in an NFV environment.

Dialogic recently hosted a SDx Central Demo Friday with Oracle that included a live demonstration of interoperability between Dialogic’s media processing applications and Oracle’s Application Orchestrator.  The purpose of this demonstration was to show operators two things:

  • The Value of multivendor interoperability in Network Functions Virtualization (NFV) environments
  • How to enable automated lifecycle management of the virtualized network functions (VNFs) that make a network service in NFV environments. 

In the demo, we were simulating the effect that peaks in voice conferencing traffic had on a virtualized media server cluster that was running on discrete virtual machines in a KVM environment.  When you think about it, moving infrastructure to the cloud to support a voice and video conferencing and chat room service is quite a different approach compared to the traditional way of deploying a collection of ‘boxes” each with a different function to support an end to end service. For example, in the current approach to implement a service you’d need several discrete “boxes”:

  • A box for providing core session control functionality
  • A separate proxy server to manage the access into the network
  • A subscriber data management server that performs subscriber authentication and stores customer profiles
  • An application server to provide the service logic
  • To support the media mixing of the conferences and any transcoding needed, you’d require a media processing function

There could be other platforms required for various functions. For example, enabling connectivity to other IP and TDM networks. Then, to provide high availability you’d need duplicate boxes with load balancing devices so that if one functional element in the network fails, there’d be another “box” to take its place. Lots of discrete boxes!

In moving these functions to support real-time multimedia services like conferencing in the cloud with NFV, we’re taking a different approach, an orchestrated approach that moves beyond virtualizing these heretofore discrete functions into virtual machines. With NFV, we can now start mapping the functionality from the physical collection of multiple “boxes” into the NFV architecture by deploying these functions as VNFs in virtual machines and logically connecting them together. These functions could include media processing, IMS core session control and access, and then of course the application server. While virtualization of applications is not a new thing, one of the big differences in NFV environments is the Management and Orchestration layer or MANO.

The NFV MANO provides the brains of the NFV architecture and this is where it starts getting fun. The MANO is actually multiple layers of orchestration functionality. The top layer is the NFV Orchestrator or NFVO which provides both network services as well as resource layer orchestration. A network service is an end to end service delivered to a customer. The NFVO is responsible for chaining together the multiple VNFs to work with each other to enable the delivery of those services. In actuality, the network functions that make up a network service will probably consist of both virtualized as well as physical network infrastructure elements.

Another component of the MANO is the Virtualized Infrastructure Manager or VIM. The VIM is responsible for controlling and managing and orchestrating the physical and virtualized compute, storage, and networking resources on which the VNFs reside. This is where a cloud operating system like Open Stack and all the different variants come into play.

Finally, the actual VNFs are orchestrated and managed by a VNF manager or VNFM. The VNFM is responsible for the lifecycle management of a single or multiple VNF instances. The activities performed by a VNF Manager include things like instantiation, configuration, modification and termination of VNFs. It also performs the scaling out, scaling in, scaling up or scaling down of the VNFs it manages.  So how does the VNF Manager know to invoke and configure new instances of an application or VNF? It references something called a VNF Descriptor to create and orchestrate and manage the VNFs, which I’ll talk about in the next blog.

If you have not had a chance to check out the archived webinar I talked about, this might be a good time to do so. It covers a lot of the topics in this blog and demonstrates VNF interoperability and automated lifecycle management in NFV environments. You can watch the video below. Tweet us at @Dialogic with your thoughts.

Topics: NFV/SDN & Cloud