Page History

...

...

...

• Enhancement (Ericsson contribution) was made to the SDC Dublin to support SOL004 PNF/VNF onboarding with .zip and .csar file extensions.
  
  • SDC VSP and Resource csar files have the ONBOARDEDETSI_PACKAGE, which contains the original vendor VNF package.
    • The VNFM and external NFVO use the original vendor VNF/NS packages.
    • ONAP-ETSI Catalog Manager will be changed for the location of the original vendor package.Author note: a common directory name, replacing the ONBOARDED_PACKAGE, is under discussion. 
  • SOL007 NS onboarding will follow the same procedure; i.e., storing the vendor SOL007 NS package into the ONBOARDEDETSI_PACKAGE directory.Author note: a common directory name, replacing the ONBOARDED_PACKAGE, is under discussion. 
• In Guilin, the ONBOARDED_PACKAGE directory is changed to the ETSI_PACKAGE directory.

1. At onboarding, SDC checks the file extension and performs the following procedures
   1. If the file is .zip, SDC unzips
      1. If it has .cert & .cms, it is a package with security and security validation will be performed.
      2. If it does not include .cert & .cms, it is an existing Heat template onboarding, and SDC follows the Heat template onboarding procedure
2. If the file is .csar, it is a package without security.
3. Next, SDC will check the TOSCA.meta file.
4. If it contains SOL004v2.x.1 keywords, the package will be handled as SOL004v2.x.1. In the Guilin release, v2.7.1 will be supported.
5. Otherwise, it will be handled as existing TOSCA (non-SOL004) package onboarding which will not have the ONBOARDEDETSI_PACKAGE artifact.

NS Onboarding Design

...

1. SOL004 VNF/PNF and SOL007 NS Packages are onboarded to SDC.
2. SDC creates its Resource CSAR by adding ONAP-specific files and metadata according to SDC procedure.
   1. For VNF onboarding, SOL001 VNFD is mapped to SDC Data Model.
   2. For NS onboarding, SOL001 NSD is mapped to SDC Data Model. Note: the SDC NS Data Model would be SOL001 NSD-based.
   3. For PNF onboarding, SOL001 PNFD is mapped to SDC Data Model.
   4. The original SOL004 VNF/PNF and SOL007 NS packages will be stored in the ONBOARDEDETSI_PACKAGE directory.
   5. SDC shall have a capability to design SOL007 NSDs and generates SOL007 NS packages
      1. Since SDC does not have a proper NS Model, it will follow SOL001 NSD.
   6. SDC embeds the Resource CSAR into its Service CSAR for distribution.
      1. After SDC validates the onboarded packages, the Service CSAR is distributed.
      2. SDC sends the package notification to DMaaP for its package notification subscribers.
3. ETSI Catalog Manager receives the package notification from SDC.
   1. ETSI Catalog Manager queries SDC for the SDC CSAR.
      1. ETSI Catalog Managers examines the SDC CSAR. If the SDC CSAR contains the ONBOARDEDETSI_PACKAGE directory, it extracts the SOL004/SOL007 packages from the directory.
      2. ETSI Catalog Manager stores the SOL004/SOL007 packages to its Catalog Database.
   2. ETSI Catalog Manager provides APIs for the SOL003/SOL005 Adapters to distribute the packages to SVNFM/NFVO.

...

• Transform SOL001-based VNFD into SDC internal models
• Store the original Vendor package into the ONBOARDEDETSI_PACKAGE directory
  • If the original vendor package is a zip file with signature and certificate, the ONBOARDEDETSI_PACKAGE directory will contain the zip file. 
• VNFM and VF-C will receive the zip-format file.
• For Frankfurt, the SVNFM and external NFVO will receive a zip-format package with signature and certificate if the original vendor package contains signature and certificate.
  • SVNFM and NFVO will unzip the incoming zip package files and extract CSAR files from the zip package files without validation.
  • After the Frankfurt release, it is assumed that SVNFM and NFVO validate the incoming packages based on signature and certificate.

...

Current Mapping Support (as of Frankfurt)

