tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3877

 Errata 
Proposed STD
Pages: 75
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: DISMAN

Alarm Management Information Base (MIB)

Part 1 of 4, p. 1 to 10
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                        S. Chisholm
Request for Comments: 3877                               Nortel Networks
Category: Standards Track                                   D. Romascanu
                                                                   Avaya
                                                          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 Notice

   Copyright (C) The Internet Society (2004).

Abstract

   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
   storing alarms.

Top       Page 2 
Table of Contents

   1.  The Internet-Standard Management Framework . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Alarm Management Framework . . . . . . . . . . . . . . . . . .  4
       3.1.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  4
       3.2.  Alarm Management Architecture. . . . . . . . . . . . . .  5
       3.3.  Features of this Architecture. . . . . . . . . . . . . .  5
       3.4.  Security . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.5.  Relationship between Alarm and Notifications . . . . . .  9
       3.6.  Notification Varbind Storage and Reference . . . . . . .  9
       3.7.  Relation to Notification Log MIB . . . . . . . . . . . . 10
       3.8.  Relation to Event MIB. . . . . . . . . . . . . . . . . . 10
   4.  Generic Alarm MIB. . . . . . . . . . . . . . . . . . . . . . . 10
       4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.2.  Definitions. . . . . . . . . . . . . . . . . . . . . . . 15
   5.  ITU Alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . 38
       5.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . 38
       5.2.  IANA Considerations. . . . . . . . . . . . . . . . . . . 39
       5.3.  Textual Conventions. . . . . . . . . . . . . . . . . . . 47
       5.4.  Definitions. . . . . . . . . . . . . . . . . . . . . . . 49
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
       6.1.  Alarms Based on linkUp/linkDown Notifications. . . . . . 59
       6.2.  Temperature Alarm using generic Notifications. . . . . . 62
       6.3.  Temperature Alarm without Notifications. . . . . . . . . 63
       6.4.  Printer MIB Alarm Example. . . . . . . . . . . . . . . . 65
       6.5.  Rmon Alarm Example . . . . . . . . . . . . . . . . . . . 66
       6.6.  The Lifetime of an Alarm . . . . . . . . . . . . . . . . 67
   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 70
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
       9.1.  Normative References . . . . . . . . . . . . . . . . . . 72
       9.2.  Informative References . . . . . . . . . . . . . . . . . 73
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 74
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 75

Top      ToC       Page 3 
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
   [RFC2580].

2.  Introduction

   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
   following sections.

   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
   [RFC2119].

Top      ToC       Page 4 
3.  Alarm Management Framework

3.1.  Terminology

   Error
      A deviation of a system from normal operation.

   Fault
      Lasting error or warning condition.

   Event
      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.

   Notification
      Unsolicited transmission of management information.

   Alarm
      Persistent indication of a fault.

   Alarm State
      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.

   Alarm Raise
      The initial detection of the fault indicated by an alarm or any
      number of alarm states later entered, except clear.

   Alarm Clear
      The detection that the fault indicated by an alarm no longer
      exists.

   Active Alarm
      An alarm which has an alarm state that has been raised, but not
      cleared.

   Alarm Detection Point
      The entity that detected the alarm.

   Perceived Severity
      The severity of the alarm as determined by the alarm detection
      point using the information it has available.

Top      ToC       Page 5 
3.2.  Alarm Management Architecture

           +------------------------------------------------+
           |                                                |
           |  +------------------------------------+        |
           |  | Notification Management            |        |
           |  +------------------------------------+        |
           |          |                                     |
           +------------------------------------------------+
                      |
                      |
                      |
                      |<----------------------------------------------+
                      |                                               |
   +------------------V-------------+                                 |
   |  +---------------V-----------+ |                                 |
   |  |         RFC 3413          | |                                 |
   |  | SNMP-NOTIFICATION-MIB     | |                                 |
   |  +--------+--------------+-+-+ |                                 |
   |           |              | |   |                                 |
   |           |              | +------------------+                  |
   |           |              |     |              |                  |
   |           |              |     |   +----------V--------------+   |
   |           |              |     |   | +--------V---------+    |   |
   | +---------V------------+ |     |   | | Alarm Modelling  |    |   |
   | |       RFC 3014       | |     |   | | (descriptions)   |    |   |
   | | NOTIFICATION-LOG-MIB | |     |   | +--------+---------+    |   |
   | +----------------------+ |     |   |          |              |   |
   |                          |     |   | +--------V------------+ |   |
   | +------------------------V-+   |   | | Generic: Model-     | |   |
   | |         RFC 3413         |   |   | | Active : Specific   | |   |
   | | SNMP-TARGET-MIB          |   |   | | Alarms : Extensions | |   |
   | +----------+---------------+   |   | +--------+------------+ |   |
   |            |                   |   |          |              |   |
   +------------|-------------------+   +----------|--------------+   |
                |                                  |                  |
                |                                  +------------------+
                V
         Informs & Traps

3.3.  Features of this Architecture

3.3.1.  Modular Alarm Architecture

   The subject of alarm management can potentially cover a large number
   of topics including real-time alarms, historical alarms, alarm
   correlation, and alarm suppression, to name a few.  Within each of
   these topics, there are a number of established models that could be

Top      ToC       Page 6 
   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
   implementation supports.

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
   this problem.

   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
   SNMP-NOTIFICATION-MIB [RFC3413].

   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].

Top      ToC       Page 7 
   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
   instance.

3.3.8.  Active Alarm Management

   A list of currently active alarms and supporting statistics on the
   SNMP entity can be obtained.

Top      ToC       Page 8 
   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.

3.4.  Security

   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].

Top      ToC       Page 9 
   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
   Alarm MIB.

   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].

Top      ToC       Page 10 
   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
   used.

   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
   clarification.



(page 10 continued on part 2)

Next RFC Part