• Created by Unknown User (fay), last modified on Jan 18, 2017

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

This page describes how to design, develop, and integrate 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 Life Cycle 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, combined, enumerate all the requirements that any VNF must meet in order to be instantiated in OpenECOMP. 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: Functions That a VNF Must or May Implement

<<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?>>

Example VNFs Included with OpenECOMP

The example VNFs distributed with OpenECOMP are:

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

The Demos page describes how these functions operate.

Onboarding (Integrating and Delivering) a VNF

<<TODO: This section will explain how to add a VNF to the AAI inventory; perhaps it will point to the User Guide>>

Using VNFs

To learn how to incorporate VNFs into a Service, see the <<DocRef:: Service Design and Creation (SDC) Introductory Developers Guide>>.

The Demos page exhibits the activation of Services containing VNFs.


  • No labels