rfc2982.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       R. Kavasseri
Request for Comments: 2982                      (Editor of this version)
Category: Standards Track                                     B. Stewart
                                            (Author of previous version)
                                                     Cisco Systems, Inc.
                                                            October 2000


                 Distributed Management Expression 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 used for managing
   expressions of MIB objects.  The results of these expressions become
   MIB objects usable like any other MIB object, such as for the test
   condition for declaring an event.

   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
   2.1 Usage .....................................................    4
   2.2 Persistence ...............................................    4
   2.3 Operation .................................................    4
   2.3.1 Sampling ................................................    5
   2.3.2 Wildcards ...............................................    5
   2.3.3 Evaluation ..............................................    5
   2.3.4 Value Identification ....................................    6
   2.4 Subsets ...................................................    6
   2.4.1 No Wildcards ............................................    6



Kavasseri & Stewart         Standards Track                     [Page 1]

RFC 2982         Distributed Management Expression MIB      October 2000


   2.4.2 No Deltas ...............................................    7
   2.5 Structure .................................................    7
   2.5.1 Resource ................................................    7
   2.5.2 Definition ..............................................    7
   2.5.3 Value ...................................................    8
   2.6 Examples ..................................................    8
   2.6.1 Wildcarding .............................................    8
   2.6.2 Calculation and Conditional .............................   10
   3 Definitions .................................................   12
   4 Intellectual Property .......................................   36
   5 Acknowledgements ............................................   37
   6 References ..................................................   37
   7 Security Considerations .....................................   38
   8 Author's Address ............................................   40
   9 Editor's Address ............................................   40
   10 Full Copyright Statement ...................................   41

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





Kavasseri & Stewart         Standards Track                     [Page 2]

