draft-ietf-entmib-entmib-05.txt   draft-ietf-entmib-entmib-06.txt 
<draft-ietf-entmib-entmib-05.txt> <draft-ietf-entmib-entmib-06.txt>
Entity MIB Entity MIB
29 May 1996 18 June 1996
Keith McCloghrie Keith McCloghrie
Cisco Systems Inc. Cisco Systems Inc.
kzm@cisco.com kzm@cisco.com
Andy Bierman Andy Bierman
Cisco Systems Inc. Cisco Systems Inc.
abierman@cisco.com abierman@cisco.com
Status of this Memo Status of this Memo
skipping to change at page 2, line ? skipping to change at page 2, line ?
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Draft Entity MIB May 1996 Draft Entity MIB June 1996
1. Introduction 1. Introduction
This memo defines an experimental portion of the Management Information This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for community. In particular, it describes managed objects used for
managing multiple logical and physical entities managed by a single SNMP managing multiple logical and physical entities managed by a single SNMP
agent. agent.
Draft Entity MIB May 1996 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 major
components. They are: 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 objects
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 for
accessing managed information. 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
semantically identical MIB conforming to the SNMPv1 SMI can be 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 the
Management Information Base or MIB. Objects in the MIB are defined Management Information Base or MIB. Objects in the MIB are defined
using the subset of Abstract Syntax Notation One (ASN.1) defined in the using the subset of Abstract Syntax Notation One (ASN.1) defined in the
SMI. In particular, each object type is named by an OBJECT IDENTIFIER, SMI. In particular, each object type is named by an OBJECT IDENTIFIER,
an administratively assigned name. The object type together with an an administratively assigned name. The object type together with an
object instance serves to uniquely identify a specific instantiation of object instance serves to uniquely identify a specific instantiation of
the object. For human convenience, we often use a textual string, the object. For human convenience, we often use a textual string,
termed the descriptor, to refer to the object type. termed the descriptor, to refer to the object type.
Draft Entity MIB May 1996 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 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;
skipping to change at page 5, line 5 skipping to change at page 5, line 5
In these situations, there is no need for varbinds for multiple logical In these situations, there is no need for varbinds for multiple logical
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.
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 May 1996 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 6, 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 May 1996 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)') should 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 should 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 [6].
This is accommodated by representing each community string as a logical This is accommodated by representing each community string as a logical
entity. 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. In such a case, object to represent different managed information.
individual logical entities can be identified by examining the
sysORTable within the same naming scope.
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. 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 a network administrator will likely be able to associate Note that a network administrator will likely be able to associate
community strings with naming scopes with proprietary mechanisms, as a community strings with naming scopes with proprietary mechanisms, as a
matter of configuration. There are no mechanisms for managing naming matter of configuration. There are no mechanisms for managing naming
scopes defined in this MIB. scopes defined in this MIB.
Draft Entity MIB May 1996 Draft Entity MIB June 1996
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 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
skipping to change at page 7, line 28 skipping to change at page 7, line 28
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 components
that have 'external values' (e.g. ifIndex) associated with them within a that have 'external values' (e.g. ifIndex) associated with them within a
given naming scope. This table can be used to identify the physical given naming scope. This table can be used to identify the physical
location of each interface in the ifTable [7]. Since ifIndex values in location of each interface in the ifTable [7]. Since ifIndex values in
different contexts are not related to one another, the interface to different contexts are not related to one another, the interface to
physical component associations are relative to the same logical entity physical component associations are relative to the same logical entity
within the agent. within the agent.
The Entity MIB also contains an 'entPhysicalName' object, which extends The Entity MIB also contains an 'entPhysicalName' object, which
the semantics of the ifName object from the Interfaces MIB [7] to all approximates the semantics of the ifName object from the Interfaces MIB
types of physical components. [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 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.
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 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 'main' naming scope). returned in all naming scopes (e.g. not just the 'main' naming scope).
For example, a community string returned for 'bridge2' may allow access For example, a community string used to access the management
Draft Entity MIB May 1996 Draft Entity MIB June 1996
to all the non-bridge related objects in the 'main' naming scope, as information for logical device 'bridge2' may allow access to all the
well as a 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 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. 'main'), which itself may contain some multi-scoped naming scope (e.g. 'main'), which itself may contain some multi-scoped
objects (e.g. system group). objects (e.g. system group).
3.8. Multiple Instances of the Entity MIB 3.8. Multiple Instances of the Entity MIB
skipping to change at page 8, line 32 skipping to change at page 8, line 33
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
different. Each agent may be managing different subsets of the entire different. Each agent may be managing different subsets of the entire
chassis as well. chassis as well.
When all of a physically-modular device is represented by a single
agent, the entry for which entPhysicalContainedIn has the value zero
would likely have 'chassis' as the value of its entPhysicalClass;
alternatively, for an agent on a module where the agent represents only
the physical entities on that module (not those on other modules), the
entry for which entPhysicalContainedIn has the value zero would likely
have 'module' as the value of its entPhysicalClass.
An agent implementation of the entLogicalTable is not required to 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.
Draft Entity MIB June 1996
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 MAX-
ACCESS clause, i.e., none are write-able. This is another conscious ACCESS clause, i.e., none are write-able. This is a conscious decision
decision by the authors to limit this MIB's scope. It is possible that by the working group to limit this MIB's scope. It is possible that
this restriction could be lifted after implementation experience, and this restriction could be lifted after implementation experience, by
additional tables (using the AUGMENTS clause) added for configuration means of additional tables (using the AUGMENTS clause) for configuration
and extended entity information. and extended entity information.
Draft Entity MIB May 1996
3.10. MIB Structure 3.10. MIB Structure
The Entity MIB contains four 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, logical
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
Contains status indication notifications.
3.10.1. entityPhysical Group 3.10.1. entityPhysical Group
This group contains a single table to identify system components, called This group contains a single table to identify physical system
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 contains at least one row for an "overall" physical entity. Each always contains at least one row for an "overall" physical entity. Each
row is indexed by an arbitrary, small integer, and contains a 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.
Draft Entity MIB June 1996
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, 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
SNMPv1 or SNMPv2C [9] access to the MIB information for the logical SNMPv1 or SNMPv2C [9] access to the MIB information for the logical
entity. entity.
Draft Entity MIB May 1996
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 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. the same physical component.
skipping to change at page 10, line 36 skipping to change at page 11, line 5
'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.
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
This group contains notification definitions relating to the overall
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 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
Draft Entity MIB May 1996
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).
Draft Entity MIB May 1996 Draft Entity MIB June 1996
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 experimental, NOTIFICATION-TYPE
FROM SNMPv2-SMI FROM SNMPv2-SMI
TDomain, TAddress, DisplayString, TEXTUAL-CONVENTION, TDomain, TAddress, DisplayString, TEXTUAL-CONVENTION,
skipping to change at page 13, line 5 skipping to change at page 13, line 5
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 } ::= { experimental xx }
entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 }
-- MIB contains four groups -- MIB contains four groups
Draft Entity MIB May 1996 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
"An arbitrary value which uniquely identifies the physical "An arbitrary value which uniquely identifies the physical
entity. The value is a small positive integer; index values entity. The value is a small positive integer; index values
for different physical entities are not necessarily for different physical entities are not necessarily
contiguous." contiguous."
SYNTAX INTEGER (1..2147483647) SYNTAX INTEGER (1..2147483647)
Draft Entity MIB May 1996 PhysicalClass ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An enumerated value which provides an indication of the
general hardware type of a particular physical entity."
SYNTAX INTEGER {
other(1),
unknown(2),
chassis(3),
backplane(4),
container(5), -- e.g. slot or daughter-card holder
powerSupply(6),
fan(7),
sensor(8),
module(9), -- e.g. plug-in card or daughter-card
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."
skipping to change at page 14, line 39 skipping to change at page 14, line 39
an NMS relate the particular entry to other entries in this an NMS relate the particular entry to other entries in this
table." table."
INDEX { entPhysicalIndex } INDEX { entPhysicalIndex }
::= { entPhysicalTable 1 } ::= { entPhysicalTable 1 }
EntPhysicalEntry ::= SEQUENCE { EntPhysicalEntry ::= SEQUENCE {
entPhysicalIndex PhysicalIndex, entPhysicalIndex PhysicalIndex,
entPhysicalDescr DisplayString, entPhysicalDescr DisplayString,
entPhysicalVendorType AutonomousType, entPhysicalVendorType AutonomousType,
entPhysicalContainedIn INTEGER, entPhysicalContainedIn INTEGER,
entPhysicalClass INTEGER, entPhysicalClass PhysicalClass,
entPhysicalParentRelPos INTEGER, entPhysicalParentRelPos INTEGER,
entPhysicalName DisplayString entPhysicalName DisplayString
} }
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 May 1996 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
skipping to change at page 16, line 5 skipping to change at page 16, line 5
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 May 1996 Draft Entity MIB June 1996
entPhysicalClass OBJECT-TYPE entPhysicalClass OBJECT-TYPE
SYNTAX INTEGER { SYNTAX PhysicalClass
other(1),
unknown(2),
chassis(3),
backplane(4),
container(5), -- e.g. slot or daughter-card holder
powerSupply(6),
fan(7),
sensor(8),
module(9), -- e.g. plug-in card or daughter-card
port(10)
}
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
the physical entity, or the primary class if there is more the physical entity, or the primary class if there is more
than one. than one.
skipping to change at page 17, line 5 skipping to change at page 16, line 42
component among all its 'sibling' components. Sibling component among all its 'sibling' components. Sibling
components are defined as entPhysicalEntries which share the components are defined as entPhysicalEntries which share the
same instance values of each of the entPhysicalContainedIn same instance values of each of the entPhysicalContainedIn
and entPhysicalClass objects. and entPhysicalClass objects.
An NMS can use this object to identify the relative ordering An NMS can use this object to identify the relative ordering
for all sibling components of a particular parent for all sibling components of a particular parent
(identified by the entPhysicalContainedIn instance in each (identified by the entPhysicalContainedIn instance in each
sibling entry). sibling entry).
Draft Entity MIB May 1996
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 17, line 41
The agent should retain parent-relative position values The agent should retain parent-relative position values
across reboots, either through algorithmic assignment or use across reboots, either through algorithmic assignment or use
of non-volatile storage." of non-volatile storage."
::= { entPhysicalEntry 6 } ::= { entPhysicalEntry 6 }
entPhysicalName OBJECT-TYPE entPhysicalName OBJECT-TYPE
SYNTAX DisplayString SYNTAX DisplayString
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
Draft Entity MIB May 1996
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
applicable, then this object contains a zero-length string."
Draft Entity MIB June 1996
applicable, then this object contains a zero-length string.
Note that the value of entPhysicalName for two physical
entities will be the same in the event that the console
interface does not distinguish between them, e.g., slot-1
and the card in slot-1."
::= { entPhysicalEntry 7 } ::= { entPhysicalEntry 7 }
Draft Entity MIB May 1996 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." "This table contains one row per logical entity. At least
one entry must exist."
::= { entityLogical 1 } ::= { entityLogical 1 }
entLogicalEntry OBJECT-TYPE entLogicalEntry OBJECT-TYPE
SYNTAX EntLogicalEntry SYNTAX EntLogicalEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular logical entity. Entities "Information about a particular logical entity. Entities
may be managed by this agent or other SNMP agents (possibly) may be managed by this agent or other SNMP agents (possibly)
in the same chassis." in the same chassis."
skipping to change at page 19, line 51 skipping to change at page 20, line 4
"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
DESCRIPTION
Draft Entity MIB May 1996 Draft Entity MIB June 1996
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
STATUS current STATUS current
skipping to change at page 20, line 31 skipping to change at page 20, line 32
module, or the majority of the MIB modules, supported by the module, or the majority of the MIB modules, supported by the
logical entity. For example: logical entity. For example:
a logical entity of a regular host/router -> mib-2 a logical entity of a regular host/router -> mib-2
a logical entity of a 802.1d bridge -> dot1dBridge a logical entity of a 802.1d bridge -> dot1dBridge
a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt
If an appropriate node in the SMI's naming hierarchy cannot If an appropriate node in the SMI's naming hierarchy cannot
be identified, the value 'mib-2' should be used." be identified, the value 'mib-2' should be used."
::= { entLogicalEntry 3 } ::= { entLogicalEntry 3 }
entLogicalCommunity OBJECT-TYPE entLogicalCommunity OBJECT-TYPE
SYNTAX OCTET STRING SYNTAX OCTET STRING (SIZE (1..255))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An SNMPv1 or SNMPv2C community-string which can be used to "An SNMPv1 or SNMPv2C community-string which can be used to
access detailed management information for this logical access detailed management information for this logical
entity. The agent should allow read access with this entity. The agent should allow read access with this
community string (to an appropriate subset of all managed community string (to an appropriate subset of all managed
objects) and may also choose to return a community string objects) and may also choose to return a community string
based on the privileges of the request used to read this based on the privileges of the request used to read this
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 conformant SNMP agent may wish to conserve naming scopes A compliant SNMP agent may wish to conserve naming scopes by
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
represented by the same value of entLogicalCommunity have no
Draft Entity MIB May 1996 Draft Entity MIB June 1996
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.
For agents not accessible via SNMPv1 or SNMPv2C, the value For agents not accessible via SNMPv1 or SNMPv2C, the value
skipping to change at page 21, line 33 skipping to change at page 21, line 34
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 Version 2 of the Simple
Network Management Protocol' [8] for further information on Network Management Protocol' (RFC 1906 [8]) for further
snmpUDPDomain." 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 [8])." Transport Mappings for SNMPv2 document (RFC 1906 [8])."
::= { entLogicalEntry 6 } ::= { entLogicalEntry 6 }
Draft Entity MIB May 1996 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
skipping to change at page 22, line 30 skipping to change at page 22, line 30
information is returned. For example, in a system which information is returned. For example, in a system which
contains a single power supply, mappings between logical contains a single power supply, mappings between logical
entities and the power supply are not useful and should not entities and the power supply are not useful and should not
be included. be included.
Also, only the most appropriate physical component which is Also, only the most appropriate physical component which is
closest to the root of a particular containment tree should closest to the root of a particular containment tree should
be identified in an entLPMapping entry. be identified in an entLPMapping entry.
For example, suppose a bridge is realized on a particular For example, suppose a bridge is realized on a particular
module, and it utilizes all of the ports on that module. A module, and all ports on that module are ports on this
mapping between the bridge and the module would be useful, bridge. A mapping between the bridge and the module would be
but additional mappings between the bridge and each of the useful, but additional mappings between the bridge and each
ports on that module would be redundant (since the of the ports on that module would be redundant (since the
entPhysicalContainedIn hierarchy can provide the same entPhysicalContainedIn hierarchy can provide the same
information). If, on the other hand, more than one bridge information). If, on the other hand, more than one bridge
was utilizing ports on this module, then mappings between was utilizing ports on this module, then mappings between
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 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 May 1996 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
} }
skipping to change at page 24, line 5 skipping to change at page 24, line 5
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 May 1996 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,
which itself is associated with a particular logical which itself is associated with a particular logical
entity's naming scope. A wildcard mechanism is provided to entity's naming scope. A 'wildcard' mechanism is provided to
indicate that an identifier is associated with more than one indicate that an identifier is associated with more than one
logical entity." logical entity."
::= { entityMapping 2 } ::= { entityMapping 2 }
entAliasMappingEntry OBJECT-TYPE entAliasMappingEntry OBJECT-TYPE
SYNTAX EntAliasMappingEntry SYNTAX EntAliasMappingEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular physical equipment, logical "Information about a particular physical equipment, logical
entity to external identifier binding. Each logical entity to external identifier binding. Each logical
entity/physical component pair may be associated with one entity/physical component pair may be associated with one
alias mapping. The logical entity index may also be used as alias mapping. The logical entity index may also be used as
a wildcard (refer to the entAliasLogicalIndexOrZero object a 'wildcard' (refer to the entAliasLogicalIndexOrZero object
DESCRIPTION clause for details.) DESCRIPTION clause for details.)
Note that only entPhysicalIndex values which represent Note that only entPhysicalIndex values which represent
physical ports (i.e. associated entPhysicalClass value is physical ports (i.e. associated entPhysicalClass value is
'port(10)') are permitted to exist in this table." 'port(10)') are permitted to exist in this table."
INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero }
::= { entAliasMappingTable 1 } ::= { entAliasMappingTable 1 }
EntAliasMappingEntry ::= SEQUENCE { EntAliasMappingEntry ::= SEQUENCE {
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 May 1996 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
skipping to change at page 25, line 29 skipping to change at page 25, line 29
entPhysicalIndex/entAliasMappingIdentifier pair. entPhysicalIndex/entAliasMappingIdentifier pair.
For example, to indicate that a particular interface (e.g. For example, to indicate that a particular interface (e.g.
physical component 33) is identified by the same value of physical component 33) is identified by the same value of
ifIndex for all logical entities, the following instance ifIndex for all logical entities, the following instance
might exist: might exist:
entAliasMappingIdentifier.33.0 = ifIndex.5 entAliasMappingIdentifier.33.0 = ifIndex.5
In the event an entPhysicalEntry is associated differently In the event an entPhysicalEntry is associated differently
for some logical entities (e.g. 4, 5, and 10 below), for some logical entities, additional entAliasMapping
additional entAliasMapping entries may exist, e.g.: entries may exist, e.g.:
entAliasMappingIdentifier.33.0 = ifIndex.6
entAliasMappingIdentifier.33.4 = ifIndex.1 entAliasMappingIdentifier.33.4 = ifIndex.1
entAliasMappingIdentifier.33.5 = ifIndex.1 entAliasMappingIdentifier.33.5 = ifIndex.1
entAliasMappingIdentifier.33.10 = ifIndex.12 entAliasMappingIdentifier.33.10 = ifIndex.12
Note that entries with non-zero entAliasLogicalIndexOrZero Note that entries with non-zero entAliasLogicalIndexOrZero
index values have precedence over any zero-indexed entry." index values have precedence over any zero-indexed entry. In
this example, all logical entities except 4, 5, and 10,
associate physical entity 33 with ifIndex.6."
::= { entAliasMappingEntry 1 } ::= { entAliasMappingEntry 1 }
entAliasMappingIdentifier OBJECT-TYPE entAliasMappingIdentifier OBJECT-TYPE
SYNTAX RowPointer SYNTAX RowPointer
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS 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
Draft Entity MIB May 1996
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
there might be two related instances of there might be two related instances of
entAliasMappingIdentifier: entAliasMappingIdentifier:
skipping to change at page 26, line 21 skipping to change at page 26, line 23
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
there might be two related instances of there might be two related instances of
entAliasMappingIdentifier: entAliasMappingIdentifier:
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."
::= { entAliasMappingEntry 2 } ::= { entAliasMappingEntry 2 }
Draft Entity MIB May 1996 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
skipping to change at page 28, line 5 skipping to change at page 28, line 5
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 May 1996 Draft Entity MIB June 1996
-- last change timestamp for the whole MIB -- last change timestamp 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
skipping to change at page 29, line 5 skipping to change at page 29, line 5
- entPhysicalParentRelPos - entPhysicalParentRelPos
- entPhysicalName - entPhysicalName
- entLogicalDescr - entLogicalDescr
- entLogicalType - entLogicalType
- entLogicalCommunity - entLogicalCommunity
- entLogicalTAddress - entLogicalTAddress
- entLogicalTDomain - entLogicalTDomain
- entAliasMappingIdentifier " - entAliasMappingIdentifier "
::= { entityGeneral 1 } ::= { entityGeneral 1 }
Draft Entity MIB May 1996 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 }
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.
This trap is throttled by the agent.
An agent must not generate more than one entConfigChange An agent must not generate more than one entConfigChange
'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
events should be discarded 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 events due to throttling or any missed entConfigChange trap-events, e.g. due to
transmission loss." throttling or transmission loss."
::= { entityMIBTraps 1 } ::= { entityMIBTrapPrefix 1 }
Draft Entity MIB May 1996 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,
entityNotificationsGroup }
::= { entityCompliances 1 } ::= { entityCompliances 1 }
-- MIB groupings -- MIB groupings
entityPhysicalGroup OBJECT-GROUP entityPhysicalGroup OBJECT-GROUP
OBJECTS { OBJECTS {
entPhysicalDescr, entPhysicalDescr,
entPhysicalVendorType, entPhysicalVendorType,
entPhysicalContainedIn, entPhysicalContainedIn,
entPhysicalClass, entPhysicalClass,
entPhysicalParentRelPos, entPhysicalParentRelPos,
entPhysicalName entPhysicalName
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The collection of objects which are used to represent "The collection of objects which are used to represent
physical system components associated with logical entities, physical system components, for which a single agent
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,
entLogicalTDomain
Draft Entity MIB May 1996 Draft Entity MIB June 1996
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
OBJECTS { OBJECTS {
skipping to change at page 31, line 40 skipping to change at page 31, line 41
OBJECTS { OBJECTS {
entLastChangeTime entLastChangeTime
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The collection of objects which are used to represent "The collection of objects which are used to represent
general entity information for which a single agent provides general entity information for which a single agent provides
management information." management information."
::= { entityGroups 4 } ::= { entityGroups 4 }
entityNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { entConfigChange }
STATUS current
DESCRIPTION
"The collection of notifications used to indicate Entity MIB
data consistency and general status information."
::= { entityGroups 5 }
END END
Draft Entity MIB May 1996 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. Auxilary components, such as fans, sensors, empty slots, understandable. Auxiliary components, such as fans, sensors, empty
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:
skipping to change at page 33, line 5 skipping to change at page 33, line 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 May 1996 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 34, line 5 skipping to change at page 34, line 5
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 May 1996 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:
skipping to change at page 35, line 5 skipping to change at page 35, line 5
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 May 1996 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
skipping to change at page 36, line 5 skipping to change at page 36, line 5
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 May 1996 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
skipping to change at page 37, line 5 skipping to change at page 37, line 5
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 May 1996 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
skipping to change at page 38, line 5 skipping to change at page 38, line 5
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 May 1996 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
skipping to change at page 39, line 5 skipping to change at page 39, line 5
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 May 1996 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
skipping to change at page 40, line 5 skipping to change at page 40, line 5
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 May 1996 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 May 1996 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 May 1996 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 43, 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 May 1996 Draft Entity MIB June 1996
8. Security Considerations 8. Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
9. Authors' Addresses 9. Authors' Addresses
Keith McCloghrie Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
skipping to change at page 44, line 5 skipping to change at page 44, line 5
Phone: 408-526-5260 Phone: 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 San Jose, CA 95134
Phone: 408-527-3711 Phone: 408-527-3711
Email: abierman@cisco.com Email: abierman@cisco.com
Draft Entity MIB May 1996 Draft Entity MIB June 1996
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
2 The SNMP Network Management Framework ........................... 3 2 The SNMP Network Management Framework ........................... 3
2.1 Object Definitions ............................................ 3 2.1 Object Definitions ............................................ 3
3 Overview ........................................................ 4 3 Overview ........................................................ 4
3.1 Terms ......................................................... 4 3.1 Terms ......................................................... 4
3.2 Relationship to Community Strings ............................. 6 3.2 Relationship to Community Strings ............................. 6
3.3 Relationship to Proxy Mechanisms .............................. 6 3.3 Relationship to Proxy Mechanisms .............................. 6
3.4 Relationship to a Chassis MIB ................................. 7 3.4 Relationship to a Chassis MIB ................................. 7
3.5 Relationship to the Interfaces MIB ............................ 7 3.5 Relationship to the Interfaces MIB ............................ 7
3.6 Relationship to the Other MIBs ................................ 7 3.6 Relationship to the Other MIBs ................................ 7
3.7 Relationship to Naming Scopes ................................. 7 3.7 Relationship to Naming Scopes ................................. 7
3.8 Multiple Instances of the Entity MIB .......................... 8 3.8 Multiple Instances of the Entity MIB .......................... 8
3.9 Re-Configuration of Entities .................................. 8 3.9 Re-Configuration of Entities .................................. 9
3.10 MIB Structure ................................................ 9 3.10 MIB Structure ................................................ 9
3.10.1 entityPhysical Group ....................................... 9 3.10.1 entityPhysical Group ....................................... 9
3.10.2 entityLogical Group ........................................ 9 3.10.2 entityLogical Group ........................................ 10
3.10.3 entityMapping Group ........................................ 10 3.10.3 entityMapping Group ........................................ 10
3.10.4 entityGeneral Group ........................................ 10 3.10.4 entityGeneral Group ........................................ 10
3.11 Multiple Agents .............................................. 10 3.10.5 entityNotifications Group .................................. 11
3.11 Multiple Agents .............................................. 11
4 Definitions ..................................................... 12 4 Definitions ..................................................... 12
5 Usage Examples .................................................. 32 5 Usage Examples .................................................. 32
5.1 Router/Bridge ................................................. 32 5.1 Router/Bridge ................................................. 32
5.2 Repeaters ..................................................... 36 5.2 Repeaters ..................................................... 36
6 Acknowledgements ................................................ 41 6 Acknowledgements ................................................ 41
7 References ...................................................... 42 7 References ...................................................... 42
8 Security Considerations ......................................... 43 8 Security Considerations ......................................... 43
9 Authors' Addresses .............................................. 43 9 Authors' Addresses .............................................. 43
 End of changes. 

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