5G - PNF Plug and Play (Casablanca carry-over items)

The following table has the 5G PNF / Plug and Play items queued up as proposals for DUBLIN (R4) Release.

New requirements will be identified in the PNF Plug and Play Wiki Page which can be found at: 5G - PNF Plug and Play

PNF PLUG AND PLAY ENHANCEMENTS SUMMARY BY PROJECT:

PROJECT	IMPACT	PTL
SDC	PNF pre-onboarding/ PNF onboarding package management and processing.	Ofir Sonsino
SO	SO to Controller to PNF communication	Seshu Kumar Mudiganti
AAF	Security Enhancements	Sarat Puthenpura
SDN-C/R	Controller to PNF communication (Ansible, NetConf)	Dan Timoney
PRH	PRH Enhancements & Integration	damian.nowak
A&AI	A&AI enhancements, PNF-ID. ESR support.	James Forsyth
VID	VID enhancements & Carry over from R3	Ofir Sonsino

SDC IMPACTS

DUBLIN ITEM

DESCRIPTION

SDC1: Licensing Management

Having meta-data manage licensing. This at first (in Dublin) might be very simple but can be expanded. Feature activation licensing. Vendor licensing management systems.

First step in Dublin related to Licensing is the License to be onboarded in the PNF onboarding package during Pre-Onboarding. This is being worked with the PNF Pre-Onboarding/PNF Onboarding Use Case. The wiki:

5G - PNF Pre-Onboarding & Onboarding

SDC2: PNF Artifacts

SDC3: (PNF Package) & PNF Modeling

[SDC] In Casablanca we did not get in artifacts in time, and for Dublin we are looking to incorporate actual Artifacts.

VES Events require their YAML definitions to be supported as PNF artifacts (incorporated into a PNF CSAR package). This is vital for the VES events that the PNFs emit to be recognized by ONAP.

Some parameters were identified for PNF model and pushed to Dublin for example the Package version.

This is now being worked with the Pre-Onboarding/PNF Onboarding Use Case, the Wiki can be found here:

5G - PNF Pre-Onboarding & Onboarding

SO IMPACTS

PnP DUBLIN WORK ITEM	DESCRIPTION
SO1: Controller Association	[SDC/SO] The PNF controller caused quite a stir in Casablanca, the tension between Design/Platform Model vs Run-Time/Deployment Model. As a result the SO controller design was sub-optimal and should be addressed in Dublin.
SO2: SO support of A&AI creation	[SO] A&AI UI can create an inactive PNF (inactive) A&AI entry. A Service provider might use an inventory system and A&AI UI to create a PNF A&AI entry. In Step #19A instead of EXITING, SO would go into WAIT STATE pending rehydration of RLF w/ pnfReady DEVELOPMENT STATUS: This is already covered in ONAP/Casablanca: SO-797 - Getting issue details... STATUS
SO3: SO support for already existing PNF A&AI entries	[SO] Support of SO for an already existing PNF (active) A&AI Entry (use case with a deleted & recreated service or instantiating 2nd service using the same PNF) Within ONAP/Beijing - In Step #19B SO would exit and service creation would continue DEVELOPMENT STATUS: In ONAP/Casablanca this was updated, and irrespective of AAI entry existence for a PNF instance, the workflow execution always waits to receive a PNF registration event. SO-797 - Getting issue details... STATUS This is not planned to be changed in ONAP/Dublin release.
SO4: SO to support updated A&AI PNF schema	[SO] Support of SO for updated AAI PNF instance model. PNF-ID is going to be used as unique PNF idenitifcator, instead of PNF-Name, used in ONAP/Casablanca. PNF PnP sub-flow might need modifications related to how PNF instance objects are created. ASSOCIATED DEVELOPMENT: See task A&AI1 and PRH1.

AAF SECURITY IMPACTS

PnP DUBLIN WORK ITEM	DESCRIPTION
AAF1: Security Enhancement	[AAF] Security enhancements slated for Dublin will need to be working for PnP Use Case

SDN-C/R (Controller) IMPACTS

PnP DUBLIN WORK ITEM

DESCRIPTION

CTL1: Controller PNF Interaction

[CONTROLLER] Controller definition (SDN-C) came so late in Casablanca, we had defined some additional optional parameter for the step37 Service Configuration but likely more evolution needs to be done. SDN-C was not the theoretical proper controller and people objected as this is conceptually the L0-L3 controller.

