TOSCA Simple Profile for Network Functions Virtualization ... · Web view6.10.1.1 Description The...

TOSCA NFV/SDN AdhocSource: Thinh Nguyenphu, [email protected], Gabor Marton, [email protected], Nokia

Date: January 10, 2018

Type: Discussion

Purpose: Updating YAML team on the current deployment flavour in ETSI NFV SOL001 GS version 0.4.0 and seeking their review comments on the grammars and matching rule requirements per Simple YAML Profile v1.2.

Reference[1] ETSI NFV SOL001 v0.4.0: https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v040.zip

DiscussionThis document contains three major parts (highlighted in green header) of the contents to illustrate the complete solution of NFV deployment flavour, which is currently in the ETSI NFV SOL001 GS.

1) Example part: Annex A1 as defined in [1].2) Capabilities Types: from Nokia current proposal.3) Node Types: from Sub-clause 6.10 as defined in [1].

The grammars and matching rules are based TOSCA-Simple-Profile-YAML-v1.2-wd02-rev05-csd02-candidate-clean.docx, https://www.oasis-open.org/committees/document.php?document_id=62182&wg_abbrev=tosca

The contents with changes marks are new additional text which has not been accepted in SOL001 GS. These change marks contents are from Nokia to future clarify the VNFD deployment flavour solution.

The author of this document kindly request TOSCA YAML team to review this document with respect to the usage of grammar and matching rule as described in Capabilities Types: Additional Requirements, and Annex A.1.

Examples

A.1 VNFD with deployment flavour modelling design exampleDeployment flavours are represented as a capability of the VNF node type. This way one VNF service template represents one deployment flavour, and different deployment flavours are described by different VNF service templates. This is in line with the idea that different deployment flavours can define different topologies of the same VNF, with different scaling aspects, different VDUs and different internal connectivity.tosca-nfv-v1.0-csd04 11 May 2017Standards Track Work Product Copyright © OASIS Open 2017. All Rights Reserved. of 17

https://www.oasis-open.org/committees/document.php?document_id=62182&wg_abbrev=tosca

https://www.oasis-open.org/committees/document.php?document_id=62182&wg_abbrev=tosca

https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v040.zip

mailto:[email protected]

mailto:[email protected]

In order to represent a VNF with multiple deployment flavours, an extra level of indirection is introduced in form of a top-level service template. This top-level service template (illustrated by the upper-right template in the below figure) only contains an abstract VNF node which only defines the common parts of the different deployment flavours (such as product information, modifiable attributes and some of the lifecycle management operations) and leaves the deployment flavour capability undefined, or to be more precise, it puts a property constraint on the deployment flavour capability (the required value of the flavour_id property); this constraint comes from the higher level where an explicit value of the flavour_id property is selected. The instantiation request contains a flavour id selected among those available in the NSD.

Top-level: The substitution_mappings in the top-level template determines that the topology_template constitutes a VNF node i.e. it can be substituted for a VNF node template in a higher-level template (NSD). This information, although not necessary for the VNFM for managing the VNF, is necessary for the NFVO for managing an NS described by an NSD: for each VNF in the NS, it needs to read the content of the VNFD in order to perform the necessary preparations (uploading images to the VIM, creating compute flavors based on compute requirements, etc.) as well as the lifecycle management operations (e.g. passing network resource identifiers, based on the the virtual link requirements, in the instantiation parameters). The top-level substitution_mappings is the first thing read by the NFVO, telling that the service template represents a VNF.

Lower-level: The substitution_mappings in the lower-level templates determines that the topology_template constitutes a VNF node (with a given deployment flavour) i.e. it can be substituted for the abstract VNF node template in the top-level template. It is necessary for the VNFM in order to instantiate the VNF with the deployment flavour designated by the instantiation request. Note that the NFVO also needs to follow this lower-level substitution_mappings when reading the VNFD as relevant parts of the VNF are anticipated to be defined in the lower-level templates.

Editor's note: Clarification is needed on property constraints. Should input parameters be used instead of property constraints?

