ONAP ETSI-Alignment Modeling Hierarchy

For OSS Service-level modeling, continue to use org.openecomp.resource.abstract.nodes.service
For NS modeling, use SOL001 tosca.nodes.nfv.NS as SDC AID DM NS node type
The OSS-Service model references/includes associated NSs (1:M)
In ONAP, tosca.nodes.nfv.NS references, a new VNF node type, org.openecomp.resource.abstract.nodes.ETSI.VNF (1:M) and a new PNF node type, org.openecomp.resource.abstract.nodes.ETSI.PNF (1:M) are used
In ONAP, tosca.nodes.nfv.NS includes SOL001 tosca.nodes.nfv.NsVirtualLink (1:M)

VNFD Mapping to SDC AID DM

SOL001 VNF mapping to/from VNF SDC AID DM

ONAP previous analysis
- There is no 1:1 mapping between the SOL001 tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.nodes.VF.
  - SDC VF node types has very few properties.
  - a lot of common properties are added to each node type created by SDC
  - new common properties are mainly about networking and ONAP specific properties
- There is no clear mapping logic between the current node types
  - SDC creates new data type as ONAP deployment configuration.
- In ETSI, the descriptor_id is used to reference to the VNF, but in ONAP, the UUID is used to reference to the VNF.
Solutions
- map between SOL001 VNF and SDC AID DM VNF selectively.
  - data in the SOL001 that would be considered Cloud Provider automation data could be remained unmapped
  - Examples of Service Provider data that would need to be mapped in order to drive ONAP automation would include:
    - HPA requirements needed by OOF to determine cloud feasibility
    - Input parameters passed to the Cloud provider
  - ONAP wants to distinguish between the mode/data required to drive ONAP functionality from a Service Provider perspective from any ancillary mode/data required to drive Cloud Provider automation.
- UUID and invariantUUID must not be modeled as metadata type, per TOSCA YAML because the data provided within metadata, maybe ignored by TOSCA orchestrator and should not affect runtime behavior.
- Identify Cloud Provider automation-related data and remove it from the mapping
- Identify Service Provider data and map it to SDC AID DM
- ONAP SO NFVO uses SOL001 VNF; other ONAP runtime components could use the new mapped org.openecomp.resource.abstract.nodes.ETSI.VNF

Current VNF Modeling in ETSI and SDC

SOL001 VNF (tosca.nodes.nfv.VNF) from SOL001 v3.3.1+4.1.1			SDC AID DM VNF (org.openecomp.resource.abstract.nodes.VF) from SDC Generic_VF.yml			org.openecomp.resource.vf.vcpeInfrastructureGwDemoApp (derived from org.openecomp.resource.abstract.nodes.VF)
name	required	type	name	required	type	name	required	type
descriptor_id	yes	string	nf_function		string	nf_function		string
descriptor_version	yes	string	nf_role		string	nf_role		string
provider	yes	string	nf_type		string	nf_type		string
product_name	yes	string	nf_naming_code		string	nf_name_code		string
software_version	yes	string	nf_naming		org.openecomp.datatyhpes.Naming	nf_naming		org.openecomp.datatyhpes.Naming
product_info_name	no	string	availability_zone_max_count		integer	availablity_zone_max_count		integer
vnfm_info	yes	list of string	min_instances		integer	min_instances		integer
localization_languages	no	list of string	max_instances		integer	max_instances		integer
default_localization_language	no	string	multi_stage_design		boolean	multi_stage_design		boolean
configurable_properties	no	tosca.datatypes.nfv.VnfconfigurableProperties	sdnc_model_name		string	vf_module_id	no
modifiable_attributes	no	tosca.datatypes.nfv.VnfInfoModifiableAttributes	sdnc_artifact_name		string	vcpe_image_name	no
lcm_operations_configuraion	no	tosca.datatypes.nfv.VnfLcmOperationsConfiguration	skip_post_instantiation_configuration		boolean (default true) constraints : true, false	public_net_id	no
monitoring_parameters	no	list of tosca.dataypes.nfv.VnfMonitoringParameter	controller_actor		string (default: SO-REF-DATA) constraints: SO-REF-DATA, CDS, SDNC, APPC	vgw_name_0	no
flavour_id	yes	string				nexus_artifact_repo	no
flavour_description	yes	string				mux_ip_addr	no
vnf_profile	no	tosca.datatyhpes.nfv.VnfProfile				vnf_id	no
mciop_profile	no	list of tosca.datatypes.nfv.MciopProfile				cpe_public_net_cidr	no
						vg_vgmux_tunnel_vni	no
						nf_naming	no
						multi_stage_design	no
