Versions Compared

Old Version 140

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version Current

changes.mady.by.user Byung-Woo Jun

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Currently, the substitution_mappings is not supported by SDC. Lack of this support blocks SOL004 VNF package management and ETSI Catalog Manager:

  • Prior to Frankfurt, as a workaround, the operator creates a dummy VNF without the substitution_mappings or node_types in the MainServiceTemplate.yaml and added a real VNF package with the substitution_mappings and user-define nodes in its Artifacts>DEPLOYMENT>OTHER directory.
  • It is to trick the current SDC onboarding issues because SDC does not check the OTHER directory.
  • In the Frankfurt/Dublin release, SDC was enhanced to support the vendor VNF package in the ETSI_PACKAGE directory.
  • In the Guilin release, the ONBOARDED_PACKAGE directory is changed to the ETSI_PACKAGE.
  • Since SDC Frankfurt/Dublin, we don't have to use the secondary VNF package unnecessary, but we still needs to follow an old way because of lack of substitution_mappings and user-defined node_types.
  • When SDC supports the subscription_mappings user-defined node types, the vendor VNF package does not have to add another VNF package in the Artifacts>DEPLOYMENT>OTHER directory, and the ETSI Catalog Manager will support the VNF package in the ETSI_PACKAGE directory.
    • ETSI Catalog Manager will depend on this SDC support.

Support of the substitution_mappings and user-defined node_types will remove the issues and support ETSI package management and others.

Support of the user-defined node types is handled by another task. This task needs to handle the substitution_mappings only.

For the testing,  use the vgw6.csar

For the Frankfurt release workaround, we added the following to the MainServiceTemplate.yaml, so the ETSI Catalog Manager can retrieve the descriptor_id from the metadata, instead of from the node_type. Once the substitution_mapping is supported by SDC, we don't have to use the descriptor_id in the metadata section.

  • descriptor_id: b1bb0ce7-2222-4fa7-95ed-4840d70a1177
SDC supports SOL004 PNF package includes SOL001 PNFD
  • PNFD onboarding is done and its regression testing will be done