RFC 2982         Distributed Management Expression MIB      October 2000


    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 (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.

2.  Overview

   Users of MIBs often desire MIB objects that MIB designers have not
   provided.  Furthermore, such needs vary from one management
   philosophy to another.  Rather than fill more and more MIBs with
   standardized objects, the Expression MIB supports externally defined
   expressions of existing MIB objects.

   In the Expression MIB the results of an evaluated expression are MIB
   objects that may be used like any other MIB objects.  These custom-
   defined objects are thus usable anywhere any other MIB object can be
   used.  For example, they can be used by a management application
   directly or referenced from another MIB, such as the Event MIB
   [MIBEventMIB].  They can even be used by the Expression MIB itself,
   forming expressions of expressions.

   The Expression MIB is instrumentation for a relatively powerful,
   complex, high-level application, considerably different from simple
   instrumentation for a communication driver or a protocol.  The MIB is
   appropriate in a relatively powerful, resource-rich managed system
   and not necessarily in a severely limited environment.

   Nevertheless, due to dependencies from the Event MIB [RFC2981] and
   the need to support as low-end a system as possible, the Expression
   MIB can be somewhat stripped down for lower-power, lower-resource
   implementations, as described in the Subsets section, below.




Kavasseri & Stewart         Standards Track                     [Page 3]

RFC 2982         Distributed Management Expression MIB      October 2000


   Implementation of the Expression MIB in a managed system led to the
   addition of objects that may not have been necessary in an
   application environment with complete knowledge of compiled MIB
   definitions.  This is appropriate since implementation must be
   possible within typical managed systems with some constraints on
   system resources.

2.1.  Usage

   On managed systems that can afford the overhead, the Expression MIB
   is a way to create new, customized MIB objects for monitoring.
   Although these can save some network traffic and overhead on
   management systems, that is often not a good tradeoff for objects
   that are simply to be recorded or displayed.

   An example of a use of the Expression MIB would be to provide custom
   objects for the Event MIB [RFC2981].  A complex expression can
   evaluate to a rate of flow or a boolean and thus be subject to
   testing as an event trigger, resulting in an SNMP notification.
   Without these capabilities such monitoring would be limited to the
   objects in predefined MIBs.  The Expression MIB thus supports
   powerful tools for the network manager faced with the monitoring of
   large, complex systems that can support a significant level of self
   management.

2.2.  Persistence

   Although like most MIBs this one has no explicit controls for the
   persistence of the values set in configuring an expression, 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.

2.3.  Operation

   Most of the operation of the MIB is described or implied in the
   object definitions but a few highlights bear mentioning here.






Kavasseri & Stewart         Standards Track                     [Page 4]

RFC 2982         Distributed Management Expression MIB      October 2000


2.3.1.  Sampling

   The MIB supports three types of object sampling for the MIB objects
   that make up the expression:  absolute, delta, and changed.

   Absolute samples are simply the value of the MIB object at the time
   it is sampled.

   Absolute samples are not sufficient for expressions of counters, as
   counters have meaning only as a delta (difference) from one sample to
   the next.  Thus objects may be sampled as deltas.  Delta sampling
   requires the application to maintain state for the value at the last
   sample, and to do continuous sampling whether or not anyone is
   looking at the results.  It thus creates constant overhead.

   Changed sampling is a simple fallout of delta sampling where rather
   than a difference the result is a boolean indicating whether or not
   the object changed value since the last sample.

2.3.2.  Wildcards

   Wildcards allow the application of a single expression to multiple
   instances of the same MIB object.  The definer of the expression
   indicates this choice and provides a partial object identifier, with
   some or all of the instance portion left off.  The application then
   does the equivalent of GetNext to obtain the object values, thus
   discovering the instances.

   All wildcarded objects in an expression must have the same semantics
   for the missing portion of their object identifiers.  Otherwise, any
   successful evaluation of the wildcarded expression would be the
   result of the accidental matching of the wildcarded portion of the
   object identifiers in the expression.  Such an evaluation will likely
   produce results which are not meaningful.

   The expression can be evaluated only for those instances where all
   the objects in the expression are available with the same value for
   the wildcarded portion of the instance.

2.3.3.  Evaluation

   There are two important aspects of evaluation that may not be
   obvious:  what objects and when.

   What objects get used in the evaluation depends on the type of
   request and whether or not the expression contains wildcarded
   objects.  If the request was a Get, that locks down the instances to




Kavasseri & Stewart         Standards Track                     [Page 5]

RFC 2982         Distributed Management Expression MIB      October 2000


   be used.  If the request was a GetNext or GetBulk, the application
   must work its way up to the next full set of objects for the
   expression.

   Evaluation of expressions happens at two possible times, depending on
   the sampling method (delta or absolute) used to evaluate the
   expression.

   If there are no delta or change values in an expression, the
   evaluation occurs on demand, i.e. when a requester attempts to read
   the value of the expression.  In this case all requesters get a
   freshly calculated value.

   For expressions with delta or change values, evaluation goes on
   continuously, every sample period.  In this case requesters get the
   value as of the last sample period.  For any given sample period of a
   given expression, only those instances exist that provided a full set
   of object values.  It may be possible that a delta expression which
   was evaluated successfully for one sample period may not be
   successfully evaluated in the next sample period.  This may, for
   example, be due to missing instances for some or all of the objects
   in the expression.  In such cases, the value from the previous sample
   period (with the successful evaluation) must not be carried forward
   to the next sample period (with the failed evaluation).

2.3.4.  Value Identification

   Values resulting from expression evaluation are identified with a
   combination of the object identifier (OID) for the data type from
   expValueTable (such as expValueCounter32Val), the expression owner,
   the expression name, and an OID fragment.

   The OID fragment is not an entire OID beginning with iso.dod.org
   (1.3.6).  Rather it begins with 0.0.  The remainder is either another
   0 when there is no wildcarding or the instance that satisfied the
   wildcard if there is wildcarding.

2.4.  Subsets

   To pare down the Expression MIBs complexity and use of resources an
   implementor can leave out various parts.

2.4.1.  No Wildcards

   Leaving out wildcarding significantly reduces the complexity of
   retrieving values to evaluate expressions and the processing required
   to do so.  Such an implementation would allow expressions made up of




Kavasseri & Stewart         Standards Track                     [Page 6]

RFC 2982         Distributed Management Expression MIB      October 2000


   individual MIB objects but would not be suitable for expressions
   applied across large tables as each instance in the table would
   require a separate expression definition.

   Furthermore it would not be suitable for tables with arbitrary,
   dynamic instances, as expressions definitions could not predict what
   instance values to use.

   An implementation without wildcards might be useful for a self-
   managing system with small tables or few dynamic instances, or one
   that can do calculations only for a few key objects.

2.4.2.  No Deltas

   Leaving out delta processing significantly reduces state that must be