rfc2737.txt

中、英文RFC文档大全打包下载完全版 .

Network Working Group                                      K. McCloghrie
Request for Comments: 2737                           Cisco Systems, Inc.
Obsoletes: 2037                                               A. Bierman
                                                     Cisco Systems, Inc.
                                                           December 1999


                         Entity MIB (Version 2)

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 (1999).  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
   multiple logical and physical entities managed by a single SNMP
   agent.

Table of Contents

   1 The SNMP Management Framework ...............................    2
   2 Overview ....................................................    3
   2.1 Terms .....................................................    4
   2.2 Relationship to Community Strings .........................    5
   2.3 Relationship to SNMP Contexts .............................    5
   2.4 Relationship to Proxy Mechanisms ..........................    6
   2.5 Relationship to a Chassis MIB .............................    6
   2.6 Relationship to the Interfaces MIB ........................    6
   2.7 Relationship to the Other MIBs ............................    7
   2.8 Relationship to Naming Scopes .............................    7
   2.9 Multiple Instances of the Entity MIB ......................    7
   2.10 Re-Configuration of Entities .............................    8
   2.11 Textual Convention Change ................................    8
   2.12 MIB Structure ............................................    8
   2.12.1 entityPhysical Group ...................................    9
   2.12.2 entityLogical Group ....................................   10
   2.12.3 entityMapping Group ....................................   10



McCloghrie & Bierman        Standards Track                     [Page 1]

RFC 2737                 Entity MIB (Version 2)            December 1999


   2.12.4 entityGeneral Group ....................................   11
   2.12.5 entityNotifications Group ..............................   11
   2.13 Multiple Agents ..........................................   11
   2.14 Changes Since RFC 2037 ...................................   11
   2.14.1 Textual Conventions ....................................   11
   2.14.2 New entPhysicalTable Objects ...........................   12
   2.14.3 New entLogicalTable Objects ............................   12
   2.14.4 Bugfixes ...............................................   12
   3 Definitions .................................................   13
   4 Usage Examples ..............................................   38
   4.1 Router/Bridge .............................................   38
   4.2 Repeaters .................................................   44
   5 Intellectual Property .......................................   51
   6 Acknowledgements ............................................   51
   7 References ..................................................   51
   8 Security Considerations .....................................   53
   9 Authors' Addresses ..........................................   55
   10 Full Copyright Statement ...................................   56

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



McCloghrie & Bierman        Standards Track                     [Page 2]

RFC 2737                 Entity MIB (Version 2)            December 1999


   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

   There is a need for a standardized way of representing a single agent
   which supports multiple instances of one MIB.  This is presently true
   for at least 3 standard MIBs, and is likely to become true for more
   and more MIBs as time passes.  For example:

      - multiple instances of a bridge supported within a single device
        having a single agent;

      - multiple repeaters supported by a single agent;

      - multiple OSPF backbone areas, each one operating as part of its
        own Autonomous System, and each identified by the same area-id
        (e.g., 0.0.0.0), supported inside a single router with one
        agent.

   The fact that it is a single agent in each of these cases implies
   there is some relationship which binds all of these entities
   together.  Effectively, there is some "overall" physical entity which
   houses the sum of the things managed by that one agent, i.e., there
   are multiple "logical" entities within a single physical entity.
   Sometimes, the overall physical entity contains multiple (smaller)
   physical entities and each logical entity is associated with a
   particular physical entity.  Sometimes, the overall physical entity
   is a "compound" of multiple physical entities (e.g., a stack of
   stackable hubs).



McCloghrie & Bierman        Standards Track                     [Page 3]

RFC 2737                 Entity MIB (Version 2)            December 1999


   What is needed is a way to determine exactly what logical entities
   are managed by the agent (with some version of SNMP), and thereby to
   be able to communicate with the agent about a particular logical
   entity.  When different logical entities are associated with
   different physical entities within the overall physical entity, it is
   also useful to be able to use this information to distinguish between
   logical entities.

   In these situations, there is no need for varbinds for multiple
   logical entities to be referenced in the same SNMP message (although
   that might be useful in the future).  Rather, it is sufficient, and
   in some situations preferable, to have the context/community in the
   message identify the logical entity to which the varbinds apply.

   Version 2 of this MIB addresses new requirements that have emerged
   since the publication of the first Entity MIB (RFC 2037 [RFC2037]).
   There is a need for a standardized way of providing non-volatile,
   administratively assigned identifiers for physical components
   represented with the Entity MIB.  There is also a need to align the
   Entity MIB with the SNMPv3 administrative framework (RFC 2571
   [RFC2571]). Implementation experience has shown that additional
   physical component attributes are also desirable.