SOL004 PNF package onboarding is done in Dublin but support
  • Update onboarding procedure for v2.7.1

    • Epic

    User Story

    Description

    Guilin Plan?

    JIRA

    MaintenanceSupport the substitution_mappings in the VNFD.

    Currently, the substitution_mappings is not supported by SDC. Lack of this support blocks SOL004 VNF package management and ETSI Catalog Manager:

    • Prior to Frankfurt, as a workaround, the operator creates a dummy VNF without the substitution_mappings or node_types in the MainServiceTemplate.yaml and added a real VNF package with the substitution_mappings and user-define nodes in its Artifacts>DEPLOYMENT>OTHER directory.
    • It is to trick the current SDC onboarding issues because SDC does not check the OTHER directory.
    • In the Frankfurt/Dublin release, SDC was enhanced to support the vendor VNF package in the ETSI_PACKAGE directory.
    • In the Guilin release, the ONBOARDED_PACKAGE directory is changed to the ETSI_PACKAGE.
    • Since SDC Frankfurt/Dublin, we don't have to use the secondary VNF package unnecessary, but we still needs to follow an old way because of lack of substitution_mappings and user-defined node_types.
    • When SDC supports the subscription_mappings user-defined node types, the vendor VNF package does not have to add another VNF package in the Artifacts>DEPLOYMENT>OTHER directory, and the ETSI Catalog Manager will support the VNF package in the ETSI_PACKAGE directory.
      • ETSI Catalog Manager will depend on this SDC support.

    Support of the substitution_mappings and user-defined node_types will remove the issues and support ETSI package management and others.

    Support of the user-defined node types is handled by another task. This task needs to handle the substitution_mappings only.


    For the testing,  use the vgw6.csar


    For the Frankfurt release workaround, we added the following to the MainServiceTemplate.yaml, so the ETSI Catalog Manager can retrieve the descriptor_id from the metadata, instead of from the node_type. Once the substitution_mapping is supported by SDC, we don't have to use the descriptor_id in the metadata section.

    • descriptor_id: b1bb0ce7-2222-4fa7-95ed-4840d70a1177
    		Onboard and Design ETSI SOL004 compliant VNF packages

    Executive Summary - Enable a vendor provided ETSI SOL004 compliant VNF package including an ETSI SOL001 VNF Descriptor to  be onboarded into ONAP for composition into an ONAP Service

    Business Impact - Enables operators and service providers to use same ETSI compliant VNF packages with ONAP and existing NFVO. Industry compatibility.

    Business Markets - All operators that are currently using ETSI packages to deploy VNFs

    Funding/Financial Impacts - Reduction in operations expense from using industry standard VNF packaging.  Reduction in capital expense from vendors using a single packaging methodology.

    Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 

    Yes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2610

    Support for onboarding ETSI v2.7.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2.7.1)

    		Yes

    Image RemovedSDC-2611 - SDC supports onboarding of the SOL004 VNF Package includes SOL001 VNFD OPEN

    Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model

    • Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model
    		Yes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2617

    		Support for editing ETSI v2.7.1 SOL001 VNF Descriptor
    • Support for editing ETSI v2.7.1 SOL001 VNF Descriptor
    		Yes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2881

    Support for using an ETSI v2.7.1 VNF in an ONAP Service

    • Support for using an ETSI v2.7.1 VNF in an ONAP Service
    		TBDSupport the substitution_mappings in the VNFD.

    2957

    Onboard and Design ETSI SOL004 compliant VNF packages


    Executive Summary - Enable a vendor provided ETSI SOL004 compliant VNF package including an ETSI SOL001 VNF Descriptor to  be onboarded into ONAP for composition into an ONAP Service

    Business Impact - Enables operators and service providers to use same ETSI compliant VNF packages with ONAP and existing NFVO. Industry compatibility.

    Business Markets - All operators that are currently using ETSI packages to deploy VNFs

    Funding/Financial Impacts - Reduction in operations expense from using industry standard VNF packaging.  Reduction in capital expense from vendors using a single packaging methodology.

    Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 

    No

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2610


    Support for onboarding ETSI v2.7.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2.7.1)

    Support for onboarding ETSI v2.7.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2.7.1)

    • Support SDC AID DM VF descriptor (see the 

      79200568 section)

    		No

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2611



    Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model

    Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model

    VNF Mapping:

    • 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

    VDU 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

    VF-Module Mapping:

    • 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
    		NoYes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2957

    Onboard ETSI SOL007 compliant Network Service Descriptor packages

    Executive Summary - Onboard an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1)  Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) to  be onboarded into ONAP for composition into an ONAP Service or deployment using an ETSI compliant NFVO.

    • Support for Cataloging and Preserving the original SOL007 package

    • Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model

    • Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using VF-C as the NFVO

    • Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO

    Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility.

    Business Markets - All operators and service providers that are developing ETSI compatible Network Services

    Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging.

    Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 

    		stretch goal

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2801

    		Support onboarding for Cataloging and Preserving the original SOL007 package

    Support onboarding for Cataloging and Preserving the original SOL007 package (Link to ETSI SOL001 v2.7.1)

    		stretch goal

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2806

    		Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model

    Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model

    • use SOL001 NSD as SDC AID DM
    		stretch goal

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-26182617


    		Support for deploying a service that contains an ETSI SOL001 editing ETSI v2.7.1 compliant Network Service using VF-C as the NFVOSOL001 VNF Descriptor
    • Support for
    deploying a service that contains an ETSI SOL001
    • editing ETSI v2.7.1
    compliant Network Service using VF-C as the NFVO    		No

    Close this, expect the current SDC distribution is sufficient

    • SOL001 VNF Descriptor
    		No

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2881


    Support for using an ETSI

    Support for deploying a service that contains an ETSI SOL001

    v2.7.1

    compliant Network Service using an external NFVO

    VNF in an ONAP Service

    • Support for
    deploying a service that contains
    • using an ETSI
    SOL001
    • v2.7.1
    compliant Network Service using an external NFVO    		No

    Close this, expect the current SDC distribution is sufficient

    • VNF in an ONAP Service

    		TBD

    Onboard Design ETSI SOL007 compliant Network Service Descriptor & packages


    Executive Summary - Design, catalog and distribute  Onboard an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1)  Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) to  be onboarded into ONAP for composition into an ONAP Service or deployment using an ETSI compliant NFVO.

    • Support for Cataloging and Preserving the original SOL007 package

    • Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model

    • Support for deploying a service that contains deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using VF-C as the NFVO

    • Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO

    Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility.

    Business Markets - All operators and service providers that are developing ETSI compatible Network Services

    Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging.

    Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 

    		YesNo

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2802

    Note: there is a PoC for this. Soon, the PoC design could be shared as initial input for discussions

    2801


    		Support onboarding for Cataloging and Preserving the original SOL007 package

    Support onboarding for Cataloging and Preserving the original SOL007 package (Link to

    Design ETSI SOL001 NSD and generate an

    ETSI SOL001 v2.7.1)

    		No

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2806






    Design ETSI SOL007 compliant Network Service Descriptor &

    package

    packages


    		Support for mapping of ETSI v2

    Executive Summary - Design ETSI SOL001 NSD and generate , catalog and distribute  an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1 compliant )  Network Service package

  • Create NS and compose NS with its sub components, such as VNFs, VLs, VNF-FG and dependencies between VNFs, etc. - final support scope will be defined

    • Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor

    in the SOL007 package into SDC AID Data Model
    • use SOL001 NSD as SDC AID DM
  • Generate SOL007 NS package
    		• Yes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2808

    (NSD) for deployment using an ETSI compliant NFVO.

    • Support for

    Support for 

    • deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using VF-C as the NFVO

    • Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using

    VF-C as the NFVO
    • Wrap the NS package in the Service for VF-C
    		Yes

    Close this, expect the current SDC distribution is sufficient

    		Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO

    Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO

    • Wrap the NS package in the Service for an external NFVO
    		Yes

    Close this, expect the current SDC distribution is sufficient

    • an external NFVO

    Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility.

    Business Markets - All operators and service providers that are developing ETSI compatible Network Services

    Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging.

    Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 

    		Support design of Service templates, leveraging NSDsSupport design of Service templates, leveraging NSDs

    		Yes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-28822802

    Note: there is a PoC for this. Soon, the PoC design could be shared as initial input for discussions


    		Design ETSI SOL001 NSD and generate an ETSI SOL001 v2.7.1 compliant Network Service Descriptor & package

    Design ETSI SOL001 NSD and generate ETSI SOL007 compliant Network Service package

    • Create NS and compose NS with its sub components, such as VNFs, VLs, VNF-FG and dependencies between VNFs, etc. - final support scope will be defined
    • Support for mapping of ETSI SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model
      • use SOL001 NSD as SDC AID DM
    • Generate SOL007 NS package
    		YesChange the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directoryChange the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directoryYes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-32442808


    		Support for Nested/Hierarchical mapping of ETSI SOL001 v2.7.1 SOL001 Network Service Descriptor

    Executive Summary - Onboard an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1)  Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) that includes references to other Network Service Descriptors for composition into an ONAP Service or deployment using an ETSI compliant NFVO.

    Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility.

    Business Markets - All operators and service providers that are developing ETSI compatible Network Services especially for 5G Slicing where each Slice Subnet is associated with a Network Service 

    Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging.

    Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 

    		in the SOL007 package into SDC AID Data Model

    Support for mapping of ETSI SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model

    • use SOL001 NSD as SDC AID DM
    • support only ETSI NS and NsVirtualLink only
    		Yes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2618


    		Support design of Service templates, leveraging NSDsSupport design of Service templates, leveraging NSDsNo

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2882


    		Change the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directoryChange the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directoryYesNo

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-28033244

    Support for onboarding of the SOL007 Nested/Hierarchical ETSI SOL001 v2.7.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP ServiceSupport for onboarding of the Network Service Descriptor

    Executive Summary - Onboard an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1

    compliant NSD

    )  Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) that includes references to other

    NSDs

    Network Service Descriptors for composition into

    ONAP Service    		No

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2811

    		Onboard ETSI SOL004 compliant PNF packages

    Executive Summary - Enable a vendor provided ETSI SOL004 compliant PNF package including an ETSI SOL001 PNF Descriptor to  be onboarded into ONAP for composition into an ONAP Servicean ONAP Service or deployment using an ETSI compliant NFVO.

    Business Impact - Enables operators and service providers to use same ETSI compliant PNF packages vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility.

    Business Markets - All operators and service providers that are currently using ETSI packages to deploy PNFsdeveloping ETSI compatible Network Services especially for 5G Slicing where each Slice Subnet is associated with a Network Service 

    Funding/Financial Impacts - Reduction in operations expense from using industry standard PNF packaging.  Reduction in capital expense from vendors using a single packaging methodologyNSD packaging.

    Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 

    		YesNo

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-28052803


    		Support for onboarding of the SOL007 v2.7.1 Yes
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2837

    Support for mapping of ETSI v2.7.1 SOL001 PNF Descriptor into SDC AID Data Model

    compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP ServiceSupport for onboarding of the SOL007 v2.7.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP ServiceNoSOL001 PNFD 2.7.1 Mapping to SDC AID DMYes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-28362811

    Onboard ETSI SOL004 compliant PNF packages

    Executive Summary - Enable a vendor provided ETSI SOL004 compliant PNF package including an ETSI SOL001 PNF Descriptor to  be onboarded into ONAP for composition into an ONAP Service

    Business Impact - Enables operators and service providers to use same ETSI compliant PNF packages with ONAP and existing NFVO. Industry compatibility.

    Business Markets - All operators that are currently using ETSI packages to deploy PNFs

    Funding/Financial Impacts - Reduction in operations expense from using industry standard PNF packaging.  Reduction in capital expense from vendors using a single packaging methodology.

    Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 

    NoSupport additional package artifact Indicators for ETSI packages and Non-ETSI packages

    SDC supports additional package artifact types to split ETSI packages from other non-ETSI TOSCA packages

    • SDC (notification) generates additional artifact types
    • SDC client filters on the additional artifact types
    Yes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-28132805


    SDC

    Notification

    supports

    additional package artifact types to split ETSI package from other non-ETSI TOSCA packages

    onboarding of the SOL004 PNF package includes SOL001 PNFD

    • PNFD onboarding is done and its regression testing will be done
    • SOL004 PNF package onboarding is done in Dublin but support v2.7.1
    • Update onboarding procedure for v2.7.1
    No

    SDC (Notification) supports additional package artifact types to split ETSI package from other non-ETSI TOSCA packages

    • for SOL004 and SOL007 packages, artifact type = ONBOARDED_ETSI_PACKAGE
    • for non-ETSI TOSCA package, artifact type = ONBOARDED_ONAP_PACKAGE
    Yes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2837



    Support for mapping of ETSI v2.7.1 SOL001 PNF Descriptor into SDC AID Data Model


    SOL001 PNFD 2.7.1 Mapping to SDC AID DMNo

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2836

    Support additional package artifact Indicators for 2814SDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI packagesSDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI packages
    • for SOL004 and SOL007 packages, filtering for artifact type = ONBOARDED_ETSI_PACKAGE
    • for non-ETSI TOSCA package, filtering for artifact type = ONBOARDED_ONAP_PACKAGE

    SDC supports additional package artifact types to split ETSI packages from other non-ETSI TOSCA packages

    • SDC (notification) generates additional artifact types
    • SDC client filters on the additional artifact types
    NoYes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2815

    Support ETSI Package Security and validation

    • ONAP supports vendor ETSI Package Security and validation

      • If the vendor package includes signature and certificate, ONAP supports the package security
    Yes

    2813


    SDC Notification supports additional package artifact types to split ETSI package from other non-ETSI TOSCA packages

    SDC (Notification) supports additional package artifact types to split ETSI package from other non-ETSI TOSCA packages

    • for SOL004 and SOL007 packages, artifact type = ONBOARDED_ETSI_PACKAGE
    • for non-ETSI TOSCA package, artifact type = ONBOARDED_ONAP_PACKAGE
    No

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2814


    SDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI packages

    SDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI packages

    • for SOL004 and SOL007 packages, filtering for artifact type = ONBOARDED_ETSI_PACKAGE
    • for non-ETSI TOSCA package, filtering for artifact type = ONBOARDED_ONAP_PACKAGE
    No

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2815

    Support ETSI Package Security and validation

    • ONAP supports vendor ETSI Package Security and validation

      • If the vendor package includes signature and certificate, ONAP supports the package security
    No2613
    • SOL004 VNF/PNF Package security will be supported by SDC, based on the package signature and certificate
    • ONAP SDC supports the package security
    Done
    • SOL007 NS Package security will be supported by SDC, based on the package signature and certificate
    • ONAP SDC supports the package security
    Yes

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-26142613


    • SOL004 VNF/PNF Package security will be supported by SDC, based on the package signature and certificate
    • ONAP SDC supports the package security
    Done

    • SOL007 NS Package security will be supported by SDC, based on the package signature and certificate
    • ONAP SDC supports the package security
    No

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySDC-2614

    Support of ETSI Package Validation
    VNF SDK will support ETSI package validation for VNF and NSTBD

    VNF SDK will support ETSI VNF package Support of ETSI Package ValidationVNF SDK will support ETSI package validation for VNF and NSTBDVNF SDK will support ETSI VNF package pre-onboarding for validationVNF SDK will support ETSI VNF package pre-onboarding for validationTBD

    VNF SDK will support ETSI NS package pre-onboarding for validationVNF SDK will support ETSI NS package pre-onboarding for validationTBD

    ...

    PlantUML Macro
    typedot
    @startuml
