Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The scope of this page is to define the Onboarding package for a PNF as well as maintain the approved list of ONAP specific non-MANO artifact specification to be registered with ETSIset identifiers. This page is required to be long-live.

The Modeling sub-committee ONAP TSC is the organization that owns the non-MANO artifacts set.  The contact persons for non_MANO artifacts set is ONAP official contact is onap-tsc@lists.onap.org

The editing of this page is limited to Michela Bevilacqua and Andrei Kojukhov

CSAR structure

TOSCA YAML CSAR file is an archive file using the ZIP file format. Two CSAR  structures are defined in ETSI SOL004.

1) CSAR containing a TOSCA-Metadata directory, which includes the TOSCA.meta file

2) CSAR containing a single yaml file at the root fo the archive. 

Option 1 is the unique option supported in ONAP in Dublin.

META FILE AND MANIFEST FILE

The use of the TOSCA.meta and the Manifest file (.mf) in line with ETSI SOL004 will help to:

1) identify the path of the ETSI MANO artifacts (by the .meta file)

2) identify the path of the NON ETSI MANO artifacts (as defined in ETSI SOL004), by the .mf file.

NON ETSI MANO ARTIFACTS in DUBLIN

In Dublin, following NON ETSI MANO artifacts is expected to be supported at least:

1) VES dictionary

2) PM dictionary

3) YANG module files.


GENERAL

According to ETSI SOL004 v.2.5.1, According to ETSI SOL004, every non-MANO artifact set shall be identified by a non-MANO artifact set identifier (TAG) which shall be registered in the ETSI registry.  

ETSI registry of non MANO artifact set identifier is available in ETSI wiki https://nfvwiki.etsi.org/index.php?title=Non_MANO_artifact_sets.

Set identifiers can be public or private. ONAP as a public community initiative decided to introduce a set of public identifiers.

Non-MANO artifact sets shall be declared in the manifest file. If the package contains at least one non-MANO artifact set, an entry named "non_mano_artifact_sets:" shall be present in the package on the manifest file on its own line after the "metadata" section.

All files belonging to the same non MANO artifact set shall share a common path prefix (e.g. multiple yang module files will share the same set identifiers).

ONAP PUBLIC NON-MANO ARTIFACTS SET APPROVED by ONAP TSC for REGISTRATION in ETSI

The followings are following table contains the public non-MANO artifact set identifiers which can be used in a PNF/VNF onboarding package .The introduction in the manifest file allow to isolate the ONAP specific topics as follows:per ONAP releases. The relevant examples of using the artifact tags are following the table

ONAP Release where the artifact ID is initially introducedNon-MANO artifact IDDescription

Reference ( R-146092 )

(“The published version link shall be updated after Frankfurt release”)

Notes
 Dublinonap_ves_events

...

contains VES registration files for handling external events

The latest requirements:

R-22346

R-025941

See the below example and clarifications in 5G - FM Meta Data / 5G - PM Dictionary

onap_pm_dictionary

...

contains the PM dictionary files used for Performance Management

The latest requirements: 

R-816745

See the usage in 5G - FM Meta Data / 5G - PM Dictionary

onap_yang_modules

...

contains Yang module files for configurations 

The latest requirements:

R-93443

R-26115

See the usage in 5G - Configuration with NETCONF

onap_ansible_playbooks

...

contains any ansible

...

playbooks

...

The latest requirements:

R-75608

See the usage in 5G - PNF Software Update

onap_others

...

contains any other non_MANO artifacts, e.g. informational documents

NEXT STEPS IN DUBLIN TIMEFRAME

1) In Dublin timeframe SDC is going to implement the PNF package onboarding in line with the agreed non-MANO artifact set identifiers.

2) Register the NON-MANO artifact set identifiers in ETSI

3) Document the ONAP non-MANO artifact set identifiers in the VNF RQT as new ONAP requirements.

4) Maintain the ONAP non-MANO artifact set identifiers by a ONAP projects for future evolution (to be discussed if MODCOM or VNFRQT project will maintain the ONAP non mano artifact set identifiers) 

...

noneSee about its usage in 5G - PNF Pre-Onboarding & Onboarding
 Frankfurtonap_pnf_sw_information PNF software version

The latest requirements:

R-972082

See about its usage in

Enable Service Level LCM Operations


EXAMPLES:


Example 1 (Dublin Release)

In the picture below, an example of a PNF onboarding package including a manifest file with URI's for non-MANO artifacts used in Dublin


Image RemovedImage Added

NOTES about the example: Folder/file name MANDATORY according to  SOL004:

...

4) Example package above does not include any certification file or other security options.

During the 2019-01-18 VNFPKG meeting we agreed to evaluate further the introduction of public identifiers to be approved in ETSI for ONAP.

Example Signed Packages

Here are two example signed packages. The packages are signed according to security option 2 in ETSI SOL004. The two file package has the signing certificate in the cryptographic message syntax. The three file has the certificate in a separate file and not in the cryptographic syntax.

2-file-signed-package.zip

3-file-signed-package.zip

Note: Only the complete package is signed. There is no signature included for the files in the package.

Files related to example signed packages here

ACTIONS

1) ACTION: finalize the list public identifiers to be proposed in ETSI and analyze further ETSI process - COMPLETED

2) ACTION: VNF SDK is going to implement package security according to ETSI SOL004. TO be further verified if option 1 and/or 2 will be supported.

3) SDC has a Jira ticket tracing the Security introduction support in the package. Certification files as they could differ according to the type of security option provided by the vendor (NOT PROVIDED IN THE EXAMPLE )

4) How to map the non-MANO artifact files to the SDC artifacts type?

5) ChangeLog.txt, a human readable text file at the root or in a location identified in the .meta file. (NOT PROVIDED IN THE EXAMPLE BELOW)




Example 2 (Frankfurt Release)

In the picture below, an example of a PNF onboarding package including a manifest file with URI's for non-MANO artifacts used in Frankfurt

Image Added

A reference PNF CSAR PACKAGE as example is available dummyPnfv3.csar (TBD) to review directories structure and new .meta and .mf files format.6) A license term file for the xNF located in a directory named Licences located at the root or in a location identified in the .meta file (NOT PROVIDED IN THE EXAMPLE BELOW)