The NFV management and orchestration VNF lifecycle operations shall support authorization of the lifecycle management request to ensure that such VNF lifecycle operations are consistent with service provider policies, the VNF Descriptor, and resource constraints in order to avoid network service interruption.

M

NR

No requirement to the VNF

The NFV management and orchestration VNF lifecycle operations shall support validation of the lifecycle management request to ensure that such VNF lifecycle operations are consistent with service provider policies, the VNF Descriptor, and resource constraints in order to avoid network service interruption. For example, when a VNF instance within a VNF-FG is terminated by NFV management and orchestration but replaced by another VNF, the impact on service using that VNF should be checked and such impact should be within a pre-determined service availability range.

M

NR

No requirement to the VNF

VNF lifecycle operation requests shall be limited to some "authorized" functional elements.

M

NR

No requirement to the VNF

The VNF Descriptor shall provide the NFV Orchestrator and the VNF Manager with information for performing the lifecycle management of a VNF as part of the network service.

M

C

The VNFD does provide information to be used by NFVO and VNFM during the LCM operations.

The VNFD shall allow for different processes in support of the VNF state transitions described in the present document. For example, the VNF specific data required for the state transition is the one that is specific for the VNF Manager and VNF Package.

M

C

The NFV Orchestrator shall be able to deploy the network services composed of VNFs with different processes in support of the VNF state transitions described in the present document.

M

NR

No requirement to the VNF

The VNF Package shall provide sufficient information for performing the instantiation of the VNF.

M

NR

No requirement to the VNF

An NFV Orchestrator from any vendor shall be able to interact with the VNF Manager of a VNF that comes from any other vendor.

M

NR

No requirement to the VNF

The VNF Package shall be provided in a format that can be stored in corresponding management and orchestration repositories.

M

C

A VNF shall have at least one SWA-1 interface. A VNF may support multiple SWA-1 interfaces (see note 1).

NOTE 1: A VNF that does not have the capability to connect to any other VNF, PNF, or End Point cannot be part of a network service.

M

C

A VNF SWA-1 interface shall be individually identifiable.

M

C

A VNF shall have at least one SWA-5 interface. A VNF may support multiple SWA-5 interfaces.

M

C

A VNF SWA-5 interface shall be individually identifiable.

M

C

It shall be possible to allocate a set of addresses to a VNF at instantiation time (see note 2).

NOTE 2: Allocation of these addresses to VNFC instances can be driven by lifecycle management operations based on rules that can be specified by the VNF Provider.

M

C

The NFV management and orchestration shall be able to dynamically allocate or deallocate addresses of a given type to a VNF instance and/or a VNFC instance during life cycle management operations based on rules that can be specified by the VNF Provider.

M

NR

No requirement to the VNF

It shall be possible to assign to a VNF addresses of the following types: L2 addresses, IPv4 and IPv6 addresses, private and public IP addresses, multicast IP addresses, and anycast IP addresses.

M

NR

No requirement to the VNF

Scaling event types and format shall be defined.

M

C

Upon request, the NFV management and orchestration shall be able to change the amount of resources allocated to each VNFC and/or to change the number of instances of each VNFC for scaling or redundancy.

M

NR

No requirement to the VNF

A VNF shall support upgrades, which consist of deploying one or more new SW image(s).

M

C

The SAPC provides upgrade by replacement.

The NFV management and orchestration of VNF update/upgrade operation shall support validation of the VNF update/upgrade management request to ensure that such VNF update/upgrade operations are consistent with service provider policies, the VNF Descriptor, and resource constraints to avoid network service interruption.

M

NR

No requirement to the VNF

The NFV management and orchestration shall maintain records on VNF Packages (e.g. SW image catalog, VNFD, version info) involved in a VNF update/upgrade operation.

M

NR

No requirement to the VNF

A VNF may support upgrades that consist of deploying a new version, which may involve more than just deploying one or more new image versions (e.g. in order for the upgrade to operate correctly, it may require a set of different requirements, i.e. more memory). In this case the VNFD shall also be upgraded.

M

NR

No requirement to the VNF

A VNF may support upgrades that require new functionalities from the underlying infrastructure (e.g. more hardware and/or virtual resources, or SRIOV driver). In this case the VNFD shall also be upgraded.

M

NR

No requirement to the VNF

In case of change in the VNF lifecycle (e.g. termination of a VNF or a VNFC), NFV management and orchestration shall enable reporting of events back to VNF instances and/or interested clients (e.g. EM) due to changes made in the VNF components or used virtualised resources.

M

NR

No requirement to the VNF

NFV management and orchestration functions may provide NFVI resources to a requested high availability (HA) VNF. If such NFVI resources are present, they may be directed to be placed in different physical hardware hosts and/or in different locations. It shall be possible to specify the requirements on specific NFVI resources as well as virtual, or geographically redundant, deployment in the VNFD.

M

NR

No requirement to the VNF

When a VNF supports some form of redundancy, e.g. Active/Standby, then both of the deployment steps (i.e. deployment of the active instance, then deployment of the standby instance, configuration of the network, etc.) as well as the type of redundancy (i.e. Active/Standby - automatic detection and IP@ transfer) shall be specified. It shall be possible to describe the resources requested for Active and Standby and the redundancy models used in the VNF Descriptor (VNFD).

