rfc2737.txt

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

   within the scope of this MIB to contain all the information which
   might be necessary to manage a "chassis".  On the other hand, the
   entities represented by an implementation of this MIB might well be
   contained in a chassis.

2.6.  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 (RFC
   2233 [RFC2233]).  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.






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


   The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias'
   objects, which approximate the semantics of the 'ifName' and '
   ifAlias' objects (respectively) from the Interfaces MIB [RFC2233],
   for all types of physical components.

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

2.8.  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 'default' naming
   scope or the SNMPv3 default context).

   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 'default' naming scope, as well as
   a second instance of the Bridge MIB (RFC 1493 [RFC1493]).

   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., 'default'), which itself
   may contain some multi-scoped objects (e.g., system group).

2.9.  Multiple Instances of the Entity MIB

   It is possible that more than one agent exists in a managed system,
   and in such cases, multiple instances of the Entity MIB (representing
   the same managed objects) may be available to an NMS.

   In order to reduce complexity for agent implementation, multiple
   instances of the Entity MIB are not required to be equivalent or even
   consistent. An NMS may be able to 'align' instances returned by
   different agents by examining the columns of each table, but vendor-
   specific identifiers and (especially) index values are likely to be
   different. Each agent may be managing different subsets of the entire
   chassis as well.



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


   When all of a physically-modular device is represented by a single
   agent, the entry for which entPhysicalContainedIn has the value zero
   would likely have 'chassis' as the value of its entPhysicalClass;
   alternatively, for an agent on a module where the agent represents
   only the physical entities on that module (not those on other
   modules), the entry for which entPhysicalContainedIn has the value
   zero would likely have 'module' as the value of its entPhysicalClass.

   An agent implementation of the entLogicalTable is not required to
   contain information about logical entities managed primarily by other
   agents. That is, the entLogicalTAddress and entLogicalTDomain objects
   in the entLogicalTable are provided to support an historical
   multiplexing mechanism, not to identify other SNMP agents.

   Note that the Entity MIB is a single-scoped MIB, in the event an
   agent represents the MIB in different naming scopes.

2.10.  Re-Configuration of Entities

   Most of the MIB objects defined in this MIB have at most a read-only
   MAX-ACCESS clause.  This is a conscious decision by the working group
   to limit this MIB's scope.  The second version of the Entity MIB
   allows a network administrator to configure some common attributes of
   physical components.

2.11.  Textual Convention Change

   Version 1 of the Entity MIB contains three MIB objects defined with
   the (now obsolete) DisplayString textual convention.  In version 2 of
   the Entity MIB, the syntax for these objects has been updated to use
   the (now preferred) SnmpAdminString textual convention.

   The working group realizes that this change is not strictly supported
   by SMIv2.  In our judgment, the alternative of deprecating the old
   objects and defining new objects would have a more adverse impact on
   backward compatibility and interoperability, given the particular
   semantics of these objects.

2.12.  MIB Structure

   The Entity MIB contains five groups of MIB objects:

      - entityPhysical group
        Describes the physical entities managed by a single agent.

      - entityLogical group
        Describes the logical entities managed by a single agent.




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


      - entityMapping group
        Describes the associations between the physical entities,
        logical entities, interfaces, and non-interface ports managed by
        a single agent.

      - entityGeneral group
        Describes general system attributes shared by potentially all
        types of entities managed by a single agent.

      - entityNotifications group
        Contains status indication notifications.

2.12.1.  entityPhysical Group

   This group contains a single table to identify physical system
   components, called the entPhysicalTable.

   The entPhysicalTable contains one row per physical entity, and must
   always contain at least one row for an "overall" physical entity,
   which should have an entPhysicalClass value of 'stack(11)', '
   chassis(3)' or 'module(9)'.

   Each row is indexed by an arbitrary, small integer, and contains a
   description and type of the physical entity.  It also optionally
   contains the index number of another entPhysicalEntry indicating a
   containment relationship between the two.

   Version 2 of the Entity MIB provides additional MIB objects for each
   physical entity. Some common read-only attributes have been added, as
   well as three writable string objects.

      - entPhysicalAlias
        This string can be used by an NMS as a non-volatile identifier
        for the physical component. Maintaining a non-volatile string
        for every physical component represented in the entPhysicalTable
        can be costly and unnecessary.  An agent may algorithmically
        generate 'entPhysicalAlias' strings for particular entries
        (e.g., based on the entPhysicalClass value).

      - entPhysicalAssetID
        This string is provided to store a user-specific asset
        identifier for removable physical components.  In order to
        reduce the non-volatile storage needed by a particular agent, a
        network administrator should only assign asset identifiers to
        physical entities which are field-replaceable (i.e., not
        permanently contained within another physical entity).





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


      - entPhysicalSerialNum
        This string is provided to store a vendor-specific serial number
        string for physical components.  This is a writable object in
        case an agent cannot identify the serial numbers of all
        installed physical entities, and a network administrator wishes
        to configure the non-volatile serial number strings manually
        (via an NMS application).

