The conceptual design provides a high-level view of the roles, areas of responsibility, and tenant flow that are required to upload an image, onboard, and deploy it.

The VNF onboarding process is typically a collaborative effort between the VNF vendor and the CSP. Before a VNF is onboarded, the VNF vendor must provide the CSP with all the prerequisites for the successful onboarding of the VNF. This includes information such as the VNF format, number of the required networks, East-West and North-South network connectivity, routing policy, security policy, IP ranges, and performance requirements.

VNF Format and Packaging

vCloud Director supports importing VNFs as standard OVF/OVA packages. As a best practice, the VNF vendor must author the package in a separate environment identical to the target vCloud NFV environment to match its features and capabilities.

VMware Ready for NFV is a program where VMware and VNF vendors collaborate to ensure that the VNF is interoperable with vCloud NFV. Based on experience, VMware provides best practices to help VNF vendors in preparing their VNFs for consumption by vCloud Director.

CSPs expect their VNF supplier to deliver a package that is ready for consumption by vCloud Director. The package must support:

  1. Autonomous VNF Life Cycle Operations: CSPs must be able to install, upgrade, and manage the VNF themselves.

  2. Compact: All components that are required to operate the VNF are packaged together. VNFCs are clearly defined, use unique and specific names, and are included in the package.

  3. Authorized: The package provided to the CSP must be verifiable. For example, an md5 hash could be used to verify that the package provided by the vendor is the same package that is installed by the CSP.

  4. Holistic: The packaged VNF must include all configuration that is required to deploy a healthy VNF. For example, if the VNF is data plane intensive, all performance-related configuration such as CPU and NUMA affinity, CPU and memory reservations must be included in the package.

VNF Onboarding by Using VMware vCloud Director

Onboarding a VNF in vCloud NFV includes the following steps:

  1. Prepare the VNF for consumption by vCloud Director.

  2. Import the VNF images to the vCloud Director catalog.

  3. Ensure that the environment is configured correctly for the VNF deployment.

  4. Deploy the VNF in the vCloud NFV environment.

The process can be divided into CSP operations and tenant operations.

Before a VNF is onboarded, the CSP administrator must collect the prerequisite information from the VNF supplier. The prerequisites include configuration information such as the number of required networks, IP ranges, North-South network connectivity, and so on.

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 can retain their own private catalog of VNF templates. The OVF/OVA package of a VNF is directly imported to the tenant catalog. In addition to VNF templates, the catalog can contain VNFC templates, used to scale deployed VNFs.

Tenant administrators deploy VNFs from the available templates in the self-service catalog. Tenants also provision East-West connectivity by using Organization VDC networks that they import from NSX-T. VNF North-South connectivity is established by connecting Organization VDC networks to the external network through an NSX-T Edge Router.

Figure 1. VNF Onboarding Conceptual Design
VNF Onboarding Conceptual Design

Resource Allocation

This process is typically collaborative between the VNF vendor and the CSP. Based on lab testing, the VNF vendor provides guidance on the amount of virtual resources needed to support a specific size or scale of telco 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 CSP accounts for near-future scale requirements, using the resource allocation mechanisms provided by vCloud Director such as resource allocation models and storage policies

VNF Networking

Based on specific VNF networking requirements, a CSP administrator can use NSX Manager to provision East-West connectivity, security groups, firewalls, micro-segmentation, NAT, and LBaaS for a tenant. Tenants import their respective networks created by the CSP administrator, to an Organization VDC. VNF North-South connectivity is established by connecting tenant networks to external networks through NSX-T Data Center routers that are deployed in Edge Nodes. External networks are created by CSP administrators and backed by physical networks.

Tenant networks are accessible by all Organization VDCs within the Organization. Therefore, the implementation of East-West connectivity between VNFCs in the same Organization VDC, and the connectivity between VNFs in two different Organization VDCs belonging to the same Organization, is identical. Tenant networks are implemented as logical switches within the Organization. The North-South network is a tenant network that is connected to the telco network through an N-VDS Enhanced switch for data-intensive workloads or by using N-VDS Standard through an NSX Edge Cluster.

vCloud Director exposes a rich set of REST API calls to enable automation. By using these API calls, the upstream VNFM and NFVO can automate all aspects of the VNF life cycle. Examples include the VNF deployment from a catalog, tenant network consumption, power operations, and VNF decommissioning.

Host Affinity and Anti-Affinity Policy

A vCloud Director system administrator can create groups of VMs in a resource pool, then use VM-Host affinity rules to specify whether members of a VM group should be deployed on members of a vSphere host DRS Group. vCloud Director VM-Host affinity rules provide vCloud Director system administrators with a way to specify how vSphere DRS should place VMs on hosts in a resource pool. VM-Host affinity rules can be useful when host-based licensing requires VMs that are running certain applications to be placed on hosts that are licensed to run those applications. They can also be useful when VMs with workload-specific configurations require placement on hosts that have certain characteristics such as acceleration.

DRS Host Groups for Placement

A host group is a vSphere host DRS group. The vSphere administrator must create host DRS groups in a resource pool mapped to a Provider VDC before they can be used in vCloud Director VM Host affinity rules. This helps in placing the workload on a particular host cluster at power-on once they are onboarded.