Network Working Group                                      K. McCloghrieRequest 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 ....................................   10McCloghrie & 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 ...................................   561.  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 beMcCloghrie & 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