Wiki to the "Base" PNF Plug and Play Page: 5G - PNF Plug and Play
PRH update handling of Logical Links (move to SO) - introduced in R4 Dublin for BBS/Re-registration Epic
DEVELOPMENT IMPACTS
PROJECT | PTL | User Story / Epic | Requirement |
A&AI | |||
AAF | |||
APPC | |||
CLAMP | |||
CC-SDK | Epic#1: Controller to PNF exchange (Epic) | Epic #1:
| |
DCAE | |||
DMaaP | |||
External API | |||
MODELING | |||
Multi-VIM / Cloud | |||
OOF | Shankaranarayanan Puzhavakath Narayanan | ||
POLICY | |||
PORTAL | |||
SDN-C | |||
SDC | |||
SO | |||
VID | |||
VNFRQTS | |||
VNF-SDK | |||
CDS |
List of PTLs:Approved Projects
SO IMPACTS
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. Generic API. CDS has its own API to SO. The work being done with the CDS work is re-used for PnP U/C, so no new development needs to be done. ASSOCIATED DEVELOPMENT: (Jira) Controller Design Studio (Design Time) - to customize configuration. This might be used to set the values of parameters that might be send down to a PNF. NetConf - see the NetConf 5G U/C Wiki: 5G - Configuration with NETCONF |
PRH IMPACTS
PnP R6 Frankfurt Work Item | |
---|---|
BBS Event Processing Micro-Service
PnP R6 Frankfurt WORK ITEM | DESCRIPTION | ||||||||
PRH(discuss): Step 37a PNF "Activated" message to ONAP BBS event processing micro-service. | State Change VES Event (type = State Change) Old state & New State. CPE Authentication Notification BBS U/C is using this flow to "update" ONAP letting ONAP know that the PNF has been successfully been activated. From VES Event Listener Document:
|
A&AI IMPACTS
DUBLIN ITEM | DESCRIPTION |
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/ During PnP, the IP address of the External Manager would saved/stored or set by user or by the PNF. Where would that be stored? would it be in A&AI. Information about the External Manager is discovered & stored. Note: The External Manager info is optional LOW PRIORITY |
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 LOW PRIORITY |
A&AI / Model | [A&AI] GeoLocation information for the PNF reported via pnfRegistration VES Event LOW PRIORITY (Nice to have) |
A&AI4: A&AI pnf-id as INDEX for PNF | [A&AI] New A&AI schema adaptations: discrepancy between PNFs and VNFs; VNFs are identified via VNF-ID (UUID), and PNFs - via PNF-name. PNF-id should be used for Identities. This differentiates the way that PRH is searching for PNFs in A&AI, when PRH does the PNF registration in A&AI (may also require SO change). July 31th 2019 → AAI team has cancelled this request (redacted). CANCELED |
MODEL IMPACTS
DUBLIN ITEM | DESCRIPTION |
Model | [Modeling] GeoLocation alignment in Modeling with RFC6225 and the PNFD, A&AI schema, and SDC AID Data model. LOW PRIORITY (Nice to have) |