rfc2037.txt

<VC++网络游戏建摸与实现>源代码

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

   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.

3.9.  Re-Configuration of Entities

   All the MIB objects defined in this MIB have at most a read-only
   MAX-ACCESS clause, i.e., none are write-able.  This is a conscious
   decision by the working group to limit this MIB's scope.  It is
   possible that this restriction could be lifted after implementation
   experience, by means of additional tables (using the AUGMENTS clause)
   for configuration and extended entity information.

3.10.  MIB Structure

   The Entity MIB contains five conformance groups:

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





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


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

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

3.10.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 contains at least one row for an "overall" physical entity.
   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.

3.10.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 SNMPv1 or SNMPv2C [9] access to the MIB
   information for the logical entity.

3.10.3.  entityMapping Group

   This group contains a 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.



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


   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 only
   relevant in a particular naming scope.


   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.

3.10.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 system configuration last changed.

3.10.5.  entityNotifications Group

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

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









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


4.  Definitions

ENTITY-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    mib-2, NOTIFICATION-TYPE
        FROM SNMPv2-SMI
    TDomain, TAddress, DisplayString, TEXTUAL-CONVENTION,
    AutonomousType, RowPointer, TimeStamp
        FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF;

entityMIB MODULE-IDENTITY
    LAST-UPDATED "9605160000Z"
    ORGANIZATION "IETF ENTMIB Working Group"
    CONTACT-INFO
            "        WG E-mail: [e-mail]
                     Subscribe: [e-mail]
                                msg body: subscribe entmib

                     Keith McCloghrie
                     ENTMIB Working Group Chair
                     Cisco Systems Inc.
                     170 West Tasman Drive
                     San Jose, CA 95134
                     408-526-5260
                     [e-mail]

                     Andy Bierman
                     ENTMIB Working Group Editor
                     Cisco Systems Inc.
                     170 West Tasman Drive
                     San Jose, CA 95134
                     408-527-3711
                     [e-mail]"
    DESCRIPTION
            "The MIB module for representing multiple logical
            entities supported by a single SNMP agent."
    ::= { mib-2 47 }

entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 }

-- MIB contains four groups

entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 }
entityLogical  OBJECT IDENTIFIER ::= { entityMIBObjects 2 }



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


entityMapping  OBJECT IDENTIFIER ::= { entityMIBObjects 3 }
entityGeneral  OBJECT IDENTIFIER ::= { entityMIBObjects 4 }


-- Textual Conventions
PhysicalIndex ::= TEXTUAL-CONVENTION
    STATUS          current
    DESCRIPTION
            "An arbitrary value which uniquely identifies the physical
            entity.  The value is a small positive integer; index values
            for different physical entities are not necessarily
            contiguous."
    SYNTAX          INTEGER (1..2147483647)


PhysicalClass ::= TEXTUAL-CONVENTION
    STATUS          current
    DESCRIPTION
            "An enumerated value which provides an indication of the
            general hardware type of a particular physical entity."
    SYNTAX      INTEGER  {
        other(1),
        unknown(2),
        chassis(3),
        backplane(4),
        container(5),   -- e.g. slot or daughter-card holder
        powerSupply(6),
        fan(7),
        sensor(8),
        module(9),      -- e.g. plug-in card or daughter-card
        port(10)
    }

--           The Physical Entity Table

entPhysicalTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF EntPhysicalEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "This table contains one row per physical entity.  There is
            always at least one row for an 'overall' physical entity."
    ::= { entityPhysical 1 }

entPhysicalEntry       OBJECT-TYPE
    SYNTAX      EntPhysicalEntry
    MAX-ACCESS  not-accessible
    STATUS      current



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


    DESCRIPTION
            "Information about a particular physical entity.

            Each entry provides objects (entPhysicalDescr,
            entPhysicalVendorType, and entPhysicalClass) to help an NMS
            identify and characterize the entry, and objects
            (entPhysicalContainedIn and entPhysicalParentRelPos) to help
            an NMS relate the particular entry to other entries in this
            table."
    INDEX   { entPhysicalIndex }
    ::= { entPhysicalTable 1 }

EntPhysicalEntry ::= SEQUENCE {
      entPhysicalIndex          PhysicalIndex,
      entPhysicalDescr          DisplayString,
      entPhysicalVendorType     AutonomousType,
      entPhysicalContainedIn    INTEGER,
      entPhysicalClass          PhysicalClass,
      entPhysicalParentRelPos   INTEGER,
      entPhysicalName           DisplayString
}

entPhysicalIndex    OBJECT-TYPE
    SYNTAX      PhysicalIndex
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "The index for this entry."
    ::= { entPhysicalEntry 1 }

entPhysicalDescr OBJECT-TYPE
    SYNTAX      DisplayString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "A textual description of physical entity.  This object
            should contain a string which identifies the manufacturer's
            name for the physical entity, and should be set to a
            distinct value for each version or model of the physical
            entity. "
    ::= { entPhysicalEntry 2 }

entPhysicalVendorType OBJECT-TYPE
    SYNTAX      AutonomousType
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "An indication of the vendor-specific hardware type of the



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


            physical entity. Note that this is different from the
            definition of MIB-II's sysObjectID.