Page History

Package Management Diagram

The following diagram depicts ONAP ETSI Package Management.

Requirements & Use Cases

...

Onboard ETSI SOL004 compliant VNF packages
- Support for onboarding ETSI v2v3.73.1 SOL004 CSAR Packages (Link to ETSI SOL004 v2v3.73.1 )
- Support for onboarding ETSI v2v3.73.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2v3.73.1)
- Support for mapping of ETSI v2v3.73.1 SOL001 VNF Descriptor into SDC AID Data Model
- Support for using an ETSI v2v3.73.1 VNF in an ONAP Service
Onboard ETSI SOL007 compliant Network Service Descriptor packages (stretch goal for Guilin)packages
- Support for Cataloging and Preserving the original SOL007 package
- Support for mapping of ETSI v2v3.73.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model
- Support for deploying a service that contains an ETSI SOL001 v2v3.73.1 compliant Network Service using VF-C as the NFVO
- Support for deploying a service that contains an ETSI SOL001 v2v3.73.1 compliant Network Service using an external NFVO
Design ETSI SOL007 compliant Network Service Descriptor packages
- Support for deploying a service that contains an ETSI SOL001 v2v3.73.1 compliant Network Service using VF-C as the NFVO
- Support for deploying a service that contains an ETSI SOL001 v2v3.73.1 compliant Network Service using an external NFVO
Support for Nested/Hierarchical ETSI SOL001 v2v3.73.1 Network Service Descriptor (not for Guilin)
Design Service templates, leveraging NSDs
- Support Service templates including NSDs

Feature Descriptions

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

v3.

7

3.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 ETSI_PACKAGE directory
ETSI Catalog Manager stores the vendor package zip files from the ETSI_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

Epic and User Story

- optional

Epic and User Story

Epic	User Story	Description	Honolulu Plan?	JIRA

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

Yes JiraserverONAP JIRAserverId425b2b0a-557c-3c0c-b515-579789cceedbkeySDC-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

Yes

Jira

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

Support for onboarding ETSI

v2

v3.

7

3.1 SOL001 VNF Descriptor (Link to ETSI SOL001

v2

v3.

7

3.1)	Support for onboarding ETSI

v2

v3.

7

3.1 SOL001 VNF Descriptor (Link to ETSI SOL001

v2

v3.

7

3.1)

Support SDC AID DM VF descriptor (see the

79200568

ETSI Package Management (SDC Enhancements)- Guilin#SOL0013.3.1VNFDMappingfrom/toSDCAIDDMVNFD section)

No

Yes

Jira

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

Support for mapping of ETSI

v2

v3.

7

3.1 SOL001 VNF Descriptor into SDC AID Data Model

Support for mapping of ETSI

v2

v3.

7

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

Yes

Jira

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

Support for editing ETSI

v2

v3.

7

3.1 SOL001 VNF Descriptor

Support for editing ETSI

v2

v3.

7

3.1 SOL001 VNF Descriptor

No

Yes

Jira

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

Support for using an ETSI

v2

v3.

7

3.1 VNF in an ONAP Service

Support for using an ETSI

v2

v3.

7

3.1 VNF in an ONAP Service		TBD
Onboard ETSI SOL007 compliant Network Service Descriptor packages		Executive Summary - Onboard an ETSI SOL007

v2

v3.

7

3.1 compliant (Link to ETSI SOL007

v2

v3.

7

3.1) Network Service Descriptor package including an ETSI version

2

3.

7

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

v3.

7

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

v3.

7

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

v2

v3.

7

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

No

Yes

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

v3.

7

3.1)

No

Yes

Jira

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

Design ETSI SOL007 compliant Network Service Descriptor & packages

Executive Summary - Design, catalog and distribute an ETSI SOL007

v2

v3.

7

3.1 compliant (Link to ETSI SOL007

v2

v3.

7

3.1) Network Service Descriptor package including an ETSI version

2

3.

7

