As per Relevance of the word entities, we have this rfc below:
Network Working Group K.
Request for Comments: 2737 Cisco Systems, Inc
Obsoletes: 2037 A.
Cisco Systems, Inc
December 1999
Entity MIB (Version 2)
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This memo defines a portion of the Management Information Base (MIB
for use with network management protocols in the Internet community
In particular, it describes managed objects used for
multiple logical and physical entities managed by a single
agent
Table of
1 The SNMP Management Framework ............................... 2
2 Overview .................................................... 3
2.1 Terms ..................................................... 4
2.2 Relationship to Community Strings ......................... 5
2.3 Relationship to SNMP Contexts ............................. 5
2.4 Relationship to Proxy Mechanisms .......................... 6
2.5 Relationship to a Chassis MIB ............................. 6
2.6 Relationship to the Interfaces MIB ........................ 6
2.7 Relationship to the Other MIBs ............................ 7
2.8 Relationship to Naming Scopes ............................. 7
2.9 Multiple Instances of the Entity MIB ...................... 7
2.10 Re-Configuration of Entities ............................. 8
2.11 Textual Convention Change ................................ 8
2.12 MIB Structure ............................................ 8
2.12.1 entityPhysical Group ................................... 9
2.12.2 entityLogical Group .................................... 10
2.12.3 entityMapping Group .................................... 10
McCloghrie & Bierman Standards Track [Page 1]
RFC 2737 Entity MIB (Version 2) December 1999
2.12.4 entityGeneral Group .................................... 11
2.12.5 entityNotifications Group .............................. 11
2.13 Multiple Agents .......................................... 11
2.14 Changes Since RFC 2037 ................................... 11
2.14.1 Textual Conventions .................................... 11
2.14.2 New entPhysicalTable Objects ........................... 12
2.14.3 New entLogicalTable Objects ............................ 12
2.14.4 Bugfixes ............................................... 12
3 Definitions ................................................. 13
4 Usage Examples .............................................. 38
4.1 Router/Bridge ............................................. 38
4.2 Repeaters ................................................. 44
5 Intellectual Property ....................................... 51
6 Acknowledgements ............................................ 51
7 References .................................................. 51
8 Security Considerations ..................................... 53
9 Authors' Addresses .......................................... 55
10 Full Copyright Statement ................................... 56
1. The SNMP Management
The SNMP Management Framework presently consists of five
components
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for
purpose of management. The first version of this Structure
Management Information (SMI) is called SMIv1 and described in
16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
[RFC1215]. The second version, called SMIv2, is described in
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,
2580 [RFC2580].
o Message protocols for transferring management information.
first version of the SNMP message protocol is called SNMPv1
described in STD 15, RFC 1157 [RFC1157]. A second version of
SNMP message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
and RFC 1906 [RFC1906]. The third version of the message
is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572
[RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in STD 15, RFC 1157 [RFC1157]. A second set of
operations and associated PDU formats is described in RFC 1905
[RFC1905].
McCloghrie & Bierman Standards Track [Page 2]
RFC 2737 Entity MIB (Version 2) December 1999
o A set of fundamental applications described in RFC 2573 [RFC2573]
and the view-based access control mechanism described in RFC 2575
[RFC2575].
A more detailed introduction to the current SNMP Management
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI
This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
translation is possible (use of Counter64). Some machine
information in SMIv2 will be converted into textual descriptions
SMIv1 during the translation process. However, this loss of
readable information is not considered to change the semantics of
MIB
2.
There is a need for a standardized way of representing a single
which supports multiple instances of one MIB. This is presently
for at least 3 standard MIBs, and is likely to become true for
and more MIBs as time passes. For example
- multiple instances of a bridge supported within a single
having a single agent
- multiple repeaters supported by a single agent
- multiple OSPF backbone areas, each one operating as part of
own Autonomous System, and each identified by the same area-
(e.g., 0.0.0.0), supported inside a single router with
agent
The fact that it is a single agent in each of these cases
there is some relationship which binds all of these
together. Effectively, there is some "overall" physical entity
houses the sum of the things managed by that one agent, i.e.,
are multiple "logical" entities within a single physical entity
Sometimes, the overall physical entity contains multiple (smaller
physical entities and each logical entity is associated with
particular physical entity. Sometimes, the overall physical
is a "compound" of multiple physical entities (e.g., a stack
stackable hubs).
McCloghrie & Bierman Standards Track [Page 3]
RFC 2737 Entity MIB (Version 2) December 1999
What is needed is a way to determine exactly what logical
are managed by the agent (with some version of SNMP), and thereby
be able to communicate with the agent about a particular
entity. When different logical entities are associated
different physical entities within the overall physical entity, it
also useful to be able to use this information to distinguish
logical entities
In these situations, there is no need for varbinds for
logical entities to be referenced in the same SNMP message (
that might be useful in the future). Rather, it is sufficient,
in some situations preferable, to have the context/community in
message identify the logical entity to which the varbinds apply
Version 2 of this MIB addresses new requirements that have
since the publication of the first Entity MIB (RFC 2037 [RFC2037]).
There is a need for a standardized way of providing non-volatile
administratively assigned identifiers for physical
represented with the Entity MIB. There is also a need to align
Entity MIB with the SNMPv3 administrative framework (RFC 2571
[RFC2571]). Implementation experience has shown that
physical component attributes are also desirable
2.1.
Some new terms are used throughout this document
- Naming
A "naming scope" represents the set of information that may
potentially accessed through a single SNMP operation.
instances within the naming scope share the same
identifier space. For SNMPv1, a naming scope is identified
the value of the associated 'entLogicalCommunity' instance.
SNMPv3, the term 'context' is used instead of 'naming scope'.
The complete definition of an SNMP context can be found
section 3.3.1 of RFC 2571 [RFC2571].
- Multi-Scoped
A MIB object, for which identical instance values
different managed information in different naming scopes,
called a "multi-scoped" MIB object
- Single-Scoped
A MIB object, for which identical instance values identify
same managed information in different naming scopes, is called
"single-scoped" MIB object
McCloghrie & Bierman Standards Track [Page 4]
RFC 2737 Entity MIB (Version 2) December 1999
- Logical
A managed system contains one or more logical entities,
represented by at most one instantiation of each of a
set of MIB objects. A set of management functions is
with each logical entity. Examples of logical entities
routers, bridges, print-servers, etc
- Physical
A "physical entity" or "physical component" represents
identifiable physical resource within a managed system. Zero
more logical entities may utilize a physical resource at
given time. It is an implementation-specific manner as to
physical components are represented by an agent in
EntPhysicalTable. Typically, physical resources (e.g.,
communications ports, backplanes, sensors, daughter-cards,
supplies, the overall chassis) which can be managed
functions associated with one or more logical entities
included in the MIB
- Containment
Each physical component may be modeled as 'contained'
another physical component. A "containment-tree" is
conceptual sequence of entPhysicalIndex values which
specifies the exact physical location of a physical
within the managed system. It is generated by 'following
recording' each 'entPhysicalContainedIn' instance 'up the
towards the root', until a value of zero indicating no
containment is found
2.2. Relationship to Community
For community-based SNMP, distinguishing between different
entities is one (but not the only) purpose of the community
(STD 15, RFC 1157 [RFC1157]). This is accommodated by
each community string as a logical entity
Note that different logical entities may share the same naming
(and therefore the same values of entLogicalCommunity). This
possible, providing they have no need for the same instance of a
object to represent different managed information
2.3. Relationship to SNMP
Version 2 of the Entity MIB contains support for associating SNMPv
contexts with logical entities. Two new MIB objects, defining
SnmpEngineID and ContextName pair, are used together to identify
SNMP context associated with a logical entity. This context can
McCloghrie & Bierman Standards Track [Page 5]
RFC 2737 Entity MIB (Version 2) December 1999
used (in conjunction with the entLogicalTAddress
entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of
particular logical entity
2.4. Relationship to Proxy
The Entity MIB is designed to allow functional component discovery
The administrative relationships between different logical
are not visible in any Entity MIB tables. An NMS cannot
whether MIB instances in different naming scopes are realized
or remotely (e.g., via some proxy mechanism) by examining
particular Entity MIB objects
The management of administrative framework functions is not
explicit goal of the Entity MIB WG at this time. This new area
functionality may be revisited after some operational experience
the Entity MIB is gained
Note that for community-based versions of SNMP, a
administrator will likely be able to associate community strings
naming scopes with proprietary mechanisms, as a matter
configuration. There are no mechanisms for managing naming
defined in this MIB
2.5. Relationship to a Chassis
Some readers may recall that a previous IETF working group
to define a Chassis MIB. No consensus was reached by that
group, possibly because its scope was too broad. As such, it is
the purpose of this MIB to be a "Chassis MIB replacement", nor is
within the scope of this MIB to contain all the information
might be necessary to manage a "chassis". On the other hand,
entities represented by an implementation of this MIB might well
contained in a chassis
2.6. Relationship to the Interfaces
The Entity MIB contains a mapping table identifying
components that have 'external values' (e.g., ifIndex)
with them within a given naming scope. This table can be used
identify the physical location of each interface in the ifTable (
2233 [RFC2233]). Since ifIndex values in different contexts are
related to one another, the interface to physical
associations are relative to the same logical entity within
agent
McCloghrie & Bierman Standards Track [Page 6]
RFC 2737 Entity MIB (Version 2) December 1999
The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias
objects, which approximate the semantics of the 'ifName' and '
ifAlias' objects (respectively) from the Interfaces MIB [RFC2233],
for all types of physical components
2.7. Relationship to the Other
The Entity MIB contains a mapping table identifying
components that have identifiers from other standard MIBs
with them. For example, this table can be used along with
physical mapping table to identify the physical location of
repeater port in the rptrPortTable, or each interface in the ifTable
2.8. Relationship to Naming
There is some question as to which MIB objects may be returned
a given naming scope. MIB objects which are not multi-scoped within
managed system are likely to ignore context information
implementation. In such a case, it is likely such objects will
returned in all naming scopes (e.g., not just the 'default'
scope or the SNMPv3 default context).
For example, a community string used to access the
information for logical device 'bridge2' may allow access to all
non-bridge related objects in the 'default' naming scope, as well
a second instance of the Bridge MIB (RFC 1493 [RFC1493]).
It is an implementation-specific matter as to the isolation
single-scoped MIB objects by the agent. An agent may wish to
the objects returned in a particular naming scope to just the multi
scoped objects in that naming scope (e.g., system group and
Bridge MIB). In this case, all single-scoped management
would belong to a common naming scope (e.g., 'default'), which
may contain some multi-scoped objects (e.g., system group).
2.9. Multiple Instances of the Entity
It is possible that more than one agent exists in a managed system
and in such cases, multiple instances of the Entity MIB (
the same managed objects) may be available to an NMS
In order to reduce complexity for agent implementation,
instances of the Entity MIB are not required to be equivalent or
consistent. An NMS may be able to 'align' instances returned
different agents by examining the columns of each table, but vendor
specific identifiers and (especially) index values are likely to
different. Each agent may be managing different subsets of the
chassis as well
McCloghrie & Bierman Standards Track [Page 7]
RFC 2737 Entity MIB (Version 2) December 1999
When all of a physically-modular device is represented by a
agent, the entry for which entPhysicalContainedIn has the value
would likely have 'chassis' as the value of its entPhysicalClass
alternatively, for an agent on a module where the agent
only the physical entities on that module (not those on
modules), the entry for which entPhysicalContainedIn has the
zero would likely have 'module' as the value of its entPhysicalClass
An agent implementation of the entLogicalTable is not required
contain information about logical entities managed primarily by
agents. That is, the entLogicalTAddress and entLogicalTDomain
in the entLogicalTable are provided to support an
multiplexing mechanism, not to identify other SNMP agents
Note that the Entity MIB is a single-scoped MIB, in the event
agent represents the MIB in different naming scopes
2.10. Re-Configuration of
Most of the MIB objects defined in this MIB have at most a read-
MAX-ACCESS clause. This is a conscious decision by the working
to limit this MIB's scope. The second version of the Entity
allows a network administrator to configure some common attributes
physical components
2.11. Textual Convention
Version 1 of the Entity MIB contains three MIB objects defined
the (now obsolete) DisplayString textual convention. In version 2
the Entity MIB, the syntax for these objects has been updated to
the (now preferred) SnmpAdminString textual convention
The working group realizes that this change is not strictly
by SMIv2. In our judgment, the alternative of deprecating the
objects and defining new objects would have a more adverse impact
backward compatibility and interoperability, given the
semantics of these objects
2.12. MIB
The Entity MIB contains five groups of MIB objects
- entityPhysical
Describes the physical entities managed by a single agent
- entityLogical
Describes the logical entities managed by a single agent
McCloghrie & Bierman Standards Track [Page 8]
RFC 2737 Entity MIB (Version 2) December 1999
- entityMapping
Describes the associations between the physical entities
logical entities, interfaces, and non-interface ports managed
a single agent
- entityGeneral
Describes general system attributes shared by potentially
types of entities managed by a single agent
- entityNotifications
Contains status indication notifications
2.12.1. entityPhysical
This group contains a single table to identify physical
components, called the entPhysicalTable
The entPhysicalTable contains one row per physical entity, and
always contain at least one row for an "overall" physical entity
which should have an entPhysicalClass value of 'stack(11)', '
chassis(3)' or 'module(9)'.
Each row is indexed by an arbitrary, small integer, and contains
description and type of the physical entity. It also
contains the index number of another entPhysicalEntry indicating
containment relationship between the two
Version 2 of the Entity MIB provides additional MIB objects for
physical entity. Some common read-only attributes have been added,
well as three writable string objects
-
This string can be used by an NMS as a non-volatile
for the physical component. Maintaining a non-volatile
for every physical component represented in the
can be costly and unnecessary. An agent may
generate 'entPhysicalAlias' strings for particular
(e.g., based on the entPhysicalClass value).
-
This string is provided to store a user-specific
identifier for removable physical components. In order
reduce the non-volatile storage needed by a particular agent,
network administrator should only assign asset identifiers
physical entities which are field-replaceable (i.e.,
permanently contained within another physical entity).
McCloghrie & Bierman Standards Track [Page 9]
RFC 2737 Entity MIB (Version 2) December 1999
-
This string is provided to store a vendor-specific serial
string for physical components. This is a writable object
case an agent cannot identify the serial numbers of
installed physical entities, and a network administrator
to configure the non-volatile serial number strings
(via an NMS application).
2.12.2. entityLogical
This group contains a single table to identify logical entities
called the entLogicalTable
The entLogicalTable contains one row per logical entity. Each row
indexed by an arbitrary, small integer and contains a name
description, and type of the logical entity. It also
information to allow access to the MIB information for the
entity. This includes SNMP versions that use a community name (
some form of implied context representation) and SNMP versions
use the SNMP ARCH [RFC2571] method of context identification
If a agent represents multiple logical entities with this MIB,
this group must be implemented for all logical entities known to
agent
If an agent represents a single logical entity, or multiple
entities within a single naming scope, then implementation of
group may be omitted by the agent
2.12.3. entityMapping
This group contains three tables to identify associations
different system components
The entLPMappingTable contains mappings between
values (logical entities) and entPhysicalIndex values (the
components supporting that entity). A logical entity can map to
than one physical component, and more than one logical entity can
to (share) the same physical component. If an agent represents
single logical entity, or multiple logical entities within a
naming scope, then implementation of this table may be omitted by
agent
The entAliasMappingTable contains mappings between entLogicalIndex
entPhysicalIndex pairs and 'alias' object identifier values.
allows resources managed with other MIBs (e.g., repeater ports
bridge ports, physical and logical interfaces) to be identified
the physical entity hierarchy. Note that each alias identifier
McCloghrie & Bierman Standards Track [Page 10]
RFC 2737 Entity MIB (Version 2) December 1999
only relevant in a particular naming scope. If an agent represents
single logical entity, or multiple logical entities within a
naming scope, then implementation of this table may be omitted by
agent
The entPhysicalContainsTable contains simple mappings
'entPhysicalContainedIn' values for each container/'containee
relationship in the managed system. The indexing of this table
an NMS to quickly discover the 'entPhysicalIndex' values for
children of a given physical entity
2.12.4. entityGeneral
This group contains general information relating to the other
groups
At this time, the entGeneral group contains a single scalar
(entLastChangeTime), which represents the value of sysUptime when
part of the Entity MIB configuration last changed
2.12.5. entityNotifications
This group contains notification definitions relating to the
status of the Entity MIB instantiation
2.13. Multiple
Even though a primary motivation for this MIB is to represent
multiple logical entities supported by a single agent, it is
possible to use it to represent multiple logical entities
by multiple agents (in the same "overall" physical entity). Indeed
it is implicit in the SNMP architecture, that the number of agents
transparent to a network management station
However, there is no agreement at this time as to the degree
cooperation which should be expected for agent implementations
Therefore, multiple agents within the same managed system are free
implement the Entity MIB independently. (Refer the section
"Multiple Instances of the Entity MIB" for more details).
2.14. Changes Since RFC 2037
2.14.1. Textual
The PhysicalClass TC text has been clarified, and a new
to support 'stackable' components has been added.
SnmpEngineIdOrNone TC has been added to support SNMPv3.
McCloghrie & Bierman Standards Track [Page 11]
RFC 2737 Entity MIB (Version 2) December 1999
2.14.2. New entPhysicalTable
The entPhysicalHardwareRev, entPhysicalFirmwareRev,
entPhysicalSoftwareRev objects have been added for
identification
The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName
and entPhysicalIsFru objects have been added for better
identification for physical components. The
object can be set by a management station in the event the
cannot identify this information
The entPhysicalAlias and entPhysicalAssetID objects have been
for better user component identification. These objects are
to be set by a management station and preserved by the agent
restarts
2.14.3. New entLogicalTable
The entLogicalContextEngineID and entLogicalContextName objects
been added to provide an SNMP context for SNMPv3 access on behalf
a logical entity
2.14.4.
A bug was fixed in the entLogicalCommunity object. The subrange
incorrect (1..255) and is now (0..255). The description clause
also been clarified. This object is now deprecated
The entLastChangeTime object description has been changed
generalize the events which cause an update to the last
timestamp
The syntax was changed from DisplayString to SnmpAdminString for
entPhysicalDescr, entPhysicalName, and entLogicalDescr objects
McCloghrie & Bierman Standards Track [Page 12]
RFC 2737 Entity MIB (Version 2) December 1999
3.
ENTITY-MIB DEFINITIONS ::=
MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-
FROM SNMPv2-
TDomain, TAddress, TEXTUAL-CONVENTION
AutonomousType, RowPointer, TimeStamp,
FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-
FROM SNMPv2-
FROM SNMP-FRAMEWORK-MIB
entityMIB MODULE-
LAST-UPDATED "9912070000Z" -- December 7, 1999
ORGANIZATION "IETF ENTMIB Working Group
CONTACT-
" WG E-mail: entmib@cisco.
Subscribe: majordomo@cisco.
msg body: subscribe
Keith
ENTMIB Working Group
Cisco Systems Inc
170 West Tasman
San Jose, CA 95134
+1 408-526-5260
kzm@cisco.
Andy
ENTMIB Working Group
Cisco Systems Inc
170 West Tasman
San Jose, CA 95134
+1 408-527-3711
abierman@cisco.com
"The MIB module for representing multiple
entities supported by a single SNMP agent."
REVISION "9912070000Z
"Initial Version of Entity MIB (Version 2).
This revision obsoletes RFC 2037.
This version published as RFC 2737."
REVISION "9610310000Z
McCloghrie & Bierman Standards Track [Page 13]
RFC 2737 Entity MIB (Version 2) December 1999
"Initial version (version 1), published
RFC 2037."
::= { mib-2 47 }
entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 }
-- MIB contains four
entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 }
entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 }
entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 }
entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 }
-- Textual
PhysicalIndex ::= TEXTUAL-
STATUS
"An arbitrary value which uniquely identifies the
entity. The value should be a small positive integer;
values for different physical entities are not
contiguous."
SYNTAX INTEGER (1..2147483647)
PhysicalClass ::= TEXTUAL-
STATUS
"An enumerated value which provides an indication of
general hardware type of a particular physical entity
There are no restrictions as to the number
entPhysicalEntries of each entPhysicalClass, which must
instantiated by an agent
The enumeration 'other' is applicable if the physical
class is known, but does not match any of the
values
The enumeration 'unknown' is applicable if the
entity class is unknown to the agent
The enumeration 'chassis' is applicable if the
entity class is an overall container for
equipment. Any class of physical entity except a stack
be contained within a chassis, and a chassis may only
contained within a stack
The enumeration 'backplane' is applicable if the
entity class is some sort of device for aggregating
forwarding networking traffic, such as a shared backplane
a modular ethernet switch. Note that an agent may model
McCloghrie & Bierman Standards Track [Page 14]
RFC 2737 Entity MIB (Version 2) December 1999
backplane as a single physical entity, which is
implemented as multiple discrete physical components (
a chassis or stack).
The enumeration 'container' is applicable if the
entity class is capable of containing one or more
physical entities, possibly of different types. For example
each (empty or full) slot in a chassis will be modeled as
container. Note that all removable physical entities
be modeled within a container entity, such as field
replaceable modules, fans, or power supplies. Note that
known containers should be modeled by the agent,
empty containers
The enumeration 'powerSupply' is applicable if the
entity class is a power-supplying component
The enumeration 'fan' is applicable if the physical
class is a fan or other heat-reduction component
The enumeration 'sensor' is applicable if the
entity class is some sort of sensor, such as a
sensor within a router chassis
The enumeration 'module' is applicable if the
entity class is some sort of self-contained sub-system.
it is removable, then it should be modeled within
container entity, otherwise it should be modeled
within another physical entity (e.g., a chassis or
module).
The enumeration 'port' is applicable if the physical
class is some sort of networking port, capable of
and/or transmitting networking traffic
The enumeration 'stack' is applicable if the physical
class is some sort of super-container (possibly virtual),
intended to group together multiple chassis entities.
stack may be realized by a 'virtual' cable, a
interconnect cable, attached to multiple chassis, or may
fact be comprised of multiple interconnect cables. A
should not be modeled within any other physical entities
but a stack may be contained within another stack.
chassis entities should be contained within a stack."
SYNTAX INTEGER {
other(1),
unknown(2),
chassis(3),
McCloghrie & Bierman Standards Track [Page 15]
RFC 2737 Entity MIB (Version 2) December 1999
backplane(4),
container(5), -- e.g., chassis slot or daughter-card
powerSupply(6),
fan(7),
sensor(8),
module(9), -- e.g., plug-in card or daughter-
port(10),
stack(11) -- e.g., stack of multiple chassis
}
SnmpEngineIdOrNone ::= TEXTUAL-
STATUS
"A specially formatted SnmpEngineID string for use with
Entity MIB
If an instance of an object of SYNTAX SnmpEngineIdOrNone
a non-zero length, then the object encoding and
are defined by the SnmpEngineID textual convention (see
2571 [RFC2571]).
If an instance of an object of SYNTAX
contains a zero-length string, then no
SnmpEngineID is associated with the logical entity (i.e.,
SNMPv3 not supported)."
SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or
-- The Physical Entity
entPhysicalTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"This table contains one row per physical entity. There
always at least one row for an 'overall' physical entity."
::= { entityPhysical 1 }
entPhysicalEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"Information about a particular physical entity
Each entry provides objects (entPhysicalDescr
entPhysicalVendorType, and entPhysicalClass) to help an
identify and characterize the entry, and
(entPhysicalContainedIn and entPhysicalParentRelPos) to
McCloghrie & Bierman Standards Track [Page 16]
RFC 2737 Entity MIB (Version 2) December 1999
an NMS relate the particular entry to other entries in
table."
INDEX { entPhysicalIndex }
::= { entPhysicalTable 1 }
EntPhysicalEntry ::= SEQUENCE {
entPhysicalIndex PhysicalIndex
entPhysicalDescr SnmpAdminString
entPhysicalVendorType AutonomousType
entPhysicalContainedIn INTEGER
entPhysicalClass PhysicalClass
entPhysicalParentRelPos INTEGER
entPhysicalName SnmpAdminString
entPhysicalHardwareRev SnmpAdminString
entPhysicalFirmwareRev SnmpAdminString
entPhysicalSoftwareRev SnmpAdminString
entPhysicalSerialNum SnmpAdminString
entPhysicalMfgName SnmpAdminString
entPhysicalModelName SnmpAdminString
entPhysicalAlias SnmpAdminString
entPhysicalAssetID SnmpAdminString
entPhysicalIsFRU
entPhysicalIndex OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The index for this entry."
::= { entPhysicalEntry 1 }
entPhysicalDescr OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"A textual description of physical entity. This
should contain a string which identifies the manufacturer'
name for the physical entity, and should be set to
distinct value for each version or model of the
entity. "
::= { entPhysicalEntry 2 }
entPhysicalVendorType OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
McCloghrie & Bierman Standards Track [Page 17]
RFC 2737 Entity MIB (Version 2) December 1999
"An indication of the vendor-specific hardware type of
physical entity. Note that this is different from
definition of MIB-II's sysObjectID
An agent should set this object to a enterprise-
registration identifier value indicating the
equipment type in detail. The associated instance
entPhysicalClass is used to indicate the general type
hardware device
If no vendor-specific registration identifier exists
this physical entity, or the value is unknown by this agent
then the value { 0 0 } is returned."
::= { entPhysicalEntry 3 }
entPhysicalContainedIn OBJECT-
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-
STATUS
"The value of entPhysicalIndex for the physical entity
'contains' this physical entity. A value of zero
this physical entity is not contained in any other
entity. Note that the set of 'containment'
define a strict hierarchy; that is, recursion is
allowed
In the event a physical entity is contained by more than
physical entity (e.g., double-wide modules), this
should identify the containing entity with the lowest
of entPhysicalIndex."
::= { entPhysicalEntry 4 }
entPhysicalClass OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"An indication of the general hardware type of the
entity
An agent should set this object to the standard
value which most accurately indicates the general class
the physical entity, or the primary class if there is
than one
If no appropriate standard registration identifier
McCloghrie & Bierman Standards Track [Page 18]
RFC 2737 Entity MIB (Version 2) December 1999
for this physical entity, then the value 'other(1)'
returned. If the value is unknown by this agent, then
value 'unknown(2)' is returned."
::= { entPhysicalEntry 5 }
entPhysicalParentRelPos OBJECT-
SYNTAX INTEGER (-1..2147483647)
MAX-ACCESS read-
STATUS
"An indication of the relative position of this 'child
component among all its 'sibling' components.
components are defined as entPhysicalEntries which share
same instance values of each of the
and entPhysicalClass objects
An NMS can use this object to identify the relative
for all sibling components of a particular
(identified by the entPhysicalContainedIn instance in
sibling entry).
This value should match any external labeling of
physical component if possible. For example, for a
(e.g., card slot) labeled as 'slot #3',
entPhysicalParentRelPos should have the value '3'.
that the entPhysicalEntry for the module plugged in slot 3
should have an entPhysicalParentRelPos value of '1'.
If the physical position of this component does not
any external numbering or clearly visible ordering,
user documentation or other external reference
should be used to determine the parent-relative position.
this is not possible, then the the agent should assign
consistent (but possibly arbitrary) ordering to a given
of 'sibling' components, perhaps based on
representation of the components
If the agent cannot determine the parent-relative
for some reason, or if the associated value
entPhysicalContainedIn is '0', then the value '-1'
returned. Otherwise a non-negative integer is returned
indicating the parent-relative position of this
entity
Parent-relative ordering normally starts from '1'
continues to 'N', where 'N' represents the
positioned child entity. However, if the physical
(e.g., slots) are labeled from a starting position of zero
McCloghrie & Bierman Standards Track [Page 19]
RFC 2737 Entity MIB (Version 2) December 1999
then the first sibling should be associated with
entPhysicalParentRelPos value of '0'. Note that
ordering may be sparse or dense, depending on
implementation
The actual values returned are not globally meaningful,
each 'parent' component may use different
algorithms. The ordering is only meaningful among
of the same parent component
The agent should retain parent-relative position
across reboots, either through algorithmic assignment or
of non-volatile storage."
::= { entPhysicalEntry 6 }
entPhysicalName OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The textual name of the physical entity. The value of
object should be the name of the component as assigned
the local device and should be suitable for use in
entered at the device's `console'. This might be a
name, such as `console' or a simple component number (e.g.,
port or module number), such as `1', depending on
physical component naming syntax of the device
If there is no local name, or this object is otherwise
applicable, then this object contains a zero-length string
Note that the value of entPhysicalName for two
entities will be the same in the event that the
interface does not distinguish between them, e.g., slot-1
and the card in slot-1."
::= { entPhysicalEntry 7 }
entPhysicalHardwareRev OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The vendor-specific hardware revision string for
physical entity. The preferred value is the
revision identifier actually printed on the component
(if present).
Note that if revision information is stored internally in
McCloghrie & Bierman Standards Track [Page 20]
RFC 2737 Entity MIB (Version 2) December 1999
non-printable (e.g., binary) format, then the agent
convert such information to a printable format, in
implementation-specific manner
If no specific hardware revision string is associated
the physical component, or this information is unknown
the agent, then this object will contain a zero-
string."
::= { entPhysicalEntry 8 }
entPhysicalFirmwareRev OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The vendor-specific firmware revision string for
physical entity
Note that if revision information is stored internally in
non-printable (e.g., binary) format, then the agent
convert such information to a printable format, in
implementation-specific manner
If no specific firmware programs are associated with
physical component, or this information is unknown to
agent, then this object will contain a zero-length string."
::= { entPhysicalEntry 9 }
entPhysicalSoftwareRev OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The vendor-specific software revision string for
physical entity
Note that if revision information is stored internally in
non-printable (e.g., binary) format, then the agent
convert such information to a printable format, in
implementation-specific manner
If no specific software programs are associated with
physical component, or this information is unknown to
agent, then this object will contain a zero-length string."
::= { entPhysicalEntry 10 }
entPhysicalSerialNum OBJECT-
SYNTAX SnmpAdminString (SIZE (0..32))
McCloghrie & Bierman Standards Track [Page 21]
RFC 2737 Entity MIB (Version 2) December 1999
MAX-ACCESS read-
STATUS
"The vendor-specific serial number string for the
entity. The preferred value is the serial number
actually printed on the component itself (if present).
On the first instantiation of an physical entity, the
of entPhysicalSerialNum associated with that entity is
to the correct vendor-assigned serial number, if
information is available to the agent. If a serial
is unknown or non-existent, the entPhysicalSerialNum will
set to a zero-length string instead
Note that implementations which can correctly identify
serial numbers of all installed physical entities do
need to provide write access to the
object. Agents which cannot provide non-volatile storage
the entPhysicalSerialNum strings are not required
implement write access for this object
Not every physical component will have a serial number,
even need one. Physical entities for which the
value of the entPhysicalIsFRU object is equal to 'false(2)'
(e.g., the repeater ports within a repeater module), do
need their own unique serial number. An agent does not
to provide write access for such entities, and may return
zero-length string
If write access is implemented for an instance
entPhysicalSerialNum, and a value is written into
instance, the agent must retain the supplied value in
entPhysicalSerialNum instance associated with the
physical entity for as long as that entity
instantiated. This includes instantiations across all re
initializations/reboots of the network management system
including those which result in a change of the
entity's entPhysicalIndex value."
::= { entPhysicalEntry 11 }
entPhysicalMfgName OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The name of the manufacturer of this physical component
The preferred value is the manufacturer name string
printed on the component itself (if present).
McCloghrie & Bierman Standards Track [Page 22]
RFC 2737 Entity MIB (Version 2) December 1999
Note that comparisons between instances of
entPhysicalModelName, entPhysicalFirmwareRev
entPhysicalSoftwareRev, and the
objects, are only meaningful amongst entPhysicalEntries
the same value of entPhysicalMfgName
If the manufacturer name string associated with the
component is unknown to the agent, then this object
contain a zero-length string."
::= { entPhysicalEntry 12 }
entPhysicalModelName OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The vendor-specific model name identifier string
with this physical component. The preferred value is
customer-visible part number, which may be printed on
component itself
If the model name string associated with the
component is unknown to the agent, then this object
contain a zero-length string."
::= { entPhysicalEntry 13 }
entPhysicalAlias OBJECT-
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS read-
STATUS
"This object is an 'alias' name for the physical entity
specified by a network manager, and provides a non-
'handle' for the physical entity
On the first instantiation of an physical entity, the
of entPhysicalAlias associated with that entity is set
the zero-length string. However, agent may set the value
a locally unique default value, instead of a zero-
string
If write access is implemented for an instance
entPhysicalAlias, and a value is written into the instance
the agent must retain the supplied value in
entPhysicalAlias instance associated with the same
entity for as long as that entity remains instantiated
This includes instantiations across all re
initializations/reboots of the network management system
McCloghrie & Bierman Standards Track [Page 23]
RFC 2737 Entity MIB (Version 2) December 1999
including those which result in a change of the
entity's entPhysicalIndex value."
::= { entPhysicalEntry 14 }
entPhysicalAssetID OBJECT-
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS read-
STATUS
"This object is a user-assigned asset tracking
for the physical entity as specified by a network manager
and provides non-volatile storage of this information
On the first instantiation of an physical entity, the
of entPhysicalAssetID associated with that entity is set
the zero-length string
Not every physical component will have a asset
identifier, or even need one. Physical entities for
the associated value of the entPhysicalIsFRU object is
to 'false(2)' (e.g., the repeater ports within a
module), do not need their own unique asset
identifier. An agent does not have to provide write
for such entities, and may instead return a zero-
string
If write access is implemented for an instance
entPhysicalAssetID, and a value is written into
instance, the agent must retain the supplied value in
entPhysicalAssetID instance associated with the
physical entity for as long as that entity
instantiated. This includes instantiations across all re
initializations/reboots of the network management system
including those which result in a change of the
entity's entPhysicalIndex value
If no asset tracking information is associated with
physical component, then this object will contain a zero
length string."
::= { entPhysicalEntry 15 }
entPhysicalIsFRU OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"This object indicates whether or not this physical
is considered a 'field replaceable unit' by the vendor.
McCloghrie & Bierman Standards Track [Page 24]
RFC 2737 Entity MIB (Version 2) December 1999
this object contains the value 'true(1)' then
entPhysicalEntry identifies a field replaceable unit.
all entPhysicalEntries which represent components that
permanently contained within a field replaceable unit,
value 'false(2)' should be returned for this object."
::= { entPhysicalEntry 16 }
-- The Logical Entity
entLogicalTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"This table contains one row per logical entity. For
which implement more than one naming scope, at least
entry must exist. Agents which instantiate all MIB
within a single naming scope are not required to
this table."
::= { entityLogical 1 }
entLogicalEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"Information about a particular logical entity.
may be managed by this agent or other SNMP agents (possibly
in the same chassis."
INDEX { entLogicalIndex }
::= { entLogicalTable 1 }
EntLogicalEntry ::= SEQUENCE {
entLogicalIndex INTEGER
entLogicalDescr SnmpAdminString
entLogicalType AutonomousType
entLogicalCommunity OCTET STRING
entLogicalTAddress TAddress
entLogicalTDomain TDomain
entLogicalContextEngineID SnmpEngineIdOrNone
entLogicalContextName
entLogicalIndex OBJECT-
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-
STATUS
McCloghrie & Bierman Standards Track [Page 25]
RFC 2737 Entity MIB (Version 2) December 1999
"The value of this object uniquely identifies the
entity. The value should be a small positive integer;
values for different logical entities are are
necessarily contiguous."
::= { entLogicalEntry 1 }
entLogicalDescr OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"A textual description of the logical entity. This
should contain a string which identifies the manufacturer'
name for the logical entity, and should be set to a
value for each version of the logical entity. "
::= { entLogicalEntry 2 }
entLogicalType OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"An indication of the type of logical entity. This
typically be the OBJECT IDENTIFIER name of the node in
SMI's naming hierarchy which represents the major
module, or the majority of the MIB modules, supported by
logical entity. For example
a logical entity of a regular host/router -> mib-2
a logical entity of a 802.1d bridge -> dot1
a logical entity of a 802.3 repeater -> snmpDot3
If an appropriate node in the SMI's naming hierarchy
be identified, the value 'mib-2' should be used."
::= { entLogicalEntry 3 }
entLogicalCommunity OBJECT-
SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-
STATUS
"An SNMPv1 or SNMPv2C community-string which can be used
access detailed management information for this
entity. The agent should allow read access with
community string (to an appropriate subset of all
objects) and may also return a community string based on
privileges of the request used to read this object.
that an agent may return a community string with read-
privileges, even if this object is accessed with a read
write community string. However, the agent must take
McCloghrie & Bierman Standards Track [Page 26]
RFC 2737 Entity MIB (Version 2) December 1999
not to return a community string which allows
privileges than the community string used to access
object
A compliant SNMP agent may wish to conserve naming scopes
representing multiple logical entities in a single 'default
naming scope. This is possible when the logical
represented by the same value of entLogicalCommunity have
object instances in common. For example, 'bridge1'
'repeater1' may be part of the main naming scope, but
least one additional community string is needed to
'bridge2' and 'repeater2'.
Logical entities 'bridge1' and 'repeater1' would
represented by sysOREntries associated with the 'default
naming scope
For agents not accessible via SNMPv1 or SNMPv2C, the
of this object is the empty string. This object may
contain an empty string if a community string has not
been assigned by the agent, or no community string
suitable access rights can be returned for a particular
request
Note that this object is deprecated. Agents which
SNMPv3 access should use the entLogicalContextEngineID
entLogicalContextName objects to identify the
associated with each logical entity. SNMPv3 agents
return a zero-length string for this object, or may
to return a community string (e.g., tri-lingual
support)."
::= { entLogicalEntry 4 }
entLogicalTAddress OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The transport service address by which the logical
receives network management traffic, formatted according
the corresponding value of entLogicalTDomain
For snmpUDPDomain, a TAddress is 6 octets long, the
4 octets containing the IP-address in network-byte order
the last 2 containing the UDP port in network-byte order
Consult 'Transport Mappings for Version 2 of the
Network Management Protocol' (RFC 1906 [RFC1906])
further information on snmpUDPDomain."
McCloghrie & Bierman Standards Track [Page 27]
RFC 2737 Entity MIB (Version 2) December 1999
::= { entLogicalEntry 5 }
entLogicalTDomain OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"Indicates the kind of transport service by which
logical entity receives network management traffic
Possible values for this object are presently found in
Transport Mappings for SNMPv2 document (RFC 1906
[RFC1906])."
::= { entLogicalEntry 6 }
entLogicalContextEngineID OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The authoritative contextEngineID that can be used to
an SNMP message concerning information held by this
entity, to the address specified by the
'entLogicalTAddress/entLogicalTDomain' pair
This object, together with the
entLogicalContextName object, defines the context
with a particular logical entity, and allows access to
engines identified by a contextEngineId and
pair
If no value has been configured by the agent, a zero-
string is returned, or the agent may choose not
instantiate this object at all."
::= { entLogicalEntry 7 }
entLogicalContextName OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The contextName that can be used to send an SNMP
concerning information held by this logical entity, to
address specified by the
'entLogicalTAddress/entLogicalTDomain' pair
This object, together with the
entLogicalContextEngineID object, defines the
associated with a particular logical entity, and
McCloghrie & Bierman Standards Track [Page 28]
RFC 2737 Entity MIB (Version 2) December 1999
access to SNMP engines identified by a contextEngineId
contextName pair
If no value has been configured by the agent, a zero-
string is returned, or the agent may choose not
instantiate this object at all."
::= { entLogicalEntry 8 }
entLPMappingTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"This table contains zero or more rows of logical entity
physical equipment associations. For each logical
known by this agent, there are zero or more mappings to
physical resources which are used to realize that
entity
An agent should limit the number and nature of entries
this table such that only meaningful and non-
information is returned. For example, in a system
contains a single power supply, mappings between
entities and the power supply are not useful and should
be included
Also, only the most appropriate physical component which
closest to the root of a particular containment tree
be identified in an entLPMapping entry
For example, suppose a bridge is realized on a
module, and all ports on that module are ports on
bridge. A mapping between the bridge and the module would
useful, but additional mappings between the bridge and
of the ports on that module would be redundant (since
entPhysicalContainedIn hierarchy can provide the
information). If, on the other hand, more than one
was utilizing ports on this module, then mappings
each bridge and the ports it used would be appropriate
Also, in the case of a single backplane repeater, a
for the backplane to the single repeater entity is
necessary."
::= { entityMapping 1 }
entLPMappingEntry OBJECT-
SYNTAX
MAX-ACCESS not-
McCloghrie & Bierman Standards Track [Page 29]
RFC 2737 Entity MIB (Version 2) December 1999
STATUS
"Information about a particular logical entity to
equipment association. Note that the nature of
association is not specifically identified in this entry
It is expected that sufficient information exists in
MIBs used to manage a particular logical entity to infer
physical component information is utilized."
INDEX { entLogicalIndex, entLPPhysicalIndex }
::= { entLPMappingTable 1 }
EntLPMappingEntry ::= SEQUENCE {
entLPPhysicalIndex
entLPPhysicalIndex OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The value of this object identifies the index value of
particular entPhysicalEntry associated with the
entLogicalEntity."
::= { entLPMappingEntry 1 }
-- logical entity/component to alias
entAliasMappingTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"This table contains zero or more rows,
mappings of logical entity and physical component
external MIB identifiers. Each physical port in the
may be associated with a mapping to an external identifier
which itself is associated with a particular
entity's naming scope. A 'wildcard' mechanism is
to indicate that an identifier is associated with more
one logical entity."
::= { entityMapping 2 }
entAliasMappingEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"Information about a particular physical equipment,
entity to external identifier binding. Each
McCloghrie & Bierman Standards Track [Page 30]
RFC 2737 Entity MIB (Version 2) December 1999
entity/physical component pair may be 