DF design as a node type (output by Chris and shitao)

Multiple DF: Two layers of TOSCA service templates Top level service template only contains the VNF node type definition Each lower level service template contains one DF Each lower level service template uses substitution_mapping to map to the top level VNF node type At NSD design time, a specific VNF flavor ID will be set to the VNF node template and match to a specific DF service template tosca-simple-profile-yaml v1.2 is needed

Mulitple DF (using substitution_mapping grammar in tosca-simple-profile-yaml-v1.2) VNFD lower level tosca_definitions_version: tosca_simple_yaml_1_2 imports: VNFD.yaml substitution mapping node_type: tosca.nodes.nfv.example_VNF properties: flavour_id: flavour1 node_templates: VDU_1: VDU_2: Top level DF_1 service template (df1.yaml) VNFD service template (VNFD.yaml) VDU_1 VDU_2 tosca_definitions_version: tosca_simple_yaml_1_2 metadata: Node types: tosca.nodes.nfv.example_VNF: derived_from: tosca.nodes.nfv.vnf properties: VNFD_ID: type: string flavour_ID: constraints: - valid_values: [ flavour1, flavour2 ] VL_1 DF_2 service template (df2.yaml) tosca_definitions_version: tosca_simple_yaml_1_2 imports: VNFD.yaml substitution mapping node_type: tosca.nodes.nfv.example_VNF properties: flavour_id: flavour2 node_templates: VDU_1: VDU_2: VDU_3: VDU_1 VDU_2 VDU_3 VL_1 1,Imports at top level mentioning the lower level STs may be needed 2, which VNFD related parameters should be set as properties, which should be set as metadata in VNFD service template. 3, tosca.nfv.vnf.vnfd is not the same as nowadays in SOL001 4, how to describe LCM operates 5, details of every definitions 6, top level ST, is the VNF node type is a abstract or concrete node type NSD tosca_definitions_version: tosca_simple_yaml_1_1 topology_template: inputs: deployment_flavor: type: string node_template: VNF1: type: tosca.nodes.nfv.example_VNF VNFD_ID: flavor_ID: { get_input: deployment_flavour} # either flavour1 or flavour2 At NSD design time, a specific VNF flavor ID will be set to the VNF node template and match to a specific DF service template

Single DF: VNFD contains only one topology option. Only one layer of TOSCA service template is needed. Normal substitution mapping mechanism is enough (tosca-simple-profile-yaml v1.2, V 1.1 can both be used)

Single DF (using substitution_mapping grammar in tosca-simple-profile-yaml-v1.1) VNFD tosca_definitions_version: tosca_simple_yaml_1_1 Node types: tosca.nodes.nfv.example_VNF: derived_from: tosca.nodes.nfv.vnf properties: flavor_ID: requirements: ExtVirtualLinkable topology_template: substitution_mapping: node_type: tosca.nodes.nfv.example_VNF capabilities: ExtVirtualLinkable: [VDU_1, ExtVirtualLinkable] node_template: VDU_1: VDU_2: VL_1: NSD tosca_definitions_version: tosca_simple_yaml_1_1 topology_template: inputs: deployment_flavor: type: string constraints: - valid_values: [ flavour1 ] node_template: VNF1: type: tosca.nodes.nfv.example_VNF VNFD_ID: flavor_ID: { get_input: deployment_flavour}

Deployment flavour service template design Capability (derived from scalable capability) of VDU node Capability of VL node DF_1 service template Policy? Did not support in tosca nowadays VDU_1 VDU_2 workflow? VL_1 Group capability Policy?

More detail for single DF proposal (based on tosca-simple-profile-yaml v1.1)

VNFD example for single DF This usage follows the same way as in ONAP SDC, discussion is still required. tosca_definitions_version: tosca_simple_yaml_1_1 metadata: vnfd_id: <file_uri> #Required   vnf_provider: <provider_string> #Required   vnf_product_name: <name_string> #Required   vnf_software_version: <version> #Required   vnfd_version: <version> #Required Node types: tosca.nodes.nfv.example_VNF: derived_from: tosca.nodes.nfv.vnfd properties: flavor_ID: # requirements: ExtVirtualLinkable topology_template: substitution_mapping: node_type: tosca.nodes.nfv.example_VNF capabilities: ExtVirtualLinkable: [VDU_1, ExtVirtualLinkable] node_template: VDU_1: type: nodes.nfv.VDU.c Vduproflie: VDU_2: scalable: min_instances: 2 max_instances: 8 VL_1: type: nodes.nfv.VirtualLinkDesc Group: element_group_1: type: tosca.groups.affinity members: [VDU_1, VDU_2] Policies: localAffinityOrAntiAffinityRule_1: type: tosca.policy.placement.local targets: VDU_1 type: # affinity or anti-affinity scope: scalingAspect_1: type: : tosca.policy.scale targets: element_group_1 tosca.nodes.nfv.vnfd: derived_from: tosca.nodes.Root properties: flavour_ID: type: string localizationLanguage type:string capabilities: requirements: - virtual_link: capability: tosca.capabilities.nfv.ExtVirtualLinkable relationship: tosca.relationships.nfv.ExtVirtualLinksTo node: tosca.nodes.nfv.VnfExtVL occurrences: [ 0, UNBOUNDED ]  

Vduprofile tosca.capabilities.Scalable Using scalable capability, or creating a new capability that derived from scalable capability Policy defined in the VNFD service template Group defined in the VNFD service template

VirtualLinkProfile The flavor ID value can be set directly within the VL node template

Examples: preferred Example_2, capabilities: vlprofile: VL1: flavor: flavor_1 node_template: VDU1: type: tosca.nodes.nfv.VnfVirtualLinkDesc properties: vl_flavors: [flavor_1, flavor_2] Example_1, Inputs: VL_flavor: constraints: {flavor_1, flavor_2} node_template: VDU1: VL1: type: tosca.nodes.nfv.VnfVirtualLinkDesc properties: vl_flavor: {get_input: VL_flavor} Similar with IFA model, but from TOSCA perspective, it is not a good design and may not implementable. preferred