This section describes how to design, develop, and submit a Virtual Network Function 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

Reference Documents for VNF Providers

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 Project.

  • No labels

15 Comments

  1. Herb Patten

    There is a typo in the bullet under the VNF Heat Template Requirements for OpenECOMP. The end of the bullet says "ONA" when it should be "ONAP"

    1. Daniel Rose

      thanks, fixed

  2. ramki krishnan

    In the VNF Management requirements document only VM is called out explicitly. What does this signify for container-based VNFs?

    1. Daniel Rose

      the initial release mostly focused on VM based VNFs. some one from the ICE / VNK SDK team (like Steven Wright) can look at them and see how we want to evolve them for containers.

    2. Steven Wright

      Containerization obviously has to be part of the ONAP roadmap, but  Release 1 is focused on the uses cases and alignment of ECOMP and Open-O.  There is at least one project on containerization of platform components though.

  3. ramki krishnan

    Thanks Daniel.

  4. Suresh Babu Nekkalapudi

    This is an important section for VNF Vendors. It would be great if the actions listed in each stage of VNF life cycle are eloborated.

    Say for a service  provider VNF (Design Time): What it means by select, order etc.. 

    1. Daniel Rose

      Steven Wright can take into account your feedback in the validation and associated projects.

    2. Steven Wright

      The VNF Requirements Project provides some guidance. There are  a couple of contributed documents identified as seed material that may be helpful.  These seed documents still need to be integrated and aligned with the ONAP Release 1 architecture, though.

  5. Laurentiu Soica

    Are the TOSCA based VNFs supported in the current ONAP version ?

    1. Daniel Rose

      no that is a key deliverable of the next release

  6. Milind Jalwadi

    The TOSCA profile for NFV would need to support specification and relation between VNF and VNFC. Is this something being proposed in TOSCA specifications? Is there any other way how this relationship would be captured? Thanks! 

    1. Milind Jalwadi

      From the TOSCA simple profile for NFV, it seems the best way to represent VNFCs, is to use the TOSCA composition feature (node template substitution for model composition).

      ETSI  NFV-IFA 011 defines the VNFD information element in which it specifies one or multiple VDUs (Virtualisation Deployment Unit). This VDU shall describe the VNFC.

      Thus for the following scenarios, the best modular way of using particular TOSCA features would be –

      1. Service having single VNF and VNF having single VNFC – This is the simplistic scenario. Two TOSCA templates could be used –

         a. One TOSCA template for VNFD could be used that details connectivity – ex. VDU Connection Point Descriptors (VduCpd), Virtual Link Descriptors (Vld) and VNF External Connection Point Descriptors (VnfExternalCpd). This template shall also mention a TOSCA VDUComposition (type: tosca.nodes.nfv. VDUComposition) for VNFC

         b. Second TOSCA template for VDU description that states requirements of the virtualized VNFC container such as virtual CPU, RAM, disks etc. This shall also have the TOSCA tag “subsititution_mappings” – so that this could be substituted by the orchestrator when referenced in ‘a’ above.

      2. Service having single VNF and VNF having multiple VNFCs – The similar modular approach above would be extended for this scenario. The VNFD TOSCA template would specify all the VNFCs as type tosca.nodes.nfv. VDUComposition. The VDU template description for every VNFC shall include the TOSCA tag “subsititution_mappings”. The connection descriptions and other infrastructure parameters could be specified in the relevant templates, based on the topology of VNFCs.

      3. Service having multiple VNFs and VNFs having multiple VNFCs – This scenario is again the extension of above, where we would have one TOSCA template to describe a service that is composed of multiple VNFs. The ‘tosca.nodes’ type could probably be used to describe this root template. This root template shall further reference individual VNFs - again as ‘tosca.nodes’ type. The further specifications of VNFs and substitutions of VNFCs could be similar to points 2 & 1 above.

      Comments would be highly appreciated! Thanks.

  7. Alina Radivoi

    Hello

    What is the best way to install the software on top on a linux qcow image in Onap? For now, part of our application installs via ansible playbooks, is ansible foreseen in Onap?

    Thank you in advance

    Regards

    Alina

  8. Amal Ahmed Anda

    Can you please tell me what is vnf indicators? How we can identify its names and values. It is related to NFR