This page describes how to create, register, and activate a Virtual Network Function, which is a Network Virtual Network Function (VNF) Onboarding.

In this specification, the terms must, must not, should, should not, and may, have specific meanings defined here.

Overview: Guidelines for Virtual Network Functions in a Network Cloud

The following document describes the motivation for VNFs, the various audiences interested in VNFs, and the differences between OpenECOMP VNFs and ETSI VNFs:

<< point to the document "Guidelines for Virtual Network Functions in a Network Cloud" when it is "open" >>

A key distinction between VNFs created for OpenECOMP versus VNFs created for ETSI's MANO model is this: under OpenECOMP, VNF providers do not provide their own proprietary VNF Managers (VNFM) or Element Management Systems (EMS). Those capabilities are provided by OpenECOMP. Hence, VNFs are required to consume standard interfaces to OpenECOMP in support of management and control. The VNF Package must include the appropriate data models for integration with OpenECOMP to enable control of the VNFs. The resulting standardization of VNFs will allow them to interoperate and to be managed consistently.

Network-cloud-ready VNF characteristics and design considerations can be grouped into four areas: Modularity, Targeted Virtualization Environment, OpenECOMP-ready, and CI/CD

Modularity

A VNF must be modular: it must be composed of single-capability, independent components (VFCs). Each of the VFCs manage a small amount of decoupled state (or no state at all), use lightweight and open APIs, and are reusable.

Single Capability: Composed of VNF Components (VNFCs)

VNFs should be composed of loosely-coupled, granular, re-usable Virtual Network Function Components (VNFCs). Each VNFC should be responsible for a single capability. However, a VNFC should not be so small that the overhead of constructing, maintaining, and operating the component outweighs its utility.

If a VNFC is to be reused by different VNFs, it should be encapsulated within a VNF having no other VNFCs.

Independence of VNFCs

VNFCs must be independently deployed, configured, upgraded, scaled, monitored, and administered (by OpenECOMP). The VNFC must be a standalone executable process.

VNFCs must use "API versioning". To be able to independently evolve a component, versioning must ensure existing clients of the component are not forced to flash-cut with each interface change. API versioning enables smoother evolution while preserving backward compatibility.

Managing State

VNFCs and their interfaces should isolate and manage state to allow for high-reliability, scalability, and performance in a network cloud environment. The use of state should be minimized as much as possible
to facilitate the movement of traffic from one instance of a VNFC to another. Where state is required it should be maintained in a geographically redundant datastore that may in fact be its own VNFC.

This concept of decoupling state data can be extended to all persistent data. Persistent data should be held in a loosely coupled database. These decoupled databases need to be engineered and placed correctly to still meet all the performance and resiliency requirements of the service.

VNFCs Use Lightweight and Open APIs

Key functions are accessible via open APIs, which align to industry API standards and supported by an open and extensible information/data model.

Reusability

VNFCs should be designed to be reusable within the VNF as well as by other VNFs. The “single capability” principle aids in this requirement. If a VNFC could be reusable by other VNFs, then it should be designed as its own single component VNF that may then be chained with other VNFs. Likewise, a VNF provider should make use of other common platform VNFs such as firewalls and load balancers, instead of building their own.

Targeted Virtualization Environment

ECOMP Ready

CI/CD

Creating a VNF

The VNF API

All VNF's (in fact, all Virtual Functions of any kind) should contain monitoring properties.

VNF Attribute Definitions

Registering a VNF

Activating a VNF

The <<SDC Demo Guide>> gives an example of onboarding a VNF.