Page History

...

Feature

Description

SDC ETSI Package Management

SOL004 VNF/PNF Package includes SOL001 VNFD/PNFD with the original vendor package will be onboarded into SDC and distributed from SDC to SVNFM/External NFVO.
SOL007 NS Package includes SOL001 NSD with the original vendor package will be onboarded into SDC and distributed from SDC to SVNFM/External NFVO.
SDC supports design of ETSI SOL007 compliant NSD packages and distribute them to SVNFM/External NFVO
SDC supports Nested/Hierarchical ETSI SOL001 v2.7.1 NSD onboarding and distribution to ONAP runtime components.

ETSI Package Security

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

SOL004 VNF/PNF Package security is supported by the package signature and certificate
SOL007 NS Package security is supported by the package signature and certificate
SDC will store the vendor package with signature and certificate in a zip format in the ONBOARDEDETSI_PACKAGE directory
ETSI Catalog Manager stores the vendor package zip files from the ONBOARDEDETSI_PACKAGE directory
SVNFM/NFVO extracts the vendor package zip/CSAR files with package validation

ETSI Package Validation

VNF SDK will support SOL004 VNF package pre-onboarding for validation - optional
VNF SDK will support SOL007 NS package pre-onboarding for validation - optional

...

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 ONBOARDED_PACKAGE directory.
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 ONBOARDED_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

Maintenance

Support 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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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)

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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2617

Support for editing ETSI v2.7.1 SOL001 VNF Descriptor

Support for editing ETSI v2.7.1 SOL001 VNF Descriptor

Yes

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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

TBD

Support 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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2610

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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2611

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

No

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2617

Support for editing ETSI v2.7.1 SOL001 VNF Descriptor

Support for editing ETSI v2.7.1 SOL001 VNF Descriptor

No

Yes

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2806

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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-26182881

Support for

deploying a service that contains an ETSI SOL001

using an ETSI v2.7.1

compliant Network Service using VF-C as the NFVO

VNF in an ONAP Service

Support for

deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service

using

VF-C as the NFVO

No

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

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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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~~

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.

Yes

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2802

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

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

~~Wrap the NS package in the Service for an external NFVO~~

~~Yes~~

Close this, expect the current SDC distribution is sufficient

Support for Nested/Hierarchical ETSI SOL001 v2.7.1 compliant Network Service Descriptor Executive Summary - Onboard an ETSI & 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

Yes

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2808

Support for mapping of ETSI v2 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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2618

Support design of Service templates, leveraging NSDs

No

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2882

Change the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directory

YesNo

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2811

Onboard ETSI SOL004 compliant PNF packages

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

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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-28052803

Support for onboarding of the

SOL007 v2.7.1

compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service

Support for onboarding of the SOL007

Yes

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2837

Support for mapping of ETSI v2.7.1 SOL001 PNF Descriptor into SDC AID Data ModelSOL001 PNFD 2.7.1 Mapping to SDC AID DMcompliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP ServiceNoYes

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2836

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

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2882

Support design of Service templates, includingNSDsSupport design of Service templates, including NSDsYes

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2883

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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-28132805

SDC

Notification

supports 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

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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 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

Yes

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-28142836

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

SDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI 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

No

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-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, filtering for artifact type = ONBOARDED_ETSI_PACKAGE
for non-ETSI TOSCA package, filtering for artifact type = ONBOARDED_ONAP_PACKAGE

YesNo

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-28152814

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

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2815

Support ETSI Package Security and validation
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

YesNo

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2613

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

YesNo

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	SDC-2614

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

VNF 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

...

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.

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
If the file is .csar, it is a package without security.
Next, SDC will check the TOSCA.meta file.
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.
Otherwise, it will be handled as existing TOSCA (non-SOL004) package onboarding which will not have the ONBOARDEDETSI_PACKAGE artifact.

NS Onboarding Design

...

SOL004 VNF/PNF and SOL007 NS Packages are onboarded to SDC.
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.
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.

...

Gliffy Diagram

macroId	c3089f5b-d8cc-4e90-8303-ad2808852d65
name	SOL001 Mapping to SDC AID DM - Guilin
pagePin	24

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 (OSS Service-Level) model references/includes associated NSs
- For the E2E service level, the org.openecop.resource.abstract.nodes.service type is still used as the base type of the service. SDC will use the ETSI SOL001 NSD type and attach the NSDs 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).

Gliffy Diagram