Mapping of ETSI Information NS-related Elements with TOSCA types

• 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 model references/includes associated NSs
• For NS modeling, use tosca.nodes.nfv.NS
  • ONAP SO-NFVO, VFC and external NFVO manage the NS models and packages
• The following diagram depicts ONAP ETSI-Alignment Modeling hierarchy.

Mapping between SOL001 Data Model and SDC AID DM

The following summarizes the mapping between two models:

...

Note: AAI impacts are under discussion.

Presentation Slide (as a summary)

The following is a presentation slide that summarizes the Mapping.

Note:

The following is being implemented for the Guilin release:

• SOL007 Design and SOL004 Onboarding
• ONAP ETSI-Alignment Modeling Hierarchy (partially)
  • NS Mapping
  • NS-Level VirtualLink (between VNFs) Mapping

The following mapping will be implemented in the Honolulu release:

• VNF Mapping
• VDU and VFC Mapping
• PNF Mapping
• SOL001 VNFD and SDC AID DM VF Template Mapping
  • VF-Module Deduction from SOL001 VNFD

SOL007 Design and SOL004 Onboarding

• SDC takes the vendor provided package and adds some files or changes files and meta data according to SDC procedure.
• SDC NS/VNF/PNF Onboarding Procedure and Original Vendor VNF/PNF Package Handling
  • SDC onboarding enhancement was made to the SDC Dublin to support SOL004 PNF/VNF onboarding with .zip and .csar file extensions. We continue to support the current onboarding mechanism with some enhancements.
  • SOL007 NS onboarding (stretch goal for Guilin) will follow the same procedure; i.e., storing the vendor SOL007 NS package into the “ETSI_PACKAGE” directory.
  • SOL007 NS design will allow users to build SOL007 NS package including SOL001 NSD from scratch
  • SDC VSP and Resource csar files have the “ETSI_PACKAGE” directory, which will contain the original vendor VNF/NS/PNF package.
    • The “ONBOARDED_PACKAGE” directory name will be changed to “ETSI_PACKAGE” as a common ETSI directory name. This change is necessary to support design of SOL007 package
    • ONAP-ETSI Catalog Manager will be extracted the ETSI packages from the “ETSI_PACKAGE” directory.
    • The VNFM and external NFVO use the original vendor VNF/NS/PNF packages through ETSI Catalog Manager.
• SDC provides mapping from ETSI SOL001 NSD/VNFD/PNFD (PNF in the future) to SDC AID DM
  • See the subsequent slides for mapping.
• Note: ETSI 2.7.1 handling will be discussed separately.

SDC CSAR for NS structure

ONAP Service CSAR
  |-- Artifacts
        |-- ETSI_PACKAGE
              |-- etsi nsd csar
        |-- <VF 1>
              |-- Deployment
                    |-- ETSI_PACKAGE
                          |-- etsi vnf package
            ...
        |-- <VF n>
              |-- Deployment
                    |-- ETSI_PACKAGE
                          |-- etsi vnf package

Mapping of ETSI Information NS-related Elements with TOSCA types

