Request for Comments: 4133 K. McCloghrie
Obsoletes: 2737 Cisco Systems, Inc.
Category: Standards Track August 2005
Entity MIB (Version 3)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
multiple logical and physical entities managed by a single SNMP
agent. This document specifies version 3 of the Entity MIB, which
obsoletes version 2 (RFC 2737).
Table of Contents
1. The SNMP Management Framework ...................................3
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 ..............................11
2.12.3. entityMapping Group ..............................11
2.12.4. entityGeneral Group ..............................12
2.12.5. entityNotifications Group ........................12
2.13. Multiple Agents ..........................................12
2.14. Changes Since RFC 2037 ...................................12
2.14.1. Textual Conventions ..............................12
2.14.2. New entPhysicalTable Objects .....................13
2.14.3. New entLogicalTable Objects ......................13
2.14.4. Bug Fixes ........................................13
2.15. Changes Since RFC 2737 ...................................13
2.15.1. Textual Conventions ..............................13
2.15.2. New Objects ......................................14
2.15.3. Bug Fixes ........................................14
3. Definitions ....................................................14
4. Usage Examples .................................................44
4.1. Router/Bridge .............................................44
4.2. Repeaters .................................................50
5. Security Considerations ........................................57
6. IANA Considerations ............................................58
7. Acknowledgements ...............................................59
8. References .....................................................59
8.1. Normative References ......................................59
8.2. Informative References ....................................59
1. The SNMP Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
2. Overview
There is a need for a standardized way of representing a single
agent, which supports multiple instances of one MIB. This is
presently true for at least 3 standard MIBs, and is likely to become
true for more and more MIBs as time passes. For example:
- multiple instances of a bridge supported within a single device
that has a single agent;
- multiple repeaters supported by a single agent;
- multiple OSPF backbone areas, each operating as part of its own
Autonomous System, and each identified by the same area-id (e.g.,
0.0.0.0), supported inside a single router with one agent.
The single agent present in each of these cases implies a
relationship binds these entities. Effectively, there is some
"overall" physical entity which houses the sum of the things managed
by that one agent, i.e., there are multiple "logical" entities within
a single physical entity. Sometimes, the overall physical entity
contains multiple (smaller) physical entities, and each logical
entity is associated with a particular physical entity. Sometimes,
the overall physical entity is a "compound" of multiple physical
entities (e.g., a stack of stackable hubs).
What is needed is a way to determine exactly which logical entities
are managed by the agent (with some version of SNMP) in order to
communicate with the agent about a particular logical entity. When
different logical entities are associated with different physical
entities within the overall physical entity, it is also useful to be
able to use this information to distinguish between logical entities.
In these situations, there is no need for varbinds for multiple
logical entities to be referenced in the same SNMP message (although
that might be useful in the future). Rather, it is sufficient, and
in some situations preferable, to have the context/community in the
message identify the logical entity to which the varbinds apply.
Version 2 of this MIB addresses new requirements, which have emerged
since the publication of the first Entity MIB (RFC 2037 [RFC2037]).
There is a need for a standardized way of providing non-volatile,
administratively-assigned identifiers for physical components
represented with the Entity MIB. There is also a need to align the
Entity MIB with the SNMPv3 administrative framework (STD 62, RFC 3411
[RFC3411]). Implementation experience has shown that additional
physical component attributes are also desirable.
Version 3 of this MIB addresses new requirements, which have emerged
since the publication of the second Entity MIB (RFC 2737 [RFC2737]).
There is a need to identify physical entities that are central
processing units (CPUs) and a need to provide a textual convention
that identifies an entPhysicalIndex value or zero, where the value
zero has application-specific semantics. Two new objects have been
added to the entPhysicalTable to identify the manufacturing date and
provide additional URIs for a particular physical entity.
2.1. Terms
Some new terms are used throughout this document:
- Naming Scope
A "naming scope" represents the set of information that may be
potentially accessed through a single SNMP operation. All
instances within the naming scope share the same unique identifier
space. For SNMPv1, a naming scope is identified by the value of
the associated ’entLogicalCommunity’ instance. For SNMPv3, the
term ’context’ is used instead of ’naming scope’. The complete
definition of an SNMP context can be found in section 3.3.1 of RFC
3411 [RFC3411].
- Multi-Scoped Object
A MIB object, for which identical instance values identify
different managed information in different naming scopes, is called
a "multi-scoped" MIB object.
- Single-Scoped Object
A MIB object, for which identical instance values identify the same
managed information in different naming scopes, is called a
"single-scoped" MIB object.
- Logical Entity
A managed system contains one or more logical entities, each
represented by at most one instantiation of each of a particular
set of MIB objects. A set of management functions is associated
with each logical entity. Examples of logical entities include
routers, bridges, print-servers, etc.
- Physical Entity
A "physical entity" or "physical component" represents an
identifiable physical resource within a managed system. Zero or
more logical entities may utilize a physical resource at any given
time. Determining which physical components are represented by an
agent in the EntPhysicalTable is an implementation-specific matter.
Typically, physical resources (e.g., communications ports,
backplanes, sensors, daughter-cards, power supplies, the overall
chassis), which can be managed via functions associated with one or
more logical entities, are included in the MIB.
- Containment Tree
Each physical component may be modeled as ’contained’ within
another physical component. A "containment-tree" is the conceptual
sequence of entPhysicalIndex values that uniquely specifies the
exact physical location of a physical component within the managed
system. It is generated by ’following and recording’ each
’entPhysicalContainedIn’ instance ’up the tree towards the root’,
until a value of zero indicating no further containment is found.
2.2. Relationship to Community Strings
For community-based SNMP, differentiating logical entities is one
(but not the only) purpose of the community string (RFC 1157
[RFC1157]). This is accommodated by representing each community
string as a logical entity.
Note that different logical entities may share the same naming scope
and, therefore, the same values of entLogicalCommunity. This is
possible, providing they have no need for the same instance of a MIB
object to represent different managed information.
2.3. Relationship to SNMP Contexts
Version 2 of the Entity MIB contains support for associating SNMPv3
contexts with logical entities. Two new MIB objects, defining an
SnmpEngineID and ContextName pair, are used together to identify an
SNMP context associated with a logical entity. This context can be
used (in conjunction with the entLogicalTAddress and
entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of a
particular logical entity.
2.4. Relationship to Proxy Mechanisms
The Entity MIB is designed to allow functional component discovery.
The administrative relationships between different logical entities
are not visible in any Entity MIB tables. A Network Management
System (NMS) cannot determine whether MIB instances in different
naming scopes are realized locally or remotely (e.g., via some proxy
mechanism) by examining any particular Entity MIB objects.
The management of administrative framework functions is not an
explicit goal of the Entity MIB WG at this time. This new area of
functionality may be revisited after some operational experience with
the Entity MIB is gained.
Note that for community-based versions of SNMP, a network
administrator will likely be able to associate community strings with
naming scopes that have proprietary mechanisms, as a matter of
configuration. There are no mechanisms for managing naming scopes
defined in this MIB.
2.5. Relationship to a Chassis MIB
Some readers may recall that a previous IETF working group attempted
to define a Chassis MIB. No consensus was reached by that working
group, possibly because its scope was too broad. As such, it is not
the purpose of this MIB to be a "Chassis MIB replacement", nor is it
within the scope of this MIB to contain all the information which
might be necessary to manage a "chassis". On the other hand, the
entities represented by an implementation of this MIB might well be
contained in a chassis.
2.6. Relationship to the Interfaces MIB
The Entity MIB contains a mapping table identifying physical
components that have ’external values’ (e.g., ifIndex) associated
with them within a given naming scope. This table can be used to
identify the physical location of each interface in the ifTable (RFC
2863 [RFC2863]). Because ifIndex values in different contexts are
not related to one another, the interface to physical component
associations are relative to the same logical entity within the
agent.
The Entity MIB also contains ’entPhysicalName’ and ’entPhysicalAlias’
objects, which approximate the semantics of the ’ifName’ and
’ifAlias’ objects (respectively) from the Interfaces MIB [RFC2863],
for all types of physical components.
2.7. Relationship to the Other MIBs
The Entity MIB contains a mapping table identifying physical
components that have identifiers from other standard MIBs associated
with them. For example, this table can be used along with the
physical mapping table to identify the physical location of each
repeater port in the rptrPortTable, or each interface in the ifTable.
2.8. Relationship to Naming Scopes
There is some question as to which MIB objects may be returned within
a given naming scope. MIB objects which are not multi-scoped within
a managed system are likely to ignore context information in
implementation. In such a case, it is likely such objects will be
returned in all naming scopes (e.g., not just the ’default’ naming
scope or the SNMPv3 default context).
For example, a community string used to access the management
information for logical device ’bridge2’ may allow access to all the
non-bridge related objects in the ’default’ naming scope, as well as
a second instance of the Bridge MIB (RFC 1493 [RFC1493]).
The isolation of single-scoped MIB objects by the agent is an
implementation-specific matter. An agent may wish to limit the
objects returned in a particular naming scope to only the multi-
scoped objects in that naming scope (e.g., system group and the
Bridge MIB). In this case, all single-scoped management information
would belong to a common naming scope (e.g., ’default’), which itself
may contain some multi-scoped objects (e.g., system group).
2.9. Multiple Instances of the Entity MIB
It is possible that more than one agent may exist in a managed
system. In such cases, multiple instances of the Entity MIB
(representing the same managed objects) may be available to an NMS.
In order to reduce complexity for agent implementation, multiple
instances of the Entity MIB are not required to be equivalent or even
consistent. An NMS may be able to ’align’ instances returned by
different agents by examining the columns of each table, but vendor-
specific identifiers and (especially) index values are likely to be
different. Each agent may be managing different subsets of the
entire chassis as well.
When all of a physically-modular device is represented by a single
agent, the entry (for which entPhysicalContainedIn has the value
zero) would likely have ’chassis’ as the value of its
entPhysicalClass. Alternatively, for an agent on a module where the
agent represents only the physical entities on that module (not those
on other modules), the entry (for which entPhysicalContainedIn has
the value zero) would likely have ’module’ as the value of its
entPhysicalClass.
An agent implementation of the entLogicalTable is not required to
contain information about logical entities managed primarily by other
agents. That is, the entLogicalTAddress and entLogicalTDomain
objects in the entLogicalTable are provided to support an historical
multiplexing mechanism, not to identify other SNMP agents.
Note that the Entity MIB is a single-scoped MIB, in the event an
agent represents the MIB in different naming scopes.
2.10. Re-Configuration of Entities
Most of the MIB objects defined in this MIB have, at most, a read-
only MAX-ACCESS clause. This is a conscious decision by the working
group to limit this MIB’s scope. The second version of the Entity
MIB allows a network administrator to configure some common
attributes of physical components.
2.11. Textual Convention Change
Version 1 of the Entity MIB contains three MIB objects defined with
the (now obsolete) DisplayString textual convention. In version 2 of
the Entity MIB, the syntax for these objects has been updated to use
the (now preferred) SnmpAdminString textual convention.
The working group realizes that this change is not strictly supported
by SMIv2. In our judgment, the alternative of deprecating the old
objects and defining new objects would have a more adverse impact on
backward compatibility and interoperability, given the particular
semantics of these objects.
2.12. MIB Structure
The Entity MIB contains five groups of MIB objects:
- entityPhysical group
Describes the physical entities managed by a single agent.
- entityLogical group
Describes the logical entities managed by a single agent.
- entityMapping group
Describes the associations between the physical entities, logical
entities, interfaces, and non-interface ports managed by a single
agent.
- entityGeneral group
Describes general system attributes shared by potentially all types
of entities managed by a single agent.
- entityNotifications group
Contains status indication notifications.
2.12.1. entityPhysical Group
This group contains a single table to identify physical system
components, called the entPhysicalTable.
The entPhysicalTable contains one row per physical entity, and must
always contain at least one row for an "overall" physical entity,
which should have an entPhysicalClass value of ’stack(11)’,
’chassis(3)’ or ’module(9)’.
Each row is indexed by an arbitrary, small integer, and contains a
description and type of the physical entity. It also optionally
contains the index number of another entPhysicalEntry, indicating a
containment relationship between the two.
Version 2 of the Entity MIB provides additional MIB objects for each
physical entity. Some common read-only attributes have been added,
as well as three writable string objects.
- entPhysicalAlias
This string can be used by an NMS as a non-volatile identifier for
the physical component. Maintaining a non-volatile string for
every physical component represented in the entPhysicalTable can be
costly and unnecessary. An agent may algorithmically generate
’entPhysicalAlias’ strings for particular entries (e.g., based on
the entPhysicalClass value).
- entPhysicalAssetID
This string is provided to store a user-specific asset identifier
for removable physical components. In order to reduce the non-
volatile storage needed by a particular agent, a network
administrator should only assign asset identifiers to physical
entities that are field-replaceable (i.e., not permanently
contained within another physical entity).
- entPhysicalSerialNum
This string is provided to store a vendor-specific serial number
string for physical components. This writable object is used when
an agent cannot identify the serial numbers of all installed
physical entities, and a network administrator wishes to configure
the non-volatile serial number strings manually (via an NMS
application).
Version 3 of the Entity MIB provides two additional MIB objects for
each physical entity:
- entPhysicalMfgDate
This object contains the date of manufacturing of the managed
entity. If the manufacturing date is unknown or not supported the
object is not instantiated. The special value ’0000000000000000’H
may also be returned in this case.
- entPhysicalUris
This object provides additional identification information about
the physical entity.
This object contains one or more Uniform Resource Identifiers
(URIs) and, therefore, the syntax of this object must conform to
RFC 3986 [RFC3986] section 2. Uniform Resource Names (URNs), RFC
3406 [RFC3406], are resource identifiers with the specific
requirements for enabling location independent identification of a
resource, as well as longevity of reference. URNs are part of the
larger URI family with the specific goal of providing persistent
naming of resources. URI schemes and URN name spaces are
registered by IANA (see http://www.iana.org/assignments/uri-schemes
and http://www.iana.org/assignments/urn-namespaces).
For example, the entPhysicalUris object may be used to encode a URI
containing a Common Language Equipment Identifier (CLEI) URN for
the managed physical entity. The URN name space for CLEIs is
defined in [RFCYYYY], and the CLEI format is defined in
[T1.213][T1.213a]. For example, an entPhysicalUris instance may
have the value of
URN:CLEI:D4CE18B7AA
[RFC3986] and [RFCYYYY] identify this as a URI in the CLEI URN name
space. The specific CLEI code, D4CE18B7AA, is based on the example
provided in [T1.213a].
Multiple URIs may be present and are separated by white space
characters. Leading and trailing white space characters are
ignored.
If no additional identification information is known about the
physical entity or supported, the object is not instantiated.
2.12.2. entityLogical Group
This group contains a single table to identify logical entities,
called the entLogicalTable.
The entLogicalTable contains one row per logical entity. Each row is
indexed by an arbitrary, small integer and contains a name,
description, and type of the logical entity. It also contains
information to allow access to the MIB information for the logical
entity. This includes SNMP versions that use a community name (with
some form of implied context representation) and SNMP versions that
use the SNMP ARCH [RFC3411] method of context identification.
If an agent represents multiple logical entities with this MIB, then
this group must be implemented for all logical entities known to the
agent.
If an agent represents a single logical entity, or multiple logical
entities within a single naming scope, then implementation of this
group may be omitted by the agent.
2.12.3. entityMapping Group
This group contains three tables to identify associations between
different system components.
- entLPMappingTable
This table contains mappings between entLogicalIndex values
(logical entities) and entPhysicalIndex values (the physical
components supporting that entity). A logical entity can map to
more than one physical component, and more than one logical entity
can map to (share) the same physical component. If an agent
represents a single logical entity, or multiple logical entities
within a single naming scope, then implementation of this table may
be omitted by the agent.
- entAliasMappingTable
This table contains mappings between entLogicalIndex,
entPhysicalIndex pairs, and ’alias’ object identifier values. This
allows resources managed with other MIBs (e.g., repeater ports,
bridge ports, physical and logical interfaces) to be identified in
the physical entity hierarchy. Note that each alias identifier is
only relevant in a particular naming scope. If an agent represents
a single logical entity, or multiple logical entities within a
single naming scope, then implementation of this table may be
omitted by the agent.
- entPhysicalContainsTable
This table contains simple mappings between
’entPhysicalContainedIn’ values for each container/’containee’
relationship in the managed system. The indexing of this table
allows an NMS to quickly discover the ’entPhysicalIndex’ values for
all children of a given physical entity.
2.12.4. entityGeneral Group
This group contains general information relating to the other object
groups.
At this time, the entGeneral group contains a single scalar object
(entLastChangeTime), which represents the value of sysUptime when any