ETSI Package Management

Use Cases

• ETSI Package Onboarding and Distribution
  • SOL004 VNF/PNF/NS Package includes SOL001 VNFD/PNFD/NSD with the original vendor package will be distributed from SDC to SVNFM/External NFVO.
  • SOL003 and SOL005 Package Management APIs will be used for the distribution.
  • SOL004 VNF/PNF Package Security will be supported by the package signature and certificate.

Feature Descriptions

Epic and User Story

ETSI Package Management Architecture

The diagram depicts the package management architecture. 

1. SDC supports SOL004 VNF/PNF package onboarding, and stores the original vendor VNF/PNF/NS package inside the SDC package
   1. SOL004 package includes VNFD/NSD/PNFD TOSCA service template
   2. PNF onboarding was tested
   3. VNF onboarding is being tested in El Alto / Frankfurt
   4. NS onboarding will be supported in Frankfurt
2. SDC supports VNF/PNF package onboarding and/or accepts VNF/PNF package management interfaces from OSS/BSS via SOL005 Package Management APIs (TBD)
3. ONAP Runtime components store SOL004 Packages as needed
   1. For the SO case, SO stores SOL004 packages for NS, VNF and PNF by leveraging the ONAP-ETSI Catalog DB microservices
4. SOL003 VNFM Adapter provides VNFMs Query/Fetch VNF packages/contents/artifacts, Reading VNFD and subscription/notification services
5. SOL005 Adapter provides NSD/PNFD management and SOL005 VNF package management

• Note: 

1. SOL007 (NS package) support is under discussion.
2. To simplify the package distribution and storage, the Runtime Catalog Manager is suggested for the future.

• ETSI Package Distribution Flows

• Open Issues:
  • Will the external NFVO get the NS package thru ONAP-ETSI Catalog Mgr and SOL005 Adapter?   <need input from Verizon>

SDC VNF/PNF Onboarding and Distribution

This section describes SDC VNF/PNF onboarding and the End-to-End package distribution from SDC to SVNFM/external NFVOs.

SDC takes the vendor provided package and adds some files or changes files and meta data according to SDC procedure.

SDC VNF/PNF Onboarding Procedure and Original Vendor VNF/PNF Package Handling

• Enhancement (Ericsson contribution) was made to the SDC Dublin to support SOL004 PNF onboarding with .zip and .csar file extensions.
  • The enhancement can be used for VNF onboarding – it is being tested.
  • SDC VSP and Resource csar files have the ONBOARDING_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.

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

SDC SOL004 VNF Package Security

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

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

• Vendor SOL004 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 package CSAR and ZIP (with certificate and signature) – the supported format is TBD based on the security requirement

ETSI Package Distribution

ETSI packages will be distributed from SDC to other ONAP runtime components such as SO and VF-C. SO will store the packages to its ETSI Catalog DB and further distribute the packages to SVNFMs/external NFVOs thru the SOL003/SOL005 Adapters.

• The original vendor package contents between the Adapters and SVNFMs/NFVOs could be one of the following.
  • Vendor package including certificate and signature (Zip format)
  • Vendor package without certificate and signature (CSAR format)
• Open Issues:
  1. Distribution of vendor VNF packages with certificates and signatures to SVFNM need to be sorted out.
  2. Currently, VF-C supports CSAR-format without certificate or signature – TBD
• The following diagram depicts the ETSI package distribution. 

• The following sequence diagram depicts the Package Information Flows.

Package Security

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

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