...
- For E2E (OSS Service) modeling, use org.openecomp.resource.abstract.nodes.service
- E2E (OSS Service-Level) is outside of ETSI scope, and it could be ONAP-specific that is orchestrated by ONAP SO
- The E2E (OSS Service-Level) model references/includes associated NSs
- For the E2E service level, the org.openecop.resource.abstract.nodes.service type is still used as the base type of the service. SDC will use the ETSI SOL001 NSD NS type and attach the NSDs NSs to the E2E (OSS Service).
- For NS modeling, use tosca.nodes.nfv.NS
- ONAP SO-NFVO, VFC and external NFVO manage the NS models and packages
...
| SOL001 VNF | SDC AID DM | comments |
|---|---|---|
| N/A | org.openecomp.resource.abstracts.nodes.service | represents OSS Service models |
| org.tosca.nodes.nfv.NS | tosca.nodes.nfv.NS | NS; use of SOL001 as SDC AID DM NS |
| tosca.nodes.nfv.NsVirtualLink | tosca.nodes.nfv.NsVirtualLink | NS VirtualLink; use of SOL001 as SDC AID DM VL |
| tosca.nodes.nfv.Vnf | org.openecomp.resource.abstract.nodes.ETSI.VNF | VNF |
| tosca.nodes.nfv.vdu | org.openecomp.resource.abstract.nodes.VFC | VDU and SDC VFC |
| tosca.nodes.nfv.VirtualLink | org.openecomp.resources.vl | VNF VL |
| tosca.nodes.nfv.VduCp | org.openecomp.resources.cp | VDU CP |
| N/A | org.openecomp.resource.allottedResource | allotted resource; could not find any from SOL001 |
| tosca.nodes.nfv.Pnf | org.openecomp.resource.abstract.nodes.PNF | PNF |
...
- ONAP previous analysis
- The SDC NSD node type, org.openecom.resource.vfc.NSD, is modeled as a component of a VF to represent an allotted resource. But, it is not derived from the org.openecomp.resource.vfc.AllottedResource, either.
- The SDC NSD might be designed for Volte use case support, and used by the VFC.
- It is recommended to deprecate the current SDC NSD node type, and to replace with SOL001 tosca.nodes.nfv.NSD NS node type.
- Solutions
- SDC generates SOL001 tosca.nodes.nfv.NSD NS node type
- SDC takes SOL001 NSD with tosca.nodes.nfv.NSD NS node type as is, without mapping; i.e., no mapping is necessary
- ONAP SO NFVO uses the SOL001 NSD
- VFC needs to use the SOL001 NSD
- There could be some impact on VID and ONAP SO Catalog DB for the SOL001 NSD - to be analyzed.
- Guilin Decisions
- SDC generates SOL001 tosca.nodes.nfv.NSD node type, and uses it as SDC AID DM.
...
| SOL001 NS (tosca.nodes.nfv.NS) - Chosen |
| |||||
|---|---|---|---|---|---|---|
| name | required | type | ||||
| descriptor_id | yes | string | ||||
| designer | yes | string | ||||
| version | yes | string | ||||
| name | yes | string | ||||
| invariant_id | yes | string | ||||
| flavor_id | yes | string | ||||
| ns_profile | no | tosca.datatypes.nfv.NsProfile | ||||
<tosca.datatypes.nfv.NsProfile>
...
- 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.
- There is no 1:1 mapping between the SOL001 tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.nodes.VF.
- 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
- map between SOL001 VNF and SDC AID DM VNF selectively.
Current VNF Modeling in ETSI and SDC
...
- Make the org.openecomp.resource.abstract.nodes.ETSI.VFC a superset of both tosca.nodes.nfv.Vdu and org.openecomp.resource.abstract.nodenodes.VFC
- Note: the org.openecomp.resource.abstract.nodes.VFC represents design-time VFC, not VFC instances
New SDC AID DM VFC type (org.openecomp.resource.abstract.nodes.ETSI.VFC)
...
| SOL001 VNFD | SDC AID DM VFD | |||
|---|---|---|---|---|
| Name | Grammar | Name | Grammar | |
| tosca_definitions_version | string (tosca_simple_yaml_1_2) | tosca_definitions_version | string (tosca_simple_yaml_1_2) | |
| description | string | description | string | |
| metadata | map of <string> | metadata | map of <string> | |
| imports | Single-line grammar
Multi-line grammar
| 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
| |
| string |
| string | |
|
| <parameter name>: type: <parameter_type> description: <parameter_description> required: <parameter_required> default: <parameter_default_value> constraints: - <parameter_constraints> | ||
| 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 |
| 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.<> | |
| <workflow name> | |||
policies
| tosca.datatypes.nfv.ScalingAspect
|
| list of VF Modules VFModule_Base: type: org.openecomp.groups.VfModule VFModule_Expansion: type: org.openecomp.groups.VfModule | |
| for each VF Module, additional information is provided | |||
| substitution_mappings | substitution_mappings | |||
|
| |||
| <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> ] | |
|
| |||
| 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
| 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> | |||
...