[RFCs/IDs] [Plain Text] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 10 11
12 13 14 15 16 17 18 RFC 3877
Disman Working Group S. Chisholm
Internet Draft Nortel Networks
Document: draft-ietf-disman-alarm-mib-01.txt D. Romascanu
Category: Standards Track Avaya Inc.
Expiration Date: Sept 2001 March 2 2001
Alarm MIB
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 defining
and storing alarms.
Table of Contents
1. The SNMP Management Framework
2. Introduction
3. Alarms Management Framework
3.1. Terminology
3.2. Alarm Management Architecture
3.3. Relation between Notifications and Alarms
3.4. Alarm Raises and Clears
3.5. Relation to Notification Log MIB
3.6. Relation to Model Specific Alarm MIBs
3.7. Alarm Notification Suppression
Chisholm & Romascanu Standards Track [Page 1]
Alarm MIB March 2001
4. MIB Overview
5. Definitions
6. Example
7. Security Considerations
8. Authors' Address
9. Acknowledgements
10. References
11. Full Copyright Statement
Chisholm & Romascanu Standards Track [Page 2]
Alarm MIB March 2001
1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
1215 [RFC1215]. The second version, called SMIv2, is described
in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
STD 58, RFC 2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is ;'ant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
Chisholm & Romascanu Standards Track [Page 3]
Alarm MIB March 2001
2. Introduction
It is important to be able to determine current alarms on a system,
so that the problems they are signalling can be fixed.
This MIB provides a model-neutral method to define and store alarms.
This MIB does not assume a particular alarm model, so it works with
any or no model. A distributed manager managing a network with
multiple alarm models, can therefore access SNMP alarm information
in a consistent manner across systems.
Alarms and other terms related to alarms management are defined in
the following sections. A modular architecture is defined, in which
the model-neutral alarm MIB can be augmented by other alarm
information, defined according to more specific models that
determine their behaviour and characteristics.
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 RFC 2119.
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 to a management
station. A fault, a change in status, crossing a threshold, or an
external input to the system, for example.
Notification
Unsolicited transmissions of management information.
Alarm
Persistent indication of a fault.
Alarm Raise
The initial detection of the fault indicated by an alarm. A
Notification SHOULD be sent on alarm raise.
Alarm Clear
The detection that the fault indicated by an alarm no longer
exists. A Notification SHOULD be sent on alarm clear.
Alarm Notification Suppression
Chisholm & Romascanu Standards Track [Page 4]
Alarm MIB March 2001
The process of not sending out the associated SNMP
notification related to a given alarm under controlled
conditions.
3.2 Alarm Management Architecture
This alarm definition and storage mechanism is defined independently
of any model used to describe the content and behaviour of alarms
within a system. Separate MIB modules that describe the alarm model
can be used, in addition to this model-neutral MIB, to fully
describe the alarm system.
An alarm definition consists of defining the OID of the notification
which SHOULD be sent out when an alarm is triggered. The alarm
definition SHOULD also consist of the definition of the raise/clear
relationship of the alarm. The definition SHOULD include the OID of
the notification that gets sent when the alarm is cleared.
3.3 Relation between Notifications and Alarms
Not all notifications are alarms. 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 uses the notification space as defined in [RFC2578] in
order to identify the notifications that are related with the
specific alarms. However there is no assumption that the respective
notifications MUST be sent for all or any of the alarms. This
architecture allows for both the efficient exploitation of the body
of defined notification and for the use of non-notification based
systems.
3.4 Alarm Raises and Clears
The raise and clear relationship between alarms is defined in the
alarmDetailsTable.
3.5 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 NOTIFICATION that can be
defined using SMI. Using the same format as the notification log
MIB also simplifies operations for systems choosing to implement
both MIBs.
The object alarmActiveLogIndex points for each entry in the
alarmActiveLogTable to the log index in the Notification Log MIB, if
used.
Chisholm & Romascanu Standards Track [Page 5]
Alarm MIB March 2001
If the Notification Log MIB is supported, it can be monitored by a
management system as a hedge against lost alarms.
3.6 Relation to Model Specific Alarm MIBs
This MIB can be used on its own, or with separately defined MIB
modules that are specific to particular alarm models. One example of
such a model is the ITU Alarm MIB [ Alarm MIB March 2001 11. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "'>ITU-ALARM-MIB].
The relationship between the Alarm MIB and the other alarm model MIB
modules is expressed by the following:
The alarmDetailsTable has a corresponding table in the specific
MIBs, with similar indexing. For each row in the specific MIB
details alarm table there is one row in the alarmDetailsTable.
The alarmActiveTable has a corresponding table in the specific MIBs
with similar indexing. For each row in the specific MIB active alarm
table there is one row in the alarmActiveTable.
The alarmDetailsModelPointer object in the alarmDetailsTable points
to the specific model corresponding to an alarm type. The
alarmActiveModelPointer object in the alarmActiveTable points to the
model specific active alarm table.
3.7 Alarm Notification Suppression
Alarm notification suppression methods are particular to specific
alarm models, so is therefore not covered in this document.
4. MIB Overview
The alarmDetailsTable contains information that is applicable to all
instances of an alarm. It can be populated at start-up with all
alarms that could happen on a system or later configured by a
management application. It contains all the alarms for a given
system. If a notification is not represented in the
alarmDetailsTable, it is not an alarm.
The alarmDetailsTable provides a means of defining the raise/clear
relationship between alarms. 'The object alarmDetailstype defines
the type of alarm - 'raise' or 'clear'. The relationship between
raise and clear alarms are defined by pairs of
alarmDetailsNotificationId and alarmDetailsClearNotificationId.
Different rows in the table can create 1:1, M:1, 1:N, or M:N
relationships between 'clear' and 'raise' alarms.'
The alarmActiveTable contains a list of alarms which are currently
occurring on a system. It is intended that this table be queried
upon device discovery and rediscovery to determine which alarms are
currently active on the device. This allows the network management
Chisholm & Romascanu Standards Track [Page 6]
Alarm MIB March 2001
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.
The alarmActiveVariableTable contains the trap variable bindings
associated with the alarms in the alarmActiveTable.
The alarmActiveStatsTable contains current and total raised alarm
counts as well as the time of the last alarm raise and alarm clears
per named alarm list.
5. Definitions
ALARM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
Integer32, Unsigned32,
TimeTicks, Counter32, Counter64,
IpAddress, Opaque, mib-2 FROM SNMPv2-SMI
TimeStamp, DateAndTime,
RowStatus, RowPointer FROM SNMPv2-TC
SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB
TimeFilter FROM RMON2-MIB
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
alarmMIB MODULE-IDENTITY
LAST-UPDATED "200103020000Z"
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO
" Sharon Chisholm
Nortel Networks
PO Box 3511 Station C
Ottawa, Ont. K1Y 4H7
Canada
schishol@nortelnetworks.com
Dan Romascanu
Avaya Inc.
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com"
DESCRIPTION
"The MIB module describes a generic solution
to define alarm details and the current list
of active alarms."
REVISION "200103020000Z"
DESCRIPTION
"Initial version, published as RFC XXXX."
::= { mib-2 xx }
Chisholm & Romascanu Standards Track [Page 7]
Alarm MIB March 2001
alarmObjects OBJECT IDENTIFIER ::= { alarmMIB 1 }
alarmDetails OBJECT IDENTIFIER ::= { alarmObjects 1 }
alarmActive OBJECT IDENTIFIER ::= { alarmObjects 2 }
alarmDetailsLastChanged OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
creation, deletion or modification of an entry in
the alarmDetailsTable.
If the number and content of entries has been unchanged
since the last re-initialization of the local network
management subsystem, then this object contains a zero
value."
::= { alarmDetails 1 }
alarmDetailsTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmDetailsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of information about possible alarms on the system."
::= { alarmDetails 2 }
alarmDetailsEntry OBJECT-TYPE
SYNTAX AlarmDetailsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries appear in this table for each possible alarm."
INDEX { alarmListName, alarmDetailsIndex }
::= { alarmDetailsTable 1 }
AlarmDetailsEntry ::= SEQUENCE {
alarmDetailsIndex Unsigned32,
alarmDetailsNotificationId OBJECT IDENTIFIER,
alarmDetailsClearNotificationId OBJECT IDENTIFIER,
alarmDetailsType INTEGER,
alarmDetailsModelPointer RowPointer,
alarmDetailsRowStatus RowStatus
}
alarmDetailsIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-only
Chisholm & Romascanu Standards Track [Page 8]
Alarm MIB March 2001
STATUS current
DESCRIPTION
"A integer which acts as an
index of entries within the named alarm list. "
::= { alarmDetailsEntry 1 }
alarmDetailsNotificationId OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The NOTIFICATION-TYPE object identifier of this alarm
raise. If this entry corresponds to a clear alarm, then
this object is the NOTIFICATION-TYPE object identifier
of the alarm clear."
::= { alarmDetailsEntry 2 }
alarmDetailsClearNotificationId OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The NOTIFICATION-TYPE object identifier of the alarm
clear associated with this alarm. If this entry
corresponds to a clear alarm, then this object should
be one of the NOTIFICATION-TYPE object identifier of
the alarm raise.
If this alarm has no corresponding clear alarm, then this
object is '0.0'."
::= { alarmDetailsEntry 3 }
alarmDetailsType OBJECT-TYPE SYNTAX INTEGER
{
other (1),
clear (2),
raise (3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" Indicates whether this is a raise or a clear alarm."
::= { alarmDetailsEntry 4 }
alarmDetailsModelPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If no additional, model-specific, alarm MIB is supported by the
system this object is `0.0'. When a model-specific alarm MIB is
supported, this object is the instance pointer to the specific
Chisholm & Romascanu Standards Track [Page 9]
Alarm MIB March 2001
model-specific alarm definition."
::= { alarmDetailsEntry 5 }
alarmDetailsRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Control for creating and deleting entries. Entries may be
modified while active.
This row can not be deleted while it is being referenced by a
value of alarmActiveDetailsIndex."
::= { alarmDetailsEntry 6 }
-- Active Alarm Table --
alarmActiveLastChanged OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
creation or deletion of an entry in the alarmActiveTable.
If the number of entries has been unchanged since the
last re-initialization of the local network management
subsystem, then this object contains a zero value."
::= { alarmActive 1 }
alarmActiveTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of Active Alarms entries."
::= { alarmActive 2 }
alarmActiveEntry OBJECT-TYPE
SYNTAX AlarmActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries appear in this table when alarms are raised. They
are removed when the alarm is cleared."
INDEX { alarmListName, alarmActiveTimeFilter,
alarmActiveIndex }
::= { alarmActiveTable 1 }
AlarmActiveEntry ::= SEQUENCE {
alarmListName SnmpAdminString,
alarmActiveTimeFilter TimeFilter,
alarmActiveIndex Unsigned32,
Chisholm & Romascanu Standards Track [Page 10]
Alarm MIB March 2001
alarmActiveTime TimeStamp,
alarmActiveDateAndTime DateAndTime,
alarmActiveEngineID SnmpEngineID,
alarmActiveEngineAddress IpAddress,
alarmActiveContextEngineID SnmpEngineID,
alarmActiveContextName SnmpAdminString,
alarmActiveVariables Unsigned32,
alarmActiveNotificationID OBJECT IDENTIFIER,
alarmActiveLogIndex Unsigned32,
alarmActiveDetailsIndex Unsigned32,
alarmActiveModelPointer RowPointer }
alarmListName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of the list of alarms. This is the same as
nlmLogName if the Nofication Log MIB [RFC3014] is supported.
An implementation may allow multiple named alarm lists, up to
some implementation-specific limit (which may be none). A
zero-length list name is reserved for creation and deletion
by the managed system, and MUST be used as the default log
name by systems that do not support named alarm lists."
::= { alarmActiveEntry 1 }
alarmActiveTimeFilter OBJECT-TYPE
SYNTAX TimeFilter
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A TimeFilter for this entry. Allows GetNext and GetBulk
to find flow table rows which have changed since a specified
value of sysUptime.
See the description of TimeFilter TC in [RFC2021] for more
information."
::= { alarmActiveEntry 2 }
alarmActiveIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A monotonically increasing integer which acts as the
index of entries within the named alarm list. It wraps
back to 1 after it reaches its maximum value."
::= { alarmActiveEntry 3 }
alarmActiveTime OBJECT-TYPE
SYNTAX TimeStamp
Chisholm & Romascanu Standards Track [Page 11]
Alarm MIB March 2001
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the alarm occurred. Alarms tend
to get cleared and re-raised if still applicable at reboot, so
this value tends to be a valid sysUptime. In the case where
the alarms are not cleared at reboot, and the alarm occurred
before the most recent management system initialization, this
object value MUST be set to zero."
::= { alarmActiveEntry 4 }
alarmActiveDateAndTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local date and time when the alarm occurred, instantiated
only by systems that have date and time capability."
::= { alarmActiveEntry 5 }
alarmActiveEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The identification of the SNMP engine at which the alarm
originated.
If the alarm list can contain Notifications from only one
engine or the Trap is from an SNMPv1 system, this object is
a zero length string."
::= { alarmActiveEntry 6 }
alarmActiveEngineAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP Address of the SNMP engine on which the alarm is
occuring. This is used to identify the source of an SNMPv1
trap, since an alarmActiveEngineId cannot be extracted from the
SNMPv1 trap pdu.
This object MUST always be instantiated, even if the list
can contain alarms from only one engine."
::= { alarmActiveEntry 7 }
alarmActiveContextEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the alarm is occurring on a device using a protocol which
Chisholm & Romascanu Standards Track [Page 12]
Alarm MIB March 2001
has a contextEngineID element like SNMPv3, this object has that
value. Otherwise its value is a zero-length string."
::= { alarmActiveEntry 8 }
alarmActiveContextName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The name of the SNMP MIB context from which the alarm came.
For SNMPv1 Traps this is the community string from the Trap.
If the alarm's source SNMP engine is known not to support
multiple contexts, this object is a zero length string."
::= { alarmActiveEntry 9 }
alarmActiveVariables OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of variables in alarmActiveVariableTable for this
Notification."
::= { alarmActiveEntry 10 }
alarmActiveNotificationID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The NOTIFICATION-TYPE object identifier of the alarm
that is occurring."
::= { alarmActiveEntry 11 }
alarmActiveLogIndex OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This number MUST be the same as the log index of the
applicable row in the notification log MIB, if it exists.
If no log index applies to the trap, then this object
MUST have the value of 0."
::= { alarmActiveEntry 12 }
alarmActiveDetailsIndex OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Chisholm & Romascanu Standards Track [Page 13]
Alarm MIB March 2001
"The index of the corresponding row in an alarm details
table."
::= { alarmActiveEntry 13 }
alarmActiveModelPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If no additional, model-specific, alarm MIB is supported by the
system this object is `0.0'. When a model-specific alarm MIB is
supported, this object is the instance pointer to the specific
model-specific active alarm list."
::= { alarmActiveEntry 14 }
-- Active Alarm Variable Table --
alarmActiveVariableTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmActiveVariableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of variables to go with active alarm entries."
::= { alarmActive 3 }
alarmActiveVariableEntry OBJECT-TYPE
SYNTAX AlarmActiveVariableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries appear in this table when there are variables in
the varbind list of a corresponding alarm in
alarmActiveTable."
INDEX { alarmListName, alarmActiveIndex,
alarmActiveVariableIndex }
::= { alarmActiveVariableTable 1 }
AlarmActiveVariableEntry ::= SEQUENCE {
alarmActiveVariableIndex Unsigned32,
alarmActiveVariableID OBJECT IDENTIFIER,
alarmActiveVariableValueType INTEGER,
alarmActiveVariableCounter32Val Counter32,
alarmActiveVariableUnsigned32Val Unsigned32,
alarmActiveVariableTimeTicksVal TimeTicks,
alarmActiveVariableInteger32Val Integer32,
alarmActiveVariableOctetStringVal OCTET STRING,
alarmActiveVariableIpAddressVal IpAddress,
alarmActiveVariableOidVal OBJECT IDENTIFIER,
alarmActiveVariableCounter64Val Counter64,
alarmActiveVariableOpaqueVal Opaque }
Chisholm & Romascanu Standards Track [Page 14]
Alarm MIB March 2001
alarmActiveVariableIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A monotonically increasing integer, starting at 1 for a given
alarmActiveIndex, for indexing variables within the active
alarm list."
::= { alarmActiveVariableEntry 1 }
alarmActiveVariableID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The variable's object identifier."
::= { alarmActiveVariableEntry 2 }
alarmActiveVariableValueType OBJECT-TYPE
SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3),
integer32(4), ipAddress(5), octetString(6),
objectId(7), counter64(8), opaque(9) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of the value. One and only one of the value
objects that follow is used, based on this type."
::= { alarmActiveVariableEntry 3 }
alarmActiveVariableCounter32Val OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'counter32'."
::= { alarmActiveVariableEntry 4 }
alarmActiveVariableUnsigned32Val OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'unsigned32'."
::= { alarmActiveVariableEntry 5 }
alarmActiveVariableTimeTicksVal OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'timeTicks'."
::= { alarmActiveVariableEntry 6 }
Chisholm & Romascanu Standards Track [Page 15]
Alarm MIB March 2001
alarmActiveVariableInteger32Val OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'integer32'."
::= { alarmActiveVariableEntry 7 }
alarmActiveVariableOctetStringVal OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'octetString'."
::= { alarmActiveVariableEntry 8 }
alarmActiveVariableIpAddressVal OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'ipAddress'."
::= { alarmActiveVariableEntry 9 }
alarmActiveVariableOidVal OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'objectId'."
::= { alarmActiveVariableEntry 10 }
alarmActiveVariableCounter64Val OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'counter64'."
::= { alarmActiveVariableEntry 11 }
alarmActiveVariableOpaqueVal OBJECT-TYPE
SYNTAX Opaque
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'opaque'."
::= { alarmActiveVariableEntry 12 }
-- Statistics --
alarmActiveStatsTable OBJECT-TYPE
Chisholm & Romascanu Standards Track [Page 16]
Alarm MIB March 2001
SYNTAX SEQUENCE OF AlarmActiveStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table represents the alarm statistics
information."
::= { alarmActive 4 }
alarmActiveStatsEntry OBJECT-TYPE
SYNTAX AlarmActiveStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Statistics on the current active alarms."
INDEX { alarmListName }
::= { alarmActiveStatsTable 1 }
AlarmActiveStatsEntry ::=
SEQUENCE {
alarmActiveStatsCurrentActive Unsigned32,
alarmActiveStatsTotalActive Unsigned32,
alarmActiveStatsLastRaise TimeTicks,
alarmActiveStatsLastClear TimeTicks
}
alarmActiveStatsCurrentActive OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of currently active alarms on the system."
::= { alarmActiveStatsEntry 1 }
alarmActiveStatsTotalActive OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of active alarms since system restart."
::= { alarmActiveStatsEntry 2 }
alarmActiveStatsLastRaise OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
Chisholm & Romascanu Standards Track [Page 17]
Alarm MIB March 2001
DESCRIPTION
"The value of sysUpTime at the time of the last
alarm raise for this alarm list.
If no alarm raises have occurred since the
last re-initialization of the local network management
subsystem, then this object contains a zero value."
::= { alarmActiveStatsEntry 3 }
alarmActiveStatLastClear OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
alarm clear for this alarm list.
If no alarm clears have occurred since the
last re-initialization of the local network management
subsystem, then this object contains a zero value."
::= { alarmActiveStatsEntry 4 }
-- Conformance
alarmConformance OBJECT IDENTIFIER ::= { alarmMIB 2 }
alarmCompliances OBJECT IDENTIFIER ::= { alarmConformance 1 }
alarmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for systems supporting
the Alarm MIB."
MODULE -- this module
MANDATORY-GROUPS {
alarmActiveGroup,
alarmDetailsGroup
}
::= { alarmCompliances 1 }
alarmGroups OBJECT IDENTIFIER ::= { alarmConformance 2 }
alarmDetailsGroup OBJECT-GROUP
OBJECTS {
alarmDetailsLastChanged,
alarmDetailsIndex,
alarmDetailsNotificationId,
alarmDetailsClearNotificationId,
alarmDetailsType,
alarmDetailsModelPointer,
alarmDetailsRowStatus
}
STATUS current
DESCRIPTION
Chisholm & Romascanu Standards Track [Page 18]
Alarm MIB March 2001
"Alarm details list group."
::= { alarmGroups 1}
alarmActiveGroup OBJECT-GROUP
OBJECTS {
alarmActiveLastChanged,
alarmListName,
alarmActiveTimeFilter,
alarmActiveIndex,
alarmActiveTime,
alarmActiveDateAndTime,
alarmActiveEngineID,
alarmActiveEngineAddress,
alarmActiveContextEngineID,
alarmActiveContextName,
alarmActiveVariables,
alarmActiveNotificationID,
alarmActiveDetailsIndex,
alarmActiveLogIndex,
alarmActiveModelPointer,
alarmActiveVariableIndex,
alarmActiveVariableID,
alarmActiveVariableValueType,
alarmActiveVariableCounter32Val,
alarmActiveVariableUnsigned32Val,
alarmActiveVariableTimeTicksVal,
alarmActiveVariableInteger32Val,
alarmActiveVariableOctetStringVal,
alarmActiveVariableIpAddressVal,
alarmActiveVariableOidVal,
alarmActiveVariableCounter64Val,
alarmActiveVariableOpaqueVal
} STATUS
current
DESCRIPTION
"Active Alarm list group."
::= { alarmGroups 2}
alarmActiveStatsGroup OBJECT-GROUP
OBJECTS {
alarmActiveStatsTotalActive,
alarmActiveStatsCurrentActive,
alarmActiveStatsLastRaise,
alarmActiveStatsLastClear
}
STATUS current
DESCRIPTION
" Active alarm summary group."
::= { alarmGroups 3}
Chisholm & Romascanu Standards Track [Page 19]
Alarm MIB March 2001
END
6. Example
Define the following Object:
acmeWidgetIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique number which identifies a particular Widget."
::= { acmeWidgetEntry 1 }
Define the following three traps:
acmeWidgetTemperatureCritical NOTIFICATION-TYPE
OBJECTS { acmeWidgetIndex }
STATUS current
DESCRIPTION
"This trap indicates that the indicated
widget has reached a critical temperature."
::= { acmeWidgetTraps 1 }
acmeWidgetTemperatureNormal NOTIFICATION-TYPE
OBJECTS { acmeWidgetIndex }
STATUS current
DESCRIPTION
"This trap indicates that the indicated widget has
reached a normal temperature."
::= { acmeWidgetTraps 2 }
dsx3LineStatusChange NOTIFICATION-TYPE
OBJECTS { dsx3LineStatus,
dsx3LineStatusLastChange }
STATUS current
DESCRIPTION
"A dsx3LineStatusChange trap is sent when the
value of an instance of dsx3LineStatus changes. It
can be utilized by an NMS to trigger polls. When
the line status change results in a lower level
line status change (i.e. ds1), then no traps for
the lower level are sent."
::= { ds3Traps 0 1 }
0. Active alarm table empty and nothing in notification log
___________________________ _____________________
| alarmActiveTable | | nlmLogTable |
|---------------------------| |---------------------|
| alarmActiveIndex | alarm | | nlmLogIndex | alarm |
|---------------------------| |---------------------|
|___________________________| |_____________________|
Chisholm & Romascanu Standards Track [Page 20]
Alarm MIB March 2001
1. Temperature of widget 2 goes critical
__________________________________________________
| alarmActiveTable |
|--------------------------------------------------|
| alarmActiveIndex | alarm |
|--------------------------------------------------|
| 1 | acmeWidgetTemperatureCritical |
|__________________________________________________|
_____________________________________________
| nlmLogTable |
|---------------------------------------------|
| nlmLogIndex | alarm |
|---------------------------------------------|
| 1 | acmeWidgetTemperatureCritical |
|_____________________________________________|
2. the value of an instance of dsx3LineStatus changes
__________________________________________________
| alarmActiveTable |
|--------------------------------------------------|
| alarmActiveIndex | alarm |
|--------------------------------------------------|
| 1 | acmeWidgetTemperatureCritical |
|__________________________________________________|
_____________________________________________
| nlmLogTable |
|---------------------------------------------|
| nlmLogIndex | alarm |
|---------------------------------------------|
| 1 | acmeWidgetTemperatureCritical |
| 2 | dsx3LineStatusChange |
|_____________________________________________|
Chisholm & Romascanu Standards Track [Page 21]
Alarm MIB March 2001
3. Temperature of widget 2 goes back to normal
__________________________________________________
| alarmActiveTable |
|--------------------------------------------------|
| alarmActiveIndex | alarm |
|--------------------------------------------------|
|__________________________________________________|
_____________________________________________
| nlmLogTable |
|---------------------------------------------|
| nlmLogIndex | alarm |
|---------------------------------------------|
| 1 | acmeWidgetTemperatureCritical |
| 2 | bgpBackwardTransition |
| 3 | acmeWidgetTemperatureNormal |
|_____________________________________________|
7. Security Considerations
There are a number of management objects defined in this MIB
that have a MAX-ACCESS clause of read-write and/or read-create.
Such objects may be considered sensitive or vulnerable in some
network environments. The support for SET operations in a
non-secure environment without proper protection can have a
negative effect on network operations.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2574 [RFC2574] and the View-
based Access Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
8. Authors' Address
Sharon Chisholm
Nortel Networks
PO Box 3511, Station C
Ottawa, Ontario, K1Y 4H7
Chisholm & Romascanu Standards Track [Page 22]
Alarm MIB March 2001
Canada
Email: schishol@nortelnetworks.com
Dan Romascanu
Avaya Inc.
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com
9. Acknowledgements
This document is a product of the DISMAN Working Group.
...
10. References
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 41999.
[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets", STD
16, RFC 1155, May 1990.
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1215] M. Rose, "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901,
January
Chisholm & Romascanu Standards Track [Page 23]
Alarm MIB March 2001
1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2572, April
1999.
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, April 1999.
[RFC2021] Waldbusser, S. "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021,
January 1997
[RFC2274] Blumenthal, U. and B. Wijnen, "User-based Security
Model (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2274, January 1998.
[RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2275, January 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3014] Stewart, B., Kavasseri, R., "Notification Log MIB,
RFC 3014, November 2000
[ITU-ALARM-MIB] Chisholm, S., Romascanu, D., "ITU Alarm MIB,
Work in Progress
Chisholm & Romascanu Standards Track [Page 24]
Alarm MIB March 2001
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Chisholm & Romascanu Standards Track [Page 25]
Html markup produced by rfcmarkup 1.70, available from
http://tools.ietf.org/tools/rfcmarkup/