3.1 SOL001 Network Service Descriptor (NSD) for deployment using an ETSI compliant NFVO.

Support for deploying a service that contains an ETSI SOL001

v2

v3.

7

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

v2

v3.

7

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

Yes

(enhancements)

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

v2

v3.

7

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

Yes

(enhancement)

Jira

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

Support for mapping of ETSI

v2

v3.

7

3.1 SOL001 Network Service Descriptor 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

(enhancement)

Jira

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

Support design of Service templates, leveraging NSDs

No

Yes

Jira

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

Change the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directory

Yes

(enhancement)

Jira

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

Support for Nested/Hierarchical ETSI SOL001

v2

v3.

7

3.1 Network Service Descriptor

Executive Summary - Onboard an ETSI SOL007

v2

v3.

7

3.1 compliant (Link to ETSI SOL007

v2

v3.

7

3.1) Network Service Descriptor package including an ETSI version

2

3.

7

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

No

Yes

Jira

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

Support for onboarding of the SOL007

v2

v3.

7

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

Support for onboarding of the SOL007

v2

v3.

7

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

No

Yes

Jira

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

No

Yes

Jira

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

SDC 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

v3.

7

3.1
Update onboarding procedure for

v2

v3.

7

3.1

No

Yes

Jira

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

Support for mapping of ETSI

v2

v3.

7

3.1 SOL001 PNF Descriptor into SDC AID Data Model

SOL001 PNFD

2

3.

7

3.1 Mapping to SDC AID DM

No

Yes

Jira

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

Support 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

No

Yes

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, artifact type = ONBOARDED_ETSI_PACKAGE
for non-ETSI TOSCA package, artifact type = ONBOARDED_ONAP_PACKAGE

No

Yes

Jira

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

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

Yes

Jira

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

No

Yes

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

No

Yes

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 NS

TBD

VNF SDK will support ETSI VNF package pre-onboarding for validation

TBD

VNF SDK will support ETSI NS package pre-onboarding for validation

TBD

ETSI Package Management Architecture

...

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, v2v3.73.1 will be supported.
Otherwise, it will be handled as existing TOSCA (non-SOL004) package onboarding which will not have the ETSI_PACKAGE artifact.

...

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 23.73.1 handling will be discussed separately.

