Network Working Group S. Chisholm
Request for Comments: 3877 Nortel Networks
Category: Standards Track D. Romascanu
September 2004 Alarm Management Information Base (MIB)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2004).
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes management objects used for modelling and
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
In traditional SNMP management, problems are detected on an entity
either through polling interesting MIB variables, waiting for the
entity to send a Notification for a problem, or some combination of
the two. This method is somewhat successful, but experience has
shown some problems with this approach. Managers monitoring large
numbers of entities cannot afford to be polling large numbers of
objects on each device. Managers trying to ensure high reliability
are unable to accurately determine whether any problems had occurred
when they were not monitoring an entity. Finally, it can be time
consuming for managers to try to understand the relationships between
the various objects they poll, the Notifications they receive and the
problems occurring on the entity. Even after detailed analysis they
may still be left with an incomplete picture of what problems are
occurring. But, it is important for an operator to be able to
determine current problems on a system, so they can be fixed.
This memo describes a method of using alarm management in SNMP to
address these problems. It also provides the necessary MIB objects
to support this method.
Alarms and other terms related to alarm management are defined in the
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
3. Alarm Management Framework
A deviation of a system from normal operation.
Lasting error or warning condition.
Something that happens which may be of interest. A fault, a
change in status, crossing a threshold, or an external input to
the system, for example.
Unsolicited transmission of management information.
Persistent indication of a fault.
A condition or stage in the existence of an alarm. As a minimum,
alarms states are raise and clear. They could also include
severity information such as defined by perceived severity in the
International Telecommunications Union (ITU) model [M.3100] -
cleared, indeterminate, critical, major, minor and warning.
The initial detection of the fault indicated by an alarm or any
number of alarm states later entered, except clear.
The detection that the fault indicated by an alarm no longer
An alarm which has an alarm state that has been raised, but not
Alarm Detection Point
The entity that detected the alarm.
The severity of the alarm as determined by the alarm detection
point using the information it has available.
supported. This memo focuses on a subset of this problem space, but
describes a modular SNMP alarm management framework. Alarms SHOULD
be modelled so Notifications are sent on alarm Clear.
The framework defines a generic Alarm MIB that can be supported on
its own, or with additional alarm modelling information such as the
provided ITU Alarm MIB. In addition, the active alarm tables could
also be extended to support additional information about active alarm
instances. This framework can also be expanded in the future to
support such features as alarm correlation and alarm suppression.
This modular architecture means that the cost of supporting alarm
management features is proportional to the number of features an
3.3.2. Flexible Alarm Modelling
Alarm models document an understanding between a manager and an agent
as to what problems will be reported on a system, how these problems
will be reported, and what might possibly happen over the lifetime of
The alarm modelling method provided in this memo provides flexibility
to support implementations with different modelling requirements.
All alarms are modelled as a series of states that are related
together using an alarm ID. Alarm states can be modelled using
traditional Notifications, generic alarm Notifications, or without
the use of Notifications.
Alarm states modelled using traditional Notifications would specify a
Notification Object Identifier, and optionally an (offset, value)
pair of one of the Notification varbinds to identify the state. This
alarm state would be entered when the entity generated a Notification
that matched this information and the alarm would be added to the
active alarm table. This Notification would also get sent on the
wire to any destinations, as indicated in the SNMP-TARGET-MIB and
Alarm states modelled using generic Notifications use the
alarmActiveState or alarmClearState Notifications defined in this
memo. These alarm states would be entered after being triggered by a
stimulus outside the scope of this memo, the alarm would be added to
the active alarm table and these generic Notifications would then be
sent on the wire to any destinations, as indicated in the SNMP-
TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413].
Alarm states modelled without any Notifications would be triggered by
some stimulus outside the scope of this memo, the alarm would be
added to the active alarm table, but no Notifications would be sent
to interested managers.
3.3.3. Problem Indication
The Alarm MIB provides a means to determine whether a given
notification is of interest to managers for purposes of alarm
management by permitting inspection of the alarm models. If no
entries in the alarmModelTable could match a particular notification,
then that notification is not relevant to the alarm models defined.
In addition, information in the alarm model, such as the Notification
ID and the description tell exactly what error or warning condition
this alarm is indicating. If the ITU-ALARM-MIB is also supported,
additional information is provided via the probable cause.
3.3.5. Identifying Resource under Alarm
An important goal of alarm management is to ensure that any detected
problems get fixed, so it is necessary to know exactly where this
problem is occurring. In addition, it is necessary to be able to
tell when alarm instances are raised against the same component, as
well as to be able to tell what instance of an alarm is cleared by an
instance of an alarm clear.
The Alarm MIB provides a generic method for identifying the resource
by extracting and building a resource ID from the Notification
varbinds. It records the relevant information needed to locate the
source of the alarm.
3.3.6. Means of obtaining ITU alarm information
Alarm Information, as defined in ITU alarm models [M.3100], is
optionally available to implementations through the optional support
of the ITU-ALARM-MIB.
3.3.7. Configuration of Alarm Models
An alarm model can be added and removed during runtime. It can be
modified assuming it is not being referenced by any active alarm
3.3.8. Active Alarm Management
A list of currently active alarms and supporting statistics on the
SNMP entity can be obtained.
This allows the network management station to find out about any
problems that may have occurred before it started managing a
particular network element, or while it was out of contact with it.
3.3.9. Distributed Alarm Management
All aspects of the Alarm MIB can be supported both on the device
experiencing the alarms and on any mid-level managers that might be
monitoring such devices.
3.3.10. Historical Alarm Management
Some systems may have a requirement that information on alarms that
are no longer active is available. This memo provides a clear table
to support this requirement.
This can also be achieved through the support of the Notification Log
MIB [RFC3014] to store alarm state transitions.
Given the nature of VACM, security for alarms is awkward since access
control for the objects in the underlying Notifications can be
checked only where the Notification is created. Thus such checking
is possible only for locally generated Notifications, and even then
only when security credentials are available.
For the purpose of this discussion, "security credentials" means the
input values for the abstract service interface function
isAccessAllowed [RFC3411] and using those credentials means
conceptually using that function to see that those credentials allow
access to the MIB objects in question, operating as for a
Notification Originator in [RFC3413].
The Alarm MIB has the notion of a named alarm list. By using alarm
list names and view-based access control [RFC3415] a network
administrator can provide different access for different users. When
an application creates an alarm model (indexed in part by the alarm
list name) the security credentials of the creator remain associated
with that alarm model and constrain what information is allowed to be
placed in the active alarm table, the active alarm variable table,
the cleared alarm table, and the ITU alarm table.
When processing locally-generated Notifications, the managed system
MUST use the security credentials associated with each alarm model
respectively, and MUST apply the same access control rules as
described for a Notification Originator in [RFC3413].
The managed system SHOULD NOT apply access control when processing
remotely-generated Notifications using the alarm models. In those
cases the security of the information in the alarm tables SHOULD be
left to the normal, overall access control for those tables.
3.5. Relationship between Alarm and Notifications
It is important to understand the relationship between alarms and
Notifications, as both are traditional fault management methods.
This relationship is modelled using the alarmModelTable to define the
alarmModelNotificationId for each alarm state.
Not all Notifications signal an alarm state transition. Some
Notifications are simply informational in nature, such as those that
indicate that a configuration operation has been performed on an
entity. These sorts of Notifications would not be represented in the
The Alarm MIB allows the use of the Notification space as defined in
[RFC2578] in order to identify the Notifications that are related
with the specific alarm state transitions. However there is no
assumption that the respective Notifications must be sent for all or
any of the alarm state transitions. It is also possible to model
alarms using no Notifications at all. This architecture allows for
both the efficient exploitation of the body of defined Notification
and for the use of non-Notification based systems.
3.6. Notification Varbind Storage and Reference
In SNMPv1 [RFC1157], the varbinds in the Trap-PDU sent over the wire
map one to one into those varbinds listed in the SMI of the trap in
the MIB in which it was defined [RFC1215]. In the case of linkDown
trap, the first varbind can unambiguously be identified as ifIndex.
With the introduction of the InformRequest-PDU and SNMPv2-Trap-PDU
types, which send sysUptime and snmpTrapOID as the first two
varbinds, while the SMI in the MIB where the Notification is defined
only lists additional varbinds, the meaning of "first varbind"
becomes less clear. In the case of the linkDown Notification,
referring to the first varbind could potentially be interpreted as
either the sysUptime or ifIndex.
The varbind storage approach taken in the Alarm MIB is that sysUptime
and snmpTrapOID SHALL always be stored in the active alarm variable
table as entry 1 and 2 respectively, regardless of whether the
transport was the Trap-PDU, the InformRequest-PDU or the SNMPv2-
Trap-PDU. If the incoming Notification is an SNMPv1 Trap-PDU then an
appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be
determined by using the rules in section 3.1 of [RFC3584].
The varbind reference approach taken in the Alarm MIB is that, for
variables such as the alarmModelVarbindIndex, the first two
obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU need
to be considered so the index values of the Trap-PDU and the SMI need
be adjusted by two. In the case of linkDown, the third varbind would
always be ifIndex.
3.7. Relation to Notification Log MIB
The Alarm MIB is intended to complement the Notification Log MIB
[RFC3014], but can be used independently. The alarmActiveTable is
defined in manner similar to that of the nlmLogTable. This format
allows for the storage of any Trap or Notification type that can be
defined using the SMI, or can be carried by SNMP. Using the same
format as the Notification Log MIB also simplifies operations for
systems choosing to implement both MIBs.
The object alarmActiveLogPointer points, for each entry in the
alarmActiveLogTable, to the log index in the Notification Log MIB, if
If the Notification Log MIB is supported, it can be monitored by a
management system as a hedge against lost alarms. The Notification
Log can also be used to support historical alarm management.
3.8. Relationship with the Event MIB
During the work and discussions in the Working Group, the issue of
the relationship between the MIB modules and the Event MIB [RFC2981]
was raised. There is no direct relation or dependency between the
Alarm MIB and the Event MIB. Some common terms (like 'event') are
being used in both MIB modules, and the user is directed to the
sections that define terminology in the two documents for