<< Back

7 APIs & Interfaces

scope

Table of Contents

In this document’s earlier chapters, the various resources and capabilities of the NFVI have been catalogued and the workloads (VNFs) have been profiled with respect to those capabilities. The intent behind this chapter and an “API Layer” is to similarly provide a single place to catalogue and thereby codify, a common set of open APIs to access (i.e. request, consume, control, etc.) the aforementioned resources, be them directly exposed to the VNFs, or purely internal to the NFVI.

It is a further intent of this chapter and this document to ensure the APIs adopted for CNTT NFVI implementations are open and not proprietary, in support of compatibility, component substitution and ability to realize maximum value from existing and future test heads and harnesses.

While it is the intent of this chapter, when included in a Reference Architecture, to catalogue the APIs, it is not the intent of this chapter to reprint the APIs, as this would make maintenance of the chapter impractical and the length of the chapter disproportionate within the Reference Model document. Instead, the APIs selected for CNTT NFVI implementations and specified in this chapter, will be incorporated by reference and URLs for the latest, authoritative versions of the APIs, provided in the References section of this document.

Although the document does not attempt to reprint the APIs themselves, where appropriate and generally where the mapping of resources and capabilities within the NFVI to objects in APIs would be otherwise ambiguous, this chapter shall provide explicit identification and mapping.

In addition to the raw or base-level NFVI functionality to API and object mapping, it is further the intent to specify an explicit, normalized set of APIs and mappings to control the logical interconnections and relationships between these objects, notably, but not limited to, support of SFC (Service Function Chaining) and other networking and network management functionality. It is initially proposed to divide the APIs into three primary categories, each reflecting a specific domain relative to the NFVI, as follows, and described in detail in the first three sections of this chapter:

  1. Intra-Infrastructure (NFVI) APIs
  2. NFVI APIs
  3. Enabler Services APIs

Infra Related: These APIs are provided and consumed directly by the infra. These APIs are purely internal to the NFVI, and not exposed to VNF workloads.

NFVI APIs: These APIs are provided to the VNF workloads (i.e. exposed), by the infra.

Enabler Services: These APIs are provided by functions which may be instantiated at higher layers (i.e. in user or workload space), and provide facilities that are required for a majority of VNFs. For example, DHCP, DNS, NTP, DBaaS, etc. Note, in some cases Enabler Services may mirror services provided within the Infra, such as DNS or DHCP. However, the purpose in this section is explicitly to describe instances of those services which are both hosted and consumed above the Infra water mark.

This is a place holder for Infra Related APIs.

7.2 NFVI APIs

The NFVI APIs consist of set of APIs that are externally and internally visible. The externally visible APIs are made available for orchestration and management of the execution environments that host workloads (e.g., VNFs) while the internally visible APIs support actions on the hypervisor and the physical resources. The ETSI NFV Reference Architecture Framework (Figure 7-1) shows a number of Interface points where specific or sets of APIs are supported. For the scope of the reference model the relevant interface points are shown in Table 7-1.

ETSI NFVI Interface

Figure 7-1: ETSI NFVI Interface points.

Interface Point NFVI Exposure Interface Between Description
Vi-Ha Internal NFVI Software Layer and Hardware Resources 1. Discover/collect resources and their configuration information
2. Create execution environment (e.g., VM) for workloads (VNF)
Vn-Nf External NFVI and VM (VNF) Represents the execution environment. There is no protocol or interface defined between these layers. Advantage is that the workloads can be made NFVI independent except for performance
NF-Vi External NFVI and VIM 1. Discover/collect physical/virtual resources and their configuration information
2. Manage (create, resize, (un) suspend, reboot, etc.) physical/virtualised resources
3. Physical/Virtual resources configuration changes
4. Physical/Virtual resource configuration.
Or-Vi External VNF Orchestrator and VIM See below
Vi-Vnfm External VNF Manager and VIM See below

Table 7-1: NFVI and VIM Interfaces with Other System Components.

The Or-Vi and Vi-VNfm are both specifying interfaces provided by the VIM and therefore are related. The Or-Vi reference point is used for exchanges between NFV Orchestrator and VIM, and supports the following interfaces; virtualised resources refers to virtualised compute, storage and network resources:

7.2.1 Tenant Level APIs

In the abstraction model of the NFVI (Chapter 3.1) a conceptual model of a Tenant (Figure 3-2) represents the slice of a cloud zone dedicated to a VNF. This slice, the Tenant, is composed of virtual resources being utilized by VNFs within that Tenant. A conceptual data model of a Tenant is shown in Figure 16. The Tenant has an assigned quota of virtual resources, a set of users can perform operations as per their assigned roles, and the Tenant exists within a Cloud Zone. The APIs will specify the allowed operations on the Tenant including its component virtual resources and the different APIs can only be executed by users with the appropriate roles. For example, a Tenant may only be allowed to be created and deleted by Cloud Zone administrators while virtual compute resources could be allowed to be created and deleted by Tenant administrators.

tenant_data_model

Figure 7-2: Conceptual Tenant data model.

For a VNF stack to be created in a Tenant also requires APIs for the management (creation, deletion and operation) of the Tenant, software flavours (Chapter 5), Operating System and VNF images (“Images”), Identity and Authorization (“Identity”), virtual resources, security and the VNF application (“stack”).

A virtual compute resource is created as per the flavour template (specifies the compute, memory and local storage capacity) and is launched using an image with access and security credentials; once launched, it is referred to as a virtual compute instance or just “Instance”). Instances can be launched by specifying the compute, memory and local storage capacity parameters instead of an existing flavour; reference to flavours coves the situation where the capacity parameters are specified. IP addresses and storage volumes can be attached to a running Instance.

Resource Create List Attach Detach Delete Notes
Flavour + + +
Image + + + Create/delete by appropriate administrators
Key pairs + + +
Privileges Created and managed by Cloud Service Provider(CSP) administrators
Role + + + Create/delete by authorized administrators where roles are assigned privileges and mapped to users in scope
Security Groups + + + Create and delete only by VDC administrators
Stack + + + Create/delete by VDC users with appropriate role
Virtual Storage + + + + + Create/delete by VDC users with appropriate role
User + + + + Create/delete only by VDC administrators
Tenant + + + + Create/delete only by Cloud Zone administrators
Virtual compute + + + + Create/delete by VDC users with appropriate role. Additional operations would include suspend/unsuspend
Virtual network + + + + + Create/delete by VDC users with appropriate role

Table 7-2: API types for a minimal set of resources.

Table 7-2 specifies a minimal set of API types for a minimal set of resources that are needed to orchestrate VNF workloads. The actual APIs for the listed operations will be specified in the Reference Architectures; each listed operation could have a number of associated APIs with a different set of parameters. For example, create virtual resource using an image or a device.

7.3 Enabler Services APIs (not-MVP)

This is a place holder for Enabler Services APIs. a. NTP, DNS, etc. – where is the care and feeding of these? Who provides certain features/services within or outside the tenant? b. Licensing and imaging connectivity