Network Working Group An-ni Huynh (Cetus)
Expires May 15, 2002 Condition MIB David Perkins (SNMPinfo)
Internet Draft Kam Lam (Lucent)
November 15, 2001
CONDITION & ARC MIB
draft-ietf-disman-conditionmib-01.txt
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.
[Editor's Note:
This version (01) of the condition/arc mib contains the following updates:
(1) In the condition mib module, the X.733 probable causes have been
replaced by the Alarm MIB IANAItuProbableCause, which is a consolidated
list from M.3100, X.733 and X.736. Editor notes have been removed.
(2) In the ARC mib module, the TI and CD Time Interval objects have been
separated from the arcTable such that the time intervals can be used by
all ARC settings.
(3) Conformance statements have been added.
(4) Editorial changes.]
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
1. Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for current and historical data of
conditions of a network device. Traps are defined for notifying the
status of a condition. This memo also defines objects for controlling
the reporting of conditions.
Textual Conventions used in this MIB are defined in [RFC2579].
Table of Contents
1 Abstract .............................................. xx
2 The SNMP Network Management Framework ................. xx
3 Introduction ......................................... xx
3.1 Terminology ........................................ xx
3.2 Alarm Definition ................................... xx
4 Condition MIB Overview ................................ xx
4.1 Role of the Condition MIB ........................... xx
4.2 Structure of the Condition MIB ...................... xx
5 ARC MIB Overview ...................................... xx
5.1 Relationship of ARC/Condition/Alarm MIB ............. xx
6 Condition MIB Object Definitions....................... xx
7 ARC MIB Object Definitions ............................ xx
8 Security Considerations ............................... xx
9 Acknowledgments........................................ xx
10 References ............................................ xx
11 Author's Address ...................................... xx
12 Intellectual Property ................................. xx
Full Copyright Statement ................................. xx
2. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major
components:
0 An overall architecture, described in RFC 2571 [RFC2571].
0 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].
0 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].
0 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 compliant 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 (e.g., 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.
3. Introduction
The scope of this MIB is target for network administrators responsible
for managing the operations of network resources. This document contains
two MIB modules: Condition MIB module and ARC MIB module.
The Condition MIB provides a mechanism for a manager to:
(1) retrieve information of current conditions in a system,
and its condition history,
(2) receive an unified notification of the occurrence of an condition,
(3) suppress the alarm notification based on the condition severity level.
The ARC MIB provides a mechanism for a manager to:
(4) suppress or defer the reporting of conditions based on the resource
and condition type.
3.1 Terminology
[Editor's note: The terms listed here need to be agreed upon
by the design team.]
Condition
A standing or transient condition that has occurred in a system.
A condition does not have to be an error or fault condition.
For instance, a manager may want to receive a notification when a
circuit pack is inserted to the system.
Error
A deviation of a system from intended operation.
Fault
A lasting error or warning condition.
Alarm
An indication of a fault.
An alarm is said to be 'set' when a standing condition is first
detected and administratively enabled.
An alarm is said to be 'cleared' when the standing condition is first
noticed to have ceased or administratively disabled.
An alarm is said to be 'raised' when a transient condition or an event
is detected and administratively enabled, e.g. insertion of a
circuitpack.
An alarm can be suppressed or deferred while the condition is standing.
Event
Something that happened. Examples include a change in status,
crossing a threshold, an external input to the system.
Additionally, setting or clearing an alarm is also an event.
Notification
An unsolicited transmission of management information due to an
event or condition.
3.2 Alarm Definitions
[Editor's note: is it going to be a finite set of alarm types abstraction?
If so, we may need to distinguish ConditionProbableCause from alarmType?
However, this section is incorporated here to assist the design of the
AlarmType textual convention.]
Each type of an alarm needs to be well specified. Ideally, a new
construct (or template) would be added to the MIB module language,
which is specified by SNMP's SMI. Unfortunately, this is not
possible. Since alarms are identified with an OID value, the best
choice of construct to use is OBJECT-IDENTITY. This construct allows
a descriptor to be defined, a status and description specified, and
an OID value assigned. The contents of the DESCRIPTION text must be
structured to specify the attributes of an alarm type. The
attributes include:
Raise Conditions
What set of conditions or events cause the alarm to be raised?
Clear Conditions
What must occur to cause the alarm to be cleared?
Source Identification
How are the sources of the alarm identified (a source can be
physical (such as port), or logical, such as a session)?
Perceived Severity
How is the perceived severity of the alarm determined (it may
be statically specified or dynamically determined)?
Service Affecting
How is it determined if the condition is service affecting (it
may be statically specified or dynamically determined)?
Associated Information
What additional information is associated, if any, with the
alarm? For example, if the alarm is due to a threshold being
crossed, the additional information could be the threshold
value and the current value.
Class (Category)
What is the class (category) of the alarm using the ITU-T
terminology?
Probable Cause
How is the probable cause of the alarm determined (it may be
statically specified or dynamically determined)?
Dependencies
What are the dependencies, if any, between this alarm and other
alarms. For example, a loss of signal alarm on a network
interface would probably also result in a network interface
down alarm.
4. Condition MIB Overview
4.1 Role of the Condition MIB
____________________
/\ :----------: | | :----------: /\
| : Condition: | Top Level | : Generic : |
| : MIB : | Manager | : ALARM : |
| :----------: |____________________| : MIB : |
| / | \ \ :--------- : |
| / | \ \ |
| / | \ \ |
| / | \ \_________________ |
| / | \ | |
| ___/ | \____ | |
| _____|_____ ___|_____ ____|_____ | |
| | Mid-Level | | Mid-Level| |Mid-Level | | |
| | Manager | | Manager | | Manager | | |
| |___________| |__________| |__________| | |
| /\ /\ /\ | |
| | | | | High Level
Detailed level | | | | Alarm
Alarm Management | | | | Abstraction
| | | | | |
| _______|_____ ____|_______ __|_______ ____|_____ =======
| | :Generic: | | :Generic: | |:Generic: | |:Generic: |
| | : Alarm : | | : Alarm : | |: Alarm : | |: Alarm : |
| | : MIB : | | : MIB : | |: MIB : | |: MIB : |
| | --------- | | --------- | |--------- | |--------- |
| | | | | | | | |
| | Mid-Level | |Large Scale | | Simple | | Simple |
| | Manager | | Network | | Network | | Network |
| |(sub-network)| | Device | | Device | | Device |
| |_____________| | | |__________| |__________|
====== /\ |:----------:|
| |: Condition:|
| |: MIB :|
| |:----------:|
| |____________|
_______|______
| |
| Large Scale |
| Network |
| Device |
| |
| :----------: |
| : Condition: |
| : MIB : |
| :----------: |
|______________|
case 1 case 2 case 3 case 4
Fig 1. Alarm Management MIB modules
The relationship of the Condition MIB and the generic alarm MIB in a
distributed management environment is illustrated in Fig 1.
The Condition MIB is defined in this document.
The Generic Alarm MIB refers to draft-ietf-disman-alarm-mib-xx.txt
Depending on the size and the architecture of the management network, there
may be a multiple level of management systems in a large scale network
(case 1, 2, or 3) or a single management system (case 4).
The generic alarm MIB provides a high level view of the network device
status while the Condition MIB reports the detail information to identify the
source of an abnormal condition in a large scale network devices.
4.2 Structure of the Condition MIB
This MIB module defines three tables. All active standing conditions
can be retrieved from the condActiveTable. As standing conditions
are cleared, they are moved from the condActiveTable to condRetiredTable.
The third table condTransientTable stores the information of all transient
conditions.
Two notifications are defined for multiple notification types:
condActiveEvent, and condRetiredEvent. Both notifications specify the
condition information from its variables (e.g., condition location,
condition category, level of severity, and probable cause).
Notifications are generated based on the value of condNotificationSelection.
A SNMP agent sends notifications based on the level of severity of the
conditions. It is the responsibility of the manager to periodically
synchronize with the agent using the condActiveTable and condRetiredTable
to determine if any condition notification have been missed.
5. ARC MIB Overview
There is a need to provide a mechanism for controlling the reporting
of alarm conditions of resources in a network device. For examples,
(a) inhibiting the reporting of alarm conditions of a resource until
the resource is problem-free, (b) inhibiting the reporting of alarm
conditions of a resource for a specified time period, or
(c) inhibiting the reporting of alarm conditions of a resource
until explicitly allowed later on by the managing system.
The alarm reporting control (ARC) feature provides an automatic
in-service provisioning capability. It allows sufficient time for
service setup, customer testing, and other maintenance activities in
an "alarm-free" state. Once a resource is "problem-free",
alarm reporting is automatically (or manually) turned on
(i.e., allowed).
By putting a network resource in ARC mode, the technicians and
managing systems will not be flooded with unnecessary work items
during operations activities such as service provisioning and
network setup/teardown. This will reduce maintenance costs and
improve the operation and maintenance of these systems.
ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3] provides the
business requirements, analysis, and design of the Alarm Reporting
Control Feature.
This MIB module defines the SNMP objects to support a subset of
the ARC functions described in M.3100 Amd3. In particular, it defines
a table that contains the ARC setting for the resources in a system.
Management objects for defining and storing alarms, including active
and history alarms, standing and transient alarms, are described in
the Alarm MIB, ITU Alarm MIB, and Condition MIB.
5.1 Relationship between ARC MIB, Condition MIB, and generic alarm MIB
The ARC mode has no impact on the Condition MIB.
However, the generic alarm mib may be impacted by the ARC state.
- For alarm condition raised prior to entering ARC mode, reporting
of alarm raised and alarm cleared will be sent as usual.
That it, ARC has no impacts.
- For alarm condition raised after entering ARC mode and also
cleared before exiting ARC mode, no reporting of raised will be
sent and no reporting of cleared will be sent.
- For alarm condition raised after entering ARC mode and cleared
after exiting ARC mode, the reporting of alarm raised will be
deferred until the moment of exiting ARC mode. The reporting of
alarm clear will be sent as usual (i.e., at the time of alarm
cleared).
Further details can be found in M.3100 Amd3.
6. Object Definitions
Condition-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32,
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, DateAndTime, TruthValue
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
IANAItuProbableCause
FROM ALARM-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
condMIB MODULE-IDENTITY
LAST-UPDATED "200111150000Z" -- November 15, 2001
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO
"WG-email: disman@dorothy.bmc.com
Subscribe: disman-request@dorothy.bmc.com
In message body:
subscribe disman your_email_address
Archive: ftp://amethyst.bmc.com/pub/disman/archives
Chair: Randy Presuhn
BMC Software
EMail: rpresuhn@bmc.com
Phone: +1-301-854-6889
Authors: Anni Huynh
a_n_huynh@yahoo.com
David T. Perkins
dperkins@dsperkins.com
Mark A. Stewart
mstewart1@nc.rr.com
Kam Lam
hklam@lucent.com
DESCRIPTION
"The MIB module defines MIB objects and notifications that
provide mechanisms to monitor abnormal conditions currently active and
the history of abnormal conditions being set and cleared on a managed
system."
REVISION "200111150000Z"
DESCRIPTION
"The initial revision"
::= { mib-2 yy }
------------------
-- MIB Objects
------------------
condMIBObjects OBJECT IDENTIFIER ::= { conMIB 1 }
condActive OBJECT IDENTIFIER ::= { condMIBObjects 1 }
condRetired OBJECT IDENTIFIER ::= { condMIBObjects 2 }
condStanding OBJECT IDENTIFIER ::= { condMIBObjects 3 }
condNotice OBJECT IDENTIFIER ::= { condMIBObjects 4 }
--------------
-- Event
--------------
condEvents OBJECT IDENTIFIER ::= { condMIB 2 }
condEventsV2 OBJECT IDENTIFIER ::= { condEvents 0 }
----------------------
-- Textual Convention
----------------------
ConditionIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The unique identifier of a condition and/or condition
notice within a table."
SYNTAX Unsigned32
ConditionLocation ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A text field describing the physical or logical location at
which a condition occurred.
The fields <node>,<Rack>,<shelf>,<slot>,<port> would be concatenated
into the physical location identifier with some delimiter."
SYNTAX SnmpAdminString
ConditionSeverity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The perceived severity level of a condition."
REFERENCE
"Recommendation X.733 (02/92) - Information Technology -
Open Systems Interconnection - Systems Management:
Alarm Reporting Function"
SYNTAX INTEGER {
cleared(1),
indeterminate(2),
warning(3),
minor(4),
major(5),
critical(6)
}
ConditionCategory ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The category of an abnormal condition."
REFERENCE
"Recommendation X.733 (02/92) - Information Technology -
Open Systems Interconnection - Systems Management:
Alarm Reporting Function"
SYNTAX INTEGER {
communications(1),
qualityOfService(2),
processingError(3),
equipment(4),
environmental(5)
}
ConditionType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The identity of the type of an abnormal condition or raised alarm"
SYNTAX IANAItuProbableCause
---------------------------
-- Active condition objects
---------------------------
condActiveMaxNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of active conditions the system will
store in condActiveTable. This value is set high
enough that it cannot be exceeded by the system (i.e., the
system is not capable of generating more than this number
of simultaneous standing conditions)."
::= { condActive 1 }
condActiveTable OBJECT-TYPE
SYNTAX SEQUENCE OF CondActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of active conditions on the system.
The table index is virtual and does not represent a physical location.
As each new condition is generated, it is assigned a new identifier;
old identifiers are not reused.
An entry in the table is removed when the condition it represents
is cleared. Note that this means the identifiers of the standing
conditions in the table cannot be assumed to be consecutive."
::= { condActive 2 }
condActiveEntry OBJECT-TYPE
SYNTAX CondActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row that contains information about an active condition."
INDEX { condActiveIndex }
::= { condActiveTable 1 }
CondActiveEntry ::=
SEQUENCE {
condActiveIndex ConditionIndex,
condActiveLocation ConditionLocation,
condActiveDateAndTime DateAndTime,
condActiveCategory ConditionCategory,
condActiveSeverity ConditionSeverity,
condActiveProbableCause ConditionType,
condActiveServiceAffecting TruthValue,
condActiveText SnmpAdminString
}
condActiveIndex OBJECT-TYPE
SYNTAX ConditionIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique identifier of the condition within this table."
::= { condActiveEntry 1 }
condActiveLocation OBJECT-TYPE
SYNTAX ConditionLocation
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The device generated identifier indicating the location of the equipment
that generated the condition (e.g. node.shelf.slot.port)."
::= { condActiveEntry 2 }
condActiveDateAndTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date and time when the condition was generated."
::= { condActiveEntry 3 }
condActiveCategory OBJECT-TYPE
SYNTAX ConditionCategory
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The category of the condition, as assigned by the device
that generated it."
::= { condActiveEntry 4 }
condActiveSeverity OBJECT-TYPE
SYNTAX ConditionSeverity
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The perceived severity level of the condition, as assigned
by the device that generated the condition."
::= { condActiveEntry 5 }
condActiveProbableCause OBJECT-TYPE
SYNTAX AlarmType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A high level qualification of the cause of the condition."
::= { condActiveEntry 6 }
condActiveServiceAffecting OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of whether or not the condition is service
affecting."
::= { condActiveEntry 7 }
condActiveText OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A text description of the condition."
::= { condActiveEntry 8 }
----------------------------
-- Retired condition objects
----------------------------
condRetiredMaxNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of retired standing conditions the system will store in
condRetiredTable. This table provides a history of conditions
that have been cleared."
::= { condRetired 1 }
condRetiredLastIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The index of the youngest entry in the retired condition log
table, or zero. The value of zero is used to indicate that no entry
exists in the retired condition log."
::= { condRetired 2 }
condRetiredTable OBJECT-TYPE
SYNTAX SEQUENCE OF CondRetiredEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of retired standing conditions on the system.
The table index is virtual and does not represent a physical location.
As each new condition is generated, it is assigned a new identifier;
old identifiers are not reused.
Once the condRetiredTable contains the maximum number of entries,
the oldest entry would be deleted to make room for new entry."
::= { condRetired 3 }
condRetiredEntry OBJECT-TYPE
SYNTAX CondRetiredEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row that contains information about an retired condition."
INDEX { condRetiredIndex }
::= { condRetiredTable 1 }
CondRetiredEntry ::=
SEQUENCE {
condRetiredIndex ConditionIndex,
condRetiredLocation ConditionLocation,
condRetiredDateAndTimeGenerated DateAndTime,
condRetiredDateAndTime DateAndTime,
condRetiredCategory ConditionCategory,
condRetiredSeverity ConditionSeverity,
condRetiredProbableCause ConditionType,
condRetiredServiceAffecting TruthValue,
condRetiredText SnmpAdminString,
condRetiredResolution SnmpAdminString
}
condRetiredIndex OBJECT-TYPE
SYNTAX ConditionIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique identifier of the retired condition within this table."
::= { condRetiredEntry 1 }
condRetiredLocation OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The device generated identifier indicating the location of the equipment
that generated the condition. It is the same as condActiveLocation."
::= { condRetiredEntry 2 }
condRetiredDateAndTimeGenerated OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date and time when the condition was generated. It is the same as
condActiveDateAndTime."
::= { condRetiredEntry 3 }
condRetiredDateAndTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date and time when the condition was retired."
::= { condRetiredEntry 4 }
condRetiredCategory OBJECT-TYPE
SYNTAX ConditionCategory
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The category of the condition, as assigned by the device
that generated it. It is the same as condActiveCategory."
::= { condRetiredEntry 5 }
condRetiredSeverity OBJECT-TYPE
SYNTAX ConditionSeverity
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The perceived severity level of the condition when it was active, as
assigned by the device that generated the condition.
It is the same as condActiveSeverity."
::= { condRetiredEntry 6 }
condRetiredProbableCause OBJECT-TYPE
SYNTAX ConditionProbableCause
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A high level qualification of the cause of the condition when it
was active. It is the same as condActiveProbableCause."
::= { condRetiredEntry 7 }
condRetiredServiceAffecting OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of whether or not the condition was service
affecting when it was active. It is the same as
condActiveServiceAffecting."
::= { condRetiredEntry 8 }
condRetiredText OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A text description of the condition. It is the same as condActiveText."
::= { condRetiredEntry 9 }
condRetiredResolution OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Free-form text containing resolution information."
::= { condRetiredEntry 10 }
---------------------------
-- Transient objects
---------------------------
condTransientMaxNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of transient conditions the system will
store in condTransientTable."
::= { condTransient 1 }
condTransientLastIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The index of the youngest entry in the transient condition log
table, or zero. The value of zero is used to indicate that no entry
exists in the transient condition log."
::= { condTransient 2 }
condTransientTable OBJECT-TYPE
SYNTAX SEQUENCE OF CondTransientEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of conditions on the system.
The table index is virtual and does not represent a physical location.
As each new condition is generated, it is assigned a new identifier;
old identifiers are not reused. Therefore, the identifiers of the transient
conditions in the table cannot be assumed to be consecutive.
When the table reaches the max number of entries, the oldest one is deleted
to make room for the new transient condition"
::= { condtransient 3 }
condTransientEntry OBJECT-TYPE
SYNTAX CondTransientEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row that contains information about an transient condition."
INDEX { condTransientIndex }
::= { condTransientTable 1 }
CondTransientEntry ::=
SEQUENCE {
condTransientIndex ConditionIndex,
condTransientLocation ConditionLocation,
condTransientDateAndTime DateAndTime,
condTransientCategory ConditionCategory,
condTransientSeverity ConditionSeverity,
condTransientProbableCause ConditionType,
condTransientServiceAffecting TruthValue,
condTransientText SnmpAdminString
}
condTransientIndex OBJECT-TYPE
SYNTAX ConditionIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique identifier of the condition within this table."
::= { condTransientEntry 1 }
condTransientLocation OBJECT-TYPE
SYNTAX ConditionLocation
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The device generated identifier indicating the location of the equipment
that generated the condition (e.g. node.shelf.slot.port)."
::= { condTransientEntry 2 }
condTransientDateAndTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date and time when the condition was generated."
::= { condTransientEntry 3 }
condTransientCategory OBJECT-TYPE
SYNTAX ConditionCategory
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The category of the condition, as assigned by the device
that generated it."
::= { condTransientEntry 4 }
condTransientSeverity OBJECT-TYPE
SYNTAX ConditionSeverity
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The perceived severity level of the condition, as assigned
by the device that generated the condition."
::= { condTransientEntry 5 }
condTransientProbableCause OBJECT-TYPE
SYNTAX ConditionProbableCause
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A high level qualification of the cause of the condition."
::= { condTransientEntry 6 }
condTransientServiceAffecting OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of whether or not the condition is service
affecting."
::= { condTransientEntry 7 }
condTransientText OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A text description of the condition."
::= { condTransientEntry 8 }
-----------------
-- Notifications
-----------------
condNotificationSelection OBJECT-TYPE
SYNTAX BITS {
cleared(0),
indeterminate(1),
warning(2),
minor(3),
major(4),
critical(5)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object controls the perceived condition severities for which
notifications are sent. If a bit is set, a notification is sent for each
new condition with the corresponding perceived severity.
By default, all bits are set except indeterminate(1)."
::= { condNotice 1 }
condActiveEvent NOTIFICATION-TYPE
OBJECTS {
condActiveIndex,
condActiveLocation,
condActiveDateAndTime,
condActiveCategory,
condActiveSeverity,
condActiveProbableCause,
condActiveServiceAffecting,
condActiveText
}
STATUS current
DESCRIPTION
" To notify an active condition, this notification is sent for every
condition
severity level that is enabled in condNotificationSelection.
The objects are the same as in the associated entry in the
condActiveTable."
::= { condEventsV2 1 }
condRetiredEvent NOTIFICATION-TYPE
OBJECTS {
condRetiredIndex,
condRetiredLocation,
condRetiredDateAndTimeGenerated,
condRetiredDateAndTime,
condRetiredCategory,
condRetiredSeverity,
condRetiredProbableCause,
condRetiredServiceAffecting,
condRetiredText,
condRetiredResolution
}
STATUS current
DESCRIPTION
" To notify that a condition is cleared, this notification is sent
for every condition severity level that is enabled in
condNotificationSelection.
The objects are the same as in the associated entry in the
condRetiredTable."
::= { condEventsV2 2 }
--------------------------
-- conformance information
--------------------------
condConformance OBJECT IDENTIFIER ::= { condMIB 3 }
condCompliances OBJECT IDENTIFIER ::= { condConformance 1 }
condCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for systems supporting
the Condition MIB."
MODULE -- this module
MANDATORY-GROUPS {
condActiveGroup,
condRetiredGroup
}
::= { condCompliances 1 }
condGroups OBJECT IDENTIFIER ::= { condConformance 2 }
condActiveGroup OBJECT-GROUP
OBJECTS {
condActiveMaxNumber,
condActiveIndex,
condActiveLocation,
condActiveDateAndTime,
condActiveCategory,
condActiveSeverity,
condActiveProbableCause,
condActiveServiceAffecting,
condActiveText
}
STATUS current
DESCRIPTION
"Condition Active group."
::= { condGroups 1}
condRetiredGroup OBJECT-GROUP
OBJECTS {
condRetiredMaxNumber,
condRetiredLastIndex,
condRetiredIndex,
condRetiredLocation,
condRetiredDateAndTimeGenerated,
condRetiredDateAndTime,
condRetiredCategory,
condRetiredSeverity,
condRetiredProbableCause,
condRetiredServiceAffecting,
condRetiredText,
condRetiredResolution
}
STATUS current
DESCRIPTION
"Condition Retired group."
::= { condGroups 2}
condTransientGroup OBJECT-GROUP
OBJECTS {
condTransientMaxNumber,
condTransientLastIndex,
condTransientIndex,
condTransientLocation,
condTransientDateAndTime,
condTransientCategory,
condTransientSeverity,
condTransientProbableCause,
condTransientServiceAffecting,
condTransientText
}
STATUS current
DESCRIPTION
" Condition Transient group."
::= { condGroups 3}
condNotificationSelectionGroup OBJECT-GROUP
OBJECTS {
condNotificationSelection
}
STATUS current
DESCRIPTION
"Notification Selection group."
::= { condGroups 4}
condNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { condActiveEvent, condRetiredEvent }
STATUS current
DESCRIPTION
"The collection of notifications."
::= { condGroups 5 }
END
7. ARC MIB Object Definition
ARC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32
FROM SNMPv2-SMI
ConditionType
FROM COND-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
arcMIB MODULE-IDENTITY
LAST-UPDATED "200111150000Z"
ORGANIZATION " "
CONTACT-INFO
"Kam Lam
Lucent Technologies
E-mail: hklam@lucent.com."
DESCRIPTION
"The MIB module describes the objects for controlling a resource
in reporting an condition that it detectes.
Alarm Report Control is a feature that provides an automatic
in-service provisioning capability. Alarm reporting is turned
off on a per-resource basis for a selective set of alarm types
(i.e., potential alarm conditions) to allow sufficient time for
customer testing and other maintenance activities in an "alarm
free" state. Once a resource is ready for service , alarm
reporting is automatically (or manually) turned on.
There are four ARC states:ALM, NALM, NALM-QI, or NALMTI
ALM may transition to NALM, NALM-QI, or NAML-TI by management request.
NALM may transition to ALM, NALM-QI, or NAML-TI by management request.
NALM-QI may transition to NALM or ALM by management request.
NALM-QI may transition to ALM automatically
if qualified problem-free (if NALM-QI-CD is not supported) or
if the CD timer expired (if NALM-QI-CD is supported)
NALM-TI may transition to ALM or NALM by management request.
NALM-TI may transition to ALM automatically if the TI timer expired.
Further details of ARC state transitions are defined in Figure 3
of M.3100 Amd3."
REVISION "200111150000Z"
DESCRIPTION
"The initial version."
::={ mib-2 yy}
------------------
-- MIB Objects
------------------
arcMIBTimeIntervals OBJECT IDENTIFIER ::= { arcMIB 1 }
arcMIBObjects OBJECT IDENTIFIER ::= { arcMIB 2 }
arcMIBTITimeInterval OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable indicates the time interval used for the nalmTI
state, in units of second. It is a pre-defined length of time
in which the resource will stay in the NALM-TI state before
transition into the ALM state. "
::= { arcMIBTimeIntervals 1 }
arcMIBCDTimeInterval OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable indicates the time interval used for the nalmQICD
state, in units of second. It is a pre-defined length of time
in which the resource will stay in the NALM-QI-CD state before
transition into the ALM state after it is problem-free."
::= { arcMIBTimeIntervals 2 }
arcTable OBJECT-TYPE
SYNTAX SEQUENCE OF ArcEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of arc settings on the system."
::= { arcMIBObjects 1 }
arcEntry OBJECT-TYPE
SYNTAX ArcEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row that contains information about the ARC setting
of a resource in the system."
INDEX { arcIndex, arcAlarmType }
::= { arcTable 1 }
ArcEntry ::=
SEQUENCE {
arcIndex OBJECT IDENTIFIER,
arcAlarmType ConditionType,
arcState INTEGER,
arcNalmTimeRemaining Unsigned32
}
arcIndex OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object uniquely identifies a resource, which is under the
arcState's control for the associated arcAlarmType."
::= { arcEntry 1 }
arcAlarmType OBJECT-TYPE
SYNTAX ConditionType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object identifies the alarm type controled by the arcState.
Only one alarm type is identified for each entry."
::= { arcEntry 2 }
arcState OBJECT-TYPE
SYNTAX INTEGER {
alm (1),
nalm (2),
nalmQI (3),
nalmTI (4),
nalmQICD (5)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The object controls the alarm report of a resource. A manager can
set the arcState to either alm, nalm, nalmQI, or nalmTI.
ALM: Alarm reporting is turned on (i.e., is allowed).
NALM: Alarm reporting is turned off.
NALM-TI: Alarm reporting is turned off for a time interval.
(TI - Time Inhibit).
NALM-QI: Alarm reporting is turned off for a selected set
of alarm types until the resource is qualified
problem-free for a specified persistence interval.
Problem-free means that none of the conditions
corresponding to the selected alarm types exist.
(QI - Qualified Inhibit).
NALM-QI-CD: This is a substate of NALM-QI and performs the
persistence timing count down function after the
resource is qualified problem-free.
(CD - Count Down).
According to the requirements in M.3100 Amendement3, a resource
supporting the ARC feature shall support the ALM state and at
least one of the NALM, NALM-TI, and NALM-QI states. NALM-QI-CD
is an optional substate of NALM-QI.
Once the resource enters the alm state for the specified alarm
type, the corresponding entry will be deleted from the arc table.
The manual setting of the arcState to alm has the effect of removing
the entry from the arc table.
The value of nalamQICD is a transitional state from nalmQI to alm.
It is optional depending on the type and the implementation of the
resource. If it is supported, before the state is transitioned
from nalmQI to alm, a count down period is activated for a duration
set by the object arcNalmCDTimeInterval. When the time is up,
the arcState is set to alm."
::= { arcEntry 3 }
arcNalmTimeRemaining OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable indicates the time remaining in the NALM-TI interval
or the NALM-QI-CD interval, in units of second.
At the moment the resource enters the NALM-TI state, this variable
will have the initial value equal to the value of
arcNalmTITimeInterval and then starts decrementing as time goes by.
Similarly at the moment the resource enters the NALM-QI-CD state,
this variable will have the initial value equal to the value of
arcNalmCDTimeInterval and then starts decrementing as time goes by.
This variable is read-write and thus will allow the manager to
extend or shorten the remaining time when the resource is in
the NALM-TI or NALM-QI-CD state as needed.
If this variable is supported and the resource is currently not in
the NALM-TI nor NAML-QI-CD state, the value of this variable shall
equal to zero."
::= { arcEntry 4 }
--------------------------
-- conformance information
--------------------------
arcConformance OBJECT IDENTIFIER ::= { arcMIB 3 }
arcCompliances OBJECT IDENTIFIER ::= { arcConformance 1 }
arcCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for systems supporting
the ARC MIB."
MODULE -- this module
MANDATORY-GROUPS {
arcSettingGroup
}
::= { arcCompliances 1 }
arcGroups OBJECT IDENTIFIER ::= { arcConformance 2 }
arcSettingGroup OBJECT-GROUP
OBJECTS {
arcIndex,
arcAlarmType
}
STATUS current
DESCRIPTION
"ARC Setting group."
::= { arcGroups 1}
arcTIGroup OBJECT-GROUP
OBJECTS {
arcMIBTITimeInterval,
arcNalmTimeRemaining
}
STATUS current
DESCRIPTION
"ARC Time Inhibit group."
::= { arcGroups 2}
arcQICDGroup OBJECT-GROUP
OBJECTS {
arcMIBCDTimeInterval,
arcNalmTimeRemaining
}
STATUS current
DESCRIPTION
"ARC Quality Inhibit (QI) Count Down (CD) group."
::= { arcGroups 3}
END
8. 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.
So, it is important to control the GET access to these objects and possibly
even encrypt the object values when sending them over the network via SNMP.
Not all versions of SNMP provide features for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), 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.
9. Acknowledgements
The authors wish to thank Brian Teer for reviewing and commenting
on this draft.
10. References
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing SNMP Management Frameworks", RFC 2571, April
1999.
[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
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.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets - MIB-II", STD 17,
RFC 1213, March 1991.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
[M.3100] ITU Recommendation M.3100, "Generic Network Information
Model", 1995
[X.733] ITU Recommendation X.733, "Information Technology - Open Systems
Interconnection - System Management: Alarm Reporting Function",
1992.
[X.736] ITU Recommendation X.736, "Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function", 1992
11. Author's Address
Name(s): An-ni Huynh
Company: Cetus Networks
Phone: 732-615-5402
EMail: a_n_huynh@yahoo.com
Name: Mark A. Stewart
Address: 1728 Bowling Green Trail
Raleigh, NC 27613
Phone: 919.247.6991
EMail: mstewart1@nc.rr.com
Name: David T. Perkins
Company: SNMPinfo
Address: 3763 Benton Street
Santa Clara, CA 95051
EMail: dperkins@dsperkins.com
Name(s): Kam Lam
Company: Lucent Technologies
Address: 101 Crawfords Corner Road, Room 4C-616A
Holmdel, NJ 07733
Phone: 732-949-8338
EMail: hklam@lucent.com
12. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Expires May 15 2002 [Page xx]
Datatracker
Report a datatracker bug
draft-ietf-disman-conditionmib-01
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3878.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |