VNF Manager (VNFM)

This site has been moved to https://cloudifynetwork.com/

A VNF manager manages the state, lifecycle and resources of one or more VNFs. It is responsible for instantiation, update, query, scaling, healing, termination etc of the VNFs.

VNF Descriptor ( VNFD)

The deployment and operational behaviour of each VNF is stored in a VNF Descriptor file ( VNFD). It contains information such as

• VNF Version:
• Version of VNF, which can be used later to enable upgrades and bug fixes

• Network connectivity:
• Service Chaining - If there are some VNFs that need to be started in particular order to provide a service to an application, that information can be stored in the VNFD. For e.g. say starting MME VNF before SGW , PGW and configure network connectivity only between MME-SGW and SGW-PGW but not MME-PGW
• Type of virtual links and QoS to be supported

• Deployment Flavor:
• How many CPUs, Cores, Threads, memory etc should be provided to this VNF

• Policies:
• Auto-scale - Policies like should VNF autoscale and if so, at what parameters? VNFM notifies the Element Manager (EM) to carry out internal operations if needed. Scaling can be any of Scale-in / Scale-out / Scale-Up / Scale-Down.
• On-Demand Scaling - Modify the VNFD adding the additional VM info. Here again VNFM notifies the Element Manager (EM) to carry out internal operations if needed.
• Auto-heal - Should auto healing be triggered , if so at what parameters?
• Affinity/Anti-Affinity - Policies wrt to VM Placements for e.g. Some VMs may have to be started on specific computes ( say for geographical redundancy )
• KPI monitoring - Can be at a minimum to monitor the VM states using ICMP/TCP/UDP messages or could be using SNMP for complex VNFs. Scale-in/Scale-out can be triggered based on this if needed.

• Virtual Deployment Unit ( VDU ):
• VM Image to be used to deploy VNF
• CPU,Memory,Network requirements

The above is just a small subset of the various kinds of information that can be stored in VNFD.

The VNFD in turn is stored in a VNF Catalogue ( VNFC). VNFC is generally stored in NFVO. However, having an NFVO is not mandatory. The capabilities of VNFM can be enhanced to deliver many of the NFVO functionalities.

Standalone VNFM

VNFM has a connection to VIM to manage VNF resources and lifecycle. However it may not always be a preferred way especially without an NFVO. Multiple VNFMs may try to allocate resources to the VNFs at the same time and may lead to collisions. For e.g. say there are 2 VNFMs both accessing the same NFVI resources. Say there are only 4 CPU cores available and the VIM conveys this information to both VNFMs. Now, if both VNFMs start instantiating VNFs with 4CPU cores, it’ll lead to collision, leading to unexpected results. To avoid such a scenario, VNFMs can talk to a VIM management layer , which can queue VNFM requests and allocate resources only if it’s available. The network may be similar to one shown below.

VNFM - Modes of Operation

VNFMs automate the lifecycle of VNFs which includes instantiation, scaling, healing and termination. To accomplish these, VNFMs send resource requests to VIMs. This can be done either directly to the selected VIMs or indirectly via NFVO.

In both the modes, VNFM first sends a “grant request” to the NFVO to get its resource request authorized. This request is also a means  for the VNFM to ensure that all resources for a VNF are available.

In direct mode, after receiving a positive grant response the VNFM requests the resources directly to the VIM

In indirect mode, the VNFM does not communicate directly with a VIM. The VNFM requests resources indirectly via the NFVO which after approving the request, proxies it to a VIM. This indirect mode can also be implemented in a situation where a VIM broker like Ansible sits in between the VNFM and VIM.

This mode definitely brings in an additional point of failure in the NFVO and thus direct mode is simpler than the indirect mode.