VES event enrichment for DCAE mS

VES event enrichment for DCAE mS

 

 

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: 

 

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:

 

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

  1. 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).

  2. On Successful enrichment, CL event to Policy will be updated to set based on A&AI object