The VNF onboarding process is typically a collaborative effort between the VNF vendor and the CSP. Before a VNF is onboarded, the CSP must collect prerequisite information from the VNF supplier. This includes configuration information such as the VNF format, number of networks required, East-West and North-South network connectivity, routing policy, security policy, IP ranges and performance requirements. Figure 27 provides a high-level view of the roles, areas of responsibility, and tenant flow to bring an image onboard and deploy it. More details will be discussed in the following section of the document

The initial format of the VNF must be taken into consideration for onboarding. The VNF's will be in a certain format and any additional components that the VNF needs to function should also be considered. The images may be able to be directly imported or they may need to be converted. VMware Integrated OpenStack supports ISO, VMDK or OVA formats, but RAW, QCOW2, VDI or VHD formats can also be imported using the CLI.

After the initial VNF requirements are understood, images needed and their formats, a project would be created to for the VNF to deployed in an operational environment. Projects are equal to tenants and administrators create the projects and assign users to each project. Administrators manage permissions through user, group, and project definitions. Users have a further restricted set of rights and privileges. Users are limited to the projects to which they are assigned. Users can be assigned as to more than one project. When a user logs in to a project, they are authenticated against Keystone. Once the user is authenticated, they can perform operations within the project.

One of the tasks the administrator has to fulfill when building a project for the VNF is setting initial quota limits for the project. Quotas are the operational limits that configured the amount of system resources available per project. Quotas can be enforced at the project and user level. When a user logs in to a project, they see an overview of the project including the resources they have been provided, the resources they have consumed, and the resources they have remaining.

Figure 1. VMware Integrated OpenStack VNF Onboarding

VMware Integrated OpenStack VNF Onboarding

Based on specific VNF deployment requirements, a tenant can provision East-West connectivity, security groups, firewalls, micro-segmentation, NAT, and LBaaS from within the VMware Integrated OpenStack user interface or CLI. VNF North-South connectivity is achieved by connecting tenant networks to external networks. External networks are created by administrators and a variety of VNF routing scenarios are possible.

Before full deployment of VNFs, tenants must consider the performance requirements for the VNF's and if they need to deploy VNF's to optimized compute nodes. Optimized compute nodes are nodes that may be configured with special performance capabilities and VNF's would need to be placed correctly in order to take advantage of the performance capabilities. As mentioned in an earlier section, the vCloud NFV platform supports many performance related capabilities, such as NUMA placement and SR-IOV ad other tuning capabilities which allow CSPs achieve high network performance across the platform

Next, the VNF routing, switching and security policies are considered. There are many different infrastructure services available that can be configured in diferent ways and the incoming sections, a couple of options are discussed.

The next figure 27 provides an example of VNFs with VLAN external connectivity. Project 1 has a logical segment built using an NSX logical switch with connectivity to an NSX ESG. The NSX ESG's northbound interface is connected to a VLAN backed external network trunked to the CSP's router. The NSX ESG routes traffic to the SP router.

Project 2 has a similar configuration with a slight modification. The VNF is directly connected to the VLAN based external network. The VLAN is trunked through the DVS to the physical router. The first hop router for Project 2 is the CSP router. In both cases, the CSP router terminates the VLANs and the route to the Telco network. To maintain separation, the VLANs may connect to MPLS Layer 2 or Layer 3 VPNs.
Figure 2. VNF Networking with VLAN Backed External Network
VNF Networking with VLAN Backed External Network

Figure 28 provides another possible example of VNF networking. VNFs require management access to establish the necessary network connectivity, for example between a VNFM deployed in the Resource pod and an NFVO deployed in the Management pod. Components in the Management pod are connected to the management network VLAN. This VLAN is trunked to the hosts in the Edge pod where the physical NICs are assigned as uplinks to a VDS. The CSP provisions a VDS port group used by administrators to configure the external network. In this scenario, the NSX Edge instance performs the role of a VXLAN to VLAN bridge and provides edge network services, including NAT and a stateful firewall for security.

Implementation of East-West connectivity between VNFCs in the same Tenant vDC, and connectivity between VNFs in two different Tenant vDCs belonging to the same project, is identical. This is true because tenant networks are accessible by all Tenant vDCs within the project. Tenant networks are implemented as logical switches within the project. The North-South network is a tenant network connected to the telecommunications network through an NSX for vSphere ESG. The ESG can be configured with edge services including NAT, load balancing, and firewall services, in addition to its role as a router. Additionally, different interfaces can be used for different services, such as direct pass through / SR-IOV for data plane traffic and VMXNET3 for management and control plane traffic.

Figure 3. VNF Networking in Three-Pod Design

VNF Networking in Three-Pod Design

VMware Integrated OpenStack exposes a rich set of API calls to allow automation. You can automate the deployment of VNFs using a Heat template. With API calls, the upstream VNFM and NFVO can automate all aspects of the VNF lifecycle.

In summary, this reference architecture provides initial guidance for designing and creating a greenfield Network Functions Virtualization (NFV) platform using VMware vCloud® NFVTM OpenStack Edition. VMware vCloud NFV OpenStack Edition combines a carrier grade NFV infrastructure with VMware® Integrated OpenStack as an NFV Virtualized Infrastructure Manager (VIM). The platform is based on VMware components that are tightly integrated and tested. Each of the components has numerous potentially valid configurations and some best practices, guidelines and deployment options have been provided to help CSP’s move aggressively forward into the market with a world class NFV platform optimized for OpenStack.