Manage VNF deployment for IP routing and EPC


  • For faster VNF deployment, use a VNFM pre-integrated with OpenStack
  • Reduce risk with a VNF manager built for specific IP routing and EPC VNFs
  • Converge ETSI MANO EMS/NMS and VNFM functions for a more unified approach

Network function virtualization (NFV) industry hype and proof of concepts have finally turned into products for IP routing and EPC virtual network function (VNF) deployment.  As carriers prepare for commercial VNF deployment, they need to start to evaluate options for managing VNFs and their lifecycle.

OpenStack has emerged as the popular choice for building and managing VNFs, but will its in-house tool set be sufficient?  While it is the primary open-source platform in use today, many carriers still feel that on its own, it may not be adequate to perform the VNF lifecycle management tasks necessary for commercial deployments. They question whether it will provide the required speed, efficiency, and manageability.

Their concern is echoed in a recent EANTC report concerning IP routing and EPC VNF validation. EANTC states that “Lifecycle  management  is crucial for VNF deployment. VNFs can be managed by OpenStack’s in-house tools with Nova commands or Heat templates. However, this is a cumbersome method requiring knowledge of OpenStack and its command-line interfaces.”

If OpenStack is not enough, then what?

The answer is to extend the OpenStack tool set with an integrated, proven and carrier-grade VNF management solution to meet the needs of commercially deploying VNFs.  Let’s look at how a carrier-grade virtual network function manager (VNFM1) that is pre-integrated with OpenStack can help accelerate and de-risk carrier IP routing and EPC VNF deployment.

1 Note that a VNFM is as defined by the ETSI Management and Orchestration (MANO) architecture

EANTC validates Nokia VNF performance and scale

Advantages of a Carrier-grade VNF Manager

When working through typical lifecycle management tasks for IP routing and EPC VNF deployment, the following steps need to be performed before the virtual network functions can be instantiated. Without the right tool set, each step can introduce errors and delays in the overall deployment process.

On-boarding software images

Using OpenStack requires you to manually on-board and validate all the VNF software images.

A carrier grade VNFM the extends OpenStack can automate on-boarding and make it more manageable by archiving, uploading, and validating software images. This greatly increases efficiency, especially when dealing with multiple OpenStack instances.

Updating the OpenStack environment

The next step is to prepare OpenStack for instantiation of a VNF. This involves manually modifying parameters in environment (ENV) files. This cumbersome process is often error-prone. It means working with OpenStack interfaces to understand which virtual network function parameters are OpenStack resources and specifying these in the ENV files.

A VNFM can help streamline this process from parameter inputs to resource selection. This greatly reduces the chance of manual input errors.

Building the initial config file

After the ENV files are manipulated, the VNF’s initial config file must be built and uploaded to the file store. This step must be done for every VNF variant that needs to be instantiated, and for each OpenStack instance that is required.

A VNFM automates this process by generating the initial config file based on virtual network function parameters, and uploading it to the file store for each OpenStack instance.

Instantiating VNFs

Now that all software images have been successfully on-boarded, VNFs can be instantiated. With OpenStack this involves using Heat commands on a specific OpenStack instance to perform a “stack-create”. The creation can be monitored using Nova CLI or the Horizon user interface (UI). Once the instance is instantiated, the virtual network function would have to be manually discovered within the EMS/NMS.

With a VNFM, a VNF is selected from a catalog of all on-boarded images. Each item in the catalog represents a Heat Orchestration Template (HOT), which defines the personality of the virtual network function. Multiple configurations should be available within the VNFM for the different VNF variants with different VM personalities, additional data path VMs and redundant VMs.

To perform a stack creation in the VNFM UI, the user selects an OpenStack instance, provides the VNF settings, and triggers the creation of the virtual network function. The stack creation is then automatically performed and tracked for success — or an alarm is raised if a failure occurs.

By pre-integrating the VNFM with the VNF vendor’s EMS/NMS, it can be automatically discovered when instantiated.

EMS/NMS integration is also important for monitoring purposes during self-healing and scaling, and for enabling common management of physical and virtual network functions, elements, and connections.

Scaling out VNFs

Using OpenStack to perform a scale out involves manipulating a HOT to add a new resource (VM). However, the operator will have to manually track OpenStack instances and associated virtual network functions to perform the scale out.

The VNF is then manually configured to make use of the resources that have just been allocated to it. This whole process is manually repeated as necessary. There is no auto-scaling based on key performance or capacity indicators (KPIs/KCIs).

With a VNFM, an on-demand scale out can be triggered for a given VNF through a user interface.  The VNFM will automatically update the HOT for the corresponding OpenStack instance that provides network function virtualization infrastructure (NFVI) for the VNF.  It will then automatically configure the VNF to utilize the new resource.

The VNFM also enables auto-scaling by leveraging NFVI and EMS/NMS integration to provide and monitor KPIs/KCIs. Pre-defined threshold crossing conditions on KPIs or KCIs allows the VNFM to trigger an automatic scale out when needed.

Healing and assurance

Using OpenStack, VNF healing is triggered manually using a Nova command or the Horizon UI. There is no automatic healing.

The VNFM can automatically execute a sequence of VNF healing actions based on events, or on-demand through a user interface.

A tight coupling between the VNFM and EMS/NMS is required to provide a meaningful VNF assurance capability. This is best accomplished within a converged system where a rich set of assurance functions can coexist with the VNFM in a single platform.

Nokia: Carrier-grade OpenStack integrated VNF manager converged with EMS/NMS

Carrier-grade OpenStack integrated VNFM converged with EMS/NMS

A carrier-grade OpenStack integrated VNF manager

A carrier-grade VNFM included as part of an OpenStack based network function virtualization architecture offers many advantages and efficiencies. The links below describe how Nokia has introduced a carrier-grade VNF manager into the 5620 Service Aware Manager (SAM) to accelerate deployment of the Nokia Virtualized Service Router (VSR) and the Nokia Evolved Packet Core (EPC) virtual network functions.


An OpenStack integrated VNF Manager for the Nokia VSR and EPC VNFs application note

Nokia 5620 Service Aware Manager product page

Evaluating the performance of Nokia VSR and VMG webinar

Our authors look forward to your questions and comments.