draft-ietf-entmib-v3-04.txt   draft-ietf-entmib-v3-05.txt 
Entity MIB Working Group Andy Bierman Entity MIB Working Group Andy Bierman
Internet Draft Keith McCloghrie Internet Draft Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
22 January 2004 22 October 2004
Entity MIB (Version 3) Entity MIB (Version 3)
<draft-ietf-entmib-v3-04.txt> <draft-ietf-entmib-v3-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all By submitting this Internet-Draft, each author represents that any
provisions of Section 10 of RFC2026 [RFC2026]. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet- Drafts as reference material documents at any time. It is inappropriate to use Internet- Drafts
or to cite them other than as "work in progress". as reference material or to cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send comments to the This document may not be modified, and derivative works of it may
Entity MIB Working Group, <entmib@ietf.org>. not be created, except to publish it as an RFC and to translate it
into languages other than English.
1. Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
"Abstract" 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).
2. Table of Contents 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).
1 Copyright Notice ................................................ 1 Table of Contents
2 Table of Contents ............................................... 2
3 The SNMP Management Framework ................................... 3
4 Overview ........................................................ 3
4.1 Terms ......................................................... 4
4.2 Relationship to Community Strings ............................. 5
4.3 Relationship to SNMP Contexts ................................. 6
4.4 Relationship to Proxy Mechanisms .............................. 6
4.5 Relationship to a Chassis MIB ................................. 6
4.6 Relationship to the Interfaces MIB ............................ 7
4.7 Relationship to the Other MIBs ................................ 7
4.8 Relationship to Naming Scopes ................................. 7
4.9 Multiple Instances of the Entity MIB .......................... 8
4.10 Re-Configuration of Entities ................................. 8
4.11 Textual Convention Change .................................... 9
4.12 MIB Structure ................................................ 9
4.12.1 entityPhysical Group ....................................... 9
4.12.2 entityLogical Group ........................................ 10
4.12.3 entityMapping Group ........................................ 11
4.12.4 entityGeneral Group ........................................ 11
4.12.5 entityNotifications Group .................................. 12
4.13 Multiple Agents .............................................. 12
4.14 Changes Since RFC 2037 ....................................... 12
4.14.1 Textual Conventions ........................................ 12
4.14.2 New entPhysicalTable Objects ............................... 12
4.14.3 New entLogicalTable Objects ................................ 13
4.14.4 Bugfixes ................................................... 13
4.15 Changes Since RFC 2737 ....................................... 13
4.15.1 Textual Conventions ........................................ 13
4.15.2 Deprecated Objects ......................................... 13
4.15.3 Bugfixes ................................................... 14
5 Definitions ..................................................... 15
6 Usage Examples .................................................. 46
6.1 Router/Bridge ................................................. 46
6.2 Repeaters ..................................................... 52 1 The SNMP Management Framework .............................. 3
7 Intellectual Property ........................................... 60 2 Overview ................................................... 3
8 Acknowledgements ................................................ 60 2.1 Terms .................................................... 4
9 Normative References ............................................ 60 2.2 Relationship to Community Strings ........................ 6
10 Informative References ......................................... 61 2.3 Relationship to SNMP Contexts ............................ 6
11 Security Considerations ........................................ 63 2.4 Relationship to Proxy Mechanisms ......................... 6
12 Authors' Addresses ............................................. 65 2.5 Relationship to a Chassis MIB ............................ 7
13 Full Copyright Statement ....................................... 66 2.6 Relationship to the Interfaces MIB ....................... 7
2.7 Relationship to the Other MIBs ........................... 7
2.8 Relationship to Naming Scopes ............................ 8
2.9 Multiple Instances of the Entity MIB ..................... 8
2.10 Re-Configuration of Entities ............................ 9
2.11 Textual Convention Change ............................... 9
2.12 MIB Structure ........................................... 9
2.12.1 entityPhysical Group .................................. 10
2.12.2 entityLogical Group ................................... 11
2.12.3 entityMapping Group ................................... 12
2.12.4 entityGeneral Group ................................... 12
2.12.5 entityNotifications Group ............................. 13
2.13 Multiple Agents ......................................... 13
2.14 Changes Since RFC 2037 .................................. 13
2.14.1 Textual Conventions ................................... 13
2.14.2 New entPhysicalTable Objects .......................... 13
2.14.3 New entLogicalTable Objects ........................... 14
2.14.4 Bugfixes .............................................. 14
2.15 Changes Since RFC 2737 .................................. 14
2.15.1 Textual Conventions ................................... 14
2.15.2 New Objects ........................................... 15
2.15.3 Deprecated Objects .................................... 15
2.15.4 Bugfixes .............................................. 15
3 Definitions ................................................ 16
4 Usage Examples ............................................. 48
4.1 Router/Bridge ............................................ 48
4.2 Repeaters ................................................ 54
5 Security Considerations .................................... 62
6 IANA Considerations ........................................ 64
7 Acknowledgements ........................................... 64
8 References ................................................. 64
8.1 Normative References ..................................... 64
8.2 Informative References ................................... 65
3. The SNMP Management Framework 1. The SNMP Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of RFC Internet-Standard Management Framework, please refer to section 7
3410 [RFC3410]. of RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store,
Management Information Base or MIB. MIB objects are generally accessed termed the Management Information Base or MIB. MIB objects are
through the Simple Network Management Protocol (SNMP). Objects in the generally accessed through the Simple Network Management Protocol
MIB are defined using the mechanisms defined in the Structure of (SNMP). Objects in the MIB are defined using the mechanisms
Management Information (SMI). This memo specifies a MIB module that is defined in the Structure of Management Information (SMI). This
compliant to the SMIv2, which is described in STD 58, RFC 2578 memo specifies a MIB module that is compliant to the SMIv2, which
[RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579
[RFC2579] and STD 58, RFC 2580 [RFC2580].
4. Overview 2. Overview
There is a need for a standardized way of representing a single agent There is a need for a standardized way of representing a single
which supports multiple instances of one MIB. This is presently true agent which supports multiple instances of one MIB. This is
for at least 3 standard MIBs, and is likely to become true for more and presently true for at least 3 standard MIBs, and is likely to
more MIBs as time passes. For example: become true for more and more MIBs as time passes. For example:
- multiple instances of a bridge supported within a single device - multiple instances of a bridge supported within a single device
having a single agent; having a single agent;
- multiple repeaters supported by a single agent; - multiple repeaters supported by a single agent;
- multiple OSPF backbone areas, each one operating as part of its own - multiple OSPF backbone areas, each one operating as part of its own
Autonomous System, and each identified by the same area-id (e.g., Autonomous System, and each identified by the same area-id (e.g.,
0.0.0.0), supported inside a single router with one agent. 0.0.0.0), supported inside a single router with one agent.
The fact that it is a single agent in each of these cases implies there The fact that it is a single agent in each of these cases implies
is some relationship which binds all of these entities together. there is some relationship which binds all of these entities
Effectively, there is some "overall" physical entity which houses the together. Effectively, there is some "overall" physical entity
sum of the things managed by that one agent, i.e., there are multiple which houses the sum of the things managed by that one agent, i.e.,
"logical" entities within a single physical entity. Sometimes, the there are multiple "logical" entities within a single physical
overall physical entity contains multiple (smaller) physical entities entity. Sometimes, the overall physical entity contains multiple
(smaller) physical entities and each logical entity is associated
and each logical entity is associated with a particular physical entity. with a particular physical entity. Sometimes, the overall physical
Sometimes, the overall physical entity is a "compound" of multiple entity is a "compound" of multiple physical entities (e.g., a stack
physical entities (e.g., a stack of stackable hubs). of stackable hubs).
What is needed is a way to determine exactly what logical entities are What is needed is a way to determine exactly what logical entities
managed by the agent (with some version of SNMP), and thereby to be able are managed by the agent (with some version of SNMP), and thereby
to communicate with the agent about a particular logical entity. When to be able to communicate with the agent about a particular logical
different logical entities are associated with different physical entity. When different logical entities are associated with
entities within the overall physical entity, it is also useful to be different physical entities within the overall physical entity, it
able to use this information to distinguish between logical entities. 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 In these situations, there is no need for varbinds for multiple
entities to be referenced in the same SNMP message (although that might logical entities to be referenced in the same SNMP message
be useful in the future). Rather, it is sufficient, and in some (although that might be useful in the future). Rather, it is
situations preferable, to have the context/community in the message sufficient, and in some situations preferable, to have the
identify the logical entity to which the varbinds apply. context/community in the message identify the logical entity to
which the varbinds apply.
Version 2 of this MIB addresses new requirements that have emerged since Version 2 of this MIB addresses new requirements that have emerged
the publication of the first Entity MIB (RFC 2037 [RFC2037]). There is since the publication of the first Entity MIB (RFC 2037 [RFC2037]).
a need for a standardized way of providing non-volatile, There is a need for a standardized way of providing non-volatile,
administratively assigned identifiers for physical components administratively assigned identifiers for physical components
represented with the Entity MIB. There is also a need to align the represented with the Entity MIB. There is also a need to align the
Entity MIB with the SNMPv3 administrative framework (STD 62, RFC 3411 Entity MIB with the SNMPv3 administrative framework (STD 62, RFC
[RFC3411]). Implementation experience has shown that additional 3411 [RFC3411]). Implementation experience has shown that
physical component attributes are also desirable. additional physical component attributes are also desirable.
Version 3 of this MIB addresses new requirements that have emerged since Version 3 of this MIB addresses new requirements that have emerged
the publication of the second Entity MIB (RFC 2737 [RFC2737]). There is since the publication of the second Entity MIB (RFC 2737
a need for identifying physical entities which are central processing [RFC2737]). There is a need for identifying physical entities
units (CPUs) and a need to provide a textual convention which identifies which are central processing units (CPUs) and a need to provide a
an entPhysicalIndex value or zero, where the value zero has application- textual convention which identifies an entPhysicalIndex value or
specific semantics. zero, where the value zero has application-specific semantics.
4.1. Terms 2.1. Terms
Some new terms are used throughout this document: Some new terms are used throughout this document:
- Naming Scope - Naming Scope
A "naming scope" represents the set of information that may be A "naming scope" represents the set of information that may be
potentially accessed through a single SNMP operation. All instances potentially accessed through a single SNMP operation. All instances
within the naming scope share the same unique identifier space. within the naming scope share the same unique identifier space.
For SNMPv1, a naming scope is identified by the value of the For SNMPv1, a naming scope is identified by the value of the
associated 'entLogicalCommunity' instance. For SNMPv3, the term associated 'entLogicalCommunity' instance. For SNMPv3, the term
'context' is used instead of 'naming scope'. The complete 'context' is used instead of 'naming scope'. The complete
skipping to change at page 5, line 43 skipping to change at page 6, line 9
- Containment Tree - Containment Tree
Each physical component may be modeled as 'contained' within Each physical component may be modeled as 'contained' within
another physical component. A "containment-tree" is the conceptual another physical component. A "containment-tree" is the conceptual
sequence of entPhysicalIndex values which uniquely specifies the sequence of entPhysicalIndex values which uniquely specifies the
exact physical location of a physical component within the managed exact physical location of a physical component within the managed
system. It is generated by 'following and recording' each system. It is generated by 'following and recording' each
'entPhysicalContainedIn' instance 'up the tree towards the root', 'entPhysicalContainedIn' instance 'up the tree towards the root',
until a value of zero indicating no further containment is found. until a value of zero indicating no further containment is found.
4.2. Relationship to Community Strings 2.2. Relationship to Community Strings
For community-based SNMP, distinguishing between different logical For community-based SNMP, distinguishing between different logical
entities is one (but not the only) purpose of the community string (RFC entities is one (but not the only) purpose of the community string
1157 [RFC1157]). This is accommodated by representing each community (RFC 1157 [RFC1157]). This is accommodated by representing each
string as a logical entity. community string as a logical entity.
Note that different logical entities may share the same naming scope Note that different logical entities may share the same naming
(and therefore the same values of entLogicalCommunity). This is scope (and therefore the same values of entLogicalCommunity). This
possible, providing they have no need for the same instance of a MIB is possible, providing they have no need for the same instance of a
object to represent different managed information. MIB object to represent different managed information.
4.3. Relationship to SNMP Contexts 2.3. Relationship to SNMP Contexts
Version 2 of the Entity MIB contains support for associating SNMPv3 Version 2 of the Entity MIB contains support for associating SNMPv3
contexts with logical entities. Two new MIB objects, defining an contexts with logical entities. Two new MIB objects, defining an
SnmpEngineID and ContextName pair, are used together to identify an SNMP SnmpEngineID and ContextName pair, are used together to identify an
context associated with a logical entity. This context can be used (in SNMP context associated with a logical entity. This context can be
conjunction with the entLogicalTAddress and entLogicalTDomain MIB used (in conjunction with the entLogicalTAddress and
objects) to send SNMPv3 messages on behalf of a particular logical entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of
entity. a particular logical entity.
4.4. Relationship to Proxy Mechanisms
The Entity MIB is designed to allow functional component discovery. The 2.4. Relationship to Proxy Mechanisms
administrative relationships between different logical entities are not
visible in any Entity MIB tables. An 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 The Entity MIB is designed to allow functional component discovery.
goal of the Entity MIB WG at this time. This new area of functionality The administrative relationships between different logical entities
may be revisited after some operational experience with the Entity MIB are not visible in any Entity MIB tables. An NMS cannot determine
is gained. 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.
Note that for community-based versions of SNMP, a network administrator The management of administrative framework functions is not an
will likely be able to associate community strings with naming scopes explicit goal of the Entity MIB WG at this time. This new area of
with proprietary mechanisms, as a matter of configuration. There are no functionality may be revisited after some operational experience
mechanisms for managing naming scopes defined in this MIB. with the Entity MIB is gained.
4.5. Relationship to a Chassis MIB Note that for community-based versions of SNMP, a network
administrator will likely be able to associate community strings
with naming scopes with proprietary mechanisms, as a matter of
configuration. There are no mechanisms for managing naming scopes
defined in this MIB.
Some readers may recall that a previous IETF working group attempted to 2.5. Relationship to a Chassis MIB
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. 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.
4.6. Relationship to the Interfaces MIB 2.6. Relationship to the Interfaces MIB
The Entity MIB contains a mapping table identifying physical components The Entity MIB contains a mapping table identifying physical
that have 'external values' (e.g., ifIndex) associated with them within components that have 'external values' (e.g., ifIndex) associated
a given naming scope. This table can be used to identify the physical with them within a given naming scope. This table can be used to
location of each interface in the ifTable (RFC 2863 [RFC2863]). Since identify the physical location of each interface in the ifTable
ifIndex values in different contexts are not related to one another, the (RFC 2863 [RFC2863]). Since ifIndex values in different contexts
interface to physical component associations are relative to the same are not related to one another, the interface to physical component
logical entity within the agent. associations are relative to the same logical entity within the
agent.
The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias' The Entity MIB also contains 'entPhysicalName' and
objects, which approximate the semantics of the 'ifName' and 'ifAlias' 'entPhysicalAlias' objects, which approximate the semantics of the
objects (respectively) from the Interfaces MIB [RFC2863], for all types 'ifName' and 'ifAlias' objects (respectively) from the Interfaces
of physical components. MIB [RFC2863], for all types of physical components.
4.7. Relationship to the Other MIBs 2.7. Relationship to the Other MIBs
The Entity MIB contains a mapping table identifying physical components The Entity MIB contains a mapping table identifying physical
that have identifiers from other standard MIBs associated with them. components that have identifiers from other standard MIBs
For example, this table can be used along with the physical mapping associated with them. For example, this table can be used along
table to identify the physical location of each repeater port in the with the physical mapping table to identify the physical location
rptrPortTable, or each interface in the ifTable. of each repeater port in the rptrPortTable, or each interface in
the ifTable.
4.8. Relationship to Naming Scopes 2.8. Relationship to Naming Scopes
There is some question as to which MIB objects may be returned within a There is some question as to which MIB objects may be returned
given naming scope. MIB objects which are not multi-scoped within a within a given naming scope. MIB objects which are not multi-scoped
managed system are likely to ignore context information in within a managed system are likely to ignore context information in
implementation. In such a case, it is likely such objects will be 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 returned in all naming scopes (e.g., not just the 'default' naming
or the SNMPv3 default context). scope or the SNMPv3 default context).
For example, a community string used to access the management For example, a community string used to access the management
information for logical device 'bridge2' may allow access to all the information for logical device 'bridge2' may allow access to all
non-bridge related objects in the 'default' naming scope, as well as a the non-bridge related objects in the 'default' naming scope, as
second instance of the Bridge MIB (RFC 1493 [RFC1493]). well as a second instance of the Bridge MIB (RFC 1493 [RFC1493]).
It is an implementation-specific matter as to the isolation of single-
scoped MIB objects by the agent. An agent may wish to limit the objects
returned in a particular naming scope to just the multi-scoped objects
in that naming scope (e.g., system group and the Bridge MIB). In this It is an implementation-specific matter as to the isolation of
case, all single-scoped management information would belong to a common single-scoped MIB objects by the agent. An agent may wish to limit
naming scope (e.g., 'default'), which itself may contain some multi- the objects returned in a particular naming scope to just the
scoped objects (e.g., system group). 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).
4.9. Multiple Instances of the Entity MIB 2.9. Multiple Instances of the Entity MIB
It is possible that more than one agent exists in a managed system, and It is possible that more than one agent exists in a managed system,
in such cases, multiple instances of the Entity MIB (representing the and in such cases, multiple instances of the Entity MIB
same managed objects) may be available to an NMS. (representing the same managed objects) may be available to an NMS.
In order to reduce complexity for agent implementation, multiple In order to reduce complexity for agent implementation, multiple
instances of the Entity MIB are not required to be equivalent or even instances of the Entity MIB are not required to be equivalent or
consistent. An NMS may be able to 'align' instances returned by even consistent. An NMS may be able to 'align' instances returned
different agents by examining the columns of each table, but vendor- by different agents by examining the columns of each table, but
specific identifiers and (especially) index values are likely to be vendor-specific identifiers and (especially) index values are
different. Each agent may be managing different subsets of the entire likely to be different. Each agent may be managing different
chassis as well. subsets of the entire chassis as well.
When all of a physically-modular device is represented by a single When all of a physically-modular device is represented by a single
agent, the entry for which entPhysicalContainedIn has the value zero agent, the entry for which entPhysicalContainedIn has the value
would likely have 'chassis' as the value of its entPhysicalClass; zero would likely have 'chassis' as the value of its
alternatively, for an agent on a module where the agent represents only entPhysicalClass; alternatively, for an agent on a module where the
the physical entities on that module (not those on other modules), the agent represents only the physical entities on that module (not
entry for which entPhysicalContainedIn has the value zero would likely those on other modules), the entry for which entPhysicalContainedIn
have 'module' as the value of its entPhysicalClass. has the value zero would likely have 'module' as the value of its
entPhysicalClass.
An agent implementation of the entLogicalTable is not required to An agent implementation of the entLogicalTable is not required to
contain information about logical entities managed primarily by other contain information about logical entities managed primarily by
agents. That is, the entLogicalTAddress and entLogicalTDomain objects in other agents. That is, the entLogicalTAddress and entLogicalTDomain
the entLogicalTable are provided to support an historical multiplexing objects in the entLogicalTable are provided to support an
mechanism, not to identify other SNMP agents. historical multiplexing mechanism, not to identify other SNMP
agents.
Note that the Entity MIB is a single-scoped MIB, in the event an agent Note that the Entity MIB is a single-scoped MIB, in the event an
represents the MIB in different naming scopes. agent represents the MIB in different naming scopes.
4.10. Re-Configuration of Entities 2.10. Re-Configuration of Entities
Most of the MIB objects defined in this MIB have at most a read-only 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 group to only MAX-ACCESS clause. This is a conscious decision by the
limit this MIB's scope. The second version of the Entity MIB allows a working group to limit this MIB's scope. The second version of the
network administrator to configure some common attributes of physical Entity MIB allows a network administrator to configure some common
components. attributes of physical components.
4.11. Textual Convention Change 2.11. Textual Convention Change
Version 1 of the Entity MIB contains three MIB objects defined with the Version 1 of the Entity MIB contains three MIB objects defined with
(now obsolete) DisplayString textual convention. In version 2 of the the (now obsolete) DisplayString textual convention. In version 2
Entity MIB, the syntax for these objects has been updated to use the of the Entity MIB, the syntax for these objects has been updated to
(now preferred) SnmpAdminString textual convention. use the (now preferred) SnmpAdminString textual convention.
The working group realizes that this change is not strictly supported by The working group realizes that this change is not strictly
SMIv2. In our judgment, the alternative of deprecating the old objects supported by SMIv2. In our judgment, the alternative of
and defining new objects would have a more adverse impact on backward deprecating the old objects and defining new objects would have a
compatibility and interoperability, given the particular semantics of more adverse impact on backward compatibility and interoperability,
these objects. given the particular semantics of these objects.
4.12. MIB Structure 2.12. MIB Structure
The Entity MIB contains five groups of MIB objects: The Entity MIB contains five groups of MIB objects:
- entityPhysical group - entityPhysical group
Describes the physical entities managed by a single agent. Describes the physical entities managed by a single agent.
- entityLogical group - entityLogical group
Describes the logical entities managed by a single agent. Describes the logical entities managed by a single agent.
- entityMapping group - entityMapping group
skipping to change at page 9, line 40 skipping to change at page 10, line 20
entities, interfaces, and non-interface ports managed by a single entities, interfaces, and non-interface ports managed by a single
agent. agent.
- entityGeneral group - entityGeneral group
Describes general system attributes shared by potentially all types Describes general system attributes shared by potentially all types
of entities managed by a single agent. of entities managed by a single agent.
- entityNotifications group - entityNotifications group
Contains status indication notifications. Contains status indication notifications.
4.12.1. entityPhysical Group 2.12.1. entityPhysical Group
This group contains a single table to identify physical system This group contains a single table to identify physical system
components, called the entPhysicalTable. components, called the entPhysicalTable.
The entPhysicalTable contains one row per physical entity, and must The entPhysicalTable contains one row per physical entity, and must
always contain at least one row for an "overall" physical entity, which always contain at least one row for an "overall" physical entity,
should have an entPhysicalClass value of 'stack(11)', 'chassis(3)' or which should have an entPhysicalClass value of 'stack(11)',
'chassis(3)' or 'module(9)'.
'module(9)'.
Each row is indexed by an arbitrary, small integer, and contains a Each row is indexed by an arbitrary, small integer, and contains a
description and type of the physical entity. It also optionally description and type of the physical entity. It also optionally
contains the index number of another entPhysicalEntry indicating a contains the index number of another entPhysicalEntry indicating a
containment relationship between the two. containment relationship between the two.
Version 2 of the Entity MIB provides additional MIB objects for each Version 2 of the Entity MIB provides additional MIB objects for
physical entity. Some common read-only attributes have been added, as each physical entity. Some common read-only attributes have been
well as three writable string objects. added, as well as three writable string objects.
- entPhysicalAlias - entPhysicalAlias
This string can be used by an NMS as a non-volatile identifier for This string can be used by an NMS as a non-volatile identifier for
the physical component. Maintaining a non-volatile string for every the physical component. Maintaining a non-volatile string for every
physical component represented in the entPhysicalTable can be physical component represented in the entPhysicalTable can be
costly and unnecessary. An agent may algorithmically generate costly and unnecessary. An agent may algorithmically generate
'entPhysicalAlias' strings for particular entries (e.g., based on 'entPhysicalAlias' strings for particular entries (e.g., based on
the entPhysicalClass value). the entPhysicalClass value).
- entPhysicalAssetID - entPhysicalAssetID
skipping to change at page 10, line 40 skipping to change at page 11, line 18
contained within another physical entity). contained within another physical entity).
- entPhysicalSerialNum - entPhysicalSerialNum
This string is provided to store a vendor-specific serial number This string is provided to store a vendor-specific serial number
string for physical components. This is a writable object in case string for physical components. This is a writable object in case
an agent cannot identify the serial numbers of all installed an agent cannot identify the serial numbers of all installed
physical entities, and a network administrator wishes to configure physical entities, and a network administrator wishes to configure
the non-volatile serial number strings manually (via an NMS the non-volatile serial number strings manually (via an NMS
application). application).
4.12.2. entityLogical Group Version 3 of the Entity MIB provides two additional MIB objects for
each physical entity:
This group contains a single table to identify logical entities, called - entPhysicalMfgDate
the entLogicalTable. 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 entLogicalTable contains one row per logical entity. Each row is - entPhysicalUris
indexed by an arbitrary, small integer and contains a name, description, This object provides additional identification information about
and type of the logical entity. It also contains information to allow the physical entity. This object may be used to encode for example
access to the MIB information for the logical entity. This includes SNMP a URI containing a Common Language Equipment Identifier (CLEI) URI
versions that use a community name (with some form of implied context [reference TBD] for the managed physical entity. If no additional
identification information is known or supported about the physical
entity the object is not instantiated.
representation) and SNMP versions that use the SNMP ARCH [RFC3411] 2.12.2. entityLogical Group
method of context identification.
If a agent represents multiple logical entities with this MIB, then this This group contains a single table to identify logical entities,
group must be implemented for all logical entities known to the agent. 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 a agent represents multiple logical entities with this MIB, then
this group must be implemented for all logical entities known to
the agent.
If an agent represents a single logical entity, or multiple logical If an agent represents a single logical entity, or multiple logical
entities within a single naming scope, then implementation of this group entities within a single naming scope, then implementation of this
may be omitted by the agent. group may be omitted by the agent.
4.12.3. entityMapping Group 2.12.3. entityMapping Group
This group contains three tables to identify associations between This group contains three tables to identify associations between
different system components. different system components.
The entLPMappingTable contains mappings between entLogicalIndex values The entLPMappingTable contains mappings between entLogicalIndex
(logical entities) and entPhysicalIndex values (the physical components values (logical entities) and entPhysicalIndex values (the physical
supporting that entity). A logical entity can map to more than one components supporting that entity). A logical entity can map to
physical component, and more than one logical entity can map to (share) more than one physical component, and more than one logical entity
the same physical component. If an agent represents a single logical can map to (share) the same physical component. If an agent
entity, or multiple logical entities within a single naming scope, then represents a single logical entity, or multiple logical entities
implementation of this table may be omitted by the agent. Note that within a single naming scope, then implementation of this table may
this table is deprecated in version 3 of the Entity MIB. be omitted by the agent. Note that this table is deprecated in
version 3 of the Entity MIB.
The entAliasMappingTable contains mappings between entLogicalIndex, The entAliasMappingTable contains mappings between entLogicalIndex,
entPhysicalIndex pairs and 'alias' object identifier values. This entPhysicalIndex pairs and 'alias' object identifier values. This
allows resources managed with other MIBs (e.g., repeater ports, bridge allows resources managed with other MIBs (e.g., repeater ports,
ports, physical and logical interfaces) to be identified in the physical bridge ports, physical and logical interfaces) to be identified in
entity hierarchy. Note that each alias identifier is only relevant in a the physical entity hierarchy. Note that each alias identifier is
particular naming scope. If an agent represents a single logical only relevant in a particular naming scope. If an agent represents
entity, or multiple logical entities within a single naming scope, then a single logical entity, or multiple logical entities within a
implementation of this table may be omitted by the agent. Note that single naming scope, then implementation of this table may be
this table is deprecated in version 3 of the Entity MIB. omitted by the agent.
The entPhysicalContainsTable contains simple mappings between The entPhysicalContainsTable contains simple mappings between
'entPhysicalContainedIn' values for each container/'containee' 'entPhysicalContainedIn' values for each container/'containee'
relationship in the managed system. The indexing of this table allows an relationship in the managed system. The indexing of this table
NMS to quickly discover the 'entPhysicalIndex' values for all children allows an NMS to quickly discover the 'entPhysicalIndex' values for
of a given physical entity. all children of a given physical entity.
4.12.4. entityGeneral Group 2.12.4. entityGeneral Group
This group contains general information relating to the other object This group contains general information relating to the other
groups. object groups.
At this time, the entGeneral group contains a single scalar object At this time, the entGeneral group contains a single scalar object
(entLastChangeTime), which represents the value of sysUptime when any (entLastChangeTime), which represents the value of sysUptime when
part of the Entity MIB configuration last changed. any part of the Entity MIB configuration last changed.
4.12.5. entityNotifications Group 2.12.5. entityNotifications Group
This group contains notification definitions relating to the overall This group contains notification definitions relating to the
status of the Entity MIB instantiation. overall status of the Entity MIB instantiation.
4.13. Multiple Agents 2.13. Multiple Agents
Even though a primary motivation for this MIB is to represent the Even though a primary motivation for this MIB is to represent the
multiple logical entities supported by a single agent, it is also multiple logical entities supported by a single agent, it is also
possible to use it to represent multiple logical entities supported by possible to use it to represent multiple logical entities supported
multiple agents (in the same "overall" physical entity). Indeed, it is by multiple agents (in the same "overall" physical entity).
implicit in the SNMP architecture, that the number of agents is Indeed, it is implicit in the SNMP architecture, that the number of
transparent to a network management station. agents is transparent to a network management station.
However, there is no agreement at this time as to the degree of However, there is no agreement at this time as to the degree of
cooperation which should be expected for agent implementations. cooperation which should be expected for agent implementations.
Therefore, multiple agents within the same managed system are free to Therefore, multiple agents within the same managed system are free
implement the Entity MIB independently. (Refer the section on "Multiple to implement the Entity MIB independently. (Refer the section on
Instances of the Entity MIB" for more details). "Multiple Instances of the Entity MIB" for more details).
4.14. Changes Since RFC 2037 2.14. Changes Since RFC 2037
4.14.1. Textual Conventions 2.14.1. Textual Conventions
The PhysicalClass TC text has been clarified, and a new enumeration to The PhysicalClass TC text has been clarified, and a new enumeration
support 'stackable' components has been added. The SnmpEngineIdOrNone to support 'stackable' components has been added. The
TC has been added to support SNMPv3. SnmpEngineIdOrNone TC has been added to support SNMPv3.
4.14.2. New entPhysicalTable Objects 2.14.2. New entPhysicalTable Objects
The entPhysicalHardwareRev, entPhysicalFirmwareRev, and The entPhysicalHardwareRev, entPhysicalFirmwareRev, and
entPhysicalSoftwareRev objects have been added for revision entPhysicalSoftwareRev objects have been added for revision
identification. identification.
The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName, and The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName,
entPhysicalIsFru objects have been added for better vendor and entPhysicalIsFru objects have been added for better vendor
identification for physical components. The entPhysicalSerialNum object identification for physical components. The entPhysicalSerialNum
can be set by a management station in the event the agent cannot object can be set by a management station in the event the agent
identify this information. cannot identify this information.
The entPhysicalAlias and entPhysicalAssetID objects have been added for The entPhysicalAlias and entPhysicalAssetID objects have been added
better user component identification. These objects are intended to be for better user component identification. These objects are
set by a management station and preserved by the agent across restarts. intended to be set by a management station and preserved by the
agent across restarts.
4.14.3. New entLogicalTable Objects 2.14.3. New entLogicalTable Objects
The entLogicalContextEngineID and entLogicalContextName objects have The entLogicalContextEngineID and entLogicalContextName objects
been added to provide an SNMP context for SNMPv3 access on behalf of a have been added to provide an SNMP context for SNMPv3 access on
logical entity. behalf of a logical entity.
4.14.4. Bugfixes 2.14.4. Bugfixes
A bug was fixed in the entLogicalCommunity object. The subrange was A bug was fixed in the entLogicalCommunity object. The subrange was
incorrect (1..255) and is now (0..255). The description clause has also incorrect (1..255) and is now (0..255). The description clause has
been clarified. This object is now deprecated. also been clarified. This object is now deprecated.
The entLastChangeTime object description has been changed to generalize The entLastChangeTime object description has been changed to
the events which cause an update to the last change timestamp. generalize the events which cause an update to the last change
timestamp.
The syntax was changed from DisplayString to SnmpAdminString for the The syntax was changed from DisplayString to SnmpAdminString for
entPhysicalDescr, entPhysicalName, and entLogicalDescr objects. the entPhysicalDescr, entPhysicalName, and entLogicalDescr objects.
4.15. Changes Since RFC 2737 2.15. Changes Since RFC 2737
4.15.1. Textual Conventions 2.15.1. Textual Conventions
The PhysicalIndexOrZero TC has been added to allow objects to reference The PhysicalIndexOrZero TC has been added to allow objects to
an entPhysicalIndex value or zero. The PhysicalClass TC has been reference an entPhysicalIndex value or zero. The PhysicalClass TC
extended to support a new enumeration for central processing units. has been extended to support a new enumeration for central
processing units.
4.15.2. Deprecated Objects 2.15.2. New Objects
The entLPMappingTable has been deprecated because no implementations The entPhysicalMfgDate object has been added to the
have been found which support this table. The entLPPhysicalIndex has entPhysicalTable to provide the date of manufacturing of the
been removed from the entityMappingGroup. This OBJECT-GROUP has been managed entity.
updated (entityMappingGroupRev1) as well as the Entity MIB MODULE-
CONFORMANCE statement.
The entAliasMappingTable has been deprecated because two independent The entPhysicalUris object has been added to the entPhysicalTable
implementations have not been found which support this table. The to provide additional identification information about the physical
entAliasMappingIdentifier object has been removed from the entity, such as a Common Language Equipment Identifier (CLEI) URI.
entityMappingGroup. This OBJECT-GROUP has been updated
(entityMappingGroupRev1) as well as the Entity MIB MODULE-CONFORMANCE
statement.
4.15.3. Bugfixes 2.15.3. Deprecated Objects
The entLPMappingTable has been deprecated because no
implementations have been found which support this table. The
entLPPhysicalIndex has been removed from the entityMappingGroup.
This OBJECT-GROUP has been updated (entityMappingGroupRev1) as well
as the Entity MIB MODULE-CONFORMANCE statement.
2.15.4. Bugfixes
The syntax was changed from INTEGER to Integer32 for the The syntax was changed from INTEGER to Integer32 for the
entPhysicalParentRelPos, entLogicalIndex, and entAliasLogicalIndexOrZero entPhysicalParentRelPos, entLogicalIndex, and
objects, and from INTEGER to PhysicalIndexOrZero for the entAliasLogicalIndexOrZero objects, and from INTEGER to
entPhysicalContainedIn object. PhysicalIndexOrZero for the entPhysicalContainedIn object.
5. Definitions 3. Definitions
ENTITY-MIB DEFINITIONS ::= BEGIN ENTITY-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE, MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE,
Integer32 Integer32
FROM SNMPv2-SMI FROM SNMPv2-SMI
TDomain, TAddress, TEXTUAL-CONVENTION, TDomain, TAddress, TEXTUAL-CONVENTION,
AutonomousType, RowPointer, TimeStamp, TruthValue AutonomousType, RowPointer, TimeStamp, TruthValue,
DateAndTime
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
SnmpAdminString SnmpAdminString
FROM SNMP-FRAMEWORK-MIB; FROM SNMP-FRAMEWORK-MIB;
entityMIB MODULE-IDENTITY entityMIB MODULE-IDENTITY
LAST-UPDATED "200401210000Z" LAST-UPDATED "200410220000Z"
ORGANIZATION "IETF ENTMIB Working Group" ORGANIZATION "IETF ENTMIB Working Group"
CONTACT-INFO CONTACT-INFO
" WG E-mail: entmib@ietf.org " WG E-mail: entmib@ietf.org
Mailing list subscription info: Mailing list subscription info:
http://www.ietf.org/mailman/listinfo/entmib http://www.ietf.org/mailman/listinfo/entmib
Andy Bierman Andy Bierman
Cisco Systems Inc. Cisco Systems Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 15, line 47 skipping to change at page 16, line 48
Cisco Systems Inc. Cisco Systems Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
+1 408-526-5260 +1 408-526-5260
kzm@cisco.com" kzm@cisco.com"
DESCRIPTION DESCRIPTION
"The MIB module for representing multiple logical "The MIB module for representing multiple logical
entities supported by a single SNMP agent. entities supported by a single SNMP agent.
Copyright (C) The Internet Society (2003). This Copyright (C) The Internet Society (2004). This
version of this MIB module is part of RFC xxxx; see version of this MIB module is part of RFC xxxx; see
the RFC itself for full legal notices." the RFC itself for full legal notices."
REVISION "200401210000Z" -- RFC Ed.: replace xxxx with actual RFC number & remove this notice
REVISION "200410220000Z"
DESCRIPTION DESCRIPTION
"Initial Version of Entity MIB (Version 3). "Initial Version of Entity MIB (Version 3).
This revision obsoletes RFC 2737. This revision obsoletes RFC 2737.
Additions: Additions:
- cpu(12) enumeration added to PhysicalClass TC - cpu(12) enumeration added to PhysicalClass TC
- PhysicalIndexOrZero TC - PhysicalIndexOrZero TC
- entPhysicalMfgDate object
- entPhysicalUris object
Changes: Changes:
- entLPMappingTable deprecated - entLPMappingTable deprecated
- entAliasMappingTable deprecated
- entPhysicalContainedIn SYNTAX changed from - entPhysicalContainedIn SYNTAX changed from
INTEGER to PhysicalIndexOrZero INTEGER to PhysicalIndexOrZero
This version published as RFC xxxx (to be This version published as RFC xxxx."
assigned by the RFC Editor)." -- RFC Ed.: replace xxxx with actual RFC number & remove this notice
REVISION "199912070000Z" REVISION "199912070000Z"
DESCRIPTION DESCRIPTION
"Initial Version of Entity MIB (Version 2). "Initial Version of Entity MIB (Version 2).
This revision obsoletes RFC 2037. This revision obsoletes RFC 2037.
This version published as RFC 2737." This version published as RFC 2737."
REVISION "199610310000Z" REVISION "199610310000Z"
DESCRIPTION DESCRIPTION
"Initial version (version 1), published as "Initial version (version 1), published as
RFC 2037." RFC 2037."
skipping to change at page 20, line 31 skipping to change at page 21, line 37
entPhysicalParentRelPos Integer32, entPhysicalParentRelPos Integer32,
entPhysicalName SnmpAdminString, entPhysicalName SnmpAdminString,
entPhysicalHardwareRev SnmpAdminString, entPhysicalHardwareRev SnmpAdminString,
entPhysicalFirmwareRev SnmpAdminString, entPhysicalFirmwareRev SnmpAdminString,
entPhysicalSoftwareRev SnmpAdminString, entPhysicalSoftwareRev SnmpAdminString,
entPhysicalSerialNum SnmpAdminString, entPhysicalSerialNum SnmpAdminString,
entPhysicalMfgName SnmpAdminString, entPhysicalMfgName SnmpAdminString,
entPhysicalModelName SnmpAdminString, entPhysicalModelName SnmpAdminString,
entPhysicalAlias SnmpAdminString, entPhysicalAlias SnmpAdminString,
entPhysicalAssetID SnmpAdminString, entPhysicalAssetID SnmpAdminString,
entPhysicalIsFRU TruthValue entPhysicalIsFRU TruthValue,
entPhysicalMfgDate DateAndTime,
entPhysicalUris OCTET STRING
} }
entPhysicalIndex OBJECT-TYPE entPhysicalIndex OBJECT-TYPE
SYNTAX PhysicalIndex SYNTAX PhysicalIndex
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The index for this entry." "The index for this entry."
::= { entPhysicalEntry 1 } ::= { entPhysicalEntry 1 }
skipping to change at page 28, line 41 skipping to change at page 30, line 5
DESCRIPTION DESCRIPTION
"This object indicates whether or not this physical entity "This object indicates whether or not this physical entity
is considered a 'field replaceable unit' by the vendor. If is considered a 'field replaceable unit' by the vendor. If
this object contains the value 'true(1)' then this this object contains the value 'true(1)' then this
entPhysicalEntry identifies a field replaceable unit. For entPhysicalEntry identifies a field replaceable unit. For
all entPhysicalEntries which represent components that are all entPhysicalEntries which represent components that are
permanently contained within a field replaceable unit, the permanently contained within a field replaceable unit, the
value 'false(2)' should be returned for this object." value 'false(2)' should be returned for this object."
::= { entPhysicalEntry 16 } ::= { entPhysicalEntry 16 }
entPhysicalMfgDate OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The manufacturing date for the physical entity."
::= { entPhysicalEntry 17 }
entPhysicalUris OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object contains additional identification information
about the physical entity. The object contains URIs and
therefore the syntax of this object must conform to RFC 2396
[RFC2396] section 2. Multiple URIs may be separated by white
space characters."
REFERENCE
"RFC 2396, Uniform Resource Identifiers (URI): Generic
Syntax, section 2, August 1998."
::= { entPhysicalEntry 18 }
-- The Logical Entity Table -- The Logical Entity Table
entLogicalTable OBJECT-TYPE entLogicalTable OBJECT-TYPE
SYNTAX SEQUENCE OF EntLogicalEntry SYNTAX SEQUENCE OF EntLogicalEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table contains one row per logical entity. For agents "This table contains one row per logical entity. For agents
which implement more than one naming scope, at least one which implement more than one naming scope, at least one
entry must exist. Agents which instantiate all MIB objects entry must exist. Agents which instantiate all MIB objects
within a single naming scope are not required to implement within a single naming scope are not required to implement
skipping to change at page 34, line 33 skipping to change at page 36, line 21
DESCRIPTION DESCRIPTION
"The value of this object identifies the index value of a "The value of this object identifies the index value of a
particular entPhysicalEntry associated with the indicated particular entPhysicalEntry associated with the indicated
entLogicalEntity." entLogicalEntity."
::= { entLPMappingEntry 1 } ::= { entLPMappingEntry 1 }
-- logical entity/component to alias table -- logical entity/component to alias table
entAliasMappingTable OBJECT-TYPE entAliasMappingTable OBJECT-TYPE
SYNTAX SEQUENCE OF EntAliasMappingEntry SYNTAX SEQUENCE OF EntAliasMappingEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS current
DESCRIPTION DESCRIPTION
"This table contains zero or more rows, representing "This table contains zero or more rows, representing
mappings of logical entity and physical component to mappings of logical entity and physical component to
external MIB identifiers. Each physical port in the system external MIB identifiers. Each physical port in the system
may be associated with a mapping to an external identifier, may be associated with a mapping to an external identifier,
which itself is associated with a particular logical which itself is associated with a particular logical
entity's naming scope. A 'wildcard' mechanism is provided entity's naming scope. A 'wildcard' mechanism is provided
to indicate that an identifier is associated with more than to indicate that an identifier is associated with more than
one logical entity." one logical entity."
::= { entityMapping 2 } ::= { entityMapping 2 }
entAliasMappingEntry OBJECT-TYPE entAliasMappingEntry OBJECT-TYPE
SYNTAX EntAliasMappingEntry SYNTAX EntAliasMappingEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular physical equipment, logical "Information about a particular physical equipment, logical
entity to external identifier binding. Each logical entity to external identifier binding. Each logical
entity/physical component pair may be associated with one entity/physical component pair may be associated with one
alias mapping. The logical entity index may also be used as alias mapping. The logical entity index may also be used as
a 'wildcard' (refer to the entAliasLogicalIndexOrZero object a 'wildcard' (refer to the entAliasLogicalIndexOrZero object
DESCRIPTION clause for details.) DESCRIPTION clause for details.)
Note that only entPhysicalIndex values which represent Note that only entPhysicalIndex values which represent
physical ports (i.e. associated entPhysicalClass value is physical ports (i.e. associated entPhysicalClass value is
skipping to change at page 35, line 27 skipping to change at page 37, line 14
::= { entAliasMappingTable 1 } ::= { entAliasMappingTable 1 }
EntAliasMappingEntry ::= SEQUENCE { EntAliasMappingEntry ::= SEQUENCE {
entAliasLogicalIndexOrZero Integer32, entAliasLogicalIndexOrZero Integer32,
entAliasMappingIdentifier RowPointer entAliasMappingIdentifier RowPointer
} }
entAliasLogicalIndexOrZero OBJECT-TYPE entAliasLogicalIndexOrZero OBJECT-TYPE
SYNTAX Integer32 (0..2147483647) SYNTAX Integer32 (0..2147483647)
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS current
DESCRIPTION DESCRIPTION
"The value of this object identifies the logical entity "The value of this object identifies the logical entity
which defines the naming scope for the associated instance which defines the naming scope for the associated instance
of the 'entAliasMappingIdentifier' object. of the 'entAliasMappingIdentifier' object.
If this object has a non-zero value, then it identifies the If this object has a non-zero value, then it identifies the
logical entity named by the same value of entLogicalIndex. logical entity named by the same value of entLogicalIndex.
If this object has a value of zero, then the mapping between If this object has a value of zero, then the mapping between
the physical component and the alias identifier for this the physical component and the alias identifier for this
skipping to change at page 36, line 25 skipping to change at page 38, line 11
Note that entries with non-zero entAliasLogicalIndexOrZero Note that entries with non-zero entAliasLogicalIndexOrZero
index values have precedence over any zero-indexed entry. In index values have precedence over any zero-indexed entry. In
this example, all logical entities except 4, 5, and 10, this example, all logical entities except 4, 5, and 10,
associate physical entity 33 with ifIndex.6." associate physical entity 33 with ifIndex.6."
::= { entAliasMappingEntry 1 } ::= { entAliasMappingEntry 1 }
entAliasMappingIdentifier OBJECT-TYPE entAliasMappingIdentifier OBJECT-TYPE
SYNTAX RowPointer SYNTAX RowPointer
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS deprecated STATUS current
DESCRIPTION DESCRIPTION
"The value of this object identifies a particular conceptual "The value of this object identifies a particular conceptual
row associated with the indicated entPhysicalIndex and row associated with the indicated entPhysicalIndex and
entLogicalIndex pair. entLogicalIndex pair.
Since only physical ports are modeled in this table, only Since only physical ports are modeled in this table, only
entries which represent interfaces or ports are allowed. If entries which represent interfaces or ports are allowed. If
an ifEntry exists on behalf of a particular physical port, an ifEntry exists on behalf of a particular physical port,
then this object should identify the associated 'ifEntry'. then this object should identify the associated 'ifEntry'.
For repeater ports, the appropriate row in the For repeater ports, the appropriate row in the
skipping to change at page 41, line 33 skipping to change at page 43, line 22
entity3Compliance MODULE-COMPLIANCE entity3Compliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The compliance statement for SNMP entities which implement "The compliance statement for SNMP entities which implement
version 3 of the Entity MIB." version 3 of the Entity MIB."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { MANDATORY-GROUPS {
entityPhysicalGroup, entityPhysicalGroup,
entityPhysical2Group, entityPhysical2Group,
entityPhysical3Group,
entityGeneralGroup, entityGeneralGroup,
entityNotificationsGroup entityNotificationsGroup
} }
GROUP entityLogical2Group GROUP entityLogical2Group
DESCRIPTION DESCRIPTION
"Implementation of this group is not mandatory for agents "Implementation of this group is not mandatory for agents
which model all MIB object instances within a single naming which model all MIB object instances within a single naming
scope." scope."
GROUP entityMappingGroupRev1 GROUP entityMappingGroupRev1
skipping to change at page 45, line 12 skipping to change at page 46, line 48
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The collection of objects which are used to represent the "The collection of objects which are used to represent the
list of logical entities for which a single SNMP entity list of logical entities for which a single SNMP entity
provides management information." provides management information."
::= { entityGroups 7 } ::= { entityGroups 7 }
entityMappingGroupRev1 OBJECT-GROUP entityMappingGroupRev1 OBJECT-GROUP
OBJECTS { OBJECTS {
entAliasMappingIdentifier,
entPhysicalChildIndex entPhysicalChildIndex
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The collection of objects which are used to represent the "The collection of objects which are used to represent the
associations between multiple logical entities, physical associations between multiple logical entities, physical
components, interfaces, and port identifiers for which a components, interfaces, and port identifiers for which a
single agent provides management information." single agent provides management information."
::= { entityGroups 8 } ::= { entityGroups 8 }
entityPhysical3Group OBJECT-GROUP
OBJECTS {
entPhysicalMfgDate,
entPhysicalUris
}
STATUS current
DESCRIPTION
"The collection of objects which are used to represent
physical system components, for which a single agent
provides management information. This group augments the
objects contained in the entityPhysicalGroup."
::= { entityGroups 9 }
END END
6. Usage Examples 4. Usage Examples
The following sections iterate the instance values for two example The following sections iterate the instance values for two example
networking devices. These examples are kept simple to make them more networking devices. These examples are kept simple to make them
understandable. Auxiliary components, such as fans, sensors, empty more understandable. Auxiliary components, such as fans, sensors,
slots, and sub-modules are not shown, but might be modeled in real empty slots, and sub-modules are not shown, but might be modeled in
implementations. real implementations.
6.1. Router/Bridge 4.1. Router/Bridge
A router containing two slots. Each slot contains a 3 port A router containing two slots. Each slot contains a 3 port
router/bridge module. Each port is represented in the ifTable. There router/bridge module. Each port is represented in the ifTable.
are two logical instances of OSPF running and two logical bridges: There are two logical instances of OSPF running and two logical
bridges:
Physical entities -- entPhysicalTable: Physical entities -- entPhysicalTable:
1 Field-replaceable physical chassis: 1 Field-replaceable physical chassis:
entPhysicalDescr.1 == 'Acme Chassis Model 100' entPhysicalDescr.1 == 'Acme Chassis Model 100'
entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1
entPhysicalContainedIn.1 == 0 entPhysicalContainedIn.1 == 0
entPhysicalClass.1 == chassis(3) entPhysicalClass.1 == chassis(3)
entPhysicalParentRelPos.1 == 0 entPhysicalParentRelPos.1 == 0
entPhysicalName.1 == '100-A' entPhysicalName.1 == '100-A'
entPhysicalHardwareRev.1 == 'A(1.00.02)' entPhysicalHardwareRev.1 == 'A(1.00.02)'
skipping to change at page 52, line 32 skipping to change at page 54, line 32
module 1 has 3 ports: module 1 has 3 ports:
entPhysicalChildIndex.4.5 == 5 entPhysicalChildIndex.4.5 == 5
entPhysicalChildIndex.4.6 == 6 entPhysicalChildIndex.4.6 == 6
entPhysicalChildIndex.4.7 == 7 entPhysicalChildIndex.4.7 == 7
module 2 has 3 ports: module 2 has 3 ports:
entPhysicalChildIndex.8.9 == 9 entPhysicalChildIndex.8.9 == 9
entPhysicalChildIndex.8.10 == 10 entPhysicalChildIndex.8.10 == 10
entPhysicalChildIndex.1.11 == 11 entPhysicalChildIndex.1.11 == 11
6.2. Repeaters 4.2. Repeaters
A 3-slot Hub with 2 backplane ethernet segments. Slot three is empty, A 3-slot Hub with 2 backplane ethernet segments. Slot three is
and the remaining slots contain ethernet repeater modules. empty, and the remaining slots contain ethernet repeater modules.
Note that this example assumes an older Repeater MIB implementation, Note that this example assumes an older Repeater MIB
(RFC 1516 [RFC1516]) rather than the new Repeater MIB (RFC 2108 implementation, (RFC 1516 [RFC1516]) rather than the new Repeater
[RFC2108]). The new version contains an object called 'rptrPortRptrId', MIB (RFC 2108 [RFC2108]). The new version contains an object
which should be used to identify repeater port groupings, rather than called 'rptrPortRptrId', which should be used to identify repeater
with community strings or contexts. port groupings, rather than with community strings or contexts.
Physical entities -- entPhysicalTable: Physical entities -- entPhysicalTable:
1 Field-replaceable physical chassis: 1 Field-replaceable physical chassis:
entPhysicalDescr.1 == 'Acme Chassis Model 110' entPhysicalDescr.1 == 'Acme Chassis Model 110'
entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2
entPhysicalContainedIn.1 == 0 entPhysicalContainedIn.1 == 0
entPhysicalClass.1 == chassis(3) entPhysicalClass.1 == chassis(3)
entPhysicalParentRelPos.1 == 0 entPhysicalParentRelPos.1 == 0
entPhysicalName.1 == '110-B' entPhysicalName.1 == '110-B'
entPhysicalHardwareRev.1 == 'A(1.02.00)' entPhysicalHardwareRev.1 == 'A(1.02.00)'
skipping to change at page 60, line 5 skipping to change at page 62, line 5
module 1 has 4 ports: module 1 has 4 ports:
entPhysicalChildIndex.7.8 == 8 entPhysicalChildIndex.7.8 == 8
entPhysicalChildIndex.7.9 == 9 entPhysicalChildIndex.7.9 == 9
entPhysicalChildIndex.7.10 == 10 entPhysicalChildIndex.7.10 == 10
entPhysicalChildIndex.7.11 == 11 entPhysicalChildIndex.7.11 == 11
module 2 has 2 ports: module 2 has 2 ports:
entPhysicalChildIndex.12.13 == 13 entPhysicalChildIndex.12.13 == 13
entPhysicalChildIndex.12.14 == 14 entPhysicalChildIndex.12.14 == 14
7. Intellectual Property 5. Security Considerations
The IETF takes no position regarding the validity or scope of any There are a number of management objects defined in this MIB that
intellectual property or other rights that might be claimed to pertain have a MAX-ACCESS clause of read-write and/or read-create. Such
to the implementation or use of the technology described in this objects may be considered sensitive or vulnerable in some network
document or the extent to which any license under such rights might or environments. The support for SET operations in a non-secure
might not be available; neither does it represent that it has made any environment without proper protection can have a negative effect on
effort to identify any such rights. Information on the IETF's network operations.
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.
The IETF invites any interested party to bring to its attention any There are a number of managed objects in this MIB that may contain
copyrights, patents or patent applications, or other proprietary rights sensitive information. These are:
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
8. Acknowledgements entPhysicalDescr
entPhysicalVendorType
entPhysicalHardwareRev
entPhysicalFirmwareRev
entPhysicalSoftwareRev
entPhysicalSerialNum
entPhysicalMfgName
entPhysicalModelName
These objects expose information about the physical entities within
a managed system, which may be used to identify the vendor, model,
and version information of each system component.
entPhysicalAssetID
This object can allow asset identifiers for various system
components to be exposed, in the event this MIB object is actually
configured by an NMS application.
entLogicalDescr
entLogicalType
These objects expose the type of logical entities present in the
managed system.
entLogicalCommunity
This object exposes community names associated with particular
logical entities within the system.
entLogicalTAddress
entLogicalTDomain
These objects expose network addresses that can be used to
communicate with an SNMP agent on behalf of particular logical
entities within the system.
entLogicalContextEngineID
entLogicalContextName
These objects identify the authoritative SNMP engine that contains
information on behalf of particular logical entities within the
system.
It is thus important to control even GET access to these objects
and possibly to even encrypt the values of these object when
sending them over the network via SNMP. Not all versions of SNMP
provide features for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is
no control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the
use of the User-based Security Model RFC 2574 [RFC2574] and the
View-based Access Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements
This memo has been produced by the IETF's Entity MIB working group. This memo has been produced by the IETF's Entity MIB working group.
9. Normative References 8. References
8.1. Normative References
[RFC2026] [RFC2026]
Bradner, S., "The Internet Standards Process -- Revision 3", RFC Bradner, S., "The Internet Standards Process -- Revision 3", RFC
2026, October, 1996. 2026, October, 1996.
[RFC2396]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2578] [RFC2578]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Structure of Management Information Version 2 and S. Waldbusser, "Structure of Management Information Version 2
(SMIv2)", STD 58, RFC 2578, April 1999. (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] [RFC2579]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC
2579, April 1999. 2579, April 1999.
skipping to change at page 61, line 19 skipping to change at page 65, line 9
[RFC3411] [RFC3411]
Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing Simple Network Management Protocol (SNMP) Management Describing Simple Network Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002. Frameworks", STD 62, RFC 3411, December 2002.
[RFC3417] [RFC3417]
R. Presuhn, Ed., "Transport Mappings for the Simple Network R. Presuhn, Ed., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
10. Informative References 8.2. Informative References
[RFC1157] [RFC1157]
Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", STD 15, RFC 1157, May 1990. Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1493] [RFC1493]
Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie,
"Definitions of Managed Objects for Bridges", RFC 1493, July, 1993. "Definitions of Managed Objects for Bridges", RFC 1493, July, 1993.
[RFC1516] [RFC1516]
skipping to change at page 63, line 5 skipping to change at page 66, line 5
[RFC2737] [RFC2737]
McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737, McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737,
December 1999. December 1999.
[RFC3410] [RFC3410]
Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and
Applicability Statements for Internet- Standard Management Applicability Statements for Internet- Standard Management
Framework", RFC 3410, December 2002. Framework", RFC 3410, December 2002.
11. Security Considerations Authors' Addresses
There are a number of management objects defined in this MIB that have a
MAX-ACCESS clause of read-write and/or read-create. Such objects may be
considered sensitive or vulnerable in some network environments. The
support for SET operations in a non-secure environment without proper
protection can have a negative effect on network operations.
There are a number of managed objects in this MIB that may contain
sensitive information. These are:
entPhysicalDescr
entPhysicalVendorType
entPhysicalHardwareRev
entPhysicalFirmwareRev
entPhysicalSoftwareRev
entPhysicalSerialNum
entPhysicalMfgName
entPhysicalModelName
These objects expose information about the physical entities within a
managed system, which may be used to identify the vendor, model, and
version information of each system component.
entPhysicalAssetID
This object can allow asset identifiers for various system components to
be exposed, in the event this MIB object is actually configured by an
NMS application.
entLogicalDescr
entLogicalType
These objects expose the type of logical entities present in the managed
system.
entLogicalCommunity
This object exposes community names associated with particular logical
entities within the system.
entLogicalTAddress
entLogicalTDomain
These objects expose network addresses that can be used to communicate
with an SNMP agent on behalf of particular logical entities within the
system.
entLogicalContextEngineID
entLogicalContextName
These objects identify the authoritative SNMP engine that contains
information on behalf of particular logical entities within the system.
It is thus important to control even GET access to these objects and
possibly to even encrypt the values of these object when sending them
over the network via SNMP. Not all versions of SNMP provide features
for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and GET/SET
(read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security features
as provided by the SNMPv3 framework. Specifically, the use of the User-
based Security Model RFC 2574 [RFC2574] and the View-based Access
Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity
giving access to an instance of this MIB, is properly configured to give
access to the objects only to those principals (users) that have
legitimate rights to indeed GET or SET (change/create/delete) them.
12. Authors' Addresses
Andy Bierman Andy Bierman
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
Phone: +1 408-527-3711 Phone: +1 408-527-3711
Email: abierman@cisco.com Email: abierman@cisco.com
Keith McCloghrie Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
Phone: +1 408-526-5260 Phone: +1 408-526-5260
Email: kzm@cisco.com Email: kzm@cisco.com
13. Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it or assurances of licenses to be made available, or the result of an
assist in its implementation may be prepared, copied, published and attempt made to obtain a general license or permission for the use
distributed, in whole or in part, without restriction of any kind, of such proprietary rights by implementers or users of this
provided that the above copyright notice and this paragraph are included specification can be obtained from the IETF on-line IPR repository
on all such copies and derivative works. However, this document itself at http://www.ietf.org/ipr.
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be The IETF invites any interested party to bring to its attention any
revoked by the Internet Society or its successors or assigns. copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
This document and the information contained herein is provided on an "AS Disclaimer of Validity
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT This document and the information contained herein are provided on
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
FITNESS FOR A PARTICULAR PURPOSE. THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/