2.12.2.  entityLogical Group

   This group contains a single table to identify logical entities,
   called the entLogicalTable.

   The entLogicalTable contains one row per logical entity.  Each row is
   indexed by an arbitrary, small integer and contains a name,
   description, and type of the logical entity. It also contains
   information to allow access to the MIB information for the logical
   entity. This includes SNMP versions that use a community name (with
   some form of implied context representation) and SNMP versions that
   use the SNMP ARCH [RFC2571] method of context identification.

   If a agent represents multiple logical entities with this MIB, then
   this group must be implemented for all logical entities known to the
   agent.

   If an agent represents a single logical entity, or multiple logical
   entities within a single naming scope, then implementation of this
   group may be omitted by the agent.

2.12.3.  entityMapping Group

   This group contains three tables to identify associations between
   different system components.

   The entLPMappingTable contains mappings between entLogicalIndex
   values (logical entities) and entPhysicalIndex values (the physical
   components supporting that entity). A logical entity can map to more
   than one physical component, and more than one logical entity can map
   to (share) the same physical component.  If an agent represents a
   single logical entity, or multiple logical entities within a single
   naming scope, then implementation of this table may be omitted by the
   agent.

   The entAliasMappingTable contains mappings between entLogicalIndex,
   entPhysicalIndex pairs and 'alias' object identifier values.  This
   allows resources managed with other MIBs (e.g., repeater ports,
   bridge ports, physical and logical interfaces) to be identified in
   the physical entity hierarchy. Note that each alias identifier is



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


   only relevant in a particular naming scope.  If an agent represents a
   single logical entity, or multiple logical entities within a single
   naming scope, then implementation of this table may be omitted by the
   agent.

   The entPhysicalContainsTable contains simple mappings between
   'entPhysicalContainedIn' values for each container/'containee'
   relationship in the managed system. The indexing of this table allows
   an NMS to quickly discover the 'entPhysicalIndex' values for all
   children of a given physical entity.

2.12.4.  entityGeneral Group

   This group contains general information relating to the other object
   groups.

   At this time, the entGeneral group contains a single scalar object
   (entLastChangeTime), which represents the value of sysUptime when any
   part of the Entity MIB configuration last changed.

2.12.5.  entityNotifications Group

   This group contains notification definitions relating to the overall
   status of the Entity MIB instantiation.

2.13.  Multiple Agents

   Even though a primary motivation for this MIB is to represent the
   multiple logical entities supported by a single agent, it is also
   possible to use it to represent multiple logical entities supported
   by multiple agents (in the same "overall" physical entity).  Indeed,
   it is implicit in the SNMP architecture, that the number of agents is
   transparent to a network management station.

   However, there is no agreement at this time as to the degree of
   cooperation which should be expected for agent implementations.
   Therefore, multiple agents within the same managed system are free to
   implement the Entity MIB independently.  (Refer the section on
   "Multiple Instances of the Entity MIB" for more details).

2.14.  Changes Since RFC 2037

2.14.1.  Textual Conventions

   The PhysicalClass TC text has been clarified, and a new enumeration
   to support 'stackable' components has been added.  The
   SnmpEngineIdOrNone TC has been added to support SNMPv3.




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


2.14.2.  New entPhysicalTable Objects

   The entPhysicalHardwareRev, entPhysicalFirmwareRev, and
   entPhysicalSoftwareRev objects have been added for revision
   identification.

   The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName,
   and entPhysicalIsFru objects have been added for better vendor
   identification for physical components.  The entPhysicalSerialNum
   object can be set by a management station in the event the agent