ARCHCOM: InfoFlow - Onboard Resource into SDC Flow

Owned by Benjamin Cheung
Oct 04, 2019
11 min read

1. Scope


DESCRIPTION: What do we mean by onboarding? A design time activity that brings "onboard" a resource into ONAP for later use in services. This flow describes the the onboarding of resources into SDC. This can apply to a new resource or an upgraded resource. A resource can be a VNF or PNF. Resources are onboarded into the SDC catalog during design time. This flow will describe what happens when a resource is brought into SDC. A resource in the SDC catalog can then be used in design time to define a service.

WHEN EXECUTED: During Design Time (before Run Time). When SDC Service imports a Resource into the SDC catalog.

PURPOSE: To bring in a VNF or PNF resource into SDC during design time.

INFORMATION PASSED: Vendor provided PNF onboarding package.

ACTORS:

  • Service Designer
  • Operations Specialist
  • SDC (Deployment Studio)

For more information and exploration you can visit the Pre-Onboarding/Onboarding Wiki at: 5G - PNF Pre-Onboarding & Onboarding

OVERVIEW PNF ONBOARDING


 - Types on Onboarding: TOSCA Onboarding, HEAT Onboarding, Manual Onboarding #@#

 - Note: xNF applies only to VNF and PNF (not to ANF - Alloted network function)


Stage view for PNF pre-onboarding/onboarding


PACKAGE DELIVERY - A vendor delivers a package that is to be onboarded. Note: that if you use Manual onboarding in SDC you do not need to have a PNF package.

PRE-ONBOARDING - In VNF-SDK can validate the PNF package (optional).

ONBOARDING - SDC allows you to create a xNF resource without a PNF package (manual onboarding). Before services are created, SDC creates resources. You can (1) use HEAT template, or (2) use TOSCA template, or (3) use a SDC GUI to manually create a resource.


OVERVIEW VNF ONBOARDING


There are 4 options when onboarding for a VNF in R4/Dublin. The first method (SOL004 based VNF onboarding) is new in R4/Dublin, the other methods already exist since R1.


1 SOL004 BASED TOSCA METHOD OF VNF ONBOARDING:

This method of VNF onboarding uses the ETSI SOL004 package specification.

For VNFs, the VNF onboarding procedure should be the same as the PNF onboarding procedure (described above) except testing has not been done yet.


2 HEAT-TEMPLATE BASED VNF ONBOARDING:

In this method, the VNF is onboarded via a vendor-provided HEAT-based package (see diagram below).

The VNF associated artifacts can be added manually added after the VNF is created.


3 TOSCA-BASED VNF ONBOARDING:

In the TOSCA based VNF onboarding procedure the VNF is created from ONAP and adding TOSCA descriptor as an artifact.

Vendor provides package, do on-boarding procedure.

This is a non-ETSI way of onboarding.

In this case, the VNF package is similar to SOL004 but it doesn't have all the keywords.


4 MANUAL VSP ONBOARDING:

A VNF (resource) can also be manually onboarded by creating the VNF resource manually.

In this method, the VSP is created manually (import to VF module), manually create VF module.


A diagram showing the TOSCA method of VNF onboarding



A diagram showing the HEAT Template based method of VNF onboarding


2. Pre-Conditions


ONAP is ready:

  • SDC - SDC is ready to ingest a package. Platform Information & Platform Data model are available.
  • CERTIFICATION STUDIO - The Certification Studio has certified the Package ready for distribution (VNF-SDK)
  • ONAP SOFTWARE - There is an ONAP installation. Software images loaded in OpenStack installation, where instantiation will happen (since no S/W image repository). Need to be available in Target Cloud Instances.

VENDOR deliveries received

  • DESCRIPTOR - Vendor PNF or VNF Descriptor Defined
  • VENDOR xNF PACKAGE - Vendor PNF or VNF Package with associated artifacts Delivered


2.1 xNF ONBOARDING PACKAGE

2.1.1 PNF PACKAGE

Vendors will prepare the Onboarding package (if you are not manually onboarding) The Onboarding Package Contains:

The following shows a diagram of the PNF Onboarding package which must be put together


2.1.2 VNF PACKAGE