As a result, the NFVO and VNFM will look into the available further service templates representing a single VNFD (the lower-right ones in the figure) and substitute for the abstract VNF node the one that has the required deployment flavour capability.

Figure A.1 illustrates a simplified overall view of the VNFD service templates.


1) Figure A.1: VNFD overview with deployment flavour support

A VNFD is a TOSCA Service Template and model as the main template in the VNF package. It is interpreted by an NFVO or VNF manager. In this example, the templates describe two variants of the VNF each corresponding to a deployment flavour: a simple one and a complex one. The simple VNF consists of one server: a DB backend. Whereas, the complex VNF variant consists of minimum three DB backend servers and one serviceNode, which may be scaled out in one-size increments.

SunshineDB: VNFD-top level (abstract node template matching)

sunshine.vnfd.tosca.yaml

tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0_mycompany

description: Relational database, non-scalable

topology_template: substitution_mappings: node_type: tosca.nodes.nfv.VNF properties: descriptor_id: 316aa140-c99a-4a08-b8f5-8e2cb73c83e6 descriptor_version: '1.0' provider: MyCompany product_name: SunshineDB software_version: '1.0' vnfm_info: - MyCompany product_info_name: SunshineDB product_info_description: Relational database, non-scalable requirements: - virtual_link: [ vnf, virtual_link ] capabilities: deployment_flavour: [ vnf, deployment_flavour ]

node_templates: vnf: type: tosca.nodes.nfv.VNF

Editor's note: Whether the above grammar complies with TOSCA YAML specification needs to be verified.


The vnf node template in the above template fragment is still abstract and is subject to further substitution; the lower-level templates in the subsequent sections provide these substitutions. The lower-level template is assumed to be selected according to section 14.3 “Abstract node template matching” of the TOSCA Simple Profile in YAML v1.2 [4] with the additional constraints:

1. Search range: VNF package. When identifying the matching template, the procedure only investigates the templates in the VNF package (ignoring all other templates in the “pre-defined node template catalog”). See Note 1.

2. Match count: exacly one. More than one matching template results in an error. No matching template results in an error, too, as no VNF can be instantiated in this case.

These constraints are important since the property constraint (the basis of matching) is anticipated to be the flavour_id property of the deployment_flavour capability alone, as illustrated by the below NSD fragment:

example.nsd.tosca.yaml


topology_template: node_templates: db: type: tosca.nodes.nfv.VNF properties: provider: MyCompany product_name: SunshineDB software_version: '1.0' descriptor_version: '1.0' capabilities: deployment_flavour: properties: flavour_id: scalable requirements: - ..

..

In the above example, the db node template is abstract, and it puts five property constraints against the replacement template to be found: four constraints (provider, product_name, software_version, descriptor_version) against the VNF node properties and one constraint (flavour_id) against the deployment_flavour capability properties. The first four constraints are satisfied directly by the top-level template (sunshine.vnfd.tosca.yaml), but the last constraint is only satisfied indirectly, i.e. this constraint is propagated (via the capability mapping) to the abstract vnf node template in the top-level template; so the next step (after locating the top-level template based on the first four constraints) is to locate the lower-level template that matches the constraint on the abstract vnf node (i.e. the last constraint). The search range needs to be the VNF package (not the whole “pre-defined node template catalog” defined in the TOSCA Simple Profile in YAML v1.2 specification [4]), otherwise lower-level templates with the same flavour_id from different VNF packages could collide.

Note 1: The range constraint (1) is not absolutely necessary. In case it is not mandated, there needs to be an additional property constraint placed on the lower-level template, e.g. the value of the descriptor_id property (i.e. the VNFD ID which must be globally unique), and accordingly, the lower-level template needs to contain (repeat) the value of the descriptor_id property.

SunshineDB: VNFD-top level (target node filter matching)

sunshine.vnfd.tosca.yaml


description: Relational database, non-scalable


