For supporting R1 usecases, DCAE expects VES events to be received from both VNF and VM through the VES Collector. Enrichment for these events are necessary for TCA, Holmes (both under DCAE platform) and Policy to support the close-loop flows.
For R1 – enrichment for only VNF and VM are being discussed in this scope; although same rules can be extended for PNF in future release.
Enrichment Key
VES specification requires the sender (vnf/vm) to populate sourceName – the actual entity generating the event to DCAE (note this value can be different from reportingEntityName incase when EMS is involved). This sourceName is expected under event.commonEventHeader.sourceName in the VES payload. This field is mandatory field in VES commonEventHeader and will be used as key for A&AI enrichment lookup
CL Event Structure (From DCAE mS to Policy)
Fields | Required | Description |
AAI | Yes | Contains the A&AI Node-Attribute list; dependent on successful enrichment of VNF/VM type |
closedLoopAlarmEnd | Yes - only for ABATED | When the alarm was cleared. This field need only be present in the ABATED message. |
closedLoopAlarmStart | Yes | When the alarm was first detected. |
closedLoopControlName | Yes | This is the unique ID for the Control Loop. It is created by the CLAMP platform during Control Loop design. The DCAE Micro service that publishes this event structure MUST include this ID. |
closedLoopEventClient | No | For monitoring/logging/auditing purposes, if there is an instance ID of the DCAE micro service this field should be populated with it. |
closedLoopEventStatus | Yes | This is the status of the closedLoopControlName/requestID pair. It can either ONSET or ABATED. |
from | Yes | The ONAP platform component publishing this message. If DCAE, then it should be 'DCAE'. |
policyName | The name of the Policy driving the DCAE micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller | |
policyScope | The scope of the Policy driving the DCAE micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller | |
policyVersion | The version of the Policy driving the DCAE Micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller | |
requestID | Yes | For the control loop, when an instance of the Control Loop occurs, this unique ID must be created. The same ID must be forwarded for both the ONSET and the ABATED control loop messages. |
target | Yes | This is the name of the field within the A&AI sub-tag that indicates the actual entity Node details. There should be a matching node field within the A&AI subtag holding this value. |
target_type | Yes | The type of the target: VM or VNF. Future PNF |
version | Yes | The version of the Control Loop event message. Should be '1.0.2' |
A&AI Enrichment APIs
VNF
Query generic-vnf object based on vnf-name (maps to event.commonEventHeader.sourceName in VES payload)
https://{aai}/aai/v11/network/generic-vnfs/generic-vnf?vnf-name={vnf-name}
Object Returned: v11-generic-vnf-object.docx
VM
Requires two step A&AI query
1) Perform node based query to identify the vserver object resource-link using vserver-name as parameter to below api (vserver-name maps to event.commonEventHeader.sourceName in VES payload)
On a successful match this would return following object containing resource-type and resource-link
result-data: object
resource-type: string
The specific type of node in the A&AI graph
resource-link: string
The URL to the specific resource
2) Use the "resource-link" returned to query A&AI to fetch the vserver specific details. (see VM examples below)
Object Returned: v11-vserver-object.docx
Based on the query parameters, the A&AI returned object can be received as json or xml. For JSON object – include ‘-H "Accept: application/json"’ in the request (default response is xml)
General enrichment guidelines for CL flow
- If there is indication from VES event (based on A&AI naming convention) or control loop parameters for mS – then appropriate A&AI api’s can be invoked directly. In the absence of information, mS will be required to call more than single API to determine the correct object to query (depending on VNF or VM – different APi’s call are invoked as noted above).
- On Successful enrichment, CL event to Policy will be updated to set based on A&AI object
For VNF, override below fields in CL event to Policy
"target_type":"VNF",
"target":"generic-vnf.vnf-name",
"AAI": {
"generic-vnf.in-maint": value,
"generic-vnf.is-closed-loop-disabled": value,
"generic-vnf.orchestration-status": value,
"generic-vnf.prov-status": value,
"generic-vnf.resource-version": value,
"generic-vnf.service-id": value,
"generic-vnf.vnf-id": value,
"generic-vnf.vnf-name": value,
"generic-vnf.vnf-type": value
}
For VM, override below fields in CL event to Policy
"target_type":"VM",
"target": "vserver.vserver-name",
"AAI": {
"vserver.in-maint": value,
"vserver.is-closed-loop-disabled": value,
"vserver.prov-status": value,
"vserver.resource-version": value
"vserver.vserver-id": value,
"vserver.vserver-name": value,
"vserver.vserver-name2": value
"vserver.vserver-selflink": value
}
3. If A&AI enrichment lookup fails, DCAE mS can identify the target CL structure based on configuration model defined per Closed loop.
For VNF, override below fields in CL event to Policy
"target_type":"VNF",
"target":"generic-vnf.vnf-name",
"AAI": {
"generic-vnf.vnf-name":$event.commonEventHeader.sourceName
}
For VM, override below fields in CL event to Policy
"target_type":"VM",
"target":"vserver.vserver-name",
"AAI": {
"vserver.vserver-name": $event.commonEventHeader.sourceName
}
Note: Policy would use lack of other A&AI fields as an indicator for failed DCAE enrichment sand attempts to query A&AI directly if necessary to perform the CL flow
4, The “requestId” field between Onset and abatement CL event should match for Policy team.
5. No enrichment necessary for Abatement event (per Pam/policy team)
VES Event Flow - VNF Enrichment example
VES Event Flow - VM Enrichment example
DCAE TCA design for Enrichment
Besides configuration for TCA processing, TCA configuration model will be enhanced to support following new configuration
- RESTProxyHost, RESTProxyPort, (this will be defined part of TCA app_config to indicate A&AI host/port (or MSB host/port) to be used for enrichment. This value will be preset into blueprint for demo setup)
- AppId, AppPwd (to match as provisioned in A&AI)
- Configurable cache time (to avoid repeated A&AI query)
- Per CL flow
- controlLoopSchemaType = VM|VNF
- closedLoopEventStatus= ONSET | ABATED
Enrichment flow (VM enrichment is stretch goal for R1)
- When new CL condition is met
- invoke A&AI to check vnf (generic-vnf object lookup)
If generic-vnf object lookup is successful
- Set/override fields based on new CL structure and set target-type and AAI setting based on generic-vnf object
If no match from A&AI – proceed to vm based check
- Invoke A&AI to check vserver (involves two additional AAI API call 1) get vserver link 2) query vserver object)
If vserver object lookup is successful
- Set/override fields based on new CL structure and set target-type and AAI setting based on vserver object
If no match from A&AI – proceed to configuration model based setting.
- Use configuration model identified “controlLoopSchemaType” to set CL event (structure as we have currently)
Reference
A&AI - https://wiki.onap.org/pages/viewpage.action?pageId=13598793