[STEP 35-37] - The SO to SDN-C and Controller to PNF exchange (Ansible or NetConf) was a carry-over item from R3. This requires that an API between SO to SDN-C is in place to support this. It requires that SDN-C support the appropriate Ansible Playbook and Directed Graph.

PRH IMPACTS

PnP DUBLIN WORK ITEM	DESCRIPTION
PRH1: A&AI New PNF Schema Adaptation	New AAI schema adaptations: Chesla Wechsler found a discrepancy between PNFs and VNFs; VNFs are idenitifed via VNF-ID (UUID), and PNFs - via PNF-Name. So PNF-ID should be used for Identities. This differentiates the way that PRH is searching for PNFs in AAI, when PRH does the PNF registration in AAI (may also require SO change). A PNF-Name parameter wil be used to search a relevant PNF instance, and then CRUD operations will be executed using the PNF-ID value obtained from that previous instance search. ASSOCIATED DEVELOPMENT: See task A&AI1 and SO4.
PRH2: PRH with actual DU	It would be nice if in Dublin (or Frankfurt) if the Plug and Play Use Case actually worked with a real DU.
PRH3: Integration	[PRH] There might be more integration or development for the PRH in Dublin.

A&AI IMPACTS

DUBLIN ITEM	DESCRIPTION
A&AI1: A&AI pnf-id as INDEX for PNF	[A&AI] Using the pnf-id (instead of pnf-name) as the index for PNF into A&AI. (discussion started in R3, socialized, Contact: Chesla Wechsler). Get naming indexing consistency with PNFs and VNFs. Schema A&AI model update. Details: Proposal to Change AAI PNF Entity to use PNF-ID as key
A&AI2: External Manager (EMS/NMS) [ESR]	[A&AI] IP address or association with the External Manager. Is the ESR concept sufficient? https://onap.readthedocs.io/en/beijing/submodules/aai/esr-server.git/docs/
A&AI3: Cloud Home Server (A&AI)	[A&AI] Tracking the Cloud Home Server (CLLI, Cloud ID); is the association with the COMPLEX Object sufficient? How-To: Register a VIM/Cloud Instance to ONAP
A&AI4: SO support of A&AI creation	[SO] A&AI UI can create an inactive PNF (inactive) A&AI entry. A Service provider might use an inventory system and A&AI UI to create a PNF A&AI entry. In Step #19A instead of EXITING, SO would go into WAIT STATE pending rehydration of RLF w/ pnfReady DEVELOPMENT STATUS: (Completed in ONAP/Casablanca - SO-797 - Getting issue details... STATUS )
A&AI5: SO support for already existing PNF A&AI entry	[SO] Support of SO for an already existing PNF (active) A&AI Entry (use case with a deleted & recreated service or instantiating 2nd service using the same PNF) In Step #19B SO would exit and service creation would continue

VID ENHANCEMENTS

PnP DUBLIN WORK ITEM

DESCRIPTION

VID1: VID Enhancements

#4 – WORK ORDER (Optional) – Supporting Work Order. Supported with service specific applications. Inventory systems (optional). Future extension to ONAP. Interface w/ BSS-OSS systems (API).

ACTION: Error cases (check if SDC model parameters != A&AI PNF entry)

#5 – VID A&AI INSTANCE CREATION – (optional) (slide 20/Step 4) – VID supporting Resource Declaration a PNF A&AI Instance creation. Similar flow in eCOMP.

VID2: VID PNF Mgmt.
Enhancements

VID comes with certain PNF management capabilities.
These will be impacted by an A&AI PNF model changes, and VID will have to be updated to support the new AAI PNF model.
Proposal to Change AAI PNF Entity to use PNF-ID as key

USE CASE SPAWNS

XTRA1: 5G RAN Work Flow	Need dedicated 5G RAN Work Flow for PNF Plug and Play (instead of it being part of the VCPE work flow).
XTRA2: VNF & PNF 5G Flow	CU w/ DU - New 5G Sub-Use Case. Interleaving w/ Controller association. MODELLING work to lay ground-work (SA/SD, OO, UML) 5G RAN W/F

Controller

[CONTROLLER] Controller definition (SDN-C) came so late in Casablanca, we had defined some additional optional parameter for the step37 Service Configuration but likely more evolution needs to be done. SDN-C was not the theoretical proper controller and people objected as this is conceptually the L0-L3 controller.

[STEP 35-37] - The SO to SDN-C and Controller to PNF exchange (Ansible or NetConf) was a carry-over item from R3. This requires that an API between SO to SDN-C is in place to support this. It requires that SDN-C support the appropriate Ansible Playbook and Directed Graph.