...

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
tosca.nodes.nfv.NsVirtualLink	tosca.nodes.nfv.NsVirtualLink	NS VirtualLink; use of SOL001 as SDC AID DM VL	Guilin
tosca.nodes.nfv.Vnf	org.openecomp.resource.abstract.nodes.ETSI.VNF	VNF	Plan for Honolulu
tosca.nodes.nfv.vdu	org.openecomp.resource.abstract.nodes.ETSI.VFC	VDU and SDC VFC	Plan for Honolulu
tosca.nodes.nfv.VirtualLink	org.openecomp.resources.vl	VNF VL	Plan for Honolulu
tosca.nodes.nfv.VduCp	org.openecomp.resources.cp	VDU CP	Plan for Honolulu
N/A	org.openecomp.resource.allottedResource	allotted resource; could not find any from SOL001
tosca.nodes.nfv.Pnf	org.openecomp.resource.abstract.nodes.ETSI.PNF	PNF	Plan for Honolulu (PNF support is under discussion for Honolulu

Current SDC Resource Models

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.nfv.NS	tosca.nodes.Root	Generic_Service.yml	org.openecomp.resource.abstract.nodes.service (use it for both E2E (OSS Service) and NS)	tosca.nodes.Root
NSD	NSD.yml	org.openecomp.resource.vfc.NSD	tosca.nodes.Root	N/A
SapD	SOL001	tosca.nodes.nfv.Sap	tosca.nodes.Root
NsVirtualLinkDesc	SOL001	tosca.nodes.nfv.NsVirtualLink (there is tosca.nodes.nfv.VnfVirtualLink)	tosca.nodes.Root	vl.yml	org.openecomp.resource.vl.VL	tosca.nodes.network.Network
				extVl.yml	org.openecomp.resource.vl.extVL	tosca.nodes.Root
				internalVl.yml	org.openecomp.resource.vl.internalVL	tosca.nodes.network.Network
	extZteVL.yml	tosca.nodes.nfv.ext.zte.VL	tosca.nodes.Root
Pnfd		tosca.nodes.nfv.PNF	tosca.nodes.Root	Generic_PNF.yml	org.openecomp.resource.abstract.nodes.PNF	tosca.nodes.Root
Vnfd	VNF.yml	tosca.nodes.nfv.VNF	tosca.nodes.Root	Generic_VF.yml	org.openecomp.resource.abstract.nodes.VF	tosca.nodes.Root
Vnffgd		tosca.groups.nfv.VNFFG	tosca.groups.Root	forwardingPath.yml(?)	org.openecomp.nodes.ForwardingPath	tosca.nodes.Root

NSD Mapping to SDC AID DM

...

ONAP previous analysis
- The SDC NSD node type, org.openecom.resource.vfc.NSD, is modeled as a component of a VF to represent an allotted resource. But, it is not derived from the org.openecomp.resource.vfc.AllottedResource, either.
- The SDC NSD might be designed for Volte use case support, and used by the VFC.
- It is recommended to deprecate the current SDC NSD node type, and to replace with SOL001 tosca.nodes.nfv.NS node type.
Solutions
- SDC generates SOL001 tosca.nodes.nfv.NS node type
- SDC takes SOL001 NSD with tosca.nodes.nfv.NS node type as is, without mapping; i.e., no mapping is necessary
- ONAP SO NFVO uses the SOL001 NSD
- VFC needs to use the SOL001 NSD
- There could be some impact on VID and ONAP SO Catalog DB for the SOL001 NSD - to be analyzed.
Guilin Decisions
- SDC generates SOL001 tosca.nodes.nfv.NSD node type, and uses it as SDC AID DM.

SOL001 NS

SOL001 NS (tosca.nodes.nfv.NS) - Chosen			~~SDC NSD~~ ~~org.openecomp.resource.vfc.NSD~~
name	required	type	~~name~~	~~required~~	~~type~~
descriptor_id	yes	string	~~nsd_id~~	~~true~~	~~string~~
designer	yes	string	~~nsd_designer~~	~~true~~	~~string~~
version	yes	string	~~nsd_version~~	~~true~~	~~string~~
name	yes	string	~~nsd_name~~	~~true~~	~~string~~
invariant_id	yes	string	~~providing_service_uuid~~	~~true~~	~~string~~
flavor_id	yes	string	~~providing_service_invariant_uuid~~	~~true~~	~~string~~
ns_profile	no	tosca.datatypes.nfv.NsProfile	~~providing_service_name~~	~~true~~	~~string~~

<tosca.datatypes.nfv.NsProfile>

...

Current VNF Modeling in ETSI and SDC

SOL001 VNF (tosca.nodes.nfv.VNF) from SOL001

v2

v3.

7

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

...

Make the org.openecomp.resource.abstract.nodes.ETSI.VNF a superset of both tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.node.VF
During VNF onboarding, SDC copies SOL001 VNF attribute contents to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VNF
- In Guilin, SO NFVO, VFC and SVNFM get those SOL001 VNF attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Guilin.
SOL001 VNF attributes in SDC AID DM VNF will be visible to SDC UI, so SDC UI can change the attributes.
- But the onboarded vendor ETSI package will note be changed by the SDC UI users in Guilin.
- Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Guilin;
- For the Honolulu release, it is under consideration
  - to sync up between those modified SOL001 VNF attributes and the vendor ETSI Package attributes
  - to reflect those modified SOL001 VNF attributes in the orchestration
ONAP specific attributes that are inherited from the org.openecomp.resource.abstract.nodes.VF will be filled up by SDC (design time)
- Those attribute contents will not be mapped back into the SOL001 VNF (reverse mapping). For that case, only the SOL001 VNF corresponding attributes will be copied

SOL001 VNF (tosca.nodes.nfv.VNF)			Mapping	New SDC AID DM VNF (org.openecomp.resource.abstract.nodes.ETSI.VNF) derived from org.openecomp.resource.abstract.nodes.VF
name	required	type		name	required	type
<SOL001 tosca.nodes.nfv.VNF attributes >				<SOL001 tosca.nodes.nfv.VNF attributes >
descriptor_id	yes	string	<-->	descriptor_id	yes	string
descriptor_version	yes	string	<-->	descriptor_version	yes	string
provider	yes	string	<-->	provider	yes	string
product_name	yes	string	<-->	product_name	yes	string
software_version	yes	string	<-->	software_version	yes	string
product_info_name	no	string	<-->	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_id	yes	string	<-->	flavour_id	yes	string
flavour_description	yes	string	<-->	flavour_description	yes	string
vnf_profile	no	tosca.datatypes.nfv.VnfProfile	<-->	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

...

no 1:1 mapping
note: the SDC AID DM VFC represents design-time VFC (like VDU), not VFC instances in runtime

SOL001 VDU			SDC AID DM VFC (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	no	map of string	vm_flavor_name	yes	string
monitoring_parameters	no	list of tosca.datatypes.nfv.VnfcMonitoringParameter	nfc_naming_code	no	string
configurable_properties	no	map of tosca.datatypes.nfv.VnfcConfigurableProperties	vm_type_tag	no	string
boot_data	no	tosca.datatypes.nfv.BootData	nfc_naming		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

...

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

SOL001 VDU			Mapping	org.openecomp.resource.abstract.nodes.ETSI.VFC (derived from org.openecomp.resource.abstract.nodes.VFC)
Name	Required	Type	<-->	Name	Required	Type
name	yes	string	<-->	name	yes	string
description	yes	string	<-->	description	yes	string
boot_order	no	boolean	<-->	boot_order	no	boolean
nfvi_constraints	no	map of string	<-->	nfvi_constraints	no	map of string
monitoring_parameters	no	list of tosca.datatypes.nfv.VnfcMonitoringParameter	<-->	monitoring_parameters	no	list of tosca.datatypes.nfv.VnfcMonitoringParameter
configurable_properties	no	map of tosca.datatypes.nfv.VnfcConfigurableProperties	<-->	configurable_properties	no	map of tosca.datatypes.nfv.VnfcConfigurableProperties
boot_data	no	tosca.datatypes.nfv.BootData	<-->	boot_data	no	tosca.datatypes.nfv.BootData
vdu_profile	yes	tosca.datatypes.nfv.VduProfile	<-->	vdu_profile	yes	tosca.datatypes.nfv.VduProfile
sw_image_data	no	tosca.datatypes.nfv.SwImageData	<-->	sw_image_data	no	tosca.datatypes.nfv.SwImageData
				<SDC AID DM VFC attributes that are inherited from the org.openecomp.resource.abstract.nodes.VFC>
				nfc_function	no	string
				high_availability	no	string
				vm_image_name	no	string
				vm_flavor_name	no	string
				nfc_naming_code	no	string
				vm_type_tag	no	string
				nfc_naming	no	org.openecomp.datatypes.Naming ONAP_generated_naming: yes: boolean naming_policy: no: string instance_name: no: string
				min_instances	no	integer

SOL001

...

3.

...

3.1 VNFD Mapping from/to SDC AID DM VNFD

SOL001

...

3.

...

3.1 VNFD Template

tosca_definitions_version: tosca_simple_yaml_1_23

description:

imports:

data_types:

...

SOL001 VNFD mapping to/from SDC AID DM VFD

SOL001 VNFD

SDC AID DM VFD

Name

Grammar

Name

Grammar

tosca_definitions_version

string

(tosca_simple_yaml_1_

2

3)

tosca_definitions_version

string

(tosca_simple_yaml_1_

2

3)
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	optional list of policies
substitution_mappings		substitution_mappings
node_type		node_type
capabilities	<capability_type_name>: derived_from: <parent_capability_type_name> version: <version_number> description: <capability_description> properties: <property_definitions> attributes: <attribute_definitions> valid_source_types: [ <node type_names> ]	capabilities	<capability_type_name>: derived_from: <parent_capability_type_name> version: <version_number> description: <capability_description> properties: <property_definitions> attributes: <attribute_definitions> valid_source_types: [ <node type_names> ]
requirements		requirements
group	not defined	group	<group_type_name>: derived_from: <parent_group_type_name> version: <version_number> metadata: <map of string> description: <group_description> properties: <property_definitions> members: [ <list_of_valid_member_types> ] requirements: - <requirement_definitions> capabilities:
policy	only the Abstract.SecurityGroupRule policy type is defined not sure if we can map this into SDC AID DM	policy	<policy_type_name>: derived_from: <parent_policy_type_name> version: <version_number> metadata: <map of string> description: <policy_description> properties: <property_definitions> targets: [ <list_of_valid_target_types> ] triggers: <list_of_trigger_definitions>
relationship	tosca.relationships.nfv.VirtualBindsTo tosca.relationships.nfv.AttachesTo	relationship	<relationship_type_name>: derived_from: <parent_relationship_type_name> version: <version_number> metadata: <map of string> description: <relationship_description> properties: <property_definitions> attributes: <attribute_definitions> interfaces: <interface_definitions> valid_target_types: [ <capability_type_names> ]
		annotation_type	<annotation_type_name>: version: <version_number> description: <annotation_type_description> properties: <property_definitions>
		annotation	<annotation_name>: type: <annotation_type> properties: <property_assignments>

VF-Module Initial Input

The following is a summary of initial input from Gil Bullard (AT&T).

...

org.openecomp.group.VfModule Attribute and SOL001 VNF Policies deduction

Name	Required	Type	SOL001 VNFD Policies
vf_module_type	yes	string valid values: Base, Expansion	Base default: Base
vf_module_label	yes	string	aspects: <A>
min_vf_module_instances	yes	integer	initial_delta: 0
max_vf_module_instances	no	integer	max_scale_level
initial_count	yes	integer	initial_data: number_of_instances
vf_module_description	no	string	aspects: description
volume_group	yes	Boolean	default to false
group_naming	no	org.openecomp.datatypes.Naming	optional field, leave it empty

VirtualLink Mapping to SDC AID DM

...

<tosca.nodes.nfv.ext.zte.VL>

tosca.nodes.nfv.ext.zte.VL
name	required	type
segmentation_id	false	string
network_name	false	string
is_predefined	false	boolean
mtu	false	integer
dns_nameservers	false	list
physical_network	false	string
dhcp_enabled	false	boolean
network_id	false	string
host_routes	false	list
ip_version	false	integer
vendor	false	string
name	false	string
start_ip	false	string
vlan_transparent	false	boolean
cidr	false	string
gateway_ip	false	string
network_type	false	string
end_ip	false	string
location_info	false	tosca.datatypes.nfv.ext.LocationInfo

tosca.nodes.nfv.ext.zte.VL:

...

Space shortcuts

Page tree

Versions Compared

Old Version 9

New Version 10

Key

Package Management Diagram

Table of Contents

Requirements & Use Cases

Feature Descriptions

Epic and User Story

Epic and User Story

ETSI Package Management Architecture

Current SDC Resource Models

NSD Mapping to SDC AID DM

SOL001 NS

Current VNF Modeling in ETSI and SDC

Solutions:

Option B:

Solutions for VDU and VFC mapping

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

SOL001

3.

3.1 VNFD Mapping from/to SDC AID DM VNFD

SOL001

3.

3.1 VNFD Template

SOL001 VNFD mapping to/from SDC AID DM VFD

VF-Module Initial Input

org.openecomp.group.VfModule Attribute and SOL001 VNF Policies deduction

VirtualLink Mapping to SDC AID DM