As defined by ETSI, the Virtual Network Functions Manager (VNFM) is responsible for the lifecycle management of VNFs under the control of the NFV Orchestrator. VNFM operations include instantiation, scaling, updating, upgrading, or termination of Virtual Network Functions (VNFs).

Choosing an architectural approach to deliver VNFM functionality is a topic for which some service providers and vendors have a preferential position – either vendor-specific or generic implementation. Both architectural approaches are viable and I could write this blog about the merits of each, but I have chosen a different approach for this blog. I believe it will be more valuable for me to show how the advantages of a vendor-specific VNFM is helping our service provider customers achieve their NFV deployment goals faster, more efficiently, and with less hassle.

In one of our Tier 1 customers, the implementation of a Sonus VNFM is the agreed-to architectural solution because it enables advanced features based on specific knowledge of the VNF applications as well as support for the automation of complex VNF workflows.

Several specific advantages are:

• Auto scaling. Our vendor-specific VNFM allows for the configuration of complex rules using multiple KPIs exposed by the VNF. This contrasts with the presentation of simple KPIs to a generic VNFM, which may lead to sub-optimal scaling triggers.
• Auto healing. Based on application level status, a generic VNFM may invoke single healing actions (i.e. Nova rebuild, Nova start), requiring the VNF/VNFC to respond in a linear fashion. On the other hand, our vendor-specific VNFM can invoke a series of actions (i.e. Invoke Nova start, run a timer, Invoke Nova rebuild), based on the knowledge of the VNFC/application state
• N:1 redundancy Management. Our vendor-specific VNFM provides application specific rules for migration, upgrading and healing for N:1 configurations. The Sonus VNFM is capable of handling differentiated configurations within an N:1 cluster, which would otherwise be very complex automation with a generic VNFM. It can also keep track of the floating IP addresses that can move from one instance to another in a N:1 redundancy group and tag to the specific instance.
• Software upgrades. Our vendor-specific VNFM provides more functionality than a generic VNFM for upgrade validation, backward compatibility, and roll-back verification. A generic VNFM currently lacks product specific semantics for upgrades and is not capable of handling backward compatibility issues and allowing/disallowing rollbacks.

Most industry surveys, and market research reports, highlight that one of the most sought after values for NFV will be its ability to automate workflows and minimize (or eliminate) the need for human intervention in network operations. While I believe a generic VFNM can provide vendor independence and is the right approach for certain applications, for complex, real-time applications like session border controllers and policy servers, it cannot deliver this goal of automation. At this time, a vendor-specific VNFM adds significant value over a generic VNFM and is really the only way to achieve much of the automation and service resiliency that NFV is expected to deliver.