<tosca.datatypes.nfv.VnfProfile>						nf_naming_code	no
instantiation_level	no	string				vgw_private_ip_0	no
min_number_of_instances	yes	integer				vgw_private_ip_1	no
max_number_of_instances	yes	integer				vgw_private_ip_2	no
						pub_key	no
						install_script_version	no
						onap_private_net_cidr	no
						cpe_public_net_id	no
						mux_gw_private_net_id	no
						dcae_collector_ip	no
						dcae_collector_port	no
						onap_private_net_id	no
						cloud_env	no

Solutions:

There are two options. For now, we chose the option A. The option B is under discussion.

Option A (chosen):

Define a new data type based on the org.openecomp.resource.abstract.nodes.VF with ETSI SOL001 VNF data type attributes.

Make the org.openecomp.resource.abstract.nodes.ETSI.VNF a superset of both tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.node.VF
During VNF onboarding, SDC copies SOL001 VNF attribute contents to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VNF
- In Honolulu, SO NFVO, VFC and SVNFM get those SOL001 VNF attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Honolulu.
SOL001 VNF attributes in SDC AID DM VNF will be visible to SDC UI, so SDC UI can change the attributes.
- But the onboarded vendor ETSI package will note be changed by the SDC UI users in Honolulu.
- Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Honolulu;
- For the Honolulu release, it is under consideration
  - to sync up between those modified SOL001 VNF attributes and the vendor ETSI Package attributes
  - to reflect those modified SOL001 VNF attributes in the orchestration
ONAP specific attributes that are inherited from the org.openecomp.resource.abstract.nodes.VF will be filled up by SDC (design time)
- Those attribute contents will not be mapped back into the SOL001 VNF (reverse mapping). For that case, only the SOL001 VNF corresponding attributes will be copied

SOL001 VNF (tosca.nodes.nfv.VNF)			Mapping	New SDC AID DM VNF (org.openecomp.resource.abstract.nodes.ETSI.VNF) derived from org.openecomp.resource.abstract.nodes.VF
name	required	type		name	required	type
<SOL001 tosca.nodes.nfv.VNF attributes >				<SOL001 tosca.nodes.nfv.VNF attributes >
descriptor_id	yes	string	<-->	descriptor_id	yes	string
descriptor_version	yes	string	<-->	descriptor_version	yes	string
provider	yes	string	<-->	provider	yes	string
product_name	yes	string	<-->	product_name	yes	string
software_version	yes	string	<-->	software_version	yes	string
product_info_name	no	string	<-->	product_info_name	no	string
vnfm_info	yes	list of string	<-->	vnfm_info	yes	list of string
localization_languages	no	list of string	<-->	localization_languages	no	list of string
default_localization_language	no	string	<-->	default_localization_language	no	string
configurable_properties	no	tosca.datatypes.nfv.VnfconfigurableProperties	<-->	configurable_properties	no	tosca.datatypes.nfv.VnfconfigurableProperties
modifiable_attributes	no	tosca.datatypes.nfv.VnfInfoModifiableAttributes	<-->	modifiable_attributes	no	tosca.datatypes.nfv.VnfInfoModifiableAttributes
lcm_operations_configuration	no	tosca.datatypes.nfv.VnfLcmOperationsConfiguration	<-->	lcm_operations_configuration	no	tosca.datatypes.nfv.VnfLcmOperationsConfiguration
monitoring_parameters	no	list of tosca.datatypes.nfv.VnfMonitoringParameter	<-->	monitoring_parameters	no	list of tosca.datatypes.nfv.VnfMonitoringParameter
flavour_id	yes	string	<-->	flavour_id	yes	string
flavour_description	yes	string	<-->	flavour_description	yes	string
vnf_profile	no	tosca.datatypes.nfv.VnfProfile	<-->	vnf_profile	no	tosca.datatypes.nfv.VnfProfile
mciop_profile	no	list of tosca.datatypes.nfv.MciopProfile	<-->	mciop_profile	no	list of tosca.datatypes.nfv.MciopProfile
				<SDC AID DM VF attributes that are inherited from org.openecomp.resource.abstract.nodes.VF>
