<< Back

3 Infrastructure Abstraction

bogo

Table of Contents

There is the necessity to clearly define which kind of infrastructure resources a shared network function virtualisation infrastructure (NFVI) will provide for hosting workloads including virtual network functions (VNFs) and/or cloud-native network functions (CNF), so that the requirements of the workloads match the capabilities of the NFVI.

The lack of a common understanding of which resources and corresponding capabilities a suitable NFVI should provide may lead to several issues which could negatively impact the time and the cost for on-boarding and maintaining these solutions on top of a virtualised infrastructure. For Example:

The abstraction model presented in this chapter specifies a common set of virtual infrastructure resources which NFVI will need to provide to be able to host most of the typical VNF/CNF workloads required by the operator community.

Although a couple of explicit and implicit abstraction models (e.g. in the context of ETSI NFV) are already available, they fall short when addressing the following design principles: - Scope: the model should describe the most relevant virtualised infrastructure resources (incl. acceleration technologies) an NFVI needs to provide for hosting Telco workloads - Separation of Concern: the model should support a clear distinction between the responsibilities related to maintaining the network function virtualisation infrastructure and the responsibilities related to managing the various VNF workloads - Simplicity: the amount of different types of resources (including their attributes and relationships amongst one another) should be kept to a minimum to reduce the configuration spectrum which needs to be considered - Declarative: the model should allow for a declarative description of the required NFVI capabilities for on-boarding and maintaining workloads - Explicit: the model needs to be rich enough to allow for a direct mapping towards the APIs of NFVIs for the instantiation of virtual infrastructure elements without requiring any additional parameters - Lifecycle: the model must distinguish between resources which have independent lifecycles but should group together those resources which share a common lifecycle - Aligned: the model should clearly highlight the dependencies between the elements to allow for a well-defined and simplified synchronisation of independent automation tasks.

To summarise: the abstraction model presented in this document will build upon existing modelling concepts and simplify and streamline them to the needs of telco operators who intend to distinguish between infrastructure related and workload related responsibilities.

3.1 Model

The abstraction model for the NFVI makes use of the following layers (only the virtual infrastructure layer will be directly exposed to workloads (VNFs/CNFs)):

NFVI model_layers

Figure 3-1: NFVI Model Layers.

The functionalities of each layer are as follows: - Physical Infrastructure Resources: This layer consists of physical hardware components such as servers, (including random access memory, local storage, network ports, and hardware acceleration devices), storage devices, network devices, etc. and the basic input output system (BIOS). - NFVI Software: This layer consists of both the host Operating System (OS) responsible for managing the physical infrastructure resources as well as the virtualization/containerization technology which, on request, dynamically allocates hardware components and exposes them as virtual resources. - Virtual Infrastructure Resources: This layer represents all the infrastructure resources (compute, storage and networks) which the NFVI provides to the workloads such as VNFs/CNFs. These virtual resources can be managed by the tenants and tenant workloads directly or indirectly via an application programming interface (API). - Workloads (VNFs/CNFs): This layer consists of workloads such as virtualized and/or containerized network functions that run on top of a VM or as a Container. The virtual infrastructure resources provided by the NFVI can be grouped into four categories as shown in the diagram in Figure 3-2.

The virtual infrastructure resources provided by the NFVI can be grouped into four categories as shown in the diagram below:

virtual_resources

Figure 3-2: Virtual Infrastructure Resources provides virtual compute, storage and networks in a tenant context.

The virtualised infrastructure resources related to these categories are listed below:

Tenant

A network function virtualisation infrastructure (NFVI) needs to be capable of supporting multiple tenants and has to isolate sets of infrastructure resources dedicated to specific workloads (VNF/CNF) from one another. Tenants represent an independently manageable logical pool of compute, storage and network resources abstracted from physical hardware. Example: a tenant within an OpenStack environment or a Kubernetes cluster.

Attribute Description
name name of the logical resource pool
type type of tenant (e.g. OpenStack tenant, Kubernetes cluster, …)
vcpus max. number of virtual CPUs
ram max. size of random access memory in GB
disc max. size of ephemeral disc in GB
networks description of external networks required for inter-domain connectivity
metadata key/value pairs for selection of the appropriate physical context (e.g. location, availability zone, …)

Table 3-1: Attributes of a tenant.

Compute

A virtual machine or a container/pod belonging to a tenant capable of hosting the application components of workloads (VNFs). A virtual compute therefore requires a tenant context and since it will need to communicate with other communication partners it is assumed that the networks have been provisioned in advance. Example: a virtual compute descriptor as defined in TOSCA Simple Profile for NFV.

Attribute Description
name name of the virtual host
vcpus number of virtual cpus
ram size of random access memory in GB
disc size of root disc in GB
nics sorted list of network interfaces connecting the host to the virtual networks
acceleration key/value pairs for selection of the appropriate acceleration technology
metadata key/value pairs for selection of the appropriate redundancy domain