topology_template: inputs: flavour_id: type: string substitution_mappings: node_type: tosca.nodes.nfv.VNF properties: descriptor_id: 316aa140-c99a-4a08-b8f5-8e2cb73c83e6 descriptor_version: '1.0' provider: MyCompany product_name: SunshineDB software_version: '1.0' vnfm_info: - MyCompany product_info_name: SunshineDB product_info_description: Relational database, non-scalable requirements: - virtual_link: [ vnf, virtual_link ] capabilities: deployment_flavour: [ vnf, deployment_flavour ]

node_templates: vnf: type: tosca.nodes.nfv.VNF node_filter: capabilities: - deployment_flavour: properties: flavour_id: { equal: { get_input: flavour_id } }

The vnf node template in the above template fragment is still abstract and is subject to further substitution; the lower-level templates in the subsequent sections provide these substitutions. The lower-level template is assumed to be selected according to section 14.4 “Target node filter matching” of the TOSCA Simple Profile in YAML v1.2 [4] with the additional constraints listed in the previous section, with the same reasoning applied.

The vnf node template in the above template fragment is still abstract and is subject to further substitution; the lower-level templates in the subsequent sections provide these substitutions. The actual lower-level template is expected to be selected based on a value constraint on the flavour_id property of the deployment_flavour capability ("bound" value); other parts of the vnf node template remain "unbound" (the virtual_link requirements).

SunshineDB (simple): Lower level

sunshinesimple.vnfd.tosca.yaml

This example illustrates one VDU.Compute nodes (dbBackend) with two connection points and two virtual links. The flavour_id is "Simple".


VNF

Figure A.2: SunshineDB (simple): Lower level


description: Relational database, simple

topology_template: substitution_mappings: node_type: tosca.nodes.nfv.VNF properties: descriptor_id: 316aa140-c99a-4a08-b8f5-8e2cb73c83e7 descriptor_version: '1.0' provider: MyCompany product_name: SunshineDB software_version: '1.0' vnfm_info: - MyCompany product_info_name: SunshineDB product_info_description: Relational database, non-scalable requirements: - virtual_link: [ dbBackendIpv4, external_virtual_link ] # IPv4 for SQL capabilities: deployment_flavour: properties: flavour_id: simple description: .. instantiation_levels: minimal: description: .. vdu_levels: dbBackend: number_of_instances: 1 default_instantiation_level_id: minimal vdu_profile: dbBackend: min_number_of_instances: 1 max_number_of_instances: 1 interfaces: Basic: instantiate: terminate:

node_templates: dbBackend: type: tosca.nodes.nfv.VDU.Compute properties: name: .. description: .. boot_order: .. nfvi_constraints: .. configurable_properties: additional_vnfc_configurable_properties: {} capabilities: virtual_compute:


properties: virtual_memory: virtual_mem_size: 8096 MB virtual_cpu: cpu_architecture: x86 num_virtual_cpu: 2 virtual_cpu_clock: 1800 MHz requirements: - virtual_storage: mariaDbStorage

mariaDbStorage: type: tosca.nodes.nfv.VDU.VirtualStorage properties: type_of_storage: .. size_of_storage: .. rdma_enabled: .. artifacts: sw_image: name: Software of Maria Db version: 1.0 checksum: 9af30fce37a4c5c831e095745744d6d2 container_format: qcow2 disk_format: bare min_disk: 2 GB min_ram: 8096 MB size: 2 GB sw_image: maria.db.image.v1.0.qcow2 operating_system: Linux supported_virtualisation_environments: - KVM

dbBackendCp: type: tosca.nodes.nfv.Cpd properties: layer_protocol: ipv4 role: leaf description: External connection point to access the DB on IPv4 requirements: - virtual_binding: dbBackend

dbBackendInternalCp: type: tosca.nodes.nfv.Cpd properties: layer_protocol: ipv4 role: leaf description: Internal connection point on an VL requirements: - virtual_binding: dbBackend - virtual_link: internalVl

internalVl: type: tosca.nodes.nfv.VL properties: connectivity_type: layer_protocol: ipv4 flow_pattern: mesh test_access: [] description: .. vl_flavours: {}