participant OSS_BSS
participant SDC
participant ONAP_ETSI_Catalog_Mgr
participant SO_NFVO
participant SOL003_Adapter
participant SOL005_Adapter
participant VNFM
participant VFC
participant Ext_NFVO
autonumber 

OSS_BSS -> SDC : Vendor SOL004/SOL007 package onboarding,\nincluding SOL001
SDC --> SDC : onboard SOL004/SOL007 package and put the vendor package\ninto the ONBOARD_PACKAGE directory
ONAP_ETSI_Catalog_Mgr -> SDC : register for SDC notification 
SDC -> ONAP_ETSI_Catalog_Mgr : send a notification for SDC CSAR with the original vendor CSAR/Zip
ONAP_ETSI_Catalog_Mgr -> SDC : query the SDC CSAR with the SDC CSAR id
ONAP_ETSI_Catalog_Mgr --> ONAP_ETSI_Catalog_Mgr : extract SOL004/Sol007 package CSAR/Zip from the SDC CSAR \nand store it

group NS PACKAGE TO SO_NFVO
	ONAP_ETSI_Catalog_Mgr -> SO_NFVO : send a notification to SO_NFVO
	SO_NFVO -> ONAP_ETSI_Catalog_Mgr : query for a NS package
end

group VNF PACKAGE TO SVNFM
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : send a notification to SOL003_Adapter
	SOL003_Adapter -> VNFM : send a notification
	VNFM -> SOL003_Adapter : query for a VNF package
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF package
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : send a VNF package 
	SOL003_Adapter -> VNFM : sends a VNF package
