Page History

...

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 node type.
Solutions
- SDC generates SOL001 tosca.nodes.nfv.NSD node type
- SDC takes SOL001 NSD with tosca.nodes.nfv.NSD 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.

SOL001 NS

SOL001 NS (tosca.nodes.nfv.NS)			SDC NSD org.openecomp.resource.vfc.NSD
name	required	type	name	required	type
descriptor_id	yes	string	nsd_id	true	string
designer	yes	string	nsd_designer	true	string
version	yes	string	nsd_version	true	string
name	yes	string	nsd_name

invariant_idyesstringflavor_idyesstringns_profilenotosca.datetypes.nfv.NsProfile

true	string
invariant_id	yes	string	providing_service_uuid	true	string
flavor_id	yes	string	providing_service_invariant_uuid	true	string
ns_profile	no	tosca.datatypes.nfv.NsProfile	providing_service_name	true	string

<tosca.datatypes.nfv.NsProfile>

Image Added

Current SDC NSD

<nodes.yml: org.openecomp.resource.vfc.NSD>

org.openecomp.resource.vfc.NSD:

derived_from: tosca.nodes.Root

description: ECOMP Allotted Resource base type all other allotted resources node types derive from

properties:

nsd_id:

type: string

required: true

description: ID of the NSD

nsd_designer:

type: string

required: true

description: Designer of the NSD

nsd_version:

type: string

required: true

description: Version of the NSD

nsd_name:

type: string

required: true

description: Name of the NSD

providing_service_uuid:

type: string

required: true

description: The depending service uuid in order to map the allotted resource to the specific service version

providing_service_invariant_uuid:

type: string

required: true

description: The depending service invariant uuid in order to map the allotted resource to the specific service version

providing_service_name:

type: string

required: true

description: The depending service name in order to map the allotted resource to the specific service version

requirements:

- virtualLink:

capability: tosca.capabilities.network.Linkable

relationship: tosca.relationships.network.LinksTo

capabilities:

virtual_linkable:

type: tosca.capabilities.network.Linkable

VNFD Mapping to 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 configurationas 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

...

ONAP previous analysis
- Each vendor/operator defined their own VL node types (e.g., tosca.nodes.nfv.ext.zte.VL)
- The vendor/operator-specific node types have no direct 1:1 mapping to tosca.nodes.nfv.NsVirtualLink
Solutions
- Deprecate vendor/operator-specific VLs
- Use SOL001 tosca.nodes.nfv.NsVirtualLink
- ONAP SO NFVO uses the SOL001 tosca.nodes.nfv.NsVirtualLink
- VFC needs to adapt SOL001 tosca.nodes.nfv.NsVirtualLink