• 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 NS type and attach the 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

  ONAP ETSI-Alignment Modeling Hierarchy

  • The following diagram depicts ONAP ETSI-Alignment Modeling hierarchy.
  • Note: the ONAP VFC model represents the design time VFC, not runtime VFC instance(s).
  • Note: VNF, VFC and PNF node types continue to be discussed for the Honolulu release. 

  Gliffy Diagram
  size 1200 name ONAP ETSI-Alignment Models pagePin 4

  
  

  Mapping between SOL001 Data Model and SDC AID DM

  The following summarizes the mapping between two models:

  SOL001 Data Model	SDC AID DM	Comments	Release
  N/A

  Saptosca.nodes.RootNsVirtualLinkDescSOL001

  tosca.nodes.nfv.NsVirtualLink

  (there is tosca.nodes.nfv.VnfVirtualLink)

  tosca.nodes.Rootvl.ymlorg.openecomp.resource.vl.VLtosca.nodes.network.NetworkextVl.yml

  org.openecomp.resource.

  vl.extVLtosca

  abstracts.nodes.

  RootinternalVl.ymlorg.openecomp.resource.vl.internalVL

  service	represents OSS Service models
  tosca.nodes.nfv.NS	tosca.nodes.

  network.NetworkextZteVL.yml

  nfv.NS	NS; use of SOL001 as SDC AID DM NS	Guilin
  tosca.nodes.nfv.

  ext.zte.VL

  NsVirtualLink

  tosca.nodes

  .RootPnfd

  .nfv.NsVirtualLink	NS VirtualLink; use of SOL001 as SDC AID DM VL	Guilin
  tosca.nodes.nfv.

  PNFtosca.nodes.RootGeneric_PNF.yml

  Vnf	org.openecomp.resource.abstract.nodes.

  PNFtosca.nodes.RootVnfdVNF.yml

  ETSI.VNF	VNF	Plan for Honolulu
  tosca.nodes.nfv.

  VNFtosca.nodes.RootGeneric_VF.yml

  vdu	org.openecomp.resource.abstract.nodes.ETSI.

  VFtosca.nodes.RootVnffgd

  VFC	VDU and SDC VFC	Plan for Honolulu
  tosca.

  groups

  nodes.nfv.

  VNFFGtosca.groups.RootforwardingPath.yml(?)

  VirtualLink

  org.openecomp.

  nodes.ForwardingPath

  resources.vl	VNF VL	Plan for Honolulu
  tosca.nodes.nfv.

  Root

  NSD Mapping to SDC AID DM

  Initial Input

  • Internal NSD representation

  NSD Mapping to SDC AID DM

  A benefit of mapping an onboarded ETSI NS to the internal representation of an ONAP Service is that the ETSI NS can access the standard ONAP runtime functionality implemented or planned for support of ONAP Services.

  SOL001 NSD mapping to/from NS SDC AID DM

  • 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.
  • Guilin Decisions
    • SDC generates SOL001 tosca.nodes.nfv.NSD node type, and uses it as SDC AID DM.

  SOL001 NS

  VduCp	org.openecomp.resources.cp	VDU CP	Plan for Honolulu
  N/A	org.openecomp.resource.allottedResource	allotted resource; could not find any from SOL001
  tosca.nodes.nfv.Pnf	org.openecomp.resource.abstract.nodes.ETSI.PNF	PNF	Plan for Honolulu (PNF support is under discussion for Honolulu

  
  Current SDC Resource Models

  SDC: nfv-types					SDC: heat-types
  ETSI NFV IE	SDC Descriptor / SOL001	TOSCA Type	Derived from		SDC Descriptor	TOSCA Type	Derived from
  NSD	nodes.yml / SOL001	tosca.nodes.nfv.NS	tosca.nodes.Root		Generic_Service.yml	org.openecomp.resource.abstract.nodes.service (use it for both E2E (OSS Service) and NS)	tosca.nodes.Root
  	NSD.yml

  SOL001 NS (tosca.nodes.nfv.NS) - Chosen
  SDC NSD

  org.openecomp.resource.vfc.NSD

  namerequiredtypenamerequiredtypedescriptor_idyesstringnsd_idtruestringdesigneryesstringnsd_designertruestringversionyesstringnsd_versiontruestringnameyesstringnsd_nametruestringinvariant_idyesstringproviding_service_uuidtruestringflavor_idyesstringproviding_service_invariant_uuidtruestringns_profilenotosca.datatypes.nfv.NsProfileproviding_service_nametruestring

  <tosca.datatypes.nfv.NsProfile>

  Image Removed

  SDC TOSCA Repository

  https://gerrit.onap.org/r/gitweb?p=sdc.git;a=tree;f=catalog-be/src/main/resources/import/tosca;h=70fecc1c6de587cd003c38f3e43547a10785e723;hb=refs/heads/master

  Image Removed

  SDC nfv-types

  Image Removed

  SDC nfv-types/NSD

  SDC TOSCA repository: /catalog-be/src/main/resources/import/tosca/nfv-types/NSD/

  • need to update to tosca_simple_yaml_1.2

  <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

  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

  ...

  • from SOL001 v2.7.1

  ...

  • from SDC Generic_VF.yml

  ...

  boolean (default true)

  • constraints : true, false

  ...

  string (default: SO-REF-DATA)

  • constraints: SO-REF-DATA, CDS, SDNC, APPC

  ...

  Solutions:

  Define a new data type based on the tosca.nodes.nfv.VNF with optional attributes that are specific to ONAP.

  Proposal A

  • Make the org.openecomp.resource.abstract.nodes.ETSI.VNF a superset of both tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.node.VF

  ...

  SOL001 VNF (tosca.nodes.nfv.VNF)

  ...

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

  derived from org.openecomp.resource.abstract.nodes.VF

  ...

  boolean (default true)

  • constraints: true, false

  ...

  string (default: SO-REF-DATA)

  • constraints: SO-REF-DATA, CDS, SDNC, APPC

  tosca.nodes.Root	N/A
  SapD	SOL001	tosca.nodes.nfv.Sap	tosca.nodes.Root
  NsVirtualLinkDesc	SOL001	tosca.nodes.nfv.NsVirtualLink (there is tosca.nodes.nfv.VnfVirtualLink)	tosca.nodes.Root	vl.yml	org.openecomp.resource.vl.VL	tosca.nodes.network.Network
  				extVl.yml	org.openecomp.resource.vl.extVL	tosca.nodes.Root
  				internalVl.yml	org.openecomp.resource.vl.internalVL	tosca.nodes.network.Network
  	extZteVL.yml	tosca.nodes.nfv.ext.zte.VL	tosca.nodes.Root
  Pnfd		tosca.nodes.nfv.PNF	tosca.nodes.Root	Generic_PNF.yml	org.openecomp.resource.abstract.nodes.PNF	tosca.nodes.Root
  Vnfd	VNF.yml	tosca.nodes.nfv.VNF	tosca.nodes.Root	Generic_VF.yml	org.openecomp.resource.abstract.nodes.VF	tosca.nodes.Root
  Vnffgd		tosca.groups.nfv.VNFFG	tosca.groups.Root	forwardingPath.yml(?)	org.openecomp.nodes.ForwardingPath	tosca.nodes.Root

  NSD Mapping to SDC AID DM

  Initial Input

  • Internal NSD representation

  NSD Mapping to SDC AID DM

  A benefit of mapping an onboarded ETSI NS to the internal representation of an ONAP Service is that the ETSI NS can access the standard ONAP runtime functionality implemented or planned for support of ONAP Services.

  SOL001 NSD mapping to/from NS SDC AID DM

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

  
  

  SOL001 NS (tosca.nodes.nfv.NS) - Chosen				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	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

  SDC TOSCA Repository

  https://gerrit.onap.org/r/gitweb?p=sdc.git;a=tree;f=catalog-be/src/main/resources/import/tosca;h=70fecc1c6de587cd003c38f3e43547a10785e723;hb=refs/heads/master

  Image Added

  
  

  SDC nfv-types

  Image Added

  
  

  SDC nfv-types/NSD

  SDC TOSCA repository: /catalog-be/src/main/resources/import/tosca/nfv-types/NSD/

  • need to update to tosca_simple_yaml_1.2

  <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

  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 v2.7.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
  								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 Guilin, SO NFVO, VFC and SVNFM get those SOL001 VNF attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Guilin.
  • 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 Guilin.
    • Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Guilin;
    • 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	<-->

  Proposal B

  Can we use the additionalAttribute map to represent ONAP specific attributes? If so, we can use the base data type extensively.

  New SDC AID DM VNF (org.openecomp.resource.abstract.nodes.ETSI.VNF)namerequiredtypedescriptor_idyesstringdescriptor_versionyesstringprovideryesstringproduct_nameyesstringsoftware_versionyesstring

  	product_info_name	no	string
  vnfm_info	yes	list of string	<-->

  localization

  vnfm_

  languages

  info

  no

  yes	list of string

  default_

  localization_

  language

  languages

  no 

  no

  stringconfigurable_

  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_

  configuraion

  configuration	no	tosca.datatypes.nfv.VnfLcmOperationsConfiguration
  monitoring_parameters	no	list of tosca.

  dataypes

  datatypes.nfv.VnfMonitoringParameter

  <-->

  flavour

  monitoring_

  id

  parameters

  yesstring

  no	list of tosca.datatypes.nfv.VnfMonitoringParameter
  flavour_

  description

  id

  yes

  string

  vnf_

  <-->	flavour_id	yes	string
  flavour_description	yes	string	<-->	flavour_description	yes	string
  vnf_profile	no	tosca.

  datatyhpes

  datatypes.nfv.VnfProfile

  additionalAttribute

  <-->

  vnf_profile

  no

  (0

  tosca.

  .N)map (string, object pair)

  SOL001 VNF mapping to/from VNF SDC AID DM

  SOL001 VDU vs. SDC AID DM VFC

  datatypes.nfv.VnfProfile
  				<SDC AID DM VF attributes that are inherited from

  SOL001 VDUSDC AID DM VFC (

  org.openecomp.resource.abstract.nodes.

  VFC)NameRequiredTypeNameRequiredTypenameyesstringnfc_functionstringdescriptionyesstringhigh_availability

  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

  boot

  nf_

  order

  naming

  no

  booleanvm_image_namestringnfvi_constraintsnomap of stringvm_flavor_nameyesstringmonitoring_parametersnolist of tosca.datatypes.nfv.VnfcMonitoringParameter

  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

  nfc_naming_code

  no

  string

  configurable

  sdnc_artifact_

  properties

  name

  no

  map of tosca.datatypes.nfv.VnfcConfigurablePropertiesvm_type_tagnostringboot_datanotosca.datatypes.nfv.BootDatanfc_naming

  org.openecomp.datatypes.Naming

  • ONAP_generated_naming: yes: boolean
  • naming_policy: no: string
  • instance_name: no: string

  vdu_profileyestosca.datatypes.nfv.VduProfilemin_instancesnointegersw_image_datanotosca.datatypes.nfv.SwImageData

  Proposals 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.node.VFC

  ...

  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

  
  

  Option B:

  Define a new data type based on the tosca.nodes.nfv.VNF with SDC AID DM VNF data type attributes.

  • SDC AID DM VNF data type attributes will be handled as the 'additionalAttributes', which is a map of key, value pairs.
  • 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.

  a new data type org.openecomp.resource.abstract.nodes.ETSI.

  ...

  SOL001 VDUMappingorg.openecomp.resource.abstract

  VNF that is inherited from SOL001 VNF (tosca.nodes.

  ETSI.VFC

  (derived from org.openecomp.resource.abstract.nodes.VFC)

  nfv.VNF)
  name	required	type
  <SOL001 tosca.nodes.nfv.VNF attributes >
  descriptor_id	yes	string
  descriptor_version

  NameRequiredType<-->NameRequiredTypename

  yes

  string

  <-->name

  provider

  yes

  string

  descriptiondescription

  product_name

  yes

  string

  <-->

  software_version

  yes

  string

  boot

  product_info_

  order

  name

  no

  no

  boolean<-->boot_ordernobooleannfvi_constraints

  string
  vnfm_info	yes	list of string
  localization_languages	no

  map

  list of string

  <-->nfvi_constraintsnomap of string

  default_localization_language	no	string
  configurable_properties

  monitoring_parameters

  no

  list of

  tosca.datatypes.nfv.

  VnfcMonitoringParameter<-->

  VnfconfigurableProperties

  modifiable_attributes

  monitoring_parameters

  no

  list of

  tosca.datatypes.nfv.

  VnfcMonitoringParameter

  VnfInfoModifiableAttributes

  configurable

  lcm_operations_

  properties

  configuraion

  no

  map of

  tosca.datatypes.nfv.

  VnfcConfigurableProperties

  VnfLcmOperationsConfiguration

  monitoring_parameters

  <-->configurable_properties

  no

  map

  list of tosca.

  datatypes

  dataypes.nfv.

  VnfcConfigurableProperties

  VnfMonitoringParameter

  boot

  flavour_

  data

  id

  notosca.datatypes.nfv.BootData<-->boot_datanotosca.datatypes.nfv.BootDatavdu_profileyestosca.datatypes.nfv.VduProfile<-->vdu_profileyestosca.datatypes.nfv.VduProfilesw_image_datanotosca.datatypes.nfv.SwImageData<-->sw_image_datanotosca.datatypes.nfv.SwImageData

  yes	string
  flavour_description	yes	string
  vnf_profile	no	tosca.datatyhpes.nfv.VnfProfile
  additionalAttriubtes (or nonManoAttributes)	no	map of key, value pair

  
  

  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 (

  <SDC AID DM VFC attributes that are inherited from the

  org.openecomp.resource.abstract.nodes.

  VFC>

  VFC)
  Name	Required	Type	Name	Required	Type
  name	yes	string	nfc_function		string
  description

  no

  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

  no

  org.openecomp.datatypes.Naming ONAP_generated_naming: yes: boolean naming_policy: no: string instance_name: no: string

  min

  vdu_

  instances

  profile

  nointeger

  SOL001 2.7.1 VNF Template

  tosca_definitions_version: tosca_simple_yaml_1_2

  description:

  imports:

  data_types:

  node_types:

  topology_template:

      inputs: 

      node_templates: 

          VNF

  substitution_mappings:

      capabilities:

      requirements:

  SDC VF 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:

  Image Removed

  SOL001 VNFD mapping to/from SDC AID DM VF

  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 Guilin, SO NFVO, VFC and SVNFM get those SOL001 VDU attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Guilin.
  • 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 Guilin.
    • Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Guilin;
    • 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 2.7.1 VNFD Mapping from/to SDC AID DM VNFD

  SOL001 2.7.1 VNFD Template

  tosca_definitions_version: tosca_simple_yaml_1_2

  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:

  
  

  Image Added

  SOL001 VNFD mapping to/from SDC AID DM VFD

  
  

  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.<>

  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 <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	SOL001 VNFD		SDC AID DM VF		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 <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	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	workflows	<workflow name>	scaling aspect	groups	list of VF Modules VFModule_Base:     type: org.openecomp.groups.VfModule VFModule_Expansion:     type: org.openecomp.groups.VfModule	policies	for each VF Module, additional information is provided	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	<group_type_name>: derived_from: <parent_groupexisting_type_name> version: <version_number> metadata: <map of string> description: <groupdatatype_description> propertiesconstraints: - <propertytype_definitionsconstraints> members: [ <list_of_valid_member_types> ] requirementsproperties: - <requirementproperty_definitions> capabilities:		policydata_types	<policydata_type_name>: derived_from: <parent_policyexisting_type_name> version: <version_number> metadata: <map of string> description: <policydatatype_description> constraints: - <type_constraints> properties: <property_definitions> targets: [ <list_of_valid_target_types> ] triggers: <list_of_trigger_definitions>
  node_types	<node	Relationship	<relationship_type_name>: derived_from: <parent_relationshipnode_type_name> version: <version_number> metadata: <map of string> description: <relationshipnode_type_description> attributes: <attribute_definitions> properties: <property_definitions> requirements: - <requirement_definitions> attributescapabilities: <attributecapability_definitions> interfaces: <interface_definitions> artifacts:valid_target <artifact_definitions>		node_types: [	< capability node_type_ names name> ] : annotation derived_ type <annotationfrom: <parent_node_type_name>: version: <version_number> metadata: <map of string> description: <annotationnode_type_description> propertiesattributes: <propertyattribute_definitions> annotation properties: <annotationproperty_namedefinitions> requirements: type: - <annotationrequirement_typedefinitions> propertiescapabilities: <propertycapability_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.

  ...

  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) – not part of Guilin

  Gliffy Diagram
  macroId 4e072032-7cad-4d7d-befc-a60416101d10 name ONAP ETSI-Alignment VF-Module Mapping pagePin 7

  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

  ...

  VirtualLink Mapping to SDC AID DM

  ...