end

group NS/VNF/PNF PACKAGE TO Ext NFVO
	ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a notification to SOL005_Adapter
	SOL005_Adapter -> Ext_NFVO : send a notification
	Ext_NFVO -> SOL005_Adapter : query for a VNF/PNF/NS package
	SOL005_Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF/PNF/NS package
	ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a VNF/PNF/NS package 
	SOL005_Adapter -> Ext_NFVO : sends a VNF/PNF/NS package
end

group NS/VNF/PNF PACKAGE TO VFC 
	ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a notification to SOL005_Adapter
	SOL005_Adapter -> VFC : send a notification
	VFC -> SOL005_Adapter : query for a VNF/PNF/NS package
	SOL005_Adapter : query for a VNF/PNF/NS package
	SOL005_Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF/PNF/NS package
	ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a VNF/PNF/NS package 
	SOL005_Adapter -> VFC : sends a VNF/PNF/NS package
end	
	
@enduml

    SDC SOL004/SOL007 VNF Package Security

    Among the SOL004/SOL007 VNF package security options, the SDC supports the option2 as depicted below. In the option 2, there are two ways to zip the VNF packages, and SDC supports both.

    SDC validates the VNF packages based on the embedded signature and certificate by leveraging CA.

    • Vendor SOL004/SOL007 VNF Package with certificate and signature is onboarded into SDC
      • ZIP-format VNF package includes CSAR, Signature and Certificate
    • SDC validates VNF package based on the certificate and signature
    • SDC generates SDC internal model plus the vendor SOL004/SOL007 package CSAR and ZIP (with certificate and signature) – the supported format is TBD based on the security requirement

    Image Removed

    Package Security

    A VNF package uses the signature and certificate to ensure package integrity and validity. A CSAR file is digitally signed with the VNF provider private key. During the VNF package onboarding to SDC, SDC validates the package and then does the following:

    • Transform SOL001-based VNFD into SDC internal models
    • Store the original Vendor package into the ETSI_PACKAGE directory
      • If the original vendor package is a zip file with signature and certificate, the ETSI_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.

    SOL001 Mapping to SDC AID DM

    The following diagram depicts SOL001 Mapping to SDC AID DM.

    Gliffy Diagram
    macroIdc3089f5b-d8cc-4e90-8303-ad2808852d65
    nameSOL001 Mapping to SDC AID DM - Guilin
    pagePin2

    Current Mapping Support (as of Frankfurt)

    Image Removed

    Note: AAI impacts are under discussion.

    Presentation Slide (as a summary)

    The following is a presentation slide.

    _Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF/PNF/NS package
	ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a VNF/PNF/NS package 
	SOL005_Adapter -> VFC : sends a VNF/PNF/NS package
