Deployment Flavour as VNF Capability: Alt1_r2 April 11, 2017 Thinh Nguyenphu, Nokia thinh.nguyenphu@nokia.com 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

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.

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:

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  

Using enhance substitution_mappings grammar (properties, capabilities)

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

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

VNF Packaging: Discussion & issues

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

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

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