2 Virtual Network Functions Manager Overview

VNFM automates lifecycle operations for VNFs, as each VNF is managed independently.

To deploy DSR it requires creating and instantiating minimum two VNFs:

  • Network OAM VNF
  • Signaling VNF

Signaling VNFs can be instantiated any time after the network OAM has been instantiated.

The main objective of the DSR VNFM is to provide an ETSI-compliant VNFM manager. VNFM would be beneficial in the following ways:

  • Automating lifecycle management (LCM) operations for DSR VNFs. Automation of these operations can reduce their execution time.
  • Providing a standardized interface to easily integrate with automation clients, especially ETSI-compliant NFVOs. The DSR VNFM provides a REST API that complies with ETSI NFV-SOL 003.

The VNFM is also helpful in responding quickly to changing customer requirements and delivers solutions for those requirements in a very short time.

The following figure illustrates the interaction between various components of DSR and VNFM:

Figure 2-1 ETSI MANO Specification

Interaction between DSR VNFM Components

2.1 Advantage of Using VNFM

Deployment of Virtual DSR (vDSR) is performed by the following methods that requires manual processing:

  • VM creation and installation process
  • HEAT Template based installation (HEAT templates require manual updates)

The manual deployment consumes multiple hours to deploy a fully operational DSR and the HEAT template based installation needed more caution since it requires more manual work.

Using DSR VNFM, users can deploy an operational DSR on OpenStack within 20 minutes.

This application benefits both the internal and external customers by reducing operating expenses associated with the implementation and by reducing human errors by eliminating manual intervention.

VNFM V1:

The Current VNFM supports both VNFM v1 and v2, VNFM v1 is the existing VNFM.

Swagger URL: https://<<VNFM HOST IP>>:8443/docs/vnfm/v1/

VNFM V2:

VNFM comes with new version of VNFM i:e; VNFM - V2 which supports Cloud Service Archive (CSAR) based VNF deployment. It is compliant with ETSI spec 003 3.6.1. This is Orchestrator mode of deployment for both VNFM and VNFs.

Note:

  • For Instantiate VNF operation, required details need to be provided from Orchestrator and the sample "vnfConfigurableProperties Json" are given below for all the Instantiate VNF scenarios of VNFM - V2.
  • For other APIs like Scale, Heal, Operate and Modify, the Additional Parameter Json for VNFM V2 is same as like VNFM V1 and these details we need to provide via Orchestrator as VNFM V2 is Orchestrator mode of deployment.

Swagger URL: https://<<VNFM HOST IP>>:8443/docs/vnfm/v2/

vnfm_version: Based on API request on particular operation for VNFM v1 or v2, the vnfm_version will change in URL.

Example: URL: https://<<VNFM HOST IP>>:8443/vnflcm/<<vnfm_version>>/vnf_instances/< VNF ID received from create request>/instantiate

VNFM v1: URL: https://<<VNFM HOST IP>>:8443/vnflcm/v1/vnf_instances/< VNF ID received from create request>/instantiate

VNFM v2: URL: https://<<VNFM HOST IP>>:8443/vnflcm/v2/vnf_instances/< VNF ID received from create request>/instantiate