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 get the resource-link
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.
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 rules 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).
- 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-id", //modify to vnf-name instead?
"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-id", //modify to vnf-name instead?
"AAI": {
"generic-vnf.vnf-id":$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)