Page History

...

• Executive Summary- Enable a vendor provided ETSI SOL004 v3.3.1 compliant VNF package including an ETSI SOL001 VNF Descriptor to  be onboarded into ONAP for composition into an ONAP Network Service
  • Support for onboarding ETSI v3.3.1SOL004 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 minimum CNF enhancements from 4.1.1  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.

...

• 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
  • Composed 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.

Design Nested/Hierarchical ETSI SOL001 v3.3.1 Network Service Descriptor package (for Istanbul release)

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

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

...

packages (for Istanbul release)

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

...

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 package inside the SDC package
   1. SOL004 package includes SOL001 VNFD/PNFD
   2. PNF onboarding has been tested
2. SDC will support SOL007 NS package onboarding and store the original vendor NS package inside the SDC package
   1. NS onboarding will be supported
   2. NS onboarding will be tested
3. SDC supports VNF/PNF package management interfaces from OSS/BSS via SOL005 Package Management APIs (TBD)
4. SO supports NS package management interfaces from OSS via SOL005 Package Management APIs (TBD)
5. ETSI Catalog Manager stores SOL004/SOL007 Packages for other ONAP runtime components such as SO, SOL003/SOL005 Adapters, VFC and others
   1. ONAP-ETSI Catalog Manager will store SOL004 packages for VNF and PNF
   2. ONAP-ETSI Catalog Manager will store SOL007 packages for NS
6. SOL003 VNFM Adapter provides VNFMs Query/Fetch VNF packages/contents/artifacts, Reading VNFD and subscription/notification services
7. SOL005 Adapter provides NS/PNF/VNF package management to VF-C/External NFVO by leveraging SOL005 package management APIs

Onboarding

SDC NS/VNF/PNF/NS 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 NS/VNF/PNF Onboarding Procedure and Original Vendor VNF/PNF Package Handling

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

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

Image Removed

NS Onboarding Design

• extend OrchestrationTemplateProcessCsarHandler.java to handle SOL007
  • processCsar()
    • instantiateToscaConverterFor(resourceType).convert(fileContentHandler)
      • calling ToscaSolModelDrivenConverterPNF()
        • pndfTransformationEngine.transform()
      • calling ToscaSolConverterVnf()
        • vnfTopologyTemplateConverter().convertTopologyTemplate(serviceTemplate, readerService)
          • convertInputs()
          • convertNodeTemplates()
          • convertOutputs()
          • convertSubstitutionMappings()
          • convertPolicies()
      • need to call ToscaSolModelDrivenConverterNS()
• create ToscaSolModelDrivenConverterNS class
  • create NSdNodeTemplateTransformationEngine class
    • transform() to SDC AID DM NS
• generate the SDC package for NS with the original vendor SOL007 NS package

VNF Onboarding Design

• leverage the existing SOL004 VNF onboarding mechanism
• create a transform class to transform to SDC AID DM VNF
• generate the SDC package for VNF with the original vendor SOL004 VNF package

PNF Onboarding Design

• leverage the existing SOL004 PNF onboarding mechanism
• the transformation to SDC AID DM is already done
• It is already done: generate the SDC package for PNF with the original vendor SOL004 VNF package

The following diagram depicts the onboarding procedures for VNF/NS/PNF.

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

Image Removed

SDC supports NSD design that meets the following requirements.

• The NSD shall reference the VNFDs applicable to its constituent VNFs.
• The NSD shall include the VLDs applicable to the VLs used by the NS to interconnect its constituent NFs.
• The NSD shall reference the PNFDs applicable to its constituent PNFs.
• The NSD shall include the descriptors of the VNFFGs applicable to the NS (stretch goal).
• The NSD shall support the capability to include or reference NS LCM scripts.
• The NSD shall support the capability to providing monitoring parameters to be tracked during the lifetime of a NS instance (stretch goal).
• The NSD shall support the capability to describe auto scale rules, associating criteria to scaling actions (stretch goal).
• The NSD shall include package security information enabling validating its authenticity and integrity.
• The NSD shall include a globally unique identifier for identifying each descriptor instance.
• The NSD shall include an identifier to select to controller compatible with the NSD.
• A VLD shall enable specifying the type of connectivity provided by the link between VNFs.

