Page History

...

Epic

User Story

Task

Description

Honolulu Plan?

JIRA

Size

(S/M/L/XL)

Priority

Support Onboard ETSI 3.3.1 SOL004 compliant VNF / CNF packages

Executive Summary- Enable a vendor provided ETSI SOL004 v3.3.1 compliant VNF package including an ETSI SOL001 VNF / CNF Descriptor to  be onboarded into ONAP for composition into an ONAP Network ServiceSupport for onboarding ETSI v3.3.1SOL004 VNF CSAR Packages with minimum CNF enhancements from 4.1.1
Support for onboarding ETSI v3.3.1 SOL001 VNF Descriptor with minimum CNF enhancements from 4.1.1
Support for mapping of ETSI v3.3.1 SOL001 VNF Descriptor with CNF enhancements into SDC AID Data Model
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

4 weeks for one designer

High

Support for onboarding ETSI v3.3.1 SOL004 VNF CSAR Packages with minimum CNF enhancements from 4.1.1

SDC users need to onboard ETSI v3.3.1 SOL004 VNF CSAR Packages with minimum CNF enhancements from 4.1.1
- Manifest File (e.g., MainServiceTemplate.mf): a new non-MANO artifact set identifier "onap_cnf_helm" - This would identify the "top-level" helm chart that can be used to deploy the CNF directly, i.e., without utilizing the LCM info the VNF Descriptor
  - e.g., onap_cnf_helm:

source: Artifacts/helm/helm_charts.yaml

note: to support the direct path, the VNFD could be optional (under discussion with ETSI NFV and ONAP Direct Path team)

SDC users should be also able to onboard the existing ETSI v2.6.1 SOL004 CSAR packages - one level backward compatibility needs to be supported
For backward compatibility support, SDC needs to check the package manifest file and metadata such as "compatible_specifcation_versions".
- If it is 3.3.1+, SDC needs to follow a new onboarding path for the ETSI 3.3.1 version package.
- If the version is prior to 3.3.1, SDC follows the existing 2.x onboarding path.
The package version and its descriptor version should match.

Yes

Jira

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

High

Determine the onboarding path based on manifest metadata

Determine the onboarding path based on the manifest file and metadata "compatible_specification_versions"
If the version is prior to 3.3.1, invoke the existing 2.x SOL004 VNF package onboarding path
Otherwise, invoke a new SOL004 VNF package onboarding path
SDC users should be able to choose the onboarding package version from SDC UI Category selection...to be discussed...

High

Create a new onboarding path for SOL004 3.3.1 VNF package

Create a new onboarding path for 3.3.1Check the CSAR structure differences between 2.7.1 and 3.3.1
Handle additional artifacts for CNF, such as Helm Charts, Container Image file(s)For the Non-ETSI CNF, handle an optional VNFD case
Handle container image files with the limited file size (up to 2MB); larger files will not be handled in this release; support of larger files requires huge effort (AMDOC's help is needed)

High

Support the SOL001 vnf_profile properties

SDC needs to support the SOL001 vnf_profile (toaca.databypes.nfv.VnfProfile) properties

Image RemovedImage Added

Jira

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

High

Support for onboarding ETSI v3.3.1 SOL001 VNF Descriptors

SDC users need to onboard ETSI v3.3.1 SOL001 VNF Descriptors
SDC users should be also able to onboard the existing ETSI v2.6.1/v2.5.1 SOL001 VNF Descriptors - one level backward compatibility needs to be supported
For backward compatibility support, SDC needs to recognize the properties changes (e.g., use the VNF package version) for the Version indication. 
SDC uses a separate onboarding process depending on the version.

Yes

Jira

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

High

Determine the onboarding path based on metadata

Determine the onboarding path based on the VNFD package version "compatible_specifcation_versions"
If the version is v2.6.1/v2.5.1, invoke the existing SOL001 VNF onboarding
Otherwise, invoke a new SOL001 VNFD onboarding path

Create a new onboarding path for SOL001 VNFD 3.3.1

Create a new onboarding path for 3.3.1 VNFDCheck the VNFD differences between 2.5.1/2.7.1 and 3.3.1
Share the common/base SDC data type and node type to represent both 3.3.1 and 2.x; i.e., merge two structures for minimum impact
Note: This is the current SDC limitation without versioning, and it will be handled separately in the future.

Support for onboarding ETSI v3.3.1 SOL001 VNF Descriptors with minimum CNF enhancements from 4.1.1

SDC users need to onboard ETSI 3.3.1 with minimum CNF enhancements from 4.1.1

Add tosca.nodes.nfv.VDU.OsContainer type to vnfd_types - aligned with the IFA011 v4.1.1 specification
Add mciopProfile type vnfd_types - aligned with the IFA011 v4.1.1 specification
Allow OsContainerDesc to be in the VDU section - only one of tosca.nodes.nfv.VDU.osContainer or tosca.nodes.nfv.VDU.compute in a VNFD
Allow mciopProfile in VNF Descriptor

SDC needs to support new CNF properties / classes / schema / data models based on defined Information Models
SDC may use a separate onboarding process for CNF
No backward compatibility for CNF support is necessary

Yes

Jira

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

High

Support minimum CNF enhancements from 4.1.1

Support the vnfd_type with CNF attributes from 4.1.1:

Add tosca.nodes.nfv.VDU.OsContainer type to vnfd_types - aligned with the IFA011 v4.1.1 specification
Add mciopProfile type vnfd_types - aligned with the IFA011 v4.1.1 specification
Allow OsContainerDesc to be in the VDU section - only one of tosca.nodes.nfv.VDU.osContainer or tosca.nodes.nfv.VDU.compute in a VNFD
Allow mciopProfile in VNF Descriptor

Extend the 3.3.1 VNFD onboarding path for CNF attributes

Extend the 3.3.1 VNFD onboarding logic for CNF attribute handling

===========

Support for mapping of ETSI v3.3.1 SOL001 VNF Descriptor into SDC AID Data Model

Once SDC onboards an ETSI v3.3.1 SOL001 VNF Descriptor, SDC needs to map the ETSI v3.3.1 SOL001 VNF Descriptor into SDC AID Data Model

No backward compatibility ; SDC supports only ETSI 3.3.1 VNFD mapping to SDC AID DM

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 (Stretch goal)

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)

SDC supports Interface mapping to SDC AID DM for creating Service and connect VNF to external networking, etc.

Capacity and requirement mapping won't be necessary in this release

Yes

Jira

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

Medium

(VF-Module mapping is a stretch goal)

Map VNF data type to SDC AID DM VF

Map VDU data type to SDC AID DM VFC

Deduce VF-Module from VNFD Policies

Map VNF Interfaces to SDC AID DM

Support for mapping of ETSI v3.3.1 SOL001 VNF Descriptor with minimum CNF enhancements from 4.1.1 into SDC AID Data Model

Once SDC onboards an ETSI v3.3.1 SOL001 VNF Descriptor with CNF enhancements, SDC needs to map the ETSI v3.3.1 SOL001 VNF Descriptor with minimum CNF enhancements from 4.1.1 into SDC AID Data Model

SDC supports VDU mapping for osContainer to SDC AID DM
- create a new NF type for CNF
SDC supports virtualCPD, MCIOP ...
note: need to discuss with the non-ETSI team for compatibility
- try to have unified modeling between non-ETSI and ETS-based CNF modeling... To discuss with SO team...
- Thinking about optional VNFD. If there is no VNFD, no mapping is necessary

Yes

Jira

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

medium

Map VNF with CNF properties to SDC AID DM

Map VDU with CNF properties to SDC AID DM

Map virtualCPD to SDC AID DM