Table 3-2: Attributes of compute resources.

Storage

A block device of a certain size for persisting information which can be created and dynamically attached to/detached from a virtual compute. A storage device resides in a tenant context and exists independently from any compute host. Example: an OpenStack cinder volume.

Attribute Description
name name of storage resources
size size of disc in GB
attachments list of compute hosts to which the device is currently attached
acceleration key/value pairs for selection of the appropriate acceleration technology
metadata key/value pairs for selection of the appropriate redundancy domain

Table 3-3: Attributes of storage resources.

Comments: we need to be more specific regarding acceleration and metadata.

Network

A layer 2 / layer 3 communication domain within a tenant. A network requires a tenant context. Example: a virtual compute descriptor as defined in TOSCA Simple Profile for NFV.

Attribute Description
name name of the network resource
subnet network address of the subnet
acceleration key/value pairs for selection of the appropriate acceleration technology

Table 3-4: Attributes of network resources.

3.2 Exposed vs Internal

The following pertains to the context of NFVI Capabilities, Metrics and Constraints, as discussed within this chapter.

Exposed: Refers to any mechanism (e.g., discovery, configuration, consumption, telemetry, some object, API, Interface, etc.) that exists in or pertains to, the domain of the NFVI and is made visible (aka “Exposed”) to a tenant and/or VNF in the workload domain. When an object is exposed to a given tenant or VNF, the scope of visibility within a given VNF is at the discretion of the specific VNF’s designer. From an Infra perspective, the Infra-resident object is simply being exposed to one or more virtual environments (i.e. VMs). It is then the responsibility of the kernel or supervisor/executive within the VM to control how, when and where the object is further exposed within the VM, with regard to permissions, security, etc. As the object(s) originate with the NFVI or Control Plane, they are by definition visible within those domains.

Internal: Effectively the opposite of Exposed; objects Internal to the NFVI, which are exclusively available for use by the NFVI and components within the NFVI control plane.

Exposed vs. Internal Scope

Figure 3-3: Exposed vs. Internal Scope

As illustrated in the figure above, objects designated as "Internal" are only visible within the area inside the blue oval (the NFVI), and only when the entity accessing the object has the appropriate permissions. Whereas objects designated as "Exposed" are potentially visible from both the area within the green oval (the Workload), as well as from within the NFVI, again provided the entity accessing the object has appropriate permissions.

Note: The figure above indicates the areas from where the objects are visible. It is not intended to indicate where the objects are instantiated. For example, the virtual resources are instantiated within the NFVI (the blue area), but are Exposed, and therefore are visible to the Workload, within the green area.

3.3 Exposed NFVI capabilities and metrics

3.3.1 Exposed NFVI capabilities

This section describes a set of explicit NFVI capabilities and metrics that define an NFVI. These capabilities and metrics are well known to VNFs as they provide capabilities which VNFs rely on.

Note: It is expected that NFVI capabilities and metrics will evolve with time as more capabilities are added as technology enhances and matures.

3.3.1.1 Exposed resource capabilities

Table 3-5 below shows resource capabilities of NFVI. Those indicate resources offered to VNFs by NFVI.

Ref NFVI capability Unit Definition/Notes
e.nfvi.res.cap.001 #vCPU cores number Min, Max number of vCPU cores that can be assigned to a single VNF-C
e.nfvi.res.cap.002 Amount of RAM (MB) MB Min, Max memory in MB that can be assigned to a single VNF-C by NFVI.
e.nfvi.res.cap.003 Total amount of instance (ephemeral) storage (GB) GB Min, Max storage in GB that can be assigned to a single VNF-C by NFVI
e.nfvi.res.cap.004 # vNICs number Max number of vNIC interfaces that can be assigned to a single VNF-C by NFVI.
e.nfvi.res.cap.005 Total amount of external (persistent) storage (GB) GB Min, Max storage in GB that can be attached / mounted to VNF-C by NFVI.

Table 3-5: Exposed resource capabilities of NFVI.

3.3.1.2 Exposed performance optimisation capabilities

Table 3-6 shows possible performance optimisation capabilities that can be provided by NFVI. These indicate capabilities exposed to VNFs. Those capabilities need to be consumed by VNFs in a standard way.

Ref NFVI capability Unit Definition/Notes
e.nfvi.per.cap.001 CPU pinning support Yes/No Determining if NFVI support CPU pinning
e.nfvi.per.cap.002 NUMA support Yes/No Determining if NFVI support NUMA awareness
e.nfvi.per.cap.003 IPSec Acceleration Yes/No IPSec Acceleration
e.nfvi.per.cap.004 Crypto Acceleration Yes/No Crypto Acceleration
e.nfvi.per.cap.005 Transcoding Acceleration Yes/No Transcoding Acceleration
e.nfvi.per.cap.006 Programmable Acceleration Yes/No Programmable Acceleration

