This page section describes how to createdesign, registerdevelop, and activate submit 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.
Guidelines for Virtual Network Functions in a Network Cloud
The following document describes, in general terms, the requirements for VNFs. It also provides background material: the motivation for VNFs, and the various audiences interested in VNFs. In addition, it points out, in general terms, the differences between OpenECOMP VNFs and ETSI VNFs.
<<DocRef: "Guidelines for Virtual Network Functions in a Network Cloud">>
Figure 1 VNF Complete Lifecycle Stages
VNF Requirements
VNFs must meet requirements that fall into the categories of packaging, configuration, run-time monitoring and management, and licensing. Also VNF must communicate using event records (indicating a change of state, or loggable event, for example).
With respect to 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...".
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.
For run-time monitoring and management, a VNF must provide event records as specified in the document.
Finally, VNFs must conform to certain licensing restrictions, such as providing a universal license key, providing metrics (such as the number of subscribers), an not depending on a license server.
The following reference documents list, in detail, the requirements for VNFs. The "OpenECOMP" document is more detailed. These documents may be merged in the future.
<<DocRef: "Common Requirements for Virtual Network Functions">>
<<DocRef: "OpenECOMP Requirements for Virtual Network Functions:>>
The VNF API
VNF Attribute Definitions
Registering a VNF
Activating a VNF
for use as a Network Resource in the ONAP environment.
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: 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:
Figure 1. VNF complete life cycle stages
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 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 <<DocRef: SDC Demo Guide>> gives an example of onboarding a VNF.