size	1200
name	ONAP ETSI-Alignment Models
pagePin	2

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

View file

name	SDCEnhancementMapping-2020-9-4.pptx
height	250

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

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	org.openecomp.resource.abstracts.nodes.service	represents OSS Service models
tosca.nodes.nfv.NS	tosca.nodes.nfv.NS	NS; use of SOL001 as SDC AID DM NS	Guilin

...

SDC: nfv-typesSDC: heat-typesETSI NFV IESDC Descriptor / SOL001TOSCA TypeDerived fromSDC DescriptorTOSCA TypeDerived fromNSDnodes.yml / SOL001tosca.nodes.nfv.NStosca.nodes.RootGeneric_Service.yml

org.openecomp.resource.abstract.nodes.service

(use it for both E2E (OSS Service) and NS)

tosca.nodes.RootNSD.ymlorg.openecomp.resource.vfc.NSDtosca.nodes.RootN/ASapDSOL001tosca.nodes.nfv.Saptosca.nodes.RootNsVirtualLinkDescSOL001

tosca.nodes.nfv.NsVirtualLink

(there is

tosca.nodes.nfv.

VnfVirtualLink)

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

Rootvl

nfv.

yml

Vnf	org.openecomp.resource.

vl.VLtosca

abstract.nodes.

network

ETSI.

Network

VNF

extVl.yml

VNF	Plan for Honolulu

org.openecomp.resource.vl.extVL

tosca.nodes.

RootinternalVl

nfv.

yml

vdu	org.openecomp.resource.

vl.internalVLtosca

abstract.nodes.

network.NetworkextZteVL.yml

ETSI.VFC	VDU and SDC VFC	Plan for Honolulu
tosca.nodes.nfv.VirtualLink	org.

ext

openecomp.

zte

resources.vl

VNF VL

tosca.nodes.RootPnfd

Plan for Honolulu

tosca.nodes.nfv.

PNF

VduCp

tosca

org.openecomp.

nodes

resources.

RootGeneric_PNF.yml

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

Vnffgd

ETSI NFV IE	SDC Descriptor / SOL001	TOSCA Type	Derived from	SDC Descriptor	TOSCA Type	Derived from
SDC: nfv-types				SDC: heat-types
NSD	nodes.yml / SOL001	tosca.nodes.Root	Vnfd	VNF.yml	tosca.nodes.nfv.VNFNS	tosca.nodes.Root	Generic_VFService.yml	org.openecomp.resource.abstract.nodes. VF service (use it for both E2E (OSS Service) and NS)	tosca.nodes.Root
NSD	NSD.yml	org.openecomp.resource.vfc.NSD	tosca.nodes.Root	N/A
SapD	SOL001		tosca.groupsnodes.nfv.VNFFGSap	tosca.groupsnodes.Root
NsVirtualLinkDesc	SOL001	tosca.nodes.nfv.NsVirtualLink (there is tosca.nodes.nfv.VnfVirtualLink)	tosca.nodes.Root	vl.ymlforwardingPath.yml(?)	org.openecomp.resource.vl.VL	tosca.nodes.network.Network
				extVl.yml	org.openecomp.resource.vl.extVL.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

...


			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

...

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.

...

SDC generates SOL001 tosca.nodes.nfv.NSD node type, and uses it as SDC AID DM.

.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

SOL001 NS

...

SDC NSD

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

...

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 hte 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 (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

...

string (default: SO-REF-DATA)

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

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

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)~~
~~name~~	~~required~~	~~type~~
~~<SOL001 tosca.nodes.nfv.VNF attributes >~~
~~descriptor_id~~	~~yes~~	~~string~~
~~descriptor_version~~	~~yes~~	~~string~~
~~provider~~	~~yes~~	~~string~~
~~product_name~~	~~yes~~	~~string~~
~~software_version~~	~~yes~~	~~string~~
~~product_info_name~~	no	~~string~~
~~vnfm_info~~	~~yes~~	~~list of string~~
~~localization_languages~~	no	~~list of string~~
~~default_localization_language~~	no	~~string~~
~~configurable_properties~~	no	~~tosca.datatypes.nfv.VnfconfigurableProperties~~
~~modifiable_attributes~~	no	~~tosca.datatypes.nfv.VnfInfoModifiableAttributes~~
~~lcm_operations_configuraion~~	no	~~tosca.datatypes.nfv.VnfLcmOperationsConfiguration~~
~~monitoring_parameters~~	no	~~list of tosca.dataypes.nfv.VnfMonitoringParameter~~
~~flavour_id~~	~~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

