5G - PNF Pre-Onboarding & Onboarding
Authors: @Benjamin Cheung , @Michela Bevilacqua [Ericsson] , @Zu Qiang
Table of Contents
- 1 Table of Contents
- 2 USE CASES (Scope)
- 3 BUSINESS DRIVER
- 4 INTRODUCTION
- 5 PROJECT IMPACT OVERVIEW
- 6 DEVELOPMENT STATUS
- 7 USE CASE ANALYSIS, SUPPORTING MATERIAL
- 7.1 PACKAGE DELIVERY: ARTIFACTS & PRODUCTS
- 7.2 PACKAGE DELIVERY: PACKAGE CREATION (VENDOR PROVIDED)
- 7.3 PACKAGE DELIVERY: PNF PACKAGE FILES & DIRECTORIES
- 7.4 PNF PACKAGE SECURITY
- 7.5 PNF PRE-ONBOARDING: VNF-SDK ENHANCEMENTS
- 7.6 PNF ONBOARDING PACKAGE: PNF ONBOARDING PACKAGE LOADED
- 7.7 DESIGN TIME ACTIVITIES: SDC ONBOARDING PACKAGE
- 7.8 DESIGN TIME ACTIVITIES: SDC ONBOARDING PACKAGE MAPPING INTO INTERNAL PACKAGE
- 7.9 DESIGN TIME ACTIVITIES: SDC ONBOARDING PACKAGE INTO SDC CATALOG
- 7.10 DESIGN TIME ACTIVITIES: LICENSING MANAGEMENT & SCHEMA
- 7.11 RUN TIME ACTIVITIES: CSAR INGESTION TO ONAP RT PLATFORM COMPONENTS
- 7.12 ROADMAP - Pre-Onboarding/Onboarding Evolution per Release
- 8 REQUIREMENTS
- 9 TESTING
- 10
- 11 APPENDIX SUPPORTING DOCUMENTS
USE CASES (Scope)
BACKGROUND: (R3 CASABLANCA)
In Casablanca Release, the PnP Use Case covered :
- manually onboarding a PNF at Design Time
- PNF Instantiation in ONAP at Run Time
In Casablanca Release, the PnP Use Case did not cover the PNF pre-onboarding / onboarding.
PNF R4 Dublin SCOPE
This is the scope (what is agreed to be delivered) in Dublin for this Use Case.
Introduce pre-onboarding and onboarding a vendor PNF onboarding package in ONAP for 5G and other use cases.
Proposed new UCs in Dublin :
PNF Pre-Onboarding
PNF Onboarding
Reference Presentation provided to 5G UC meeting (Nov 15th, 2018): ONAP Dublin_PNFOnboarding.pptx
PNF PRE-ONBOARDING SCOPE (R4 Dublin)
The pre-onboarding step is optional and it can be used to verify a vendor PNF onboarding package/Archive format by VNF SDK tools
Use Case Notes
Use Case shall be aligned as much as possible to the ONAP VNF package pre-onboarding UC
PNF archive is provided by a vendor and it will include PNFD (based on ETSI SOL001v2.5.1) and all the artifacts required by ONAP (non ETSI NFV artifacts provided managed as Non-MANO artifact (i.e. FM and PM dictionary)). The PNF package structure shall be based on ETSI SOL004v2.6.1.
This UC shall be aligned as much as possible to the ONAP VNF package pre-onboarding U/C the artifacts required by ONAP (non-ETSI NFV artifact provided managed as Non-MANO Artifact (i.e. FM Meta Data and PM dictionary)
PNF ONBOARDING SCOPE (R4 Dublin)
A vendor provided PNF onboarding package can be on-boarded in ONAP. The onboarding step is mandatory to onboard artifacts and descriptor provided by the vendor.
Use Case Notes
ONAP SDC shall also continue to support manually onboarding a PNF as in Casablanca Release
ONAP SDC shall also continue to support VNF onboarding as in Casablanca Release
PNF descriptor and artifacts can be onboarded through ONAP and stored in ONAP catalogues in order to be then utilized also at run time.
The PNF package structure shall be based on ETSI SOL004v2.6.1. And the PNFD is based on ETSI SOL001v2.5.1
BUSINESS DRIVER
This section describes Business Drivers needs.
Executive Summary - Pre-onboarding & onboarding is used to "upload" a vendor's PNF onboarding package which contains the descriptor and artifacts for the PNF. (VNFs are handled with a different wiki)
Business Impact - Pre-onboarding & onboarding is a business imperative because it is vital because ONAP needs to be able to "load" PNF descriptor and artifacts which define the PNF capabilities and functionalities.
Business Markets - Applies to PNFs within a service operator's network. Applies to all markets that might use PNFs including Wireless, wireless, optical.
Funding/Financial Impacts - This use case can potentially save a large amount of OPEX because there is a lot of time associated with manually onboarding a PNF which would have to be done if this use case were not implemented.
Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider.
INTRODUCTION
PNF PRE-ONBOARDING & ONBOARDING OVERVIEW
| Descriptor, Artifacts and Package Delivery | PNF Package Pre-onboarding | ONAP onboarding process, PNF Package onboarding | ONAP Design Time activities | ONAP Run Time activities |
|---|---|---|---|---|---|
WHEN | PNF delivery time | Pre-Onboarding activities | Onboarding Activities | ONAP Design Time Activities | ONAP Run Time |
WHO | Vendor | Technology Specialist | Technology Specialist Asset Manager | Service Designer Operations Specialist | Operations Specialist |
WHAT | Descriptor, Artifacts and Package delivery | PNF Package NF validation Activities | PNF Package, PNF Descriptor PNF Onboarding SDC Meta-data added (vendor onboarded CSAR to SDC onboarded CSAR) | ONAP Common Information Model SDC Data Model 5G Service Definition Service Design SDC Model mapping | 5G Service Instantiation PNF Instance A&AI PNF Instance |
ETSI NFV reference | SOL001 PNFD SOL004 Package | ETSI SOL004 Package | ETSI SOL001 PNFD, SOL004 Package |
| - |
PNF PRE-ONBOARDING & ONBOARDING DUBLIN WORK
STAGE | DESCRIPTION | DELIVERABLE |
|---|---|---|
(1) Package Delivery | Producing and collecting NF artifacts for a NF package. Vendor provided. Dublin Priorities are the artifacts & descriptor files of the PNF package. These include: 1. PNFD, 2. NF Registration YAML File (for VES event definition), 3. PM Dictionary & Schema. | PNF Onboarding Package |
(2) PNF Pre-Onboarding | VNF SDK: Enhance VNF-SDK to be able to validate (optionally) the on-boarding PNF package. Optionally, create a PNF onboarding package through VNF-SDK. VNF-SDK can: [1] (optionally) Create a PNF package. VNF-SDK optionally can extend a package and provide as output a new onboarding PNF package the SDC will use. Package, output of the VNF SDK (as optional step) must be compliant and aligned to the PNF package onboarding format provided by the vendor as both can be used as input to SDC for the ONAP onboarding package. [2] (optionally) Validate a PNF package. Validate the package according to available VES specifications and onboarding package structure. SDC/CDS: Load PNF model & Controller blue-print for PNF orchestration and Network communication. Before R3/Casalanca a Preload interim solution was used for Network Assignments. | VNF SDK validates PNF onboarding Package |
(3) PNF Onboarding | In PNF Onboarding, SDC takes the PNF vendor-provided package and adds meta-data content and recomposes a new CSAR into the SDC expected directory structure format. It copies the PNF vendor-provided PNF onboarded package and put it into a vendor-provided directory. Onboarding the Package: SDC Enhancements need to be made to onboard the PNF Package and enter into the SDC Catalog The CSAR package provided by SDC as output of the onboarding process. This work will include the PNF artifacts into CSAR package. | SDC CSAR Package of PNF Onboarded Package (CSAR) |
(4) Design Time Activities (SDC) | Design time activities occur where an operator and define services. A Service is defined, and a new CSAR package is produced with service-related artifacts associated with outputs of SDC ready for distribution to other ONAP run-time components. | SDC CSAR (output) |
(5) ONAP RT Component Ingestion of CSAR package & PNF Onboarding package artifacts | Proper Distribution & Reception of SDC CSAR: The SDC CSAR package is distributed by SDC to ONAP Run-Time Components. Chances need to be made to verify the reception of the CSAR and use of the CSAR by the Components. We need to insure that the distribution of PNF artifacts does not break the ONAP platform components. (for example SO looked for Heat Templates, which were only applicable for VNFs). Some ONAP RT assume that any package notification only have VNF artifacts. In practice, there is only the subscription of artifacts (listeners) and the distribution of the PNF package, we need to make sure this behaves correctly and that there are no errors. Pre-integration checks and validation that the distribution of PNF artifacts will not cause side effects. Want to insure that FM & PM artifacts are distributed properly. PM dictionary would be used in DCAE & PM Mapper. FM Meta Data is new, and from the start (what is new in Dublin) is that it is being used for both VNFs and PNF. | SDC CSAR (service artifacts from SDC) |
PROJECT IMPACT OVERVIEW
The following table gives an overview and summary of the ONAP RT Component Project impacts.
COMPONENT | IMPACT DESCRIPTION | PTL |
|---|---|---|
5. RESOURCE VIEW TO DISPLAY PNF ONBOARDED ARTIFACTS
| @Ofir Sonsino | |
PACKAGE VERIFICATION - PNF package format verification PNF PACKAGE FORMAT PACKAGE USAGE - Package for PNF Onboarding Package for use in VNF SDK | @victor gao | |
Modelling Subcommittee | PNFD MAPPING - Onboarded PNFD to platform PNFD mapping THis activity is traced as a sw implementation task in SDC but PNFD mapping will be discussed as part of the ONAP Resource Data Model. | @Hui Deng @Anatoly Katzman |
| @Steven wright |
DEVELOPMENT STATUS
Project / PTL | JIRA | Description | Status |
|---|---|---|---|
SDC @Michael Lando @Vitaly E @Ofir Sonsino
|
| PTL notified (11/19 ) Code is ready for M4(11/04) | |
VNF SDK @victor gao VNFSDK Model Package @Andy Mayer
|
| VNFSDK PTL notified (12/05) VNF SDK Model, Package notified (11/30) Scope planned for Dublin completed ...except from package security item: E2E work tracked in this Jira item: | |
RESOURCE DATA MODEL @Anatoly Katzman | No JIRA ticket required, project can help to identify the mappings required in SDC in Dublin timeframe |
| PTL notified (11/26) |
VNF RQTS @Steven wright |
| PTL notified (01/16) |
USE CASE ANALYSIS, SUPPORTING MATERIAL
The following material is used during Dublin timeframe as input for discussion. It is subject to updates during Dublin timeframe. A final version will be available by Dublin signoff.
PACKAGE DELIVERY: ARTIFACTS & PRODUCTS
PACKAGE DELIVERY | ONBOARDING PROCESS | DESIGN TIME | RUN TIME |
|---|---|---|---|
NF Descriptor | NF Descriptor Model | SDC Data Model | A&AI PNF Data model, PNF instance |
VES event registration file/ PM dictionary | artifact | SDC Catalog | Run time Catalog
|
Informational Artifacts | artifact | SDC Catalog | Run time Catalog |
Configuration Models and Files, (including Ansible Playbooks) | artifact | SDC Catalog | Run time Catalog |
Multiple artifacts can be provided by a vendor in the Package. A list of the supported artifacts by ONAP will be finalized during Dublin timeframe.
Note about the picture: NF Registration stands for VES event registration file. Info model provided in the picture, just as example
PACKAGE DELIVERY: PACKAGE CREATION (VENDOR PROVIDED)
The PNF Onboarding Package could contain the following things:
ARTIFACT | DESCRIPTION |
|---|---|
PNF Descriptor | PNF Descriptor. The PNFD is a model which describes the requirements and capabilities of the PNF. The ETSI SOL 001 specification also suggests a model that can be used for a PNFD. This could be a TOSCA definition of the PNF. MANDATORY |
NF Registration | Definition of VES Events. The NF Registration is defined by the VES Registration specification. You can read about the VES Event Listener here: Service: VES Event Listener 7.0.1 MANDATORY |
Licensing | NF Licensing information that needs to be included in the Package N/A for PNF |
Informational Artifacts | Informational artifacts include:
OPTIONAL |
Configuration Files | Configuration Files related to the NF for configuration management OPTIONAL |
|
|
Ansible Playbooks | Ansible Playbooks to interact with NF. These are anticipated to be used with the communication of the NF controller to the NF. This can be seen in the PNF Plug and Play Wiki: 5G - PNF Plug and Play OPTIONAL |
PACKAGE DELIVERY: PNF PACKAGE FILES & DIRECTORIES
The onboarding PNF Package must be defined as specified as ETSI SOL004v2.6.1 + NFV CR NFVSOL(18)000746r3
The package structure must be a CSAR with TOSCA-Metadata as specified in SOL004 section 4.1.2
The TOSCA.meta file keyname extension: SOL004 section 4.1.2.3
EXAMPLE of the TOSCA.meta
TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-By: Ericsson
Entry-Definitions: Definitions/MainServiceTemplate.yml
ETSI-Entry-Manifest: MainServiceTemplate.mf
ETSI-Entry-Change-Log: Artifacts/ChangeLog.txt
END of EXAMPLE
The PNF manifeat file must contains
metadata with following keynames: pnfd_ provider, pnfd_name, pnfd_release_date_time, pnfd_archive_version
a list of all files contained in or referenced from the package with their location, expressed using a Source: location/name key-value pair.
Non-mano-artefact tag: ONAP defined tags
EXAMPLE of the PNF manifeat file
metadata:
pnfd_name: gNB
pnfd_provider: Ericsson
pnfd_archive_version:1.0
pnfd_release_date_time:2018-12-03T08:44:00-05:00
source: Definitions/MainServiceTemplate.yaml
source: Definitions/etsi_nfv_sol001_vnfd_2_5_1_types.yaml
source: Definitions/etsi_nfv_sol001_pnfd_2_5_1_types.yaml
non_mano_artifact_sets:
onap_ves_events:
source: Artifacts/Events/VES_registration.yaml
onap_pm_dictionary:
source: Artifacts/Measurements/PM_Dictionary.yaml
onap_yang_module:
source: Artifacts/Yang_module/Yang_module.yamlonap_ansible_playbooks:
source: Artifacts/Playbooks/playbook.yml
onap_others:
source: Artifacts/scripts/install.sh
source: Artifacts/Informational/user_guide.txt
source: Artifacts/Other/installation_guide.txt
source: Artifacts/Other/review_log.txt
END of EXAMPLE
The following diagram illustrates a basic PNF package and some suggested file structure and content in the directories.
The PNF package is expected to be a CSAR package with file extension .csar.
PNF PACKAGE SECURITY
According to ETSI SOL004 v2.6.1 the onboarding package shall be signed. ETSI SOL004 provides two options:
Option 1 - One Digest for each components of the VNF package. The table of hashes is included in the manifest file, which is signed with the VNF provider private key. A signing certificate including the provider’s public key shall be included in the package.
Option 2 - The complete CSAR file shall be digitally signed with the provider private key. The provider delivers one zip file consisting of the CSAR file, a signature file and a certificate file that includes the VNF provider public key.
In Dublin release option 2 is going to be implemented in SDC.
The VNF/PNF package authenticity and integrity is ensured by signing the CSAR file with the provider private key. The digital signature is stored in a separate file.
The VNF/PNF provider shall also include an X.509 certificate in a separate file with extension .cert or, if the signature format allows it, in the signature file itself. The VNF/PNF provider creates a zip file consisting of the CSAR file with file extension .csar, signature and certificate files. The signature and certificate files shall be siblings of the CSAR file with extensions .cms and .cert respectively.
Only CMS signature file format is supported in this release.
At pre-onboarding of the PNF/VNF package, VNFSDK tool could verify the signature of the complete CSAR package with the provider’s public key
At onboarding of the PNF/VNF package, SDC could verify the signature of the complete CSAR package with the provider’s public key.
At onboarding, SDC is expecting package file extension as following:
Heat template: .zip
TOSCA without package security: .csar
TOSCA with package security (option 2): zip file consisting of the CSAR file, a signature file and a certificate file .
PNF PRE-ONBOARDING: VNF-SDK ENHANCEMENTS
VNF SDK is (optionally) responsible to validate the PNF package provided by the vendor.
VNF SDK can also be used (optionally) to create a PNF package.
Today, optionally, the VNF SDK is also able to provide
We expect the VNF SDK development to be able to reuse much of the functionality from VNF SDK, format delivery, processing are all the same except HEAT deployments templates are not used (as they do not apply to PNFs).
The VNF SDK will be used to VALIDATE the PNF Onboarding Package
It is possible for a user to bring in the PNF Onboarding Package (provided by a vendor) without the use of the PNF SDK tools.
Some of the NF artifacts are created by the SDC tool.
[INVESTIGATE] What are artifacts that SDC adds during the Onboarding process, looking at SDC supported artifact types, possibly VENDOR LICENSE and MODEL INVENTORY (are there others?)