1. Deployment Flavour as VNF Capability: Alt1_r2
April 11, 2017
Thinh Nguyenphu, Nokia
History:
R1: based on each DF (different topology) would be represented in its own Service Template. And, All the common attributes of VNFD should be described in as properties within VNFD capability type.
R2: update slide 7

2. Overview: VNF Node Type: tosca. nodes. nfv
Overview: VNF Node Type: tosca.nodes.nfv.VNF: (DF & VNFD as a VNF capabilities)
VNF
topology template:
substtution_mappings:
tosca.nodes.nfv.VNF
capabilities:
vnf_common:
deployment_flavour
requirements:
virtual_link
node templates:
tosca.nodes.nfv.VNF.Header
tosca.nodes.nfv.VDU.Compute
tosca.nodes.nfv.VDU.VirtualStorage
tosca.nodes.nfv.VduCpd
tosca.nodes.nfv.VL
tosca.nodes.nfv.ExtCpd
tosca.nodes.nfv.VNF:
derived_from: tosca.nodes.Root
capabilities:
vnf_common:
type: tosca.capabilities.nfv.VNFD
deployment_flavour:
type: tosca.capabilities.nfv.VnfDeploymentFlavour
#monitoring_parameter:
# modeled as ad hoc capabilities in VNF node template
requirements:
- virtual_link:
capability: tosca.capabilities.nfv.VirtualLinkable
relationship: tosca.relationships.nfv.VirtualLinksTo
node: tosca.nodes.nfv.VL
occurrences: [ 0, UNBOUNDED ]
# still under discussion:
#interfaces:
# Basic: # not to collide with Standard on tosca.nodes.Root
# type: tosca.interfaces.nfv.vnf.lifecycle.Basic
# Healable:
# type: tosca.interfaces.nfv.vnf.lifecycle.Healable
# Scalable:
# type: tosca.interfaces.nfv.vnf.lifecycle.Scalable
# Custom:
# type: tosca.interfaces.nfv.vnf.lifecycle.Custom
VNF tosca.nodes.nfv.VNF
cap:
req
vnf:
deployment_flavour:
interfaces VL
Node Type
Service template
Note: tosca.nodes.nfv.VNF.Header is not a manageable entity, and DependOn relationship is required.

3. tosca.capabilities.nfv.VNFD:
derived_from: tosca. capabilities.Root
properties:
descriptor_id: # instead of vnfd_id
type: string # GUID
required: true
descriptor_version: # instead of vnfd_version
type: string
provider: # instead of vnf_provider
product_name: # instead of vnf_product_name
software_version: # instead of vnf_software_version
product_info_name: # instead of vnf_product_info_name
required: false
product_info_description: # instead of vnf_product_info_description
vnfm_info:
type: list
entry_schema:
localization_languages:
default_localization_language:

4. tosca.capabilities.nfv.VnfDeploymentFlavour:
derived_from: tosca.capabilities.Root
properties:
flavour_id:
type: string # Identifier
description:
type: string
required: true
vdu_profile:
type: map # key: VDU id
entry_schema:
type: tosca.datatypes.nfv.VduProfile
vl_profile:
type: map # key: VL id
type: map # key: VlFlavour id
type: tosca.datatypes.nfv.VlProfile
required: false
instantiation_levels:
type: map
type: tosca.datatypes.nfv.InstantiationLevel
default_instantiation_level_id:
#supported_operations:
# modeled as operations
lcm_operations_configuration:
type: tosca.datatypes.nfv.VnfLcmOperationsConfiguration
required: false # true in IFA011, but all members are false
#affinity_or_anti_affinity_groups:
# modeled as policies
#monitoring_parameters:
# modeled as ad hoc capabilities in VNF node template
scaling_aspects:
type: map # key: aspectId
type: tosca.datatypes.nfv.ScalingAspect

5. Using enhance substitution_mappings grammar (properties, capabilities)

6. Using enhance substitution_mappings grammar (capabilities)
VNF (abstract)
VNFDeplymentFlavour
req
req
ECP1
req
req
req
property
property
ECP2
req
property
cap: DF
interface
deployment_flavour
cap: DF
interface
deployment_flavour
VDU1
VDU2 … … …
(DF = Deployment Flavour)
Note: substitution_mappings gramma enhancement in Simple YAML v1.2:
Properties in substitution_mappings
In-place capabilities in substitution_mappings
Interfaces in substitution_mappings
Indexed access of requirements in substitution_mappings

