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
Presentation for Epic #4:
DEVELOPMENT IMPACTS
PROJECT | PTL | User Story / Epic | Requirement |
A&AI | |||
AAF | Epic #4:
| ||
APPC | |||
CLAMP | |||
CC-SDK | Epic#1: Controller to PNF exchange (Epic) STEP 37 | Epic #1:
| |
DCAE | Epic #4 Secure PnP Epic #5: Refactor Tests for DCAE-SDK DMaaP-Client | ||
DMaaP | |||
External API | |||
MODELING | Epic #2: Geolocation parameters | Epic #2:
| |
Multi-VIM / Cloud | |||
OOF | Shankaranarayanan Puzhavakath Narayanan | ||
POLICY | |||
PORTAL | |||
SDN-C | |||
SDC | |||
SO | Epic #3: SO Building Blocks. | ||
VID | Epic #3: SO Building Blocks | Need to sync on the VID implementation of 5G VID Instantiation/orchestration. VCPE also wants to use these building blocks. | |
VNFRQTS | |||
VNF-SDK | |||
CDS | Yuriy Malakov | Epic #6: CDS Integration with SDC |
List of PTLs:Approved Projects
EPIC / REQ
The Plug and Play Epic for R6 Frankfurt:
- REQ-134Getting issue details... STATUS
AAF
PnP Frankfurt Work Item | DESCRIPTION |
---|---|
Secure pnfRegistration | Introduction of Secure Communications with CMPv2. 3GPP PnP operator certificate (to DCAE) before it sends pnfRegistration event. Not on DCAE-side. Setup ONAP system have to have root CA, CA chain from the CAs that issue NF certificates. you get DCAE component Certificate signed by local AAF/CA. DCAE doesn't use AAF directly, DCAE component uses its own init container to get certs. NetConf over TLS will use CMPv2. External border components (DCAE, Controllers) need real certificates, which they don't have right now. This will be developed in R6. ONAP platform Containers / Prepare system to upload certificates manually. Need automatic way to get operator certificates through CMPv2 client. Plug-in to AAF to get certificates, how are these distributed to other ONAP components. Need trust chain. Can't do this manually with 100s of instances. Don't have a factory certificate w/ inherent identifier. PNFs scope. DCAE components need to get operator certificates. COMPONENTS: DCAE, AAF. |
SO IMPACTS
VID IMPACTS
R6 ITEM | DESCRIPTION |
---|---|
VID1 Migration of Sub-worksflows | Migration of existing PNF PnP sub-workflows to a new BB approach (probably we will be creating 4-5 new BBs). VID Impact: Within “old” VID macro orchestration pages, a special field to provide a pnf-id parameter (shall be actually called “correlationID” or “PNF correlationID”) has been displayed under the following conditions:
When we migrate to BB approach, we`d keep the possibility to provide this parameter to the SO API call as input. How this will change with SO/BB approach, and with new VID GUI targeted at macro (GR) flows – we`d see exactly, after we execute some tests with VID. We`d have to check, what capabilities and conditions could be applied to display and process this “PNF Correlation ID parameter”. Can the same BBs could be re-used in “standard” vCPE use-case. We`re looking at a generic solution, and we`d probably display this additional field, when we figure out, that there is a PNF resource used in a Service Model. |
CONTROLLER IMPACTS
PnP R6 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
R6 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 This will ONLY be modeling work in R6, functionality it moved to future release MODELING WORK ONLY |
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
R6 ITEM | DESCRIPTION |
Model | [Modeling] GeoLocation alignment in Modeling with RFC 6225 and the PNFD, A&AI schema, and SDC AID Data model. (Sept 5) "Place" object (off of the Root) platform ONAP info-model. GB922 Location standards Latitude/ Longitude / Altitude (RFC 6225) > GP922 > ONAP > Complex & Place object. LOW PRIORITY (Nice to have) |
MEETINGS
PNF: PnP - PNFD/SDC AID/AAI Schema Modeling - for GeoLocation - (Aug 22 2019) Discussion of Geolocation / PNFD/ Civic Address parameters
PNF: PnP - PNFD/SDC AID/AAI Schema Modeling - for GeoLocation Discussion Sept 5 2019 - (Sept 5 2019) Discussion of Modeling
PNF: PnP - PNFD/SDC AID/AAI Schema Modeling - Discussion Oct 3 2019 - (Oct 3 2019) Discussion of Civic Address / Place-Location Model