RFC 3877
Alarm Management Information Base (MIB)
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.
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
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].
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.
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 & Traps3.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
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].
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.
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].
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].
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)
