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.

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.

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.

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!

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.