end	
	
@enduml


    SDC SOL004/SOL007 VNF Package Security

    Among the SOL004/SOL007 VNF package security options, the SDC supports the option2 as depicted below. In the option 2, there are two ways to zip the VNF packages, and SDC supports both.

    SDC validates the VNF packages based on the embedded signature and certificate by leveraging CA.

    • Vendor SOL004/SOL007 VNF Package with certificate and signature is onboarded into SDC
      • ZIP-format VNF package includes CSAR, Signature and Certificate
    • SDC validates VNF package based on the certificate and signature
    • SDC generates SDC internal model plus the vendor SOL004/SOL007 package CSAR and ZIP (with certificate and signature) – the supported format is TBD based on the security requirement

    Image Added


    Package Security

    A VNF package uses the signature and certificate to ensure package integrity and validity. A CSAR file is digitally signed with the VNF provider private key. During the VNF package onboarding to SDC, SDC validates the package and then does the following:

    • Transform SOL001-based VNFD into SDC internal models
    • Store the original Vendor package into the ETSI_PACKAGE directory
      • If the original vendor package is a zip file with signature and certificate, the ETSI_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.


    SOL001 Mapping to SDC AID DM

    The following diagram depicts SOL001 Mapping to SDC AID DM.

    Gliffy Diagram
    macroIdc3089f5b-d8cc-4e90-8303-ad2808852d65
    nameSOL001 Mapping to SDC AID DM - Guilin
    pagePin4


    Current Mapping Support (as of Frankfurt)


    Image Added

    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

    View file
    nameSDCEnhancementMapping-2020-9-4.pptx
    height250

    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 View filenameSDCEnhancementMapping-2020-8-17.pptxheight250

    Mapping of ETSI Information NS-related Elements with TOSCA types

    ...

    • 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
    size1200
    nameONAP ETSI-Alignment Models
    pagePin4

    ...

    SOL001 Data ModelSDC AID DMCommentsRelease
    N/Aorg.openecomp.resource.abstracts.nodes.servicerepresents OSS Service models
    tosca.nodes.nfv.NStosca.nodes.nfv.NSNS; use of SOL001 as SDC AID DM NSGuilin
    tosca.nodes.nfv.NsVirtualLinktosca.nodes.nfv.NsVirtualLinkNS VirtualLink; use of SOL001 as SDC AID DM VLGuilin
    tosca.nodes.nfv.Vnforg.openecomp.resource.abstract.nodes.ETSI.VNFVNFPlan for Honolulu
    tosca.nodes.nfv.vduorg.openecomp.resource.abstract.nodes.ETSI.VFCVDU and SDC VFCPlan for Honolulu
    tosca.nodes.nfv.VirtualLinkorg.openecomp.resources.vlVNF VLPlan for Honolulu
    tosca.nodes.nfv.VduCporg.openecomp.resources.cpVDU CPPlan for Honolulu
    N/Aorg.openecomp.resource.allottedResourceallotted resource; could not find any from SOL001
    tosca.nodes.nfv.Pnforg.openecomp.resource.abstract.nodes.ETSI.PNFPNFPlan for Honolulu (PNF support is under discussion for Honolulu


    Current SDC Resource Models

    ...

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

    namerequiredtype
    		namerequiredtype
    <SOL001 tosca.nodes.nfv.VNF attributes >


    		<SOL001 tosca.nodes.nfv.VNF attributes >

    descriptor_idyesstring<-->descriptor_idyesstring
    descriptor_versionyesstring<-->descriptor_versionyesstring
    provideryesstring<-->provideryesstring
    product_nameyesstring<-->product_nameyesstring
    software_versionyesstring<-->software_versionyesstring
    product_info_nameno string<-->product_info_nameno string
    vnfm_infoyeslist of string<-->vnfm_infoyeslist of string
    localization_languagesnolist of string<-->localization_languagesnolist of string
    default_localization_languageno string<-->default_localization_languageno string
    configurable_propertiesnotosca.datatypes.nfv.VnfconfigurableProperties<-->configurable_propertiesnotosca.datatypes.nfv.VnfconfigurableProperties
    modifiable_attributesnotosca.datatypes.nfv.VnfInfoModifiableAttributes<-->modifiable_attributesnotosca.datatypes.nfv.VnfInfoModifiableAttributes
    lcm_operations_configurationnotosca.datatypes.nfv.VnfLcmOperationsConfiguration<-->lcm_operations_configurationnotosca.datatypes.nfv.VnfLcmOperationsConfiguration
    monitoring_parametersnolist of tosca.datatypes.nfv.VnfMonitoringParameter<-->monitoring_parametersnolist of tosca.datatypes.nfv.VnfMonitoringParameter
    flavour_idyesstring<-->flavour_idyesstring
    flavour_descriptionyesstring<-->flavour_descriptionyesstring
    vnf_profilenotosca.datatypes.nfv.VnfProfile<-->vnf_profilenotosca.datatypes.nfv.VnfProfile




    		<SDC AID DM VF attributes that are inherited from org.openecomp.resource.abstract.nodes.VF>

    <the followings are being considered>


    		nf_functionnostring
    requirementsYes

    		nf_rolenostring
    interfacesyestosca.interfaces.nfv.VnfLcm
    		nf_typenostring




    		nf_naming_codenostring




    		nf_namingnoorg.openecomp.datatypes.Naming




    		availability_zone_max_countnointeger




    		min_instancesnointeger




    		max_instancesnointeger




    		multi_stage_designnoboolean




    		sdnc_model_namenostring




    		sdnc_artifact_namenostring




    		skip_post_instantiation_configurationno

    boolean (default true)

    • constraints: true, false




    		controller_actorno

    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.VNF that is inherited from SOL001 VNF (tosca.nodes.nfv.VNF)

    namerequiredtype
    <SOL001 tosca.nodes.nfv.VNF attributes >

    descriptor_idyesstring
    descriptor_versionyesstring
    provideryesstring
    product_nameyesstring
    software_versionyesstring
    product_info_nameno string
    vnfm_infoyeslist of string
    localization_languagesnolist of string
    default_localization_languageno string
    configurable_propertiesnotosca.datatypes.nfv.VnfconfigurableProperties
    modifiable_attributesnotosca.datatypes.nfv.VnfInfoModifiableAttributes
    lcm_operations_configuraionnotosca.datatypes.nfv.VnfLcmOperationsConfiguration
    monitoring_parametersnolist of tosca.dataypes.nfv.VnfMonitoringParameter
    flavour_idyesstring
    flavour_descriptionyesstring
    vnf_profilenotosca.datatyhpes.nfv.VnfProfile
    additionalAttriubtes (or nonManoAttributes)nomap of key, value pair


    SOL001 VDU mapping to/from VNF SDC AID DM VFC

    ...

    • 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.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 VNFD
    		SDC AID DM VFD
    NameGrammar
    		NameGrammar
    tosca_definitions_version

    string

    (tosca_simple_yaml_1_2)


    		tosca_definitions_version

    string

    (tosca_simple_yaml_1_2)

    descriptionstring
    		descriptionstring
    metadatamap of <string>
    		metadatamap 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>

    		importsIdentifies 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

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






    ...

        • 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
    macroId4e072032-7cad-4d7d-befc-a60416101d10
    nameONAP ETSI-Alignment VF-Module Mapping
    pagePin7

    ...