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
- Weitao 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 | SO / bbs-apex-policy (during Access Connectivity and Internet Profile VFCs creation & update) | Yes, as metadata of CFS service instance | service-type |
| Access ID | PNF registration event | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | remote-id |
| Upstream Speed | Service Order via Ext API | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | up-speed |
| Downstream Speed | Service Order via Ext API | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | down-speed |
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 Service Order via Ext API [optional - if not provided by Access SDN M&C] | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | cvlan |
| SVLAN | PNF registration event Service Order via Ext API [optional - if not provided by Access SDN M&C] | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | svlan |
| Expected ONT ID | Service Order via Ext API [optional] | SDN-C or SO? (for Access Connectivity VFC creation) | Yes, as metadata of CFS service instance | 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 | CPE PNF onboarding in SDC? | |||
OLT NNI Slot | Infrastructure bootstraping (manual script) ? | |||
OLT NNI Port | Infrastructure bootstraping (manual script) ? |
6 Comments
Damian Nowak
A few comments:
If it is planned to re-use that PNF management piece within teh SO workflow, then we need this parameter to be provided in ExtAPI, and SO API.
... are as well received in the pnfRegistration message, and are stored in the AAI within a PNF object, as part of PNF Registration Handler (PRH) processing.
Exact listing of pnfRegistration fields: https://onap.readthedocs.io/en/casablanca/submodules/vnfsdk/model.git/docs/files/VESEventListener_7_0_1.html#datatype-pnfregistrationfields
Majority of them are persisted in the AAI, after the pnfRegistration is received.
Stavros Kanarakis
Damian,
Do you refer to this mapping between service instance properties and the PNF registration fields?
CPE manufacturer < - - > pnfRegistrationFields:vendorName
CPE Equipment Type < - - > pnfRegistrationFields:unitType
CPE model < - - > pnfRegistrationFields:modelNumber
Damian Nowak
Well, not Service Instance, but PNF (resource) instance is updated in this fashion (Left side are AAI PNF instance parameters, Right side - pnfRegistration parameters):
..but this is on PNF instance level, not service instance level.
I see now, that you`re referring to CPE/HSIA service model here.
Adrian OSullivan
For the section "Single Service Design", the assumption from the Paris F2F was that the Service Model would be an E2E Service ( like VoLTE/CCVPN ). So the SDC modelling had originally planned to use the SDC category "E2E Service". I just want to make sure this is still the case based on the comments in section "PNF PnP flow in E2E services"?, i.e. the BBS CFS service is still from the customer perspective expected to be an automated E2E service delivery?.
The VID SO APIs are not geared for full Service Automation, i.e. each Operation task is performed manually via the UI ( createVnfInstance, createVolumeGroupInstance, etc etc all performed separately via the VID UI calling associated separate SO APIs. External API Framework currently supports calling the VID Service Create API ( POST "http://localhost/onap/so/infra/serviceInstantiation/{version}/serviceInstances" ) ,for non "E2E Service" SDC services but from a VID perspective this just creates a place holder in A&AI for the Service Instance. From a Service Order Automation perspective, SO E2E Service API is needed if we want to automate the delivery of the BBS CFS Service. Also SO currently does not support operation status notifications, so without the Service Order going via ExtAPI the BBS portal with not receive automatic notification of order progress either/ nor Service Inventory update notifications.
Stavros Kanarakis
Andrian, I recall that ExtAPI will be sending the correlation ID, right?
Adrian OSullivan
Hi Stavros Kanarakis , yes the correclation ID is listed on the modelling page as "PNF Name" as an Input. External API will pass all Attributes that is marked as an Input in the SDC CFS Service TOSCA Topology Model. These attributes will be captured by the BBS Portal ( michail salichos ) and passed as ServiceCharacteristics within the orderItem of a Service Order, these then are relayed by ExtAPI onto SO in the Create Service request to E2EServiceInstances API.