Summary:
Single service design: single CFS with resources (VNFs+PNF). No nested services.
PNF PnP in E2E services: PNF PnP is not currently implemented in SO's CreateE2EService BPMN workflow, which is the one triggered by ExternalAPI during service instantiation
- PRH team to update PNF_READY internal event: BBS needs additional info to be passed in the PNF_READY event
- Service instance related info: SO team needs clarification on how those service instance metadatum are provided to SO and which data needs to be stored as metadata in AAI vs SDNC MD-SAL vs data that is only needed at orchestration time
Single service design
Nested services feature is not currently supported as expected in SO. There is a workaround involving allotted resources, but the easiest solution for us is to go with a design with a single service (CFS) and everything else as a resource underneath it (Access Connectivity, Internet Profile, CPE PNF...). This will not not impact our agreement with A&AI team for BBS. Everything that needs to be stored as metadata, can still be stored in the metadata section of the single CFS service instance. SDN-C will be creating every resource under one single service instance
- victor gao will have to handle the modeling changes so that in the service design, we can create one service with 2 VFs (Internet Profile and Access Connectivity), 1 PNF (CPE-ONT), and the necessary virtual-links/CPs.
- Stavros Kanarakis will have to change the bbs-event-processor microservice implementation to reflect the fact that everything will now be under a single CFS service.
PNF PnP flow in E2E services
PNF PnP flow part currently only works for normal service orchestration (services instantiated by VID). It is not implemented for E2E services orchestration (instantiated by an External API order request). As explained by Seshu Kumar Mudiganti, ExternalAPI can only trigger the instantiation of E2E Services in SO.
We need to check with the SO team how to handle it. It is a priority for BBS since we have based all of our flows in the PnP flow and we make use of ExternalAPI for service ordering and instantiation.
PRH team to update PNF_READY internal event
PRH needs to send additional information (additionalFields) coming in the PNF registration event that is BBS use case specific in the PNF_READY event (attachmentPoint, accessID, CVLAN, SVLAN).
PNF_Ready is published after AAI is updated with PNF relevant information.
It is initially agreed, that PRH will copy in 1:1 fashion the contents of VES.pnfRegistration.additionalFields structure/array/Map into the PNF_READY event, along with the correlationID parameter sent there already in ONAP/Casablanca release.
This allows other applications in the flow (BBS uS, SO,...) to react based on domain specific information sent in the pnfRegistration.additionalFields in addition to the standard PNF related attributes.
Service-instance-related information
We need to provide further details for each piece of data we want to store under A&AI as part of a service instance, since SO handles service-related information.
Specifically
- Where this information comes from? Ext-API when ordering a service? CL event? What is the API used?
- Is the piece really needed to be in A&AI? (for example if only SDN-C uses it for resource controlling, then it could just come as input to its NBI and stored in MD-SAL)
- Which component is going to use it from A&AI?
| BBS Properties Per HSIA CFS Service Instance | Input Source | ONAP Components that must fetch the value from A&AI | Does it really need A&AI storage? | A&AI Metaname (for Metadata) |
|---|---|---|---|---|
| RG MAC Address | Service Order via Ext API It also comes in the CPE Authentication Event | bbs-event-processor DCAE microservice (it fetches existing value from A&AI to compare it with the new value coming from PNF CPE authentication event in order to deduce if there is any mismatch) | Yes, as metadata of CFS service instance | rgw-mac-address |
| Correlation ID (PNF-name) | Service Order via Ext API It also comes in the sourceName of the PNF registration event's commonEventHeader | Yes, as property of PNF object | ||
| Service Type | Service Order via Ext API | |||
| Access ID | PNF registration event | |||
| Upstream Speed | Service Order via Ext API | |||
| Downstream Speed | Service Order via Ext API | |||
OLT Name | PNF registration event (extracted from attachment point) | |||
| OLT PON port | PNF registration event (extracted from attachment point) | |||
| OLT PON slot | PNF registration event (extracted from attachment point) | |||
CVLAN | PNF registration event | |||
| SVLAN | PNF registration event | |||
| Expected ONT ID | ||||
| CPE Manufacturer | PNF registration event | Yes, as property of PNF object | Not Applicable | |
| CPE Model | PNF registration event | Yes, as property of PNF object | Not Applicable | |
| CPE Equipment Type | PNF registration event | Yes, as property of PNF object | Not Applicable | |
| CPE Serial Number | PNF registration event | Yes, as property of PNF object | Not Applicable | |
| CPE SW Version | PNF registration event (also present in CPE Authentication Event) | Yes, as property of PNF object | Not Applicable | |
Attachment Point (Not a real BBS modeling property, since its constituent parts are captured in other model properties) | PNF registration event | bbs-event-processor DCAE microservice (it fetches existing value from A&AI to compare it with the new value coming from PNF re-registration event in order to deduce if it is a true relocation) | Yes, as value of link-name property of a logical-link bridged to the PNF object | Not Applicable |
ONT NNI Port | ||||
OLT NNI Slot | ||||
OLT NNI Port |