<the followings are being considered>				nf_function	no	string
requirements	Yes			nf_role	no	string
interfaces	yes	tosca.interfaces.nfv.VnfLcm		nf_type	no	string
				nf_naming_code	no	string
				nf_naming	no	org.openecomp.datatypes.Naming
				availability_zone_max_count	no	integer
				min_instances	no	integer
				max_instances	no	integer
				multi_stage_design	no	boolean
				sdnc_model_name	no	string
				sdnc_artifact_name	no	string
				skip_post_instantiation_configuration	no	boolean (default true) constraints: true, false
				controller_actor	no	string (default: SO-REF-DATA) constraints: SO-REF-DATA, CDS, SDNC, APPC

SOL001 VDU mapping to/from VNF SDC AID DM VFC

Current SOL001 VDU vs. SDC AID DM VFC

no 1:1 mapping
note: the SDC AID DM VFC represents design-time VFC (like VDU), not VFC instances in runtime

SOL001 VDU			SDC AID DM VFC (org.openecomp.resource.abstract.nodes.VFC)
Name	Required	Type	Name	Required	Type
name	yes	string	nfc_function		string
description	yes	string	high_availability	no	string
boot_order	no	boolean	vm_image_name		string
nfvi_constraints	no	map of string	vm_flavor_name	yes	string
monitoring_parameters	no	list of tosca.datatypes.nfv.VnfcMonitoringParameter	nfc_naming_code	no	string
configurable_properties	no	map of tosca.datatypes.nfv.VnfcConfigurableProperties	vm_type_tag	no	string
boot_data	no	tosca.datatypes.nfv.BootData	nfc_naming		org.openecomp.datatypes.Naming ONAP_generated_naming: yes: boolean naming_policy: no: string instance_name: no: string
vdu_profile	yes	tosca.datatypes.nfv.VduProfile	min_instances	no	integer
sw_image_data	no	tosca.datatypes.nfv.SwImageData

Solutions for VDU and VFC mapping

Make the org.openecomp.resource.abstract.nodes.ETSI.VFC a superset of both tosca.nodes.nfv.Vdu and org.openecomp.resource.abstract.nodes.VFC
Note: the org.openecomp.resource.abstract.nodes.VFC represents design-time VFC, not VFC instances
During VNF onboarding, SDC copies SOL001 VDU attribute contents to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VFC
- In Honolulu, SO NFVO, VFC and SVNFM get those SOL001 VDU attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Honolulu.
SOL001 VDU attributes in SDC AID DM VNF will be visible to SDC UI, so SDC UI can change the attributes.
- But the onboarded vendor ETSI package will note be changed by the SDC UI users in Honolulu.
- Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Honolulu;
- For the Honolulu release, it is under consideration
  - to sync up between those modified SOL001 VDU attributes and the vendor ETSI Package attributes
  - to reflect those modified SOL001 VDU / VFC attributes in the orchestration

New SDC AID DM VFC type (org.openecomp.resource.abstract.nodes.ETSI.VFC)

SOL001 VDU			Mapping	org.openecomp.resource.abstract.nodes.ETSI.VFC (derived from org.openecomp.resource.abstract.nodes.VFC)
Name	Required	Type	<-->	Name	Required	Type
name	yes	string	<-->	name	yes	string
description	yes	string	<-->	description	yes	string
boot_order	no	boolean	<-->	boot_order	no	boolean
nfvi_constraints	no	map of string	<-->	nfvi_constraints	no	map of string
monitoring_parameters	no	list of tosca.datatypes.nfv.VnfcMonitoringParameter	<-->	monitoring_parameters	no	list of tosca.datatypes.nfv.VnfcMonitoringParameter
configurable_properties	no	map of tosca.datatypes.nfv.VnfcConfigurableProperties	<-->	configurable_properties	no	map of tosca.datatypes.nfv.VnfcConfigurableProperties
boot_data	no	tosca.datatypes.nfv.BootData	<-->	boot_data	no	tosca.datatypes.nfv.BootData
vdu_profile	yes	tosca.datatypes.nfv.VduProfile	<-->	vdu_profile	yes	tosca.datatypes.nfv.VduProfile
sw_image_data	no	tosca.datatypes.nfv.SwImageData	<-->	sw_image_data	no	tosca.datatypes.nfv.SwImageData
				<SDC AID DM VFC attributes that are inherited from the org.openecomp.resource.abstract.nodes.VFC>
				nfc_function	no	string
				high_availability	no	string
				vm_image_name	no	string
				vm_flavor_name	no	string
				nfc_naming_code	no	string
				vm_type_tag	no	string
				nfc_naming	no	org.openecomp.datatypes.Naming ONAP_generated_naming: yes: boolean naming_policy: no: string instance_name: no: string
				min_instances	no	integer

