Chapter 10. Deployment and Lifecycle Management

10.1. Management and Network Orchestration (MANO)

ETSI-NFV provides a framework for provisioning and maintenance of VNFs in the Management and Network Orchestration in ETSI GS NFV-MAN 001 V1.1.1 (2014-12) (http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf). We will discuss the orchestration aspects in general and as it pertains to vEPC in this section.

10.2. Orchestration: VNFM, NFVo and Virtual Intrastructure Manager (VIM) interactions

A note about VNFMs. There are two types of VNFMs - Generic VNFM (GVNFM) and Specialized VNFM (SVNFM) . The SVNFMs are tightly coupled with the VNFs that they manage. Lifecycle management of vEPC is a very complex task. Altough GVNFMs may be able to perform most of the tasks required in vEPC in theory, in practice, there would have to be a lot of customization to make the GVNFM knowledgeable about the vEPC VNF . KPI monitoring, element management, failover, load-balancing, elasticity and application healing aspects require a deep and real-time knowledge of the application state. As a result complex VNFs such as vEPC tend to have their own VNFM provided by the VNF vendor.

In vEPC deployments, the NFV-O acts as the top-level orchestration layer that interfaces with northbound entities such as the service catalog, customer portal and service assurance. Customers in the vEPC context are not end users of mobile/smartphones typically. They may be enterprise customers ordering over-the-top enterprise VPN service from the mobile operator or ordering an instance to house additional M2M (Machine to Machine) instances. Typically, this order will result in one of the following:

  • It can be accommodated on the existing vEPC instance where sufficient capacity exists on active instance
  • Accommodated on existing vEPC where some new instances (new PGW for instance) is required
  • Brand new instance of vEPC will be required because we have run out of capacity on the existing instance and due to infrastructure or other limitations we cannot add more instances to existing vEPC

Regardless of which case, when a customer orders a service that results in modifications to the vEPC (existing or new), mobile operators prefer it goes through a manual approval process where a human checks to make sure the order is valid. Once customer service/onboarding team approves the order, the NFV-O gets messaging with service attributes. The NFV-O will take the following action(s):

  • Translate it into actual infrastructure/application requirements. For e.g. it may need another VM with more service modules to accommodate this customer order
  • Check available resources against a resource database
  • Send one or more requests to a VNFM if one exists to instantiate the new resource (new server/host, new VM, additional network ports/capacity etc). Some mobile operators choose not to use any VNFM at all and embed the VNFM functionality into the NFV-O. While this model does not strictly adhere to the ETSI NFVI model, the operators see this as a better fit in terms of architectural alignment as well as operational. It should be noted that the NFV-O in actual deployments may also talk to some configuration automation engine such as Red Hat Ansible to push configurations to underlay network elements or other lower layer requests that will be required to complete this order.
  • The next step is for the VNFM to translate the request from the NFV-O into actual commands that the VIM would understand. For e.g. it may be a “Nova Boot” or “Neutron Net Create” etc.
  • Success or failure is reported back to NFV-O.
  • NFV-O updates resource database if required, updates order processing system, adds the new resources into the service assurance system or fault management system to monitor

Figure 30 shows a flow diagram with details of VNF instantiation as recommended by ETSI. It should be noted that vEPC VNFs may be accompanied by Element Managers (EMs) that assist in managing the VNF from an application standpoint.

VNF instantiation flow

Figure 30: VNF Instantiation flow as per ETSI

10.3. Day0 Config

The VNFM typically is responsible for Day0 configuration. It will start the VM using the ssh-keys assigned for it, configure Eth0 if required for management/SSH access. All higher level configuration such as protocols (BGP, Firewall rules etc.) will be done through configuration automation tool such as Ansible.

10.4. Fixed IP Addressing

For internal communication between the control modules and service modules, vEPC application may have reserved internal IP address ranges. These are typically RFC-1918 non-routable IP subnets. The application may choose not to use the DHCP services offered by OpenStack L3 agent.

If the platform uses provider networks for their tenant connectivity and compute hosts don’t have access to the dhcp-agent running on the controller using the provider networks, special provisions need to be made to enable DHCP services for the guests, or the guests need to use pre-provisioned static IP addresses. One of the ways to accomplish this is to use config-drive to pass networking information to the guests. Images used to instantiate the VMs need to contain a cloud-init package capable of mounting the config-drive or a special script can be created to mount the drive, depending on the guest OS.

10.5. Virtualized Infrastructure Manager (VIM)

While mobile VNF vendors tend to support both OpenStack as well as VMWare, the focus of this document will be around Red Hat OpenStack Platform as a VIM. vEPC VNFMs may use some middleware to abstract the VIM API requests (for e.g. OpenStack API).