rfc2981.txt

<VC++网络游戏建摸与实现>源代码

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