This page section describes how to createdesign, registerdevelop, and activate submit a Virtual Network Function , which is for use as a Network Resource in the ONAP environment.

A 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.

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

can be developed in a stand-alone development environment without most of the tools – or even API libraries – used or furnished by ONAP. The completed VNF must meet the set of VNF Requirements.

The primary audiences for this documentation are

• VNF providers: creators of VNFs (executables and related configuration files)
• Acceptance personnel: those tasked with certifying VNFs (approving them to run in ONAP environments)

The following readers may wish to refer to this documentation for a deeper understanding of VNFs, however, for operational information, they should read Using ONAP.

• Service Designers: those who combine Virtual Functions (including VNFs) into Services in ONAP
• DevOps: those who deploy, operate, and monitor ONAP Services containing VNFs

There are three stages in the life cycle of a VNF, shown here:

Image Added

Figure 1. VNF complete life cycle stages

Anchor
RefDocs RefDocs

Reference Documents for VNF Providers

The ONAP release documentation is available at ONAP.readthedocs.io, including VNF Provider guidance: VNF Guidelines, VNF Requirements 

Example VNFs Included with ONAP

The example VNFs distributed with ONAP are:

• vFW (Firewall)
• vDNS (Domain Name Server).

The Setting Up ONAP pages describe how to design and operate Services using these VNFs.

Reference VNFs are managed by the Integration ProjectThe <<SDC Demo Guide>> gives an example of onboarding a VNF.