This section describes how to design, develop, and submit a Virtual Network Function for use as a Network Resource in the OpenECOMP ONAP environment.Additionally, this section includes an outline of actions to be taken by a service provider to design and deploy a Service containing a VNF

A Virtual Network Function 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: thse those tasked with certifying VNFs (approving them to run in OpenECOMP environments)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 OpenECOMPin ONAP
• DevOps: those who deploy, operate, and monitor OpenECOMP ONAP Services containing VNFs

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

Image RemovedImage Added

Figure 1. VNF complete life cycle stages

Anchor
RefDocs RefDocs

Reference Documents for VNF Providers

There are four reference documents for VNF Providers, summarized here.

<<DocRef: VNF Guidelines for Network Cloud and OpenECOMP>>

• identifies audiences interested in VNFs
• describes the VNF environment
• gives an overview of requirements
• points out differences between OpenECOMP VNFs and ETSI VNFs

<<DocRef: VNF Cloud Readiness Requirements for OpenECOMP (formerly: "Common Requirements...">>

• design requirements (API versioning, decomposition, reliance on open source database, packet size limitations)
• resiliency requirements
• security requirements

<<DocRef: VNF Management Requirements for OpenECOMP>>

• requirements imposed by the targeted network cloud infrastructure, including the hypervisor
• identification requirements for the VNF and its components
• configuration management requirements
  
  • a VNF must provide a Device YANG model
  • a VNF must implement a NETCONF server; the required NETCONF API's are referenced, and the supplier must demonstrate mounting the NETCONF server on OpenDaylight
• monitoring and operations requirements
  • format of messages (event records)
  • frequency of reporting
  • security
• licensing requirements

<<DocRef: VNF Heat Template Requirements for OpenECOMP>>

• provides recommendations and standards for building Heat templates compatible with OpenECOMP

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 OpenECOMP ONAP are:

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

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

VNF Acceptance

Here is an outline of the steps used by a service provider to test a VNF and add it to the OpenECOMP inventory.

Pre-onboarding

1. Create a tenant
2. Validate VFs
3. Generate manifest and package artifacts

Resource onboarding

1. Create a license model
2. Licensing
   1. Create a license key group [optional]
   2. Create an entitlement pool
   3. Create a feature group
   4. Create a license agreement
3. Create a Vendor Software Product
4. Update VFCs in a VSP [optional]
5. Update a VSP [optional]

VF creation and testing

1. Create a VF
2. Update a VF [optional]
3. Submit a VF for testing
4. Test a VF

Designing a Service Using a VNF

1. Create a service
2. Create workflows [optional]
   1. Create a management workflow [optional]
   2. Create a network callflow [optional]
   3. Select VID inputs [optional]
3. Update a service [optional]
4. Submit a service for testing
5. Test a service
6. Assign an IP address plan

Governance Approval and Service Distribution

1. Review a service for governance approval
2. Request service distribution
3. Distribute a service
4. Verify that the blueprint is deployed

Closed Loop Design

1. Design a model
2. Collector
   1. Configure Collector
   2. Configure StringMatch
   3. Configure Policy

Policy Design

...

Reference VNFs are managed by the Integration Project.