M

NR

No requirement to the VNF

It shall be possible to specify the minimum and maximum number of VNFC instances required for deployment and elasticity of a VNF in the VNFD.

M

NR

No requirement to the VNF

The VNFD shall describe the NFVI virtual resources required to deploy a VNF, such as the number of virtualisation containers, vCPU, and virtual memory per virtualisation containers.

M

C

When a VNF is made of multiple VNF Components, this requires information about the relationship (dependencies, inter-connectivity, etc.) between the VNFCs. It shall be possible to specify these properties in the VNFD.

M

C

Void.

M

NR

No requirement to the VNF

The VNFD may have different versions to describe different VNF versions. Anytime there is an update on a VNF, the VNFD shall be updated and a new version of this VNFD shall be created.

M

NR

No requirement to the VNF

A VNF requiring metrics to be collected for proper operation may indicate the need for batch delivery of metrics (e.g. round trip delay, jitter, etc.), providing a list of metrics required and eventually the source providing those (i.e. NFVI, other VNF, etc.), a set of conditions applying to those metrics (e.g. alarms=critical, or CPU > 70 %) and time range (e.g. last 3 days). It shall be possible to define this information in the VNFD, and/or ad-hoc request could be sent via the open interface with NFV management and orchestration (see note).

NOTE: Implementations are expected to have VNFDs and VNF Managers that allow performance information sent to external EM, virtualised EM, the VNF Manager or the VNF instances.

M

NR

No requirement to the VNF

The VNFD of a given VNF shall provide sufficient information about the SWA-1 supported by that VNF to determine compatibility with a different VNF obtained from a different VNF Provider, such as certain protocol support.

M

NC

The SAPC does not provide information about the protocol support in its VNFD, but all its interfaces are documented.

The VNFD shall provide a parameter to specify that a VNFC requires a NIC compatible with a requested data processing acceleration software library.

M

C

The VNFD shall provide a parameter to specify that a VNFC requires a CPU compatible with a requested data processing acceleration software library (e.g. DPDK).

M

C

It shall be possible to specify in the VNFD which network speed/bandwidth is to be guaranteed per requested NIC.

M

NR

No requirement to the VNF

It shall be possible to specify in the VNFD that a VNFC needs a NIC with RDMA support.

M

NR

No requirement to the VNF

It shall be possible to specify in the VNFD that the VNFC needs a NIC that supports SRIOV.

M

NR

No requirement to the VNF

When a VNF is made up of multiple VNF Components, the VNF shall be maintained as one logical entity with one VNF Descriptor, and the NFV management and orchestration shall manage the VNF as one logical entity with identifier, descriptor, status, version, etc.

M

C

The SAPC VNF provides a unique VNFD.

When a VNF is made up of multiple VNF Components, the VNF Descriptor shall include information to be used to deploy VNFC(s) contained in the VNF. NOTE: A VNFC is deployed by management and orchestration functions as defined by its corresponding VDU.

M

C

For a given VNF package, a VNF shall come with zero or one SW image per VNFC, and associated version number.

M

C

It shall be possible to support multiple SW images of the same VNFC by supporting multiple variants of a VNF Package. NOTE: Multiple SW images of the same VNFC may be required when a VNF is designed to execute on different types of virtualisation containers and/or different HW platforms.

M

C

Images provided for supporting KVM and ESXI.

The VNFD shall specify possible interfaces of such VNF with other entities, VNFs or PNFs. It will be up to the VNF-FG or NFV management and orchestration to determine or describe which interface(s) will be used by the other VNF, PNF entities.

M

NR

No requirement to the VNF

The VNFD shall contain the specification of the connectivity graph and dependencies between the VNFC interfaces.

M

C

A VNF may be composed of multiple VNFCs that have different needs (e.g. number of vNICs, specific list of VLAN ids per vNIC, number of IP addresses per VLAN, bandwidth, unit cost, speed, security, etc.) and reliability/HA models (e.g. desired network resiliency, including e.g. link aggregation, NIC teaming, etc.). The VNFD shall support these types of VNFC requirements, including support for different redundancy models if requested.

M

NR

No requirement to the VNF

The VNFD typically provided by the VNF Provider is not expected to be edited by any other entity. Management and orchestration shall ensure the integrity of this VNFD.

M

NR

No requirement to the VNF

Some VNFs may require specific processing and storage capability, (i.e. dedicated CPU type or number of CPUs, dedicated memory, accelerators, etc.). It shall be possible to specify these properties in the VNFD.

M

NR

No requirement to the VNF

It shall be possible to specify in the VNFD whether to allocate/deallocate an address of a given address type to a VNFC instance when it is created/terminated.

M

NR

No requirement to the VNF

A VNF supporting scalability will describe the different types of scalability supported (e.g. scale up, scale down, scale in, scale out) and describe how each one is achieved, for instance describing which VNFC(s) should be scaled. It shall be possible to specify these properties in the VNFD.

M

C

The SAPC describes the way of scaling the VNF.

It shall be possible to specify in the VNFD whether to allocate/deallocate an address of a given address type to a VNFC instance when it is created/terminated as a result of scaling out/in.

M

NR

No requirement to the VNF