Map MCIOP to SDC AID DM

Support for editing ETSI v3.3.1 SOL001 VNF / CNF Descriptor

SDC users should be able to edit onboarded ETSI v3.3.1 SOL001 VNF Descriptors

no backward compatibility is necessary
SDC supports value changes and also adding properties

Note: should we reflect the changes to original vendor packages in ETSI_PACKAGE directory??? need to think about impact... SDC generates a new digital signature for the package and distributes it to ETSI Catalog Manager.

Yes

Jira

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

medium

Enhance SDC UI for editing SOL001 VNF / CNF descriptor properties

Design ETSI SOL007 compliant Network Service Descriptor packages

Executive Summary- Design, catalog and distribute  an ETSI SOL007 v3.3.1 compliant Network Service Descriptor package including an ETSI v3.3.1 SOL001 Network Service Descriptor (NSD) for deployment using an ETSI compliant NFVO.Support for designing an ETSI SOL001 v3.3.1 compliant Network Service that can be deployed with an ETSI compliant NFVO
Compose of one or more VNFs and the Virtual Links that connect them.
Support for using VNFs with CNF enhancements
Business Impact- Enables operators and service providers to use internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility.
Business Markets- All operators and service providers that are developing and deploying 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-3338

1 week for one designer

High

Support for designing an ETSI SOL001 v3.3.1 compliant Network Service that can be deployed with an ETSI compliant NFVO

SDC users need to design an ETSI SOL001 v3.3.1 compliant Network Service that can be deployed with an ETSI compliant NFVO

SDC needs to support backward compatibility for 2.5.1/2.6.1?
SDC users need to create NS
SDC users need to generate SOL007 NS package

Yes

Jira

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

High

Enhance SDC design for creating v3.3.1 NS

Generate v3.3.1 SOL007 NS package

No backward compatibility is necessary

Compose of one or more VNFs and the Virtual Links that connect them

SDC users need to compose one or more VNFs and the Virtual Links that connect them in NS

The NSD and its referenced VNF / CNF versions should be matched.
During SDC references VNFs, SDC needs to validate the version of VNFs / CNF, based on the VNF / CNF descriptor metadata (version indicator in the metadata)
- After 2.6.1, there is a version indicator in the metadata

Note: cover the VNF version validation... SAP descriptor has a version...

Yes

Jira

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

High

Enhance SDC to compose v3.3.1 VNFs and VLs for v3.3.1 NS

Enhance SDC to allow compose v3.3.1 VNFs and VLs for v3.3.1 NS

Validate NSD and VNFD version match

The versions of NS and sub models should be matched

Support for compose VNFs with CNF enhancements

SDC users need to compose VNFs with CNF enhancements

~~note: virtual CPD ... version... TBD~~

Yes

Jira

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

High

Enhance SDC to compose v3.3.1 VNFs with CNF enhancements

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

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

map SOL001 NSD to SDC AID DM
support ETSI NS and NsVirtualLink only.. maybe more... TBD
support Interfaces

Yes

Jira

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

Medium

Map v3.3.1 NSD to SDC AID DM

Suport Interfaces

Suport NS Interfaces to SDC AID DM

Support design of Service templates, leveraging NSDs

SDC users need to support design of Service templates, leveraging NSDs

ONAP service references NSDs...

Yes

Jira

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

Medium

Compose Service Templates referencing NSDs

Design Nested/Hierarchical ETSI SOL001 v3.3.1 Network Service Descriptor package

Executive Summary- Design an ETSI SOL007 v3.3.1 compliant Network Service Descriptor package including an ETSI v3.3.1 SOL001 Network Service Descriptor (NSD) that includes references to other Network Service Descriptors for deployment using an ETSI compliant NFVO.
- Composed of zero or more VNFs and one or more nested Network Services and the Virtual Links that connect them.
- Support for using VNFs with CNF enhancements
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

Jira

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

N/A

Compose of zero or more VNFs and one or more nested Network Services and the Virtual Links that connect them

SDC users need to compose zero or more VNFs and one or more nested Network Services and the Virtual Links that connect them

No

Jira

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

N/A

Support for using VNFs with CNF enhancements

Support design of Service templates, leveraging NSDs

No

Jira

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

N/A

Onboard Prototype Package based on ETSI IFA011 v4.1.1 supporting containerized VNF (CNF) packages

Executive Summary- Enable a vendor provided ETSI SOL004 compliant containerized VNF package including an ETSI SOL001 VNF Descriptor with container enhancements to be onboarded into ONAP for composition into an ETSI Network Service
- Support for onboarding Prototype v4.1.1 CSAR Packages
- Support for onboarding Prototype v4.1.1 VNF Descriptor
- Support for mapping of Prototype v4.1.1 VNF Descriptor into SDC AID Data Model
- Support for using a Prototype v4.1.1 VNF in an ETSI Network Service
Business Impact- Enables operators and service providers to use same ETSI aligned containerized VNF (CNF) packages with ONAP and existing NFVO. Industry compatibility.
Business Markets- All operators that are currently using ETSI packages to deploy containerized VNFs (CNFs)
Funding/Financial Impacts- Reduction in operations expense from using industry standard containerized VNF (CNF) 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-3353

N/A

Support for onboarding Prototype v4.1.1 CSAR Packages

SDC needs to support onboarding prototype v4.1.1 CSAR packages with CNF artifacts and metadata

No

Jira

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

Support for onboarding Prototype v4.1.1 VNF/CNF Descriptor

SDC needs to support onboarding prototype v4.1.1 VNF/CNF descriptor

No

Jira

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

Support for mapping of Prototype v4.1.1 VNF/CNF Descriptor into SDC AID Data Model

SDC needs to support mapping of prototype v4.1.1 VNF/CNF Descriptor into SDC AID Data Model

No

Jira

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

Support for using a Prototype v4.1.1 VNF in an ETSI Network Service

SDC needs to support for a prototype v4.1.1 VNF/CNF in an ETSI network Service

No

Jira

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

Onboard ETSI 3.3.1 SOL004 compliant PNF packages

Executive Summary - Enable a vendor provided ETSI 3.3.1 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

Jira

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

N/A

SDC supports onboarding of the 3.3.1 SOL004 PNF package includes SOL001 PNFD

SDC user needs to onboard ETSI 3.3.1 SOL004 PNF packages
SDC needs to update onboarding procedure for v3.3.1

No

Jira

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

N/A

Support for mapping of ETSI v3.3.1 SOL001 PNF Descriptor into SDC AID Data Model

SDC needs to support 3.3.1 SOL001 PNFD Mapping to SDC AID DM

No

Jira

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

N/A

Onboard ETSI SOL007 compliant Network Service Descriptor packages

Executive Summary - Onboard an ETSI SOL007 v3.3.1 compliant (Link to ETSI SOL007 v3.3.1) Network Service Descriptor package including an ETSI version 3.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 v3.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 v3.3.1 compliant Network Service using VF-C as the NFVO
Support for deploying a service that contains an ETSI SOL001 v3.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

Jira

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

N/A

Support onboarding for Cataloging and Preserving the original SOL007 package

SDC users need to support onboarding for Cataloging and Preserving the original SOL007 package (Link to ETSI SOL001 v3.3.1)

No

Jira

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

N/A

Support for onboarding of the SOL007 v3.3.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service

SDC users need to support for onboarding of the SOL007 v3.3.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service

No

Jira

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

N/A

Support ETSI Package Security and validation

ONAP supports vendor ETSI 3.3.1Package Security and validation

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

Yes

Jira

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

4 weeks for one designer

High

