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 page includes an outline of service provider actions to design a Service containing a VNF, and to deploy the Service
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 ONAP environments)
Other audiences who may refer to these documents include: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:
Figure 1. VNF complete life cycle stages
Anchor | ||||
---|---|---|---|---|
|
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...">>
- general requirements for all VNFs
- requirements imposed by the targeted network cloud infrastructure, including the hypervisor
- resiliency requirements
- security requirements
<<DocRef: VNF Management Requirements for OpenECOMP>>
- design requirements: identification of 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
OpenECOMP Common Functions that VNFs May Invoke
See Common Services.
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 how these functions operate.
Designing a Service Using a VNF
The forthcoming <<DocRef: User Guide>>, in its "Design" section, will explain how to add any Virtual Function (including a Virtual Network Function) to the OpenECOMP environment. Here is an outline of the steps involved:
Pre-onboarding
- Create a tenant
- Validate VFs
- Generate manifest and package artifacts
Resource onboarding
- Create a license model
- Licensing
- Create a license key group [optional]
- Create an entitlement pool
- Create a feature group
- Create a license agreement
- Create a Vendor Software Product
- Update VFCs in a VSP [optional]
- Update a VSP [optional]
VF creation and testing
- Create a VF
- Update a VF [optional]
- Submit a VF for testing
- Test a VF
Service design
- Create a service
- Create workflows [optional]
- Create a management workflow [optional]
- Create a network callflow [optional]
- Select VID inputs [optional]
- Update a service [optional]
- Submit a service for testing
- Test a service
- Assign an IP address plan
Governance approval and service distribution
- Review a service for governance approval
- Request service distribution
- Distribute a service
- Verify that the blueprint is deployed
Closed loop design
- Design a model
- Collector
- Configure Collector
- Configure StringMatch
- Configure Policy
Policy design
- Import a policy attribute dictionary [optional]
- Edit a policy attribute dictionary [optional]
- Add a scope
- Assign a scope to a user
- Create a policy
- Push a policy
Deploying a VNF
The Setting Up ONAP pages describe how to design and operate Services using these VNFs.
Reference VNFs are managed by the Integration ProjectThe Demos page exhibits the activation of Services containing VNFs.