5 VNF Descriptor Template for NFV
5.1 Introduction
The VNF Descriptor (VNFD) describes the topology of the VNF by means of ETSI NFV
IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual Links, External Connection
Points, Scaling Aspects, Instantiation Levels and Deployment Flavours.
The VNFD (VNF Descriptor) is read by both the NFVO and the VNFM. It represents the
contract & interface of a VNF and ensures the interoperability across the NFV functional
blocks. The following figure illustrate an UML representation of the VNFD high level
elements structure, as defined in the [IFA011].
Figure xx: VNFD high-level structure [IFA011]
The main parts of the VNFD are the following:

VNF topology: it is modeled in a cloud agnostic way using virtualized containers and their
connectivity. Virtual Deployment Units (VDU) describe the capabilities of the virtualized
containers, such as virtual CPU, RAM, disks; their connectivity is modeled with VDU
Connection Point Descriptors (VduCpd), Virtual Link Descriptors (Vld) and VNF External
Connection Point Descriptors (VnfExternalCpd);

VNF deployment aspects: they are described in one or more deployment flavours, including
instantiation levels, supported LCM operations, VNF LCM operation configuration
parameters, placement constraints (affinity / antiaffinity), minimum and maximum VDU
instance numbers, and scaling aspect for horizontal scaling.
5.2 TOSCA Types
The following table defines the TOSCA Type “derived from” values that SHALL be used when
using the TOSCA Simple Profile for NFV version 1.0 specification [TOSCA-Simple-ProfileNFV-v1.0] for NFV VNFD.
ETSI NFV
TOSCA VNFD
Derived from
Comment:
Element
[TOSCA-Simple-
derived from [TOSCA-Simple-
[IFA011]
Profile-NFV-v1.0]
Profile-NFV-v1.0] (csd03)
Editor note: The intent of this
column is to aid the development of
the profile. It will be removed when
the next version of committee spec.
draft.
VNF
tosca.nodes.nfv.VNF
tosca.nodes.Root
tosca.nodes.Root
Existing in csd03, additional
modification is needed
VDU
tosca.nodes.nfv.VDU
tosca.nodes.Root
tosca.nodes.Root
existing in csd03, additional
modification is needed
CP
tosca.nodes.nfv.CP
tosca.nodes.Root
tosca.nodes.network.Port
(Connection
Point)
Existing in csd03. New type is
required.
Proposing to use “tosca.node.Root”
instead of the current
“tosca.nodes.network.Port”
Reason: tosca.nodes.network.Port
profile contains parameters that are
not mapping with IFA011 elements
requirements.
VL (Virtual
Link)
tosca.nodes.nfv.VL
tosca.nodes.Root
tosca.nodes.network.Network
Existing in csd03. New type is
required.
Proposing to use “tosca.node.Root”
instead of the current
“tosca.nodes.network.Network”
Reason:
tosca.nodes.network.Network
profile contains parameters that are
not mapping with IFA011 elements
requirements.
External
tosca.nodes.nfv.ECP
tosca.nodes.Root
Connection
New to [TOSCA-Simple-ProfileNFV-v1.0] (csd03)
Point
external side: link to external VL;
internal side: link to CP xor link to
internal VL
Virtual
tosca.nodes.nfv.VS
tosca.nodes.Root
Storage
New to [TOSCA-Simple-ProfileNFV-v1.0] (csd03)
requirement of VDU
Virtual
tosca.nodes.nfv.VC
tosca.nodes.Root
Compute
New to [TOSCA-Simple-ProfileNFV-v1.0] (csd03)
requirement of VDU
Software
tosca.nodes.nfv.SwI
Image
mage
tosca.nodes.Root
New to [TOSCA-Simple-ProfileNFV-v1.0] (csd03)
requirement of VS and VC
Deployment
tosca.capabilities.nfv.
Flavour
DeploymentFlavour
NFV-v1.0] (csd03)
Editor note: For
capability of VNF; different
further study to
deployment flavours to be defined
determine the type.
in different service templates
Scaling
tosca.datatypes.nfv.
Aspect
ScalingAspect
tosca.capabilities.Root
tosca.datatypes.Root
New to [TOSCA-Simple-Profile-
New to [TOSCA-Simple-ProfileNFV-v1.0] (csd03)
Editor note: For
property of Deployment Flavour
further study to
determine the type.
Element
tosca.groups.nfv.Ele
tosca.groups.Root
New to [TOSCA-Simple-Profile-
Group
mentGroup
NFV-v1.0] (csd03)
Editor note: For
used in Scaling Aspect
further study to
determine the type.
Instantiation
tosca.datatypes.nfv.I
Level
nstantiationLevel
NFV-v1.0] (csd03)
Editor note: For
property of Deployment Flavour
further study to
determine the type.
tosca.datatypes.Root
New to [TOSCA-Simple-Profile-
5.3 TOSCA model for VNFD
Figure 5.3-1: TOSCA node, capability and relationship types used in VNF
applicationTOSCA template for VNFD
The substitution mapping feature as defined in [TOSCA-Simple-Profile-YAML], is used to
define a new node type, which its characteristics can be mapped to internal elements of a
service template.
Figure 5.3-2: Substitution mapping for a VNF node type to a service template
Figure 5.3-2 shows an example of the internal structure of a VNF. In this example, VNF2
comprises 3 VDUs which connect to an internal Virtual Link. The first VDU has two
Connection Points: one (CP21) used to connect the external Virtual Link, another one used
(CP22) to connect the internal Virtual Link. VDU provides the capability Bindable to bind
Connection Point. Connection point has two requirements, bindable and virtualLinkable. The
connection point that has the requirement to the external virtual link exposes the
virtualLinkable requirement of the VNF. The external connection point (CP21) also has
Forwarder capability, used to form the network forwarding path
tosca_definitions _version:
tosca_simple_profile_for_nfv_1_0
description: example for VNF2
metadata:
ID:
# ID of this Network Service
Descriptor
vendor:
# Provider or vendor of the Network
Service
version:
Descriptor
topology_template:
inputs:
substitution_mappings:
# Version of the Network Service
node_type: tosca.nodes.nfv.VNF.VNF2
requirements:
virtualLink1: [CP21, virtualLink]
capabilities:
forwarder1: [CP21, Forwarder]
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU
properties:
# omitted here for brivity
requirements:
- host:
node_filter:
capabilities:
# Constraints for selecting “host” (Container Capability)
- host
properties:
- num_cpus: { in_range: [ 1, 4 ] }
- mem_size: { greater_or_equal: 2 GB }
artifacts:
VM_image:vdu1.image
#the VM image of VDU1
Interface:
Standard:
create:vdu1_install.sh
configure:
implementation: vdu1_configure.sh
VDU2:
type: tosca.nodes.nfv.VDU
properties:
# omitted here for brivity
VDU3:
type: tosca.nodes.nfv.VDU
properties:
# omitted here for brivity
CP21:
#endpoints of VNF2
type: tosca.nodes.nfv.CP
properties:
type:
requirements:
virtualbinding: VDU1
capabilities:
Forwarder
CP22:
type: tosca.nodes.nfv.CP
properties:
type:
requirements:
virtualbinding: VDU1
virtualLink: internal_VL
CP23
type: tosca.nodes.nfv.CP
properties:
type:
requirements:
virtualbinding: VDU2
virtualLink: internal_VL
CP24
type: tosca.nodes.nfv.CP
properties:
type:
requirements:
virtualbinding: VDU3
virtualLink: internal_VL
internal_VL
type: tosca.nodes.nfv.VL.ELAN
properties:
# omitted here for brivity
capabilities:
-virtual_linkable
occurrences: [1, 5]
In the example above, ID, vender and version are defined service_properties for VNFD
specific usage. The topology_template defines the internal structure of VNF2. In the
substitution_mappings element, it defines the node type as tosca.nodes.nfv.vnf2 which is the
substitutable node type as defined by this service template. The virtualLinkable requirement is
exposed by the virtualLinkable requirement of CP21.
VDU as a compute component in VNF, has requirement for compute and memory, it may also
include VM image, which can be described as artifact. CP21 as the endpoint of VNF2, has
binding requirement for VDU1, and virtualLinkable requirement for external virtual link. CP22,
CP23 and CP24 are internal connection point of VNF2, which all connect to the internal_VL.