MDONS Close Loop Use Case
Introduction
This CL story is specified here as inter domain link restoration process. It is considered as an extension of MDONS use case from ONAP Frankfurt release.
Design & Implementation
The scope of code change will be very limited with the existing capability at ONAP CLAMP, DCAE and POLICY components. Given the fact that FNC Virtuora MSA support has already delivered
L0/L1 alarms and PM data in VES (CEDM) (7.0 version) format. However, those delivered through TAPI APIs are retrieved from FPM server and converted into TAPI standard in Json format.
HLD
Close Loop Diagram in MDONS
- SDC/DCAEMOD/Policy Portal design and activate policy.
- Policy config and activate the policy.
- SDC/DCAEMOD distribute the DCAE config.
- SDC/DCAEMOD/HOMES UI distribute the alarm correlation rules to Holmes.
- 3rd party domain controllers report link down alarm to DCAE
- DCAE will do data cleaning and filtering for the alarms
- DCAE keep track the data.
- Holmes do analysis for the alarms.
- Holmes notify the reroute event.
- Policy matching the reroute rules.
- Policy call SO or SDNC to delete the old services and create the new services. For the creation flow, a variable route will be recalculated.
Domain Controller APIs
MSA
TAPI
DCAE
Option 1 - RCC/VES Mapper
Data Collection Diagram
If the notification data is received from domain controller in non-VES format, such as, TAPI, and/or other JSON format, RCC is the data collection micro-service and VES Mapper micro-service is needed to convert the alarm notification into VES format.
RestConf Collector (RCC)
In MDONS use case, prior to subscribing to topics to get event notifications. We manually register 'DCAE' in the domain controller (DC). Once registration is successful, system can subscribe to different topics of DC to get event notification. It is mandatory to pass 'notification URL' to DC so that when event occurs it posts notification to that URL.
- DCAEGEN2-2293Getting issue details... STATUS
Alarm Notification
- TAPI Alarm Notification[TAPI format]
- OpenRoadM Alarm Notification[VES format]
Since MSA notification is already in VES format, it could be posted directly on to DMAAP with relevant topic to be consumed by Hulmes directly. If RCC does not support such configuration, then a 1n1 attribute mirroring mapping xml file need to be designed to feed the data into the existing flow. Thus, VES Mapper plays the role of VES event validation as it is required functionality in VES collector.
MS Blueprint
This is the RCC blueprint which defines the initial configuration for alarm collection in MDONS close loop. RCC supports multiple DC connections.
RCC_Output Event
This event is the output to be posted on Dmaap by RCC and will be consumed by VES Mapper.
VES Mapper
Mapping File
- TAPI Alarm to VES Mapping template
- MSA Data are already in VES format. If VES Collector supports Rest API notification mode, MDONS can use VES collector for OpenRoadM data collection from domain controller.
VES Event
Mapper output as an VES event is posted back to Dmaap.
Option 2 - VES Colloctor
In case the domain controller acts like a VES client that can deliver the notification data in VES format, VES collector micro-service is needed and VES mapper could be skipped in the data collection flow in MDONS closed instance.
HOLMES
- HOLMES-312Getting issue details... STATUS
AAI APIs
Upon receiving NNI down alarm:
- AAI APIs - APIs to update status of related NNI status, retrieve alarm correlation keys and related service instance IDs, etc.
Code change needs to be introduced for functions to adapt the above AAI APIs from the correlation rules.
Drools Rule - Alarm Correlation
- Alarm Correlation Rules - Drools rules design time from SDC or Holmes UI to correlate the alarms.
Upon receiving NNI up notification - update the status of the NNI in AAI.
Output
POLICY
Operational Policy
Policy Engine - Apex
Apex Policy Engine is used in MDONS use case to execute the operational Policy.