2.1.  Terms

   Some new terms are used throughout this document:

      - Naming Scope
        A "naming scope" represents the set of information that may be
        potentially accessed through a single SNMP operation. All
        instances within the naming scope share the same unique
        identifier space.  For SNMPv1, a naming scope is identified by
        the value of the associated 'entLogicalCommunity' instance.  For
        SNMPv3, the term 'context' is used instead of 'naming scope'.
        The complete definition of an SNMP context can be found in
        section 3.3.1 of RFC 2571 [RFC2571].

      - Multi-Scoped Object
        A MIB object, for which identical instance values identify
        different managed information in different naming scopes, is
        called a "multi-scoped" MIB object.

      - Single-Scoped Object
        A MIB object, for which identical instance values identify the
        same managed information in different naming scopes, is called a
        "single-scoped" MIB object.





McCloghrie & Bierman        Standards Track                     [Page 4]

RFC 2737                 Entity MIB (Version 2)            December 1999


      - Logical Entity
        A managed system contains one or more logical entities, each
        represented by at most one instantiation of each of a particular
        set of MIB objects.  A set of management functions is associated
        with each logical entity. Examples of logical entities include
        routers, bridges, print-servers, etc.

      - Physical Entity
        A "physical entity" or "physical component" represents an
        identifiable physical resource within a managed system. Zero or
        more logical entities may utilize a physical resource at any
        given time. It is an implementation-specific manner as to which
        physical components are represented by an agent in the
        EntPhysicalTable.  Typically, physical resources (e.g.,
        communications ports, backplanes, sensors, daughter-cards, power
        supplies, the overall chassis) which can be managed via
        functions associated with one or more logical entities are
        included in the MIB.

      - Containment Tree
        Each physical component may be modeled as 'contained' within
        another physical component. A "containment-tree" is the
        conceptual sequence of entPhysicalIndex values which uniquely
        specifies the exact physical location of a physical component
        within the managed system.  It is generated by 'following and
        recording' each 'entPhysicalContainedIn' instance 'up the tree
        towards the root', until a value of zero indicating no further
        containment is found.

2.2.  Relationship to Community Strings

   For community-based SNMP, distinguishing between different logical
   entities is one (but not the only) purpose of the community string
   (STD 15, RFC 1157 [RFC1157]).  This is accommodated by representing
   each community string as a logical entity.

   Note that different logical entities may share the same naming scope
   (and therefore the same values of entLogicalCommunity). This is
   possible, providing they have no need for the same instance of a MIB
   object to represent different managed information.

2.3.  Relationship to SNMP Contexts

   Version 2 of the Entity MIB contains support for associating SNMPv3
   contexts with logical entities. Two new MIB objects, defining an
   SnmpEngineID and ContextName pair, are used together to identify an
   SNMP context associated with a logical entity. This context can be




McCloghrie & Bierman        Standards Track                     [Page 5]

RFC 2737                 Entity MIB (Version 2)            December 1999


   used (in conjunction with the entLogicalTAddress and
   entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of a
   particular logical entity.

2.4.  Relationship to Proxy Mechanisms

   The Entity MIB is designed to allow functional component discovery.
   The administrative relationships between different logical entities
   are not visible in any Entity MIB tables. An NMS cannot determine
   whether MIB instances in different naming scopes are realized locally
   or remotely (e.g., via some proxy mechanism) by examining any
   particular Entity MIB objects.

   The management of administrative framework functions is not an
   explicit goal of the Entity MIB WG at this time. This new area of
   functionality may be revisited after some operational experience with
   the Entity MIB is gained.

   Note that for community-based versions of SNMP, a network
   administrator will likely be able to associate community strings with
   naming scopes with proprietary mechanisms, as a matter of
   configuration.  There are no mechanisms for managing naming scopes
   defined in this MIB.

2.5.  Relationship to a Chassis MIB

   Some readers may recall that a previous IETF working group attempted
   to define a Chassis MIB.  No consensus was reached by that working
   group, possibly because its scope was too broad.  As such, it is not
   the purpose of this MIB to be a "Chassis MIB replacement", nor is it