SOL001 3.3.1 VNFD Mapping from/to SDC AID DM VNFD

SOL001 3.3.1 VNFD Template

tosca_definitions_version: tosca_simple_yaml_1_3

description:

imports:

data_types:

node_types:

topology_template:

inputs:

node_templates:

VNF

substitution_mappings:

capabilities:

requirements:

SDC VFD Template

tosca_definitions_version: tosca_simple_profile_for_ecomp_1_0

descriptions:

imports:

data_types:

node_types:

topology_template:

inputs:

node_templates:

vfc:

type: org.openecomp.resource.vfc

extCP:

type: org.openecomp.resources.cp

groups:

VFModule_Base:

type: org.openecomp.groups.VfModule

VFModule_Expansion:

type: org.openecomp.groups.VfModule

workflows:

policies:

anti_collated_az_policy:

substitution_mappings:

node_type: org.openecomp.resources.vf.<vf_name>

capabilities:

requirements:

SOL001 VNFD mapping to/from SDC AID DM VFD

SOL001 VNFD		SDC AID DM VFD
Name	Grammar	Name	Grammar
tosca_definitions_version	string (tosca_simple_yaml_1_3)	tosca_definitions_version	string (tosca_simple_yaml_1_3)
description	string	description	string
metadata	map of <string>	metadata	map of <string>
imports	Single-line grammar <URI_1> <URI_2> Multi-line grammar file: <file_URI> repository: <repository name> namespace_uri: <definition_namespace_uri> # deprecated namespace_prefix: <definition_namespace_prefix>	imports	Identifies the lower level models (VFC, CP, VL, heat)
data_types	<data_type_name>: derived_from: <existing_type_name> version: <version_number> metadata: <map of string> description: <datatype_description> constraints: - <type_constraints> properties: <property_definitions>	data_types	<data_type_name>: derived_from: <existing_type_name> version: <version_number> metadata: <map of string> description: <datatype_description> constraints: - <type_constraints> properties: <property_definitions>
node_types	<node_type_name>: derived_from: <parent_node_type_name> version: <version_number> metadata: <map of string> description: <node_type_description> attributes: <attribute_definitions> properties: <property_definitions> requirements: - <requirement_definitions> capabilities: <capability_definitions> interfaces: <interface_definitions> artifacts: <artifact_definitions>	node_types	<node_type_name>: derived_from: <parent_node_type_name> version: <version_number> metadata: <map of string> description: <node_type_description> attributes: <attribute_definitions> properties: <property_definitions> requirements: - <requirement_definitions> capabilities: <capability_definitions> interfaces: <interface_definitions> artifacts: <artifact_definitions>
topology_template	topology_template: description: <template_description> inputs: <input_parameter_list> outputs: <output_parameter_list> node_templates: <node_template_list> relationship_templates: <relationship_template_list> groups: <group_definition_list> policies: - <policy_definition_list> workflows: <workflow_list> # Optional declaration that exports the Topology Template # as an implementation of a Node Type. substitution_mappings: <substitution_mappings>	topology_template	similar, but the following are different node_templates contents groups workflows
description	string	description	string
inputs		inputs	<parameter name>: type: <parameter_type> description: <parameter_description> required: <parameter_required> default: <parameter_default_value> constraints: - <parameter_constraints>
node_templates	vnf: tosca.nodes.nfv.Vnf vdu: tosca.nodes.nfv.Vdu vl: tosca.nodes.nfv.VnfVirtualLink vduCp: tosca.nodes.nfv.VduCp vduCompute: tosca.nodes.nfv.Vdu.Compute	node_templates	vfc: type: org.openecomp.resources.vfc.<> vl: type: org.openecomp.resources.vl.<> cp: type: org.openecomp.resources.cp.<> allotted_resource: type: org.openecomp.resource.allottedResource.<>
		workflows	<workflow name>
policies scaling aspect	tosca.datatypes.nfv.ScalingAspect description properties name: description max_scale_level: step_deltas:	groups	list of VF Modules VFModule_Base: type: org.openecomp.groups.VfModule VFModule_Expansion: type: org.openecomp.groups.VfModule
		policies	optional list of policies
