home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2037.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  72.6 KB  |  1,964 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                     K. McCloghrie
  8. Request for Comments: 2037                                   A. Bierman
  9. Category: Standards Track                                 Cisco Systems
  10.                                                            October 1996
  11.  
  12.  
  13.                          Entity MIB using SMIv2
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Table of Contents
  24.  
  25.    1. Introduction ..............................................    2
  26.    2. The SNMP Network Management Framework .....................    2
  27.    2.1 Object Definitions .......................................    2
  28.    3. Overview ..................................................    3
  29.    3.1 Terms ....................................................    4
  30.    3.2 Relationship to Community Strings ........................    5
  31.    3.3 Relationship to Proxy Mechanisms .........................    5
  32.    3.4 Relationship to a Chassis MIB ............................    5
  33.    3.5 Relationship to the Interfaces MIB .......................    6
  34.    3.6 Relationship to the Other MIBs ...........................    6
  35.    3.7 Relationship to Naming Scopes ............................    6
  36.    3.8 Multiple Instances of the Entity MIB .....................    7
  37.    3.9 Re-Configuration of Entities .............................    7
  38.    3.10 MIB Structure ...........................................    7
  39.    3.10.1 entityPhysical Group ..................................    8
  40.    3.10.2 entityLogical Group ...................................    8
  41.    3.10.3 entityMapping Group ...................................    8
  42.    3.10.4 entityGeneral Group ...................................    9
  43.    3.10.5 entityNotifications Group .............................    9
  44.    3.11 Multiple Agents .........................................    9
  45.    4. Definitions ...............................................   10
  46.    5. Usage Examples ............................................   26
  47.    5.1 Router/Bridge ............................................   26
  48.    5.2 Repeaters ................................................   30
  49.    6. Acknowledgements ..........................................   33
  50.    7. References ................................................   34
  51.    8. Security Considerations ...................................   35
  52.    9. Authors' Addresses ........................................   35
  53.  
  54.  
  55.  
  56.  
  57.  
  58. McCloghrie & Bierman        Standards Track                     [Page 1]
  59.  
  60. RFC 2037                 Entity MIB using SMIv2             October 1996
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    This memo defines a portion of the Management Information Base (MIB)
  66.    for use with network management protocols in the Internet community.
  67.    In particular, it describes managed objects used for managing
  68.    multiple logical and physical entities managed by a single SNMP
  69.    agent.
  70.  
  71. 2.  The SNMP Network Management Framework
  72.  
  73.    The SNMP Network Management Framework presently consists of three
  74.    major components.  They are:
  75.  
  76.    o    the SMI, described in RFC 1902 [1], - the mechanisms used for
  77.         describing and naming objects for the purpose of management.
  78.  
  79.    o    the MIB-II, STD 17, RFC 1213 [2], - the core set of managed
  80.         objects for the Internet suite of protocols.
  81.  
  82.    o    the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the protocol
  83.         for accessing managed information.
  84.  
  85.    Textual conventions are defined in RFC 1903 [3], and conformance
  86.    statements are defined in RFC 1904 [5].
  87.  
  88.    The Framework permits new objects to be defined for the purpose of
  89.    experimentation and evaluation.
  90.  
  91.    This memo specifies a MIB module that is compliant to the SNMPv2 SMI.
  92.    A semantically identical MIB conforming to the SNMPv1 SMI can be
  93.    produced through the appropriate translation.
  94.  
  95. 2.1.  Object Definitions
  96.  
  97.    Managed objects are accessed via a virtual information store, termed
  98.    the Management Information Base or MIB.  Objects in the MIB are
  99.    defined using the subset of Abstract Syntax Notation One (ASN.1)
  100.    defined in the SMI.  In particular, each object type is named by an
  101.    OBJECT IDENTIFIER, an administratively assigned name.  The object
  102.    type together with an object instance serves to uniquely identify a
  103.    specific instantiation of the object.  For human convenience, we
  104.    often use a textual string, termed the descriptor, to refer to the
  105.    object type.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. McCloghrie & Bierman        Standards Track                     [Page 2]
  115.  
  116. RFC 2037                 Entity MIB using SMIv2             October 1996
  117.  
  118.  
  119. 3.  Overview
  120.  
  121.    There is a need for a standardized way of representing a single agent
  122.    which supports multiple instances of one MIB.  This is presently true
  123.    for at least 3 standard MIBs, and is likely to become true for more
  124.    and more MIBs as time passes.  For example:
  125.  
  126.       - multiple instances of a bridge supported within a single
  127.         device having a single agent;
  128.  
  129.       - multiple repeaters supported by a single agent;
  130.  
  131.       - multiple OSPF backbone areas, each one operating as part
  132.         of its own Autonomous System, and each identified by the
  133.         same area-id (e.g., 0.0.0.0), supported inside a single
  134.         router with one agent.
  135.  
  136.    The fact that it is a single agent in each of these cases implies
  137.    there is some relationship which binds all of these entities
  138.    together.  Effectively, there is some "overall" physical entity which
  139.    houses the sum of the things managed by that one agent, i.e., there
  140.    are multiple "logical" entities within a single physical entity.
  141.    Sometimes, the overall physical entity contains multiple (smaller)
  142.    physical entities and each logical entity is associated with a
  143.    particular physical entity.  Sometimes, the overall physical entity
  144.    is a "compound" of multiple physical entities (e.g., a stack of
  145.    stackable hubs).
  146.  
  147.    What is needed is a way to determine exactly what logical entities
  148.    are managed by the agent (either by SNMPv1 or SNMPv2), and thereby to
  149.    be able to communicate with the agent about a particular logical
  150.    entity.  When different logical entities are associated with
  151.    different physical entities within the overall physical entity, it is
  152.    also useful to be able to use this information to distinguish between
  153.    logical entities.
  154.  
  155.    In these situations, there is no need for varbinds for multiple
  156.    logical entities to be referenced in the same SNMP message (although
  157.    that might be useful in the future).  Rather, it is sufficient, and
  158.    in some situations preferable, to have the context/community in the
  159.    message identify the logical entity to which the varbinds apply.
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. McCloghrie & Bierman        Standards Track                     [Page 3]
  171.  
  172. RFC 2037                 Entity MIB using SMIv2             October 1996
  173.  
  174.  
  175. 3.1.  Terms
  176.  
  177.    Some new terms are used throughout this document:
  178.  
  179.    - Naming Scope
  180.      A "naming scope" represents the set of information that may be
  181.      potentially accessed through a single SNMP operation. All instances
  182.      within the naming scope share the same unique identifier space. For
  183.      SNMPv1, a naming scope is identified by the value of the associated
  184.      'entLogicalCommunity' instance.
  185.  
  186.    - Multi-Scoped Object
  187.      A MIB object, for which identical instance values identify
  188.      different managed information in different naming scopes, is called
  189.      a "multi-scoped" MIB object.
  190.  
  191.    - Single-Scoped Object
  192.      A MIB object, for which identical instance values identify the same
  193.      managed information in different naming scopes, is called a
  194.      "single-scoped" MIB object.
  195.  
  196.    - Logical Entity
  197.      A managed system contains one or more logical entities, each
  198.      represented by at most one instantiation of each of a particular
  199.      set of MIB objects. A set of management functions is associated
  200.      with each logical entity. Examples of logical entities include
  201.      routers, bridges, print-servers, etc.
  202.  
  203.    - Physical Entity
  204.      A "physical entity" or "physical component" represents an
  205.      identifiable physical resource within a managed system. Zero or
  206.      more logical entities may utilize a physical resource at any given
  207.      time. It is an implementation-specific manner as to which physical
  208.      components are represented by an agent in the EntPhysicalTable.
  209.      Typically, physical resources (e.g. communications ports,
  210.      backplanes, sensors, daughter-cards, power supplies, the overall
  211.      chassis) which can be managed via functions associated with one or
  212.      more logical entities are included in the MIB.
  213.  
  214.    - Containment Tree
  215.      Each physical component may optionally be modeled as 'contained'
  216.      within another physical component. A "containment-tree" is the
  217.      conceptual sequence of entPhysicalIndex values which uniquely
  218.      specifies the exact physical location of a physical component
  219.      within the managed system. It is generated by 'following and
  220.      recording' each 'entPhysicalContainedIn' instance 'up the tree
  221.      towards the root', until a value of zero indicating no further
  222.      containment is found.
  223.  
  224.  
  225.  
  226. McCloghrie & Bierman        Standards Track                     [Page 4]
  227.  
  228. RFC 2037                 Entity MIB using SMIv2             October 1996
  229.  
  230.  
  231.      Note that chassis slots, which are capable of accepting one or more
  232.      module types from one or more vendors, are modeled as containers in
  233.      this MIB. The value of entPhysicalContainedIn for a particular
  234.      'module' entity (entPhysicalClass value of 'module(9)') must be
  235.      equal to an entPhysicalIndex that represents the parent 'container'
  236.      entity (associated entPhysicalClass value of ('container(5)'). An
  237.      agent must represent both empty and full containers in the
  238.      entPhysicalTable.
  239.  
  240. 3.2.  Relationship to Community Strings
  241.  
  242.    For community-based SNMP, distinguishing between different logical
  243.    entities is one (but not the only) purpose of the community string
  244.    [6].  This is accommodated by representing each community string as a
  245.    logical entity.
  246.  
  247.    Note that different logical entities may share the same naming scope
  248.    (and therefore the same values of entLogicalCommunity). This is
  249.    possible, providing they have no need for the same instance of a MIB
  250.    object to represent different managed information.
  251.  
  252. 3.3.  Relationship to Proxy Mechanisms
  253.  
  254.    The Entity MIB is designed to allow functional component discovery.
  255.    The administrative relationships between different logical entities
  256.    are not visible in any Entity MIB tables. An NMS cannot determine
  257.    whether MIB instances in different naming scopes are realized locally
  258.    or remotely (e.g. via some proxy mechanism) by examining any
  259.    particular Entity MIB objects.
  260.  
  261.    The management of administrative framework functions is not an
  262.    explicit goal of the Entity MIB WG at this time. This new area of
  263.    functionality may be revisited after some operational experience with
  264.    the Entity MIB is gained.
  265.  
  266.    Note that a network administrator will likely be able to associate
  267.    community strings with naming scopes with proprietary mechanisms, as
  268.    a matter of configuration. There are no mechanisms for managing
  269.    naming scopes defined in this MIB.
  270.  
  271. 3.4.  Relationship to a Chassis MIB
  272.  
  273.    Some readers may recall that a previous IETF working group attempted
  274.    to define a Chassis MIB.  No consensus was reached by that working
  275.    group, possibly because its scope was too broad.  As such, it is not
  276.    the purpose of this MIB to be a "Chassis MIB replacement", nor is it
  277.    within the scope of this MIB to contain all the information which
  278.    might be necessary to manage a "chassis".  On the other hand, the
  279.  
  280.  
  281.  
  282. McCloghrie & Bierman        Standards Track                     [Page 5]
  283.  
  284. RFC 2037                 Entity MIB using SMIv2             October 1996
  285.  
  286.  
  287.    entities represented by an implementation of this MIB might well be
  288.    contained in a chassis.
  289.  
  290. 3.5.  Relationship to the Interfaces MIB
  291.  
  292.    The Entity MIB contains a mapping table identifying physical
  293.    components that have 'external values' (e.g. ifIndex) associated with
  294.    them within a given naming scope.  This table can be used to identify
  295.    the physical location of each interface in the ifTable [7]. Since
  296.    ifIndex values in different contexts are not related to one another,
  297.    the interface to physical component associations are relative to the
  298.    same logical entity within the agent.
  299.  
  300.    The Entity MIB also contains an 'entPhysicalName' object, which
  301.    approximates the semantics of the ifName object from the Interfaces
  302.    MIB [7] for all types of physical components.
  303.  
  304. 3.6.  Relationship to the Other MIBs
  305.  
  306.    The Entity MIB contains a mapping table identifying physical
  307.    components that have identifiers from other standard MIBs associated
  308.    with them.  For example, this table can be used along with the
  309.    physical mapping table to identify the physical location of each
  310.    repeater port in the rptrPortTable, or each interface in the ifTable.
  311.  
  312. 3.7.  Relationship to Naming Scopes
  313.  
  314.    There is some question as to which MIB objects may be returned within
  315.    a given naming scope. MIB objects which are not multi-scoped within a
  316.    managed system are likely to ignore context information in
  317.    implementation. In such a case, it is likely such objects will be
  318.    returned in all naming scopes (e.g. not just the 'main' naming
  319.    scope).
  320.  
  321.    For example, a community string used to access the management
  322.    information for logical device 'bridge2' may allow access to all the
  323.    non-bridge related objects in the 'main' naming scope, as well as a
  324.    second instance of the Bridge MIB.
  325.  
  326.    It is an implementation-specific matter as to the isolation of
  327.    single-scoped MIB objects by the agent. An agent may wish to limit
  328.    the objects returned in a particular naming scope to just the multi-
  329.    scoped objects in that naming scope (e.g. system group and the Bridge
  330.    MIB).  In this case, all single-scoped management information would
  331.    belong to a common naming scope (e.g. 'main'), which itself may
  332.    contain some multi-scoped objects (e.g. system group).
  333.  
  334.  
  335.  
  336.  
  337.  
  338. McCloghrie & Bierman        Standards Track                     [Page 6]
  339.  
  340. RFC 2037                 Entity MIB using SMIv2             October 1996
  341.  
  342.  
  343. 3.8.  Multiple Instances of the Entity MIB
  344.  
  345.    It is possible that more than one agent exists in a managed system,
  346.    and in such cases, multiple instances of the Entity MIB (representing
  347.    the same managed objects) may be available to an NMS.
  348.  
  349.    In order to reduce complexity for agent implementation, multiple
  350.    instances of the Entity MIB are not required to be equivalent or even
  351.    consistent. An NMS may be able to 'align' instances returned by
  352.    different agents by examining the columns of each table, but vendor-
  353.    specific identifiers and (especially) index values are likely to be
  354.    different. Each agent may be managing different subsets of the entire
  355.    chassis as well.
  356.  
  357.    When all of a physically-modular device is represented by a single
  358.    agent, the entry for which entPhysicalContainedIn has the value zero
  359.    would likely have 'chassis' as the value of its entPhysicalClass;
  360.    alternatively, for an agent on a module where the agent represents
  361.    only the physical entities on that module (not those on other
  362.    modules), the entry for which entPhysicalContainedIn has the value
  363.    zero would likely have 'module' as the value of its entPhysicalClass.
  364.  
  365.    An agent implementation of the entLogicalTable is not required to
  366.    contain information about logical entities managed primarily by other
  367.    agents. That is, the entLogicalTAddress and entLogicalTDomain objects
  368.    in the entLogicalTable are provided to support an historical
  369.    multiplexing mechanism, not to identify other SNMP agents.
  370.  
  371.    Note that the Entity MIB is a single-scoped MIB, in the event an
  372.    agent represents the MIB in different naming scopes.
  373.  
  374. 3.9.  Re-Configuration of Entities
  375.  
  376.    All the MIB objects defined in this MIB have at most a read-only
  377.    MAX-ACCESS clause, i.e., none are write-able.  This is a conscious
  378.    decision by the working group to limit this MIB's scope.  It is
  379.    possible that this restriction could be lifted after implementation
  380.    experience, by means of additional tables (using the AUGMENTS clause)
  381.    for configuration and extended entity information.
  382.  
  383. 3.10.  MIB Structure
  384.  
  385.    The Entity MIB contains five conformance groups:
  386.  
  387.      - entityPhysical group
  388.         Describes the physical entities managed by a single agent.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. McCloghrie & Bierman        Standards Track                     [Page 7]
  395.  
  396. RFC 2037                 Entity MIB using SMIv2             October 1996
  397.  
  398.  
  399.      - entityLogical group
  400.         Describes the logical entities managed by a single agent.
  401.  
  402.      - entityMapping group
  403.         Describes the associations between the physical entities,
  404.         logical entities, interfaces, and non-interface ports managed
  405.         by a single agent.
  406.  
  407.      -entityGeneral group
  408.         Describes general system attributes shared by potentially
  409.         all types of entities managed by a single agent.
  410.  
  411.      -entityNotifications group
  412.         Contains status indication notifications.
  413.  
  414. 3.10.1.  entityPhysical Group
  415.  
  416.    This group contains a single table to identify physical system
  417.    components, called the entPhysicalTable.
  418.  
  419.    The entPhysicalTable contains one row per physical entity, and must
  420.    always contains at least one row for an "overall" physical entity.
  421.    Each row is indexed by an arbitrary, small integer, and contains a
  422.    description and type of the physical entity.  It also optionally
  423.    contains the index number of another entPhysicalEntry indicating a
  424.    containment relationship between the two.
  425.  
  426. 3.10.2.  entityLogical Group
  427.  
  428.    This group contains a single table to identify logical entities,
  429.    called the entLogicalTable.
  430.  
  431.    The entLogicalTable contains one row per logical entity.  Each row is
  432.    indexed by an arbitrary, small integer and contains a name,
  433.    description, and type of the logical entity. It also contains
  434.    information to allow SNMPv1 or SNMPv2C [9] access to the MIB
  435.    information for the logical entity.
  436.  
  437. 3.10.3.  entityMapping Group
  438.  
  439.    This group contains a three tables to identify associations between
  440.    different system components.
  441.  
  442.    The entLPMappingTable contains mappings between entLogicalIndex
  443.    values (logical entities) and entPhysicalIndex values (the physical
  444.    components supporting that entity). A logical entity can map to more
  445.    than one physical component, and more than one logical entity can map
  446.    to (share) the same physical component.
  447.  
  448.  
  449.  
  450. McCloghrie & Bierman        Standards Track                     [Page 8]
  451.  
  452. RFC 2037                 Entity MIB using SMIv2             October 1996
  453.  
  454.  
  455.    The entAliasMappingTable contains mappings between entLogicalIndex,
  456.    entPhysicalIndex pairs and 'alias' object identifier values.  This
  457.    allows resources managed with other MIBs (e.g. repeater ports, bridge
  458.    ports, physical and logical interfaces) to be identified in the
  459.    physical entity hierarchy. Note that each alias identifier is only
  460.    relevant in a particular naming scope.
  461.  
  462.  
  463.    The entPhysicalContainsTable contains simple mappings between
  464.    'entPhysicalContainedIn' values for each container/containee
  465.    relationship in the managed system. The indexing of this table allows
  466.    an NMS to quickly discover the 'entPhysicalIndex' values for all
  467.    children of a given physical entity.
  468.  
  469. 3.10.4.  entityGeneral Group
  470.  
  471.    This group contains general information relating to the other object
  472.    groups.
  473.  
  474.    At this time, the entGeneral group contains a single scalar object
  475.    (entLastChangeTime), which represents the value of sysUptime when any
  476.    part of the system configuration last changed.
  477.  
  478. 3.10.5.  entityNotifications Group
  479.  
  480.    This group contains notification definitions relating to the overall
  481.    status of the Entity MIB instantiation.
  482.  
  483. 3.11.  Multiple Agents
  484.  
  485.    Even though a primary motivation for this MIB is to represent the
  486.    multiple logical entities supported by a single agent, it is also
  487.    possible to use it to represent multiple logical entities supported
  488.    by multiple agents (in the same "overall" physical entity).  Indeed,
  489.    it is implicit in the SNMP architecture, that the number of agents is
  490.    transparent to a network management station.
  491.  
  492.    However, there is no agreement at this time as to the degree of
  493.    cooperation which should be expected for agent implementations.
  494.    Therefore, multiple agents within the same managed system are free to
  495.    implement the Entity MIB independently.  (Refer the section on
  496.    "Multiple Instances of the Entity MIB" for more details).
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. McCloghrie & Bierman        Standards Track                     [Page 9]
  507.  
  508. RFC 2037                 Entity MIB using SMIv2             October 1996
  509.  
  510.  
  511. 4.  Definitions
  512.  
  513. ENTITY-MIB DEFINITIONS ::= BEGIN
  514.  
  515. IMPORTS
  516.     MODULE-IDENTITY, OBJECT-TYPE,
  517.     mib-2, NOTIFICATION-TYPE
  518.         FROM SNMPv2-SMI
  519.     TDomain, TAddress, DisplayString, TEXTUAL-CONVENTION,
  520.     AutonomousType, RowPointer, TimeStamp
  521.         FROM SNMPv2-TC
  522.     MODULE-COMPLIANCE, OBJECT-GROUP
  523.         FROM SNMPv2-CONF;
  524.  
  525. entityMIB MODULE-IDENTITY
  526.     LAST-UPDATED "9605160000Z"
  527.     ORGANIZATION "IETF ENTMIB Working Group"
  528.     CONTACT-INFO
  529.             "        WG E-mail: entmib@cisco.com
  530.                      Subscribe: majordomo@cisco.com
  531.                                 msg body: subscribe entmib
  532.  
  533.                      Keith McCloghrie
  534.                      ENTMIB Working Group Chair
  535.                      Cisco Systems Inc.
  536.                      170 West Tasman Drive
  537.                      San Jose, CA 95134
  538.                      408-526-5260
  539.                      kzm@cisco.com
  540.  
  541.                      Andy Bierman
  542.                      ENTMIB Working Group Editor
  543.                      Cisco Systems Inc.
  544.                      170 West Tasman Drive
  545.                      San Jose, CA 95134
  546.                      408-527-3711
  547.                      abierman@cisco.com"
  548.     DESCRIPTION
  549.             "The MIB module for representing multiple logical
  550.             entities supported by a single SNMP agent."
  551.     ::= { mib-2 47 }
  552.  
  553. entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 }
  554.  
  555. -- MIB contains four groups
  556.  
  557. entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 }
  558. entityLogical  OBJECT IDENTIFIER ::= { entityMIBObjects 2 }
  559.  
  560.  
  561.  
  562. McCloghrie & Bierman        Standards Track                    [Page 10]
  563.  
  564. RFC 2037                 Entity MIB using SMIv2             October 1996
  565.  
  566.  
  567. entityMapping  OBJECT IDENTIFIER ::= { entityMIBObjects 3 }
  568. entityGeneral  OBJECT IDENTIFIER ::= { entityMIBObjects 4 }
  569.  
  570.  
  571. -- Textual Conventions
  572. PhysicalIndex ::= TEXTUAL-CONVENTION
  573.     STATUS          current
  574.     DESCRIPTION
  575.             "An arbitrary value which uniquely identifies the physical
  576.             entity.  The value is a small positive integer; index values
  577.             for different physical entities are not necessarily
  578.             contiguous."
  579.     SYNTAX          INTEGER (1..2147483647)
  580.  
  581.  
  582. PhysicalClass ::= TEXTUAL-CONVENTION
  583.     STATUS          current
  584.     DESCRIPTION
  585.             "An enumerated value which provides an indication of the
  586.             general hardware type of a particular physical entity."
  587.     SYNTAX      INTEGER  {
  588.         other(1),
  589.         unknown(2),
  590.         chassis(3),
  591.         backplane(4),
  592.         container(5),   -- e.g. slot or daughter-card holder
  593.         powerSupply(6),
  594.         fan(7),
  595.         sensor(8),
  596.         module(9),      -- e.g. plug-in card or daughter-card
  597.         port(10)
  598.     }
  599.  
  600. --           The Physical Entity Table
  601.  
  602. entPhysicalTable OBJECT-TYPE
  603.     SYNTAX      SEQUENCE OF EntPhysicalEntry
  604.     MAX-ACCESS  not-accessible
  605.     STATUS      current
  606.     DESCRIPTION
  607.             "This table contains one row per physical entity.  There is
  608.             always at least one row for an 'overall' physical entity."
  609.     ::= { entityPhysical 1 }
  610.  
  611. entPhysicalEntry       OBJECT-TYPE
  612.     SYNTAX      EntPhysicalEntry
  613.     MAX-ACCESS  not-accessible
  614.     STATUS      current
  615.  
  616.  
  617.  
  618. McCloghrie & Bierman        Standards Track                    [Page 11]
  619.  
  620. RFC 2037                 Entity MIB using SMIv2             October 1996
  621.  
  622.  
  623.     DESCRIPTION
  624.             "Information about a particular physical entity.
  625.  
  626.             Each entry provides objects (entPhysicalDescr,
  627.             entPhysicalVendorType, and entPhysicalClass) to help an NMS
  628.             identify and characterize the entry, and objects
  629.             (entPhysicalContainedIn and entPhysicalParentRelPos) to help
  630.             an NMS relate the particular entry to other entries in this
  631.             table."
  632.     INDEX   { entPhysicalIndex }
  633.     ::= { entPhysicalTable 1 }
  634.  
  635. EntPhysicalEntry ::= SEQUENCE {
  636.       entPhysicalIndex          PhysicalIndex,
  637.       entPhysicalDescr          DisplayString,
  638.       entPhysicalVendorType     AutonomousType,
  639.       entPhysicalContainedIn    INTEGER,
  640.       entPhysicalClass          PhysicalClass,
  641.       entPhysicalParentRelPos   INTEGER,
  642.       entPhysicalName           DisplayString
  643. }
  644.  
  645. entPhysicalIndex    OBJECT-TYPE
  646.     SYNTAX      PhysicalIndex
  647.     MAX-ACCESS  not-accessible
  648.     STATUS      current
  649.     DESCRIPTION
  650.             "The index for this entry."
  651.     ::= { entPhysicalEntry 1 }
  652.  
  653. entPhysicalDescr OBJECT-TYPE
  654.     SYNTAX      DisplayString
  655.     MAX-ACCESS  read-only
  656.     STATUS      current
  657.     DESCRIPTION
  658.             "A textual description of physical entity.  This object
  659.             should contain a string which identifies the manufacturer's
  660.             name for the physical entity, and should be set to a
  661.             distinct value for each version or model of the physical
  662.             entity. "
  663.     ::= { entPhysicalEntry 2 }
  664.  
  665. entPhysicalVendorType OBJECT-TYPE
  666.     SYNTAX      AutonomousType
  667.     MAX-ACCESS  read-only
  668.     STATUS      current
  669.     DESCRIPTION
  670.             "An indication of the vendor-specific hardware type of the
  671.  
  672.  
  673.  
  674. McCloghrie & Bierman        Standards Track                    [Page 12]
  675.  
  676. RFC 2037                 Entity MIB using SMIv2             October 1996
  677.  
  678.  
  679.             physical entity. Note that this is different from the
  680.             definition of MIB-II's sysObjectID.
  681.  
  682.             An agent should set this object to a enterprise-specific
  683.             registration identifier value indicating the specific
  684.             equipment type in detail.  The associated instance of
  685.             entPhysicalClass is used to indicate the general type of
  686.             hardware device.
  687.  
  688.             If no vendor-specific registration identifier exists for
  689.             this physical entity, or the value is unknown by this agent,
  690.             then the value { 0 0 } is returned."
  691.     ::= { entPhysicalEntry 3 }
  692.  
  693. entPhysicalContainedIn OBJECT-TYPE
  694.     SYNTAX      INTEGER (0..2147483647)
  695.     MAX-ACCESS  read-only
  696.     STATUS      current
  697.     DESCRIPTION
  698.             "The value of entPhysicalIndex for the physical entity which
  699.             'contains' this physical entity.  A value of zero indicates
  700.             this physical entity is not contained in any other physical
  701.             entity.  Note that the set of 'containment' relationships
  702.             define a strict hierarchy; that is, recursion is not
  703.             allowed."
  704.     ::= { entPhysicalEntry 4 }
  705.  
  706. entPhysicalClass OBJECT-TYPE
  707.     SYNTAX      PhysicalClass
  708.     MAX-ACCESS  read-only
  709.     STATUS      current
  710.     DESCRIPTION
  711.             "An indication of the general hardware type of the physical
  712.             entity.
  713.  
  714.             An agent should set this object to the standard enumeration
  715.             value which most accurately indicates the general class of
  716.             the physical entity, or the primary class if there is more
  717.             than one.
  718.  
  719.             If no appropriate standard registration identifier exists
  720.             for this physical entity, then the value 'other(1)' is
  721.             returned. If the value is unknown by this agent, then the
  722.             value 'unknown(2)' is returned."
  723.     ::= { entPhysicalEntry 5 }
  724.  
  725. entPhysicalParentRelPos OBJECT-TYPE
  726.     SYNTAX      INTEGER (-1..2147483647)
  727.  
  728.  
  729.  
  730. McCloghrie & Bierman        Standards Track                    [Page 13]
  731.  
  732. RFC 2037                 Entity MIB using SMIv2             October 1996
  733.  
  734.  
  735.     MAX-ACCESS  read-only
  736.     STATUS      current
  737.     DESCRIPTION
  738.             "An indication of the relative position of this 'child'
  739.             component among all its 'sibling' components. Sibling
  740.             components are defined as entPhysicalEntries which share the
  741.             same instance values of each of the entPhysicalContainedIn
  742.             and entPhysicalClass objects.
  743.  
  744.             An NMS can use this object to identify the relative ordering
  745.             for all sibling components of a particular parent
  746.             (identified by the entPhysicalContainedIn instance in each
  747.             sibling entry).
  748.  
  749.             This value should match any external labeling of the
  750.             physical component if possible. For example, for a module
  751.             labeled as 'card #3', entPhysicalParentRelPos should have
  752.             the value '3'.
  753.  
  754.             If the physical position of this component does not match
  755.             any external numbering or clearly visible ordering, then
  756.             user documentation or other external reference material
  757.             should be used to determine the parent-relative position. If
  758.             this is not possible, then the the agent should assign a
  759.             consistent (but possibly arbitrary) ordering to a given set
  760.             of 'sibling' components, perhaps based on internal
  761.             representation of the components.
  762.  
  763.             If the agent cannot determine the parent-relative position
  764.             for some reason, or if the associated value of
  765.             entPhysicalContainedIn is '0', then the value '-1' is
  766.             returned. Otherwise a non-negative integer is returned,
  767.             indicating the parent-relative position of this physical
  768.             entity.
  769.  
  770.             Parent-relative ordering normally starts from '1' and
  771.             continues to 'N', where 'N' represents the highest
  772.             positioned child entity.  However, if the physical entities
  773.             (e.g. slots) are labeled from a starting position of zero,
  774.             then the first sibling should be associated with a
  775.             entPhysicalParentRelPos value of '0'.  Note that this
  776.             ordering may be sparse or dense, depending on agent
  777.             implementation.
  778.  
  779.             The actual values returned are not globally meaningful, as
  780.             each 'parent' component may use different numbering
  781.             algorithms. The ordering is only meaningful among siblings
  782.             of the same parent component.
  783.  
  784.  
  785.  
  786. McCloghrie & Bierman        Standards Track                    [Page 14]
  787.  
  788. RFC 2037                 Entity MIB using SMIv2             October 1996
  789.  
  790.  
  791.             The agent should retain parent-relative position values
  792.             across reboots, either through algorithmic assignment or use
  793.             of non-volatile storage."
  794.     ::= { entPhysicalEntry 6 }
  795.  
  796.  
  797. entPhysicalName OBJECT-TYPE
  798.     SYNTAX      DisplayString
  799.     MAX-ACCESS  read-only
  800.     STATUS      current
  801.     DESCRIPTION
  802.             "The textual name of the physical entity.  The value of this
  803.             object should be the name of the component as assigned by
  804.             the local device and should be suitable for use in commands
  805.             entered at the device's `console'.  This might be a text
  806.             name, such as `console' or a simple component number (e.g.
  807.             port or module number), such as `1', depending on the
  808.             physical component naming syntax of the device.
  809.  
  810.             If there is no local name, or this object is otherwise not
  811.             applicable, then this object contains a zero-length string.
  812.  
  813.             Note that the value of entPhysicalName for two physical
  814.             entities will be the same in the event that the console
  815.             interface does not distinguish between them, e.g., slot-1
  816.             and the card in slot-1."
  817.     ::= { entPhysicalEntry 7 }
  818.  
  819. --           The Logical Entity Table
  820. entLogicalTable OBJECT-TYPE
  821.     SYNTAX      SEQUENCE OF EntLogicalEntry
  822.     MAX-ACCESS  not-accessible
  823.     STATUS      current
  824.     DESCRIPTION
  825.             "This table contains one row per logical entity.  At least
  826.             one entry must exist."
  827.     ::= { entityLogical 1 }
  828.  
  829. entLogicalEntry       OBJECT-TYPE
  830.     SYNTAX      EntLogicalEntry
  831.     MAX-ACCESS  not-accessible
  832.     STATUS      current
  833.     DESCRIPTION
  834.             "Information about a particular logical entity.  Entities
  835.             may be managed by this agent or other SNMP agents (possibly)
  836.             in the same chassis."
  837.     INDEX       { entLogicalIndex }
  838.     ::= { entLogicalTable 1 }
  839.  
  840.  
  841.  
  842. McCloghrie & Bierman        Standards Track                    [Page 15]
  843.  
  844. RFC 2037                 Entity MIB using SMIv2             October 1996
  845.  
  846.  
  847. EntLogicalEntry ::= SEQUENCE {
  848.       entLogicalIndex            INTEGER,
  849.       entLogicalDescr            DisplayString,
  850.       entLogicalType             AutonomousType,
  851.       entLogicalCommunity        OCTET STRING,
  852.       entLogicalTAddress         TAddress,
  853.       entLogicalTDomain          TDomain
  854. }
  855.  
  856. entLogicalIndex OBJECT-TYPE
  857.     SYNTAX      INTEGER (1..2147483647)
  858.     MAX-ACCESS  not-accessible
  859.     STATUS      current
  860.     DESCRIPTION
  861.             "The value of this object uniquely identifies the logical
  862.             entity. The value is a small positive integer; index values
  863.             for different logical entities are are not necessarily
  864.             contiguous."
  865.     ::= { entLogicalEntry 1 }
  866.  
  867. entLogicalDescr OBJECT-TYPE
  868.     SYNTAX      DisplayString
  869.     MAX-ACCESS  read-only
  870.     STATUS      current
  871.     DESCRIPTION
  872.             "A textual description of the logical entity.  This object
  873.             should contain a string which identifies the manufacturer's
  874.             name for the logical entity, and should be set to a distinct
  875.             value for each version of the logical entity. "
  876.     ::= { entLogicalEntry 2 }
  877.  
  878. entLogicalType OBJECT-TYPE
  879.     SYNTAX      AutonomousType
  880.     MAX-ACCESS  read-only
  881.     STATUS      current
  882.     DESCRIPTION
  883.             "An indication of the type of logical entity.  This will
  884.             typically be the OBJECT IDENTIFIER name of the node in the
  885.             SMI's naming hierarchy which represents the major MIB
  886.             module, or the majority of the MIB modules, supported by the
  887.             logical entity.  For example:
  888.                a logical entity of a regular host/router -> mib-2
  889.                a logical entity of a 802.1d bridge -> dot1dBridge
  890.                a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt
  891.             If an appropriate node in the SMI's naming hierarchy cannot
  892.             be identified, the value 'mib-2' should be used."
  893.     ::= { entLogicalEntry 3 }
  894.  
  895.  
  896.  
  897.  
  898. McCloghrie & Bierman        Standards Track                    [Page 16]
  899.  
  900. RFC 2037                 Entity MIB using SMIv2             October 1996
  901.  
  902.  
  903. entLogicalCommunity OBJECT-TYPE
  904.     SYNTAX      OCTET STRING (SIZE (1..255))
  905.     MAX-ACCESS  read-only
  906.     STATUS      current
  907.     DESCRIPTION
  908.             "An SNMPv1 or SNMPv2C community-string which can be used to
  909.             access detailed management information for this logical
  910.             entity.  The agent should allow read access with this
  911.             community string (to an appropriate subset of all managed
  912.             objects) and may also choose to return a community string
  913.             based on the privileges of the request used to read this
  914.             object.  Note that an agent may choose to return a community
  915.             string with read-only privileges, even if this object is
  916.             accessed with a read-write community string. However, the
  917.             agent must take care not to return a community string which
  918.             allows more privileges than the community string used to
  919.             access this object.
  920.  
  921.             A compliant SNMP agent may wish to conserve naming scopes by
  922.             representing multiple logical entities in a single 'main'
  923.             naming scope.  This is possible when the logical entities
  924.             represented by the same value of entLogicalCommunity have no
  925.             object instances in common.  For example, 'bridge1' and
  926.             'repeater1' may be part of the main naming scope, but at
  927.             least one additional community string is needed to represent
  928.             'bridge2' and 'repeater2'.
  929.  
  930.             Logical entities 'bridge1' and 'repeater1' would be
  931.             represented by sysOREntries associated with the 'main'
  932.             naming scope.
  933.  
  934.             For agents not accessible via SNMPv1 or SNMPv2C, the value
  935.             of this object is the empty-string."
  936.     ::= { entLogicalEntry 4 }
  937.  
  938. entLogicalTAddress OBJECT-TYPE
  939.     SYNTAX      TAddress
  940.     MAX-ACCESS  read-only
  941.     STATUS      current
  942.     DESCRIPTION
  943.             "The transport service address by which the logical entity
  944.             receives network management traffic, formatted according to
  945.             the corresponding value of entLogicalTDomain.
  946.  
  947.             For snmpUDPDomain, a TAddress is 6 octets long, the initial
  948.             4 octets containing the IP-address in network-byte order and
  949.             the last 2 containing the UDP port in network-byte order.
  950.             Consult 'Transport Mappings for Version 2 of the Simple
  951.  
  952.  
  953.  
  954. McCloghrie & Bierman        Standards Track                    [Page 17]
  955.  
  956. RFC 2037                 Entity MIB using SMIv2             October 1996
  957.  
  958.  
  959.             Network Management Protocol' (RFC 1906 [8]) for further
  960.             information on snmpUDPDomain."
  961.     ::= { entLogicalEntry 5 }
  962.  
  963. entLogicalTDomain OBJECT-TYPE
  964.     SYNTAX      TDomain
  965.     MAX-ACCESS  read-only
  966.     STATUS      current
  967.     DESCRIPTION
  968.             "Indicates the kind of transport service by which the
  969.             logical entity receives network management traffic.
  970.             Possible values for this object are presently found in the
  971.             Transport Mappings for SNMPv2 document (RFC 1906 [8])."
  972.     ::= { entLogicalEntry 6 }
  973.  
  974. entLPMappingTable OBJECT-TYPE
  975.     SYNTAX      SEQUENCE OF EntLPMappingEntry
  976.     MAX-ACCESS  not-accessible
  977.     STATUS      current
  978.     DESCRIPTION
  979.             "This table contains zero or more rows of logical entity to
  980.             physical equipment associations. For each logical entity
  981.             known by this agent, there are zero or more mappings to the
  982.             physical resources which are used to realize that logical
  983.             entity.
  984.  
  985.             An agent should limit the number and nature of entries in
  986.             this table such that only meaningful and non-redundant
  987.             information is returned. For example, in a system which
  988.             contains a single power supply, mappings between logical
  989.             entities and the power supply are not useful and should not
  990.             be included.
  991.  
  992.             Also, only the most appropriate physical component which is
  993.             closest to the root of a particular containment tree should
  994.             be identified in an entLPMapping entry.
  995.  
  996.             For example, suppose a bridge is realized on a particular
  997.             module, and all ports on that module are ports on this
  998.             bridge. A mapping between the bridge and the module would be
  999.             useful, but additional mappings between the bridge and each
  1000.             of the ports on that module would be redundant (since the
  1001.             entPhysicalContainedIn hierarchy can provide the same
  1002.             information). If, on the other hand, more than one bridge
  1003.             was utilizing ports on this module, then mappings between
  1004.             each bridge and the ports it used would be appropriate.
  1005.  
  1006.             Also, in the case of a single backplane repeater, a mapping
  1007.  
  1008.  
  1009.  
  1010. McCloghrie & Bierman        Standards Track                    [Page 18]
  1011.  
  1012. RFC 2037                 Entity MIB using SMIv2             October 1996
  1013.  
  1014.  
  1015.             for the backplane to the single repeater entity is not
  1016.             necessary."
  1017.     ::= { entityMapping 1 }
  1018.  
  1019. entLPMappingEntry       OBJECT-TYPE
  1020.     SYNTAX      EntLPMappingEntry
  1021.     MAX-ACCESS  not-accessible
  1022.     STATUS      current
  1023.     DESCRIPTION
  1024.             "Information about a particular logical entity to physical
  1025.             equipment association. Note that the nature of the
  1026.             association is not specifically identified in this entry. It
  1027.             is expected that sufficient information exists in the MIBs
  1028.             used to manage a particular logical entity to infer how
  1029.             physical component information is utilized."
  1030.     INDEX       { entLogicalIndex, entLPPhysicalIndex }
  1031.     ::= { entLPMappingTable 1 }
  1032.  
  1033. EntLPMappingEntry ::= SEQUENCE {
  1034.       entLPPhysicalIndex         PhysicalIndex
  1035. }
  1036.  
  1037. entLPPhysicalIndex OBJECT-TYPE
  1038.     SYNTAX      PhysicalIndex
  1039.     MAX-ACCESS  read-only
  1040.     STATUS      current
  1041.     DESCRIPTION
  1042.             "The value of this object identifies the index value of a
  1043.             particular entPhysicalEntry associated with the indicated
  1044.             entLogicalEntity."
  1045.     ::= { entLPMappingEntry 1 }
  1046.  
  1047. -- logical entity/component to alias table
  1048. entAliasMappingTable OBJECT-TYPE
  1049.     SYNTAX      SEQUENCE OF EntAliasMappingEntry
  1050.     MAX-ACCESS  not-accessible
  1051.     STATUS      current
  1052.     DESCRIPTION
  1053.             "This table contains zero or more rows, representing
  1054.             mappings of logical entity and physical component to
  1055.             external MIB identifiers.  Each physical port in the system
  1056.             may be associated with a mapping to an external identifier,
  1057.             which itself is associated with a particular logical
  1058.             entity's naming scope. A 'wildcard' mechanism is provided to
  1059.             indicate that an identifier is associated with more than one
  1060.             logical entity."
  1061.     ::= { entityMapping 2 }
  1062.  
  1063.  
  1064.  
  1065.  
  1066. McCloghrie & Bierman        Standards Track                    [Page 19]
  1067.  
  1068. RFC 2037                 Entity MIB using SMIv2             October 1996
  1069.  
  1070.  
  1071. entAliasMappingEntry       OBJECT-TYPE
  1072.     SYNTAX      EntAliasMappingEntry
  1073.     MAX-ACCESS  not-accessible
  1074.     STATUS      current
  1075.     DESCRIPTION
  1076.             "Information about a particular physical equipment, logical
  1077.             entity to external identifier binding. Each logical
  1078.             entity/physical component pair may be associated with one
  1079.             alias mapping.  The logical entity index may also be used as
  1080.             a 'wildcard' (refer to the entAliasLogicalIndexOrZero object
  1081.             DESCRIPTION clause for details.)
  1082.  
  1083.             Note that only entPhysicalIndex values which represent
  1084.             physical ports (i.e. associated entPhysicalClass value is
  1085.             'port(10)') are permitted to exist in this table."
  1086.     INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero }
  1087.     ::= { entAliasMappingTable 1 }
  1088.  
  1089. EntAliasMappingEntry ::= SEQUENCE {
  1090.       entAliasLogicalIndexOrZero        INTEGER,
  1091.       entAliasMappingIdentifier         RowPointer
  1092. }
  1093.  
  1094. entAliasLogicalIndexOrZero OBJECT-TYPE
  1095.     SYNTAX      INTEGER (0..2147483647)
  1096.     MAX-ACCESS  not-accessible
  1097.     STATUS      current
  1098.     DESCRIPTION
  1099.             "The value of this object uniquely identifies the logical
  1100.             entity which defines the naming scope for the associated
  1101.             instance of the 'entAliasMappingIdentifier' object.
  1102.  
  1103.             If this object has a non-zero value, then it identifies the
  1104.             logical entity named by the same value of entLogicalIndex.
  1105.  
  1106.             If this object has a value of zero, then the mapping between
  1107.             the physical component and the alias identifier for this
  1108.             entAliasMapping entry is associated with all unspecified
  1109.             logical entities. That is, a value of zero (the default
  1110.             mapping) identifies any logical entity which does not have
  1111.             an explicit entry in this table for a particular
  1112.             entPhysicalIndex/entAliasMappingIdentifier pair.
  1113.  
  1114.             For example, to indicate that a particular interface (e.g.
  1115.             physical component 33) is identified by the same value of
  1116.             ifIndex for all logical entities, the following instance
  1117.             might exist:
  1118.  
  1119.  
  1120.  
  1121.  
  1122. McCloghrie & Bierman        Standards Track                    [Page 20]
  1123.  
  1124. RFC 2037                 Entity MIB using SMIv2             October 1996
  1125.  
  1126.  
  1127.                     entAliasMappingIdentifier.33.0 = ifIndex.5
  1128.  
  1129.             In the event an entPhysicalEntry is associated differently
  1130.             for some logical entities, additional entAliasMapping
  1131.             entries may exist, e.g.:
  1132.  
  1133.                     entAliasMappingIdentifier.33.0 = ifIndex.6
  1134.                     entAliasMappingIdentifier.33.4 =  ifIndex.1
  1135.                     entAliasMappingIdentifier.33.5 =  ifIndex.1
  1136.                     entAliasMappingIdentifier.33.10 = ifIndex.12
  1137.  
  1138.             Note that entries with non-zero entAliasLogicalIndexOrZero
  1139.             index values have precedence over any zero-indexed entry. In
  1140.             this example, all logical entities except 4, 5, and 10,
  1141.             associate physical entity 33 with ifIndex.6."
  1142.     ::= { entAliasMappingEntry 1 }
  1143.  
  1144.  
  1145. entAliasMappingIdentifier OBJECT-TYPE
  1146.     SYNTAX      RowPointer
  1147.     MAX-ACCESS  read-only
  1148.     STATUS      current
  1149.     DESCRIPTION
  1150.             "The value of this object identifies a particular conceptual
  1151.             row associated with the indicated entPhysicalIndex and
  1152.             entLogicalIndex pair.
  1153.  
  1154.             Since only physical ports are modeled in this table, only
  1155.             entries which represent interfaces or ports are allowed.  If
  1156.             an ifEntry exists on behalf of a particular physical port,
  1157.             then this object should identify the associated 'ifEntry'.
  1158.             For repeater ports, the appropriate row in the
  1159.             'rptrPortGroupTable' should be identified instead.
  1160.  
  1161.             For example, suppose a physical port was represented by
  1162.             entPhysicalEntry.3, entLogicalEntry.15 existed for a
  1163.             repeater, and entLogicalEntry.22 existed for a bridge.  Then
  1164.             there might be two related instances of
  1165.             entAliasMappingIdentifier:
  1166.                entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2
  1167.                entAliasMappingIdentifier.3.22 == ifIndex.17
  1168.             It is possible that other mappings (besides interfaces and
  1169.             repeater ports) may be defined in the future, as required.
  1170.  
  1171.             Bridge ports are identified by examining the Bridge MIB and
  1172.             appropriate ifEntries associated with each 'dot1dBasePort',
  1173.             and are thus not represented in this table."
  1174.     ::= { entAliasMappingEntry 2 }
  1175.  
  1176.  
  1177.  
  1178. McCloghrie & Bierman        Standards Track                    [Page 21]
  1179.  
  1180. RFC 2037                 Entity MIB using SMIv2             October 1996
  1181.  
  1182.  
  1183. -- physical mapping table
  1184. entPhysicalContainsTable OBJECT-TYPE
  1185.     SYNTAX      SEQUENCE OF EntPhysicalContainsEntry
  1186.     MAX-ACCESS  not-accessible
  1187.     STATUS      current
  1188.     DESCRIPTION
  1189.             "A table which exposes the container/containee relationships
  1190.             between physical entities. This table provides equivalent
  1191.             information found by constructing the virtual containment
  1192.             tree for a given entPhysicalTable but in a more direct
  1193.             format."
  1194.     ::= { entityMapping 3 }
  1195.  
  1196. entPhysicalContainsEntry OBJECT-TYPE
  1197.     SYNTAX      EntPhysicalContainsEntry
  1198.     MAX-ACCESS  not-accessible
  1199.     STATUS      current
  1200.     DESCRIPTION
  1201.             "A single container/containee relationship."
  1202.     INDEX       { entPhysicalIndex, entPhysicalChildIndex }
  1203.     ::= { entPhysicalContainsTable 1 }
  1204.  
  1205. EntPhysicalContainsEntry ::= SEQUENCE {
  1206.       entPhysicalChildIndex     PhysicalIndex
  1207. }
  1208.  
  1209. entPhysicalChildIndex OBJECT-TYPE
  1210.     SYNTAX      PhysicalIndex
  1211.     MAX-ACCESS  read-only
  1212.     STATUS      current
  1213.     DESCRIPTION
  1214.             "The value of entPhysicalIndex for the contained physical
  1215.             entity."
  1216.     ::= { entPhysicalContainsEntry 1 }
  1217.  
  1218. -- last change time stamp for the whole MIB
  1219. entLastChangeTime OBJECT-TYPE
  1220.     SYNTAX      TimeStamp
  1221.     MAX-ACCESS  read-only
  1222.     STATUS      current
  1223.     DESCRIPTION
  1224.             "The value of sysUpTime at the time any of these events
  1225.             occur:
  1226.                 * a conceptual row is created or deleted in any
  1227.                   of these tables:
  1228.                     - entPhysicalTable
  1229.                     - entLogicalTable
  1230.                     - entLPMappingTable
  1231.  
  1232.  
  1233.  
  1234. McCloghrie & Bierman        Standards Track                    [Page 22]
  1235.  
  1236. RFC 2037                 Entity MIB using SMIv2             October 1996
  1237.  
  1238.  
  1239.                     - entAliasMappingTable
  1240.                     - entPhysicalContainsTable
  1241.  
  1242.                 * any instance in the following list of objects
  1243.                   changes value:
  1244.                     - entPhysicalDescr
  1245.                     - entPhysicalVendorType
  1246.                     - entPhysicalContainedIn
  1247.                     - entPhysicalClass
  1248.                     - entPhysicalParentRelPos
  1249.                     - entPhysicalName
  1250.                     - entLogicalDescr
  1251.                     - entLogicalType
  1252.                     - entLogicalCommunity
  1253.                     - entLogicalTAddress
  1254.                     - entLogicalTDomain
  1255.                     - entAliasMappingIdentifier "
  1256.     ::= { entityGeneral 1 }
  1257.  
  1258. -- Entity MIB Trap Definitions
  1259. entityMIBTraps      OBJECT IDENTIFIER ::= { entityMIB 2 }
  1260. entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 }
  1261.  
  1262. entConfigChange NOTIFICATION-TYPE
  1263.     STATUS             current
  1264.     DESCRIPTION
  1265.             "An entConfigChange trap is sent when the value of
  1266.             entLastChangeTime changes. It can be utilized by an NMS to
  1267.             trigger logical/physical entity table maintenance polls.
  1268.  
  1269.             An agent must not generate more than one entConfigChange
  1270.             'trap-event' in a five second period, where a 'trap-event'
  1271.             is the transmission of a single trap PDU to a list of trap
  1272.             destinations.  If additional configuration changes occur
  1273.             within the five second 'throttling' period, then these
  1274.             trap-events should be suppressed by the agent. An NMS should
  1275.             periodically check the value of entLastChangeTime to detect
  1276.             any missed entConfigChange trap-events, e.g. due to
  1277.             throttling or transmission loss."
  1278.    ::= { entityMIBTrapPrefix 1 }
  1279.  
  1280. -- conformance information
  1281. entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 }
  1282.  
  1283. entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 }
  1284. entityGroups      OBJECT IDENTIFIER ::= { entityConformance 2 }
  1285.  
  1286. -- compliance statements
  1287.  
  1288.  
  1289.  
  1290. McCloghrie & Bierman        Standards Track                    [Page 23]
  1291.  
  1292. RFC 2037                 Entity MIB using SMIv2             October 1996
  1293.  
  1294.  
  1295. entityCompliance MODULE-COMPLIANCE
  1296.     STATUS  current
  1297.     DESCRIPTION
  1298.             "The compliance statement for SNMP entities which implement
  1299.             the Entity MIB."
  1300.     MODULE  -- this module
  1301.         MANDATORY-GROUPS { entityPhysicalGroup,
  1302.                            entityLogicalGroup,
  1303.                            entityMappingGroup,
  1304.                            entityGeneralGroup,
  1305.                            entityNotificationsGroup }
  1306.     ::= { entityCompliances 1 }
  1307.  
  1308. -- MIB groupings
  1309.  
  1310. entityPhysicalGroup    OBJECT-GROUP
  1311.     OBJECTS {
  1312.               entPhysicalDescr,
  1313.               entPhysicalVendorType,
  1314.               entPhysicalContainedIn,
  1315.               entPhysicalClass,
  1316.               entPhysicalParentRelPos,
  1317.               entPhysicalName
  1318.             }
  1319.     STATUS  current
  1320.     DESCRIPTION
  1321.             "The collection of objects which are used to represent
  1322.             physical system components, for which a single agent
  1323.             provides management information."
  1324.     ::= { entityGroups 1 }
  1325.  
  1326. entityLogicalGroup    OBJECT-GROUP
  1327.     OBJECTS {
  1328.               entLogicalDescr,
  1329.               entLogicalType,
  1330.               entLogicalCommunity,
  1331.               entLogicalTAddress,
  1332.               entLogicalTDomain
  1333.             }
  1334.     STATUS  current
  1335.     DESCRIPTION
  1336.             "The collection of objects which are used to represent the
  1337.             list of logical entities for which a single agent provides
  1338.             management information."
  1339.     ::= { entityGroups 2 }
  1340.  
  1341. entityMappingGroup    OBJECT-GROUP
  1342.     OBJECTS {
  1343.  
  1344.  
  1345.  
  1346. McCloghrie & Bierman        Standards Track                    [Page 24]
  1347.  
  1348. RFC 2037                 Entity MIB using SMIv2             October 1996
  1349.  
  1350.  
  1351.               entLPPhysicalIndex,
  1352.               entAliasMappingIdentifier,
  1353.               entPhysicalChildIndex
  1354.             }
  1355.     STATUS  current
  1356.     DESCRIPTION
  1357.             "The collection of objects which are used to represent the
  1358.             associations between multiple logical entities, physical
  1359.             components, interfaces, and port identifiers for which a
  1360.             single agent provides management information."
  1361.     ::= { entityGroups 3 }
  1362.  
  1363. entityGeneralGroup    OBJECT-GROUP
  1364.     OBJECTS {
  1365.               entLastChangeTime
  1366.             }
  1367.     STATUS  current
  1368.     DESCRIPTION
  1369.             "The collection of objects which are used to represent
  1370.             general entity information for which a single agent provides
  1371.             management information."
  1372.     ::= { entityGroups 4 }
  1373.  
  1374. entityNotificationsGroup NOTIFICATION-GROUP
  1375.     NOTIFICATIONS { entConfigChange }
  1376.     STATUS        current
  1377.     DESCRIPTION
  1378.             "The collection of notifications used to indicate Entity MIB
  1379.             data consistency and general status information."
  1380.     ::= { entityGroups 5 }
  1381.  
  1382.  
  1383. END
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. McCloghrie & Bierman        Standards Track                    [Page 25]
  1403.  
  1404. RFC 2037                 Entity MIB using SMIv2             October 1996
  1405.  
  1406.  
  1407. 5.  Usage Examples
  1408.  
  1409.    The following sections iterate the instance values for two example
  1410.    networking devices. These examples are kept simple to make them more
  1411.    understandable. Auxiliary components, such as fans, sensors, empty
  1412.    slots, and sub-modules are not shown, but might be modeled in real
  1413.    implementations.
  1414.  
  1415. 5.1.  Router/Bridge
  1416.  
  1417.    A router containing two slots.  Each slot contains a 3 port
  1418.    router/bridge module. Each port is represented in the ifTable.  There
  1419.    are two logical instances of OSPF running and two logical bridges:
  1420.  
  1421.   Physical entities -- entPhysicalTable:
  1422.     1 Field-replaceable physical chassis:
  1423.       entPhysicalDescr.1 ==             "Acme Chassis Model 100"
  1424.       entPhysicalVendorType.1  ==       acmeProducts.chassisTypes.1
  1425.       entPhysicalContainedIn.1 ==       0
  1426.       entPhysicalClass.1 ==             chassis(3)
  1427.       entPhysicalParentRelPos.1 ==      0
  1428.       entPhysicalName.1 ==              '100-A'
  1429.  
  1430.     2 slots within the chassis:
  1431.       entPhysicalDescr.2 ==             "Acme Chassis Slot Type AA"
  1432.       entPhysicalVendorType.2  ==       acmeProducts.slotTypes.1
  1433.       entPhysicalContainedIn.2 ==       1
  1434.       entPhysicalClass.2 ==             container(5)
  1435.       entPhysicalParentRelPos.2 ==      1
  1436.       entPhysicalName.2 ==              'S1'
  1437.  
  1438.       entPhysicalDescr.3 ==             "Acme Chassis Slot Type AA"
  1439.       entPhysicalVendorType.3  ==       acmeProducts.slotTypes.1
  1440.       entPhysicalContainedIn.3 ==       1
  1441.       entPhysicalClass.3 ==             container(5)
  1442.       entPhysicalParentRelPos.3 ==      2
  1443.       entPhysicalName.3 ==              'S2'
  1444.  
  1445.     2 Field-replaceable modules:
  1446.     Slot 1 contains a module with 3 ports:
  1447.       entPhysicalDescr.4 ==             "Acme Router-100"
  1448.       entPhysicalVendorType.4  ==       acmeProducts.moduleTypes.14
  1449.       entPhysicalContainedIn.4 ==       2
  1450.       entPhysicalClass.4 ==             module(9)
  1451.       entPhysicalParentRelPos.4 ==      1
  1452.       entPhysicalName.4 ==              'M1'
  1453.  
  1454.       entPhysicalDescr.5 ==             "Acme Ethernet-100 Port Rev G"
  1455.  
  1456.  
  1457.  
  1458. McCloghrie & Bierman        Standards Track                    [Page 26]
  1459.  
  1460. RFC 2037                 Entity MIB using SMIv2             October 1996
  1461.  
  1462.  
  1463.       entPhysicalVendorType.5  ==       acmeProducts.portTypes.2
  1464.       entPhysicalContainedIn.5 ==       4
  1465.       entPhysicalClass.5 ==             port(10)
  1466.       entPhysicalParentRelPos.5 ==      1
  1467.       entPhysicalName.5 ==              'P1'
  1468.  
  1469.       entPhysicalDescr.6 ==             "Acme Ethernet-100 Port Rev G"
  1470.       entPhysicalVendorType.6  ==       acmeProducts.portTypes.2
  1471.       entPhysicalContainedIn.6 ==       4
  1472.       entPhysicalClass.6 ==             port(10)
  1473.       entPhysicalParentRelPos.6 ==      2
  1474.       entPhysicalName.6 ==              'P2'
  1475.  
  1476.       entPhysicalDescr.7 ==             "Acme Router-100 F-Port: Rev B"
  1477.       entPhysicalVendorType.7  ==       acmeProducts.portTypes.3
  1478.       entPhysicalContainedIn.7 ==       4
  1479.       entPhysicalClass.7 ==             port(10)
  1480.       entPhysicalParentRelPos.7 ==      3
  1481.       entPhysicalName.7 ==              'P3'
  1482.  
  1483.    Slot 2 contains another 3-port module:
  1484.       entPhysicalDescr.8 ==             "Acme Router-100 Comm Module: Rev C"
  1485.       entPhysicalVendorType.8  ==       acmeProducts.moduleTypes.15
  1486.       entPhysicalContainedIn.8 ==       3
  1487.       entPhysicalClass.8 ==             module(9)
  1488.       entPhysicalParentRelPos.8 ==      1
  1489.       entPhysicalName.8 ==              'M2'
  1490.  
  1491.       entPhysicalDescr.9 ==             "Acme Fddi-100 Port Rev CC"
  1492.       entPhysicalVendorType.9 ==        acmeProducts.portTypes.5
  1493.       entPhysicalContainedIn.9 ==       8
  1494.       entPhysicalClass.9 ==             port(10)
  1495.       entPhysicalParentRelPos.9 ==      1
  1496.       entPhysicalName.9 ==              'FDDI Primary'
  1497.  
  1498.       entPhysicalDescr.10 ==            "Acme Ethernet-100 Port Rev G"
  1499.       entPhysicalVendorType.10 ==       acmeProducts.portTypes.2
  1500.       entPhysicalContainedIn.10 ==      8
  1501.       entPhysicalClass.10 ==            port(10)
  1502.       entPhysicalParentRelPos.10 ==     2
  1503.       entPhysicalName.10 ==             'Ethernet A'
  1504.  
  1505.       entPhysicalDescr.11 ==            "Acme Ethernet-100 Port Rev G"
  1506.       entPhysicalVendorType.11 ==       acmeProducts.portTypes.2
  1507.       entPhysicalContainedIn.11 ==      8
  1508.       entPhysicalClass.11 ==            port(10)
  1509.       entPhysicalParentRelPos.11 ==     3
  1510.       entPhysicalName.11 ==             'Ethernet B'
  1511.  
  1512.  
  1513.  
  1514. McCloghrie & Bierman        Standards Track                    [Page 27]
  1515.  
  1516. RFC 2037                 Entity MIB using SMIv2             October 1996
  1517.  
  1518.  
  1519.    Logical entities -- entLogicalTable
  1520.     2 OSPF instances:
  1521.       entLogicalDescr.1 ==            "Acme OSPF v1.1"
  1522.       entLogicalType.1 ==             ospf
  1523.       entLogicalCommunity.1 ==        "public-ospf1"
  1524.       entLogicalTAddress.1 ==         124.125.126.127:161
  1525.       entLogicalTDomain.1 ==          snmpUDPDomain
  1526.  
  1527.       entLogicalDescr.2 ==            "Acme OSPF v1.1"
  1528.       entLogicalType.2 ==             ospf
  1529.       entLogicalCommunity.2 ==        "public-ospf2"
  1530.       entLogicalTAddress.2 ==         124.125.126.127:161
  1531.       entLogicalTDomain.2 ==          snmpUDPDomain
  1532.  
  1533.     2 logical bridges:
  1534.       entLogicalDescr.3 ==            "Acme Bridge v2.1.1"
  1535.       entLogicalType.3  ==            dod1dBridge
  1536.       entLogicalCommunity.3 ==        "public-bridge1"
  1537.       entLogicalTAddress.3 ==         124.125.126.127:161
  1538.       entLogicalTDomain.3 ==          snmpUDPDomain
  1539.  
  1540.       entLogicalDescr.4 ==            "Acme Bridge v2.1.1"
  1541.       entLogicalType.4 ==             dod1dBridge
  1542.       entLogicalCommunity.4 ==        "public-bridge2"
  1543.       entLogicalTAddress.4 ==         124.125.126.127:161
  1544.       entLogicalTDomain.4 ==          snmpUDPDomain
  1545.  
  1546. Logical to Physical Mappings:
  1547.   1st OSPF instance: uses module 1-port 1
  1548.       entLPPhysicalIndex.1.5 ==         5
  1549.  
  1550.   2nd OSPF instance: uses module 2-port 1
  1551.       entLPPhysicalIndex.2.9 ==         9
  1552.  
  1553.   1st bridge group: uses module 1, all ports
  1554.  
  1555.   [ed. -- Note that these mappings are included in the table since
  1556.   another logical entity (1st OSPF) utilizes one of the
  1557.   ports. If this were not the case, then a single mapping
  1558.   to the module (e.g. entLPPhysicalIndex.3.4) would be
  1559.   present instead. ]
  1560.       entLPPhysicalIndex.3.5 ==         5
  1561.       entLPPhysicalIndex.3.6 ==         6
  1562.       entLPPhysicalIndex.3.7 ==         7
  1563.  
  1564.   2nd bridge group: uses module 2, all ports
  1565.       entLPPhysicalIndex.4.9  ==        9
  1566.       entLPPhysicalIndex.4.10 ==        10
  1567.  
  1568.  
  1569.  
  1570. McCloghrie & Bierman        Standards Track                    [Page 28]
  1571.  
  1572. RFC 2037                 Entity MIB using SMIv2             October 1996
  1573.  
  1574.  
  1575.       entLPPhysicalIndex.4.11 ==        11
  1576.  
  1577. Physical to Logical to MIB Alias Mappings -- entAliasMappingTable:
  1578.   Example 1: ifIndex values are global to all logical entities
  1579.       entAliasMappingIdentifier.5.0   ==        ifIndex.1
  1580.       entAliasMappingIdentifier.6.0   ==        ifIndex.2
  1581.       entAliasMappingIdentifier.7.0   ==        ifIndex.3
  1582.       entAliasMappingIdentifier.9.0   ==        ifIndex.4
  1583.       entAliasMappingIdentifier.10.0  ==        ifIndex.5
  1584.       entAliasMappingIdentifier.11.0  ==        ifIndex.6
  1585.  
  1586.   Example 2: ifIndex values are not shared by all logical entities
  1587.       entAliasMappingIdentifier.5.0   ==        ifIndex.1
  1588.       entAliasMappingIdentifier.5.3   ==        ifIndex.101
  1589.       entAliasMappingIdentifier.6.0   ==        ifIndex.2
  1590.       entAliasMappingIdentifier.6.3   ==        ifIndex.102
  1591.       entAliasMappingIdentifier.7.0   ==        ifIndex.3
  1592.       entAliasMappingIdentifier.7.3   ==        ifIndex.103
  1593.       entAliasMappingIdentifier.9.0   ==        ifIndex.4
  1594.       entAliasMappingIdentifier.9.3   ==        ifIndex.204
  1595.       entAliasMappingIdentifier.10.0  ==        ifIndex.5
  1596.       entAliasMappingIdentifier.10.3  ==        ifIndex.205
  1597.       entAliasMappingIdentifier.11.0  ==        ifIndex.6
  1598.       entAliasMappingIdentifier.11.3  ==        ifIndex.206
  1599.  
  1600. Physical Containment Tree -- entPhysicalContainsTable
  1601.   chassis has two containers:
  1602.       entPhysicalChildIndex.1.2 = 2
  1603.       entPhysicalChildIndex.1.3 = 3
  1604.  
  1605.   container 1 has a module:
  1606.       entPhysicalChildIndex.2.4 = 4
  1607.  
  1608.   container 2 has a module:
  1609.       entPhysicalChildIndex.3.8 = 8
  1610.  
  1611.   module 1 has 3 ports:
  1612.       entPhysicalChildIndex.4.5 = 5
  1613.       entPhysicalChildIndex.4.6 = 6
  1614.       entPhysicalChildIndex.4.7 = 7
  1615.  
  1616.   module 2 has 3 ports:
  1617.       entPhysicalChildIndex.8.9 = 9
  1618.       entPhysicalChildIndex.8.10 = 10
  1619.       entPhysicalChildIndex.1.11 = 11
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. McCloghrie & Bierman        Standards Track                    [Page 29]
  1627.  
  1628. RFC 2037                 Entity MIB using SMIv2             October 1996
  1629.  
  1630.  
  1631. 5.2.  Repeaters
  1632.  
  1633.    A 3-slot Hub with 2 backplane ethernet segments.  Slot three is
  1634.    empty, and the remaining slots contain ethernet repeater modules.
  1635.    [ed. -- Note that a replacement for the current Repeater MIB (RFC
  1636.    1516) is likely to emerge soon, and it will no longer be necessary to
  1637.    access repeater MIB data in different naming scopes.]
  1638.  
  1639. Physical entities -- entPhysicalTable:
  1640.    1 Field-replaceable physical chassis:
  1641.       entPhysicalDescr.1 ==          "Acme Chassis Model 110"
  1642.       entPhysicalVendorType.1 ==     acmeProducts.chassisTypes.2
  1643.       entPhysicalContainedIn.1 ==    0
  1644.       entPhysicalClass.1 ==          chassis(3)
  1645.       entPhysicalParentRelPos.1 ==   0
  1646.       entPhysicalName.1 ==           '110-B'
  1647.  
  1648.    2 Chassis Ethernet Backplanes:
  1649.       entPhysicalDescr.2 ==          "Acme Ethernet Backplane Type A"
  1650.       entPhysicalVendorType.2 ==     acmeProducts.backplaneTypes.1
  1651.       entPhysicalContainedIn.2 ==    1
  1652.       entPhysicalClass.2 ==          backplane(4)
  1653.       entPhysicalParentRelPos.2 ==   1
  1654.       entPhysicalName.2 ==           'B1'
  1655.  
  1656.       entPhysicalDescr.3 ==          "Acme Ethernet Backplane Type A"
  1657.       entPhysicalVendorType.3  ==    acmeProducts.backplaneTypes.1
  1658.       entPhysicalContainedIn.3 ==    1
  1659.       entPhysicalClass.3 ==          backplane(4)
  1660.       entPhysicalParentRelPos.3 ==   2
  1661.       entPhysicalName.3 ==           'B2'
  1662.  
  1663.    3 slots within the chassis:
  1664.       entPhysicalDescr.4 ==          "Acme Hub Slot Type RB"
  1665.       entPhysicalVendorType.4  ==    acmeProducts.slotTypes.5
  1666.       entPhysicalContainedIn.4 ==    1
  1667.       entPhysicalClass.4 ==          container(5)
  1668.       entPhysicalParentRelPos.4 ==   1
  1669.       entPhysicalName.4 ==           'Slot 1'
  1670.  
  1671.       entPhysicalDescr.5 ==          "Acme Hub Slot Type RB"
  1672.       entPhysicalVendorType.5  ==    acmeProducts.slotTypes.5
  1673.       entPhysicalContainedIn.5 ==    1
  1674.       entPhysicalClass.5 ==          container(5)
  1675.       entPhysicalParentRelPos.5 ==   2
  1676.       entPhysicalName.5 ==           'Slot 2'
  1677.  
  1678.       entPhysicalDescr.6 ==          "Acme Hub Slot Type RB"
  1679.  
  1680.  
  1681.  
  1682. McCloghrie & Bierman        Standards Track                    [Page 30]
  1683.  
  1684. RFC 2037                 Entity MIB using SMIv2             October 1996
  1685.  
  1686.  
  1687.       entPhysicalVendorType.6  ==    acmeProducts.slotTypes.5
  1688.       entPhysicalContainedIn.6 ==    1
  1689.       entPhysicalClass.6 ==          container(5)
  1690.       entPhysicalParentRelPos.6 ==   3
  1691.       entPhysicalName.6 ==           'Slot 3'
  1692.  
  1693.    Slot 1 contains a plug-in module with 4 10-BaseT ports:
  1694.       entPhysicalDescr.7  ==         "Acme 10Base-T Module 114 Rev A"
  1695.       entPhysicalVendorType.7   ==   acmeProducts.moduleTypes.32
  1696.       entPhysicalContainedIn.7  ==   4
  1697.       entPhysicalClass.7 ==          module(9)
  1698.       entPhysicalParentRelPos.7 ==   1
  1699.       entPhysicalName.7 ==           'M1'
  1700.  
  1701.       entPhysicalDescr.8  ==         "Acme 10Base-T Port RB Rev A"
  1702.       entPhysicalVendorType.8   ==   acmeProducts.portTypes.10
  1703.       entPhysicalContainedIn.8  ==   7
  1704.       entPhysicalClass.8 ==          port(10)
  1705.       entPhysicalParentRelPos.8 ==   1
  1706.       entPhysicalName.8 ==           'Ethernet-A'
  1707.  
  1708.       entPhysicalDescr.9  ==         "Acme 10Base-T Port RB Rev A"
  1709.       entPhysicalVendorType.9   ==   acmeProducts.portTypes.10
  1710.       entPhysicalContainedIn.9  ==   7
  1711.       entPhysicalClass.9 ==          port(10)
  1712.       entPhysicalParentRelPos.9 ==   2
  1713.       entPhysicalName.9 ==           'Ethernet-B'
  1714.  
  1715.       entPhysicalDescr.10 ==         "Acme 10Base-T Port RB Rev B"
  1716.       entPhysicalVendorType.10  ==   acmeProducts.portTypes.10
  1717.       entPhysicalContainedIn.10 ==   7
  1718.       entPhysicalClass.10 ==         port(10)
  1719.       entPhysicalParentRelPos.10 ==  3
  1720.       entPhysicalName.10 ==          'Ethernet-C'
  1721.  
  1722.       entPhysicalDescr.11 ==         "Acme 10Base-T Port RB Rev B"
  1723.       entPhysicalVendorType.11  ==   acmeProducts.portTypes.10
  1724.       entPhysicalContainedIn.11 ==   7
  1725.       entPhysicalClass.11 ==         port(10)
  1726.       entPhysicalParentRelPos.11 ==  4
  1727.       entPhysicalName.11 ==          'Ethernet-D'
  1728.  
  1729.    Slot 2 contains another ethernet module with 2 ports.
  1730.       entPhysicalDescr.12 ==         "Acme 10Base-T Module Model 4 Rev A"
  1731.       entPhysicalVendorType.12 ==    acmeProducts.moduleTypes.30
  1732.       entPhysicalContainedIn.12 =    5
  1733.       entPhysicalClass.12 ==         module(9)
  1734.       entPhysicalParentRelPos.12 ==  1
  1735.  
  1736.  
  1737.  
  1738. McCloghrie & Bierman        Standards Track                    [Page 31]
  1739.  
  1740. RFC 2037                 Entity MIB using SMIv2             October 1996
  1741.  
  1742.  
  1743.       entPhysicalName.12 ==          'M2'
  1744.  
  1745.       entPhysicalDescr.13 ==         "Acme 802.3 AUI Port Rev A"
  1746.       entPhysicalVendorType.13  ==   acmeProducts.portTypes.11
  1747.       entPhysicalContainedIn.13 ==   12
  1748.       entPhysicalClass.13 ==         port(10)
  1749.       entPhysicalParentRelPos.13 ==  1
  1750.       entPhysicalName.13 ==          'AUI'
  1751.  
  1752.       entPhysicalDescr.14 ==         "Acme 10Base-T Port RD Rev B"
  1753.       entPhysicalVendorType.14  ==   acmeProducts.portTypes.14
  1754.       entPhysicalContainedIn.14 ==   12
  1755.       entPhysicalClass.14 ==         port(10)
  1756.       entPhysicalParentRelPos.14 ==  2
  1757.       entPhysicalName.14 ==          'E2'
  1758.  
  1759. Logical entities -- entLogicalTable
  1760.    Repeater 1--comprised of any ports attached to backplane 1
  1761.       entLogicalDescr.1 ==         "Acme repeater v3.1"
  1762.       entLogicalType.1  ==         snmpDot3RptrMgt
  1763.       entLogicalCommunity.1        "public-repeater1"
  1764.       entLogicalTAddress.1 ==      124.125.126.127:161
  1765.       entLogicalTDomain.1 ==       snmpUDPDomain
  1766.  
  1767.    Repeater 2--comprised of any ports attached to backplane 2:
  1768.       entLogicalDescr.2 ==         "Acme repeater v3.1"
  1769.       entLogicalType.2  ==         snmpDot3RptrMgt
  1770.       entLogicalCommunity.2 ==     "public-repeater2"
  1771.       entLogicalTAddress.2 ==      124.125.126.127:161
  1772.       entLogicalTDomain.2 ==       snmpUDPDomain
  1773.  
  1774. Logical to Physical Mappings -- entLPMappingTable:
  1775.  
  1776.   repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1
  1777.   [ed. -- Note that a mapping to the module is not included,
  1778.    since in this example represents a port-switchable hub.
  1779.    Even though all ports on the module could belong to the
  1780.    same repeater as a matter of configuration, the LP port
  1781.    mappings should not be replaced dynamically with a single
  1782.    mapping for the module (e.g. entLPPhysicalIndex.1.7).
  1783.    If all ports on the module shared a single backplane connection,
  1784.    then a single mapping for the module would be more appropriate. ]
  1785.  
  1786.      entLPPhysicalIndex.1.2 ==          2
  1787.      entLPPhysicalIndex.1.8 ==          8
  1788.      entLPPhysicalIndex.1.9 ==          9
  1789.      entLPPhysicalIndex.1.13 ==         13
  1790.  
  1791.  
  1792.  
  1793.  
  1794. McCloghrie & Bierman        Standards Track                    [Page 32]
  1795.  
  1796. RFC 2037                 Entity MIB using SMIv2             October 1996
  1797.  
  1798.  
  1799.   repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2
  1800.       entLPPhysicalIndex.2.3 ==         3
  1801.       entLPPhysicalIndex.2.10 ==        10
  1802.       entLPPhysicalIndex.2.11 ==        11
  1803.       entLPPhysicalIndex.2.14 ==        14
  1804.  
  1805. Physical to Logical to MIB Alias Mappings -- entAliasMappingTable:
  1806.   Repeater Port Identifier values are shared by both repeaters:
  1807.       entAliasMappingIdentifier.8.0 ==  rptrPortGroupIndex.1.1
  1808.       entAliasMappingIdentifier.9.0 ==  rptrPortGroupIndex.1.2
  1809.       entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3
  1810.       entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4
  1811.       entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1
  1812.       entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2
  1813.  
  1814. Physical Containment Tree -- entPhysicalContainsTable
  1815.   chassis has two backplanes and three containers:
  1816.       entPhysicalChildIndex.1.2 = 2
  1817.       entPhysicalChildIndex.1.3 = 3
  1818.       entPhysicalChildIndex.1.4 = 4
  1819.       entPhysicalChildIndex.1.5 = 5
  1820.       entPhysicalChildIndex.1.6 = 6
  1821.  
  1822.   container 1 has a module:
  1823.       entPhysicalChildIndex.4.7 = 7
  1824.  
  1825.   container 2 has a module
  1826.       entPhysicalChildIndex.5.12 = 12
  1827.   [ed. - in this example, container 3 is empty.]
  1828.  
  1829.   module 1 has 4 ports:
  1830.       entPhysicalChildIndex.7.8 = 8
  1831.       entPhysicalChildIndex.7.9 = 9
  1832.       entPhysicalChildIndex.7.10 = 10
  1833.       entPhysicalChildIndex.7.11 = 11
  1834.  
  1835.   module 2 has 2 ports:
  1836.       entPhysicalChildIndex.12.13 = 13
  1837.       entPhysicalChildIndex.12.14 = 14
  1838.  
  1839. 6.  Acknowledgements
  1840.  
  1841.    This document was produced by the IETF Entity MIB Working Group.
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. McCloghrie & Bierman        Standards Track                    [Page 33]
  1851.  
  1852. RFC 2037                 Entity MIB using SMIv2             October 1996
  1853.  
  1854.  
  1855. 7.  References
  1856.  
  1857. [1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1858.      S. Waldbusser, "Structure of Management Information for version 2
  1859.      of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
  1860.      January 1996.
  1861.  
  1862. [2]  McCloghrie, K., and M. Rose, Editors, "Management Information Base
  1863.      for Network Management of TCP/IP-based internets: MIB-II", STD 17,
  1864.      RFC 1213, Hughes LAN Systems, Performance Systems International,
  1865.      March 1991.
  1866.  
  1867. [3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1868.      S. Waldbusser, "Textual Conventions for version 2 of the Simple
  1869.      Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
  1870.  
  1871. [4]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1872.      S. Waldbusser, "Protocol Operations for version 2 of the Simple
  1873.      Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
  1874.  
  1875. [5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1876.      S. Waldbusser, "Conformance Statements for version 2 of the Simple
  1877.      Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
  1878.  
  1879. [6]  Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
  1880.      Management Protocol", RFC 1157, SNMP Research, Performance Systems
  1881.      International, MIT Laboratory for Computer Science, May 1990.
  1882.  
  1883. [7]  McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution",
  1884.      RFC 1573, Hughes LAN Systems, FTP Software, January 1994.
  1885.  
  1886. [8]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1887.      S. Waldbusser, "Transport Mappings for version 2 of the Simple
  1888.      Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
  1889.  
  1890. [9]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1891.      S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901,
  1892.      January 1996.
  1893.  
  1894.  
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906. McCloghrie & Bierman        Standards Track                    [Page 34]
  1907.  
  1908. RFC 2037                 Entity MIB using SMIv2             October 1996
  1909.  
  1910.  
  1911. 8.  Security Considerations
  1912.  
  1913.    In order to implement this MIB, an agent must make certain management
  1914.    information available about various logical and physical entities
  1915.    within a managed system, which may be considered sensitive in some
  1916.    network environments.
  1917.  
  1918.    Therefore, a network administrator may wish to employ instance-level
  1919.    access control, and configure the Entity MIB access (i.e., community
  1920.    strings in SNMPv1 and SNMPv2C), such that certain instances within
  1921.    this MIB (e.g., entLogicalCommunity, or entire entLogicalEntries,
  1922.    entPhysicalEntries, and associated mapping table entries), are
  1923.    excluded from particular MIB views.
  1924.  
  1925. 9.  Authors' Addresses
  1926.  
  1927.    Keith McCloghrie
  1928.    Cisco Systems, Inc.
  1929.    170 West Tasman Drive
  1930.    San Jose, CA 95134
  1931.  
  1932.    Phone: 408-526-5260
  1933.    EMail: kzm@cisco.com
  1934.  
  1935.  
  1936.    Andy Bierman
  1937.    Cisco Systems, Inc.
  1938.    170 West Tasman Drive
  1939.    San Jose, CA 95134
  1940.  
  1941.    Phone: 408-527-3711
  1942.    EMail: abierman@cisco.com
  1943.  
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950.  
  1951.  
  1952.  
  1953.  
  1954.  
  1955.  
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. McCloghrie & Bierman        Standards Track                    [Page 35]
  1963.  
  1964.