One of the guiding principles in NFV is introducing a high degree of automation in the process of managing and orchestrating the functional components that make up the virtualized infrastructure used to deliver services. A recent OpenStack Foundation Report summarized this concept by referring to NFV as “a new way to define, create, and manage networks by replacing dedicated network appliances with software and automation.” Automation plays a key role in NFV and in multivendor environments, and interoperability in management activities between network functions and orchestration applications developed by different ecosystem participants is of utmost importance.
In a recent webinar Dialogic hosted with Oracle we demonstrated an elastic conferencing service enabled by Dialogic virtualized network functions (VNF) that performed the multimedia processing. Part of the demonstration was to show the Dialogic VNFs interwork with Oracle’s Management and Orchestration (MANO) layer application in an NFV environment. In this demo, we showed that interoperability in multivendor NFV environments rely in part on the VNF application exposing a collection of run-time KPIs for lifecycle management. This information is consumed by the VNF Manager in the MANO layer. The VNF Manager is responsible for the lifecycle management of VNF instances and can manage a single VNF instance or multiple ones. 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, up or down of the VNFs it manages.
A VNF Descriptor is used by the VNFM to create, orchestrate, and manage the VNFs. In order for the VNF Manager to know what to do with this information, associated scaling policy specific to the KPIs are called out in the VNF Descriptor for a particular application. In addition, stack information with the parameters on how the application is scaled out is provided in an open format to allow the NFV MANO layer to initiate the required changes. For example like adding a new instance of, in the case of the demo, a media processing resource in response to changes in traffic demands for a conferencing service.
The KPIs provided are specific to the application and can help the VNF Manager make some very intelligent decisions when scaling out and scaling in capacity. Some of the KPIs relate to system information like CPU utilization and bandwidth, while others are more application specific like number of ports utilized, number of active conferences or number of active transcoding sessions. Then finally there are service specific KPIs that provide very granular information from a service level perspective such as dropped packets and video blockiness. These KPIs can be used as proxies that relate insight on the users’ quality of experience. Some of these KPIs would naturally be provided to the Element Manager and OSS/BSS layer, but nonetheless they all provide valuable intelligence to the VNF manager in deciding when and where additional capacity needs to be brought up or down.
The KPIs also need to be collected with some degree of frequency, and the associated policy rules set up to react proactively to the changing traffic and load on the applications. So for example, if the need for a new instance of a media server is predicated on a particular number of active sessions, you don’t want the VNF Manager to wait until the application has reached that upper limit to start the scaling process. The important thing to remember is that the KPIs provide the input for developing real-time analytics that enable the application of predictive self-organizing and self-healing policy rules to make the NFV smart and help the end-to-end service adhere to the required SLAs. In this manner, operational scenarios are possible that aim to ensure continuous service quality; like responding rapidly and automatically to dynamic traffic loads. So this frees up organizational resources that are currently dedicated to making manual capacity planning decisions.
If you think about it, the amount of interdependency between applications, for example in the IMS core or LTE EPC, is significant, so KPIs and auto scaling policy communicated to the MANO layer by a specific VNF will have to provide a good snapshot of the system, application and service performance characteristics. This may result in the need for additional intelligence to be shared with the VNFM and MANO in general. Let us know what you think on NFV automation. In the meantime, I encourage you to follow this link to check out a recent webinar on NFV interoperability and automated lifecycle management between our PowerMedia XMS media server and PowerMedia Media Resource Broker and Oracle’s Application Orchestrator VNF Manager. Please Tweet us at @Dialogic.