Table 3-6: Exposed performance optimisation capabilities of NFVI.

3.3.1.3 Exposed monitoring capabilities

Table 3-9 shows possible monitoring capabilities available by NFVI for VNFs.

Ref NFVI capability Unit Definition/Notes
e.nfvi.mon.cap.001 Monitoring of L2-7 data Yes/No Ability for VNF-C to monitor their own L2-L7 data.

Table 3-7: Exposed monitoring capabilities of NFVI.

3.3.2 Exposed NFVI metrics

The intent of those metrics is to be well known to VNFs.

3.3.2.1 Exposed performance metrics

The following shows performance metrics per VNF-C, vNIC or vCPU.

Ref NFVI metric Unit Definition/Notes
e.nfvi.per.met.001 Network throughput bits/s or packets/s Max throughput per vNIC (as aligned with ETSI GS NFV-TST 009 [2])
e.nfvi.per.met.002 Network latency second Max round trip time to vNIC (as aligned with ETSI GS NFV-TST 009 [2])
e.nfvi.per.met.003 Network Delay Variation second Max packet delay variation (a.k.a., jitter) of round trip time to vNIC (as aligned with ETSI GS NFV-TST 009 [2])
e.nfvi.per.met.004 Simultaneous active flows number Max simultaneous active L4 flows per vNIC before a new flow is dropped
e.nfvi.per.met.005 New flows rate flows/s Max new L4 flow rate per vNIC
e.nfvi.per.met.006 Storage throughput bytes/s or IO/s Max throughput per virtual block storage unit assigned to VNF-C
e.nfvi.per.met.007 Processing capacity test-specific Processing capacity test-specific score per vCPU

Table 3-8: Exposed performance metrics of NFVI.

3.4 Internal NFVI capabilities metrics, and constraints

This section covers a list of implicit NFVI capabilities and metrics that define the interior of NFVI. These capabilities and metrics determine how the NFVI behaves internally. They are hidden from VNFs (i.e. VNFs may not know about them) but they will have a big impact on the overall performance and capabilities of a given NFVI solution.

Note: It is expected that implicit NFVI capabilities and metrics will evolve with time as more capabilities are added as technology enhances and matures.

3.4.1 Internal NFVI capabilities

3.4.1.1 Internal resource capabilities

Table 3-13 shows resource capabilities of NFVI. These include capabilities offered to VNFs and resources consumed internally by NFVI.

Ref NFVI capability Unit Definition/Notes
i.nfvi.res.cap.001 Percentage of vCPU cores consumed by NFVI overhead in a compute node. % (of total available) Indicates the percentage of vCPU cores consumed (wasted) by NFVI components (including host OS) in a compute node.
i.nfvi.res.cap.002 Percentage of memory consumed by NFVI overhead in a compute node. % (of total available) Indicates the percentage of memory consumed (wasted) by NFVI components (including host OS) in a compute node.

Table 3-9: Internal resource capabilities of NFVI.

3.4.1.2 Internal SLA capabilities

Table 3-10 below shows SLA (Service Level Agreement) capabilities available by NFVI. These include capabilities required by VNFs as well as internal capabilities to NFVI. Application of these capabilities to a given workload is determined by its instance type (e.g. T-Shirt size).

Ref NFVI capability Unit Definition/Notes
i.nfvi.sla.cap.001 CPU overbooking 1:N This indicates the number of vCPU cores consumed (wasted) by NFVI components (including host OS) in a compute node.
i.nfvi.sla.cap.002 vNIC QoS Yes/No QoS enablement

Table 3-10: Internal SLA capabilities to NFVI.

3.4.1.3 Internal performance optimisation capabilities

Table 3-11 below shows possible performance optimisation capabilities that can be provided by NFVI. These include capabilities exposed to VNFs as well as internal capabilities to NFVI. These capabilities will be determined by the standard instance type used by VNF-C (VNF Component)

Ref NFVI capability Unit Definition/Notes
i.nfvi.per.cap.001 Huge page support Yes/No Determining if NFVI support huge pages

Table 3-11: Internal performance optimisation capabilities of NFVI.

3.4.1.4 Internal monitoring capabilities

Table 3-12 shows possible monitoring capabilities available by NFVI. The availability of these capabilities will be determined by the instance type used by the workloads.