A description of the things in the VNF and PNF Onboarding Packages SOL004 TOSCA-based Package (of the above diagrams).

  • PNF DESCRIPTORS (PNFD) - (Instantiation/Design Time) PNFD and VNFD have been mapped to ONAP platform data/information model. That is, the onboarded descriptor models (vendor provided) have been mapped onto ONAP platform data & information models that are useable and known to ONAP. For a RAN PNF these are driven from the ETSI SOL001 standards.
  • TOSCA METADATA - This file provided by the vendor describes the meta-information about the package. Notably it gives the directory location of key files in the package in the package as directory paths.
  • MANIFEST FILE - The Manifest file include basic information about the package itself.
    • 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-artifact tag: ONAP defined tags
  • VES EVENT REGISTRATION - This file describes all of the VES events that are supported by the PNF. It defines the possible events that the PNF can support, such as faults, heartbeating, pnfRegistration, Performance measurements. These are defined in the VES Event specification document available in the repository. The Event Registration also defines all of the fields that each of these events have to fill in when they send the event, and the details of the VES header also.
  • PM DICTIONARY - Performance Measurements and schema definitions. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
  • ANSIBLE PLAYBOOKS - Ansible playbooks define the "scripts" that are used for remote Ansible communications from ONAP towards a PNF or VNF. This is OPTIONAL, a PNF or VNF package does NOT necessarily have this artifact.
  • NETCONF YANG MODELS - Defines the NetConf Yang Models that are used for NetConf communications between ONAP and the PNF or VNF. This is OPTIONAL, a PNF or VNf package does NOT necessarily have this artifact. Starting in R3 (Casablanca release) and continuing into R4 (Dublin) a U/C w/ PNFs. VNFs available since R1.
  • CHEF COOKBOOKS - When Chef communications are supported between ONAP and the PNF or VNF, these define the communication playbooks that are used by Chef. This is OPTIONAL, a PNF or VNF package does NOT necessarily have this artifact.
  • MANUALS - Manuals can be included as informational artifacts in the VNF / PNF onboarding package provided by the vendor. These are typically additional information that can be provided (free-form) by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
  • HELP FILES - Help files can be included as informational artifacts in the PNF onboarding package provided by the vendor. These kinds of file can provide information for trouble shooting for example, but can be any kind of assistance in text from the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
  • CUSTOMER DOCUMENTATION PRODUCTS - Customer documentation products can be included as informational artifacts in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
  • TEST FILES - Test files are files that might be for testing, or end-to-end integration of the PNF with ONAP. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is not included in R4/Dublin.
  • LICENSING AGREEMENTS - Licensing agreements can be included as informational artifacts in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is not included in R4/Dublin and has been postponed.
  • RESOURCE CONFIGURATION INFORMATION - Resource Configuration Information can be included in the PNF onboarding package provided by the vendor. For example, these might be settings or other configuration management type data associated with the resource. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact. Note: starting in Frankfurt (R6) there is a CM (Config Mgmt) 5G U/C.
  • CONTROLLER BLUEPRINT ARTIFACT - From a controller perspective, there is a TOSCA implementation to execute template for configuration. These include Velocity templates, Jinja template. They can be generic or per PNF type (customized). This is OPTIONAL, a PNF package does NOT necessarily have this artifact. In future releases this could be incorporated into the PNF package. In R4/Dublin a ONAP user would manually upload the Controller Blueprint Artifact.

2.2 EXAMPLE xNF PACKAGE w/ FILES & DIRECTORIES


This section describes what an example of what an actual package might look like. It shows some of the key files and directories and how they might be arranged and delivered.

The onboarding PNF/VNF Package must be defined as specified as ETSI SOL004 v2.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. You can refer to the PNF Pre-onboarding & Onboarding Wiki for more information: 5G - PNF Pre-Onboarding & Onboarding



3. Information Flow

3.1 Pre-onboarding Flow

The following UML diagram shows the VNF/PNF Pre-onboarding Flow

3.2 Onboarding Flow

The following UML diagram shows Onboarding Flow:

The following sections describe the above (UML) steps in more detail:

3.3 Flow Description: PNF PACKAGE DELIVERY


1. PNF PACKAGE DELIVERY – Vendor Delivers the Package.

There are multiple ways that a vendor could deliver a package. There is not SOL or any other kind of standard which specifies HOW a vendor shall deliver a package. There is no API, it could  be on a memory/flash drive or cloud shared delivery system or any other conceivable way to deliver digital information.

2. PNF PACKAGE DELIVERY – Package is accepted into ONAP

the Vendor provided package is imported by a Technology Specialist/Asset manager into SDC.

3.4 Flow Description: PACKAGE VALIDATION (VNF-SDK)

3. LICENSE FILE CHECK – VNF-SDK performs a license file check within the vendor-delivered PNF package.

4. CERTIFICATE FILE CHECK – VNF-SDK performs a certificate file check within the vendor-delivered PNF package.

5. FILE AND DESTINATION CHECK – VNF-SDK examines the MainServiceTemplate.mf (Manifest file) and performs a cross-check of the files & pathway directories specified within the manifest faile against the actual files within the vendor-delivered PNF package. It checks that the files that have been specified in the manifest file are actually in the given destination (directories).

6. MANIFEST FILE TAG VALIDATION – VNF-SDK performs a check of the PNF keywords in the MainServiceTemplate.mf (Manifest file). The tags are pnf_product_name, pnf_provider_id, pnf_package_version, pnf_release_data_time, and non-mano_artifact_sets.

7. TOSCA METADATA FILE VALIDATION – VNF checks the Meta Data file (TOSCA.meta) in the PNF package with the ETSI SOL004 validation tags. The checks performed are the Entry definition, Entry-manifest, Entry-change-log, Entry-tests, Entry certificates.

8. USER CHECKS VALIDATION – The end user may then inspect that the PNF package has been appropriately verified in the Certification studio.