substitution_mappings		substitution_mappings
node_type		node_type
capabilities	<capability_type_name>: derived_from: <parent_capability_type_name> version: <version_number> description: <capability_description> properties: <property_definitions> attributes: <attribute_definitions> valid_source_types: [ <node type_names> ]	capabilities	<capability_type_name>: derived_from: <parent_capability_type_name> version: <version_number> description: <capability_description> properties: <property_definitions> attributes: <attribute_definitions> valid_source_types: [ <node type_names> ]
requirements		requirements
group	not defined	group	<group_type_name>: derived_from: <parent_group_type_name> version: <version_number> metadata: <map of string> description: <group_description> properties: <property_definitions> members: [ <list_of_valid_member_types> ] requirements: - <requirement_definitions> capabilities:
policy	only the Abstract.SecurityGroupRule policy type is defined not sure if we can map this into SDC AID DM	policy	<policy_type_name>: derived_from: <parent_policy_type_name> version: <version_number> metadata: <map of string> description: <policy_description> properties: <property_definitions> targets: [ <list_of_valid_target_types> ] triggers: <list_of_trigger_definitions>
relationship	tosca.relationships.nfv.VirtualBindsTo tosca.relationships.nfv.AttachesTo	relationship	<relationship_type_name>: derived_from: <parent_relationship_type_name> version: <version_number> metadata: <map of string> description: <relationship_description> properties: <property_definitions> attributes: <attribute_definitions> interfaces: <interface_definitions> valid_target_types: [ <capability_type_names> ]
		annotation_type	<annotation_type_name>: version: <version_number> description: <annotation_type_description> properties: <property_definitions>
		annotation	<annotation_name>: type: <annotation_type> properties: <property_assignments>

VF-Module Initial Input

The following is a summary of initial input from Gil Bullard (AT&T).

Mapping Scope Challenges and Suggestions
- ONAP wants to distinguish between the mode/data required to drive ONAP functionality from a Service Provider perspective from any ancillary mode/data required to drive Cloud Provider automation.
  - See the ONAP MultiVim Proposal on the separation of concerns.
- SDC AID was created before a separation of concerns was envisioned, thus there are data structures in the SDC AID that would be considered Cloud Provider automation data and that we would likely take out of the SDC AID.
  - Examples of Service Provider data that would need to be mapped in order to drive ONAP automation would include:
    - HPA requirements needed by OOF to determine cloud feasibility
    - Input parameters passed to the Cloud provider
  - There is probably some data in the SOL001 that would be considered Cloud Provider automation data. Any such data could remain unmapped
  - SOL001 content needed to drive ONAP automation (SO, OOF, SDNC, AAI, DCAE, etc.) would need to be mapped
- The VNFM should not be aware of the VF Module structure, though the current SO-SDNC interactions to get assignment are by VF Module, and the VF Module entity plays prominent in AAI. That means there needs to be two adaptation points as we have discussed:
  - An SDC function to extract VF Module information from the SOL001 VNFD prior to distribution to runtime
  - A VNFM Adapter function to flatten the VF Module structure prior to handoff to the VNFM
VF-Module Deduction from SOL001

- There is an assumption that SDC transforms the vendor provided VNF package into ONAP-compliant one; i.e., deducing VF Modules based on VNFD ScalingAspects and Delta.
- If SDC supports the transformation in Dublin time-frame, the transformed CSAR will be imported to SO, and SO VNF- and VF-Module-level workflows will manage VNF and VF Module topology towards SDNC with the following changes - Input from Gil Bullard (AT&T)
  - Today the VNF-level workflow has an embedded per-VF Module loop that a) retrieves the SDNC assignments for that VF Module, and then b) sends those VF Module-level assignments down to the VIM (e.g., OpenStack); the loop then moves to repeat "a" with the next VF Module.
  - The new VNF-level flow will have the following sequences:
    1. an embedded per-VF Module loop that only retrieves the SDNC assignments for each VF Module; because the VIM is hidden from SO's sight, beneath the VNFM Adapter/VNFM.
    2. After finishing the loop, the SO workflows will send a structure to the VNFM Adapter that includes the aggregate assignments at the VNF level.
    3. The VNFM Adapter aggregates all the VF-Module level assignments and transforms the assignment data into SOL003 API parameters before sending them to SVNFM
      1. The VNFM Adapter would need to be able to parse the VNF-level assignments structure received from SO to obtain the per-VDUconnection point assignments information and any per-VDU parameter information (e.g., hostnames)
      2. In doing so, the VNFM Adapter would need to know to ignore the VF Module groupings of these assignments
      3. Further know how to map the ONAP data structure and parameter names into the ETSI (e.g., VM=VDU, VNFC=VNFC, vNIC=vNIC, etc.). Note that the above assumes that in ONAP, as in ETSI, there will be a one-to-one correspondence between VM/VDU and VNFC.