SOL004 VNF/PNF Package security will be supported by SDC, based on the ETSI 3.3.1 package signature and certificate

ONAP SDC supports ETSI 3.3.1 SOL004 VNF/PNF Package security

Yes

SOL007 NS Package security will be supported by SDC, based on the ETSI 3.3.1 package signature and certificate

ONAP SDC supports ETSI 3.3.1 SOL007 NS Package security

Yes

Jira

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

High

Support of ETSI Package Validation

VNF SDK will support ETSI package validation for VNF and NS

TBD

N/A

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

TBD

N/A

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

TBD

N/A

...

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 ETSI_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.
- SOL007 NS onboarding will follow the same procedure; i.e., storing the vendor SOL007 NS package into the ETSI_PACKAGE directory.
In Guilin, the ONBOARDED_PACKAGE directory is changed to the ETSI_PACKAGE directory.

Image RemovedImage Added

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

Image RemovedImage Added

NS Onboarding Design

...

Gliffy Diagram

macroId	fbc6e2f8-a0f2-4c65-9293-6931f8e8b2e9
name	ETSI SDC Onboarding - Honolulu
pagePin	116

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

SOL004 and SOL001 v3.3.1 + 4.1.1 (hybrid) Onboarding

Gliffy Diagram

macroId	d34e147d-5457-466e-a4b2-206abd612a83
name	SOL004 VNF-CNF structure onboarding - Honolulu
pagePin	19

Design NS

NSD Structure

Image RemovedImage Added

SDC supports NSD design that meets the following requirements.

...

SDC supports the following NSD Information Elements.
SDC supports the netestedNsdId(s) for nested NSDs. (not for Guilin)
SDC UI should be able to manage the NSD attributes.
SDC supports the virtualLinkDesc(s) to define constituent VLs.

Image RemovedImage Added

Use Cases for Guilin

...

SDC should be able to reference the vCPE NSD from the E2E Service model.
SDC should be able to reference all the constituent VNFs and VL(s).

Image RemovedImage Added

Image RemovedImage Added

Test with vGW and VGMUX with a VL first.

...

SDC supports NSVLDs that are defined in the ETSI IFA 014, as part of NS design.
SDC UI should be able to handle the following VLD attributes.

Image RemovedImage Added

VNFD Composition

...

Drag and drops onboarded VNFs

VNFD Data Model

tosca.nodes.nfv.VNF:

...

description: The generic abstract type from which all VNF specific abstract node types shall be derived to form, together with other node types, the TOSCA service template(s) representing the VNFD
...
tosca.nodes.nfv.VNF:
derived_from: tosca.nodes.Root
description: The generic abstract type from which all VNF specific node types shall be derived to form, together with other node types, the TOSCA service template(s) representing the VNFD
...
Identifies the version of the VNFD
...
lcm_operations_configuration
...
tosca.datatypes.nfv.VnfLcmOperationsConfiguration
...
Describes the configuration parameters for the VNF LCM operations
...
monitoring_parameters
...
tosca.datatypes.nfv.VnfMonitoringParameter
...
Describes monitoring parameters applicable to the VNF.
...
flavour_id
...
Identifier of the Deployment Flavour within the VNFD
...
flavour_description
...
Human readable description of the DF
...
tosca.datatypes.nfv.VnfProfile
...
Describes a profile for instantiating VNFs of a particular NS DF according to a specific VNFD and VNF DF
...
Describes additional instantiation data for the MCIOPs used in this deployment
...
attributes:
scale_status:
type: map # key: aspectId
description: Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how "big" the VNF has been scaled w.r.t. that aspect.
entry_schema:
type: tosca.datatypes.nfv.ScaleInfo
requirements:
- virtual_link:
capability: tosca.capabilities.nfv.VirtualLinkable
relationship: tosca.relationships.nfv.VirtualLinksTo
occurrences: [ 0, 1 ]
# Additional requirements shall be defined in the VNF specific node type (deriving from tosca.nodes.nfv.VNF) corresponding to NS virtual links that need to connect to VnfExtCps
...
interfaces:
Vnflcm:
type: tosca.interfaces.nfv.Vnflcm
# VnfIndicator:
# type: tosca.interfaces.nfv.VnfIndicator
# derived types are expected to introduce Vnf Indicator interfaces
# with their type derived from tosca.interfaces.nfv.VnfIndicator

VDU OsContainer Data Model

...

tosca.nodes.nfv.Vdu.osContainer:

derived_from: tosca.nodes.Root

description: Describes the container compute part of a VDU which is a construct supporting the description of the deployment and operational behavior of a VNFC

...

Describes constraints on the NFVI for the VNFC instance(s) created from this VDU. This property is reserved for future use in the present document.

...

monitoring_parameters

...

tosca.datatypes.nfv.VnfcMonitoringParameter

...

Describes monitoring parameters applicable to a VNFC instantiated from this VDU

...

#configurable_properties

...

tosca.datatypes.nfv.VnfcConfigurableProperties

...

# derived types are expected to introduce configurable_properties with its type derived from tosca.datatypes.nfv.VnfcConfigurableProperties

...

vdu_profile

...

tosca.datatypes.nfv.VduProfile

...

Defines additional instantiation data for the Vdu.OsContainer node

...

sw_image_data

...

tosca.datatypes.nfv.SwImageData

...

Defines information related to a SwImage artifact used by this Vdu.OsContainer node

...

boot_data

...

tosca.datatypes.nfv.BootData

...

Contains the information used to customize a container compute resource at boot time. The bootData may contain variable parts that are replaced by deployment specific values before being sent

...

capabilities:

virtual_compute:

type: tosca.capabilities.nfv.VirtualComputej

occurrences: [ 1, 1 ]

virtual_binding:

type: tosca.capabilities.nfv.VirtualBindable

occurrences: [ 1, UNBOUNDED ]

...

requirements:

- virtual_storage:

capability: tosca.capabilities.nfv.VirtualStorage

relationship: tosca.relationships.nfv.AttachesTo

occurrences: [ 0, UNBOUNDED ]

MciopProfile Data Model

...

tosca.datatypes.nfv.MciopProfile:

derived_from: tosca.datatypes.Root

description: describes a profile for instantiating VNFs of a particular NS DF according to a specific VNFD and VNF DF.

...

mciopId

...

Identifies the MCIOP in the VNF package.

...

deploymentOrder

...

Indicates the order in which this MCIOP shall be deployed in relation to other MCIOPs. A lower value specifies an earlier deployment.

null is allowed

...

# affinityOrAntiAffinityGroupId

...

References the affinity or anti-affinity groups(s) the MCIOP belongs to.

...

associatedVdu

...

List of VDUs which are associated to this MCIOP and which are deployed using this MCIOP

VnfInstantiateOperationConfiguration Data Model

...

tosca.datatypes.nfv.VnfInstantiateOperationConfiguration:

derived_from: tosca.datatypes.Root

description: represents information that affect the invocation of the InstantiateVnf operation.

...

VnfMonitoringParameter Data Model

...

tosca.datatypes.nfv.VnfMonitoringParameter:
derived_from: tosca.datatypes.Root
description: Represents information on virtualised resource related performance metrics applicable to the VNF.

...

name

...

String

...

1

...

Human readable name of the monitoring parameter

...

performance_metric

...

String

...

1

...

