5.1.1. Introduction
The following sub-clauses describe the numbered requirements for VNF Descriptor (VNFD) and PNF Descriptor (PNFD) or in other words the VNF/PNF Service Template based on the most updated draft of ETSI NFV-SOL001 standard for VNF/PNF Descriptor. The ETSI standard specifies a NFV specific data model using TOSCA/YAML data model constructs specified in TOSCA Simple Profile in YAML v.1.2.
The requirements for TOSCA/CSAR based VNF/PNF package are described as well and they are based on ETSI NFV-SOL004 standard.
5.1.1.1. References
ETSI GS NFV-SOL001 v.2.5.1
TOSCA SIMPLE Profile in YAML v.1.2
ETSI GS NFV-SOL004 v.2.6.1 + NFV CR NFVSOL(18)000746r3.
5.1.1.2. Intended Audience
This document is intended for developers of VNF TOSCA templates that will be orchestrated by ONAP. The document is also applicable for creating RFP’s with the list of required TOSCA/YAML features supported by VNF provider.
5.1.1.3. Scope
ONAP implementations of Network Cloud supports TOSCA Templates, also referred to as TOSCA in this document.
ONAP requires the TOSCA Templates to follow a specific format. This document provides the mandatory, recommended, and optional requirements associated with this format.
5.1.1.4. Overview
The document includes three charters to help the VNF or PNF providers to use the VNF or PNF model design tools and understand the VNF or PNF package structure and VNF or PNF TOSCA templates.
In the ONAP, VNF or PNF Package and VNFD or PNFD template can be designed by manually or via model designer tools. VNF or PNF model designer tools can provide the GUI and CLI tools for the VNF or PNF provider to develop the VNF or PNF Package and VNFD or PNFD template.
The VNF or PNF package structure is align to the NFV TOSCA protocol, and supports CSAR
The VNFD or PNFD and VNF or PNF package are all align to the NFV TOSCA protocol, which supports multiple TOSCA template yaml files, and also supports self-defined node or other extensions.
5.1.1.5. TOSCA Introduction
TOSCA defines a Meta model for defining IT services. This Meta model defines both the structure of a service as well as how to manage it. A Topology Template (also referred to as the topology model of a service) defines the structure of a service. Plans define the process models that are used to create and terminate a service as well as to manage a service during its whole lifetime.
A Topology Template consists of a set of Node Templates and Relationship Templates that together define the topology model of a service as a (not necessarily connected) directed graph. A node in this graph is represented by a Node Template. A Node Template specifies the occurrence of a Node Type as a component of a service. A Node Type defines the properties of such a component (via Node Type Properties) and the operations (via Interfaces) available to manipulate the component. Node Types are defined separately for reuse purposes and a Node Template references a Node Type and adds usage constraints, such as how many times the component can occur.
Figure 1: Structural Elements of Service Template and their Relations
5.1.1.6. TOSCA Modeling Principles & Data Model
This section describing TOSCA modeling principles and data model for NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML V1.0], or new type based on ETSI NFV requirements, etc.