ETSI Package Management (SDC Enhancements)- Guilin

Requirements & Use Cases

The following requirements are defined in the Guilin release - functional requirements proposed list, Guilin release - functional requirements proposed list

• Onboard ETSI SOL004 compliant VNF packages 
  • Support for onboarding ETSI v2.7.1 SOL004 CSAR Packages (Link to ETSI SOL004 v2.7.1 )
  • Support for onboarding ETSI v2.7.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2.7.1)
  • Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model
  • Support for using an ETSI v2.7.1 VNF in an ONAP Service
• Onboard ETSI SOL007 compliant Network Service Descriptor packages
  • Support for Cataloging and Preserving the original SOL007 package
  • Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model
  • Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using VF-C as the NFVO
  • Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO
• Design ETSI SOL007 compliant Network Service Descriptor packages
  • Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using VF-C as the NFVO
  • Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO
• Support for Nested/Hierarchical ETSI SOL001 v2.7.1 Network Service Descriptor

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 package inside the SDC package
   1. SOL004 package includes SOL001 VNFD/PNFD
   2. PNF onboarding has been tested
   3. VNF onboarding will be tested in El Alto / Frankfurt
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 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 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 ONBOARDED_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 ONBOARDED_PACKAGE directory.

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

Design NS

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.

Package Distribution Components Interactions

The following diagram depicts the ETSI package distribution. 

ETSI Package Distribution Flows

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

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 ONBOARDED_PACKAGE directory
  • If the original vendor package is a zip file with signature and certificate, the ONBOARDED_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)

NSD Mapping to SDC AID DM

Initial Input

• Internal NSD representation

TBD

VNFD Mapping to SDC AID DM (a possible option)

Initial Input 

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

• Mapping Scope Challenges and Suggestions 

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

    • See the ONAP MultiVim Proposal on the separation of concerns.
  • SDC AID  was created before a separation of concerns was envisioned, thus there are data structures in the SDC AID that would be considered Cloud Provider automation data and that we would likely take out of the SDC AID.
    • 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
    • There is probably some data in the SOL001 that would be considered Cloud Provider automation data. Any such data could remain unmapped
    • SOL001 content needed to drive ONAP automation (SO, OOF, SDNC, AAI, DCAE, etc.) would need to be mapped
  • The VNFM should not be aware of the VF Module structure, though the current SO-SDNC interactions to get assignment are by VF Module, and the VF Module entity plays prominent in AAI. That means there needs to be two adaptation points as we have discussed:
    • An SDC function to extract VF Module information from the SOL001 VNFD prior to distribution to runtime
    • A VNFM Adapter function to flatten the VF Module structure prior to handoff to the VNFM

• VF-Module Deduction from SOL001

• • There is an assumption that SDC transforms the vendor provided VNF package into ONAP-compliant one; i.e., deducing VF Modules based on VNFD ScalingAspects and Delta.
  • If SDC supports the transformation in Dublin time-frame, the transformed CSAR will be imported to SO, and SO VNF- and VF-Module-level workflows will manage VNF and VF Module topology towards SDNC with the following changes - Input from Gil Bullard (AT&T)
    • Today the VNF-level workflow has an embedded per-VF Module loop that a) retrieves the SDNC assignments for that VF Module, and then b) sends those VF Module-level assignments down to the VIM (e.g., OpenStack); the loop then moves to repeat "a" with the next VF Module. 
    • The new VNF-level flow will have the following sequences:
      1. an embedded per-VF Module loop that only retrieves the SDNC assignments for each VF Module; because the VIM is hidden from SO's sight, beneath the VNFM Adapter/VNFM.
      2. After finishing the loop, the SO workflows will send a structure  to the VNFM Adapter that includes the aggregate assignments at the VNF level.
      3. The VNFM Adapter aggregates all the VF-Module level assignments and transforms the assignment data into SOL003 API parameters before sending them to SVNFM
         1. The VNFM Adapter would need to be able to parse the VNF-level assignments structure received from SO to obtain the per-VDUconnection point assignments information and any per-VDU parameter information (e.g., hostnames)
         2. In doing so, the VNFM Adapter would need to know to ignore the VF Module groupings of these assignments
         3. Further know how to map the ONAP data structure and parameter names into the ETSI (e.g., VM=VDU, VNFC=VNFC, vNIC=vNIC, etc.). Note that the above assumes that in ONAP, as in ETSI, there will be a one-to-one correspondence between VM/VDU and VNFC.

