draft-ietf-entmib-v3-00.txt   draft-ietf-entmib-v3-01.txt 
Entity MIB Working Group Keith McCloghrie Entity MIB Working Group Keith McCloghrie
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Andy Bierman Andy Bierman
Cisco Systems, Inc. Cisco Systems, Inc.
24 June 2002 12 May 2003
Entity MIB (Version 3) Entity MIB (Version 3)
<draft-ietf-entmib-v3-00.txt> <draft-ietf-entmib-v3-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [RFC2026]. provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
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 Distribution of this document is unlimited. Please send comments to the
Entity MIB Working Group, <entmib@ietf.org>. Entity MIB Working Group, <entmib@ietf.org>.
1. Copyright Notice 1. Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
2. Abstract "Abstract"
This memo defines a portion of the Management Information Base (MIB) for This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In use with network management protocols in the Internet community. In
particular, it describes managed objects used for managing multiple particular, it describes managed objects used for managing multiple
logical and physical entities managed by a single SNMP agent. logical and physical entities managed by a single SNMP agent.
3. Table of Contents 2. Table of Contents
1 Copyright Notice ................................................ 1 1 Copyright Notice ................................................ 1
2 Abstract ........................................................ 2 2 Table of Contents ............................................... 2
3 Table of Contents ............................................... 2 3 The SNMP Management Framework ................................... 3
4 The SNMP Management Framework ................................... 3 4 Overview ........................................................ 3
5 Overview ........................................................ 4 4.1 Terms ......................................................... 4
5.1 Terms ......................................................... 5 4.2 Relationship to Community Strings ............................. 5
5.2 Relationship to Community Strings ............................. 6 4.3 Relationship to SNMP Contexts ................................. 6
5.3 Relationship to SNMP Contexts ................................. 6 4.4 Relationship to Proxy Mechanisms .............................. 6
5.4 Relationship to Proxy Mechanisms .............................. 7 4.5 Relationship to a Chassis MIB ................................. 6
5.5 Relationship to a Chassis MIB ................................. 7 4.6 Relationship to the Interfaces MIB ............................ 7
5.6 Relationship to the Interfaces MIB ............................ 7 4.7 Relationship to the Other MIBs ................................ 7
5.7 Relationship to the Other MIBs ................................ 8 4.8 Relationship to Naming Scopes ................................. 7
5.8 Relationship to Naming Scopes ................................. 8 4.9 Multiple Instances of the Entity MIB .......................... 8
5.9 Multiple Instances of the Entity MIB .......................... 8 4.10 Re-Configuration of Entities ................................. 8
5.10 Re-Configuration of Entities ................................. 9 4.11 Textual Convention Change .................................... 9
5.11 Textual Convention Change .................................... 9 4.12 MIB Structure ................................................ 9
5.12 MIB Structure ................................................ 10 4.12.1 entityPhysical Group ....................................... 9
5.12.1 entityPhysical Group ....................................... 10 4.12.2 entityLogical Group ........................................ 10
5.12.2 entityLogical Group ........................................ 11 4.12.3 entityMapping Group ........................................ 11
5.12.3 entityMapping Group ........................................ 12 4.12.4 entityGeneral Group ........................................ 11
5.12.4 entityGeneral Group ........................................ 12 4.12.5 entityNotifications Group .................................. 12
5.12.5 entityNotifications Group .................................. 12 4.13 Multiple Agents .............................................. 12
5.13 Multiple Agents .............................................. 13 4.14 Changes Since RFC 2037 ....................................... 12
5.14 Changes Since RFC 2037 ....................................... 13 4.14.1 Textual Conventions ........................................ 12
5.14.1 Textual Conventions ........................................ 13 4.14.2 New entPhysicalTable Objects ............................... 12
5.14.2 New entPhysicalTable Objects ............................... 13 4.14.3 New entLogicalTable Objects ................................ 13
5.14.3 New entLogicalTable Objects ................................ 13 4.14.4 Bugfixes ................................................... 13
5.14.4 Bugfixes ................................................... 14 4.15 Changes Since RFC 2737 ....................................... 13
5.15 Changes Since RFC 2737 ....................................... 14 4.15.1 Textual Conventions ........................................ 13
5.15.1 Textual Conventions ........................................ 14 4.15.2 Deprecated Objects ......................................... 13
5.15.2 Bugfixes ................................................... 14 4.15.3 Bugfixes ................................................... 13
6 Definitions ..................................................... 15 5 Definitions ..................................................... 14
7 Usage Examples .................................................. 43 6 Usage Examples .................................................. 45
7.1 Router/Bridge ................................................. 43 6.1 Router/Bridge ................................................. 45
7.2 Repeaters ..................................................... 49 6.2 Repeaters ..................................................... 51
8 Intellectual Property ........................................... 57 7 Intellectual Property ........................................... 59
8 Acknowledgements ................................................ 59
9 Acknowledgements ................................................ 57
10 Normative References ........................................... 57
11 Informative References ......................................... 58
12 Security Considerations ........................................ 60
13 Authors' Addresses ............................................. 62
14 Full Copyright Statement ....................................... 63
4. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215].
The second version, called SMIv2, is described in RFC 2578
[RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in RFC 1157 [RFC1157]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
and RFC 1906 [RFC1906]. The third version of the message
protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in RFC 1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[RFC1905].
o A set of fundamental applications described in RFC 2573 9 Normative References ............................................ 59
[RFC2573] and the view-based access control mechanism described 10 Informative References ......................................... 60
in RFC 2575 [RFC2575]. 11 Security Considerations ........................................ 62
12 Authors' Addresses ............................................. 64
13 Full Copyright Statement ....................................... 65
A more detailed introduction to the current SNMP Management Framework 3. The SNMP Management Framework
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed For a detailed overview of the documents that describe the current
the Management Information Base or MIB. Objects in the MIB are Internet-Standard Management Framework, please refer to section 7 of RFC
defined using the mechanisms defined in the SMI. 3410 [RFC3410].
This memo specifies a MIB module that is compliant to the SMIv2. A Managed objects are accessed via a virtual information store, termed the
MIB conforming to the SMIv1 can be produced through the appropriate Management Information Base or MIB. MIB objects are generally accessed
translations. The resulting translated MIB must be semantically through the Simple Network Management Protocol (SNMP). Objects in the
equivalent, except where objects or events are omitted because no MIB are defined using the mechanisms defined in the Structure of
translation is possible (use of Counter64). Some machine readable Management Information (SMI). This memo specifies a MIB module that is
information in SMIv2 will be converted into textual descriptions in compliant to the SMIv2, which is described in STD 58, RFC 2578
SMIv1 during the translation process. However, this loss of machine [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
readable information is not considered to change the semantics of the
MIB.
5. Overview 4. 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 agent
which supports multiple instances of one MIB. This is presently true 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 for at least 3 standard MIBs, and is likely to become true for more and
more MIBs as time passes. For example: 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;
skipping to change at page 5, line 16 skipping to change at page 4, line 23
entities to be referenced in the same SNMP message (although that might entities to be referenced in the same SNMP message (although that might
be useful in the future). Rather, it is sufficient, and in some be useful in the future). Rather, it is sufficient, and in some
situations preferable, to have the context/community in the message situations preferable, to have the context/community in the message
identify the logical entity to which the varbinds apply. 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 since
the publication of the first Entity MIB (RFC 2037 [RFC2037]). There is the publication of the first Entity MIB (RFC 2037 [RFC2037]). There is
a need for a standardized way of providing non-volatile, 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 (RFC 2571 Entity MIB with the SNMPv3 administrative framework (STD 62, RFC 3411
[RFC2571]). Implementation experience has shown that additional physical [RFC3411]). Implementation experience has shown that additional
component attributes are also desirable. 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 since
the publication of the second Entity MIB (RFC 2737 [RFC2737]). There is the publication of the second Entity MIB (RFC 2737 [RFC2737]). There is
a need for identifying physical entities which are central processing a need for identifying physical entities which are central processing
units (CPUs) and a need to provide a textual convention which identifies units (CPUs) and a need to provide a textual convention which identifies
an entPhysicalIndex value or zero, where the value zero has application- an entPhysicalIndex value or zero, where the value zero has application-
specific semantics. specific semantics.
5.1. Terms 4.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
definition of an SNMP context can be found in section 3.3.1 of RFC definition of an SNMP context can be found in section 3.3.1 of RFC
2571 [RFC2571]. 3411 [RFC3411].
- Multi-Scoped Object - Multi-Scoped Object
A MIB object, for which identical instance values identify A MIB object, for which identical instance values identify
different managed information in different naming scopes, is called different managed information in different naming scopes, is called
a "multi-scoped" MIB object. a "multi-scoped" MIB object.
- Single-Scoped Object - Single-Scoped Object
A MIB object, for which identical instance values identify the same A MIB object, for which identical instance values identify the same
managed information in different naming scopes, is called a managed information in different naming scopes, is called a
"single-scoped" MIB object. "single-scoped" MIB object.
skipping to change at page 6, line 32 skipping to change at page 5, line 39
- 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.
5.2. Relationship to Community Strings 4.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 (RFC
1157 [RFC1157]). This is accommodated by representing each community 1157 [RFC1157]). This is accommodated by representing each community
string as a logical entity. 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 scope
(and therefore the same values of entLogicalCommunity). This is (and therefore the same values of entLogicalCommunity). This is
possible, providing they have no need for the same instance of a MIB possible, providing they have no need for the same instance of a MIB
object to represent different managed information. object to represent different managed information.
5.3. Relationship to SNMP Contexts 4.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 SNMP
context associated with a logical entity. This context can be used (in context associated with a logical entity. This context can be used (in
conjunction with the entLogicalTAddress and entLogicalTDomain MIB conjunction with the entLogicalTAddress and entLogicalTDomain MIB
objects) to send SNMPv3 messages on behalf of a particular logical objects) to send SNMPv3 messages on behalf of a particular logical
entity. entity.
5.4. Relationship to Proxy Mechanisms 4.4. Relationship to Proxy Mechanisms
The Entity MIB is designed to allow functional component discovery. The The Entity MIB is designed to allow functional component discovery. The
administrative relationships between different logical entities are not administrative relationships between different logical entities are not
visible in any Entity MIB tables. An NMS cannot determine whether MIB visible in any Entity MIB tables. An NMS cannot determine whether MIB
instances in different naming scopes are realized locally or remotely instances in different naming scopes are realized locally or remotely
(e.g., via some proxy mechanism) by examining any particular Entity MIB (e.g., via some proxy mechanism) by examining any particular Entity MIB
objects. objects.
The management of administrative framework functions is not an explicit The management of administrative framework functions is not an explicit
goal of the Entity MIB WG at this time. This new area of functionality 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 may be revisited after some operational experience with the Entity MIB
is gained. is gained.
Note that for community-based versions of SNMP, a network administrator Note that for community-based versions of SNMP, a network administrator
will likely be able to associate community strings with naming scopes will likely be able to associate community strings with naming scopes
with proprietary mechanisms, as a matter of configuration. There are no with proprietary mechanisms, as a matter of configuration. There are no
mechanisms for managing naming scopes defined in this MIB. mechanisms for managing naming scopes defined in this MIB.
5.5. Relationship to a Chassis MIB 4.5. Relationship to a Chassis MIB
Some readers may recall that a previous IETF working group attempted to Some readers may recall that a previous IETF working group attempted to
define a Chassis MIB. No consensus was reached by that working group, 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 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 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 the scope of this MIB to contain all the information which might be
necessary to manage a "chassis". On the other hand, the entities necessary to manage a "chassis". On the other hand, the entities
represented by an implementation of this MIB might well be contained in represented by an implementation of this MIB might well be contained in
a chassis. a chassis.
5.6. Relationship to the Interfaces MIB 4.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 components
that have 'external values' (e.g., ifIndex) associated with them within that have 'external values' (e.g., ifIndex) associated with them within
a given naming scope. This table can be used to identify the physical a given naming scope. This table can be used to identify the physical
location of each interface in the ifTable (RFC 2233 [RFC2233]). Since location of each interface in the ifTable (RFC 2863 [RFC2863]). Since
ifIndex values in different contexts are not related to one another, the ifIndex values in different contexts are not related to one another, the
interface to physical component associations are relative to the same interface to physical component associations are relative to the same
logical entity within the agent. logical entity within the agent.
The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias' The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias'
objects, which approximate the semantics of the 'ifName' and 'ifAlias' objects, which approximate the semantics of the 'ifName' and 'ifAlias'
objects (respectively) from the Interfaces MIB [RFC2233], for all types objects (respectively) from the Interfaces MIB [RFC2863], for all types
of physical components. of physical components.
5.7. Relationship to the Other MIBs 4.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 components
that have identifiers from other standard MIBs associated with them. that have identifiers from other standard MIBs associated with them.
For example, this table can be used along with the physical mapping For example, this table can be used along with the physical mapping
table to identify the physical location of each repeater port in the table to identify the physical location of each repeater port in the
rptrPortTable, or each interface in the ifTable. rptrPortTable, or each interface in the ifTable.
5.8. Relationship to Naming Scopes 4.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 within a
given naming scope. MIB objects which are not multi-scoped within a given naming scope. MIB objects which are not multi-scoped within a
managed system are likely to ignore context information in 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 scope
or the SNMPv3 default context). 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 the
skipping to change at page 8, line 40 skipping to change at page 8, line 4
information for logical device 'bridge2' may allow access to all the information for logical device 'bridge2' may allow access to all the
non-bridge related objects in the 'default' naming scope, as well as a non-bridge related objects in the 'default' naming scope, as well as a
second instance of the Bridge MIB (RFC 1493 [RFC1493]). second instance of the Bridge MIB (RFC 1493 [RFC1493]).
It is an implementation-specific matter as to the isolation of single- 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 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 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 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 case, all single-scoped management information would belong to a common
naming scope (e.g., 'default'), which itself may contain some multi- naming scope (e.g., 'default'), which itself may contain some multi-
scoped objects (e.g., system group). scoped objects (e.g., system group).
5.9. Multiple Instances of the Entity MIB 4.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, and
in such cases, multiple instances of the Entity MIB (representing the in such cases, multiple instances of the Entity MIB (representing the
same managed objects) may be available to an NMS. 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 even
consistent. An NMS may be able to 'align' instances returned by consistent. An NMS may be able to 'align' instances returned by
different agents by examining the columns of each table, but vendor- different agents by examining the columns of each table, but vendor-
specific identifiers and (especially) index values are likely to be specific identifiers and (especially) index values are likely to be
skipping to change at page 9, line 30 skipping to change at page 8, line 38
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 other
agents. That is, the entLogicalTAddress and entLogicalTDomain objects in agents. That is, the entLogicalTAddress and entLogicalTDomain objects in
the entLogicalTable are provided to support an historical multiplexing the entLogicalTable are provided to support an historical multiplexing
mechanism, not to identify other SNMP agents. 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 agent
represents the MIB in different naming scopes. represents the MIB in different naming scopes.
5.10. Re-Configuration of Entities 4.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-only
MAX-ACCESS clause. This is a conscious decision by the working group to 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 limit this MIB's scope. The second version of the Entity MIB allows a
network administrator to configure some common attributes of physical network administrator to configure some common attributes of physical
components. components.
5.11. Textual Convention Change 4.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 the
(now obsolete) DisplayString textual convention. In version 2 of the (now obsolete) DisplayString textual convention. In version 2 of the
Entity MIB, the syntax for these objects has been updated to use the Entity MIB, the syntax for these objects has been updated to use the
(now preferred) SnmpAdminString textual convention. (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 supported by
SMIv2. In our judgment, the alternative of deprecating the old objects SMIv2. In our judgment, the alternative of deprecating the old objects
and defining new objects would have a more adverse impact on backward and defining new objects would have a more adverse impact on backward
compatibility and interoperability, given the particular semantics of compatibility and interoperability, given the particular semantics of
these objects. these objects.
5.12. MIB Structure 4.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 10, line 30 skipping to change at page 9, line 40
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.
5.12.1. entityPhysical Group 4.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, which
should have an entPhysicalClass value of 'stack(11)', 'chassis(3)' or 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 each
physical entity. Some common read-only attributes have been added, as physical entity. Some common read-only attributes have been added, as
well as three writable string objects. well as three writable string objects.
skipping to change at page 11, line 29 skipping to change at page 10, line 40
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).
5.12.2. entityLogical Group 4.12.2. entityLogical Group
This group contains a single table to identify logical entities, called This group contains a single table to identify logical entities, called
the entLogicalTable. the entLogicalTable.
The entLogicalTable contains one row per logical entity. Each row is The entLogicalTable contains one row per logical entity. Each row is
indexed by an arbitrary, small integer and contains a name, description, indexed by an arbitrary, small integer and contains a name, description,
and type of the logical entity. It also contains information to allow and type of the logical entity. It also contains information to allow
access to the MIB information for the logical entity. This includes SNMP access to the MIB information for the logical entity. This includes SNMP
versions that use a community name (with some form of implied context versions that use a community name (with some form of implied context
representation) and SNMP versions that use the SNMP ARCH [RFC2571]
representation) and SNMP versions that use the SNMP ARCH [RFC3411]
method of context identification. method of context identification.
If a agent represents multiple logical entities with this MIB, then this If a agent represents multiple logical entities with this MIB, then this
group must be implemented for all logical entities known to the agent. 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 group
may be omitted by the agent. may be omitted by the agent.
5.12.3. entityMapping Group 4.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 values
(logical entities) and entPhysicalIndex values (the physical components (logical entities) and entPhysicalIndex values (the physical components
supporting that entity). A logical entity can map to more than one supporting that entity). A logical entity can map to more than one
physical component, and more than one logical entity can map to (share) physical component, and more than one logical entity can map to (share)
the same physical component. If an agent represents a single logical the same physical component. If an agent represents a single logical
entity, or multiple logical entities within a single naming scope, then entity, or multiple logical entities within a single naming scope, then
implementation of this table may be omitted by the agent. implementation of this table may 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, bridge
ports, physical and logical interfaces) to be identified in the physical ports, physical and logical interfaces) to be identified in the physical
entity hierarchy. Note that each alias identifier is only relevant in a entity hierarchy. Note that each alias identifier is only relevant in a
particular naming scope. If an agent represents a single logical particular naming scope. If an agent represents a single logical
entity, or multiple logical entities within a single naming scope, then entity, or multiple logical entities within a single naming scope, then
implementation of this table may be omitted by the agent. implementation of this table may be 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 allows an
NMS to quickly discover the 'entPhysicalIndex' values for all children NMS to quickly discover the 'entPhysicalIndex' values for all children
of a given physical entity. of a given physical entity.
5.12.4. entityGeneral Group 4.12.4. entityGeneral Group
This group contains general information relating to the other object This group contains general information relating to the other object
groups. 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 any
part of the Entity MIB configuration last changed. part of the Entity MIB configuration last changed.
5.12.5. entityNotifications Group 4.12.5. entityNotifications Group
This group contains notification definitions relating to the overall This group contains notification definitions relating to the overall
status of the Entity MIB instantiation. status of the Entity MIB instantiation.
5.13. Multiple Agents 4.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 by
multiple agents (in the same "overall" physical entity). Indeed, it is multiple agents (in the same "overall" physical entity). Indeed, it is
implicit in the SNMP architecture, that the number of agents is implicit in the SNMP architecture, that the number of agents is
transparent to a network management station. 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 to
implement the Entity MIB independently. (Refer the section on "Multiple implement the Entity MIB independently. (Refer the section on "Multiple
Instances of the Entity MIB" for more details). Instances of the Entity MIB" for more details).
5.14. Changes Since RFC 2037 4.14. Changes Since RFC 2037
5.14.1. Textual Conventions 4.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 to
support 'stackable' components has been added. The SnmpEngineIdOrNone support 'stackable' components has been added. The SnmpEngineIdOrNone
TC has been added to support SNMPv3. TC has been added to support SNMPv3.
5.14.2. New entPhysicalTable Objects 4.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, and
entPhysicalIsFru objects have been added for better vendor entPhysicalIsFru objects have been added for better vendor
identification for physical components. The entPhysicalSerialNum object identification for physical components. The entPhysicalSerialNum object
can be set by a management station in the event the agent cannot can be set by a management station in the event the agent cannot
identify this information. identify this information.
The entPhysicalAlias and entPhysicalAssetID objects have been added for The entPhysicalAlias and entPhysicalAssetID objects have been added for
better user component identification. These objects are intended to be better user component identification. These objects are intended to be
set by a management station and preserved by the agent across restarts. set by a management station and preserved by the agent across restarts.
5.14.3. New entLogicalTable Objects 4.14.3. New entLogicalTable Objects
The entLogicalContextEngineID and entLogicalContextName objects have The entLogicalContextEngineID and entLogicalContextName objects have
been added to provide an SNMP context for SNMPv3 access on behalf of a been added to provide an SNMP context for SNMPv3 access on behalf of a
logical entity. logical entity.
5.14.4. Bugfixes 4.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 also
been clarified. This object is now deprecated. been clarified. This object is now deprecated.
The entLastChangeTime object description has been changed to generalize The entLastChangeTime object description has been changed to generalize
the events which cause an update to the last change timestamp. 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 the
entPhysicalDescr, entPhysicalName, and entLogicalDescr objects. entPhysicalDescr, entPhysicalName, and entLogicalDescr objects.
5.15. Changes Since RFC 2737 4.15. Changes Since RFC 2737
5.15.1. Textual Conventions 4.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 reference
an entPhysicalIndex value or zero. The PhysicalClass TC has been an entPhysicalIndex value or zero. The PhysicalClass TC has been
extended to support a new enumeration for central processing units. extended to support a new enumeration for central processing units.
5.15.2. Bugfixes 4.15.2. Deprecated Objects
The syntax was changed from INTEGER to Integer32 for the PhysicalClass The entLPMappingTable has been deprecated because no implementations
TC and the entPhysicalContainedIn, entPhysicalParentRelPos, have been found which support this table. The entLPPhysicalIndex has
entLogicalIndex, and entAliasLogicalIndexOrZero objects. been removed from the entityMappingGroup. This OBJECT-GROUP has been
updated (entityMappingGroupRev1) as well as the Entity MIB MODULE-
CONFORMANCE statement.
6. Definitions 4.15.3. Bugfixes
The syntax was changed from INTEGER to Integer32 for the
entPhysicalContainedIn, entPhysicalParentRelPos, entLogicalIndex, and
entAliasLogicalIndexOrZero objects.
5. 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
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 "200206210000Z" LAST-UPDATED "200305110000Z"
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
Keith McCloghrie Keith McCloghrie
ENTMIB Working Group Chair
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
Andy Bierman Andy Bierman
ENTMIB Working Group Editor
Cisco Systems Inc. Cisco Systems Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
+1 408-527-3711 +1 408-527-3711
abierman@cisco.com" abierman@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."
REVISION "200206210000Z" REVISION "200305110000Z"
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
Changes:
- entLPMappingTable deprecated
This version published as RFC xxxx (to be This version published as RFC xxxx (to be
assigned by the RFC Editor)." assigned by the RFC Editor)."
REVISION "9610310000Z" REVISION "9610310000Z"
DESCRIPTION DESCRIPTION
"Initial version (version 1), published as "Initial version (version 1), published as
RFC 2037." RFC 2037."
::= { mib-2 47 } ::= { mib-2 47 }
entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 }
skipping to change at page 19, line 9 skipping to change at page 18, line 9
} }
SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A specially formatted SnmpEngineID string for use with the "A specially formatted SnmpEngineID string for use with the
Entity MIB. Entity MIB.
If an instance of an object of SYNTAX SnmpEngineIdOrNone has If an instance of an object of SYNTAX SnmpEngineIdOrNone has
a non-zero length, then the object encoding and semantics a non-zero length, then the object encoding and semantics
are defined by the SnmpEngineID textual convention (see RFC are defined by the SnmpEngineID textual convention (see STD
2571 [RFC2571]). 62, RFC 3411 [RFC3411]).
If an instance of an object of SYNTAX SnmpEngineIdOrNone If an instance of an object of SYNTAX SnmpEngineIdOrNone
contains a zero-length string, then no appropriate contains a zero-length string, then no appropriate
SnmpEngineID is associated with the logical entity (i.e., SnmpEngineID is associated with the logical entity (i.e.,
SNMPv3 not supported)." SNMPv3 not supported)."
SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID
-- The Physical Entity Table -- The Physical Entity Table
entPhysicalTable OBJECT-TYPE entPhysicalTable OBJECT-TYPE
SYNTAX SEQUENCE OF EntPhysicalEntry SYNTAX SEQUENCE OF EntPhysicalEntry
skipping to change at page 31, line 26 skipping to change at page 30, line 26
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The transport service address by which the logical entity "The transport service address by which the logical entity
receives network management traffic, formatted according to receives network management traffic, formatted according to
the corresponding value of entLogicalTDomain. the corresponding value of entLogicalTDomain.
For snmpUDPDomain, a TAddress is 6 octets long, the initial For snmpUDPDomain, a TAddress is 6 octets long, the initial
4 octets containing the IP-address in network-byte order and 4 octets containing the IP-address in network-byte order and
the last 2 containing the UDP port in network-byte order. the last 2 containing the UDP port in network-byte order.
Consult 'Transport Mappings for Version 2 of the Simple Consult 'Transport Mappings for the Simple Network
Network Management Protocol' (RFC 1906 [RFC1906]) for Management Protocol' (STD 62, RFC 3417 [RFC3417]) for
further information on snmpUDPDomain." further information on snmpUDPDomain."
::= { entLogicalEntry 5 } ::= { entLogicalEntry 5 }
entLogicalTDomain OBJECT-TYPE entLogicalTDomain OBJECT-TYPE
SYNTAX TDomain SYNTAX TDomain
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Indicates the kind of transport service by which the "Indicates the kind of transport service by which the
logical entity receives network management traffic. logical entity receives network management traffic.
Possible values for this object are presently found in the Possible values for this object are presently found in the
Transport Mappings for SNMPv2 document (RFC 1906 Transport Mappings for Simple Network Management Protocol'
[RFC1906])." (STD 62, RFC 3417 [RFC3417])."
::= { entLogicalEntry 6 } ::= { entLogicalEntry 6 }
entLogicalContextEngineID OBJECT-TYPE entLogicalContextEngineID OBJECT-TYPE
SYNTAX SnmpEngineIdOrNone SYNTAX SnmpEngineIdOrNone
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The authoritative contextEngineID that can be used to send "The authoritative contextEngineID that can be used to send
an SNMP message concerning information held by this logical an SNMP message concerning information held by this logical
entity, to the address specified by the associated entity, to the address specified by the associated
skipping to change at page 32, line 42 skipping to change at page 31, line 42
contextName pair. contextName pair.
If no value has been configured by the agent, a zero-length If no value has been configured by the agent, a zero-length
string is returned, or the agent may choose not to string is returned, or the agent may choose not to
instantiate this object at all." instantiate this object at all."
::= { entLogicalEntry 8 } ::= { entLogicalEntry 8 }
entLPMappingTable OBJECT-TYPE entLPMappingTable OBJECT-TYPE
SYNTAX SEQUENCE OF EntLPMappingEntry SYNTAX SEQUENCE OF EntLPMappingEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS deprecated
DESCRIPTION DESCRIPTION
"This table contains zero or more rows of logical entity to "This table contains zero or more rows of logical entity to
physical equipment associations. For each logical entity physical equipment associations. For each logical entity
known by this agent, there are zero or more mappings to the known by this agent, there are zero or more mappings to the
physical resources which are used to realize that logical physical resources which are used to realize that logical
entity. entity.
An agent should limit the number and nature of entries in An agent should limit the number and nature of entries in
this table such that only meaningful and non-redundant this table such that only meaningful and non-redundant
information is returned. For example, in a system which information is returned. For example, in a system which
skipping to change at page 33, line 34 skipping to change at page 32, line 34
each bridge and the ports it used would be appropriate. each bridge and the ports it used would be appropriate.
Also, in the case of a single backplane repeater, a mapping Also, in the case of a single backplane repeater, a mapping
for the backplane to the single repeater entity is not for the backplane to the single repeater entity is not
necessary." necessary."
::= { entityMapping 1 } ::= { entityMapping 1 }
entLPMappingEntry OBJECT-TYPE entLPMappingEntry OBJECT-TYPE
SYNTAX EntLPMappingEntry SYNTAX EntLPMappingEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS deprecated
DESCRIPTION DESCRIPTION
"Information about a particular logical entity to physical "Information about a particular logical entity to physical
equipment association. Note that the nature of the equipment association. Note that the nature of the
association is not specifically identified in this entry. association is not specifically identified in this entry.
It is expected that sufficient information exists in the It is expected that sufficient information exists in the
MIBs used to manage a particular logical entity to infer how MIBs used to manage a particular logical entity to infer how
physical component information is utilized." physical component information is utilized."
INDEX { entLogicalIndex, entLPPhysicalIndex } INDEX { entLogicalIndex, entLPPhysicalIndex }
::= { entLPMappingTable 1 } ::= { entLPMappingTable 1 }
EntLPMappingEntry ::= SEQUENCE { EntLPMappingEntry ::= SEQUENCE {
entLPPhysicalIndex PhysicalIndex entLPPhysicalIndex PhysicalIndex
} }
entLPPhysicalIndex OBJECT-TYPE entLPPhysicalIndex OBJECT-TYPE
SYNTAX PhysicalIndex SYNTAX PhysicalIndex
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS deprecated
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
skipping to change at page 39, line 16 skipping to change at page 38, line 16
MANDATORY-GROUPS { MANDATORY-GROUPS {
entityPhysicalGroup, entityPhysicalGroup,
entityLogicalGroup, entityLogicalGroup,
entityMappingGroup, entityMappingGroup,
entityGeneralGroup, entityGeneralGroup,
entityNotificationsGroup entityNotificationsGroup
} }
::= { entityCompliances 1 } ::= { entityCompliances 1 }
entity2Compliance MODULE-COMPLIANCE entity2Compliance MODULE-COMPLIANCE
STATUS current STATUS deprecated
DESCRIPTION DESCRIPTION
"The compliance statement for SNMP entities which implement "The compliance statement for SNMP entities which implement
version 2 of the Entity MIB." version 2 of the Entity MIB."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { MANDATORY-GROUPS {
entityPhysicalGroup, entityPhysicalGroup,
entityPhysical2Group, entityPhysical2Group,
entityGeneralGroup, entityGeneralGroup,
entityNotificationsGroup entityNotificationsGroup
} }
skipping to change at page 40, line 32 skipping to change at page 39, line 32
OBJECT entPhysicalAssetID OBJECT entPhysicalAssetID
MIN-ACCESS not-accessible MIN-ACCESS not-accessible
DESCRIPTION DESCRIPTION
"Read and write access is not required for agents which "Read and write access is not required for agents which
cannot provide non-volatile storage for NMS-assigned asset cannot provide non-volatile storage for NMS-assigned asset
identifiers. identifiers.
Write access is not required for physical entities for which Write access is not required for physical entities for which
the associated value of entPhysicalIsFRU is equal to the associated value of entPhysicalIsFRU is equal to
'false(2)'." 'false(2)'."
OBJECT entPhysicalClass
SYNTAX INTEGER {
other(1),
unknown(2),
chassis(3),
backplane(4),
container(5),
powerSupply(6),
fan(7),
sensor(8),
module(9),
port(10),
stack(11)
}
DESCRIPTION
"Implementation of the 'cpu(12)' enumeration is not
required."
::= { entityCompliances 2 } ::= { entityCompliances 2 }
entity3Compliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which implement
version 3 of the Entity MIB."
MODULE -- this module
MANDATORY-GROUPS {
entityPhysicalGroup,
entityPhysical2Group,
entityGeneralGroup,
entityNotificationsGroup
}
GROUP entityLogical2Group
DESCRIPTION
"Implementation of this group is not mandatory for agents
which model all MIB object instances within a single naming
scope."
GROUP entityMappingGroupRev1
DESCRIPTION
"Implementation of the entPhysicalContainsTable is mandatory
for all agents. Implementation of the entAliasMappingTable
is not mandatory for agents which model all MIB object
instances within a single naming scope.
Note that the entAliasMappingTable may be useful for all
agents, however implementation of the entityLogicalGroup or
entityLogical2Group is required to support this table."
OBJECT entPhysicalSerialNum
MIN-ACCESS not-accessible
DESCRIPTION
"Read and write access is not required for agents which
cannot identify serial number information for physical
entities, and/or cannot provide non-volatile storage for
NMS-assigned serial numbers.
Write access is not required for agents which can identify
serial number information for physical entities, but cannot
provide non-volatile storage for NMS-assigned serial
numbers.
Write access is not required for physical entities for
physical entities for which the associated value of the
entPhysicalIsFRU object is equal to 'false(2)'."
OBJECT entPhysicalAlias
MIN-ACCESS read-only
DESCRIPTION
"Write access is required only if the associated
entPhysicalClass value is equal to 'chassis(3)'."
OBJECT entPhysicalAssetID
MIN-ACCESS not-accessible
DESCRIPTION
"Read and write access is not required for agents which
cannot provide non-volatile storage for NMS-assigned asset
identifiers.
Write access is not required for physical entities for which
the associated value of entPhysicalIsFRU is equal to
'false(2)'."
::= { entityCompliances 3 }
-- MIB groupings -- MIB groupings
entityPhysicalGroup OBJECT-GROUP entityPhysicalGroup OBJECT-GROUP
OBJECTS { OBJECTS {
entPhysicalDescr, entPhysicalDescr,
entPhysicalVendorType, entPhysicalVendorType,
entPhysicalContainedIn, entPhysicalContainedIn,
entPhysicalClass, entPhysicalClass,
entPhysicalParentRelPos, entPhysicalParentRelPos,
entPhysicalName entPhysicalName
} }
skipping to change at page 41, line 28 skipping to change at page 42, line 22
list of logical entities for which a single agent provides list of logical entities for which a single agent provides
management information." management information."
::= { entityGroups 2 } ::= { entityGroups 2 }
entityMappingGroup OBJECT-GROUP entityMappingGroup OBJECT-GROUP
OBJECTS { OBJECTS {
entLPPhysicalIndex, entLPPhysicalIndex,
entAliasMappingIdentifier, entAliasMappingIdentifier,
entPhysicalChildIndex entPhysicalChildIndex
} }
STATUS current STATUS deprecated
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 3 } ::= { entityGroups 3 }
entityGeneralGroup OBJECT-GROUP entityGeneralGroup OBJECT-GROUP
OBJECTS { OBJECTS {
entLastChangeTime entLastChangeTime
skipping to change at page 42, line 46 skipping to change at page 43, line 41
entLogicalContextEngineID, entLogicalContextEngineID,
entLogicalContextName entLogicalContextName
} }
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
OBJECTS {
entAliasMappingIdentifier,
entPhysicalChildIndex
}
STATUS current
DESCRIPTION
"The collection of objects which are used to represent the
associations between multiple logical entities, physical
components, interfaces, and port identifiers for which a
single agent provides management information."
::= { entityGroups 8 }
END END
7. Usage Examples 6. 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 more
understandable. Auxiliary components, such as fans, sensors, empty understandable. Auxiliary components, such as fans, sensors, empty
slots, and sub-modules are not shown, but might be modeled in real slots, and sub-modules are not shown, but might be modeled in real
implementations. implementations.
7.1. Router/Bridge 6.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. There
are two logical instances of OSPF running and two logical bridges: 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
skipping to change at page 49, line 32 skipping to change at page 51, 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
7.2. Repeaters 6.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 empty,
and the remaining slots contain ethernet repeater modules. 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 implementation,
(RFC 1516 [RFC1516]) rather than the new Repeater MIB (RFC 2108 (RFC 1516 [RFC1516]) rather than the new Repeater MIB (RFC 2108
[RFC2108]). The new version contains an object called 'rptrPortRptrId', [RFC2108]). The new version contains an object called 'rptrPortRptrId',
which should be used to identify repeater port groupings, rather than which should be used to identify repeater port groupings, rather than
with community strings or contexts. with community strings or contexts.
skipping to change at page 57, line 5 skipping to change at page 59, 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
8. Intellectual Property 7. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to rights made available for publication and any assurances of licenses to
skipping to change at page 57, line 27 skipping to change at page 59, line 27
license or permission for the use of such proprietary rights by license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the implementors or users of this specification can be obtained from the
IETF Secretariat. IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive standard. Please address the information to the IETF Executive
Director. Director.
9. Acknowledgements 8. 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.
10. Normative References 9. Normative References
[RFC1905]
Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, January 1996.
[RFC1906]
Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[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.
[RFC2571]
Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[RFC2572]
Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[RFC2573]
Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
2573, April 1999.
[RFC2574]
Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC
2574, April 1999.
[RFC2575]
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.
[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)", RFC 2578, STD 58, 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", RFC 2579, STD and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC
58, April 1999. 2579, April 1999.
[RFC2580] [RFC2580]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC
STD 58, April 1999. 2580, April 1999.
11. Informative References [RFC3411]
Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing Simple Network Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[RFC1155] [RFC3417]
Rose, M., and K. McCloghrie, "Structure and Identification of R. Presuhn, Ed., "Transport Mappings for the Simple Network
Management Information for TCP/IP-based Internets", RFC 1155, STD Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
16, May 1990.
10. 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", RFC 1157, STD 15, May 1990. Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1212]
Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212,
STD 16, March 1991.
[RFC1215]
M. Rose, "A Convention for Defining Traps for use with the SNMP",
RFC 1215, March 1991.
[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]
McMaster, D., and K. McCloghrie, "Definitions of Managed Objects McMaster, D., and K. McCloghrie, "Definitions of Managed Objects
for IEEE 802.3 Repeater Devices", RFC 1516, September, 1993. for IEEE 802.3 Repeater Devices", RFC 1516, September, 1993.
[RFC1901]
Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC2037] [RFC2037]
McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2", RFC 2037, McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2", RFC 2037,
October 1996. October 1996.
[RFC2108] [RFC2108]
de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie,
"Definitions of Managed Objects for IEEE 802.3 Repeater Devices "Definitions of Managed Objects for IEEE 802.3 Repeater Devices
using SMIv2", RFC 2108, February, 1997. using SMIv2", RFC 2108, February, 1997.
[RFC2233] [RFC2863]
McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB Using McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC
SMIv2", RFC 2233, November, 1997. 2863, June, 2000.
[RFC2570]
Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to
Version 3 of the Internet-standard Network Management Framework",
RFC 2570, April 1999.
[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.
12. Security Considerations [RFC3410]
Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and
Applicability Statements for Internet- Standard Management
Framework", RFC 3410, December 2002.
11. Security Considerations
There are a number of management objects defined in this MIB that have a 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 MAX-ACCESS clause of read-write and/or read-create. Such objects may be
considered sensitive or vulnerable in some network environments. The considered sensitive or vulnerable in some network environments. The
support for SET operations in a non-secure environment without proper support for SET operations in a non-secure environment without proper
protection can have a negative effect on network operations. protection can have a negative effect on network operations.
There are a number of managed objects in this MIB that may contain There are a number of managed objects in this MIB that may contain
sensitive information. These are: sensitive information. These are:
skipping to change at page 62, line 5 skipping to change at page 64, line 5
It is recommended that the implementers consider the security features It is recommended that the implementers consider the security features
as provided by the SNMPv3 framework. Specifically, the use of the User- as provided by the SNMPv3 framework. Specifically, the use of the User-
based Security Model RFC 2574 [RFC2574] and the View-based Access based Security Model RFC 2574 [RFC2574] and the View-based Access
Control Model RFC 2575 [RFC2575] is recommended. Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity 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 giving access to an instance of this MIB, is properly configured to give
access to the objects only to those principals (users) that have access to the objects only to those principals (users) that have
legitimate rights to indeed GET or SET (change/create/delete) them. legitimate rights to indeed GET or SET (change/create/delete) them.
13. Authors' Addresses 12. Authors' Addresses
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
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
14. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
 End of changes. 

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