NSD Information Element

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

Image Removed

Use Cases for Guilin

VCPE

The following is an example of VCPE model hierarchy. In VCPE, the E2E Service model includes one NS (vCPE). And the vCPE NS model includes vbng, vbrgemu, vgmux and vgw VNFs and a network VL.

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

Image Removed

<example>

Image Removed

• Test with vGW and VGMUX with a VL first.

Latest vCPE CSARs

The latest (Frankfurt) vCPE CSARs can be retrieved from the https://git.onap.org/demo/tree/tosca/vCPE_F. There are one NS CSAR and five VNF CSARs:

• ns.csar
• infra.csar
• vbng.csar
• vbrgemu.csar
• vgmux.csar
• vgw.csar

Other Use Case

To represent nested NS cases, we will choose another use case.

• TBD

NSD Design Process in SDC

VNF Composition

The following diagram depicts how SDC

1. creates a NSD, based on SOL001 NSD
   1. generates SDC AID DM for NS, based on SOL001 NSD
2. drags and drops constituent VFs
3. generates SOL007 NS package

...

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 package inside the SDC package
   1. SOL004 package includes SOL001 VNFD/PNFD
   2. PNF onboarding has been tested
2. SDC will support SOL007 NS package onboarding and store the original vendor NS package inside the SDC package
   1. NS onboarding will be supported
   2. NS onboarding will be tested
3. SDC supports VNF/PNF package management interfaces from OSS/BSS via SOL005 Package Management APIs (TBD)
4. SO supports NS package management interfaces from OSS via SOL005 Package Management APIs (TBD)
5. ETSI Catalog Manager stores SOL004/SOL007 Packages for other ONAP runtime components such as SO, SOL003/SOL005 Adapters, VFC and others
   1. ONAP-ETSI Catalog Manager will store SOL004 packages for VNF and PNF
   2. ONAP-ETSI Catalog Manager will store SOL007 packages for NS
6. SOL003 VNFM Adapter provides VNFMs Query/Fetch VNF packages/contents/artifacts, Reading VNFD and subscription/notification services
7. SOL005 Adapter provides NS/PNF/VNF package management to VF-C/External NFVO by leveraging SOL005 package management APIs

Onboarding

SDC NS/VNF/PNF/NS 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 NS/VNF/PNF Onboarding Procedure and Original Vendor VNF/PNF Package Handling

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

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

Image Added

NS Onboarding Design

• extend OrchestrationTemplateProcessCsarHandler.java to handle SOL007
  • processCsar()
    • instantiateToscaConverterFor(resourceType).convert(fileContentHandler)
      • calling ToscaSolModelDrivenConverterPNF()
        • pndfTransformationEngine.transform()
      • calling ToscaSolConverterVnf()
        • vnfTopologyTemplateConverter().convertTopologyTemplate(serviceTemplate, readerService)
          • convertInputs()
          • convertNodeTemplates()
          • convertOutputs()
          • convertSubstitutionMappings()
          • convertPolicies()
      • need to call ToscaSolModelDrivenConverterNS()
• create ToscaSolModelDrivenConverterNS class
  • create NSdNodeTemplateTransformationEngine class
    • transform() to SDC AID DM NS
• generate the SDC package for NS with the original vendor SOL007 NS package

VNF Onboarding Design

• leverage the existing SOL004 VNF onboarding mechanism
• create a transform class to transform to SDC AID DM VNF
• generate the SDC package for VNF with the original vendor SOL004 VNF package

PNF Onboarding Design

• leverage the existing SOL004 PNF onboarding mechanism
• the transformation to SDC AID DM is already done
• It is already done: generate the SDC package for PNF with the original vendor SOL004 VNF package

The following diagram depicts the onboarding procedures for VNF/NS/PNF.

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

Design NS

NSD Structure

Image Added

Image Added

SDC supports NSD design that meets the following requirements.

