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