Page Comparison

...

Note: the page is on-going contracted and finalized information shall be updated

The scope of this page is to define the Onboarding package for a PNF as well as non-MANO artifact specification to be registered with ETSI on ONAP Frankfurt Release.

Comparing to PNF On-boarding on R4 Dublin Release, the updated information is marked as light blue.Note: the page is on-going contracted and finalized information might be updated

New in Frankfurt Release for OnBoarding PNF package. The propsoal is APPROVED on TSC 2019-10-24

On the ONAP R4 Resource IM Call 2019-6-17, A new non-MANO artifact called PNF Software version SW VERSION in PNF package_DDF.pptx is proposed and discussed on the ONAP R4 Resource IM Call 2019-6-17 AND get the following agreement
- 'The option 1 is preferred in Frankfurt Release and going for a poll on modeling subcommittee call' (details will be described in this page).
on ONAP R6 Resource IM Call 2019-9-23, further discussion for non-MANO artifact called PNF Software Version in PNF upgrade on ONAP Frankfurt Release got basic agreement .
- The next step to get a poll for non-MANO artifact key word, file format and key words in .yaml file as below red font.
  - onap_pnf_sw_information for non-MANO artifact Registered in ETSI&IANA
  - .yaml format is proposed,
  - Key words in .yaml file
    - pnf_ software_information:
    - - pnf_software_version: ”5gDUv18.05.201”
On ONAP Modeling Sub-committee meeting on 2019-10-15, get the approved for above proposal with voting result.
- Call for vote: PNF Software Version (Fei Zhang (Ericsson) )
  - See: Proposal for PNF software version in PNF upgrade in Frankfurt release
  - Results: YES: Ericsson, AT&T, Amdocs, Huawei, CMCC
  - Will share the recommendation with the ONAP TSC before forwarding registration request to ETSI.
On TSC 2019-10-24 meeting for voting, the final approved in ONAP. Good news!!!
- The next step to register such keyname in IANA/ETSI.

This page is covering ETSI SOL004 Package on-boarding option with ETSI SOL001 TOSCA VNF/PNF Descriptor.

Other on-boarding package options are not covered, e.g. HEAT, TOSCA VNFD in NON-ETSI compliant package.

CSAR structure on SDC

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

...

Option 1) is the unique option supported in ONAP from Dublin in Dublin, EL-ALTO and Frankfurt.

META FILE AND MANIFEST FILE

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

...

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

NON ETSI MANO ARTIFACTS

NON-ETSI-MANO Artifacts in the onbarding package are provided by the vendor. They provide information that may enable additional functionalities in ONAP.

All the artifacts are optional in the onboarding package.

In Dublin and El Alto following NON-ETSI-MANO artifacts are supported in ONAP:

1) VES dictionary

2) PM dictionary

3) YANG module files

4) Ansible files

5) information documents provided in the onap_others set identifier

In Frankfurt, following NON-ETSI-MANO artifacts are expected to be supported in ONAP

1) VES dictionary

2) PM dictionary

3) YANG module files

4) Ansible files

5) information documents

6) PNF information file

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

The Set identifiers can be public or private. ONAP as a public community initiative decided to introduce a set of public identifiers. The following page lists the registered ONAP set identifiers in ETSI registry.

ONAP Non-MANO Artifacts Set Identifiers

NON-ETSI-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 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).

In Dublin and El Alto following NON-ETSI-MANO artifacts are supported in ONAP:

1) VES dictionary

2) PM dictionary

3) YANG module files

4) Ansible files

5) information documents provided in the onap_others set identifier

In Frankfurt, following NON-ETSI-MANO artifacts are expected to be supported in ONAP

1) VES dictionary

2) PM dictionary

3) YANG module files

4) Ansible files

5) information documents provided in the onap_others set identifier

6) PNF software information file

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

The followings are the public non-MANO artifact set identifiers which can be used in a PNF/VNF onboarding package.

...

onap_ves_events: contains VES registration files
onap_pm_dictionary: contains the PM dictionary files (file names are not defined in ONAP)
onap_yang_modules: contains Yang module files for configurations (file names are not defined in ONAP)
onap_ansible_playbooks: contains any ansible_playbooks (file names are not defined in ONAP)
onap_scripts: contains any scripts, e.g. installation scripts (NOT REQUIRED IN DUBLIN TIMEFRAME BUT MAY BE REGISTERED LATER
)
onap_others: contains any other non_MANO artifacts, e.g. informational documents
onap_pnf_nfsw_information: contains NF(Network Function) PNF software related information. e.g. PNF, VNF or xNF itself information. In Frankfurt, it contains a new file for PNF information

FILE DIRECTORY — Need to be discussed, which option is better?

onap_nf_information

pnf_sw_version file / PNF information file (name ?)

vnf_info....

Two options:

1) we define a single onap nf info directory with different files (i.e pnf specific info, vnf specific info, xnf specific info)

2) we define one directory for each file

FILE NAME