- Assumptions for deducing VF-Module from SOL001 (Gil Bullard's input)

- - SOL001 concept of Aspect+ScalingDelta combination is one to one with the ONAP concept of VF Module.
  - SOL001 concept of VDU is one to one with the ONAP concept of A&AI vServer
  - SOL001 concept of a connection point associated with a VDU corresponds to the ONAP concept of the same name, as does the understanding of the meaning of “internal” versus “external” connection point.
  - ONAP-compliant SOL001 VNF Vendors will be obliged to name their HEAT files using a naming convention that encodes the SOL001 Aspect+ScalingDelta names
  - ONAP-compliant SOL001 VNF Vendors will be obliged to name their SOL001 Aspect+ScalingDelta parameters using a naming convention that readily maps to the corresponding HEAT properties.
  - In addition, if AT&T has already deployed such a vendor’s VNF into its network, the HEAT naming will remain invariant, and (at least) the (AT&T version of that) SOL001 be written to match it.
- What to do
  - ONAP will be extended to incorporate the constructs of Aspect and Scaling Level. This includes SDC’s, SOs, and A&AI’s modeling of these constructs and A&AI's ability to capture and SO’s ability to set/update the "current scaling level" of a VNF for a given Aspect.
  - If ETSI in their SOL001 VNFD had defined a "ScalingDelta" in a straightforward manner, i.e., in terms of the VNFCs that comprise it, then it would be very easy to extract VF Module information from the VNFD. (I would like to see ETSI define "ScalingDelta" in this manner, as opposed to the current way they do so. ) However, given that they did not, ONAP SDC would need to be extended to derive the VF Module “structure” from the SOL001 document through the algorithm below. “Structure” in this case includes the VDU topology, connection points and associated parameters. This algorithm will:
  - Determine the set of Aspects and corresponding VDUs and associated ScalingDeltas (step_deltas) from the SOL001.
  - Determine the set of ScalingLevels associated with each Aspect and the ScalingDeltas associated with each.
  - Translate the VDU-centric representation of ScalingDeltas (step_deltas) as per SOL001 to come up with a ScalingDelta-centric representation that captures the number and type of VDUs associated with that ScalingDelta across the various VDU types.
  - Create a VF Module object that corresponds to each ScalingDelta-centric representation of a ScalingDelta calculated above.
  - Fill in the details of the VF Module object based on the SOL001 data to represent the VDU connection points, associated Networks (internal or external), and associated Parameters.
  - Determine if there is an artifact in the SOL004 package that is a HOT YAML whose file name corresponds (through a VNF vendor obligatory naming convention) to the Aspect+ScalingDelta from which this VF Module object was derived. If so, associate that HOT file with the VF Module.
  - Name the VF Module based on a naming convention to capture the Aspect+ScalingDelta names
  - Determine and capture the mapping from each Aspect + ScalingLevel model for the VNF to the corresponding VF Module.
  - Given a desired state Aspect+ScalingLevel, will be able to calculate (from the SDC distributed mapping of Aspect+ScalingLevel to VF Module along with the current Scaling Level for this Aspect as per A&AI) the (ordered set of) VF Module(s) needed to take that VNF from the “current scaling level” to the desired level for that Aspect.
  - Note: As an aside, SDC enhancements are being discussed. It is not clear if the SDC changes will be available in the Dublin time frame. some “stubbing off” SDC with a simulator could be suggested to at least prove in the run-time aspects of the solution.

Solution:

SDC deduces the VF-Module from the SOL001 VNFD Policies>scaling_aspects>properties>aspects
Additional VF-Module attributes are deduced as the following table
SOL003 Adapter may need to transform the VF-Module back to the SOL001 VNFD policies for the scaling and healing requests from VNFM(s)

org.openecomp.group.VfModule Attribute and SOL001 VNF Policies deduction

Name	Required	Type	SOL001 VNFD Policies
vf_module_type	yes	string valid values: Base, Expansion	Base default: Base
vf_module_label	yes	string	aspects: <A>
min_vf_module_instances	yes	integer	initial_delta: 0
max_vf_module_instances	no	integer	max_scale_level
initial_count	yes	integer	initial_data: number_of_instances
vf_module_description	no	string	aspects: description
volume_group	yes	Boolean	default to false
group_naming	no	org.openecomp.datatypes.Naming	optional field, leave it empty

Browser not supported