• The NSD shall reference the VNFDs applicable to its constituent VNFs.
• The NSD shall include the VLDs applicable to the VLs used by the NS to interconnect its constituent NFs.
• The NSD shall reference the PNFDs applicable to its constituent PNFs.
• The NSD shall include the descriptors of the VNFFGs applicable to the NS (stretch goal).
• The NSD shall support the capability to include or reference NS LCM scripts.
• The NSD shall support the capability to providing monitoring parameters to be tracked during the lifetime of a NS instance (stretch goal).
• The NSD shall support the capability to describe auto scale rules, associating criteria to scaling actions (stretch goal).
• The NSD shall include package security information enabling validating its authenticity and integrity.
• The NSD shall include a globally unique identifier for identifying each descriptor instance.
• The NSD shall include an identifier to select to controller compatible with the NSD.
• A VLD shall enable specifying the type of connectivity provided by the link between VNFs.

NSD Information Element

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

Image Added

Use Cases for Guilin

VCPE

The following is an example of VCPE model hierarchy. In VCPE, the E2E Service model includes one NS (vCPE). And the vCPE NS model includes vbng, vbrgemu, vgmux and vgw VNFs and a network VL.

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

Image Added

<example>

Image Added

• Test with vGW and VGMUX with a VL first.

Latest vCPE CSARs

The latest (Frankfurt) vCPE CSARs can be retrieved from the https://git.onap.org/demo/tree/tosca/vCPE_F. There are one NS CSAR and five VNF CSARs:

• ns.csar
• infra.csar
• vbng.csar
• vbrgemu.csar
• vgmux.csar
• vgw.csar

Other Use Case

To represent nested NS cases, we will choose another use case.

• TBD

NSD Design Process in SDC

VNF Composition

The following diagram depicts how SDC

1. creates a NSD, based on SOL001 NSD
   1. generates SDC AID DM for NS, based on SOL001 NSD
2. drags and drops constituent VFs
3. generates SOL007 NS package

VL Composition

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

VNFD Composition

The NSD references the VNFD of a constituent VNFs.

• Drag and drops onboarded VNFs

VNFD 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

VNFD Information element

The following depicts the VNFD information element.

Image Added

Image Added

SapD Composition

SapD fulfills the following information element.

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

• The original vendor package format could be one of the following.
  • Vendor package including certificate and signature (Zip format)
  • Vendor package without certificate and signature (CSAR format)

ETSI Catalog Manager Enhancements

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

Image Added

Package Distribution Components Interactions

The following diagram depicts the ETSI package distribution. 

ETSI Package Distribution Flows

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

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

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

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

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

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

SDC SOL004/SOL007 VNF Package Security

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

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

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

Image Added

Package Security

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

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

SOL001 Mapping to SDC AID DM

The following diagram depicts SOL001 Mapping to SDC AID DM.

Current Mapping Support (as of Frankfurt)

Image Added

Note: AAI impacts are under discussion.

Presentation Slide (as a summary)

The following is a presentation slide that summarizes the Mapping.

Note:

The following is being implemented for the Guilin release:

• SOL007 Design and SOL004 Onboarding
• ONAP ETSI-Alignment Modeling Hierarchy (partially)
  • NS Mapping
  • NS-Level VirtualLink (between VNFs) Mapping

The following mapping will be implemented in the Honolulu release:

• VNF Mapping
• VDU and VFC Mapping
• PNF Mapping
• SOL001 VNFD and SDC AID DM VF Template Mapping
  • VF-Module Deduction from SOL001 VNFD

SOL007 Design and SOL004 Onboarding

• SDC takes the vendor provided package and adds some files or changes files and meta data according to SDC procedure.
• SDC NS/VNF/PNF Onboarding Procedure and Original Vendor VNF/PNF Package Handling
  • SDC onboarding enhancement was made to the SDC Dublin to support SOL004 PNF/VNF onboarding with .zip and .csar file extensions. We continue to support the current onboarding mechanism with some enhancements.
  • SOL007 NS onboarding (stretch goal for Guilin) will follow the same procedure; i.e., storing the vendor SOL007 NS package into the “ETSI_PACKAGE” directory.
  • SOL007 NS design will allow users to build SOL007 NS package including SOL001 NSD from scratch
  • SDC VSP and Resource csar files have the “ETSI_PACKAGE” directory, which will contain the original vendor VNF/NS/PNF package.
    • The “ONBOARDED_PACKAGE” directory name will be changed to “ETSI_PACKAGE” as a common ETSI directory name. This change is necessary to support design of SOL007 package
    • ONAP-ETSI Catalog Manager will be extracted the ETSI packages from the “ETSI_PACKAGE” directory.
    • The VNFM and external NFVO use the original vendor VNF/NS/PNF packages through ETSI Catalog Manager.