PNF_information ? /pnf_sw_version file?

FILE FORMAT

The file is a yml file

pnf_information.yaml

{

pnf_sw_version: type

}

pnf_software_version.yaml

{

description: PNF software version

parameters:

pnf-sw_version:

type: string

default: ” 5gDUv18.05.201”

}

...

software information

NON-MANO Artifact Set Identifier name

onap_pnf_sw_information: contains PNF software related information. In Frankfurt, it contains a new file for PNF software information:

Code Block

language	yml
title	pnf_sw_information.yaml
linenumbers	true

description: "pnf software information"
provider: "Ericsson"
version: "1.0"
pnf_software_information:
  - description: "software version of PNF"
    pnf_software_version: "5gDUv18.05.201"

NEXT STEPS IN FRANKFURT TIMEFRAME

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

Jira Legacy

server	System Jira
columns	key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId	4733707d-2057-3a0f-ae5e-4fd8aff50176
key	SDC-2589

)

2) Register the NON-MANO artifact set identifiers in ETSI and update the reference ONAP page (add the reference).

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

Jira Legacy

server	System Jira
columns	key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId	4733707d-2057-3a0f-ae5e-4fd8aff50176
key	VNFRQTS-744

)

4) create a csar package file example aligned to Frankfurt release to be added in this page(dummyPnfv3.csar )

5) Is CMCC going to test Onboarding Package for VNF in ElAlto ? Can we extend the onboarding package support to VNF ? (Jira ticket ?: SDC-2072)

PNF ONBOARDING PACKAGE EXAMPLE WITH USING NON-MANO ARTIFACTS in FRANKFURT

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 RemovedImage Added

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

TOSCA-Metadata directory and TOSCA.meta file (unique CSAR package structure supported in ONAP Frankfurt)
Manifest file extension, XXX.mf, located at the root or in a location identified in the .meta file. The name of the file is the same of the TOSCA yaml file. Below is example of pnf_main_descriptor.mf in dummyPnfv3.csar

Code Block

language	yml
title	pnf_main_descriptor.mf
linenumbers	true

metadata:    
    pnfd_name: myPnf    
    pnfd_provider: Acme    
    pnfd_archive_version: 1.0    
    pnfd_release_date_time: 2019-03-11T11:25:00+00:00

Source: pnf_main_descriptor.mf
Source: Definitions/pnf_main_descriptor.yaml
Source: Definitions/etsi_nfv_sol001_pnfd_2_5_1_types.yaml
Source: Definitions/etsi_nfv_sol001_vnfd_2_5_1_types.yaml
Source: Files/ChangeLog.txtSource: Files/Events/MyPnf_Pnf_v1.yaml
Source: Files/Guides/user_guide.txt
Source: Files/Measurements/PM_Dictionary.yaml
Source: Files/Scripts/my_script.sh
Source: Files/Yang_module/mynetconf.yang
Source: TOSCA-Metadata/TOSCA.meta
Source: Files/pnf-sw-information/pnf-sw-information.yaml

non_mano_artifact_sets:    
    onap_ves_events:
        Source: Files/Events/MyPnf_Pnf_v1.yaml
    onap_pm_dictionary:
        Source: Files/Measurements/PM_Dictionary.yaml
    onap_yang_modules:
        Source: Files/Yang_module/mynetconf.yang
    onap_others:
        Source: Files/Guides/user_guide.txt
    onap_pnf_sw_information:
	Source: Files/pnf-sw-information/pnf-sw-information.yaml

Ín the example the following files are not provided:

...

A reference PNF CSAR PACKAGE as example is available dummyPnfv2available dummyPnfv3.csar (TO BE UPDATED) to review directories structure and new .meta and .mf files format.

...

1) Only csar package structure with TOSCA-Metadata directory will be supported in Dublin Frankfurt timeframe

2) PM Dictionary, Event registration, Yang modules and NF PNF software information are the only NON MANO ARTIFACTS that will be listed in the manifest file

...

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.

ACTIONS

...

get a poll for non-MANO artifact for pnf software version proposal in PNF Software Version in PNF upgrade on ONAP Frankfurt Release — Done
Update example PNF CSAR file ---Done

Versions Compared

Old Version 13

New Version Current

Key

This page is covering ETSI SOL004 Package on-boarding option with ETSI SOL001 TOSCA VNF/PNF Descriptor.

Other on-boarding package options are not covered, e.g. HEAT, TOSCA VNFD in NON-ETSI compliant package.

CSAR structure on SDC

META FILE AND MANIFEST FILE

NON ETSI MANO ARTIFACTS

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

FILE DIRECTORY — Need to be discussed, which option is better?

FILE NAME

FILE FORMAT

NON-MANO Artifact Set Identifier name

NEXT STEPS IN FRANKFURT TIMEFRAME

PNF ONBOARDING PACKAGE EXAMPLE WITH USING NON-MANO ARTIFACTS in FRANKFURT

Example Signed Packages

ACTIONS