This section describes how to design, develop, and deliver submit a Virtual Network Function , which is for use as a Network Resource in the ONAP environment.
A Virtual Network Function (VNF) Onboarding in OpenECOMPcan 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 Validating, Certifying, and Onboarding certifying VNFs (making approving them available in an OpenECOMP instance)
...
- 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 OpenECOMPin ONAP
- OpenECOMP OperatorsDevOps: 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
Reference Documents
...
<<DocRef: OpenECOMP Requirements and Guidelines for Virtual Network Functions in a Network Cloud>>
- identifies audiences interested in VNFs
- describes the VNF environment
- gives an overview of requirements
- points out differences between OpenECOMP VNFs and ETSI VNFs
<<DocRef: Common Requirements for Virtual Network Functions>>
- general Requirements for all VNFs (e.g., Security, Resiliency, Operations, Design)
<<DocRef: OpenECOMP Requirements for Virtual Network Functions>>
- requirements for how VNFs interact with and use OpenECOMP
<<DocRef: Heat Template Requirements for Virtual Network Functions>>
- provides recommendations and standards for building Heat templates compatible with OpenECOMP
Currently, these guidelines are intended for network clouds based on OpenStack. Future versions are envisioned to include other targeted virtualization environments, such as Customer Premises or other single-tenant small scale cloud implementations.
Overview of VNF Requirements
VNFs must meet requirements that fall into the categories of packaging, configuration, run-time monitoring and management, and licensing.
Packaging
The specification states that "Initially this information may be provided in documents, but in the near future a method will be developed to automate as much of the transfer of data as possible...".
Configuration
Regarding configuration management, "The VNF providers must provide the device YANG model and NETCONF server, supporting NETCONF APIs, to comply with target OpenECOMP and industry standards." In addition, the supplier "shall demonstrate mounting the NETCONF server on OpenDaylight (client)...", and successfully carry out specified operations thereon.
Run-Time Monitoring and Management
A VNF must provide event records as specified in the documentation. These event records describe a change of state or other loggable event.
Licensing
VNFs must conform to certain licensing restrictions, such as providing a universal license key, providing metrics (such as the number of subscribers), and not depending on a license server.
The VNF API: Functions That a VNF Must or May Implement <<TODO: in progress>>
<<TODO: This might be a pointer to NETCONF or ETSI specs, along with other OpenECOMP APIs. The Requirements documents above don't enumerate all functions in the API, but they might contain enough references to other documents to comprise the full description of functions that VNFs must implement. >>
OpenECOMP Common Functions that VNFs May Invoke
See Common Services.
VNF Attribute Definitions
<<TODO: is there a list of all possible VNF attributes? Is it already contained in the Requirements documents above?>>
...
Anchor | ||||
---|---|---|---|---|
|
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).
...
- .
Onboarding (Integrating and Delivering) 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:
<<TODO: fill out these sections, or reconsider>>
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
Using VNFs
To learn how to incorporate VNFs into a Service, see the <<DocRef:: the "Design" section of the Users Guide>>.
The Demos page exhibits the activation of Services containing VNFsThe Setting Up ONAP pages describe how to design and operate Services using these VNFs.
Reference VNFs are managed by the Integration Project.