dbBackendIpv4: type: tosca.nodes.nfv.ECP properties: layer_protocol: ipv4 requirements: - internal_connection_point: dbBackendCp

The properties section of the substitution_mappings may or may not be overridden in the substitution_mappings one level higher (it is overridden in example top-level template shown in the previous clause).


SunshineDB (complex): Lower level

This example illustrates two VDU.Compute nodes (dbBackend, and serviceNode) with two connection points and two virtual links. The flavour_id is "complex".

Figure A.3: SunshineDB (complex): lower level

NOTE: The single external VL above illustrates that both serviceNodeIp4 and dbBackendIp4 are connected to the same external VL. Alternatively, external connection points can be connected to separate external VLs.

sunshinedbcomplex.vnfd.tosca.yaml


description: Relational database, complex

topology_template: substitution_mappings: node_type: tosca.nodes.nfv.VNF properties: descriptor_id: 316aa140-c99a-4a08-b8f5-8e2cb73c83e8 descriptor_version: '1.0' provider: MyCompany product_name: SunshineDB software_version: '1.0' vnfm_info: - MyCompany product_info_name: SunshineDB product_info_description: Relational database, non-scalable requirements: - virtual_link: [ dbBackendIpv4, external_virtual_link ] # IPv4 for SQL - virtual_link: [ serviceNodeIpv4, external_virtual_link ] # IPv4 for SSH capabilities: deployment_flavour: properties: flavour_id: complex description: .. instantiation_levels: small: description: .. vdu_levels: dbBackend: number_of_instances: 3 serviceNode: number_of_instances: 1 big: description: .. vdu_levels:


dbBackend: number_of_instances: 6 serviceNode: number_of_instances: 6 default_instantiation_level_id: small vdu_profile: dbBackend: min_number_of_instances: 3 max_number_of_instances: 6 serviceNode: min_number_of_instances: 1 max_number_of_instances: 6 interfaces: Basic: instantiate: terminate: Scalable: scale:

node_templates: dbBackend: type: tosca.nodes.nfv.VDU.Compute properties: name: .. description: .. boot_order: .. nfvi_constraints: .. configurable_properties: additional_vnfc_configurable_properties: {} capabilities: virtual_compute: properties: virtual_memory: virtual_mem_size: 8096 MB virtual_cpu: cpu_architecture: x86 num_virtual_cpu: 2 virtual_cpu_clock: 1800 MHz requirements: - virtual_storage: mariaDbStorage

serviceNode: type: tosca.nodes.nfv.VDU.Compute properties: name: .. description: .. boot_order: .. nfvi_constraints: .. configurable_properties: additional_vnfc_configurable_properties: {} capabilities: virtual_compute: properties: virtual_memory: virtual_mem_size: 8096 MB virtual_cpu: cpu_architecture: x86 num_virtual_cpu: 2 virtual_cpu_clock: 1800 MHz requirements: - virtual_storage: mariaDbStorage

mariaDbStorage: type: tosca.nodes.nfv.VDU.VirtualStorage properties: type_of_storage: .. size_of_storage: .. rdma_enabled: .. artifacts: sw_image: name: Software of Maria Db version: 1.0 checksum: 9af30fce37a4c5c831e095745744d6d2


container_format: qcow2 disk_format: bare min_disk: 2 GB min_ram: 8096 MB size: 2 GB sw_image: maria.db.image.v1.0.qcow2 operating_system: Linux supported_virtualisation_environments: - KVM

dbBackendCp: type: tosca.nodes.nfv.Cpd properties: layer_protocol: ipv4 role: leaf description: External connection point to access the DB on IPv4 requirements: - virtual_binding: dbBackend

dbBackendInternalCp: type: tosca.nodes.nfv.Cpd properties: layer_protocol: ipv4 role: leaf description: Internal connection point on an VL requirements: - virtual_binding: dbBackend - virtual_link: internalVl

serviceNodeCp: type: tosca.nodes.nfv.Cpd properties: layer_protocol: ipv4 role: leaf description: External connection point to access the DB on IPv4 requirements: - virtual_binding: serviceNode