• SDC provides mapping from ETSI SOL001 NSD/VNFD/PNFD (PNF in the future) to SDC AID DM
  • See the subsequent slides for mapping.
• Note: ETSI 3.3.1 handling will be discussed separately.

SDC CSAR for NS structure

ONAP Service CSAR
  |-- Artifacts
        |-- ETSI_PACKAGE
              |-- etsi nsd csar
        |-- <VF 1>
              |-- Deployment
                    |-- ETSI_PACKAGE
                          |-- etsi vnf package
            ...
        |-- <VF n>
              |-- Deployment
                    |-- ETSI_PACKAGE
                          |-- etsi vnf package

Mapping of ETSI Information NS-related Elements with TOSCA types

• For E2E (OSS Service) modeling, use org.openecomp.resource.abstract.nodes.service
  • E2E (OSS Service-Level) is outside of ETSI scope, and it could be ONAP-specific that is orchestrated by ONAP SO
  • The E2E (OSS Service-Level) model references/includes associated NSs
  • For the E2E service level, the org.openecop.resource.abstract.nodes.service type is still used as the base type of the service. SDC will use the ETSI SOL001 NS type and attach the NSs to the E2E (OSS Service).
• For NS modeling, use tosca.nodes.nfv.NS
  • ONAP SO-NFVO, VFC and external NFVO manage the NS models and packages

ONAP ETSI-Alignment Modeling Hierarchy

• The following diagram depicts ONAP ETSI-Alignment Modeling hierarchy.
• Note: the ONAP VFC model represents the design time VFC, not runtime VFC instance(s).
• Note: VNF, VFC and PNF node types continue to be discussed for the Honolulu release. 

Mapping between SOL001 Data Model and SDC AID DM

The following summarizes the mapping between two models:

Current SDC Resource Models

SDC: nfv-types					SDC: heat-types
ETSI NFV IE	SDC Descriptor / SOL001	TOSCA Type	Derived from		SDC Descriptor	TOSCA Type	Derived from
NSD	nodes.yml / SOL001	tosca.nodes.nfv.NS	tosca.nodes.Root		Generic_Service.yml	org.openecomp.resource.abstract.nodes.service (use it for both E2E (OSS Service) and NS)	tosca.nodes.Root
	NSD.yml	org.openecomp.resource.vfc.NSD	tosca.nodes.Root		N/A
SapD	SOL001	tosca.nodes.nfv.Sap	tosca.nodes.Root
NsVirtualLinkDesc	SOL001	tosca.nodes.nfv.NsVirtualLink (there is tosca.nodes.nfv.VnfVirtualLink)	tosca.nodes.Root		vl.yml	org.openecomp.resource.vl.VL	tosca.nodes.network.Network
					extVl.yml	org.openecomp.resource.vl.extVL	tosca.nodes.Root
					internalVl.yml	org.openecomp.resource.vl.internalVL	tosca.nodes.network.Network
	extZteVL.yml	tosca.nodes.nfv.ext.zte.VL	tosca.nodes.Root
Pnfd		tosca.nodes.nfv.PNF	tosca.nodes.Root		Generic_PNF.yml	org.openecomp.resource.abstract.nodes.PNF	tosca.nodes.Root
Vnfd	VNF.yml	tosca.nodes.nfv.VNF	tosca.nodes.Root		Generic_VF.yml	org.openecomp.resource.abstract.nodes.VF	tosca.nodes.Root
Vnffgd		tosca.groups.nfv.VNFFG	tosca.groups.Root		forwardingPath.yml(?)	org.openecomp.nodes.ForwardingPath	tosca.nodes.Root

NSD Mapping to SDC AID DM

Initial Input

• Internal NSD representation

NSD Mapping to SDC AID DM