3.5 Flow Description: SDC PACKAGE ONBOARDING

In the next steps, SDC brings that Vendor provided package into the SDC Catalog and creates an SDC internal representation of that package.


A. UUID IDENTIFIER – SDC adds a UUID identifier.

B. TOSCA METADATA – SDC adds additional TOSCA Meta-data.

C. TOSCA DESCRIPTOR – SDC may add a TOSCA Descriptor

D. LICENSE MODEL FILE – SDC can add a license model file.

E. ADDITIONAL ARTIFACTS – The User may optionally manually add additional artifacts.


PACKAGE ONBOARDING

There are two options to onboard into SDC. OPTION #1 is to "automatically" onboard a package.

In this case, a VSP model is created using an Onboarding package (PNF CSAR, VNF CSAR or Heat)

9. ONBOARD PACKAGE - The onboarding package is accessed by a Technology specialist/Asset manager

10. INTERNAL MODEL - An internal model is created in SDC with MetaData added.

11. TRANSFORM ARTIFACTS - The artifacts from the PNF or VNF package are transformed into onboarding artifacts during SDC onboarding.

12. ONBOARD DESCRIPTOR - SDC transforms the xNF onboarding descriptor (PNFD or VNFD) into an SDC internal descriptor.

13. LICENSE MODEL FILES - License Model Files are added (optional).

PACKAGE ONBOARDING - MANUAL VNF VSP CREATION

The second option is to manually onboard into SDC, this entails the manual creation of a VNF VSP.

In this case, a VNF VSP model is manually created.

14. CREATE A VSP - The Technology specialist/Asset manager initiates a manual VSP creation.

15. INTERNAL MODEL - SDC is used to create an internal model with Metadata added.

16. INTERNAL DESCRIPTOR - The internal descriptor proprieties are updated. The vendor provided descriptor can specify attribute value limitations or ranges.

17. LICENSE MODEL FILES - The License Model Files are then added to the VSP

18. ARTIFACTS ADDED -  Finally, additional artifacts are added if necessary (optional).


CREATE RESOURCE - FROM A VSP

There are two ways to create a resource. A resource can be: (option 1) created from a VSP or (option 2) through manual creation.

These are the steps for creating a resource from a VSP.

19. CREATE VSP - The ONAP Operator requests for a resource to be created from a VSP.

20. RESOURCE MODEL - A VSP is transformed into a resource model.

21. INTERNAL DESCRIPTORS - The SDC Internal descriptor properties are updated. Customized types during design time allows service providers to specify additional restrictions on onboarded parameters. For example a vendor specified attribute might have allowed values 1 through 6; and customized types would restrict certain allowed values.

22. LICENSE MODEL FILES - License model files are updated in SDC.

23. ADDITIONAL ARTIFACTS - The operator may add additional artifacts to the resource. The resource becomes available in the SDC catalog for use in service creation (steps 28-30).


CREATE RESOURCE - MANUAL CREATION OF xNF RESOURCE

24. MANUAL CREATION, INTERNAL MODEL - The operator invokes the manual creation of a PNF or VNF resource. An internal VNF / PNF model is created with Metadata added.

25. INTERNAL DESCRIPTOR - In SDC, the internal descriptor properties are updated by the ONAP user.

26. LICENSE MODEL FILES - License model files can be added by the user in SDC.

27. ADDITIONAL ARTIFACTS - The operator may add additional artifacts to the resource (optional). The resource becomes available in the SDC catalog for use in service creation.  


4. Post Conditions

4a. Post Condition (Pre-onboarding)

The post-conditions for the pre-onboarding flow are the following. Once, pre-onboarded, the xNF is ready for onboarding.

  • PACKAGE VALIDATED - VNF-SDK has successfully validated the package (as a result of pre-onboarding) and verified the content that VNF-SDK can perform validation on (See the VNF-SDK Validation section).
  • Package SECURITY VALIDATION - The onboarding package is tested and validated for security.
  • Artifacts SECURITY VALIDATION - The artifacts of the onboarding package are tested and validated for security.

4b. Post Condition (Onboarding)

The post-conditions for the onboarding flow are the following. Once, onboarded, the xNF is ready for service creation.

  • Package SECURITY VALIDATION - The onboarded package is tested and validated for security.
  • VNFD/PNFD MODEL LOADED - The xNF Resource's Descriptor model is visible in SDC.
  • SDC INTERNAL PACKAGE EXISTS - The SDC Internal Package derived from the vendor provided xNF package has been successfully stored in SDC's catalog and is visible. All of the xNF artifacts, including the VES registration and PM dictionary/schema (for example) are visible and loaded properly.
  • Internal Package Function Tested - The internal package function is tested and validated.
  • ADDITIONAL ARTIFACTS - Additional manual artifacts can be incorporated into the Internal SDC xNF package.


REFERENCES


Read the Docs - for DCAE Designer: https://onap.readthedocs.io/en/latest/submodules/sdc.git/docs/dcaedesigner.html


SUPPORTING FILES & SLIDES

FilesFile
onboarding slides (Zu, Ben, Michela)