- valid_values: [ v_cpu_usage_mean_vnf, v_cpu_usage_peak_vnf,
v_memory_usage_mean_vnf, v_memory_usage_peak_vnf,
v_disk_usage_mean_vnf, v_disk_usage_peak_vnf,
byte_incoming_vnf_ext_cp, byte_outgoing_vnf_ext_cp,
packet_incoming_vnf_ext_cp, packet_outgoing_vnf_ext_cp

...

Identifies the performance metric, according to ETSI GS NFV-IFA 027.

...

collection_period

...

scalar-unit.time

...

0..1

...

- greater_than: 0 s

...

Describes the recommended periodicity at which to collect the performance information.

VnfProfile Data Model

...

tosca.datatypes.nfv.VnfProfile:
derived_from: tosca.datatypes.Root
description: describes a profile for instantiating VNFs of a particular NS DF according to a specific VNFD and VNF DF.

...

instantiation_level

...

String

...

0..1

...

Identifier of the instantiation level of the VNF DF to be used for instantiation. If not present, the default instantiation level as declared in the VNFD shall be used

...

min_number_of_instances

...

Integer

...

1

...

- greater_or_equal: 0

...

Minimum number of instances of the VNF based on this VNFD that is permitted to exist for this VnfProfile.

...

max_number_of_instances

...

Integer

...

1

...

- greater_or_equal: 0

...

Maximum number of instances of the VNF based on this VNFD that is permitted to exist for this VnfProfile.

SwImageData Data Model

...

tosca.datatypes.nfv.SwImageData:

derived_from: tosca.datatypes.Root

description: describes information related to a software image artifact

...

name

...

String

...

1

...

Name of this software image

...

version

...

String

...

1

...

Version of this software image

...

provider

...

String

...

1

...

Provider of this software image

...

checksum

...

tosca.datatypes.nfv.ChecksumData

...

Checksum of the software image file

...

container_format

...

- valid_values: [ aki, ami, ari, bare, docker, ova, ovf ]

...

The container format describes the container file format in which software image is provided

...

disk_format

...

- valid_values: [ aki, ami, ari, iso, qcow2, raw, vdi, vhd, vhdx, vmdk ]

...

The disk format of a software image is the format of the underlying disk image

...

min_disk

...

scalar-unit.size # Number

...

- greater_or_equal: 0 B

...

The minimal disk size requirement for this software image

...

min_ram

...

scalar-unit.size # Number

...

- greater_or_equal: 0 B

...

The minimal RAM requirement for this software image

...

size

...

scalar-unit.size # Number

...

The size of this software image

...

operating_system

...

Identifies the operating system used in the software image

...

supported_virtualisation_environments

...

Identifies the virtualisation environments (e.g. hypervisor) compatible with this software image

BootData Data Model

...

tosca.datatypes.nfv.BootData:

derived_from: tosca.datatypes.Root

description: describes the information used to customize a virtualised or containerized compute resource at boot time.

...

vim_specific_properties

...

tosca.datatypes.nfv.BootDataVimSpecificProperties

...

0..1

...

Properties used for selecting VIM or CISM specific capabilities when setting the boot data.

...

kvp_data

...

tosca.datatypes.nfv.KvpData

...

0..1

...

A set of key-value pairs for configuring a virtual or container compute resource.

...

content_or_file_data

...

tosca.datatypes.nfv.ContentOrFileData

...

0..1

...

A string content or a file for configuring a virtual or container compute resource.

BootDataVimSpecificProperties Data Model

...

tosca.datatypes.nfv.BootDataVimSpecificProperties:

derived_from: tosca.datatypes.Root

description: describes the VIM specific information used for selecting VIM specific capabilities when setting the boot data.

...

vim_type

...

String

...

1

...

Discriminator for the different types of the VIM or CISM information.

...

properties

...

map of String

...

0..n

...

Properties used for selecting VIM or CISM specific capabilities when setting the boot data

KvpData Data Model

...

tosca.datatypes.nfv.KvpData:

derived_from: tosca.datatypes.Root

description: describes a set of key-value pairs information used to customize a virtualised or containerized compute resource at boot time by using only key-value pairs data.

...

data

...

map of String

...

0..n

...

A map of strings that contains a set of key-value pairs that describes the information for configuring the virtualised or containerized compute resource.

ContentOrFileData Data Model

...

The following Data Model link define VNFD and its sub node types.

VNF/CNF Data Model Based on ETSI v3.3.1 SOL001 plus CNF Enhancements

...

tosca.datatypes.nfv.ContentOrFileData:

derived_from: tosca.datatypes.Root

description: describes a string content or a file information used to customize a virtualised or containerized compute resource at boot time by using string content or file.

...

data

...

map of String

...

0..n

...

A map of strings that contains a set of key-value pairs that carries the dynamic deployment values which used to replace the corresponding variable parts in the file as identify by a URL as described in source_path. Shall be present if "source_path" is present and shall be absent otherwise..

...

content

...

The string information used to customize a virtualised or containerized compute resource at boot time.

...

source_path

...

The URL to a file contained in the VNF package used to customize a virtualised or containerized compute resource. The content shall comply with IETF RFC 3986 [8].

...

destination_path

...

The URL address when inject a file into the virtualised or containerized compute resource. The content shall comply with IETF RFC 3986 [8].

VNFD Information element

The following depicts the VNFD information element.

Image RemovedImage Added

SapD Composition

SapD fulfills the following information element.

Image RemovedImage Added

Distribution

ETSI packages will be distributed from SDC to the ETSI Catalog Manager for other ONAP runtime components such as SO (SOL003/SOL005 Adapter) and VF-C.

...

ETSI Catalog Manager will interface with the SDC directly, without a help from ONAP SO.

Image RemovedImage Added

Package Distribution Components Interactions

...

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

Image RemovedImage Added

Package Security

...

Current Mapping Support (as of Frankfurt)

Image RemovedImage Added

Note: AAI impacts are under discussion.

...

<tosca.datatypes.nfv.NsProfile>

Image RemovedImage Added

SDC TOSCA Repository

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

Image RemovedImage Added

SDC nfv-types

Image RemovedImage Added

SDC nfv-types/NSD

...

SOL001 VNF (tosca.nodes.nfv.VNF) from SOL001 v3.3.1+4.1.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
mciop_profile	no	list of tosca.datatypes.nfv.MciopProfile				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

...

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
mciop_profile	no	list of tosca.datatypes.nfv.MciopProfile	<-->	mciop_profile	no	list of tosca.datatypes.nfv.MciopProfile
				<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.~~

...

capabilities:

requirements:

Image RemovedImage Added

SOL001 VNFD mapping to/from SDC AID DM VFD

...

<tosca.nodes.nfv.NsVirtualLink>

Image RemovedImage Added

<tosca.datatypes.nfv.NsVlProfile>

Image RemovedImage Added

<tosca.datatypes.nfv.ConnectivityType>

Image RemovedImage Added

<tosca.datatypes.nfv.LinkBitrateRequirements>

Image RemovedImage Added

<tosca.datatypes.nfv.NsVirtualLinkQos>

Image RemovedImage Added

<tosca.datatypes.nfv.ServiceAvailability>

Image RemovedImage Added

Current SDC VL

...

SOL001 PNF mapping to/from VL SDC AID DM

Image RemovedImage Added

Executive Summary- Enable a vendor provided ETSI SOL004 v3.3.1 compliant VNF package including an ETSI SOL001 VNF / CNF Descriptor to  be onboarded into ONAP for composition into an ONAP Network ServiceSupport for onboarding ETSI v3.3.1SOL004 VNF CSAR Packages with minimum CNF enhancements from 4.1.1
Support for onboarding ETSI v3.3.1 SOL001 VNF Descriptor with minimum CNF enhancements from 4.1.1
Support for mapping of ETSI v3.3.1 SOL001 VNF Descriptor with CNF enhancements into SDC AID Data Model
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

4 weeks for one designer

High

Support for onboarding ETSI v3.3.1 SOL004 VNF CSAR Packages with minimum CNF enhancements from 4.1.1

SDC users need to onboard ETSI v3.3.1 SOL004 VNF CSAR Packages with minimum CNF enhancements from 4.1.1
- Manifest File (e.g., MainServiceTemplate.mf): a new non-MANO artifact set identifier "onap_cnf_helm" - This would identify the "top-level" helm chart that can be used to deploy the CNF directly, i.e., without utilizing the LCM info the VNF Descriptor
  - e.g., onap_cnf_helm:

source: Artifacts/helm/helm_charts.yaml

note: to support the direct path, the VNFD could be optional (under discussion with ETSI NFV and ONAP Direct Path team)

SDC users should be also able to onboard the existing ETSI v2.6.1 SOL004 CSAR packages - one level backward compatibility needs to be supported
For backward compatibility support, SDC needs to check the package manifest file and metadata such as "compatible_specifcation_versions".
- If it is 3.3.1+, SDC needs to follow a new onboarding path for the ETSI 3.3.1 version package.
- If the version is prior to 3.3.1, SDC follows the existing 2.x onboarding path.
The package version and its descriptor version should match.

Yes

Jira

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

High

Determine the onboarding path based on manifest metadata

Determine the onboarding path based on the manifest file and metadata "compatible_specification_versions"
If the version is prior to 3.3.1, invoke the existing 2.x SOL004 VNF package onboarding path
Otherwise, invoke a new SOL004 VNF package onboarding path
SDC users should be able to choose the onboarding package version from SDC UI Category selection...to be discussed...

High

Create a new onboarding path for SOL004 3.3.1 VNF package

Create a new onboarding path for 3.3.1Check the CSAR structure differences between 2.7.1 and 3.3.1
Handle additional artifacts for CNF, such as Helm Charts, Container Image file(s)For the Non-ETSI CNF, handle an optional VNFD case
Handle container image files with the limited file size (up to 2MB); larger files will not be handled in this release; support of larger files requires huge effort (AMDOC's help is needed)

High

Support the SOL001 vnf_profile properties

SDC needs to support the SOL001 vnf_profile (toaca.databypes.nfv.VnfProfile) properties

Image RemovedImage Added

Jira

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

High

Support for onboarding ETSI v3.3.1 SOL001 VNF Descriptors

SDC users need to onboard ETSI v3.3.1 SOL001 VNF Descriptors
SDC users should be also able to onboard the existing ETSI v2.6.1/v2.5.1 SOL001 VNF Descriptors - one level backward compatibility needs to be supported
For backward compatibility support, SDC needs to recognize the properties changes (e.g., use the VNF package version) for the Version indication. 
SDC uses a separate onboarding process depending on the version.

Yes

Jira

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

High

Determine the onboarding path based on metadata

Determine the onboarding path based on the VNFD package version "compatible_specifcation_versions"
If the version is v2.6.1/v2.5.1, invoke the existing SOL001 VNF onboarding
Otherwise, invoke a new SOL001 VNFD onboarding path

Create a new onboarding path for SOL001 VNFD 3.3.1

Create a new onboarding path for 3.3.1 VNFDCheck the VNFD differences between 2.5.1/2.7.1 and 3.3.1
Share the common/base SDC data type and node type to represent both 3.3.1 and 2.x; i.e., merge two structures for minimum impact
Note: This is the current SDC limitation without versioning, and it will be handled separately in the future.

Support for onboarding ETSI v3.3.1 SOL001 VNF Descriptors with minimum CNF enhancements from 4.1.1

SDC users need to onboard ETSI 3.3.1 with minimum CNF enhancements from 4.1.1

Add tosca.nodes.nfv.VDU.OsContainer type to vnfd_types - aligned with the IFA011 v4.1.1 specification
Add mciopProfile type vnfd_types - aligned with the IFA011 v4.1.1 specification
Allow OsContainerDesc to be in the VDU section - only one of tosca.nodes.nfv.VDU.osContainer or tosca.nodes.nfv.VDU.compute in a VNFD
Allow mciopProfile in VNF Descriptor

SDC needs to support new CNF properties / classes / schema / data models based on defined Information Models
SDC may use a separate onboarding process for CNF
No backward compatibility for CNF support is necessary

Yes

Jira

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

High

Support minimum CNF enhancements from 4.1.1

Support the vnfd_type with CNF attributes from 4.1.1:

Add tosca.nodes.nfv.VDU.OsContainer type to vnfd_types - aligned with the IFA011 v4.1.1 specification
Add mciopProfile type vnfd_types - aligned with the IFA011 v4.1.1 specification
Allow OsContainerDesc to be in the VDU section - only one of tosca.nodes.nfv.VDU.osContainer or tosca.nodes.nfv.VDU.compute in a VNFD
Allow mciopProfile in VNF Descriptor

Extend the 3.3.1 VNFD onboarding path for CNF attributes

Extend the 3.3.1 VNFD onboarding logic for CNF attribute handling

===========

Support for mapping of ETSI v3.3.1 SOL001 VNF Descriptor into SDC AID Data Model

Once SDC onboards an ETSI v3.3.1 SOL001 VNF Descriptor, SDC needs to map the ETSI v3.3.1 SOL001 VNF Descriptor into SDC AID Data Model

No backward compatibility ; SDC supports only ETSI 3.3.1 VNFD mapping to SDC AID DM

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 (Stretch goal)

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)

SDC supports Interface mapping to SDC AID DM for creating Service and connect VNF to external networking, etc.

Capacity and requirement mapping won't be necessary in this release

Yes

Jira

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

Medium

(VF-Module mapping is a stretch goal)

Map VNF data type to SDC AID DM VF

Map VDU data type to SDC AID DM VFC

Deduce VF-Module from VNFD Policies

Map VNF Interfaces to SDC AID DM

Support for mapping of ETSI v3.3.1 SOL001 VNF Descriptor with minimum CNF enhancements from 4.1.1 into SDC AID Data Model

Once SDC onboards an ETSI v3.3.1 SOL001 VNF Descriptor with CNF enhancements, SDC needs to map the ETSI v3.3.1 SOL001 VNF Descriptor with minimum CNF enhancements from 4.1.1 into SDC AID Data Model

SDC supports VDU mapping for osContainer to SDC AID DM
- create a new NF type for CNF
SDC supports virtualCPD, MCIOP ...
note: need to discuss with the non-ETSI team for compatibility
- try to have unified modeling between non-ETSI and ETS-based CNF modeling... To discuss with SO team...
- Thinking about optional VNFD. If there is no VNFD, no mapping is necessary

Yes

Jira

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

medium

Map VNF with CNF properties to SDC AID DM

Map VDU with CNF properties to SDC AID DM

Map virtualCPD to SDC AID DM

Map MCIOP to SDC AID DM

Support for editing ETSI v3.3.1 SOL001 VNF / CNF Descriptor

SDC users should be able to edit onboarded ETSI v3.3.1 SOL001 VNF Descriptors

no backward compatibility is necessary
SDC supports value changes and also adding properties

Note: should we reflect the changes to original vendor packages in ETSI_PACKAGE directory??? need to think about impact... SDC generates a new digital signature for the package and distributes it to ETSI Catalog Manager.

Yes

Jira

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

medium

Enhance SDC UI for editing SOL001 VNF / CNF descriptor properties

Design ETSI SOL007 compliant Network Service Descriptor packages

Executive Summary- Design, catalog and distribute  an ETSI SOL007 v3.3.1 compliant Network Service Descriptor package including an ETSI v3.3.1 SOL001 Network Service Descriptor (NSD) for deployment using an ETSI compliant NFVO.Support for designing an ETSI SOL001 v3.3.1 compliant Network Service that can be deployed with an ETSI compliant NFVO
Compose of one or more VNFs and the Virtual Links that connect them.
Support for using VNFs with CNF enhancements
Business Impact- Enables operators and service providers to use internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility.
Business Markets- All operators and service providers that are developing and deploying 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-3338

1 week for one designer

High

Support for designing an ETSI SOL001 v3.3.1 compliant Network Service that can be deployed with an ETSI compliant NFVO

SDC users need to design an ETSI SOL001 v3.3.1 compliant Network Service that can be deployed with an ETSI compliant NFVO

SDC needs to support backward compatibility for 2.5.1/2.6.1?
SDC users need to create NS
SDC users need to generate SOL007 NS package

Yes

Jira

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

High

Enhance SDC design for creating v3.3.1 NS

Generate v3.3.1 SOL007 NS package

No backward compatibility is necessary

Compose of one or more VNFs and the Virtual Links that connect them

SDC users need to compose one or more VNFs and the Virtual Links that connect them in NS

The NSD and its referenced VNF / CNF versions should be matched.
During SDC references VNFs, SDC needs to validate the version of VNFs / CNF, based on the VNF / CNF descriptor metadata (version indicator in the metadata)
- After 2.6.1, there is a version indicator in the metadata

Note: cover the VNF version validation... SAP descriptor has a version...

Yes

Jira

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

High

Enhance SDC to compose v3.3.1 VNFs and VLs for v3.3.1 NS

Enhance SDC to allow compose v3.3.1 VNFs and VLs for v3.3.1 NS

Validate NSD and VNFD version match

The versions of NS and sub models should be matched

Support for compose VNFs with CNF enhancements

SDC users need to compose VNFs with CNF enhancements

~~note: virtual CPD ... version... TBD~~

Yes

Jira

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

High

Enhance SDC to compose v3.3.1 VNFs with CNF enhancements

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

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

map SOL001 NSD to SDC AID DM
support ETSI NS and NsVirtualLink only.. maybe more... TBD
support Interfaces

Yes

Jira

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

Medium

Map v3.3.1 NSD to SDC AID DM

Suport Interfaces

Suport NS Interfaces to SDC AID DM

Support design of Service templates, leveraging NSDs

SDC users need to support design of Service templates, leveraging NSDs

ONAP service references NSDs...

Yes

Jira

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

Medium

Compose Service Templates referencing NSDs

Design Nested/Hierarchical ETSI SOL001 v3.3.1 Network Service Descriptor package

Executive Summary- Design an ETSI SOL007 v3.3.1 compliant Network Service Descriptor package including an ETSI v3.3.1 SOL001 Network Service Descriptor (NSD) that includes references to other Network Service Descriptors for deployment using an ETSI compliant NFVO.
- Composed of zero or more VNFs and one or more nested Network Services and the Virtual Links that connect them.
- Support for using VNFs with CNF enhancements
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

Jira

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

N/A

Compose of zero or more VNFs and one or more nested Network Services and the Virtual Links that connect them

SDC users need to compose zero or more VNFs and one or more nested Network Services and the Virtual Links that connect them

No

Jira

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

N/A

Support for using VNFs with CNF enhancements

Support design of Service templates, leveraging NSDs

No

Jira

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

N/A

Onboard Prototype Package based on ETSI IFA011 v4.1.1 supporting containerized VNF (CNF) packages

Executive Summary- Enable a vendor provided ETSI SOL004 compliant containerized VNF package including an ETSI SOL001 VNF Descriptor with container enhancements to be onboarded into ONAP for composition into an ETSI Network Service
- Support for onboarding Prototype v4.1.1 CSAR Packages
- Support for onboarding Prototype v4.1.1 VNF Descriptor
- Support for mapping of Prototype v4.1.1 VNF Descriptor into SDC AID Data Model
- Support for using a Prototype v4.1.1 VNF in an ETSI Network Service
Business Impact- Enables operators and service providers to use same ETSI aligned containerized VNF (CNF) packages with ONAP and existing NFVO. Industry compatibility.
Business Markets- All operators that are currently using ETSI packages to deploy containerized VNFs (CNFs)
Funding/Financial Impacts- Reduction in operations expense from using industry standard containerized VNF (CNF) 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-3353

N/A

Support for onboarding Prototype v4.1.1 CSAR Packages

SDC needs to support onboarding prototype v4.1.1 CSAR packages with CNF artifacts and metadata

No

Jira

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

Support for onboarding Prototype v4.1.1 VNF/CNF Descriptor

SDC needs to support onboarding prototype v4.1.1 VNF/CNF descriptor

No

Jira

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

Support for mapping of Prototype v4.1.1 VNF/CNF Descriptor into SDC AID Data Model

SDC needs to support mapping of prototype v4.1.1 VNF/CNF Descriptor into SDC AID Data Model

No

Jira

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

Support for using a Prototype v4.1.1 VNF in an ETSI Network Service

SDC needs to support for a prototype v4.1.1 VNF/CNF in an ETSI network Service

No

Jira

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

Onboard ETSI 3.3.1 SOL004 compliant PNF packages

Executive Summary - Enable a vendor provided ETSI 3.3.1 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

Jira

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

N/A

SDC supports onboarding of the 3.3.1 SOL004 PNF package includes SOL001 PNFD

SDC user needs to onboard ETSI 3.3.1 SOL004 PNF packages
SDC needs to update onboarding procedure for v3.3.1

No

Jira

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

N/A

Support for mapping of ETSI v3.3.1 SOL001 PNF Descriptor into SDC AID Data Model

SDC needs to support 3.3.1 SOL001 PNFD Mapping to SDC AID DM

No

Jira

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

N/A

Onboard ETSI SOL007 compliant Network Service Descriptor packages

Executive Summary - Onboard an ETSI SOL007 v3.3.1 compliant (Link to ETSI SOL007 v3.3.1) Network Service Descriptor package including an ETSI version 3.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 v3.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 v3.3.1 compliant Network Service using VF-C as the NFVO
Support for deploying a service that contains an ETSI SOL001 v3.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

Jira

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

N/A

Support onboarding for Cataloging and Preserving the original SOL007 package

SDC users need to support onboarding for Cataloging and Preserving the original SOL007 package (Link to ETSI SOL001 v3.3.1)

No

Jira

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

N/A

Support for onboarding of the SOL007 v3.3.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service

SDC users need to support for onboarding of the SOL007 v3.3.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service

No

Jira

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

N/A

Support ETSI Package Security and validation

ONAP supports vendor ETSI 3.3.1Package Security and validation

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

Yes

Jira

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

4 weeks for one designer

High

SOL004 VNF/PNF Package security will be supported by SDC, based on the ETSI 3.3.1 package signature and certificate

ONAP SDC supports ETSI 3.3.1 SOL004 VNF/PNF Package security

Yes

SOL007 NS Package security will be supported by SDC, based on the ETSI 3.3.1 package signature and certificate

ONAP SDC supports ETSI 3.3.1 SOL007 NS Package security

Yes

Jira

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

High

Support of ETSI Package Validation

VNF SDK will support ETSI package validation for VNF and NS

TBD

N/A

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

TBD

N/A

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

TBD

N/A

...

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 ETSI_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.
- SOL007 NS onboarding will follow the same procedure; i.e., storing the vendor SOL007 NS package into the ETSI_PACKAGE directory.
In Guilin, the ONBOARDED_PACKAGE directory is changed to the ETSI_PACKAGE directory.

Image RemovedImage Added

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

Image RemovedImage Added

NS Onboarding Design

...

Gliffy Diagram

macroId	fbc6e2f8-a0f2-4c65-9293-6931f8e8b2e9
name	ETSI SDC Onboarding - Honolulu
pagePin	116

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

Design NS

NSD Structure

Image RemovedImage Added

SDC supports NSD design that meets the following requirements.

...

SDC supports the following NSD Information Elements.
SDC supports the netestedNsdId(s) for nested NSDs. (not for Guilin)
SDC UI should be able to manage the NSD attributes.
SDC supports the virtualLinkDesc(s) to define constituent VLs.

Image RemovedImage Added

Use Cases for Guilin

...

SDC should be able to reference the vCPE NSD from the E2E Service model.
SDC should be able to reference all the constituent VNFs and VL(s).

Image RemovedImage Added

...

Image Added

Image RemovedImage Added

Test with vGW and VGMUX with a VL first.

...

SDC supports NSVLDs that are defined in the ETSI IFA 014, as part of NS design.
SDC UI should be able to handle the following VLD attributes.

Image RemovedImage Added

VNFD Composition

...

Id	Type	Cardinality	Description
tosca.nodes.nfv.VNF: derived_from: tosca.nodes.Root description: The generic abstract type from which all VNF specific node types shall be derived to form, together with other node types, the TOSCA service template(s) representing the VNFD
descriptor_id	String #UUID	1	Identifier for the VNFD
descriptor_version	String	1	Identifies the version of the VNFD
provider	String	1	provider of the VNF and of the VNFD
product_name	String	1	name to identify the VNF product. Invariant for the VNF Product lifetime
software_version	String	1	Software version of the VNF
product_info_name	String	0..1	Human readable name of the VNF Product
product_info_description	String	0..1	Human readable name for the VNF product
vnfm_info	list of String	1..n	Identifies VNFM(s) compatible with the VNF
localization_languages	list of String	0..n	Information about localization languages of the VNF
lcm_operations_configuration	tosca.datatypes.nfv.VnfLcmOperationsConfiguration	0..n	Describes the configuration parameters for the VNF LCM operations
monitoring_parameters	list of tosca.datatypes.nfv.VnfMonitoringParameter	0..n	Describes monitoring parameters applicable to the VNF.
flavour_id	String	1	Identifier of the Deployment Flavour within the VNFD
flavour_description	String	1	Human readable description of the DF
vnf_profile	tosca.datatypes.nfv.VnfProfile	0..1	Describes a profile for instantiating VNFs of a particular NS DF according to a specific VNFD and VNF DF
mciop_profile	list of tosca.datatypes.nfv.MciopProfile	0..n	Describes additional instantiation data for the MCIOPs used in this deployment


attributes: scale_status: type: map # key: aspectId description: Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how "big" the VNF has been scaled w.r.t. that aspect. entry_schema: type: tosca.datatypes.nfv.ScaleInfo
requirements: - virtual_link: capability: tosca.capabilities.nfv.VirtualLinkable relationship: tosca.relationships.nfv.VirtualLinksTo occurrences: [ 0, 1 ] # Additional requirements shall be defined in the VNF specific node type (deriving from tosca.nodes.nfv.VNF) corresponding to NS virtual links that need to connect to VnfExtCps
interfaces: Vnflcm: type: tosca.interfaces.nfv.Vnflcm # VnfIndicator: # type: tosca.interfaces.nfv.VnfIndicator # derived types are expected to introduce Vnf Indicator interfaces # with their type derived from tosca.interfaces.nfv.VnfIndicator

VDU OsContainer Data Model

Id	Type	Cardinality	Description
tosca.nodes.nfv.Vdu.osContainer: derived_from: tosca.nodes.Root description: Describes the container compute part of a VDU which is a construct supporting the description of the deployment and operational behavior of a VNFC
name	String	1	Human readable name of the VDU
description	String	1	Human readable description of the VDU
nfvi_constraints	map of String	0..n	Describes constraints on the NFVI for the VNFC instance(s) created from this VDU. This property is reserved for future use in the present document.
monitoring_parameters	list of tosca.datatypes.nfv.VnfcMonitoringParameter	0..n	Describes monitoring parameters applicable to a VNFC instantiated from this VDU
#configurable_properties	tosca.datatypes.nfv.VnfcConfigurableProperties	0..1	# derived types are expected to introduce configurable_properties with its type derived from tosca.datatypes.nfv.VnfcConfigurableProperties
vdu_profile	tosca.datatypes.nfv.VduProfile	1	Defines additional instantiation data for the Vdu.OsContainer node
sw_image_data	tosca.datatypes.nfv.SwImageData	1	Defines information related to a SwImage artifact used by this Vdu.OsContainer node
boot_data	tosca.datatypes.nfv.BootData	0..1	Contains the information used to customize a container compute resource at boot time. The bootData may contain variable parts that are replaced by deployment specific values before being sent

capabilities: virtual_compute: type: tosca.capabilities.nfv.VirtualCompute occurrences: [ 1, 1 ] virtual_binding: type: tosca.capabilities.nfv.VirtualBindable occurrences: [ 1, UNBOUNDED ]
requirements: - virtual_storage: capability: tosca.capabilities.nfv.VirtualStorage relationship: tosca.relationships.nfv.AttachesTo occurrences: [ 0, UNBOUNDED ]

MciopProfile Data Model

Id	Type	Cardinality	Constraints	Description
tosca.datatypes.nfv.MciopProfile: derived_from: tosca.datatypes.Root description: describes a profile for instantiating VNFs of a particular NS DF according to a specific VNFD and VNF DF.
mciopId	String	1		Identifies the MCIOP in the VNF package.
deploymentOrder	Integer	0..1	greater_or_equal: 0	Indicates the order in which this MCIOP shall be deployed in relation to other MCIOPs. A lower value specifies an earlier deployment. null is allowed
# affinityOrAntiAffinityGroupId	list of String	0..n		References the affinity or anti-affinity groups(s) the MCIOP belongs to.
associatedVdu	list of String	0..n		List of VDUs which are associated to this MCIOP and which are deployed using this MCIOP

VnfInstantiateOperationConfiguration Data Model

Id	Type	Cardinality	Description
tosca.datatypes.nfv.VnfInstantiateOperationConfiguration: derived_from: tosca.datatypes.Root description: represents information that affect the invocation of the InstantiateVnf operation.
description	String	0..1	Description of VnfInstantiateOperationConfiguration

VnfMonitoringParameter Data Model

Id	Type	Cardinality	Constraints	Description
tosca.datatypes.nfv.VnfMonitoringParameter: derived_from: tosca.datatypes.Root description: Represents information on virtualised resource related performance metrics applicable to the VNF.
name	String	1		Human readable name of the monitoring parameter
performance_metric	String	1	- valid_values: [ v_cpu_usage_mean_vnf, v_cpu_usage_peak_vnf, v_memory_usage_mean_vnf, v_memory_usage_peak_vnf, v_disk_usage_mean_vnf, v_disk_usage_peak_vnf, byte_incoming_vnf_ext_cp, byte_outgoing_vnf_ext_cp, packet_incoming_vnf_ext_cp, packet_outgoing_vnf_ext_cp	Identifies the performance metric, according to ETSI GS NFV-IFA 027.
collection_period	scalar-unit.time	0..1	- greater_than: 0 s	Describes the recommended periodicity at which to collect the performance information.

VnfProfile Data Model

Id	Type	Cardinality	Constraints	Description
tosca.datatypes.nfv.VnfProfile: derived_from: tosca.datatypes.Root description: describes a profile for instantiating VNFs of a particular NS DF according to a specific VNFD and VNF DF.
instantiation_level	String	0..1		Identifier of the instantiation level of the VNF DF to be used for instantiation. If not present, the default instantiation level as declared in the VNFD shall be used
min_number_of_instances	Integer	1	- greater_or_equal: 0	Minimum number of instances of the VNF based on this VNFD that is permitted to exist for this VnfProfile.
max_number_of_instances	Integer	1	- greater_or_equal: 0	Maximum number of instances of the VNF based on this VNFD that is permitted to exist for this VnfProfile.

SwImageData Data Model

Id	Type	Cardinality	Constraints	Description
tosca.datatypes.nfv.SwImageData: derived_from: tosca.datatypes.Root description: describes information related to a software image artifact
name	String	1		Name of this software image
version	String	1		Version of this software image
provider	String	1		Provider of this software image
checksum	tosca.datatypes.nfv.ChecksumData	1		Checksum of the software image file
container_format	String	1	- valid_values: [ aki, ami, ari, bare, docker, ova, ovf ]	The container format describes the container file format in which software image is provided
disk_format	String	1	- valid_values: [ aki, ami, ari, iso, qcow2, raw, vdi, vhd, vhdx, vmdk ]	The disk format of a software image is the format of the underlying disk image
min_disk	scalar-unit.size # Number	1	- greater_or_equal: 0 B	The minimal disk size requirement for this software image
min_ram	scalar-unit.size # Number	0..1	- greater_or_equal: 0 B	The minimal RAM requirement for this software image
size	scalar-unit.size # Number	1		The size of this software image
operating_system	String	0..1		Identifies the operating system used in the software image
supported_virtualisation_environments	list of String	0..n		Identifies the virtualisation environments (e.g. hypervisor) compatible with this software image

BootData Data Model

Id	Type	Cardinality	Description
tosca.datatypes.nfv.BootData: derived_from: tosca.datatypes.Root description: describes the information used to customize a virtualised or containerized compute resource at boot time.
vim_specific_properties	tosca.datatypes.nfv.BootDataVimSpecificProperties	0..1	Properties used for selecting VIM or CISM specific capabilities when setting the boot data.
kvp_data	tosca.datatypes.nfv.KvpData	0..1	A set of key-value pairs for configuring a virtual or container compute resource.
content_or_file_data	tosca.datatypes.nfv.ContentOrFileData	0..1	A string content or a file for configuring a virtual or container compute resource.

BootDataVimSpecificProperties Data Model

tosca.datatypes.nfv.BootDataVimSpecificProperties:

derived_from: tosca.datatypes.Root

description: describes the VIM specific information used for selecting VIM specific capabilities when setting the boot data.

Id

Type

Cardinality

Constraints

Description

vim_type

String

1

Discriminator for the different types of the VIM or CISM information.

properties

map of String

0..n

Properties used for selecting VIM or CISM specific capabilities when setting the boot data

KvpData Data Model

tosca.datatypes.nfv.KvpData:

derived_from: tosca.datatypes.Root

description: describes a set of key-value pairs information used to customize a virtualised or containerized compute resource at boot time by using only key-value pairs data.

Id

Type

Cardinality

Constraints

Description

data

map of String

0..n

A map of strings that contains a set of key-value pairs that describes the information for configuring the virtualised or containerized compute resource.

ContentOrFileData Data Model

Id	Type	Cardinality	Description
tosca.datatypes.nfv.ContentOrFileData: derived_from: tosca.datatypes.Root description: describes a string content or a file information used to customize a virtualised or containerized compute resource at boot time by using string content or file.
data	map of String	0..n	A map of strings that contains a set of key-value pairs that carries the dynamic deployment values which used to replace the corresponding variable parts in the file as identify by a URL as described in source_path. Shall be present if "source_path" is present and shall be absent otherwise..
content	String	0..1	The string information used to customize a virtualised or containerized compute resource at boot time.
source_path	String	0..1	The URL to a file contained in the VNF package used to customize a virtualised or containerized compute resource. The content shall comply with IETF RFC 3986 [8].
destination_path	String	0..1	The URL address when inject a file into the virtualised or containerized compute resource. The content shall comply with IETF RFC 3986 [8].

...

The following depicts the VNFD information element.

Image RemovedImage Added

SapD Composition

SapD fulfills the following information element.

Image RemovedImage Added

Distribution

ETSI packages will be distributed from SDC to the ETSI Catalog Manager for other ONAP runtime components such as SO (SOL003/SOL005 Adapter) and VF-C.

...

ETSI Catalog Manager will interface with the SDC directly, without a help from ONAP SO.

Image RemovedImage Added

Package Distribution Components Interactions

...

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

Image RemovedImage Added

Package Security

...

Current Mapping Support (as of Frankfurt)

Image RemovedImage Added

Note: AAI impacts are under discussion.

...

<tosca.datatypes.nfv.NsProfile>

Image RemovedImage Added

SDC TOSCA Repository

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

Image RemovedImage Added

SDC nfv-types

Image RemovedImage Added

SDC nfv-types/NSD

...

capabilities:

requirements:

Image RemovedImage Added

SOL001 VNFD mapping to/from SDC AID DM VFD

...

<tosca.nodes.nfv.NsVirtualLink>

Image RemovedImage Added

<tosca.datatypes.nfv.NsVlProfile>

Image RemovedImage Added

<tosca.datatypes.nfv.ConnectivityType>

Image RemovedImage Added

<tosca.datatypes.nfv.LinkBitrateRequirements>

Image RemovedImage Added

<tosca.datatypes.nfv.NsVirtualLinkQos>

Image RemovedImage Added

<tosca.datatypes.nfv.ServiceAvailability>

Image RemovedImage Added

Current SDC VL

...

SOL001 PNF mapping to/from VL SDC AID DM

Image RemovedImage Added

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 46

New Version Current

Key

NS Onboarding Design

SOL004 and SOL001 v3.3.1 + 4.1.1 (hybrid) Onboarding

Design NS

NSD Structure

SDC supports NSD design that meets the following requirements.

Use Cases for Guilin

Image RemovedImage Added

VNFD Composition

VNFD Data Model

VDU OsContainer Data Model

MciopProfile Data Model

VnfInstantiateOperationConfiguration Data Model

VnfMonitoringParameter Data Model

VnfProfile Data Model

SwImageData Data Model

BootData Data Model

BootDataVimSpecificProperties Data Model

KvpData Data Model

ContentOrFileData Data Model

VNFD Information element

SapD Composition

Distribution

Package Distribution Components Interactions

Package Security

Current Mapping Support (as of Frankfurt)

SDC TOSCA Repository

SDC nfv-types

SDC nfv-types/NSD

Option B:

SOL001 VNFD mapping to/from SDC AID DM VFD

Current SDC VL

SOL001 PNF mapping to/from VL SDC AID DM

Table of Contents

NS Onboarding Design

Design NS

NSD Structure

SDC supports NSD design that meets the following requirements.

Use Cases for Guilin

Image Added

VNFD Composition

VDU OsContainer Data Model

MciopProfile Data Model

VnfInstantiateOperationConfiguration Data Model

VnfMonitoringParameter Data Model

VnfProfile Data Model

SwImageData Data Model

BootData Data Model

BootDataVimSpecificProperties Data Model

KvpData Data Model

ContentOrFileData Data Model

SapD Composition

Distribution

Package Distribution Components Interactions

Package Security

Current Mapping Support (as of Frankfurt)

SDC TOSCA Repository

SDC nfv-types

SDC nfv-types/NSD

SOL001 VNFD mapping to/from SDC AID DM VFD

Current SDC VL

SOL001 PNF mapping to/from VL SDC AID DM