DCAE does not do aggregation of  alarms for most if not all of the supported ONAP use cases.   The DCAE behavior for example on the VFW use case is that every packet assessed to be excess of the configured threshold, DCAE will an ONSET event for policy consumption.   This implies that Policy will get flooded with potentially hundreds of ONSETs at once being picked up from DMaaP.

More specifically, DCAE generates an ONSET event for the same “network fault” with _different_ request-ids, and alarm-start timestamps (as a note the alarm-start timestamp will differ in a few milliseconds from each other).    Correlation in Policy is challenging as the drools fact insertion, rule evaluation, and rule execution (underlying drools behavior) are somewhat independent. 

Processing of multiple ONSETs (potentially hundreds in a batch read) of the same underlying unique network alarm severely impacts performance, as PDP-D Control Loop APPs will perform high cost operations which include AAI custom queries (this in turn can take in the order of seconds to complete) up to the point that the ONSET could be discarded as considered as a duplicate of the same "network  alarm".   Further if the operation is blocking, as such is the case with AAI at present, it will deteriorate the response time severely, and substantially degrade the system, when the rate of incoming flooding ONSETs overwhelms the ONSET discard rate as it was just mentioned.

This task aims to mitigate/eliminate this problem.