7. DF tosca.nodes.nfv.VnfDeploymentFlavour
Overview: Using enhance substitution_mappings grammar (capabilities) 1/2
VNF
topology template:
substtution_mappings:
type: tosca.nodes.nfv.VnfDeploymentFlavour
properties:
capabilities:
deployment_flavour
requirements:
virtual_link
node templates:
tosca.nodes.nfv.VDU.Compute
tosca.nodes.nfv.VDU.VirtualStorage
tosca.nodes.nfv.VduCpd
tosca.nodes.nfv.VL
tosca.nodes.nfv.ExtCpd
tosca.nodes.nfv.VnfDeploymentFlavour:
derived_from: tosca.nodes.Root
capabilities:
vnf_common:
type: tosca.capabilities.nfv.VNFD
deployment_flavour:
type: tosca.capabilities.nfv.VnfDeploymentFlavour
#monitoring_parameter:
# modeled as ad hoc capabilities in VNF node template
requirements:
- virtual_link:
capability: tosca.capabilities.nfv.VirtualLinkable
relationship: tosca.relationships.nfv.VirtualLinksTo
node: tosca.nodes.nfv.VL
occurrences: [ 0, UNBOUNDED ]
# still under discussion:
#interfaces:
# Basic: # not to collide with Standard on tosca.nodes.Root
# type: tosca.interfaces.nfv.vnf.lifecycle.Basic
# Healable:
# type: tosca.interfaces.nfv.vnf.lifecycle.Healable
# Scalable:
# type: tosca.interfaces.nfv.vnf.lifecycle.Scalable
# Custom:
# type: tosca.interfaces.nfv.vnf.lifecycle.Custom
DF tosca.nodes.nfv.VnfDeploymentFlavour
cap:
req
deployment_flavour:
interfaces VL
properties
Node Type
Service template
Note: substitution_mappings gramma enhancement in Simple YAML v1.2:
Properties in substitution_mappings
In-place capabilities in substitution_mappings
Interfaces in substitution_mappings
Indexed access of requirements in substitution_mappings

8. VNF Packaging: Discussion & issues

9. VNF Package: Discussion
VNF Package contains:
the VNF descriptor (VNFD) that defines metadata for package onboarding and VNF management
Artifacts:
the software images needed to run the VNF
optional additional files to manage the VNF (e.g. scripts, vendor-specific files etc.)
Is digitally signed and delivered by the VNF provider as a whole
Is immutable (protected from modification)
Is stored in a repository by the NFVO
Can be accessed by VNFM
Option 1
Option 2
VNF Package
VNF Package
VNFD(s)
VNFD
Artifact(s)
Artifact(s)
Discussion:
Option 1: Single VNF package contains all of VNFD(s) + all of supported artifacts + manifest file. Or,
Option 2: Single VNF package contains a VNFD + all of supported artifacts + manifest file.
Manifest
Manifest
Current thinking of some TOSCA NFV Adhoc members
VNFD= single DF

10. VNF Package: Option 1 Discussion: Open issue:
Single VNF package contains all of VNFD(s) + all of supported artifacts + manifest file.
Open issue:
The current approach does not satisfy with the requirement VNF_PACK.ID.002
VNF_PACK.ID.002: VNF Package shall be globally uniquely identifiable. The globally unique identifier for the VNF Package shall be used to uniquely identify the VNFD and the VNF included in the package.
Vnf package id = vnfd id
Impacting to the Change VNF Flavour operation “ChangeVnfFlavourRequest “
A new DF id “flavour_id” and information are in another VNFD.
Requires a new VNF via creating a new VNF identifier “vnfInstanceId” and perform another operation. Also, it will requires VNFM to terminate existing VNF instance.
At the time of creating a new VNF instance identifier, the NFVO must know which DF to be deployed. It is a major impact.
Impacting VNF Package onboarding operation.
Multiple VNF identifiers within a package is not compatible with IFA interface specifications.
Option 1
VNF Package
VNFD(s)
Artifact(s)
Manifest

11. VNF Package: Option 2 Discussion: Open issue:
Single VNF package contains a VNFD + all of supported artifacts + manifest file.
Open issue:
Impacting to the Change VNF Flavour operation “ChangeVnfFlavourRequest “
A new DF id “flavour_id” and information are in another VNFD.
Creating additional burden to NFVO and VNFM to track and manage “onboardedVnfPkgInfoId”, “vnfId”, “vnfInstanceId”, notification operation, local storages.
Requires a new VNF via creating a new VNF identifier “vnfInstanceId” and perform another operation. Also, it will requires VNFM to terminate existing VNF instance.
At the time of creating a new VNF instance identifier, the NFVO must know which DF to be deployed. It is a major impact.
Impacting to VNF Provider software delivery and packaging their product, such as increasing risk of errors, managing many SW packages with different DFs. Similar issue at the service provider side.
Option 2
VNF Package
VNFD
Artifact(s)
Manifest
Current thinking of some TOSCA NFV Adhoc members
VNFD= single DF