ETSI Alignment Support

• Resource commitment:
  • Ericsson: Byung-Woo Jun
  • CMCC: Yan Yang
  • Verizon: Fernando Oliveira
• Usecase:
  • Ericsson: Byung-Woo Jun
  • CMCC: Yan Yang
  • Verizon: Fernando Oliveira
• TSC Contact:
  • Ericsson: Stephen Terrill
• Participating ONAP Projects:
  • SO, SOL003 Adapter, SOL005 Adapter
  • SDC
  • AAI
  • SDNC

In the Frankfurt release, the following ETSI Alignment features will be supported by leveraging:

• SOL004 including SOL001 VNFD
• SOL003 APIs
• SOL005 APIs
• ETSI Catalog Manager
• SOL003 Adapter 
• SOL005 Adapter

Table of Contents

Use Cases

• ETSI Package Management Use Case
  • SOL004 VNF/PNF/NS Package includes SOL001 VNFD/PNFD/NSD with the original vendor package
  • SOL004 VNF/PNF/NS Package Security
  • SO ETSI Catalog DB enhancement, by leveraging ETSI Catalog Management Microservices
• ETSI Catalog Management Use Case
  • ETSI Catalog API Management
  • ETSI Catalog Database
• ETSI-Alignment SOL003 Adapter Use Case
  • Package Management for SVNFM
  • Granting Enhancement with HPA
  • Query
  • Modify (TBD)
  • Policy-based Scaling (Stretch goal)
  • Security between the Adapter and VNFMs
  • Additional operations will be determined
• ETSI-Alignment SOL005 Adapter Use Case
  • Package Management for External NFVO
  • Security between the Adapters and External NFVOs
  • Additional operations will be determined

Feature Descriptions

Epic and User Story

Architecture and Design

The following sections describe ETSI-Alignment architecture and design.

SOL003 VNFM Adapter Architecture for Frankfurt

The diagram depicts SOL003 VNFM Adapter Architecture.

1. VNFM Adapter exposes its NBI to any VNFM Adapter client
   1. VNFM Adapter continues to be a SO microservice component.
   2. VNFM Adapter will be registered to MSB.
   3. a VNFM Adapter client (e.g., GNFC) will locate the VNFM Adapter through MSB.
2. Interfaces are refactored to be generic (accessed by other ONAP/External components) - TBD
   1. the VNFM Adapter NBI will be enhanced for additional SOL003 operation support.
3. SDC CSAR including the SDC internal model and the vendor original SOL004 package is supported
4. SO leverages ETSI Catalog microservice for ETSI-based NS, VNF and PNF
5. VNFM Adapter retrieves VNF package from Catalog Manager
6. VNFM Adapter Client uses MSB to locate the VNFM Adapter
7. VNFM Adapter locates a VNFM based on a better VNFM locating mechanism
8. VNFM Adapter and SVNFM support additional SOL003 operations, possibly including modification for configuration
9. VNFM Adapter and SVNFM support authentication and authorization
   1. AAF will be used for authentication and authorization
   2. But, vendor SVNFMs may use their own AA mechanism
10. VNFM Adapter interfaces with OOF to support HPA-support granting (see the Granting enhancement section)
11. For the integration testing, the VNFM Simulator in the CSIT container will be used.

SOL003-based Operation Sequence Flows

• Create / Instantiate VNF
  • It is supported in the Dublin release, but it needs to be enhanced to leverage the ETSI Catalog Manager.
• The following sequence flows depicts the SOL003 Create/Instantiate operations by leveraging the above architecture. 

• Terminate/Delete VNF
• Query VNF

SOL005-based Operation Sequence Flows

Need to add

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

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 – Ericsson contribution in Dublin
   1. PNF onboarding was tested
   2. VNF onboarding is being tested in El Alto / 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 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

Communication Security for SOL005 and SOL003 APIs

• Requirement: External NFVO and SVNFM need to validate incoming ETSI package
• SO queries the package thru SDC
• SO stores Service + Non ETSI model
  • Not all VNFD needs to be transformed to the SDC AID DM - TBD
• SO stores ETSI / vendor VNF package CSAR or ZIP – the supported format is TBD based on the security requirement
• SOL003 Adapter provides VNF package management APIs
• SOL005 Adapter provides NS package management APIs
• If CSAR-format is chosen, NFVO/SVFNM trusts integrity (authN and authZ) between the Adapters and NFVO/SVNFM.
• For certificate validation, we need to resolve Certificate Authority (CA) placement.