Ref NFVI capability Unit Definition/Notes
i.nfvi.mon.cap.001 Host CPU usage Per Compute node. It needs to Maps to ETSI NFV-TST 008[1] clause 6, processor usage metric (NFVI exposed to VIM) and ETSI NFV-IFA 027 Mean Virtual CPU usage and Peak Virtual CPU usage (VIM exposed to VNFM).
i.nfvi.mon.cap.002 Virtual compute resource CPU usage QoS enablement
i.nfvi.mon.cap.003 Host CPU utilization Per Compute node. It needs to map to ETSI NFV-IFA 027 Mean Virtual CPU usage and Peak Virtual CPU usage (VIM, exposed to VNFM).
i.nfvi.mon.cap.004 Virtual compute resource CPU utilization Range (min, max) per VNF-C
i.nfvi.mon.cap.005 Monitoring of external storage IOPS Yes/No Transcoding Acceleration
i.nfvi.mon.cap.006 Monitoring of external storage throughput Yes/No Programmable Acceleration
i.nfvi.mon.cap.007 Monitoring of external storage capacity Yes/No

Table 3-12: Internal monitoring capabilities of NFVI.

3.4.1.5 Internal security capabilities

Ref NFVI capability Unit Definition/Notes
i.nfvi.sec.cap.001 VNF-C<->VNF-C memory isolation Yes/No Are VNF-C memories isolated from each other by hardware support?
i.nfvi.sec.cap.002 VNF-C -> Host Yes/No Can VNF-C access host memory?
i.nfvi.sec.cap.003 Host -> VNF-C Yes/No Can Host access VNF-C memory?
i.nfvi.sec.cap.004 External storage at-rest encryption Yes/No Is external storage encrypted at-rest?

Table 3-13: Internal security capabilities of NFVI.

3.4.2 Internal NFVI metrics

3.4.2.1 Internal performance metrics

The following table shows performance metrics per NFVI node.

Ref NFVI metrics Unit Definition/Notes
i.nfvi.per.met.001 Network throughput bits/s or packets/s Max throughput per node (aligned with ETSI GS NFV-TST 009 [2])
i.nfvi.per.met.002 Simultaneous active flows number Max simultaneous active L4 flows per node before a new flow is dropped
i.nfvi.per.met.003 New flows rate flows/s Max new L4 flow rate per node
i.nfvi.per.met.004 Processing capacity test-specific Processing capacity test-specific score per node
i.nfvi.per.met.005 Energy consumption W Maximum energy consumption of the node without hosting any VNF-C (but fully ready for it)
i.nfvi.per.met.006 Network energy efficiency W/bits/s Energy consumption for the node max network throughput, normalized to the bit rate
i.nfvi.per.met.007 Processing energy efficiency W/core Energy consumption during the node processing capacity measurement (i.nfvi.per.met.004), normalized to physical cores usable by VNF-C

Table 3-14: Internal performance metrics of NFVI.

It should be noted that energy-related metrics must only be considered for NFVI software implementations benchmarking on a same NFVI hardware implementation (since energy consumption may be very different for a same processor model due to foundry process spread).

3.4.2.2 Internal availability/reliability metrics

Editor Note: the following table should be reviewed to only consider and probably detail the recovery-related metrics ; indeed, availability and MTBF metrics do not seem consistent with expected testbed measurement duration]

Editor Note: This table needs to be reworked and clarified w/ clear explanations and assumptions stated.

Ref NFVI metric Unit Definition/Notes
i.nfvi.arl.met.001 Availability %
i.nfvi.arl.met.002 MTBF single node days Mean Time between Failure for single node
i.nfvi.arl.met.003 MTBF AZ days Mean Time between Failure for an AZ
i.nfvi.arl.met.004 Recovery time seconds

Table 3-15: Internal availability/reliability metrics of NFVI.

3.5 VIM capabilities, metrics, and constraints.

Editor Note: This Section is still to be worked on.

3.5.1 VIM capabilities.

Editor Note: This Section is still to be worked on.

3.5.2 VIM metrics.

3.5.2.1 Resources management metrics

Table 3-16 shows resource management metrics of VIM as aligned with ETSI GS NFV TST-012 [3].

Ref VIM metrics Unit Definition/Notes
vim.rmt.met.001 Time to create Virtual Compute for a given VNF Max ms
vim.rmt.met.002 Time to delete Virtual Compute of a given VNF Max ms
vim.rmt.met.003 Time to start Virtual Compute of a given VNF Max ms
vim.rmt.met.004 Time to stop Virtual Compute of a given VNF Max ms
vim.rmt.met.005 Time to pause Virtual Compute of a given VNF Max ms
vim.rmt.met.006 Time to create internal virtual network Max ms
vim.rmt.met.007 Time to delete internal virtual network Max ms
vim.rmt.met.008 Time to update internal virtual network Max ms
vim.rmt.met.009 Time to create external virtual network Max ms
vim.rmt.met.010 Time to delete external virtual network Max ms
vim.rmt.met.011 Time to update external virtual network Max ms
vim.rmt.met.014 Time to create external storage ready for use by VNF Max ms

Table 3-16: Resource management metrics of VIM.