• 
  

  • Assumptions for deducing VF-Module from SOL001 (Gil Bullard's input)

• • • SOL001 concept of Aspect+ScalingDelta combination is one to one with the ONAP concept of VF Module.
    • SOL001 concept of VDU is one to one with the ONAP concept of A&AI vServer
    • SOL001 concept of a connection point associated with a VDU corresponds to the ONAP concept of the same name, as does the understanding of the meaning of “internal” versus “external” connection point.
    • ONAP-compliant SOL001 VNF Vendors will be obliged to name their HEAT files using a naming convention that encodes the SOL001 Aspect+ScalingDelta names
    • ONAP-compliant SOL001 VNF Vendors will be obliged to name their SOL001 Aspect+ScalingDelta parameters using a naming convention that readily maps to the corresponding HEAT properties.  
    • In addition, if AT&T has already deployed such a vendor’s VNF into its network, the HEAT naming will remain invariant, and (at least) the (AT&T version of that) SOL001 be written to match it.
  • What to do
    • ONAP will be extended to incorporate the constructs of Aspect and Scaling Level.  This includes SDC’s, SOs, and A&AI’s modeling of these constructs and A&AI's ability to capture and SO’s ability to set/update the "current scaling level" of a VNF for a given Aspect. 
    • If ETSI in their SOL001 VNFD had defined a "ScalingDelta" in a straightforward manner, i.e., in terms of the VNFCs that comprise it, then it would be very easy to extract VF Module information from the VNFD.  (I would like to see ETSI define "ScalingDelta" in this manner, as opposed to the current way they do so. )  However, given that they did not, ONAP SDC would need to be extended to derive the VF Module “structure” from the SOL001 document through the algorithm below.  “Structure” in this case includes the VDU topology, connection points and associated parameters.  This algorithm will:
    • Determine the set of Aspects and corresponding VDUs and associated ScalingDeltas (step_deltas) from the SOL001.
    • Determine the set of ScalingLevels associated with each Aspect and the ScalingDeltas associated with each.
    • Translate the VDU-centric representation of ScalingDeltas (step_deltas) as per SOL001 to come up with a ScalingDelta-centric representation that captures the number and type of VDUs associated with that ScalingDelta across the various VDU types.
    • Create a VF Module object that corresponds to each ScalingDelta-centric representation of a ScalingDelta calculated above.
    • Fill in the details of the VF Module object based on the SOL001 data to represent the VDU connection points, associated Networks (internal or external), and associated Parameters.
    • Determine if there is an the artifact in the SOL004 package that is a HOT YAML whose file name corresponds (through a VNF vendor obligatory naming convention) to the Aspect+ScalingDelta from which this VF Module object was derived.  If so, associate that HOT file with the VF Module.
    • Name the VF Module based on a naming convention to capture the Aspect+ScalingDelta names
    • Determine and capture the mapping from each Aspect + ScalingLevel model for the VNF to the corresponding VF Module.
    • Given a desired state Aspect+ScalingLevel, will be able to calculate (from the SDC distributed mapping of Aspect+ScalingLevel to VF Module along with the current Scaling Level for this Aspect as per A&AI) the (ordered set of) VF Module(s) needed to take that VNF from the “current scaling level” to the desired level for that Aspect.
    • Note:  As an aside, SDC enhancements are being discussed. It is not clear if the SDC changes will be available in the Dublin time frame. some “stubbing off” SDC with a simulator could be suggested to at least prove in the run-time aspects of the solution.

SOL001 VNFD vs. ONAP SDC AID DM VNF