A benefit of mapping an onboarded ETSI NS to the internal representation of an ONAP Service is that the ETSI NS can access the standard ONAP runtime functionality implemented or planned for support of ONAP Services.

SOL001 NSD mapping to/from NS SDC AID DM

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

SOL001 NS

<tosca.datatypes.nfv.NsProfile>

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

SDC nfv-types

Image Added

SDC nfv-types/NSD

SDC TOSCA repository: /catalog-be/src/main/resources/import/tosca/nfv-types/NSD/

• need to update to tosca_simple_yaml_1.2

<nodes.yml: org.openecomp.resource.vfc.NSD>

  org.openecomp.resource.vfc.NSD:

    derived_from: tosca.nodes.Root

    description: ECOMP Allotted Resource base type all other allotted resources node types derive from

    properties:

      nsd_id:

        type: string

        required: true

        description: ID of the NSD

      nsd_designer:

        type: string

        required: true

        description: Designer of the NSD

      nsd_version:

        type: string

        required: true

        description: Version of the NSD

      nsd_name:

        type: string

        required: true

        description: Name of the NSD

      providing_service_uuid:

        type: string

        required: true

        description: The depending service uuid in order to map the allotted resource to the specific service version

      providing_service_invariant_uuid:

        type: string

        required: true

        description: The depending service invariant uuid in order to map the allotted resource to the specific service version

      providing_service_name:

        type: string

        required: true

        description: The depending service name in order to map the allotted resource to the specific service version

    requirements:

    - virtualLink:

        capability: tosca.capabilities.network.Linkable

        relationship: tosca.relationships.network.LinksTo

    capabilities:

      virtual_linkable:

        type: tosca.capabilities.network.Linkable

VNFD Mapping to SDC AID DM

SOL001 VNF mapping to/from VNF SDC AID DM

• ONAP previous analysis
  • There is no 1:1 mapping between the SOL001 tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.nodes.VF.
    • SDC VF node types has very few properties.
    • a lot of common properties are added to each node type created by SDC
    • new common properties are mainly about networking and ONAP specific properties
  • There is no clear mapping logic between the current node types
    • SDC creates new data type as ONAP deployment configuration.
  • In ETSI, the descriptor_id is used to reference to the VNF, but in ONAP, the UUID is used to reference to the VNF.
• Solutions
  • map between SOL001 VNF and SDC AID DM VNF selectively.
    • data in the SOL001 that would be considered Cloud Provider automation data could be remained unmapped
    • Examples of Service Provider data that would need to be mapped in order to drive ONAP automation would include:
      • HPA requirements needed by OOF to determine cloud feasibility
      • Input parameters passed to the Cloud provider
    • ONAP wants to distinguish between the mode/data required to drive ONAP functionality from a Service Provider perspective from any ancillary mode/data required to drive Cloud Provider automation.
  • UUID and invariantUUID must not be modeled as metadata type, per TOSCA YAML because the data provided within metadata, maybe ignored by TOSCA orchestrator and should not affect runtime behavior. 
  • Identify Cloud Provider automation-related data and remove it from the mapping
  • Identify Service Provider data and map it to SDC AID DM
  • ONAP SO NFVO uses SOL001 VNF; other ONAP runtime components could use the new mapped org.openecomp.resource.abstract.nodes.ETSI.VNF

Current VNF Modeling in ETSI and SDC

Solutions:

There are two options. For now, we chose the option A. The option B is under discussion.

Option A (chosen):

Define a new data type based on the org.openecomp.resource.abstract.nodes.VF with ETSI SOL001 VNF data type attributes.

• Make the org.openecomp.resource.abstract.nodes.ETSI.VNF a superset of both tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.node.VF
• During VNF onboarding, SDC copies SOL001 VNF attribute contents to the corresponding attributes in 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

Option B:

Define a new data type based on the tosca.nodes.nfv.VNF with SDC AID DM VNF data type attributes.

• SDC AID DM VNF data type attributes will be handled as the 'additionalAttributes', which is a map of key, value pairs.
• Those attribute contents will not be mapped back into the SOL001 VNF (reverse mapping). For that case, only the SOL001 VNF corresponding attributes will be copied.