...

SOL001 VDU			SDC AID DM VFC (org.openecomp.resource.abstract.nodes.VFC)
Name	Required	Type	Name	Required	Type
name	yes	string	nfc_function		string
description	yes	string	high_availability	no	string
boot_order	no	boolean	vm_image_name		string
nfvi_constraints_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 stringtosca.datatypes.nfv.VnfcConfigurableProperties	vm_flavortype_nametag	yesno	string
monitoringboot_parametersdata	no	list of tosca.datatypes.nfv.VnfcMonitoringParameterBootData	nfc_naming_code	no	string			org.openecomp.datatypes.Naming ONAP_generated_naming: yes: boolean naming_policy: no: string instance_name: no: string
vdu_profile	yes	configurable_properties	no	map of tosca.datatypes.nfv.VnfcConfigurablePropertiesVduProfile	vmmin_type_taginstances	no	stringinteger
bootsw_image_data	no	tosca.datatypes.nfv.BootData	nfc_naming	org.openecomp.datatypes.Naming ONAP_generated_naming: yes: boolean naming_policy: no: string instance_name: no: string
vdu_profile	yes	tosca.datatypes.nfv.VduProfile	min_instances	no	integer
sw_image_data	no	tosca.datatypes.nfv.SwImageData

Solutions for VDU and VFC mapping

	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
Make the org.openecomp.resource.abstract.nodes.ETSI.VFC a superset of both tosca.nodes.nfv.Vdu and org.openecomp.resource.abstract.node.VFC

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	yesno	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 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_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 for each VF Module, additional information is provided	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>

...

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

...

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

...

Space shortcuts

Page tree

Versions Compared

Old Version 126

New Version Current

Key

NS Onboarding Design

Current Mapping Support (as of Frankfurt)

Mapping of ETSI Information NS-related Elements with TOSCA types

ONAP ETSI-Alignment Modeling Hierarchy

Mapping between SOL001 Data Model and SDC AID DM

Presentation Slide (as a summary)

SOL007 Design and SOL004 Onboarding

SDC CSAR for NS structure

Mapping of ETSI Information NS-related Elements with TOSCA types

ONAP ETSI-Alignment Modeling Hierarchy

Mapping between SOL001 Data Model and SDC AID DM

Current SDC Resource Models

NSD Mapping to SDC AID DM

Initial Input

NSD Mapping to SDC AID DM

SOL001 NSD mapping to/from NS SDC AID DM

NSD Mapping to SDC AID DM

Initial Input

NSD Mapping to SDC AID DM

SOL001 NSD mapping to/from NS SDC AID DM

SOL001 NS

SOL001 NS

Current VNF Modeling in ETSI and SDC

Solutions:

Option A (chosen):

Option B:

Current SOL001 VDU vs. SDC AID DM VFC

Solutions for VDU and VFC mapping

Solutions for VDU and VFC mapping

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

Solution:

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

VirtualLink Mapping to SDC AID DM

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 126

New Version Current

Key

NS Onboarding Design

Current Mapping Support (as of Frankfurt)

Mapping of ETSI Information NS-related Elements with TOSCA types

ONAP ETSI-Alignment Modeling Hierarchy

Mapping between SOL001 Data Model and SDC AID DM

Presentation Slide (as a summary)

SOL007 Design and SOL004 Onboarding

SDC CSAR for NS structure

Mapping of ETSI Information NS-related Elements with TOSCA types

ONAP ETSI-Alignment Modeling Hierarchy

Mapping between SOL001 Data Model and SDC AID DM

Current SDC Resource Models

NSD Mapping to SDC AID DM

Initial Input

NSD Mapping to SDC AID DM

SOL001 NSD mapping to/from NS SDC AID DM

NSD Mapping to SDC AID DM

Initial Input

NSD Mapping to SDC AID DM

SOL001 NSD mapping to/from NS SDC AID DM

SOL001 NS

SOL001 NS

Current VNF Modeling in ETSI and SDC

Solutions:

Option A (chosen):

Option B:

Current SOL001 VDU vs. SDC AID DM VFC

Solutions for VDU and VFC mapping

Solutions for VDU and VFC mapping

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

Solution:

Gliffy DiagrammacroId4e072032-7cad-4d7d-befc-a60416101d10nameONAP ETSI-Alignment VF-Module MappingpagePin7

VirtualLink Mapping to SDC AID DM

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