serviceNodeInternalCp: type: tosca.nodes.nfv.Cpd properties: layer_protocol: ipv4 role: leaf description: Internal connection point on VL requirements: - virtual_binding: serviceNode - virtual_link: internalVl

internalVl: type: tosca.nodes.nfv.VL properties: connectivity_type: layer_protocol: ipv4 flow_pattern: mesh test_access: [] description: .. vl_flavours: {}

dbBackendIpv4: type: tosca.nodes.nfv.ECP properties: layer_protocol: ipv4 requirements: - internal_connection_point: dbBackendCp

serviceNodeIpv4: type: tosca.nodes.nfv.ECP properties: layer_protocol: ipv4 requirements: - internal_connection_point: serviceNodeCp


Capabilities types6.5.4 tosca.capabilities.nfv.VnfDeploymentFlavourThe VnfDeploymentFlavour describes a specific deployment version of a VNF.

Table 6.5.4-1: Type name, shorthand, and URI

Shorthand Name VnfDeploymentFlavour

Type Qualified Name

tosca: VnfDeploymentFlavour

Type URI tosca.capabilities.nfv.VnfDeploymentFlavour

6.5.4.1 Properties Table 6.5.4.1-1: Properties

Name Required

Type Constraints Description

flavour_id yes string Identifier of this DF within the VNFD.

description yes string Human readable description of the DF.

vdu_profile yes map Describes additional instantiation data for the VDUs used in this flavour.

vl_profile no map Defines the internal VLD along with additional data which is used in this DF. See notes 1 and 2.

instantiation_levels

yes map Describes the various levels of resources that can be used to instantiate the VNF using this flavour. Examples: Small, Medium, Large.If there is only one "instantiationLevel" entry, it shall be treated as the default instantiation level for this DF.

default_instantiation_level_id

yes string This property references the "instantiationLevel" entry which defines the default instantiation level for this DF. It shall be present if there are multiple "instantiationLevel" entries.

supported_operations

no string Indicates which operations are available for this DF via the VNF LCM interface. Instantiate VNF, Query VNF and Terminate VNF are supported in all DF and therefore need not be included in this list.

lcm_operations_configuration

no Configuration parameters for the VNF Lifecycle Management operations.


Name Required


affinity_or_anti_affinity_groups

no Specifies affinity or anti-affinity relationship applicable between the virtualisation containers (e.g. virtual machines) to be created using different VDUs or internal VLs to be created using different VnfVirtualLinkDesc(s) in the same affinity or anti-affinity group.

monitoring_parameters

no Defines the virtualised resources monitoring parameters on VNF level.

scaling_aspects

no map The scaling aspects supported by this DF of the VNF. scalingAspect shall be present if the VNF supports scaling.

6.5.4.2 Definition

Table 6.5.4.2-1: Definition

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 required: true vl_profile: type: map # key: VL id entry_schema: type: map # key: VlFlavour id entry_schema: type: tosca.datatypes.nfv.VlProfile required: false instantiation_levels: type: map entry_schema: type: tosca.datatypes.nfv.InstantiationLevel required: true default_instantiation_level_id: type: string # Identifier required: true #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 entry_schema: type: tosca.datatypes.nfv.ScalingAspect required: false

6.5.4.3 Additional Requirement

When using a target node filter for selecting (the “realizing VNF” with) the desired deployment flavour, the NFVO and VNFM shall use the matching procedures defined in sections section 14.3 “Abstract node template matching” and 14.4 “Target node filter matching” of the TOSCA Simple Profile in YAML v1.2 [4], with the following additional constraints:

1. Search range: VNF package. When identifying the matching template, the procedure only investigates the templates in the VNF package (ignoring all other templates in the “pre-defined node template catalog”). Further explanation can be found in Annex A (Examples). See Note 1

2. Match count: exacly one. More than one matching template results in an error. No matching template results in an error, too, as no VNF can be instantiated in this case.

The node_filter keyword and supporting grammar shall be used with the Node Template, as defined in TOSCA Simple Profile in YAML [4], section 3.8.2 “Requirement assignment”.

