Generic VNF Manager

The Generic VNF Manager is an implementation following the ETSI MANO specifications. It works as intermediate component between the NFVO and the VNFs, particularly the Virtual Machines on top of which the VNF software is installed. In order to complete the lifecycle of a VNF, it interoperates with the Open Baton Element Management System (EMS) which acts as an agent inside the VMs and executing scripts contained in a VNF package or defined via the scripts-link inside the VNFD. This VNFM may be assigned to the management of a single VNF instance, or the management of multiple VNF instances of the same type or of different types.

The Generic VNFM handles communication between the NFVO and the EMS. The communication NFVO ↔ VNFM ↔ EMS is done using the AMQP protocol over RabbitMQ.

The communication between the NFVO and Generic VNFM:

The communication between the Generic VNFM and EMS:

As you can see, the Generic VNFM sends commands to the EMS, which is running in the VM. Then the EMS executes the commands (scripts) locally in the VNFC. Please note that the EMS executes those scripts as root user. The following sequence diagram explains the communication messages.

The Generic VNFManager is supposed to be used for any type of VNF that follows some conventions regarding:

• VMs deployment
• Script execution costraints
• VMs termination

VMs deployment

Accordingly to the ETSI MANO B.3 the VNF instantiation flows can be done in two ways:

1. With resource allocation done by NFVO
2. With resource allocation done by VNF Manager

The Generic VNFM follows the first approach. In the first approach two messages will be sent to the NFVO:

• GRANT_OPERATION message: check if the resources are available on the selected PoP. If the GRANT_OPERATION message is returned, then there are enough resources, otherwise an ERROR message will be sent. After the GRANT_OPERATION message it is possible to send the ALLOCATE_RESOURCE message.

• ALLOCATE_RESOURCE message: This message ask the NFVO to create all the resources and then, if no errors occurred, the ALLOCATE_RESOURCE message will be returned to the VNFManager. Only the VNFMs which follow the first approach need to send this message.

After that point the VMs are created and the VNF record is filled with values, such as ips, that can be found directly in the VirtualNetworkFunctionRecord→VirtualDeploymentUnit→VNFCInstance object.

Script Execution Costraints

For each operation of the VNF Lifecycle Management interface, the VNFManager sends scripts to the EMS which executes them locally in the VMs.

Note: The scripts come from the VNFPackage which you need to create (see VNFPackage documentation).

The ordering of this scripts is defined in the NetworkServiceDescriptor from which the NetworkServiceRecord was created, in particular into the NetworkServiceDescriptor→VirtualNetworkFunctionDescriptor→LifecycleEvents. Here an example (to make it more readable it is shown only the VNF lifecycle event part):

{// NSD
  ...
  {// VNFD
    ...
    "lifecycle_event":[
        {
            "event":"INSTANTIATE",
            "lifecycle_events":[
                "pre-install.sh",
                "install.sh"
            ]
        },
        {
            "event":"CONFIGURE",
            "lifecycle_events":[
                "server_configure.sh"
            ]
        },
        {
            "event":"START",
            "lifecycle_events":[
                 "start.sh"
            ]
        },
        {
            "event":"STOP",
            "lifecycle_events":[
                 "stop.sh"
            ]
        },
        {
            "event":"TERMINATE",
            "lifecycle_events":[
                 "terminate.sh"
            ]
        }
    ],
    ...
  }
  ...
}

In the following table is described for each VNF lifecycle event when the scripts are executed.

VNF Lifecycle event	When scripts are executed
INSTANTIATE	During the instantiation of the corresponding VNF
CONFIGURE	After the instantiation. Useful if the VNF depends on other VNFs, because we can get parameters provided by them (e.g. IP). The parameters are available as environment variables (see later).
START	After the instantiation or configuration (It depends whether the event CONFIGURE specified).
STOP	During the stop of the corresponding VNF
TERMINATE	During the termination of the corresponding VNF
SCALE_IN	When the VNF is target of a scaled in vnfcInstance

The available parameters are defined in the VirtualNetworkFunctionDescriptor fields:

• configurations: it contains specific parameters which you want to use in the scripts.
• out-of-the-box: the following parameters are automatically available into the scripts:
  1. Private IP
  2. Floating IP (if requested)
  3. Hostname

In the INSTANTIATE scripts, the parameters defined in these two fields are then available as environment variables into the script exactly as defined (i.e. you can get by $parameter_name).

In the MODIFY scripts, the INSTANTIATE parameters are still available but plus there are environment variables that come from other VNF sources, where they are specified in the provides field. These kind of parameters are defined in the requires fields (of the VNF target) and the VNFDependency→parameters fields (of the NSD), and are then available as $type_of_vnf_source_name_of_parameter (in the VNF target).

NOTE: the scripts in the CONFIGURE lifecycle event need to start with the type of the source VNF followed by _ (underscore) and the name of the script (i.e. server_configure.sh)

VMs termination

The STOP lifecycle event is meant to just stop the VNF service and afterward be able to start it again. The TERMINATE lifecycle event delete the virtual resources from the PoP As for VMs deployment, VMs termination is done by the NFVO. Specific scripts can be run before termination by putting them under the TERMINATE lifecycle event.