SO ETSI Catalog DB Support for NS, VNF and PNF

For the ETSI package storage, SO does the following:

• SO (SDC Controller component) queries the package from SDC
• SO stores ETSI (including SDC AID DM) + vendor VNF package CSAR or ZIP
  • Not all VNFD needs to be transformed to the SDC AID DM - TBD
• For Non-ETSI models (Service + Non-ETSI Resource), SO will use the existing SO embedded Catalog DB

Instead of building ETSI Catalog management in SO, SO will leverage the existing ETSI Catalog Manager function.

• Consideration of leveraging VF-C Catalog Microservices for the NS, VNF and PNF catalog support, https://wiki.onap.org/pages/viewpage.action?pageId=63996543
  • VFC Catalog Manager function consists of two microservices: VF-C DB and VF-C Catalog. Deployment of these microservices is independent of VF-C, and the microservices have no dependency on other VF-C components – a good stepping stone towards common ETSI Catalog management
  • VFC Catalog Manager will be enhanced to handle the vendor package in the ONBOARDING_PACKAGE directory.

1. VF-C Catalog DB Microservice

• Database: nfvocatalog (vfc-nfvo-catalog-createdb.sql // create db scripts)
• Database Table (vfc-nfvo-catalog-createobj.sql // create tables scripts)
• Catalog_NSPackage
• Catalog_VNFPackage
• Catalog_PNFPackage
• Catalog_SoftwareImageModel

2.VF-C Catalog (API) Microservice

• vfc-catalog docker
• VFC Catalog REST APIs (following is part of Swagger REST APIs), https://docs.onap.org/en/latest/_downloads/0fea611e8b07fb4042e1a66ce202898c/CATALOG_API_Specification_v1.json

SDC - SO SDC Controller - ETSI Catalog Manager

• SO SDC Controller module (ASDCController and ToscaResourceInstall) needs to be updated for handling SOL004 packages including SOL001 VNFD and PNFD.
• Service-level catalog and other non-ETSI catalog (SDC AID DM) will be stored in SO Catalog DB.
• VNF/PNF/NS-level catalog handling would be simplified:
  • By using the ETSI Catalog Manager, ETSI VNF/PNF/NS-level catalogs (i.e., original vendor packages) will be stored in ETSI Catalog DB
  • SO itself does not need to manage ETSI-based VNF LCM; i.e., delegates the LCM to VNFM through the SOL003 VNFM Adapter
• In Frankfurt, VNF package management is the first focus.
• ETSI Catalog Manager POST API will be used to store the VNF packages
  • POST /api/catalog/v1/vnfpackages // passing csarId, vimIds and labVimId

• Q&A:
  • How does VFC handle VNF packages from SDC? Does it use SDC AID DM? Does it use VF-Modules?
  • Answer:
    • VF-C supports SDC internal models with the original vendor package and ETSI-based VNF package
    • Currently, no VF-Module support from VF-C and SOL003 VNFM Adapter
    • VF-Module mapping and handling need to be sorted out.

ETSI Catalog Manager - SOL003/SOL005 Adapter

• ETSI Catalog Manager consists of two microservices:
  • ETSI Catalog API
  • ETSI Catalog DB
• ETSI Catalog Manager provides RESTful services to Adapters:
  • ETSI package management for the Adapters.
    • GET /api/catalog/v1/vnfpackages/{csarId}

• • • Need to pass artifacts (images) to VIM thru the Adapter
    • Get the original vendor VNF package
      • ETSI Catalog APIs will be enhanced to extract the original vendor VNF package from the ONBOARDING_PACKAGE directory
      • Does the vendor original package include VNF software image or path?
  • Retrieving VNFD for SOL003 Adapter
  • Retrieving NSD/VNFD for SOL005 Adapter
    • GET /nspackages/{csarId} // query NS package info
    • More SOL005 Adapter requirements are being collected.

SOL003 Adapter - SVNFM Operations

Package Management

• Query/Reading VNF package information (VNFM → SOL003 Adapter)
• Reading VNFD of an on-boarded VNF package (VNFM → SOL003 Adapter)
• Fetching an on-boarded VNF package (VNFM → SOL003 Adapter)
• Fetching a VNF package artifact (VNFM → SOL003 Adapter)

• Creating subscriptions for the package management (VNFM → SOL003 Adapter)

• Sending notifications for the package management (SOL003 Adapter → VNFM)

OOF-Based Granting (HPA support)

• During SO decompose processing, SO calls OOF for collecting homing information for the service.
  • Hardware Platform capability requirements are downloaded as part of the VNFD data
  • Current SO decompose processing goes up to the VF-Module level and collect homing info up to the VF-Module level.
    • Call the OOF APIs to perform the optimize service/VNF homing and placement
    • User the existing homing workflows to pass hardware platform capability requirements to OOF
  • If this processing does not work for the vendor VNF homing, we may want to use the second method, by calling OOF for VNF-level homing.
• VNFM Adapter - OOF
  • VNFM Adapter sends out homing requests to OOF (OSDF) containing resource info
  • OOF (OSDF) pulls all the related homing constraints from Policy
  • OOF (HAS) checks AAI database to pull region (flavor) information
  • OOF (HAS) communicates with Multi-Cloud to check cloud capacity (vims which fulfill the requirements)
  • OOF (OSDF) returns homing allocation solution to VNFM Adapter
  • OOF collects information as following:
  • Service and Resource Info, from: AAI
  • HPA Flavors/Capabilities/Capacity Info, from: AAI
  • Policy Models (Homing, PCI) from: Policy
  • Infrastructure Metrics Info (capacity), from: MultiCloud
  • Cloud Agnostic Intent Info, from: MultiCloud
  • PCI configuration data (not yet a part of SDC model)

SOL001 VNFD to SDC AID DM Mapping

TBD

SOL003 Operations

The following SOL003 operations will be supported:

• Package Management
• Grant enhancement
• Query of VNF
• Scaling (stretch goal)
• Modify
• Operation Status

SOL005 Operations

The following SOL005 operations will be supported:

• Package Management
• TBD

Authentication and Authorization for the VNFM Adapter and the VNFM

• Leverage AAF for authentication and authorization to secure communications among ONAP components and SVNFM and external NFVO (App-to-App AA). The following is input from AT&T. More to discuss…
  • OAuth2 is not yet used in ONAP. Start with HTTP Basic Authentication with HTTPS
  • Update an application pom file and add properties; i.e., no application code changes?
    • Remove Spring Security as well, as we cannot have both in place
  • There is no need to use the CADI Rest Client at all
  • The CADI filter can be configured to handle authorization; that is the method AT&T uses, or the application can enforce the authorization. It supports basic URI matching semantics
  • Generate certificates by AAF for HTTPS is the current gap.
• Authentication and Authorization on SOL003 and SOL005 APIs need to be supported.
  • HTTP Basic Authentication + TLS
  • OAuth2
  • Two-way TLS
• How does ONAP support vendor-specific SVNFM security (authentication/authorization)? It is under discussion.
  • Security between SOL003/SOL005 and SVNFM/NFVO
  • Each SVNFM can use their own security mechanism; i.e., non-AAF based
• Note:
  • Communications between SOL003/SOL005 Adapter and SVNFM/NFVO must be secured through HTTPS
  • SOL002 Adapter is facing the similar security requirements.

Open Issues

• Storing the original vendor VNF package with certificate and signature?
• Mapping between SOL001 VNFD to SDC AID DM, including ScalingAspect+Delta and VF-Module - Not all VNFD needs to be transformed to the SDC AID DM
• Deployment location of SOL003 Adapter
• How does ONAP support vendor-specific SVNFM security (authentication/authorization)?
• SOL007 (NS package) support is under discussion
• Certificate generation and distribution by AAF
• SOL005 Adapter requirements for the ETSI Catalog Manager
• Where (SOL003 Adapter, or SO NFVO) do we support VNF software image transfer to VIM?

The following sections describe the architecture, requirement and design details of each feature.

• ETSI Package Management Security
• SO ETSI Catalog Handling for NS and VNF/PNF Packages
  • ETSI Catalog Manager - SOL003/SOL005 Adapter
  • SDC - SO SDC Controller - ETSI Catalog Manager
• SOL001 VNFD Mapping to SDC AID DM
• SO VNFM Adapter Features for Frankfurt
• Additional feature details, please see the SOL003 Adapter and Roadmap below