Note 1: The range constraint (1) is not absolutely necessary. In case it is not mandated, there needs to be an additional property constraint placed on the lower-level template, e.g. the value of the descriptor_id property (i.e. the VNFD ID which must be globally unique), and accordingly, the lower-level template needs to contain (repeat) the value of the descriptor_id property.

Node types

6.10 Node Types6.10.1 tosca.nodes.nfv.VNF

6.10.1.1 Description

The NFV Virtualized Network Function (VNF) node type describes a VNF in terms of deployment and operational behaviour requirements, which it contains connectivity, interfaces and virtualised resource requirements, as defined by ETSI GS NFV-IFA 011 [Error: Reference source not found].

Table 6.1.1.1-1

Shorthand Name VNFType Qualified Name tosca:VNFType URI tosca.nodes.nfv.VNFderived_from tosca.nodes.Root


6.10.1.2 Properties

Table 6.10.1.2-1

Name Required


descriptor_id yes string GUID Identifier of this VNFD information element. This attribute shall be globally unique. The format will be defined in the data model specification phase.

The VNFD Identifier shall be used as the unique identifier of the VNF Package that contains this VNFD. Any modification of the content of the VNFD or the VNF Package shall result in a new VNFD Identifier.

descriptor_version yes string Identifies the version of the VNFD.provider yes string Provider of the VNF and of the VNFD.product_name yes string Name to identify the VNF Product.

Invariant for the VNF Product lifetime.software_version yes string Software version of the VNF. This is

changed when there is any change to the software that is included in the VNF Package.

product_info_name yes string Human readable name for the VNF Product. Can change during the VNF Product lifetime.

product_info_description no string Human readable description of the VNF Product. Can change during the VNF Product lifetime.

vnfm_info yes list Identifies VNFM(s) compatible with the VNF described in this version of the VNFD.

localization_languages no list Information about localization languages of the VNF (includes e.g. strings in the VNFD).

This allows to provide one or more localization languages to support selecting a specific localization language at VNF instantiation time.

default_localization_language

no string Default localization language that is instantiated if no information about selected localization language is available.Shall be present if "localizationLanguage" is present and shall be absent otherwise.

Editor's note: The names used in the above table differ from the attribute names in ETSI GS NFV-IFA 011

descriptor_id = vnfd_id

descriptor_version = vnfd_version

provider = vnf_provider

product_name = vnf_product_name

software_version = vnf_software_version


product_infor_name = vnf_product_info_name

Whether to align with ETSI GS NFV-IFA 011 requires further study.

6.10.1.3 Attributes

TBD

6.10.1.4 Requirements

Table 6.10.1.4-1

Name Required Type Constraints Descriptionvirtual_link yes tosca.nodes.nfv.VL Describes the requirements for linking to

virtual link

6.10.1.5 Capabilities

Table 6.10.1.5-1

Name Type Constraints Descriptionvnf tosca.capabilities.nfv.VNF Describes the

capabilities of VNFdeployment_flavour tosca.capabilities.nfv.VnfDeploymentFlavou

rDescribes specific deployment flavour of a VNF with specific requirement for capacity and performance.

monitoring_parameter(see note)

tosca.capabilities.nfv.Metric none Monitoring parameter, which can be tracked for a VNF

NOTE: Modeled as ad hoc capabilities in VNF node template.

6.10.1.6 Definition

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


type: string required: true localization_languages: type: list entry_schema: type: string required: false default_localization_language: type: string required: false capabilities: vnf: type: tosca.capabilities.nfv.VNF deployment_flavour: type: tosca.capabilities.nfv.VnfDeploymentFlavour #monitoring_parameter: # modelled 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 ]

Editor note: interfaces/operation are needed to be defined in the vnf node type.# 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

6.10.1.7 Artifact

None.


TOSCA Simple Profile for Network Functions Virtualization ... · Web view6.10.1.1 Description The...

Documents

Transcript of TOSCA Simple Profile for Network Functions Virtualization ... · Web view6.10.1.1 Description The...