Nevion Multicon MRP - Manual (Page 33)

Modular Routing Protocol - MRP Rev. L
nevion.com | 33
8
Server Alarms and Events
8.1 Alarm status
Alarms are sent as status messages asynchronously from the controller. Alarms are stored
in the system until they are deactivated and removed.
<status> ::= <alarm>
<alarm> ::= 'alarm' <alarmid> <alarm_details> <alarm_desc>
<alarm_details> ::= <state> <time> <user ID> <severity>
<alarm_desc> ::= '"'<origin>'"' '"'<description>'"'
<alarmid>
Unique number identifying the alarm.
<state> State of the alarm:
0 Removed: the alarm is not present. The alist response
is not required to include removed alarms, if
acknowledge is supported. Acknowledge of a restored
alarm will result in a removed response.
1 New: the alarm is active and has not been
acknowledged.
2 Restored: the alarm has been active, but is now gone.
Do acknowledge this alarm to remove it. Devices
without acknowledge support will not respond with
alarms in this state.
3 Acknowledged: the alarm is active and has been
acknowledged. The alarm will be removed if it becomes
inactive. Devices without acknowledge support will not
respond with alarms in this state. Do unacknowledge
this alarm to set it to new.
<time>
Time when the alarm state was last changed. Seconds since
January 1, 1970 (midnight UTC). Devices without a real-time
clock can respond with zero.
<severity>
The degree of alarm seriousness.
0 Ok
1 Information
2 Warning
3 Minor
4 Major
5 Critical
6 Unknown
<origin>
A description of the originator of the alarm. This string is comma
separated with details from highest layers first and closest to the
originating device last. Multiple layers can be used.
<description> A description of the alarm.