Table Of Contents

Event and Alarm Correlation Flow

Software Function Architecture

Event Correlation Flow

Event Creation (VNE level)

Pre-Correlation Rule (Event Correlator)

Local Correlation (Event Correlator)

Network Correlation (Event Correlator, Flow)

Correlation Logic (Event Correlator)

Alarm Sending (Event Correlator)

Interrupt Alarm (Event Correlator)

Post-Correlation Rule (Event Correlator)

Event and Alarm Correlation Flow

---

This chapter describes in detail the flow of alarms and events during the correlation process.

Software Function Architecture

Figure C-1 Event Correlation Flow (VNE level)

---

Note See "Event and Alarm Configuration Parameters" for a detailed description of each parameter.

---

1. Decision based on the value of drop-event.

2. Decision based on the value of correlate.

3. Decision based on the value of send_uncorrelated.

4. Decision based on the value of is-correlation-allowed.

Event Correlation Flow

Event Creation (VNE level)

An event (EventCorrelationData) is created in the VNE level by three different sources:

•Device Component (DC)—When processing service alarms.

•EventProcessor—After parsing Syslog and SNMP trap.

•TCA Extension—After identifying a change in a property in the IMO.

The EventCorrelationData holds the following information:

Table C-1 Event Correlation Data Parameters

Name	Description	Type
Event Type	The type of the event. Alarms with the same Source and Event Type will be considered as a single alarm.	String
Event Sub Type	The sub type of the event (identifies the exact event definition that needs to be loaded).	String
Source	The OID of the IMO on which the event occurred on.	Oid
Correlation key	The string used for local correlation	String
Flow destination	The destination of a flow (if activate-flow is enabled).	Object
Flow starting point	The beginning of a flow (if activate-flow is enabled).	XID
Event time	The time the event occurred (as determined in the VNE).	Long
Description	A description of the event.	String

Pre-Correlation Rule (Event Correlator)

If the drop-event flag is not set to "true" the event will be processed by a set of pre-correlation rules.

The following are the potential actions taken by the pre-correlation rules:

1. Stop correlation.

2. Continue with next rule (if any).

3. Stop subsequent pre-correlation rule processing (for the current processed event).

Currently there is one pre-correlation rule:

•PreCorrelateDeviceUnreachableRule—This rule is used for special handling device unreachable and link down correlation.

Local Correlation (Event Correlator)

Local correlation will be performed if the correlate flag is set true and after waiting the time specified by the correlation-delay value.

The event correlation key is used to extract alarms that were waiting for correlation on that specific key. If alarms with the same correlation key exist the correlation logic is invoked to determine the best candidate of the locally available alarms. If the event did not find an alarm to correlate to, it will be put into the waiting for correlation event queue with its respective correlation key.

Network Correlation (Event Correlator, Flow)

Network correlation will be performed if the event was not locally correlated and the activate_flow flag is set to true. The following actions will be executed:

1. A trigger message of the type specified for the specific event definition is created.

2. The message is sent to the Event Correlator with the flow-delay specified and triggers the flow to collect alarms.

3. The flow starting and ending points are defined by the event correlation parameters (see Table C-1).

4. After the follow finishes it will get a message that contains all the collected alarms. Alarms are collected on every DC that the flow intercepts regardless of the original correlation key of the event that triggered it.

5. Next, it will initiate an "Interrupt Alarm" based on the alarms collected with the correlation key of the event that triggered the flow.

Correlation Logic (Event Correlator)

The correlation logic is used for determining the most fitting alarm to serve as a root cause for the specified event. It selects from the alarms with the highest weight which time-wise is closest to the event that it is being correlated.

Alarm Sending (Event Correlator)

Once an event has gone through the correlation process it will be transformed into an alarm and will be sent to the gateway.

Interrupt Alarm (Event Correlator)

After the alarm is created it will be interrupted on the correlation key of the original event that created it. The interrupt alarm causes all the events waiting for correlation to compare against the correlation key that is passed to the method in order to correlate them.

The interrupt alarm is then invoked recursively on every new alarm with the key being the source OID of the new alarm.

Post-Correlation Rule (Event Correlator)

The post-correlation rule is used for performing logic which needs to be performed after the event had been sent. Usually the post-correlation rule is used for triggering additional behaviors such as search for affected services that where influenced by the alarm.