rfc2037.txt

RFC 的详细文档！

Network Working Group                                     K. McCloghrie
Request for Comments: 2037                                   A. Bierman
Category: Standards Track                                 Cisco Systems
                                                           October 1996


                         Entity MIB using SMIv2

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.

Table of Contents

   1. Introduction ..............................................    2
   2. The SNMP Network Management Framework .....................    2
   2.1 Object Definitions .......................................    2
   3. Overview ..................................................    3
   3.1 Terms ....................................................    4
   3.2 Relationship to Community Strings ........................    5
   3.3 Relationship to Proxy Mechanisms .........................    5
   3.4 Relationship to a Chassis MIB ............................    5
   3.5 Relationship to the Interfaces MIB .......................    6
   3.6 Relationship to the Other MIBs ...........................    6
   3.7 Relationship to Naming Scopes ............................    6
   3.8 Multiple Instances of the Entity MIB .....................    7
   3.9 Re-Configuration of Entities .............................    7
   3.10 MIB Structure ...........................................    7
   3.10.1 entityPhysical Group ..................................    8
   3.10.2 entityLogical Group ...................................    8
   3.10.3 entityMapping Group ...................................    8
   3.10.4 entityGeneral Group ...................................    9
   3.10.5 entityNotifications Group .............................    9
   3.11 Multiple Agents .........................................    9
   4. Definitions ...............................................   10
   5. Usage Examples ............................................   26
   5.1 Router/Bridge ............................................   26
   5.2 Repeaters ................................................   30
   6. Acknowledgements ..........................................   33
   7. References ................................................   34
   8. Security Considerations ...................................   35
   9. Authors' Addresses ........................................   35





McCloghrie & Bierman        Standards Track                     [Page 1]

RFC 2037                 Entity MIB using SMIv2             October 1996


1.  Introduction

   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.

2.  The SNMP Network Management Framework

   The SNMP Network Management Framework presently consists of three
   major components.  They are:

   o    the SMI, described in RFC 1902 [1], - the mechanisms used for
        describing and naming objects for the purpose of management.

   o    the MIB-II, STD 17, RFC 1213 [2], - the core set of managed
        objects for the Internet suite of protocols.

   o    the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the protocol
        for accessing managed information.

   Textual conventions are defined in RFC 1903 [3], and conformance
   statements are defined in RFC 1904 [5].

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

   This memo specifies a MIB module that is compliant to the SNMPv2 SMI.
   A semantically identical MIB conforming to the SNMPv1 SMI can be
   produced through the appropriate translation.

2.1.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object type is named by an
   OBJECT IDENTIFIER, an administratively assigned name.  The object
   type together with an object instance serves to uniquely identify a
   specific instantiation of the object.  For human convenience, we
   often use a textual string, termed the descriptor, to refer to the
   object type.








McCloghrie & Bierman        Standards Track                     [Page 2]

RFC 2037                 Entity MIB using SMIv2             October 1996


3.  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).

   What is needed is a way to determine exactly what logical entities
   are managed by the agent (either by SNMPv1 or SNMPv2), 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.










McCloghrie & Bierman        Standards Track                     [Page 3]

RFC 2037                 Entity MIB using SMIv2             October 1996


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

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

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



McCloghrie & Bierman        Standards Track                     [Page 4]

RFC 2037                 Entity MIB using SMIv2             October 1996


     Note that chassis slots, which are capable of accepting one or more
     module types from one or more vendors, are modeled as containers in
     this MIB. The value of entPhysicalContainedIn for a particular
     'module' entity (entPhysicalClass value of 'module(9)') must be
     equal to an entPhysicalIndex that represents the parent 'container'
     entity (associated entPhysicalClass value of ('container(5)'). An
     agent must represent both empty and full containers in the
     entPhysicalTable.

3.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
   [6].  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.

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

3.4.  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
   within the scope of this MIB to contain all the information which
   might be necessary to manage a "chassis".  On the other hand, the



McCloghrie & Bierman        Standards Track                     [Page 5]

RFC 2037                 Entity MIB using SMIv2             October 1996


   entities represented by an implementation of this MIB might well be
   contained in a chassis.

3.5.  Relationship to the Interfaces MIB

   The Entity MIB contains a mapping table identifying physical
   components that have 'external values' (e.g. ifIndex) associated with
   them within a given naming scope.  This table can be used to identify
   the physical location of each interface in the ifTable [7]. Since
   ifIndex values in different contexts are not related to one another,
   the interface to physical component associations are relative to the
   same logical entity within the agent.

   The Entity MIB also contains an 'entPhysicalName' object, which
   approximates the semantics of the ifName object from the Interfaces
   MIB [7] for all types of physical components.

3.6.  Relationship to the Other MIBs

   The Entity MIB contains a mapping table identifying physical
   components that have identifiers from other standard MIBs associated
   with them.  For example, this table can be used along with the
   physical mapping table to identify the physical location of each
   repeater port in the rptrPortTable, or each interface in the ifTable.

3.7.  Relationship to Naming Scopes

   There is some question as to which MIB objects may be returned within
   a given naming scope. MIB objects which are not multi-scoped within a
   managed system are likely to ignore context information in
   implementation. In such a case, it is likely such objects will be
   returned in all naming scopes (e.g. not just the 'main' naming
   scope).

   For example, a community string used to access the management
   information for logical device 'bridge2' may allow access to all the
   non-bridge related objects in the 'main' naming scope, as well as a
   second instance of the Bridge MIB.

   It is an implementation-specific matter as to the isolation of
   single-scoped MIB objects by the agent. An agent may wish to limit
   the objects returned in a particular naming scope to just the multi-
   scoped objects in that naming scope (e.g. system group and the Bridge
   MIB).  In this case, all single-scoped management information would
   belong to a common naming scope (e.g. 'main'), which itself may