rfc2981.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,738 行 · 第 1/5 页
TXT
1,738 行
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?