From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1451.txt | 2124 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2124 insertions(+) create mode 100644 doc/rfc/rfc1451.txt (limited to 'doc/rfc/rfc1451.txt') diff --git a/doc/rfc/rfc1451.txt b/doc/rfc/rfc1451.txt new file mode 100644 index 0000000..8159be1 --- /dev/null +++ b/doc/rfc/rfc1451.txt @@ -0,0 +1,2124 @@ + + + + Network Working Group J. Case + Request for Comments: 1451 SNMP Research, Inc. + K. McCloghrie + Hughes LAN Systems + M. Rose + Dover Beach Consulting, Inc. + S. Waldbusser + Carnegie Mellon University + April 1993 + + + Manager-to-Manager + Management Information Base + + + Status of this Memo + + This RFC specifes an IAB standards track protocol for the + Internet community, and requests discussion and suggestions + for improvements. Please refer to the current edition of the + "IAB Official Protocol Standards" for the standardization + state and status of this protocol. Distribution of this memo + is unlimited. + + + Table of Contents + + + 1 Introduction .......................................... 2 + 1.1 A Note on Terminology ............................... 2 + 2 Overview .............................................. 3 + 2.1 A SNMPv2 Entity Acting in a Dual Role ............... 3 + 2.2 Alarms, Events, and Notifications ................... 3 + 2.3 Access Control ...................................... 4 + 3 Definitions ........................................... 6 + 3.1 The Alarm Group ..................................... 7 + 3.1.1 Alarm-Related Notifications ....................... 20 + 3.2 The Event Group ..................................... 21 + 3.3 Conformance Information ............................. 29 + 3.3.1 Compliance Statements ............................. 29 + 3.3.2 Units of Conformance .............................. 29 + 4 Acknowledgements ...................................... 31 + 5 References ............................................ 35 + 6 Security Considerations ............................... 36 + 7 Authors' Addresses .................................... 36 + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 1] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + 1. Introduction + + A network management system contains: several (potentially + many) nodes, each with a processing entity, termed an agent, + which has access to management instrumentation; at least one + management station; and, a management protocol, used to convey + management information between the agents and management + stations. Operations of the protocol are carried out under an + administrative framework which defines both authentication and + authorization policies. + + Network management stations execute management applications + which monitor and control network elements. Network elements + are devices such as hosts, routers, terminal servers, etc., + which are monitored and controlled through access to their + management information. + + Management information is viewed as a collection of managed + objects, residing in a virtual information store, termed the + Management Information Base (MIB). Collections of related + objects are defined in MIB modules. These modules are written + using a subset of OSI's Abstract Syntax Notation One (ASN.1) + [1], termed the Structure of Management Information (SMI) [2]. + + The management protocol, version 2 of the Simple Network + Management Protocol [3], provides for the exchange of messages + which convey management information between the agents and the + management stations, including between management stations. + It is the purpose of this document to define managed objects + which describe the behavior of a SNMPv2 entity acting in both + a manager role and an agent role. + + + 1.1. A Note on Terminology + + For the purpose of exposition, the original Internet-standard + Network Management Framework, as described in RFCs 1155, 1157, + and 1212, is termed the SNMP version 1 framework (SNMPv1). + The current framework is termed the SNMP version 2 framework + (SNMPv2). + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 2] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + 2. Overview + + The purpose of this MIB is to provide the means for + coordination between multiple management stations. That is, + the means by which the controlling and monitoring functions of + network management can be distributed amongst multiple + management stations. Such distribution facilitates the + scaling of network management solutions based on the SNMPv2 to + meet the needs of very large networks, or of networks composed + of multiple interconnected administrations. Specifically, this + MIB provides the means for one management station to request + management services from another management station. + + + 2.1. A SNMPv2 Entity Acting in a Dual Role + + A management station providing services to other management + station(s), is a SNMPv2 entity which acts in the dual role of + both manager and agent; the requests for service are received + through acting in an agent role (with respect to the managed + objects defined in this MIB), and the requested services are + performed through acting in a manager role. + + + 2.2. Alarms, Events, and Notifications + + In this initial version, this MIB defines the concepts of + "alarms", "events", and "notifications". Each alarm is a + specific condition detected through the periodic (at a + configured sampling interval) monitoring of the value of a + specific management information variable. An example of an + alarm condition is when the monitored variable falls outside a + configured range. Each alarm condition triggers an event, and + each event can cause (one or more) notifications to be + reported to other management stations using the Inform-Request + PDU. + + Specifically, this MIB defines three MIB tables and a number + of scalar objects. The three tables are: the Alarm Table, the + Event Table, and the Notification Table. + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 3] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + 2.3. Access Control + + The Administrative Model for SNMPv2 document [4] includes an + access control model, which must not be subverted by allowing + access to management information variables via the Alarm + table. That is, access to a monitored variable via the Alarm + table must be controlled according to the identity of the + management station accessing the particular entry in the Alarm + table. + + An entry in the Alarm table provides the means to configure + the sampling of the value of a MIB variable in the MIB view + associated with the specified context (which can refer to + object resources that are either local or remote). The + sampling is done by (conceptually or actually) issuing a + SNMPv2 request to retrieve the variable's value. This request + is authenticated and/or protected from disclosure according to + a source party and a destination party pair which has access + to the indicated context. + + Thus, to provide the required access control, the initial MIB + view assigned, by convention, to parties on SNMPv2 entities + that implement the snmpAlarmTable, must include the component: + + viewSubtree = { snmpAlarm } + viewStatus = { excluded } + viewMask = { ''H } + + Then, the MIB view associated with the context, + requestContext, accessible by a requesting management station, + can be configured to include specific Alarm table entries -- + the ones associated with those contexts to which the + requesting management station has access. + + In particular, to provide a requestContext with access to the + sampling context sampleContext, the following family of view + subtrees would be included for the requestContext on the + SNMPv2 entity acting in a dual role: + + { snmpAlarmEntry WILDCARD sampleContext } + + Which would be configured in the party MIB [5] as: + + contextIdentity = { requestContext } + contextViewIndex = { ViewIndex } + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 4] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + viewIndex = { ViewIndex } + viewSubtree = { snmpAlarmEntry 0 sampleContext } + viewStatus = { included } + viewMask = { 'FFEF'H } -- specifies wildcard for column + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 5] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + 3. Definitions + + SNMPv2-M2M-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + Integer32, Counter32, snmpModules + FROM SNMPv2-SMI + DisplayString, InstancePointer, RowStatus, TimeStamp + FROM SNMPv2-TC + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF + contextIdentity + FROM SNMPv2-PARTY-MIB; + + + snmpM2M MODULE-IDENTITY + LAST-UPDATED "9304010000Z" + ORGANIZATION "IETF SNMPv2 Working Group" + CONTACT-INFO + " Steven Waldbusser + + Postal: Carnegie Mellon University + 4910 Forbes Ave + Pittsburgh, PA 15213 + + Tel: +1 412 268 6628 + Fax: +1 412 268 4987 + + E-mail: waldbusser@cmu.edu" + DESCRIPTION + "The Manager-to-Manager MIB module." + ::= { snmpModules 2 } + + + snmpM2MObjects OBJECT IDENTIFIER ::= { snmpM2M 1 } + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 6] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + -- the alarm group + -- + -- a collection of objects allowing the description and + -- configuration of threshold alarms from a SNMPv2 entity + -- acting in a dual role. + + snmpAlarm OBJECT IDENTIFIER ::= { snmpM2MObjects 1 } + + -- This Alarm mechanism periodically takes statistical samples + -- from variables available via SNMPv2 and compares them to + -- thresholds that have been configured. The alarm table + -- stores configuration entries that each define a variable, + -- polling period, and threshold parameters. If a sample is + -- found to cross the threshold values, an event is generated. + -- Only variables that resolve to an ASN.1 primitive type of + -- INTEGER (Integer32, Counter32, Gauge32, TimeTicks, + -- Counter64, or UInteger32) may be monitored in this way. + -- + -- This function has a hysteresis mechanism to limit the + -- generation of events. This mechanism generates one event + -- as a threshold is crossed in the appropriate direction. No + -- more events are generated for that threshold until the + -- opposite threshold is crossed. + -- + -- In the case of sampling a deltaValue, an entity may + -- implement this mechanism with more precision if it takes a + -- delta sample twice per period, each time comparing the sum + -- of the latest two samples to the threshold. This allows + -- the detection of threshold crossings that span the sampling + -- boundary. Note that this does not require any special + -- configuration of the threshold value. It is suggested that + -- entities implement this more precise algorithm. + -- + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 7] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmNextIndex OBJECT-TYPE + SYNTAX INTEGER (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The index number of the next appropriate + unassigned entry in the snmpAlarmTable. The value + 0 indicates that no unassigned entries are + available. + + A management station should create new entries in + the snmpAlarmTable using this algorithm: first, + issue a management protocol retrieval operation to + determine the value of snmpAlarmNextIndex; and, + second, issue a management protocol set operation + to create an instance of the snmpAlarmStatus + object setting its value to `createAndGo' or + `createAndWait' (as specified in the description + of the RowStatus textual convention)." + ::= { snmpAlarm 1 } + + snmpAlarmTable OBJECT-TYPE + SYNTAX SEQUENCE OF SnmpAlarmEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of snmpAlarm entries." + ::= { snmpAlarm 2 } + + snmpAlarmEntry OBJECT-TYPE + SYNTAX SnmpAlarmEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of parameters that set up a periodic + sampling query to check for alarm conditions. The + contextIdentity included in the INDEX clause is + the context to which the sampling queries are + directed." + INDEX { contextIdentity, snmpAlarmIndex } + ::= { snmpAlarmTable 1 } + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 8] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + SnmpAlarmEntry ::= SEQUENCE { + snmpAlarmIndex INTEGER, + snmpAlarmVariable InstancePointer, + snmpAlarmInterval Integer32, + snmpAlarmSampleType INTEGER, + snmpAlarmValue Integer32, + snmpAlarmStartupAlarm INTEGER, + snmpAlarmRisingThreshold Integer32, + snmpAlarmFallingThreshold Integer32, + snmpAlarmRisingEventIndex INTEGER, + snmpAlarmFallingEventIndex INTEGER, + snmpAlarmUnavailableEventIndex INTEGER, + snmpAlarmStatus RowStatus + } + + snmpAlarmIndex OBJECT-TYPE + SYNTAX INTEGER (1..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An index that uniquely identifies an entry in the + snmpAlarm table for a particular sampling context. + Each such entry defines a diagnostic sample at a + particular interval for a variable in the + particular context's object resources." + ::= { snmpAlarmEntry 1 } + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 9] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmVariable OBJECT-TYPE + SYNTAX InstancePointer + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The object identifier of the particular variable + to be sampled. Only variables that resolve to an + ASN.1 primitive type of INTEGER (Integer32, + Counter32, Gauge32, TimeTicks, Counter64, or + UInteger32) may be sampled. + + If it is detected by an error response of + authorizationError, noSuchObject, or + noSuchInstance that the variable name of an + established snmpAlarmEntry is no longer available + in the sampling context, a single + snmpObjectUnavailableAlarm event is generated and + the status of this snmpAlarmEntry is set to + `destroy'. Likewise, if the syntax of the + variable retrieved by the query is not Integer32, + Counter32, Gauge32, TimeTicks, Counter64, or + UInteger32, the same actions will be taken. + + If the SNMPv2 entity acting in a dual role detects + that the sampled value can not be obtained due to + lack of response to management queries, it should + either: + + 1) Set the status of this snmpAlarmEntry to + `destroy', if it is determined that further + communication is not possible; + + or, + + 2) Delete the associated snmpAlarmValue + instance (but not the entire conceptual row), + and continue to attempt to sample the + variable and recreate the associated + snmpAlarmValue instance should communication + be reestablished. + + An attempt to modify this object will fail with an + `inconsistentValue' error if the associated + snmpAlarmStatus object would be equal to `active' + both before and after the modification attempt." + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 10] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + ::= { snmpAlarmEntry 2 } + + snmpAlarmInterval OBJECT-TYPE + SYNTAX Integer32 + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The interval in seconds over which the data is + sampled and compared with the rising and falling + thresholds. When setting this object and the + sampling type is `deltaValue', care should be + taken to ensure that the change during this + interval of the variable being sampled will not + exceed the (-2^31...2^31-1) range of the + snmpAlarmValue. + + An attempt to modify this object will fail with an + `inconsistentValue' error if the associated + snmpAlarmStatus object would be equal to `active' + both before and after the modification attempt." + ::= { snmpAlarmEntry 3 } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 11] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmSampleType OBJECT-TYPE + SYNTAX INTEGER { + absoluteValue(1), + deltaValue(2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The method of sampling the selected variable and + calculating the value to be compared against the + thresholds. If the value of this object is + `absoluteValue', the value of the selected + variable at the end of the sampling interval will + be compared directly with both the + snmpAlarmRisingThreshold and the + snmpAlarmFallingThreshold values. If the value of + this object is `deltaValue', the value of the + selected variable at the end of the sampling + interval will be subtracted from its value at the + end of the previous sampling interval, and the + difference compared with both the + snmpAlarmRisingThreshold and the + snmpAlarmFallingThreshold values. + + An attempt to modify this object will fail with an + `inconsistentValue' error if the associated + snmpAlarmStatus object would be equal to `active' + both before and after the modification attempt." + DEFVAL { deltaValue } + ::= { snmpAlarmEntry 4 } + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 12] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmValue OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of the statistic during the last + sampling period. The value during the current + sampling period is not made available until the + period is completed. If the value of the + statistic does not fit in the signed 32 bit + representation of this object, it should be + truncated in an implementation specific manner. + + Note that if the associated snmpAlarmSampleType is + set to `deltaValue', the value of this object is + the difference in the sampled variable since the + last sample. + + This object will be created by the SNMPv2 entity + acting in a dual role when this entry is set to + `active', and the first sampling period has + completed. It may be created and deleted at other + times by the SNMPv2 entity acting in a dual role + when the sampled value can not be obtained, as + specified in the snmpAlarmVariable object." + ::= { snmpAlarmEntry 5 } + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 13] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmStartupAlarm OBJECT-TYPE + SYNTAX INTEGER { + risingAlarm(1), + fallingAlarm(2), + risingOrFallingAlarm(3) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The alarm that may be sent when this entry is + first set to `active'. If the first sample after + this entry becomes active is greater than or equal + to the risingThreshold and snmpAlarmStartupAlarm + is equal to `risingAlarm' or + `risingOrFallingAlarm', then a single rising alarm + will be generated. If the first sample after this + entry becomes active is less than or equal to the + fallingThreshold and snmpAlarmStartupAlarm is + equal to `fallingAlarm' or `risingOrFallingAlarm', + then a single falling alarm will be generated. + Note that a snmpObjectUnavailableAlarm is sent + upon startup whenever it is applicable, + independent of the setting of + snmpAlarmStartupAlarm. + + An attempt to modify this object will fail with an + `inconsistentValue' error if the associated + snmpAlarmStatus object would be equal to `active' + both before and after the modification attempt." + DEFVAL { risingOrFallingAlarm } + ::= { snmpAlarmEntry 6 } + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 14] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmRisingThreshold OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A threshold for the sampled statistic. When the + current sampled value is greater than or equal to + this threshold, and the value at the last sampling + interval was less than this threshold, a single + event will be generated. A single event will also + be generated if the first sample after this entry + becomes active is greater than or equal to this + threshold and the associated snmpAlarmStartupAlarm + is equal to `risingAlarm' or + `risingOrFallingAlarm'. + + After a rising event is generated, another such + event will not be generated until the sampled + value falls below this threshold and reaches the + snmpAlarmFallingThreshold. + + An attempt to modify this object will fail with an + `inconsistentValue' error if the associated + snmpAlarmStatus object would be equal to `active' + both before and after the modification attempt." + ::= { snmpAlarmEntry 7 } + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 15] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmFallingThreshold OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A threshold for the sampled statistic. When the + current sampled value is less than or equal to + this threshold, and the value at the last sampling + interval was greater than this threshold, a single + event will be generated. A single event will also + be generated if the first sample after this entry + becomes active is less than or equal to this + threshold and the associated snmpAlarmStartupAlarm + is equal to `fallingAlarm' or + `risingOrFallingAlarm'. + + After a falling event is generated, another such + event will not be generated until the sampled + value rises above this threshold and reaches the + snmpAlarmRisingThreshold. + + An attempt to modify this object will fail with an + `inconsistentValue' error if the associated + snmpAlarmStatus object would be equal to `active' + both before and after the modification attempt." + ::= { snmpAlarmEntry 8 } + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 16] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmRisingEventIndex OBJECT-TYPE + SYNTAX INTEGER (0..65535) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The index of the snmpEventEntry that is used when + a rising threshold is crossed. The snmpEventEntry + identified by a particular value of this index is + the same as identified by the same value of the + snmpEventIndex object. If there is no + corresponding entry in the snmpEventTable, then no + association exists. In particular, if this value + is zero, no associated event will be generated, as + zero is not a valid snmpEventIndex. + + An attempt to modify this object will fail with an + `inconsistentValue' error if the associated + snmpAlarmStatus object would be equal to `active' + both before and after the modification attempt." + ::= { snmpAlarmEntry 9 } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 17] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmFallingEventIndex OBJECT-TYPE + SYNTAX INTEGER (0..65535) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The index of the snmpEventEntry that is used when + a falling threshold is crossed. The + snmpEventEntry identified by a particular value of + this index is the same as identified by the same + value of the snmpEventIndex object. If there is + no corresponding entry in the snmpEventTable, then + no association exists. In particular, if this + value is zero, no associated event will be + generated, as zero is not a valid snmpEventIndex. + + An attempt to modify this object will fail with an + `inconsistentValue' error if the associated + snmpAlarmStatus object would be equal to `active' + both before and after the modification attempt." + ::= { snmpAlarmEntry 10 } + + snmpAlarmUnavailableEventIndex OBJECT-TYPE + SYNTAX INTEGER (0..65535) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The index of the snmpEventEntry that is used when + a variable becomes unavailable. The + snmpEventEntry identified by a particular value of + this index is the same as identified by the same + value of the snmpEventIndex object. If there is + no corresponding entry in the snmpEventTable, then + no association exists. In particular, if this + value is zero, no associated event will be + generated, as zero is not a valid snmpEventIndex. + + An attempt to modify this object will fail with an + `inconsistentValue' error if the associated + snmpAlarmStatus object would be equal to `active' + both before and after the modification attempt." + ::= { snmpAlarmEntry 11 } + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 18] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpAlarmStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of this snmpAlarm entry. This object + may not be set to `active' unless the following + columnar objects exist in this row: + snmpAlarmVariable, snmpAlarmInterval, + snmpAlarmSampleType, snmpAlarmStartupAlarm, + snmpAlarmRisingThreshold, + snmpAlarmFallingThreshold, + snmpAlarmRisingEventIndex, + snmpAlarmFallingEventIndex, and + snmpAlarmUnavailableEventIndex." + ::= { snmpAlarmEntry 12 } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 19] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + -- alarm-related notifications + + snmpAlarmNotifications + OBJECT IDENTIFIER ::= { snmpAlarm 3 } + + snmpRisingAlarm NOTIFICATION-TYPE + OBJECTS { snmpAlarmVariable, snmpAlarmSampleType, + snmpAlarmValue, snmpAlarmRisingThreshold } + STATUS current + DESCRIPTION + "An event that is generated when an alarm entry + crosses its rising threshold. The instances of + those objects contained within the varbind list + are those of the alarm entry which generated this + event." + ::= { snmpAlarmNotifications 1 } + + snmpFallingAlarm NOTIFICATION-TYPE + OBJECTS { snmpAlarmVariable, snmpAlarmSampleType, + snmpAlarmValue, snmpAlarmFallingThreshold } + STATUS current + DESCRIPTION + "An event that is generated when an alarm entry + crosses its falling threshold. The instances of + those objects contained within the varbind list + are those of the alarm entry which generated this + event." + ::= { snmpAlarmNotifications 2 } + + snmpObjectUnavailableAlarm NOTIFICATION-TYPE + OBJECTS { snmpAlarmVariable } + STATUS current + DESCRIPTION + "An event that is generated when a variable + monitored by an alarm entry becomes unavailable. + The instance of snmpAlarmVariable contained within + the varbind list is the one associated with the + alarm entry which generated this event." + ::= { snmpAlarmNotifications 3 } + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 20] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + -- the event group + -- + -- a collection of objects allowing the description and + -- configuration of events from a SNMPv2 entity acting + -- in a dual role. + + snmpEvent OBJECT IDENTIFIER ::= { snmpM2MObjects 2 } + + -- The snmpEvent table defines the set of events generated on + -- a SNMPv2 entity acting in a dual role. Each entry in the + -- snmpEventTable associates an event type with the + -- notification method and associated parameters. Some + -- snmpEvent entries are fired by an associated condition in + -- the snmpAlarmTable. Others are fired on behalf of + -- conditions defined in the NOTIFICATION-TYPE macro. The + -- snmpNotificationTable defines notifications that should + -- occur when an associated event is fired. + + snmpEventNextIndex OBJECT-TYPE + SYNTAX INTEGER (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The index number of the next appropriate + unassigned entry in the snmpEventTable. The value + 0 indicates that no unassigned entries are + available. + + A management station should create new entries in + the snmpEventTable using this algorithm: first, + issue a management protocol retrieval operation to + determine the value of snmpEventNextIndex; and, + second, issue a management protocol set operation + to create an instance of the snmpEventStatus + object setting its value to `createAndWait' or + 'createAndGo'." + ::= { snmpEvent 1 } + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 21] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpEventTable OBJECT-TYPE + SYNTAX SEQUENCE OF SnmpEventEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of events." + ::= { snmpEvent 2 } + + snmpEventEntry OBJECT-TYPE + SYNTAX SnmpEventEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A set of parameters that describe an event that + is generated when certain conditions are met." + INDEX { snmpEventIndex } + ::= { snmpEventTable 1 } + + SnmpEventEntry ::= SEQUENCE { + snmpEventIndex INTEGER, + snmpEventID OBJECT IDENTIFIER, + snmpEventDescription DisplayString, + snmpEventEvents Counter32, + snmpEventLastTimeSent TimeStamp, + snmpEventStatus RowStatus + } + + snmpEventIndex OBJECT-TYPE + SYNTAX INTEGER (1..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An index that uniquely identifies an entry in the + snmpEvent table. Each such entry defines an event + generated when the appropriate conditions occur." + ::= { snmpEventEntry 1 } + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 22] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpEventID OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The authoritative identification of the event + type generated by this entry. This variable + occurs as the second varbind of an InformRequest- + PDU. If this OBJECT IDENTIFIER maps to a + NOTIFICATION-TYPE the sender will place the + objects listed in the NOTIFICATION-TYPE in the + varbind list." + ::= { snmpEventEntry 2 } + + snmpEventDescription OBJECT-TYPE + SYNTAX DisplayString (SIZE (0..127)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A comment describing this snmpEvent entry." + ::= { snmpEventEntry 3 } + + snmpEventEvents OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of events caused by event generators + associated with this snmpEvent entry." + ::= { snmpEventEntry 4 } + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 23] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpEventLastTimeSent OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time this snmpEvent + entry last generated an event. If this entry has + not generated any events, this value will be + zero." + DEFVAL { 0 } + ::= { snmpEventEntry 5 } + + snmpEventStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of this snmpEvent entry. This object + may not be set to `active' unless the following + columnar objects exist in this row: snmpEventID, + snmpEventDescription, snmpEventEvents, and + snmpEventLastTimeSent. + + Setting an instance of this object to the value + 'destroy' has the effect of invalidating any/all + entries in the snmpEventTable, and the + snmpEventNotifyTable which reference the + corresponding snmpEventEntry." + ::= { snmpEventEntry 6 } + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 24] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpEventNotifyMinInterval OBJECT-TYPE + SYNTAX Integer32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum interval that the SNMPv2 entity + acting in a dual role will wait before + retransmitting an InformRequest-PDU. This object + specifies the minimal value supported by the + SNMPv2 entity acting in a dual role, based on + resource or implementation constraints. + + For a particular entry in the + snmpEventNotifyTable, if the associated + snmpEventNotifyIntervalRequested variable is + greater than this object, the + snmpEventNotifyIntervalRequested value shall be + used as the minimum interval for retransmissions + of InformRequest-PDUs sent on behalf of that + entry." + ::= { snmpEvent 3 } + + snmpEventNotifyMaxRetransmissions OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of time that the SNMPv2 entity + acting in a dual role will retransmit an + InformRequest-PDU. This object specifies the + maximal value supported by the SNMPv2 entity + acting in a dual role, based on resource or + implementation constraints. + + For a particular entry in the + snmpEventNotifyTable, if the associated + snmpEventNotifyRetransmissionsRequested variable + is less than this object, the + snmpEventNotifyRetransmissionsRequested value + shall be used as the retransmission count for + InformRequest-PDUs sent on behalf of that entry." + ::= { snmpEvent 4 } + + -- The snmpEventNotifyTable is used to configure the + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 25] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + -- destination and type of notifications sent by a SNMPv2 + -- entity acting in a manager role when a particular event + -- is triggered. + + snmpEventNotifyTable OBJECT-TYPE + SYNTAX SEQUENCE OF SnmpEventNotifyEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of protocol configuration entries for + event notifications from this entity." + ::= { snmpEvent 5 } + + snmpEventNotifyEntry OBJECT-TYPE + SYNTAX SnmpEventNotifyEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A set of parameters that describe the type and + destination of InformRequest-PDUs sent for a + particular event. The snmpEventIndex in this + entry's INDEX clause identifies the snmpEventEntry + which, when triggered, will generate a + notification as configured in this entry. The + contextIdentity in this entry's INDEX clause + identifies the context to which a notification + will be sent." + INDEX { snmpEventIndex, contextIdentity } + ::= { snmpEventNotifyTable 1 } + + SnmpEventNotifyEntry ::= SEQUENCE { + snmpEventNotifyIntervalRequested Integer32, + snmpEventNotifyRetransmissionsRequested Integer32, + snmpEventNotifyLifetime Integer32, + snmpEventNotifyStatus RowStatus + } + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 26] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpEventNotifyIntervalRequested OBJECT-TYPE + SYNTAX Integer32 + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The requested interval for retransmission of + Inform PDUs generated on the behalf of this entry. + + This variable will be the actual interval used + unless the snmpEventNotifyMinInterval is greater + than this object, in which case the interval shall + be equal to snmpEventNotifyMinInterval." + DEFVAL { 30 } + ::= { snmpEventNotifyEntry 1 } + + snmpEventNotifyRetransmissionsRequested OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The requested number of retransmissions of an + InformRequest-PDU generated on behalf of this + entry. + + This variable will be the actual number of + retransmissions used unless the + snmpEventNotifyMaxRetransmissions is less than + this object, in which case the retransmission + count shall be equal to + snmpEventNotifyMaxRetransmissions." + DEFVAL { 5 } + ::= { snmpEventNotifyEntry 2 } + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 27] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpEventNotifyLifetime OBJECT-TYPE + SYNTAX Integer32 + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The number of seconds this entry shall live until + the corresponding instance of + snmpEventNotifyStatus is set to 'destroy'. This + value shall count down to zero, at which time the + corresponding instance of snmpEventNotifyStatus + will be set to 'destroy'. Any management station + that is using this entry must periodically refresh + this value to ensure the continued delivery of + events." + DEFVAL { 86400 } + ::= { snmpEventNotifyEntry 3 } + + snmpEventNotifyStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The state of this snmpEventNotifyEntry. This + object may not be set to `active' unless the + following columnar objects exist in this row: + snmpEventNotifyIntervalRequested, + snmpEventNotifyRetransmissionsRequested, and + snmpEventNotifyLifetime." + ::= { snmpEventNotifyEntry 4 } + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 28] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + -- conformance information + + snmpM2MConformance + OBJECT IDENTIFIER ::= { snmpM2M 2 } + + snmpM2MCompliances + OBJECT IDENTIFIER ::= { snmpM2MConformance 1 } + snmpM2MGroups OBJECT IDENTIFIER ::= { snmpM2MConformance 2 } + + + -- compliance statements + + snmpM2MCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMPv2 entities + which implement the Manager-to-Manager MIB." + MODULE -- this module + MANDATORY-GROUPS { snmpAlarmGroup, snmpEventGroup } + ::= { snmpM2MCompliances 1 } + + + -- units of conformance + + snmpAlarmGroup OBJECT-GROUP + OBJECTS { snmpAlarmNextIndex, + snmpAlarmVariable, snmpAlarmInterval, + snmpAlarmSampleType, snmpAlarmValue, + snmpAlarmStartupAlarm, snmpAlarmRisingThreshold, + snmpAlarmFallingThreshold, + snmpAlarmRisingEventIndex, + snmpAlarmFallingEventIndex, + snmpAlarmUnavailableEventIndex, + snmpAlarmStatus } + STATUS current + DESCRIPTION + "A collection of objects allowing the description + and configuration of threshold alarms from a + SNMPv2 entity acting in a dual role." + ::= { snmpM2MGroups 1 } + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 29] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + snmpEventGroup OBJECT-GROUP + OBJECTS { snmpEventNextIndex, + snmpEventID, snmpEventDescription, + snmpEventEvents, snmpEventLastTimeSent, + snmpEventStatus, snmpEventNotifyMinInterval, + snmpEventNotifyMaxRetransmissions, + snmpEventNotifyIntervalRequested, + snmpEventNotifyRetransmissionsRequested, + snmpEventNotifyLifetime, snmpEventNotifyStatus } + STATUS current + DESCRIPTION + "A collection of objects allowing the description + and configuration of events from a SNMPv2 entity + acting in a dual role." + ::= { snmpM2MGroups 2 } + + + END + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 30] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + 4. Acknowledgements + + The comments of the SNMP version 2 working group are + gratefully acknowledged: + + Beth Adams, Network Management Forum + Steve Alexander, INTERACTIVE Systems Corporation + David Arneson, Cabletron Systems + Toshiya Asaba + Fred Baker, ACC + Jim Barnes, Xylogics, Inc. + Brian Bataille + Andy Bierman, SynOptics Communications, Inc. + Uri Blumenthal, IBM Corporation + Fred Bohle, Interlink + Jack Brown + Theodore Brunner, Bellcore + Stephen F. Bush, GE Information Services + Jeffrey D. Case, University of Tennessee, Knoxville + John Chang, IBM Corporation + Szusin Chen, Sun Microsystems + Robert Ching + Chris Chiotasso, Ungermann-Bass + Bobby A. Clay, NASA/Boeing + John Cooke, Chipcom + Tracy Cox, Bellcore + Juan Cruz, Datability, Inc. + David Cullerot, Cabletron Systems + Cathy Cunningham, Microcom + James R. (Chuck) Davin, Bellcore + Michael Davis, Clearpoint + Mike Davison, FiberCom + Cynthia DellaTorre, MITRE + Taso N. Devetzis, Bellcore + Manual Diaz, DAVID Systems, Inc. + Jon Dreyer, Sun Microsystems + David Engel, Optical Data Systems + Mike Erlinger, Lexcel + Roger Fajman, NIH + Daniel Fauvarque, Sun Microsystems + Karen Frisa, CMU + Shari Galitzer, MITRE + Shawn Gallagher, Digital Equipment Corporation + Richard Graveman, Bellcore + Maria Greene, Xyplex, Inc. + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 31] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + Michel Guittet, Apple + Robert Gutierrez, NASA + Bill Hagerty, Cabletron Systems + Gary W. Haney, Martin Marietta Energy Systems + Patrick Hanil, Nokia Telecommunications + Matt Hecht, SNMP Research, Inc. + Edward A. Heiner, Jr., Synernetics Inc. + Susan E. Hicks, Martin Marietta Energy Systems + Geral Holzhauer, Apple + John Hopprich, DAVID Systems, Inc. + Jeff Hughes, Hewlett-Packard + Robin Iddon, Axon Networks, Inc. + David Itusak + Kevin M. Jackson, Concord Communications, Inc. + Ole J. Jacobsen, Interop Company + Ronald Jacoby, Silicon Graphics, Inc. + Satish Joshi, SynOptics Communications, Inc. + Frank Kastenholz, FTP Software + Mark Kepke, Hewlett-Packard + Ken Key, SNMP Research, Inc. + Zbiginew Kielczewski, Eicon + Jongyeoi Kim + Andrew Knutsen, The Santa Cruz Operation + Michael L. Kornegay, VisiSoft + Deirdre C. Kostik, Bellcore + Cheryl Krupczak, Georgia Tech + Mark S. Lewis, Telebit + David Lin + David Lindemulder, AT&T/NCR + Ben Lisowski, Sprint + David Liu, Bell-Northern Research + John Lunny, The Wollongong Group + Robert C. Lushbaugh Martin, Marietta Energy Systems + Michael Luufer, BBN + Carl Madison, Star-Tek, Inc. + Keith McCloghrie, Hughes LAN Systems + Evan McGinnis, 3Com Corporation + Bill McKenzie, IBM Corporation + Donna McMaster, SynOptics Communications, Inc. + John Medicke, IBM Corporation + Doug Miller, Telebit + Dave Minnich, FiberCom + Mohammad Mirhakkak, MITRE + Rohit Mital, Protools + George Mouradian, AT&T Bell Labs + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 32] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + Patrick Mullaney, Cabletron Systems + Dan Myers, 3Com Corporation + Rina Nathaniel, Rad Network Devices Ltd. + Hien V. Nguyen, Sprint + Mo Nikain + Tom Nisbet + William B. Norton, MERIT + Steve Onishi, Wellfleet Communications, Inc. + David T. Perkins, SynOptics Communications, Inc. + Carl Powell, BBN + Ilan Raab, SynOptics Communications, Inc. + Richard Ramons, AT&T + Venkat D. Rangan, Metric Network Systems, Inc. + Louise Reingold, Sprint + Sam Roberts, Farallon Computing, Inc. + Kary Robertson, Concord Communications, Inc. + Dan Romascanu, Lannet Data Communications Ltd. + Marshall T. Rose, Dover Beach Consulting, Inc. + Shawn A. Routhier, Epilogue Technology Corporation + Chris Rozman + Asaf Rubissa, Fibronics + Jon Saperia, Digital Equipment Corporation + Michael Sapich + Mike Scanlon, Interlan + Sam Schaen, MITRE + John Seligson, Ultra Network Technologies + Paul A. Serice, Corporation for Open Systems + Chris Shaw, Banyan Systems + Timon Sloane + Robert Snyder, Cisco Systems + Joo Young Song + Roy Spitier, Sprint + Einar Stefferud, Network Management Associates + John Stephens, Cayman Systems, Inc. + Robert L. Stewart, Xyplex, Inc. (chair) + Kaj Tesink, Bellcore + Dean Throop, Data General + Ahmet Tuncay, France Telecom-CNET + Maurice Turcotte, Racal Datacom + Warren Vik, INTERACTIVE Systems Corporation + Yannis Viniotis + Steven L. Waldbusser, Carnegie Mellon Universitty + Timothy M. Walden, ACC + Alice Wang, Sun Microsystems + James Watt, Newbridge + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 33] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + Luanne Waul, Timeplex + Donald E. Westlake III, Digital Equipment Corporation + Gerry White + Bert Wijnen, IBM Corporation + Peter Wilson, 3Com Corporation + Steven Wong, Digital Equipment Corporation + Randy Worzella, IBM Corporation + Daniel Woycke, MITRE + Honda Wu + Jeff Yarnell, Protools + Chris Young, Cabletron + Kiho Yum, 3Com Corporation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 34] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + 5. References + + [1] Information processing systems - Open Systems + Interconnection - Specification of Abstract Syntax + Notation One (ASN.1), International Organization for + Standardization. International Standard 8824, (December, + 1987). + + [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., + "Structure of Management Information for version 2 of the + Simple Network Management Protocol (SNMPv2)", RFC 1442, + SNMP Research, Inc., Hughes LAN Systems, Dover Beach + Consulting, Inc., Carnegie Mellon University, April 1993. + + [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., + "Protocol Operations for version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1448, SNMP Research, + Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., + Carnegie Mellon University, April 1993. + + [4] Galvin, J., and McCloghrie, K., "Administrative Model for + version 2 of the Simple Network Management Protocol + (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes + LAN Systems, April 1993. + + [5] McCloghrie, K., and Galvin, J., "Party MIB for version 2 + of the Simple Network Management Protocol (SNMPv2)", RFC + 1447, Hughes LAN Systems, Trusted Information Systems, + April 1993. + + + + + + + + + + + + + + + + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 35] + + + + + + RFC 1451 Manager-to-Manager MIB April 1993 + + + 6. Security Considerations + + Security issues are not discussed in this memo. + + + 7. Authors' Addresses + + Jeffrey D. Case + SNMP Research, Inc. + 3001 Kimberlin Heights Rd. + Knoxville, TN 37920-9716 + US + + Phone: +1 615 573 1434 + Email: case@snmp.com + + + Keith McCloghrie + Hughes LAN Systems + 1225 Charleston Road + Mountain View, CA 94043 + US + + Phone: +1 415 966 7934 + Email: kzm@hls.com + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Mountain View, CA 94043-2186 + US + + Phone: +1 415 968 1052 + Email: mrose@dbc.mtview.ca.us + + Steven Waldbusser + Carnegie Mellon University + 4910 Forbes Ave + Pittsburgh, PA 15213 + US + + Phone: +1 412 268 6628 + Email: waldbusser@cmu.edu + + + + + + + Case, McCloghrie, Rose & Waldbusser [Page 36] + -- cgit v1.2.3