...
R6 Frankfurt CANDIDATE ENHANCEMENTS | IMPACT | ||||||||||
REQ (Requirements) Epic | The main Epic REQ Jira ticket for enhancements for POB/OB in R6 is
| ||||||||||
Modelling | Definition of Platform Info & Data model continues Introduce/Refine PNF S/W version (get it review & approved) | ||||||||||
Resource Data Model | Onboarding PNFD to Platform PNFD mapping development & enhancement | ||||||||||
VNF-SDK (PNF-SDK) | Package Validation enhancements notable Package security (option 2 per artifact), SOL004 alignment, License Model Check. | ||||||||||
PNF Onboarding Package | Further carry-over development from R4/Dublin for PNF onboarding process. | ||||||||||
VNF Onboarding | VNF onboarding, same procedure, same function, but testing/integration was not completed in R4/Dublin. | ||||||||||
VNFD Mapping to Platform Model | Additional validation of security package. VNFD Modeling transformation (PNFD was completed in R4) | ||||||||||
PNF Software version onboarding | The PNF S/W version needs to be onboarded (and defined) for usage in the PNF S/W Upgrade use case. | ||||||||||
Documentation / | VNF requirements document / Read the docs. DOCS project VNF-RQTS project requirements update. | ||||||||||
ETSI & SOL Alignment |
DEVELOPMENT IMPACTS
PROJECT | PTL | User Story / Epic | Requirement |
A&AI | |||
AAF | |||
APPC | |||
CLAMP | |||
CC-SDK | |||
DCAE | |||
DMaaP | |||
External API | |||
MODELING | Epic 1: VNF onboarding Epic 2: VNFD Model mapping Epic 3: S/W Version in Package | E1b: VNFD transforming (modeling team discussions) E2: VNFD (onboarded) to Platform Model (modeling team discussions) E3: S/W Version (under discussion in resource info modeling team) | |
Multi-VIM / Cloud | |||
OOF | |||
POLICY | |||
PORTAL | |||
SDN-C | |||
SDC | Epic 1: VNF onboarding Epic 2: VNFD Model mapping Epic 3: S/W Version in Package | E1a: Alignment to SOL 001. E1b: VNFD transforming (modeling team discussions) E1c: Enhance security for xNF package artifacts. E2: VNFD (onboarded) to Platform Model (modeling team discussions) E3: S/W Version (under discussion in resource info modeling team) | |
SO | |||
VID | ittay | ||
VNFRQTS | |||
VNF-SDK | Epic 4: VNF-SDK Enhancements | E4a: Enhance security for xNF package artifacts bug fixing (Option 1 done in R5) E4b: PNF descriptor requirements alignment E4c: Integration Testing work Morgan Richomme | |
CDS |
List of PTLs:Approved Projects
The "Base" PNF Pre-onboarding/Onboarding Wiki
...
#6: PACKAGE SECURITY (finished in R5 maybe some bug fixing in R6) | Driven from SOL004: Option 1 (Supported in R4 Dublin): TOSCA.meta (exists) Meta-directory based, XML based approach. Option 2 (NOT support in R4 Dublin): CSAR without TOSCA.meta. Manifest (.mf) file that has everything (so the TOSCA.meta is redundant). Yaml-based approach. The Public Key a key to open the package. SOL004 Option 1, 2 and use key to open the package - X.509 certificates public key, private key to sign the package and private key correspond to the private key of the package also delivered with the package. a package, a signature, and public key certificate delivered together. There may be more than one signature. Option 1 there is a digest for every file. All of those digests are listed in the manifest file. The manifest file is signed, one signature on the manifest. One signature and one key/pair & 1 certificate. Still optional to sign other files. The signature is a file beside. myimage.iso myimage.xyz but the same file/directory. Every file signed should have a signature files. CSAR file signed in a .sm file, package signature. The public key is signed can be signed by a root certificate. An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. (investigate) if VNF-SDK would like to use AAF as the CA. Can AAF perform the CA functions. To open the package need: (1) Public Key (to open the manifest file) (2) file input (3) certificate input. create a hash, the hash is verified against the signature. SHA-256 R5 (El Alto). Implemented Option 1 per artifact security (R4 had only Option 2 per package security). Had to fix a bug. No more is needed in R6. OPEN - only Bug Fixes were done no new functionality, post-poned to Rx | |||||||||||
#7: PNF DESCRIPTOR | The descriptor. There is validation of the VNFD. PNF Descriptor: TOSCA descriptor, and validate the node type. Validation of TOSCA PNFD. Following TOSCA rules. Components required are there. (NEEDS INVESTIGATION) VNFSDK check the VNFD based on VNF requirements. In R6: Req (from Victor Gao) - discrepancies in Req. Req for VNFs. Added new Req for PNF. some need to be refactored. To make sure PNF stuff is validated in better way. PNFD validation. ASSOCIATED DEVELOPMENT:
| R4 HIGH | ||||||||||
#F1: CREATE PACKAGE FUNCTION FOR PNF | The create package function creates the metadata files, and CSAR files. This needs to be modified to support SOL004. (NEEDS INVESTIGATION) [Low Priority] - Likely to be pushed to R7 Guilin OPEN: Post-poned to R7 | R7 LOW PRI | ||||||||||
#F2: TOSCA Metafile License Content Check | SDC license model check. Potential ARTIFACTS: Vendor license model & agreement, features. VNF can have >1 features, entitlement pool, license key pools, actual keys. [Low Priority] - Licensing Management Use Case is introduced in R6, so License content check will for POB/OB will happen in NEXT release R7 Guilin (at earliest) OPEN: Post-Poned to R7 | R7 LOW PRI |
Additional Resources / Links:
ONAP R6+ Onboarding VNF/PNF package format, non-MANO artifacts set definition
INTEGRATION & TESTING
This section discusses the Testing & Integration for R6 PnP
- WHO IS TESTING - what company, team, and people will be doing the testing & responsibilities for testing.
- TEST ENVIRONMENT - which does the lab & test environment.
- RESOURCES NEEDED - what resources are needed.
- WHO IS CONTRIBUTING RESOURCES - what resources will be provided and by whom/what company.
- NETWORK CONNECTIVITY - Connectivity requirements
- INTEGRATION LEAD DEFINITION - ONAP "Use Case/Requirement" Integration Lead
PNF PnP Integration Test Cases for Preonboarding/Onboarding. These can be navigated to from the Integration team page hierarchy.
5G - PNF E2E Pre-Onboarding & Onboarding Integration Test Cases
Testing Status
Dublin 5G - PNF PnP - Test Status