Alarm Subscription and Reporting Framework

The BAA layer provides the capability to receive alarms from pANs, adapt the alarm into the standard alarm as defined in the IETF YANG Alarm module (ietf-alarm) RFC 8632 and then forward the alarm based on subscriptions created by SDN M&C clients to the BAA layer.

The BAA layer uses the alarm-list and the alarm-inventory objects as defined in RFC 8632. The alarm-inventory contains the list of all possible alarm types (e.g., link-alarm, jitter-violation) generated by a pAN. The alarm-list contains the list of the alarm instances present on that pAN.

An alarm instance is identified by the tuple (resource, alarm-type identifier, and alarm-type qualifier). For example ("GigabitEthernet0/15", "link-alarm", “”) defines a link-alarm on the specified interface.

In addition the IETF YANG alarm module contains interesting parameters about an Alarm:

Note that “An alarm signifies an undesirable state in a resource that requires corrective action. (…) It also focuses on alarms as a state on a resource, not the notifications that report the state changes” (RFC 8632, section 3.1).

Notifications are sent when the alarm list changes. It is possible to control the severity of the alarms for which notifications are sent.

Alarm shelving is an optional feature that allows moving certain alarms to be blocked/filtered by moving them to a separate list.

Alarm Filtering

Alarms are filtered using notification subscriptions as defined in RFC 5277 section 5.1.

For example to receive all major and critical alarms, all severities from eth0 and only link-down alarms from eth1 the following subscription is created:

<create-subscription
   xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
   <filter netconf:type="subtree">
      <alarm-notification xmlns="urn:ietf:params:xml:ns:yang:ietf-alarms">
         <perceived-severity>major</perceived-severity>
      </alarm-notification>

      <alarm-notification xmlns="urn:ietf:params:xml:ns:yang:ietf-alarms">
         <perceived-severity>critical</perceived-severity>
      </alarm-notification>

      <alarm-notification xmlns="urn:ietf:params:xml:ns:yang:ietf-alarms">
         <resource>eth0</resource>
      </alarm-notification>

      <alarm-notification xmlns="urn:ietf:params:xml:ns:yang:ietf-alarms">
         <resource>eth1</resource>
         <al:alarm-type-id
            xmlns:vendor-alarms="urn:vendor:vendor-alarms">vendor-alarms:link-down</al:alarm-type-id>
      </alarm-notification>
   </filter>
</create-subscription>

In the above example, the subscription will filter by specific severities on all alarms, by a specific resource and by a specific alarm on a specific resource.

Alarm List

The BAA layer has an Alarm Service keeps an alarm-list per pAN which is populated by the notifications received from the device and is integrated with the alarm reporting flow described here.

Note that the alarm-list is necessary as some pANs do not support the standard IETF RFC 8632 Alarm YANG module. In this instance, the vendor adapter normalizes the notification to an ietf-alarm format using the Notification callback.

Alarm Forwarding

The alarm forwarding sequence is described below:

he device notification listener receives notifications from the pANs. A callback interface from notification service is used to forward notification with the device context.

Here the callback uses device interface for any notification translations and then publishes this to ALARM stream.

Device notification listener

The device notification listener receives the notification from a particular device and combines the device context with the notification and the calls the callback in the notification service. In addition the device notification client listeners are notified so that any application can implement this listener and perform business logic based on device-notification received. If the incoming notification is vendor-specific alarm notification, then the alarm is to be adapted prior to being sent to the callback.

Notification callback

The notification callback which is interested in an alarm-notification that is ietf-alarm compliant can extract the notification element call an interface to raise or clear the alarm.

The AlarmService defines the raise or clear actions and stores the alarm if necessary prior to forwarding the alarm notification to the Aggregator. The Aggregator then publishes the alarm to ALARM stream.

<–Architecture