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. | |
SO | SO to Controller to PNF communication | |
AAF | Security Enhancements | |
SDN-C/R | Controller to PNF communication (Ansible, NetConf) | |
PRH | PRH Enhancements & Integration | |
A&AI | A&AI enhancements, PNF-ID. ESR support. | |
VID | VID enhancements & Carry over from R3 | Ofir Sonsino |
PORTAL | Impact on Functional Menus | Manoop Talasila |
SDC & PRE/ONBOARDING 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: |
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: |
SO IMPACTS
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. Discussing with DCAE about supporting TLS authentication just with Certificate without Username & Password. If the NF already uses the UN&P for the HTTP connection (that should still work). Certificate use should be working in Dublin to setup the HTTPS connection. PROPOSAL: Thus, both Certificate & Username & Password will be supported. (This is suggested for backward compatibility). i.e. there are already existing deployment. PROPOSAL: It is recommended to use the Certificate. Certificates as part of the authorization? Subject of the certificate is something that can be used as authorization, the proposal to DCAE is that there is a list of authorized users/subjects. Initially it could be manually configured, but the objective is that this would come from AAF. Start with Certificates local check: subjects against a list (w/ wildcards). Agree w/ appropriate interface w/ AAF then integrate w/ AAF. If identity not found use basic authentication a second check w/ username & password. otherwise access is rejected (HTTP return code). |
SDN-C/R (Controller) IMPACTS
The Controller to PNF service configuration happens in Steps 36 & 37 in the PNF Plug and Play flow (you can read more at the PNF PnP Wiki).
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 A&AI schema adaptations: Chesla Wechsler found a discrepancy between PNFs and VNFs; VNFs are identified via VNF-ID (UUID), and PNFs - via PNF-name. PNF-id = UUID; PNF-name = Correlation ID. PRH use search API to find PNF instance based on PNF-name then get the PNF-id. pnfRegistration VES Event to get the Key to search A&AI. use "sourcename" (part of VES Common header). Take value of sourcename search A&AI to find a PNF entry. In R3/Casa search against PNF-name = sourcename (search for object get PNFid); In R4/Dublin search against PNF-name = sourcename (with a different API). search for object. Change in primary key in A&AI. 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 ). ACTIONS: Inform Clients of break in change & migration. |
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. 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-797Getting 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 | 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) |
VID2: VID Enhancements | 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 |
PORTAL IMPACTS
DUBLIN ITEM | DESCRIPTION |
Impact on Functional Menus | Interface update change. Functional menu accesable to any ONAP users from portal. provide seamless user experience when multiple back-end components involved e.g. SDC, VID, A&AI etc when user goes from 1 component to another e.g. modeling, pnf instance decalaration, activation can be provided as functional menus in PORTAL. If a new user doesn't know what the next step is to perform, the PORTAL can recomment the next step via notifications or alerts. More details are here - 5G Usecase Impacts on Portal platform |
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 |