A VNF is onboarded to a two-pod vCloud NFV design by following these steps: preparing the VNF for consumption by vCloud Director, importing the VNF images, ensuring that the VNF is setup correctly in the environment, storing it in a vCloud Director catalog, and deploying it by various means. The process can be divided into CSP operations and tenant operations, as detailed in this section of the document.

vCloud Director supports importing VNFs as standard OVF/OVA packages. While multiple options are available to create an OVF/OVA package, for best practices the VNF vendor must author the package in a separate environment identical to the target vCloud NFV, to match its features and capabilities. To import a VNF as a standard OVF package, follow these steps:

  1. Create a vApp and add the VNFCs to it. Use of preconfigured, reusable virtual machine VNFC templates simplifies the process of vApp creation.

  2. East-West vApp VNF networks are created by provisioning organization networks. North-South connectivity requires routed organization networks. Both networks are configured from within vCloud Director.

  3. VNF Components are connected to the networks and the VNF is validated on the NFVI platform

  4. The final vApp is captured as a vApp template and exported as an OVF package provided to the CSP.

Ensuring that the resources needed for the VNF are available is not only integral, but central to the platform design. This process is typically collaborative between the VNF vendor and the CSP. The VNF vendor provides guidance based on lab testing, regarding the amount of virtual resources needed to support a specific size or scale of telecommunications service. For example, a virtual Evolved Packet Core (vEPC) is likely to specify that to serve a certain number of subscribers with active features such as deep packet inspection (DPI) and quality of service (QoS), a specific number of vCPUs, memory, network bandwidth, and storage is required. The NFVI operator accounts for near-future scale requirements, using the mechanisms described in this section to make resources available.

Before a VNF is onboarded, the CSP must collect prerequisite information from the VNF supplier. This includes configuration information such as the number of networks required, IP ranges, and North-South network connectivity.

vCloud Director uses the concept of catalogs for storing content. Catalogs are containers for VNF templates and media images. CSPs can create global catalogs with golden VNF templates that can be shared to one or more tenants, while tenants retain their own private catalog of VNF templates. The OVF/OVA package of a VNF is directly imported into the tenant catalog. In addition to VNF templates, the catalog may contain VNF Component templates, used to scale deployed VNFs.

Tenant administrators deploy VNFs from available templates in the self-service catalog and provision East-West connectivity by using OvDC networks from within the vCloud Director UI. VNF North-South connectivity is achieved by connecting OvDC networks to vCloud Director external networks.

Figure 1. VNF Onboarding in a Two-Pod Design

VNF Onboarding Two-Pod Design

vCloud Director exposes a rich set of REST API calls to allow automation. Using these API calls, the upstream VNFM and NFVO can automate all aspects of the VNF lifecycle. Examples include VNF deployment from a catalog, tenant network creation and configuration, power operations, and VNF decommissioning. The complete list of APIs are described in detail in the vCloud API Programming Guide for ServiceProviders document.

in the file. These configuration parameters are interpreted by the system when the VNFC is deployed and can be used to specify advanced performance tuning parameters such as those for NUMA node affinity, interrupt coalescing, and latency sensitivity. These are further described in the Performance section of this document.

While some VNFs may have their own application level high availability capabilities, all VNFs can leverage the vSphere platform high availability features such as vSphere Fault Tolerance, vSphere HA, and Orchestrated HA. vSphere Fault Tolerance provides continuous availability for virtual machines (VMs) by creating and maintaining a Secondary VM that is identical to, and continuously available to replace, the Primary VM in the event of a failover. vSphere HA protects VMs from host failure by restarting the VM on another host in the cluster. Orchestrated HA is an extension to vSphere HA that allows the VNF vendor or CSP to specify rules for VM startup, based on application dependencies during a vSphere HA restart. These features all minimize administrative intervention and ensure operational efficiency for the NFVI platform and VNF workloads.