Network Working Group R. Kavasseri Request for Comments: 2981 (Editor of this version) Category: Standards Track B. Stewart (Author of previous version) Cisco Systems, Inc. October 2000 Event MIB Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1 The SNMP Management Framework ............................... 2 2 Overview .................................................... 3 3 Relationship to Other MIBs .................................. 3 4 MIB Sections ................................................ 4 5 Operation ................................................... 5 6 Security .................................................... 7 7 Definitions ................................................. 7 8 Intellectual Property ....................................... 47 9 Acknowledgements ............................................ 47 Kavasseri & Stewart Standards Track [Page 1] RFC 2981 Event MIB October 2000 10 References ................................................. 47 11 Security Considerations .................................... 49 12 Author's Address ........................................... 49 13 Editor's Address ........................................... 49 14 Full Copyright Statement ................................... 50 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. Kavasseri & Stewart Standards Track [Page 2] RFC 2981 Event MIB October 2000 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 (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. It may not be possible to meaningfully monitor Counter64 objects using an SMIv1 version of the MIB. 2. Overview With network sizes well beyond the ability of people to manage them directly, automated, distributed management is vital. An important aspect of such management is the ability of a system to monitor itself or for some other system to monitor it. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. The MIB is intended to suit either a relatively powerful manager or mid- level manager, as well as a somewhat more limited self-managing system. 3. Relationship to Other MIBs The Event MIB is based on extensive experience with the RMON MIB [RFC1757] and provides a superset of the capabilities of the RMON alarm and event groups. Conceptually, the key extension is the ability to allow alarms to be generated for MIB objects that are on another network element. The Event MIB calls "triggers" what the RMON MIB called "alarms," but the concepts are the same. Event MIB triggers maintain the RMON handling of thresholds and add the concept of booleans. Event MIB events maintain the RMON concept of sending an SNMP notification in response to a trigger and add the concept of setting a MIB object. The Event MIB is the successor and update to SNMPv2's Manager-to- Manager MIB [RFC1451] which was declared Historic pending this work. The Event MIB depends on the services of the SNMPv3 Management Target and Notification MIBs [RFC2573]. The Event MIB is nicely complemented by the Distributed Management Expression MIB [RFC2982], which is the expected source of boolean objects to monitor. Note that there is considerable overlap between Kavasseri & Stewart Standards Track [Page 3] RFC 2981 Event MIB October 2000 the wildcard and delta sample capabilities of the Event and Expression MIBs. A carefully-planned implementation might well use common code to provide the overlapping functions. 4. MIB Sections The MIB has four sections: triggers, objects, events, and notifications. Triggers define the conditions that lead to events. Events may cause notifications. The trigger table lists what objects are to be monitored and how and relates each trigger to an event. It has supplementary, companion tables for additional objects that depend on the type of test done for the trigger. The objects table lists objects that can be added to notifications based on the trigger, the trigger test type, or the event that resulted in the notification. The event table defines what happens when an event is triggered: sending a notification, setting a MIB object or both. It has supplementary, companion tables for additional objects that depend on the action taken. The notification section defines a set of generic notifications to go with the events and for Event MIB error handling, and it defines a set of objects to put in those notifications. The following diagram describes the relationships between the tables in the Event MIB. Kavasseri & Stewart Standards Track [Page 4] RFC 2981 Event MIB October 2000 +-----------------------------+ | mteTriggerEntry | subclassed by: | { mteOwner, |---+ | IMPLIED mteTriggerName } | +-- mteTriggerDeltaEntry | | | | | +-- mteTriggerExistenceEntry | | | | | +-- mteTriggerBooleanEntry | | | | | +-- mteTriggerThresholdEntry | | | mteTrigger*Event -------------------------------->+ | | | | mteTriggerObjects ------------------>+ | +-----------------------------+ | | | | +-----------------------------+ V | | mteObjectsEntry | | | | { mteOwner, |<-------------+ | | mteObjectsName, | | | mteObjectsIndex } | | +-----------------------------+ | V +---------------------------+ | | mteEventEntry |<----------------------------+ | { mteOwner, | | IMPLIED mteEventName } | | | | mteEventAction---> + (condition) +---------------------------+ | V +---------------------------+ | +---------------------------+ | mteEventNotificationEntry | | | mteEventSetEntry | | { mteOwner, |<--+-->| { mteOwner, | | IMPLIED mteEventName } | | IMPLIED mteEventName } | +---------------------------+ +---------------------------+ 5. Operation The Event MIB is instrumentation for a distributed management application that monitors MIB objects. In its simplest form this application monitors individual, local MIB objects, just as an RMON probe fulfills the functions implied by RMON's alarm and event operation. Additionally the application can monitor remote objects and wildcarded groups of objects. Kavasseri & Stewart Standards Track [Page 5] RFC 2981 Event MIB October 2000 Remote monitoring uses the tag service of the Management Target MIB [RFC2573] to select and access remote systems as an ordinary SNMP- based management application. Local monitoring may be via a more intimate, local interface which may, for example, bypass SNMP encoding but otherwise is functionally identical to remote SNMP operation, including the application of access control. A self- management only system MAY not implement remote monitoring. Wildcards indicate that the application SHOULD use a GetNext-type operation to find the zero or more instances implied by a truncated object identifier, just like an ordinary SNMP-based management application. Each instance of a wildcard is treated as if it were a separate entry, that is the instances of a wildcarded object are independent of one another. For example, a wild-carded object may trigger an event, and result in the setting of another wildcarded object. The instance that satisfied the trigger function is used to perform the set function. All of this takes place independently of any additional instances that may fill the wildcard. Error handling is by notification. These error notifications SHOULD be enabled only for the diagnosis of problems indicated by error counters. If minimizing the probability of notification loss is a concern they SHOULD be transmitted as Inform PDUs as described in the [SNMP-TARGET-MIB] or directed to a log as described in the Notification Log MIB [rfcNotificationLogMIB]. Note that this does not mean the Notification Log MIB is REQUIRED, since in fact notifications usually are not lost, but that the Notification Log MIB can be helpful with this as well as other MIBs that include notifications. Although like most MIBs this one has no explicit controls for the persistence of the values set in configuring events, a robust, polite implementation would certainly not force its managing applications to reconfigure it whenever it resets. Again, as with most MIBs, it is implementation-specific how a system provides and manages such persistence. To speculate, one could imagine, for example, that persistence depended on the context in which the expression was configured, or perhaps system-specific characteristics of the expression's owner. Or perhaps everything in a MIB such as this one, which is clearly aimed at persistent configuration, is automatically part of a system's other persistent configuration. Kavasseri & Stewart Standards Track [Page 6] RFC 2981 Event MIB October 2000 6. Security Security of Event MIB entries depends on SNMPv3 access control for the entire MIB or for subsets based on entry owner names. Security of monitored objects for remote access depends on the Management Target MIB [RFC2573]. Security for local access can depend on the Management Target MIB or on recording appropriate security credentials of the creator of an entry and using those to access the local objects. These security credentials are the parameters necessary as inputs to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. When accessing local objects without using a local target tag, the system MUST (conceptually) use isAccessAllowed to ensure that it does not violate security. To facilitate the provisioning of access control by a security administrator for this MIB itself using the View-Based Access Control Model (VACM) defined in RFC 2275 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. If a security administrator were to employ such an approach, all entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same sub-identifiers (except for the "column" sub-identifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column sub-identifier. More elaborate configurations are possible. 7. Definitions DISMAN-EVENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, NOTIFICATION-TYPE, Counter32,