draft-ietf-entmib-entmib-06.txt   rfc2037.txt 
<draft-ietf-entmib-entmib-06.txt> Network Working Group K. McCloghrie
Entity MIB Request for Comments: 2037 A. Bierman
Category: Standards Track Cisco Systems
18 June 1996 October 1996
Keith McCloghrie
Cisco Systems Inc.
kzm@cisco.com
Andy Bierman
Cisco Systems Inc.
abierman@cisco.com
Status of this Memo Entity MIB using SMIv2
This document is an Internet-Draft. Internet-Drafts are working Status of this Memo
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet- Drafts as reference material improvements. Please refer to the current edition of the "Internet
or to cite them other than as ``work in progress.'' Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
To learn the current status of any Internet-Draft, please check the Table of Contents
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Draft Entity MIB June 1996 1. Introduction .............................................. 2
2. The SNMP Network Management Framework ..................... 2
2.1 Object Definitions ....................................... 2
3. Overview .................................................. 3
3.1 Terms .................................................... 4
3.2 Relationship to Community Strings ........................ 5
3.3 Relationship to Proxy Mechanisms ......................... 5
3.4 Relationship to a Chassis MIB ............................ 5
3.5 Relationship to the Interfaces MIB ....................... 6
3.6 Relationship to the Other MIBs ........................... 6
3.7 Relationship to Naming Scopes ............................ 6
3.8 Multiple Instances of the Entity MIB ..................... 7
3.9 Re-Configuration of Entities ............................. 7
3.10 MIB Structure ........................................... 7
3.10.1 entityPhysical Group .................................. 8
3.10.2 entityLogical Group ................................... 8
3.10.3 entityMapping Group ................................... 8
3.10.4 entityGeneral Group ................................... 9
3.10.5 entityNotifications Group ............................. 9
3.11 Multiple Agents ......................................... 9
4. Definitions ............................................... 10
5. Usage Examples ............................................ 26
5.1 Router/Bridge ............................................ 26
5.2 Repeaters ................................................ 30
6. Acknowledgements .......................................... 33
7. References ................................................ 34
8. Security Considerations ................................... 35
9. Authors' Addresses ........................................ 35
1. Introduction 1. Introduction
This memo defines an experimental portion of the Management Information This memo defines a portion of the Management Information Base (MIB)
Base (MIB) for use with network management protocols in the Internet for use with network management protocols in the Internet community.
community. In particular, it describes managed objects used for In particular, it describes managed objects used for managing
managing multiple logical and physical entities managed by a single SNMP multiple logical and physical entities managed by a single SNMP
agent. agent.
Draft Entity MIB June 1996
2. The SNMP Network Management Framework 2. The SNMP Network Management Framework
The SNMP Network Management Framework presently consists of three major The SNMP Network Management Framework presently consists of three
components. They are: major components. They are:
o the SMI, described in RFC 1902 [1], - the mechanisms used for o the SMI, described in RFC 1902 [1], - the mechanisms used for
describing and naming objects for the purpose of management. describing and naming objects for the purpose of management.
o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed objects o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed
for the Internet suite of protocols. objects for the Internet suite of protocols.
o the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the protocol for o the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the protocol
accessing managed information. for accessing managed information.
Textual conventions are defined in RFC 1903 [3], and conformance Textual conventions are defined in RFC 1903 [3], and conformance
statements are defined in RFC 1904 [5]. statements are defined in RFC 1904 [5].
The Framework permits new objects to be defined for the purpose of The Framework permits new objects to be defined for the purpose of
experimentation and evaluation. experimentation and evaluation.
This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A This memo specifies a MIB module that is compliant to the SNMPv2 SMI.
semantically identical MIB conforming to the SNMPv1 SMI can be produced A semantically identical MIB conforming to the SNMPv1 SMI can be
through the appropriate translation. produced through the appropriate translation.
2.1. Object Definitions 2.1. Object Definitions
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed
Management Information Base or MIB. Objects in the MIB are defined the Management Information Base or MIB. Objects in the MIB are
using the subset of Abstract Syntax Notation One (ASN.1) defined in the defined using the subset of Abstract Syntax Notation One (ASN.1)
SMI. In particular, each object type is named by an OBJECT IDENTIFIER, defined in the SMI. In particular, each object type is named by an
an administratively assigned name. The object type together with an OBJECT IDENTIFIER, an administratively assigned name. The object
object instance serves to uniquely identify a specific instantiation of type together with an object instance serves to uniquely identify a
the object. For human convenience, we often use a textual string, specific instantiation of the object. For human convenience, we
termed the descriptor, to refer to the object type. often use a textual string, termed the descriptor, to refer to the
object type.
Draft Entity MIB June 1996
3. Overview 3. 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
more MIBs as time passes. For example: 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
having a single agent; device 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
Autonomous System, and each identified by the same area-id (e.g., of its own Autonomous System, and each identified by the
0.0.0.0), supported inside a single router with one agent. same area-id (e.g., 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 which
sum of the things managed by that one agent, i.e., there are multiple houses the sum of the things managed by that one agent, i.e., there
"logical" entities within a single physical entity. Sometimes, the are multiple "logical" entities within a single physical entity.
overall physical entity contains multiple (smaller) physical entities Sometimes, the overall physical entity contains multiple (smaller)
and each logical entity is associated with a particular physical entity. physical entities and each logical entity is associated with a
Sometimes, the overall physical entity is a "compound" of multiple particular physical entity. Sometimes, the overall physical entity
physical entities (e.g., a stack of stackable hubs). is a "compound" of multiple physical entities (e.g., a stack 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 (either by SNMPv1 or SNMPv2), and thereby to be are managed by the agent (either by SNMPv1 or SNMPv2), and thereby to
able to communicate with the agent about a particular logical entity. be able to communicate with the agent about a particular logical
When 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 is
able to use this information to distinguish between logical entities. 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 (although
be useful in the future). Rather, it is sufficient, and in some that might be useful in the future). Rather, it is sufficient, and
situations preferable, to have the context/community in the message in some situations preferable, to have the context/community in the
identify the logical entity to which the varbinds apply. message identify the logical entity to which the varbinds apply.
3.1. Terms 3.1. Terms
Some new terms are used throughout this document: Some new terms are used throughout this document:
Draft Entity MIB June 1996
- 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. For within the naming scope share the same unique identifier space. For
SNMPv1, a naming scope is identified by the value of the associated SNMPv1, a naming scope is identified by the value of the associated
'entLogicalCommunity' instance. 'entLogicalCommunity' instance.
- Multi-Scoped Object - Multi-Scoped Object
A MIB object, for which identical instance values identify A MIB object, for which identical instance values identify
skipping to change at page 6, line 5 skipping to change at page 5, line 5
- Containment Tree - Containment Tree
Each physical component may optionally be modeled as 'contained' Each physical component may optionally be modeled as 'contained'
within another physical component. A "containment-tree" is the within another physical component. A "containment-tree" is the
conceptual sequence of entPhysicalIndex values which uniquely conceptual sequence of entPhysicalIndex values which uniquely
specifies the exact physical location of a physical component specifies the exact physical location of a physical component
within the managed system. It is generated by 'following and within the managed system. It is generated by 'following and
recording' each 'entPhysicalContainedIn' instance 'up the tree recording' each 'entPhysicalContainedIn' instance 'up the tree
towards the root', until a value of zero indicating no further towards the root', until a value of zero indicating no further
containment is found. containment is found.
Draft Entity MIB June 1996
Note that chassis slots, which are capable of accepting one or more Note that chassis slots, which are capable of accepting one or more
module types from one or more vendors, are modeled as containers in module types from one or more vendors, are modeled as containers in
this MIB. The value of entPhysicalContainedIn for a particular this MIB. The value of entPhysicalContainedIn for a particular
'module' entity (entPhysicalClass value of 'module(9)') must be 'module' entity (entPhysicalClass value of 'module(9)') must be
equal to an entPhysicalIndex that represents the parent 'container' equal to an entPhysicalIndex that represents the parent 'container'
entity (associated entPhysicalClass value of ('container(5)'). An entity (associated entPhysicalClass value of ('container(5)'). An
agent must represent both empty and full containers in the agent must represent both empty and full containers in the
entPhysicalTable. entPhysicalTable.
3.2. Relationship to Community Strings 3.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 [6]. entities is one (but not the only) purpose of the community string
This is accommodated by representing each community string as a logical [6]. This is accommodated by representing each community string as a
entity. 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.
3.3. Relationship to Proxy Mechanisms 3.3. 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.
administrative relationships between different logical entities are not The administrative relationships between different logical entities
visible in any Entity MIB tables. An NMS cannot determine whether MIB are not visible in any Entity MIB tables. An NMS cannot determine
instances in different naming scopes are realized locally or remotely whether MIB instances in different naming scopes are realized locally
(e.g. via some proxy mechanism) by examining any particular Entity MIB or remotely (e.g. via some proxy mechanism) by examining any
objects. particular Entity MIB objects.
The management of administrative framework functions is not an explicit
goal of the Entity MIB WG at this time. This new area of functionality
may be revisited after some operational experience with the Entity MIB
is gained.
Note that a network administrator will likely be able to associate The management of administrative framework functions is not an
community strings with naming scopes with proprietary mechanisms, as a explicit goal of the Entity MIB WG at this time. This new area of
matter of configuration. There are no mechanisms for managing naming functionality may be revisited after some operational experience with
scopes defined in this MIB. the Entity MIB is gained.
Draft Entity MIB June 1996 Note that 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.
3.4. Relationship to a Chassis MIB 3.4. 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
define a Chassis MIB. No consensus was reached by that working group, to define a Chassis MIB. No consensus was reached by that working
possibly because its scope was too broad. As such, it is not the group, possibly because its scope was too broad. As such, it is not
purpose of this MIB to be a "Chassis MIB replacement", nor is it within the purpose of this MIB to be a "Chassis MIB replacement", nor is it
the scope of this MIB to contain all the information which might be within the scope of this MIB to contain all the information which
necessary to manage a "chassis". On the other hand, the entities might be necessary to manage a "chassis". On the other hand, the
represented by an implementation of this MIB might well be contained in entities represented by an implementation of this MIB might well be
a chassis. contained in a chassis.
3.5. Relationship to the Interfaces MIB 3.5. 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 a components that have 'external values' (e.g. ifIndex) associated with
given naming scope. This table can be used to identify the physical them within a given naming scope. This table can be used to identify
location of each interface in the ifTable [7]. Since ifIndex values in the physical location of each interface in the ifTable [7]. Since
different contexts are not related to one another, the interface to ifIndex values in different contexts are not related to one another,
physical component associations are relative to the same logical entity the interface to physical component associations are relative to the
within the agent. same logical entity within the agent.
The Entity MIB also contains an 'entPhysicalName' object, which The Entity MIB also contains an 'entPhysicalName' object, which
approximates the semantics of the ifName object from the Interfaces MIB approximates the semantics of the ifName object from the Interfaces
[7] for all types of physical components. MIB [7] for all types of physical components.
3.6. Relationship to the Other MIBs 3.6. 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 associated
For example, this table can be used along with the physical mapping with them. For example, this table can be used along with the
table to identify the physical location of each repeater port in the physical mapping table to identify the physical location of each
rptrPortTable, or each interface in the ifTable. repeater port in the rptrPortTable, or each interface in the ifTable.
3.7. Relationship to Naming Scopes 3.7. 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
given naming scope. MIB objects which are not multi-scoped within a 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 'main' naming scope). returned in all naming scopes (e.g. not just the 'main' naming
scope).
For example, a community string used to access the management
Draft Entity MIB June 1996
information for logical device 'bridge2' may allow access to all the For example, a community string used to access the management
non-bridge related objects in the 'main' naming scope, as well as a information for logical device 'bridge2' may allow access to all the
second instance of the Bridge MIB. non-bridge related objects in the 'main' naming scope, as well as a
second instance of the Bridge MIB.
It is an implementation-specific matter as to the isolation of single- It is an implementation-specific matter as to the isolation of
scoped MIB objects by the agent. An agent may wish to limit the objects single-scoped MIB objects by the agent. An agent may wish to limit
returned in a particular naming scope to just the multi-scoped objects the objects returned in a particular naming scope to just the multi-
in that naming scope (e.g. system group and the Bridge MIB). In this scoped objects in that naming scope (e.g. system group and the Bridge
case, all single-scoped management information would belong to a common MIB). In this case, all single-scoped management information would
naming scope (e.g. 'main'), which itself may contain some multi-scoped belong to a common naming scope (e.g. 'main'), which itself may
objects (e.g. system group). contain some multi-scoped objects (e.g. system group).
3.8. Multiple Instances of the Entity MIB 3.8. 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 (representing
same managed objects) may be available to an NMS. the same managed objects) may be available to an NMS.
In order to reduce complexity for agent implementation, multiple
instances of the Entity MIB are not required to be equivalent or even
consistent. An NMS may be able to 'align' instances returned by
different agents by examining the columns of each table, but vendor-
specific identifiers and (especially) index values are likely to be
different. Each agent may be managing different subsets of the entire
chassis as well.
When all of a physically-modular device is represented by a single In order to reduce complexity for agent implementation, multiple
agent, the entry for which entPhysicalContainedIn has the value zero instances of the Entity MIB are not required to be equivalent or even
would likely have 'chassis' as the value of its entPhysicalClass; consistent. An NMS may be able to 'align' instances returned by
alternatively, for an agent on a module where the agent represents only different agents by examining the columns of each table, but vendor-
the physical entities on that module (not those on other modules), the specific identifiers and (especially) index values are likely to be
entry for which entPhysicalContainedIn has the value zero would likely different. Each agent may be managing different subsets of the entire
have 'module' as the value of its entPhysicalClass. chassis as well.
An agent implementation of the entLogicalTable is not required to When all of a physically-modular device is represented by a single
contain information about logical entities managed primarily by other agent, the entry for which entPhysicalContainedIn has the value zero
agents. That is, the entLogicalTAddress and entLogicalTDomain objects in would likely have 'chassis' as the value of its entPhysicalClass;
the entLogicalTable are provided to support an historical multiplexing alternatively, for an agent on a module where the agent represents
mechanism, not to identify other SNMP agents. only the physical entities on that module (not those on other
modules), the entry for which entPhysicalContainedIn has the value
zero would likely have 'module' as the value of its entPhysicalClass.
Note that the Entity MIB is a single-scoped MIB, in the event an agent An agent implementation of the entLogicalTable is not required to
represents the MIB in different naming scopes. contain information about logical entities managed primarily by other
agents. That is, the entLogicalTAddress and entLogicalTDomain objects
in the entLogicalTable are provided to support an historical
multiplexing mechanism, not to identify other SNMP agents.
Draft Entity MIB June 1996 Note that the Entity MIB is a single-scoped MIB, in the event an
agent represents the MIB in different naming scopes.
3.9. Re-Configuration of Entities 3.9. Re-Configuration of Entities
All the MIB objects defined in this MIB have at most a read-only MAX- All the MIB objects defined in this MIB have at most a read-only
ACCESS clause, i.e., none are write-able. This is a conscious decision MAX-ACCESS clause, i.e., none are write-able. This is a conscious
by the working group to limit this MIB's scope. It is possible that decision by the working group to limit this MIB's scope. It is
this restriction could be lifted after implementation experience, by possible that this restriction could be lifted after implementation
means of additional tables (using the AUGMENTS clause) for configuration experience, by means of additional tables (using the AUGMENTS clause)
and extended entity information. for configuration and extended entity information.
3.10. MIB Structure 3.10. MIB Structure
The Entity MIB contains five conformance groups: The Entity MIB contains five conformance groups:
- 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
Describes the associations between the physical entities, logical Describes the associations between the physical entities,
entities, interfaces, and non-interface ports managed by a single logical entities, interfaces, and non-interface ports managed
agent. by a single agent.
-entityGeneral group -entityGeneral group
Describes general system attributes shared by potentially all types Describes general system attributes shared by potentially
of entities managed by a single agent. all types of entities managed by a single agent.
-entityNotifications group -entityNotifications group
Contains status indication notifications. Contains status indication notifications.
3.10.1. entityPhysical Group 3.10.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
always contains at least one row for an "overall" physical entity. Each
row is indexed by an arbitrary, small integer, and contains a
description and type of the physical entity. It also optionally
contains the index number of another entPhysicalEntry indicating a
containment relationship between the two.
Draft Entity MIB June 1996 The entPhysicalTable contains one row per physical entity, and must
always contains at least one row for an "overall" physical entity.
Each row is indexed by an arbitrary, small integer, and contains a
description and type of the physical entity. It also optionally
contains the index number of another entPhysicalEntry indicating a
containment relationship between the two.
3.10.2. entityLogical Group 3.10.2. entityLogical Group
This group contains a single table to identify logical entities, called This group contains a single table to identify logical entities,
the entLogicalTable. called 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,
and type of the logical entity. It also contains information to allow description, and type of the logical entity. It also contains
SNMPv1 or SNMPv2C [9] access to the MIB information for the logical information to allow SNMPv1 or SNMPv2C [9] access to the MIB
entity. information for the logical entity.
3.10.3. entityMapping Group 3.10.3. entityMapping Group
This group contains a three tables to identify associations between This group contains a 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 more
physical component, and more than one logical entity can map to (share) than one physical component, and more than one logical entity can map
the same physical component. to (share) the same physical component.
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
entity hierarchy. Note that each alias identifier is only relevant in a physical entity hierarchy. Note that each alias identifier is only
particular naming scope. relevant in a particular naming scope.
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
NMS to quickly discover the 'entPhysicalIndex' values for all children an NMS to quickly discover the 'entPhysicalIndex' values for all
of a given physical entity. children of a given physical entity.
3.10.4. entityGeneral Group 3.10.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.
Draft Entity MIB June 1996
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 system configuration last changed. part of the system configuration last changed.
3.10.5. entityNotifications Group 3.10.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.
3.11. Multiple Agents 3.11. 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). Indeed,
implicit in the SNMP architecture, that the number of agents is it 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
cooperation which should be expected for agent implementations.
Therefore, multiple agents within the same managed system are free to
implement the Entity MIB independently. (Refer the section on "Multiple
Instances of the Entity MIB" for more details).
Draft Entity MIB June 1996 However, there is no agreement at this time as to the degree of
cooperation which should be expected for agent implementations.
Therefore, multiple agents within the same managed system are free to
implement the Entity MIB independently. (Refer the section on
"Multiple Instances of the Entity MIB" for more details).
4. Definitions 4. Definitions
ENTITY-MIB DEFINITIONS ::= BEGIN ENTITY-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, MODULE-IDENTITY, OBJECT-TYPE,
experimental, NOTIFICATION-TYPE mib-2, NOTIFICATION-TYPE
FROM SNMPv2-SMI FROM SNMPv2-SMI
TDomain, TAddress, DisplayString, TEXTUAL-CONVENTION, TDomain, TAddress, DisplayString, TEXTUAL-CONVENTION,
AutonomousType, RowPointer, TimeStamp AutonomousType, RowPointer, TimeStamp
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF; FROM SNMPv2-CONF;
entityMIB MODULE-IDENTITY entityMIB MODULE-IDENTITY
LAST-UPDATED "9605160000Z" LAST-UPDATED "9605160000Z"
ORGANIZATION "IETF ENTMIB Working Group" ORGANIZATION "IETF ENTMIB Working Group"
skipping to change at page 12, line 47 skipping to change at page 10, line 45
Andy Bierman Andy Bierman
ENTMIB Working Group Editor 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
408-527-3711 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."
::= { experimental xx } ::= { mib-2 47 }
entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 }
-- MIB contains four groups -- MIB contains four groups
Draft Entity MIB June 1996
entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 }
entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 }
entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 }
entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 }
-- Textual Conventions -- Textual Conventions
PhysicalIndex ::= TEXTUAL-CONVENTION PhysicalIndex ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 14, line 5 skipping to change at page 11, line 35
chassis(3), chassis(3),
backplane(4), backplane(4),
container(5), -- e.g. slot or daughter-card holder container(5), -- e.g. slot or daughter-card holder
powerSupply(6), powerSupply(6),
fan(7), fan(7),
sensor(8), sensor(8),
module(9), -- e.g. plug-in card or daughter-card module(9), -- e.g. plug-in card or daughter-card
port(10) port(10)
} }
Draft Entity MIB June 1996
-- The Physical Entity Table -- The Physical Entity Table
entPhysicalTable OBJECT-TYPE entPhysicalTable OBJECT-TYPE
SYNTAX SEQUENCE OF EntPhysicalEntry SYNTAX SEQUENCE OF EntPhysicalEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table contains one row per physical entity. There is "This table contains one row per physical entity. There is
always at least one row for an 'overall' physical entity." always at least one row for an 'overall' physical entity."
::= { entityPhysical 1 } ::= { entityPhysical 1 }
skipping to change at page 15, line 5 skipping to change at page 12, line 34
} }
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 }
Draft Entity MIB June 1996
entPhysicalDescr OBJECT-TYPE entPhysicalDescr OBJECT-TYPE
SYNTAX DisplayString SYNTAX DisplayString
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A textual description of physical entity. This object "A textual description of physical entity. This object
should contain a string which identifies the manufacturer's should contain a string which identifies the manufacturer's
name for the physical entity, and should be set to a name for the physical entity, and should be set to a
distinct value for each version or model of the physical distinct value for each version or model of the physical
entity. " entity. "
skipping to change at page 16, line 5 skipping to change at page 13, line 31
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of entPhysicalIndex for the physical entity which "The value of entPhysicalIndex for the physical entity which
'contains' this physical entity. A value of zero indicates 'contains' this physical entity. A value of zero indicates
this physical entity is not contained in any other physical this physical entity is not contained in any other physical
entity. Note that the set of 'containment' relationships entity. Note that the set of 'containment' relationships
define a strict hierarchy; that is, recursion is not define a strict hierarchy; that is, recursion is not
allowed." allowed."
::= { entPhysicalEntry 4 } ::= { entPhysicalEntry 4 }
Draft Entity MIB June 1996
entPhysicalClass OBJECT-TYPE entPhysicalClass OBJECT-TYPE
SYNTAX PhysicalClass SYNTAX PhysicalClass
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An indication of the general hardware type of the physical "An indication of the general hardware type of the physical
entity. entity.
An agent should set this object to the standard enumeration An agent should set this object to the standard enumeration
value which most accurately indicates the general class of value which most accurately indicates the general class of
skipping to change at page 17, line 4 skipping to change at page 14, line 28
This value should match any external labeling of the This value should match any external labeling of the
physical component if possible. For example, for a module physical component if possible. For example, for a module
labeled as 'card #3', entPhysicalParentRelPos should have labeled as 'card #3', entPhysicalParentRelPos should have
the value '3'. the value '3'.
If the physical position of this component does not match If the physical position of this component does not match
any external numbering or clearly visible ordering, then any external numbering or clearly visible ordering, then
user documentation or other external reference material user documentation or other external reference material
should be used to determine the parent-relative position. If should be used to determine the parent-relative position. If
this is not possible, then the the agent should assign a this is not possible, then the the agent should assign a
Draft Entity MIB June 1996
consistent (but possibly arbitrary) ordering to a given set consistent (but possibly arbitrary) ordering to a given set
of 'sibling' components, perhaps based on internal of 'sibling' components, perhaps based on internal
representation of the components. representation of the components.
If the agent cannot determine the parent-relative position If the agent cannot determine the parent-relative position
for some reason, or if the associated value of for some reason, or if the associated value of
entPhysicalContainedIn is '0', then the value '-1' is entPhysicalContainedIn is '0', then the value '-1' is
returned. Otherwise a non-negative integer is returned, returned. Otherwise a non-negative integer is returned,
indicating the parent-relative position of this physical indicating the parent-relative position of this physical
entity. entity.
skipping to change at page 18, line 4 skipping to change at page 15, line 24
DESCRIPTION DESCRIPTION
"The textual name of the physical entity. The value of this "The textual name of the physical entity. The value of this
object should be the name of the component as assigned by object should be the name of the component as assigned by
the local device and should be suitable for use in commands the local device and should be suitable for use in commands
entered at the device's `console'. This might be a text entered at the device's `console'. This might be a text
name, such as `console' or a simple component number (e.g. name, such as `console' or a simple component number (e.g.
port or module number), such as `1', depending on the port or module number), such as `1', depending on the
physical component naming syntax of the device. physical component naming syntax of the device.
If there is no local name, or this object is otherwise not If there is no local name, or this object is otherwise not
Draft Entity MIB June 1996
applicable, then this object contains a zero-length string. applicable, then this object contains a zero-length string.
Note that the value of entPhysicalName for two physical Note that the value of entPhysicalName for two physical
entities will be the same in the event that the console entities will be the same in the event that the console
interface does not distinguish between them, e.g., slot-1 interface does not distinguish between them, e.g., slot-1
and the card in slot-1." and the card in slot-1."
::= { entPhysicalEntry 7 } ::= { entPhysicalEntry 7 }
Draft Entity MIB June 1996
-- 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. At least "This table contains one row per logical entity. At least
one entry must exist." one entry must exist."
::= { entityLogical 1 } ::= { entityLogical 1 }
skipping to change at page 20, line 4 skipping to change at page 16, line 29
"The value of this object uniquely identifies the logical "The value of this object uniquely identifies the logical
entity. The value is a small positive integer; index values entity. The value is a small positive integer; index values
for different logical entities are are not necessarily for different logical entities are are not necessarily
contiguous." contiguous."
::= { entLogicalEntry 1 } ::= { entLogicalEntry 1 }
entLogicalDescr OBJECT-TYPE entLogicalDescr OBJECT-TYPE
SYNTAX DisplayString SYNTAX DisplayString
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
Draft Entity MIB June 1996
DESCRIPTION DESCRIPTION
"A textual description of the logical entity. This object "A textual description of the logical entity. This object
should contain a string which identifies the manufacturer's should contain a string which identifies the manufacturer's
name for the logical entity, and should be set to a distinct name for the logical entity, and should be set to a distinct
value for each version of the logical entity. " value for each version of the logical entity. "
::= { entLogicalEntry 2 } ::= { entLogicalEntry 2 }
entLogicalType OBJECT-TYPE entLogicalType OBJECT-TYPE
SYNTAX AutonomousType SYNTAX AutonomousType
MAX-ACCESS read-only MAX-ACCESS read-only
skipping to change at page 21, line 4 skipping to change at page 17, line 26
object. Note that an agent may choose to return a community object. Note that an agent may choose to return a community
string with read-only privileges, even if this object is string with read-only privileges, even if this object is
accessed with a read-write community string. However, the accessed with a read-write community string. However, the
agent must take care not to return a community string which agent must take care not to return a community string which
allows more privileges than the community string used to allows more privileges than the community string used to
access this object. access this object.
A compliant SNMP agent may wish to conserve naming scopes by A compliant SNMP agent may wish to conserve naming scopes by
representing multiple logical entities in a single 'main' representing multiple logical entities in a single 'main'
naming scope. This is possible when the logical entities naming scope. This is possible when the logical entities
Draft Entity MIB June 1996
represented by the same value of entLogicalCommunity have no represented by the same value of entLogicalCommunity have no
object instances in common. For example, 'bridge1' and object instances in common. For example, 'bridge1' and
'repeater1' may be part of the main naming scope, but at 'repeater1' may be part of the main naming scope, but at
least one additional community string is needed to represent least one additional community string is needed to represent
'bridge2' and 'repeater2'. 'bridge2' and 'repeater2'.
Logical entities 'bridge1' and 'repeater1' would be Logical entities 'bridge1' and 'repeater1' would be
represented by sysOREntries associated with the 'main' represented by sysOREntries associated with the 'main'
naming scope. naming scope.
skipping to change at page 22, line 5 skipping to change at page 18, line 19
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 [8])." Transport Mappings for SNMPv2 document (RFC 1906 [8])."
::= { entLogicalEntry 6 } ::= { entLogicalEntry 6 }
Draft Entity MIB June 1996
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 current
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.
skipping to change at page 23, line 4 skipping to change at page 19, line 16
::= { 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 current
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. It association is not specifically identified in this entry. It
Draft Entity MIB June 1996
is expected that sufficient information exists in the MIBs is expected that sufficient information exists in the MIBs
used to manage a particular logical entity to infer how 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 current
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 }
Draft Entity MIB June 1996
-- 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 current 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,
skipping to change at page 25, line 4 skipping to change at page 20, line 34
entAliasLogicalIndexOrZero INTEGER, entAliasLogicalIndexOrZero INTEGER,
entAliasMappingIdentifier RowPointer entAliasMappingIdentifier RowPointer
} }
entAliasLogicalIndexOrZero OBJECT-TYPE entAliasLogicalIndexOrZero OBJECT-TYPE
SYNTAX INTEGER (0..2147483647) SYNTAX INTEGER (0..2147483647)
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of this object uniquely identifies the logical "The value of this object uniquely identifies the logical
Draft Entity MIB June 1996
entity which defines the naming scope for the associated entity which defines the naming scope for the associated
instance of the 'entAliasMappingIdentifier' object. instance 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
entAliasMapping entry is associated with all unspecified entAliasMapping entry is associated with all unspecified
logical entities. That is, a value of zero (the default logical entities. That is, a value of zero (the default
skipping to change at page 26, line 5 skipping to change at page 21, line 31
entAliasMappingIdentifier OBJECT-TYPE entAliasMappingIdentifier OBJECT-TYPE
SYNTAX RowPointer SYNTAX RowPointer
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current 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.
Draft Entity MIB June 1996
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
'rptrPortGroupTable' should be identified instead. 'rptrPortGroupTable' should be identified instead.
For example, suppose a physical port was represented by For example, suppose a physical port was represented by
entPhysicalEntry.3, entLogicalEntry.15 existed for a entPhysicalEntry.3, entLogicalEntry.15 existed for a
repeater, and entLogicalEntry.22 existed for a bridge. Then repeater, and entLogicalEntry.22 existed for a bridge. Then
skipping to change at page 27, line 5 skipping to change at page 22, line 5
entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2
entAliasMappingIdentifier.3.22 == ifIndex.17 entAliasMappingIdentifier.3.22 == ifIndex.17
It is possible that other mappings (besides interfaces and It is possible that other mappings (besides interfaces and
repeater ports) may be defined in the future, as required. repeater ports) may be defined in the future, as required.
Bridge ports are identified by examining the Bridge MIB and Bridge ports are identified by examining the Bridge MIB and
appropriate ifEntries associated with each 'dot1dBasePort', appropriate ifEntries associated with each 'dot1dBasePort',
and are thus not represented in this table." and are thus not represented in this table."
::= { entAliasMappingEntry 2 } ::= { entAliasMappingEntry 2 }
Draft Entity MIB June 1996
-- physical mapping table -- physical mapping table
entPhysicalContainsTable OBJECT-TYPE entPhysicalContainsTable OBJECT-TYPE
SYNTAX SEQUENCE OF EntPhysicalContainsEntry SYNTAX SEQUENCE OF EntPhysicalContainsEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table which exposes the container/containee relationships "A table which exposes the container/containee relationships
between physical entities. This table provides equivalent between physical entities. This table provides equivalent
information found by constructing the virtual containment information found by constructing the virtual containment
tree for a given entPhysicalTable but in a more direct tree for a given entPhysicalTable but in a more direct
skipping to change at page 28, line 5 skipping to change at page 22, line 40
entPhysicalChildIndex OBJECT-TYPE entPhysicalChildIndex OBJECT-TYPE
SYNTAX PhysicalIndex SYNTAX PhysicalIndex
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of entPhysicalIndex for the contained physical "The value of entPhysicalIndex for the contained physical
entity." entity."
::= { entPhysicalContainsEntry 1 } ::= { entPhysicalContainsEntry 1 }
Draft Entity MIB June 1996
-- last change time stamp for the whole MIB -- last change time stamp for the whole MIB
entLastChangeTime OBJECT-TYPE entLastChangeTime OBJECT-TYPE
SYNTAX TimeStamp SYNTAX TimeStamp
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of sysUpTime at the time any of these events "The value of sysUpTime at the time any of these events
occur: occur:
* a conceptual row is created or deleted in any * a conceptual row is created or deleted in any
of these tables: of these tables:
skipping to change at page 29, line 5 skipping to change at page 23, line 23
- entPhysicalParentRelPos - entPhysicalParentRelPos
- entPhysicalName - entPhysicalName
- entLogicalDescr - entLogicalDescr
- entLogicalType - entLogicalType
- entLogicalCommunity - entLogicalCommunity
- entLogicalTAddress - entLogicalTAddress
- entLogicalTDomain - entLogicalTDomain
- entAliasMappingIdentifier " - entAliasMappingIdentifier "
::= { entityGeneral 1 } ::= { entityGeneral 1 }
Draft Entity MIB June 1996
-- Entity MIB Trap Definitions -- Entity MIB Trap Definitions
entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 }
entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 }
entConfigChange NOTIFICATION-TYPE entConfigChange NOTIFICATION-TYPE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An entConfigChange trap is sent when the value of "An entConfigChange trap is sent when the value of
entLastChangeTime changes. It can be utilized by an NMS to entLastChangeTime changes. It can be utilized by an NMS to
trigger logical/physical entity table maintenance polls. trigger logical/physical entity table maintenance polls.
skipping to change at page 30, line 5 skipping to change at page 23, line 45
'trap-event' in a five second period, where a 'trap-event' 'trap-event' in a five second period, where a 'trap-event'
is the transmission of a single trap PDU to a list of trap is the transmission of a single trap PDU to a list of trap
destinations. If additional configuration changes occur destinations. If additional configuration changes occur
within the five second 'throttling' period, then these within the five second 'throttling' period, then these
trap-events should be suppressed by the agent. An NMS should trap-events should be suppressed by the agent. An NMS should
periodically check the value of entLastChangeTime to detect periodically check the value of entLastChangeTime to detect
any missed entConfigChange trap-events, e.g. due to any missed entConfigChange trap-events, e.g. due to
throttling or transmission loss." throttling or transmission loss."
::= { entityMIBTrapPrefix 1 } ::= { entityMIBTrapPrefix 1 }
Draft Entity MIB June 1996
-- conformance information -- conformance information
entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 }
entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 }
entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 }
-- compliance statements -- compliance statements
entityCompliance MODULE-COMPLIANCE entityCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The compliance statement for SNMP entities which implement "The compliance statement for SNMP entities which implement
the Entity MIB." the Entity MIB."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { entityPhysicalGroup, MANDATORY-GROUPS { entityPhysicalGroup,
entityLogicalGroup, entityLogicalGroup,
entityMappingGroup, entityMappingGroup,
entityGeneralGroup, entityGeneralGroup,
skipping to change at page 31, line 4 skipping to change at page 24, line 41
physical system components, for which a single agent physical system components, for which a single agent
provides management information." provides management information."
::= { entityGroups 1 } ::= { entityGroups 1 }
entityLogicalGroup OBJECT-GROUP entityLogicalGroup OBJECT-GROUP
OBJECTS { OBJECTS {
entLogicalDescr, entLogicalDescr,
entLogicalType, entLogicalType,
entLogicalCommunity, entLogicalCommunity,
entLogicalTAddress, entLogicalTAddress,
Draft Entity MIB June 1996
entLogicalTDomain entLogicalTDomain
} }
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 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
skipping to change at page 32, line 4 skipping to change at page 26, line 4
entityNotificationsGroup NOTIFICATION-GROUP entityNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { entConfigChange } NOTIFICATIONS { entConfigChange }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The collection of notifications used to indicate Entity MIB "The collection of notifications used to indicate Entity MIB
data consistency and general status information." data consistency and general status information."
::= { entityGroups 5 } ::= { entityGroups 5 }
END END
Draft Entity MIB June 1996
5. Usage Examples 5. 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.
5.1. Router/Bridge 5.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
entPhysicalClass.1 == chassis(3) entPhysicalClass.1 == chassis(3)
entPhysicalParentRelPos.1 == 0 entPhysicalParentRelPos.1 == 0
entPhysicalName.1 == '100-A' entPhysicalName.1 == '100-A'
skipping to change at page 33, line 4 skipping to change at page 26, line 48
entPhysicalClass.3 == container(5) entPhysicalClass.3 == container(5)
entPhysicalParentRelPos.3 == 2 entPhysicalParentRelPos.3 == 2
entPhysicalName.3 == 'S2' entPhysicalName.3 == 'S2'
2 Field-replaceable modules: 2 Field-replaceable modules:
Slot 1 contains a module with 3 ports: Slot 1 contains a module with 3 ports:
entPhysicalDescr.4 == "Acme Router-100" entPhysicalDescr.4 == "Acme Router-100"
entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14
entPhysicalContainedIn.4 == 2 entPhysicalContainedIn.4 == 2
entPhysicalClass.4 == module(9) entPhysicalClass.4 == module(9)
Draft Entity MIB June 1996
entPhysicalParentRelPos.4 == 1 entPhysicalParentRelPos.4 == 1
entPhysicalName.4 == 'M1' entPhysicalName.4 == 'M1'
entPhysicalDescr.5 == "Acme Ethernet-100 Port Rev G" entPhysicalDescr.5 == "Acme Ethernet-100 Port Rev G"
entPhysicalVendorType.5 == acmeProducts.portTypes.2 entPhysicalVendorType.5 == acmeProducts.portTypes.2
entPhysicalContainedIn.5 == 4 entPhysicalContainedIn.5 == 4
entPhysicalClass.5 == port(10) entPhysicalClass.5 == port(10)
entPhysicalParentRelPos.5 == 1 entPhysicalParentRelPos.5 == 1
entPhysicalName.5 == 'P1' entPhysicalName.5 == 'P1'
skipping to change at page 33, line 37 skipping to change at page 27, line 30
entPhysicalClass.7 == port(10) entPhysicalClass.7 == port(10)
entPhysicalParentRelPos.7 == 3 entPhysicalParentRelPos.7 == 3
entPhysicalName.7 == 'P3' entPhysicalName.7 == 'P3'
Slot 2 contains another 3-port module: Slot 2 contains another 3-port module:
entPhysicalDescr.8 == "Acme Router-100 Comm Module: Rev C" entPhysicalDescr.8 == "Acme Router-100 Comm Module: Rev C"
entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15
entPhysicalContainedIn.8 == 3 entPhysicalContainedIn.8 == 3
entPhysicalClass.8 == module(9) entPhysicalClass.8 == module(9)
entPhysicalParentRelPos.8 == 1 entPhysicalParentRelPos.8 == 1
entPhysicalName.8 == 'M1' entPhysicalName.8 == 'M2'
entPhysicalDescr.9 == "Acme Fddi-100 Port Rev CC" entPhysicalDescr.9 == "Acme Fddi-100 Port Rev CC"
entPhysicalVendorType.9 == acmeProducts.portTypes.5 entPhysicalVendorType.9 == acmeProducts.portTypes.5
entPhysicalContainedIn.9 == 8 entPhysicalContainedIn.9 == 8
entPhysicalClass.9 == port(10) entPhysicalClass.9 == port(10)
entPhysicalParentRelPos.9 == 1 entPhysicalParentRelPos.9 == 1
entPhysicalName.9 == 'FDDI Primary' entPhysicalName.9 == 'FDDI Primary'
entPhysicalDescr.10 == "Acme Ethernet-100 Port Rev G" entPhysicalDescr.10 == "Acme Ethernet-100 Port Rev G"
entPhysicalVendorType.10 == acmeProducts.portTypes.2 entPhysicalVendorType.10 == acmeProducts.portTypes.2
entPhysicalContainedIn.10 == 8 entPhysicalContainedIn.10 == 8
entPhysicalClass.10 == port(10) entPhysicalClass.10 == port(10)
entPhysicalParentRelPos.10 == 2 entPhysicalParentRelPos.10 == 2
entPhysicalName.10 == 'Ethernet A' entPhysicalName.10 == 'Ethernet A'
Draft Entity MIB June 1996
entPhysicalDescr.11 == "Acme Ethernet-100 Port Rev G" entPhysicalDescr.11 == "Acme Ethernet-100 Port Rev G"
entPhysicalVendorType.11 == acmeProducts.portTypes.2 entPhysicalVendorType.11 == acmeProducts.portTypes.2
entPhysicalContainedIn.11 == 8 entPhysicalContainedIn.11 == 8
entPhysicalClass.11 == port(10) entPhysicalClass.11 == port(10)
entPhysicalParentRelPos.11 == 3 entPhysicalParentRelPos.11 == 3
entPhysicalName.11 == 'Ethernet B' entPhysicalName.11 == 'Ethernet B'
Logical entities -- entLogicalTable Logical entities -- entLogicalTable
2 OSPF instances: 2 OSPF instances:
entLogicalDescr.1 == "Acme OSPF v1.1" entLogicalDescr.1 == "Acme OSPF v1.1"
skipping to change at page 35, line 4 skipping to change at page 28, line 43
1st OSPF instance: uses module 1-port 1 1st OSPF instance: uses module 1-port 1
entLPPhysicalIndex.1.5 == 5 entLPPhysicalIndex.1.5 == 5
2nd OSPF instance: uses module 2-port 1 2nd OSPF instance: uses module 2-port 1
entLPPhysicalIndex.2.9 == 9 entLPPhysicalIndex.2.9 == 9
1st bridge group: uses module 1, all ports 1st bridge group: uses module 1, all ports
[ed. -- Note that these mappings are included in the table since [ed. -- Note that these mappings are included in the table since
another logical entity (1st OSPF) utilizes one of the another logical entity (1st OSPF) utilizes one of the
Draft Entity MIB June 1996
ports. If this were not the case, then a single mapping ports. If this were not the case, then a single mapping
to the module (e.g. entLPPhysicalIndex.3.4) would be to the module (e.g. entLPPhysicalIndex.3.4) would be
present instead. ] present instead. ]
entLPPhysicalIndex.3.5 == 5 entLPPhysicalIndex.3.5 == 5
entLPPhysicalIndex.3.6 == 6 entLPPhysicalIndex.3.6 == 6
entLPPhysicalIndex.3.7 == 7 entLPPhysicalIndex.3.7 == 7
2nd bridge group: uses module 2, all ports 2nd bridge group: uses module 2, all ports
entLPPhysicalIndex.4.9 == 9 entLPPhysicalIndex.4.9 == 9
entLPPhysicalIndex.4.10 == 10 entLPPhysicalIndex.4.10 == 10
skipping to change at page 36, line 5 skipping to change at page 29, line 40
chassis has two containers: chassis has two containers:
entPhysicalChildIndex.1.2 = 2 entPhysicalChildIndex.1.2 = 2
entPhysicalChildIndex.1.3 = 3 entPhysicalChildIndex.1.3 = 3
container 1 has a module: container 1 has a module:
entPhysicalChildIndex.2.4 = 4 entPhysicalChildIndex.2.4 = 4
container 2 has a module: container 2 has a module:
entPhysicalChildIndex.3.8 = 8 entPhysicalChildIndex.3.8 = 8
Draft Entity MIB June 1996
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
5.2. Repeaters 5.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. [ed. -- Note empty, and the remaining slots contain ethernet repeater modules.
that a replacement for the current Repeater MIB (RFC 1516) is likely to [ed. -- Note that a replacement for the current Repeater MIB (RFC
emerge soon, and it will no longer be necessary to access repeater MIB 1516) is likely to emerge soon, and it will no longer be necessary to
data in different naming scopes.] access repeater MIB data in different naming scopes.]
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'
skipping to change at page 37, line 4 skipping to change at page 30, line 39
entPhysicalDescr.3 == "Acme Ethernet Backplane Type A" entPhysicalDescr.3 == "Acme Ethernet Backplane Type A"
entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1
entPhysicalContainedIn.3 == 1 entPhysicalContainedIn.3 == 1
entPhysicalClass.3 == backplane(4) entPhysicalClass.3 == backplane(4)
entPhysicalParentRelPos.3 == 2 entPhysicalParentRelPos.3 == 2
entPhysicalName.3 == 'B2' entPhysicalName.3 == 'B2'
3 slots within the chassis: 3 slots within the chassis:
entPhysicalDescr.4 == "Acme Hub Slot Type RB" entPhysicalDescr.4 == "Acme Hub Slot Type RB"
Draft Entity MIB June 1996
entPhysicalVendorType.4 == acmeProducts.slotTypes.5 entPhysicalVendorType.4 == acmeProducts.slotTypes.5
entPhysicalContainedIn.4 == 1 entPhysicalContainedIn.4 == 1
entPhysicalClass.4 == container(5) entPhysicalClass.4 == container(5)
entPhysicalParentRelPos.4 == 1 entPhysicalParentRelPos.4 == 1
entPhysicalName.4 == 'Slot 1' entPhysicalName.4 == 'Slot 1'
entPhysicalDescr.5 == "Acme Hub Slot Type RB" entPhysicalDescr.5 == "Acme Hub Slot Type RB"
entPhysicalVendorType.5 == acmeProducts.slotTypes.5 entPhysicalVendorType.5 == acmeProducts.slotTypes.5
entPhysicalContainedIn.5 == 1 entPhysicalContainedIn.5 == 1
entPhysicalClass.5 == container(5) entPhysicalClass.5 == container(5)
skipping to change at page 38, line 4 skipping to change at page 31, line 35
entPhysicalDescr.9 == "Acme 10Base-T Port RB Rev A" entPhysicalDescr.9 == "Acme 10Base-T Port RB Rev A"
entPhysicalVendorType.9 == acmeProducts.portTypes.10 entPhysicalVendorType.9 == acmeProducts.portTypes.10
entPhysicalContainedIn.9 == 7 entPhysicalContainedIn.9 == 7
entPhysicalClass.9 == port(10) entPhysicalClass.9 == port(10)
entPhysicalParentRelPos.9 == 2 entPhysicalParentRelPos.9 == 2
entPhysicalName.9 == 'Ethernet-B' entPhysicalName.9 == 'Ethernet-B'
entPhysicalDescr.10 == "Acme 10Base-T Port RB Rev B" entPhysicalDescr.10 == "Acme 10Base-T Port RB Rev B"
entPhysicalVendorType.10 == acmeProducts.portTypes.10 entPhysicalVendorType.10 == acmeProducts.portTypes.10
entPhysicalContainedIn.10 == 7 entPhysicalContainedIn.10 == 7
Draft Entity MIB June 1996
entPhysicalClass.10 == port(10) entPhysicalClass.10 == port(10)
entPhysicalParentRelPos.10 == 3 entPhysicalParentRelPos.10 == 3
entPhysicalName.10 == 'Ethernet-C' entPhysicalName.10 == 'Ethernet-C'
entPhysicalDescr.11 == "Acme 10Base-T Port RB Rev B" entPhysicalDescr.11 == "Acme 10Base-T Port RB Rev B"
entPhysicalVendorType.11 == acmeProducts.portTypes.10 entPhysicalVendorType.11 == acmeProducts.portTypes.10
entPhysicalContainedIn.11 == 7 entPhysicalContainedIn.11 == 7
entPhysicalClass.11 == port(10) entPhysicalClass.11 == port(10)
entPhysicalParentRelPos.11 == 4 entPhysicalParentRelPos.11 == 4
entPhysicalName.11 == 'Ethernet-D' entPhysicalName.11 == 'Ethernet-D'
Slot 2 contains another ethernet module with 2 ports. Slot 2 contains another ethernet module with 2 ports.
entPhysicalDescr.12 == "Acme 10Base-T Module Model 4 Rev A" entPhysicalDescr.12 == "Acme 10Base-T Module Model 4 Rev A"
entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30
entPhysicalContainedIn.12 = 5 entPhysicalContainedIn.12 = 5
entPhysicalClass.12 == module(9) entPhysicalClass.12 == module(9)
entPhysicalParentRelPos.12 == 1 entPhysicalParentRelPos.12 == 1
entPhysicalName.12 == 'M1' entPhysicalName.12 == 'M2'
entPhysicalDescr.13 == "Acme 802.3 AUI Port Rev A" entPhysicalDescr.13 == "Acme 802.3 AUI Port Rev A"
entPhysicalVendorType.13 == acmeProducts.portTypes.11 entPhysicalVendorType.13 == acmeProducts.portTypes.11
entPhysicalContainedIn.13 == 12 entPhysicalContainedIn.13 == 12
entPhysicalClass.13 == port(10) entPhysicalClass.13 == port(10)
entPhysicalParentRelPos.13 == 1 entPhysicalParentRelPos.13 == 1
entPhysicalName.13 == 'AUI' entPhysicalName.13 == 'AUI'
entPhysicalDescr.14 == "Acme 10Base-T Port RD Rev B" entPhysicalDescr.14 == "Acme 10Base-T Port RD Rev B"
entPhysicalVendorType.14 == acmeProducts.portTypes.14 entPhysicalVendorType.14 == acmeProducts.portTypes.14
skipping to change at page 39, line 4 skipping to change at page 32, line 32
entLogicalDescr.1 == "Acme repeater v3.1" entLogicalDescr.1 == "Acme repeater v3.1"
entLogicalType.1 == snmpDot3RptrMgt entLogicalType.1 == snmpDot3RptrMgt
entLogicalCommunity.1 "public-repeater1" entLogicalCommunity.1 "public-repeater1"
entLogicalTAddress.1 == 124.125.126.127:161 entLogicalTAddress.1 == 124.125.126.127:161
entLogicalTDomain.1 == snmpUDPDomain entLogicalTDomain.1 == snmpUDPDomain
Repeater 2--comprised of any ports attached to backplane 2: Repeater 2--comprised of any ports attached to backplane 2:
entLogicalDescr.2 == "Acme repeater v3.1" entLogicalDescr.2 == "Acme repeater v3.1"
entLogicalType.2 == snmpDot3RptrMgt entLogicalType.2 == snmpDot3RptrMgt
entLogicalCommunity.2 == "public-repeater2" entLogicalCommunity.2 == "public-repeater2"
Draft Entity MIB June 1996
entLogicalTAddress.2 == 124.125.126.127:161 entLogicalTAddress.2 == 124.125.126.127:161
entLogicalTDomain.2 == snmpUDPDomain entLogicalTDomain.2 == snmpUDPDomain
Logical to Physical Mappings -- entLPMappingTable: Logical to Physical Mappings -- entLPMappingTable:
repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1
[ed. -- Note that a mapping to the module is not included, [ed. -- Note that a mapping to the module is not included,
since in this example represents a port-switchable hub. since in this example represents a port-switchable hub.
Even though all ports on the module could belong to the Even though all ports on the module could belong to the
same repeater as a matter of configuration, the LP port same repeater as a matter of configuration, the LP port
skipping to change at page 40, line 5 skipping to change at page 33, line 31
chassis has two backplanes and three containers: chassis has two backplanes and three containers:
entPhysicalChildIndex.1.2 = 2 entPhysicalChildIndex.1.2 = 2
entPhysicalChildIndex.1.3 = 3 entPhysicalChildIndex.1.3 = 3
entPhysicalChildIndex.1.4 = 4 entPhysicalChildIndex.1.4 = 4
entPhysicalChildIndex.1.5 = 5 entPhysicalChildIndex.1.5 = 5
entPhysicalChildIndex.1.6 = 6 entPhysicalChildIndex.1.6 = 6
container 1 has a module: container 1 has a module:
entPhysicalChildIndex.4.7 = 7 entPhysicalChildIndex.4.7 = 7
Draft Entity MIB June 1996
container 2 has a module container 2 has a module
entPhysicalChildIndex.5.12 = 12 entPhysicalChildIndex.5.12 = 12
[ed. - in this example, container 3 is empty.] [ed. - in this example, container 3 is empty.]
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
Draft Entity MIB June 1996
6. Acknowledgements 6. Acknowledgements
This document was produced by the IETF Entity MIB Working Group. This document was produced by the IETF Entity MIB Working Group.
Draft Entity MIB June 1996
7. References 7. References
[1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for version 2 S. Waldbusser, "Structure of Management Information for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902, of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996. January 1996.
[2] McCloghrie, K., and M. Rose, Editors, "Management Information Base [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17, for Network Management of TCP/IP-based internets: MIB-II", STD 17,
skipping to change at page 43, line 5 skipping to change at page 35, line 5
RFC 1573, Hughes LAN Systems, FTP Software, January 1994. RFC 1573, Hughes LAN Systems, FTP Software, January 1994.
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Transport Mappings for version 2 of the Simple S. Waldbusser, "Transport Mappings for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1906, January 1996. Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901,
January 1996. January 1996.
Draft Entity MIB June 1996
8. Security Considerations 8. Security Considerations
Security issues are not discussed in this memo. In order to implement this MIB, an agent must make certain management
information available about various logical and physical entities
within a managed system, which may be considered sensitive in some
network environments.
9. Authors' Addresses Therefore, a network administrator may wish to employ instance-level
access control, and configure the Entity MIB access (i.e., community
strings in SNMPv1 and SNMPv2C), such that certain instances within
this MIB (e.g., entLogicalCommunity, or entire entLogicalEntries,
entPhysicalEntries, and associated mapping table entries), are
excluded from particular MIB views.
Keith McCloghrie 9. Authors' Addresses
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: 408-526-5260
Email: kzm@cisco.com
Andy Bierman Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Phone: 408-527-3711
Email: abierman@cisco.com
Draft Entity MIB June 1996 Phone: 408-526-5260
EMail: kzm@cisco.com
Table of Contents Andy Bierman
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
1 Introduction .................................................... 2 Phone: 408-527-3711
2 The SNMP Network Management Framework ........................... 3 EMail: abierman@cisco.com
2.1 Object Definitions ............................................ 3
3 Overview ........................................................ 4
3.1 Terms ......................................................... 4
3.2 Relationship to Community Strings ............................. 6
3.3 Relationship to Proxy Mechanisms .............................. 6
3.4 Relationship to a Chassis MIB ................................. 7
3.5 Relationship to the Interfaces MIB ............................ 7
3.6 Relationship to the Other MIBs ................................ 7
3.7 Relationship to Naming Scopes ................................. 7
3.8 Multiple Instances of the Entity MIB .......................... 8
3.9 Re-Configuration of Entities .................................. 9
3.10 MIB Structure ................................................ 9
3.10.1 entityPhysical Group ....................................... 9
3.10.2 entityLogical Group ........................................ 10
3.10.3 entityMapping Group ........................................ 10
3.10.4 entityGeneral Group ........................................ 10
3.10.5 entityNotifications Group .................................. 11
3.11 Multiple Agents .............................................. 11
4 Definitions ..................................................... 12
5 Usage Examples .................................................. 32
5.1 Router/Bridge ................................................. 32
5.2 Repeaters ..................................................... 36
6 Acknowledgements ................................................ 41
7 References ...................................................... 42
8 Security Considerations ......................................... 43
9 Authors' Addresses .............................................. 43
 End of changes. 107 change blocks. 
369 lines changed or deleted 299 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/