draft-ietf-entmib-entmib-03.txt   draft-ietf-entmib-entmib-04.txt 
<draft-ietf-entmib-entmib-03.txt> <draft-ietf-entmib-entmib-04.txt> |
Entity MIB Entity MIB
12 April 1996 20 May 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 April 1996 Draft Entity MIB May 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 April 1996 Draft Entity MIB May 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 4, line 5 skipping to change at page 4, line 5
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 April 1996 Draft Entity MIB May 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 April 1996 Draft Entity MIB May 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 April 1996 Draft Entity MIB May 1996
It is required that physical containment-trees retain their
identity across reboots. Specifically, two identical hardware
configurations should produce the same set of containment-trees for
every corresponding entry in the entPhysicalTable (i.e. the same
set of entPhysicalEntries with the same entPhysicalIndex values.
This requirement exists only if the agent is warmstarting, not
coldstarting. If the hardware configuration changes in any way,
then the index values retained across the reboot do not have to be
used.
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)') should 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 should represent both empty and full containers in the
entPhysicalTable. entPhysicalTable.
3.2. Relationship to Community Strings 3.2. Relationship to Community Strings
skipping to change at page 7, line 4 skipping to change at page 6, line 40
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
Draft Entity MIB April 1996
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
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
a chassis. a chassis.
skipping to change at page 7, line 37 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 semantics of the ifName object from the Interfaces MIB [7] to 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.
Draft Entity MIB April 1996
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 returned for 'bridge2' may allow access
Draft Entity MIB May 1996
to all the non-bridge related objects in the 'main' naming scope, as to all the non-bridge related objects in the 'main' naming scope, as
well as a second instance of the Bridge MIB. 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).
skipping to change at page 9, line 5 skipping to change at page 8, line 41
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 April 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 another conscious
decision by the authors to limit this MIB's scope. It is possible that decision by the authors 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, and
additional tables (using the AUGMENTS clause) added for configuration additional tables (using the AUGMENTS clause) added for configuration
and extended entity information. and extended entity information.
Draft Entity MIB May 1996
3.10. MIB Structure 3.10. MIB Structure
This MIB contains five tables: the entPhysicalTable and the The Entity MIB contains four groups: +
entLogicalTable each provide a list of entities. The entLPMappingTable
provides mappings between logical and physical entities. The
entAliasMappingTable provides mappings between physical components and
associated identifiers from other MIBs. These mappings may be defined
for all logical entities, or individual logical entities. The
entPhysicalContainsTable provides efficient discovery of the containment
relationships of all physical entities (also derivable from
'entPhysicalContainedIn' values).
The entPhysicalTable contains one row per physical entity, and should - entityPhysical group
Describes the physical entities managed by a single agent. |
- entityLogical group |
Describes the logical entities managed by a single agent. |
- entityMapping group |
Describes the associations between the physical entities, logical |
entities, interfaces, and non-interface ports managed by a single |
agent. |
-entityGeneral group |
Describes general system attributes shared by potentially all types |
of entities managed by a single agent. |
3.10.1. entityPhysical Group |
This group contains a single table to identify system 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 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.
3.10.2. entityLogical Group
This group contains a single table to identify logical entities, called +
the entLogicalTable. +
The entLogicalTable contains one row per logical entity. Each row is 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
This group contains a three tables to identify associations between +
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.
Draft Entity MIB April 1996
The entAliasMappingTable contains mappings between entLogicalIndex, The entAliasMappingTable contains mappings between entLogicalIndex,
entPhysicalIndex pairs and 'alias' object identifier values. This entPhysicalIndex pairs and 'alias' object identifier values. This
allows resources managed with other MIBs (e.g. repeater ports, bridge allows resources managed with other MIBs (e.g. repeater ports, bridge
ports, physical and logical interfaces) to be identified in the physical ports, physical and logical interfaces) to be identified in the physical
entity hierarchy. Note that each alias identifier is only relevant in a entity hierarchy. Note that each alias identifier is only relevant in a
particular naming scope. 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 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
This group contains general information relating to the other object +
groups. +
At this time, the entGeneral group contains a single scalar object +
(entLastChangeTime), which represents the value of sysUptime when any +
part of the system configuration last changed. +
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 April 1996 Draft Entity MIB May 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, TDomain, TAddress, DisplayString,
AutonomousType, TruthValue, RowPointer AutonomousType, TruthValue, 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 "9604100000Z" LAST-UPDATED "9605160000Z" |
ORGANIZATION "IETF ENTMIB Working Group" ORGANIZATION "IETF ENTMIB Working Group"
CONTACT-INFO CONTACT-INFO
" Keith McCloghrie " Keith McCloghrie
ENTMIB Working Group Chair ENTMIB Working Group Chair
Cisco Systems Inc. Cisco Systems Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
408-526-5260 408-526-5260
kzm@cisco.com kzm@cisco.com
skipping to change at page 12, line 5 skipping to change at page 12, line 47
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 } ::= { experimental xx }
entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 }
Draft Entity MIB April 1996 -- MIB contains four groups +
entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } +
entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } +
entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } +
entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } +
Draft Entity MIB May 1996
-- Textual Conventions +
PhysicalIndex ::= TEXTUAL-CONVENTION +
STATUS current +
DESCRIPTION +
"An arbitrary value which uniquely identifies the physical +
entity. The value is a small positive integer; index values +
for different physical entities are not necessarily +
contiguous." +
SYNTAX INTEGER (1..2147483647) +
Draft Entity MIB May 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."
::= { entityMIBObjects 1 } ::= { entityPhysical 1 } |
entPhysicalEntry OBJECT-TYPE entPhysicalEntry OBJECT-TYPE
SYNTAX EntPhysicalEntry SYNTAX EntPhysicalEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular physical entity. An agent "Information about a particular physical entity. -
is expected to represent physical components in as much
detail as possible."
Each entry provides objects (entPhysicalDescr, +
entPhysicalVendorType, and entPhysicalClass) to help an NMS +
identify and characterize the entry, and objects +
(entPhysicalContainedIn and entPhysicalParentRelPos) to help +
an NMS relate the particular entry to other entries in this +
table." +
INDEX { entPhysicalIndex } INDEX { entPhysicalIndex }
::= { entPhysicalTable 1 } ::= { entPhysicalTable 1 }
EntPhysicalEntry ::= SEQUENCE { EntPhysicalEntry ::= SEQUENCE {
entPhysicalIndex INTEGER, entPhysicalIndex INTEGER,
entPhysicalDescr DisplayString, entPhysicalDescr DisplayString,
entPhysicalVendorType AutonomousType, entPhysicalVendorType AutonomousType,
entPhysicalContainedIn INTEGER, entPhysicalContainedIn INTEGER,
entPhysicalClass INTEGER, entPhysicalClass INTEGER,
entPhysicalParentRelPos INTEGER entPhysicalParentRelPos INTEGER, |
entPhysicalName DisplayString |
} }
entPhysicalIndex OBJECT-TYPE entPhysicalIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647) SYNTAX PhysicalIndex |
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of this object uniquely identifies the physical "The index for this entry." |
entity. The value is a small positive integer; index values
for different physical entities are not necessarily
contiguous."
::= { entPhysicalEntry 1 } ::= { entPhysicalEntry 1 }
Draft Entity MIB May 1996
entPhysicalDescr OBJECT-TYPE entPhysicalDescr OBJECT-TYPE
SYNTAX DisplayString SYNTAX DisplayString
Draft Entity MIB April 1996
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A textual description of physical entity." "A textual description of physical entity. This object |
should contain a string which identifies the manufacturer's |
name for the physical entity, and should be set to a |
distinct value for each version or model of the physical |
entity. " |
::= { entPhysicalEntry 2 } ::= { entPhysicalEntry 2 }
entPhysicalVendorType OBJECT-TYPE entPhysicalVendorType OBJECT-TYPE
SYNTAX AutonomousType SYNTAX AutonomousType
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An indication of the vendor-specific hardware type of the "An indication of the vendor-specific hardware type of the
physical entity. Note that this is different from the physical entity. Note that this is different from the
definition of MIB-II's sysObjectID. definition of MIB-II's sysObjectID.
An agent should set this object to a enterprise-specific An agent should set this object to a enterprise-specific
registration identifier value indicating the specific registration identifier value indicating the specific
equipment type in detail. The associated instance of equipment type in detail. The associated instance of |
entPhysicalClass should be used to indicate the general type entPhysicalClass is used |
of hardware device. to indicate the general type of hardware device.
If no vendor-specific registration identifier exists for If no vendor-specific registration identifier exists for
this physical entity, or the value is unknown by this agent, this physical entity, or the value is unknown by this agent,
then the value { 0 0 } is returned." then the value { 0 0 } is returned."
::= { entPhysicalEntry 3 } ::= { entPhysicalEntry 3 }
entPhysicalContainedIn OBJECT-TYPE entPhysicalContainedIn OBJECT-TYPE
SYNTAX INTEGER (0..2147483647) SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-only MAX-ACCESS read-only
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
entPhysicalClass OBJECT-TYPE entPhysicalClass OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
other(1), other(1),
unknown(2), unknown(2),
chassis(3), chassis(3),
backplane(4), backplane(4),
Draft Entity MIB April 1996
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)
} }
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 14, line 36 skipping to change at page 16, line 42
for this physical entity, then the value 'other(1)' is for this physical entity, then the value 'other(1)' is
returned. If the value is unknown by this agent, then the returned. If the value is unknown by this agent, then the
value 'unknown(2)' is returned." value 'unknown(2)' is returned."
::= { entPhysicalEntry 5 } ::= { entPhysicalEntry 5 }
entPhysicalParentRelPos OBJECT-TYPE entPhysicalParentRelPos OBJECT-TYPE
SYNTAX INTEGER (-1..2147483647) SYNTAX INTEGER (-1..2147483647)
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An indication of the position of this 'child' component "An indication of the relative position of this 'child' |
among all its 'sibling' components. The numbering is component among all its 'sibling' components. Sibling |
relative to the 'parent' component. A component's parent is components are defined as entPhysicalEntries which share the |
identified by the associated instance of the same instance values of each of the entPhysicalContainedIn |
entPhysicalContainedIn object. An NMS may use this value to and entPhysicalClass objects. |
compare against other entPhysicalEntries with the same
parent. An NMS can use this object to identify the relative ordering +
for all sibling components of a particular parent +
(identified by the entPhysicalContainedIn instance in each +
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
Draft Entity MIB April 1996
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
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.
Parent-relative ordering normally starts from '1' and Parent-relative ordering normally starts from '1' and |
continue to 'N', where 'N' represents the highest positioned continues to 'N', |
child entity. However, if slots are labeled from a starting where 'N' represents the highest positioned child entity. |
position of zero, then the first sibling should be However, if the physical entities (e.g. slots) are labeled |
associated with a entPhysicalParentRelPos value of '0'. from a starting position of zero, then the first sibling |
should be associated with a entPhysicalParentRelPos value of |
'0'. |
Note that this ordering may be sparse or dense, depending on Note that this ordering may be sparse or dense, depending on
agent implementation. The actual values returned are not agent implementation. +
globally meaningful, as each 'parent' component may use
different numbering algorithms. The ordering is only The actual values returned are not globally meaningful, as
meaningful among siblings of the same parent component. each 'parent' component may use different numbering
algorithms. The ordering is only meaningful among siblings
of the same parent component.
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 }
Draft Entity MIB April 1996 entPhysicalName OBJECT-TYPE +
SYNTAX DisplayString +
MAX-ACCESS read-only +
entLogicalTable OBJECT-TYPE Draft Entity MIB May 1996
STATUS current +
DESCRIPTION +
"The textual name of the physical entity. The value of this +
object should be the name of the component as assigned by +
the local device and should be suitable for use in commands +
entered at the device's `console'. This might be a text +
name, such as `console' or a simple component number (e.g. +
port or module number), such as `1', depending on the +
physical component naming syntax of the device. +
If there is no local name, or this object is otherwise not +
applicable, then this object contains a zero-length string." +
::= { entPhysicalEntry 7 } +
Draft Entity MIB May 1996
-- The Logical Entity Table 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."
::= { entityMIBObjects 2 } ::= { 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."
INDEX { entLogicalIndex } INDEX { entLogicalIndex }
skipping to change at page 17, line 5 skipping to change at page 19, line 46
SYNTAX INTEGER (1..2147483647) SYNTAX INTEGER (1..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
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 }
Draft Entity MIB April 1996 entLogicalDescr OBJECT-TYPE -
entLogicalDescr OBJECT-TYPE
SYNTAX DisplayString SYNTAX DisplayString
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A textual description of the logical entity." "A textual description of the logical entity. This object |
Draft Entity MIB May 1996
should contain a string which identifies the manufacturer's |
name for the logical entity, and should be set to a distinct |
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
DESCRIPTION DESCRIPTION
"An indication of the type of logical entity. This will "An indication of the type of logical entity. This will
typically be the OBJECT IDENTIFIER name of the node in the typically be the OBJECT IDENTIFIER name of the node in the
SMI's naming hierarchy which represents the major MIB SMI's naming hierarchy which represents the major MIB
skipping to change at page 18, line 4 skipping to change at page 20, line 50
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 conformant SNMP agent may wish to conserve naming scopes
by representing multiple logical entities in a single 'main' by representing multiple logical entities in a single 'main'
Draft Entity MIB April 1996
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 represented by the same value of entLogicalCommunity have no
Draft Entity MIB May 1996
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
of this object is the empty-string." of this object is the empty-string."
::= { entLogicalEntry 4 } ::= { entLogicalEntry 4 }
entLogicalTAddress OBJECT-TYPE entLogicalTAddress OBJECT-TYPE
SYNTAX TAddress SYNTAX TAddress
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The transport service address by which the logical entity "The transport service address by which the logical entity
receives network management traffic, formatted according to receives network management traffic, formatted according to
the corresponding value of entLogicalTDomain. For the corresponding value of entLogicalTDomain. |
snmpUDPDomain, entLogicalTAddress is formatted as a 4-octet
IP Address concatenated with a 2-octet UDP port number." For snmpUDPDomain, a TAddress is 6 octets long, the initial |
4 octets containing the IP-address in network-byte order and |
the last 2 containing the UDP port in network-byte order. |
Consult 'Transport Mappings for Version 2 of the Simple |
Network Management Protocol' [8] for further information on |
snmpUDPDomain." |
::= { entLogicalEntry 5 } ::= { entLogicalEntry 5 }
entLogicalTDomain OBJECT-TYPE entLogicalTDomain OBJECT-TYPE
SYNTAX TDomain SYNTAX TDomain
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Indicates the kind of transport service by which the "Indicates the kind of transport service by which the
logical entity receives network management traffic. logical entity receives network management traffic.
Possible values for this object are presently found in the Possible values for this object are presently found in the
Transport Mappings for SNMPv2 document (RFC 1906 [8])." Transport Mappings for SNMPv2 document (RFC 1906 [8])."
::= { entLogicalEntry 6 } ::= { entLogicalEntry 6 }
Draft Entity MIB April 1996 Draft Entity MIB May 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 19, line 42 skipping to change at page 22, line 42
but additional mappings between the bridge and each of the but additional mappings between the bridge and each of the
ports on that module would be redundant (since 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."
::= { entityMIBObjects 3 } ::= { 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 April 1996 Draft Entity MIB May 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 INTEGER entLPPhysicalIndex INTEGER
} }
entLPPhysicalIndex OBJECT-TYPE entLPPhysicalIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647) SYNTAX PhysicalIndex |
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of this object identifies a particular "The value of this object identifies the index value of a |
entPhysicalEntry associated with the indicated particular entPhysicalEntry associated with the indicated |
entLogicalEntity." entLogicalEntity."
::= { entLPMappingEntry 1 } ::= { entLPMappingEntry 1 }
Draft Entity MIB April 1996 Draft Entity MIB May 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 of logical entity, "This table contains zero or more rows, representing |
and physical component to external MIB identifiers. Each mappings of logical entity and physical component to |
physical port in the system may be associated with a mapping external MIB identifiers. |
to an external identifier, which itself is associated with a Each physical port in the system may be associated with a
particular logical entity's naming scope. A wildcard mapping to an external identifier, which itself is
mechanism is provided to indicate that an identifier is associated with a particular logical entity's naming scope.
associated with more than one logical entity." A wildcard mechanism is provided to indicate that an
::= { entityMIBObjects 4 } identifier is associated with more than one logical entity."
::= { 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
skipping to change at page 21, line 51 skipping to change at page 25, line 4
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
entity which defines the naming scope for the associated
Draft Entity MIB April 1996 Draft Entity MIB May 1996
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
mapping) identifies any logical entity which does not have mapping) identifies any logical entity which does not have
skipping to change at page 22, line 50 skipping to change at page 26, line 4
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.
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,
Draft Entity MIB April 1996 Draft Entity MIB May 1996
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:
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'."
::= { entAliasMappingEntry 2 } ::= { entAliasMappingEntry 2 }
Draft Entity MIB April 1996 Draft Entity MIB May 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
format." format."
::= { entityMIBObjects 5 } ::= { entityMapping 3 } |
entPhysicalContainsEntry OBJECT-TYPE entPhysicalContainsEntry OBJECT-TYPE
SYNTAX EntPhysicalContainsEntry SYNTAX EntPhysicalContainsEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A single container/containee relationship." "A single container/containee relationship."
INDEX { entPhysicalIndex, entPhysicalChildIndex } INDEX { entPhysicalIndex, entPhysicalChildIndex }
::= { entPhysicalContainsTable 1 } ::= { entPhysicalContainsTable 1 }
EntPhysicalContainsEntry ::= SEQUENCE { EntPhysicalContainsEntry ::= SEQUENCE {
entPhysicalChildIndex INTEGER entPhysicalChildIndex INTEGER
} }
entPhysicalChildIndex OBJECT-TYPE entPhysicalChildIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647) 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 April 1996 Draft Entity MIB May 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
of these tables: of these tables:
- entPhysicalTable - entPhysicalTable
- entLogicalTable - entLogicalTable
- entLPMappingTable - entLPMappingTable
- entAliasMappingTable - entAliasMappingTable
- entPhysicalContainsTable - entPhysicalContainsTable
* any instance in the following list of objects * any instance in the following list of objects
changes value: changes value:
- entPhysicalDescr - entPhysicalDescr
- entPhysicalVendorType - entPhysicalVendorType
- entPhysicalContainedIn - entPhysicalContainedIn
- entPhysicalClass - entPhysicalClass
- entPhysicalParentRelPos +
- entPhysicalName +
- entLogicalDescr - entLogicalDescr
- entLogicalType - entLogicalType
- entLogicalCommunity - entLogicalCommunity
- entLogicalTAddress - entLogicalTAddress
- entLogicalTDomain - entLogicalTDomain
- entAliasMappingIdentifier - entAliasMappingIdentifier
" "
::= { entityMIBObjects 6 } ::= { entityGeneral 1 } |
Draft Entity MIB April 1996 Draft Entity MIB May 1996
-- Entity MIB Trap Definitions -- Entity MIB Trap Definitions
entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 }
entConfigChange NOTIFICATION-TYPE entConfigChange NOTIFICATION-TYPE
OBJECTS { STATUS current -
entLastChangeTime
}
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. This trap is throttled by the agent.
The value of entLastChangeTime at the time the An agent must not generate more than |
entConfigChange event is detected by the agent is encoded as one entConfigChange 'trap-event' in a five second period,
a var-bind in the trap. This will normally be the same value where a 'trap-event' is the transmission of a single trap
as the sysUpTime instance included in the trap, but may not PDU to a list of trap destinations. If additional
be if trap generation is delayed at all within the agent. configuration changes occur within the five second
'throttling' period, then these events should be discarded
An agent must take care not to generate more than one by the agent. An NMS should periodically check the value of
entConfigChange 'trap-event' in a five second period, where entLastChangeTime to detect any missed entConfigChange
a 'trap-event' is the transmission of a single trap PDU to a events due to throttling or transmission loss."
list of trap destinations. If additional configuration
changes occur within the five second 'throttling' period,
then these events should be discarded by the agent. An NMS
should periodically check the value of entLastChangeTime to
detect any missed entConfigChange events due to throttling
or transmission loss."
::= { entityMIBTraps 1 } ::= { entityMIBTraps 1 }
Draft Entity MIB April 1996 Draft Entity MIB May 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 { entityLogicalGroup } MANDATORY-GROUPS { entityPhysicalGroup, |
entityLogicalGroup, |
entityMappingGroup, |
entityGeneralGroup } |
::= { entityCompliances 1 } ::= { entityCompliances 1 }
-- MIB groupings -- MIB groupings
entityPhysicalGroup OBJECT-GROUP +
OBJECTS { +
entPhysicalDescr, +
entPhysicalVendorType, +
entPhysicalContainedIn, +
entPhysicalClass, +
entPhysicalParentRelPos, +
entPhysicalName +
} +
STATUS current +
DESCRIPTION +
"The collection of objects which are used to represent +
physical system components associated with logical entities, +
for which a single agent provides management information." +
::= { entityGroups 1 } +
entityLogicalGroup OBJECT-GROUP entityLogicalGroup OBJECT-GROUP
OBJECTS { OBJECTS {
entLogicalDescr, entLogicalDescr,
entLogicalType, entLogicalType,
entLogicalCommunity, entLogicalCommunity,
entLogicalTAddress, entLogicalTAddress,
entLogicalTDomain, entLogicalTDomain |
entLastChangeTime
Draft Entity MIB May 1996
} }
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 1 } ::= { entityGroups 2 } |
entityMappingGroup OBJECT-GROUP entityMappingGroup OBJECT-GROUP
OBJECTS { OBJECTS {
entPhysicalDescr, entLPPhysicalIndex, -
entPhysicalVendorType,
entPhysicalContainedIn,
entPhysicalClass,
entPhysicalParentRelPos,
entLPPhysicalIndex,
entAliasLogicalIndexOrZero, entAliasLogicalIndexOrZero,
entAliasMappingIdentifier, entAliasMappingIdentifier,
entPhysicalChildIndex entPhysicalChildIndex
Draft Entity MIB April 1996
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The collection of objects which are used to represent the "The collection of objects which are used to represent the
associations between multiple physical components, associations between multiple logical entities, physical |
interfaces, and port identifiers for which a single agent components, interfaces, and port |
provides management information." identifiers for which a single agent provides management
::= { entityGroups 2 } information."
::= { entityGroups 3 } |
entityGeneralGroup OBJECT-GROUP +
OBJECTS { +
entLastChangeTime +
} +
STATUS current +
DESCRIPTION +
"The collection of objects which are used to represent +
general entity information for which a single agent provides +
management information." +
::= { entityGroups 4 } +
END END
Draft Entity MIB April 1996 Draft Entity MIB May 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. Auxillary components, such as fans, sensors, empty understandable. Auxilary components, |
slots, and sub-modules are not shown, but might be modeled in real such as fans, sensors, empty slots, and sub-modules are not shown, but
implementations. might be modeled in real 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' +
2 slots within the chassis: 2 slots within the chassis:
entPhysicalDescr.2 == "Acme Router Chassis Slot 1" entPhysicalDescr.2 == "Acme Chassis Slot Type AA" |
entPhysicalVendorType.2 == acmeProducts.slotTypes.1 entPhysicalVendorType.2 == acmeProducts.slotTypes.1
entPhysicalContainedIn.2 == 1 entPhysicalContainedIn.2 == 1
entPhysicalClass.2 == container(5) entPhysicalClass.2 == container(5)
entPhysicalParentRelPos.2 == 1 entPhysicalParentRelPos.2 == 1
entPhysicalName.2 == 'S1' |
entPhysicalDescr.3 == "Acme Router Chassis Slot 2" entPhysicalDescr.3 == "Acme Chassis Slot Type AA" |
entPhysicalVendorType.3 == acmeProducts.slotTypes.1 entPhysicalVendorType.3 == acmeProducts.slotTypes.1
entPhysicalContainedIn.3 == 1 entPhysicalContainedIn.3 == 1
entPhysicalClass.3 == container(5) entPhysicalClass.3 == container(5)
entPhysicalParentRelPos.3 == 2 entPhysicalParentRelPos.3 == 2
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 Module Model 10" 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)
entPhysicalParentRelPos.4 == 1
entPhysicalDescr.5 == "Acme Router Ethernet Port 1" Draft Entity MIB May 1996
Draft Entity MIB April 1996 entPhysicalParentRelPos.4 == 1
entPhysicalName.4 == 'M1' +
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' +
entPhysicalDescr.6 == "Acme Router Ethernet Port 2" entPhysicalDescr.6 == "Acme Ethernet-100 Port Rev G" |
entPhysicalVendorType.6 == acmeProducts.portTypes.2 entPhysicalVendorType.6 == acmeProducts.portTypes.2
entPhysicalContainedIn.6 == 4 entPhysicalContainedIn.6 == 4
entPhysicalClass.6 == port(10) entPhysicalClass.6 == port(10)
entPhysicalParentRelPos.6 == 2 entPhysicalParentRelPos.6 == 2
entPhysicalName.6 == 'P2' +
entPhysicalDescr.7 == "Acme Router Fddi Port 3" entPhysicalDescr.7 == "Acme Router-100 F-Port: Rev B" |
entPhysicalVendorType.7 == acmeProducts.portTypes.3 entPhysicalVendorType.7 == acmeProducts.portTypes.3
entPhysicalContainedIn.7 == 4 entPhysicalContainedIn.7 == 4
entPhysicalClass.7 == port(10) entPhysicalClass.7 == port(10)
entPhysicalParentRelPos.7 == 3 entPhysicalParentRelPos.7 == 3
entPhysicalName.7 == 'P3' +
Slot 2 contains another 3-port module: Slot 2 contains another 3-port module:
entPhysicalDescr.8 == "Acme Router Module Model 11" 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' +
entPhysicalDescr.9 == "Acme Router Fddi Port 1" entPhysicalDescr.9 == "Acme Fddi-100 Port Rev CC" |
entPhysicalVendorType.9 == acmeProducts.portTypes.3 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' +
entPhysicalDescr.10 == "Acme Router Ethernet Port 2" 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' +
entPhysicalDescr.11 == "Acme Router Ethernet Port 3" Draft Entity MIB May 1996
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' +
Logical entities -- entLogicalTable Logical entities -- entLogicalTable
2 OSPF instances: 2 OSPF instances: |
entLogicalDescr.1 == "ospf-1" entLogicalDescr.1 == "Acme OSPF v1.1" |
Draft Entity MIB April 1996
entLogicalType.1 == ospf entLogicalType.1 == ospf
entLogicalCommunity.1 == "public-ospf1" entLogicalCommunity.1 == "public-ospf1"
entLogicalTAddress.1 == 124.125.126.127:161 entLogicalTAddress.1 == 124.125.126.127:161
entLogicalTDomain.1 == snmpUDPDomain entLogicalTDomain.1 == snmpUDPDomain
entLogicalDescr.2 == "ospf-2" entLogicalDescr.2 == "Acme OSPF v1.1" |
entLogicalType.2 == ospf entLogicalType.2 == ospf
entLogicalCommunity.2 == "public-ospf2" entLogicalCommunity.2 == "public-ospf2"
entLogicalTAddress.2 == 124.125.126.127:161 entLogicalTAddress.2 == 124.125.126.127:161
entLogicalTDomain.2 == snmpUDPDomain entLogicalTDomain.2 == snmpUDPDomain
2 logical bridges: 2 logical bridges:
entLogicalDescr.3 == "bridge1" entLogicalDescr.3 == "Acme Bridge v2.1.1" |
entLogicalType.3 == dod1dBridge entLogicalType.3 == dod1dBridge
entLogicalCommunity.3 == "public-bridge1" entLogicalCommunity.3 == "public-bridge1"
entLogicalTAddress.3 == 124.125.126.127:161 entLogicalTAddress.3 == 124.125.126.127:161
entLogicalTDomain.3 == snmpUDPDomain entLogicalTDomain.3 == snmpUDPDomain
entLogicalDescr.4 == "bridge2" entLogicalDescr.4 == "Acme Bridge v2.1.1" |
entLogicalType.4 == dod1dBridge entLogicalType.4 == dod1dBridge
entLogicalCommunity.4 == "public-bridge2" entLogicalCommunity.4 == "public-bridge2"
entLogicalTAddress.4 == 124.125.126.127:161 entLogicalTAddress.4 == 124.125.126.127:161
entLogicalTDomain.4 == snmpUDPDomain entLogicalTDomain.4 == snmpUDPDomain
Logical to Physical Mappings: Logical to Physical Mappings:
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 May 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
Draft Entity MIB April 1996
entLPPhysicalIndex.4.11 == 11 entLPPhysicalIndex.4.11 == 11
Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: Physical to Logical to MIB Alias Mappings -- entAliasMappingTable:
Example 1: ifIndex values are global to all logical entities Example 1: ifIndex values are global to all logical entities
entAliasMappingIdentifier.5.0 == ifIndex.1 entAliasMappingIdentifier.5.0 == ifIndex.1
entAliasMappingIdentifier.6.0 == ifIndex.2 entAliasMappingIdentifier.6.0 == ifIndex.2
entAliasMappingIdentifier.7.0 == ifIndex.3 entAliasMappingIdentifier.7.0 == ifIndex.3
entAliasMappingIdentifier.9.0 == ifIndex.4 entAliasMappingIdentifier.9.0 == ifIndex.4
entAliasMappingIdentifier.10.0 == ifIndex.5 entAliasMappingIdentifier.10.0 == ifIndex.5
entAliasMappingIdentifier.11.0 == ifIndex.6 entAliasMappingIdentifier.11.0 == ifIndex.6
skipping to change at page 32, line 43 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
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
Draft Entity MIB April 1996
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 empty,
and the remaining slots contain ethernet repeater modules. [ed. -- Note and the remaining slots contain ethernet repeater modules. [ed. -- Note
that a replacement for the current Repeater MIB (RFC 1516) is likely to that a replacement for the current Repeater MIB (RFC 1516) is likely to
emerge soon, and it will no longer be necessary to access repeater MIB emerge soon, and it will no longer be necessary to access repeater MIB
data in different naming scopes.] data in different naming scopes.]
Physical entities -- entPhysicalTable: Physical entities -- entPhysicalTable:
1 Field-replaceable physical chassis: 1 Field-replaceable physical chassis:
entPhysicalDescr.1 == "Acme Repeater 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' +
2 Chassis Ethernet Backplanes: 2 Chassis Ethernet Backplanes:
entPhysicalDescr.2 == "Ethernet Backplane 1" entPhysicalDescr.2 == "Acme Ethernet Backplane Type A" |
entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1
entPhysicalContainedIn.2 == 1 entPhysicalContainedIn.2 == 1
entPhysicalClass.2 == backplane(4) entPhysicalClass.2 == backplane(4)
entPhysicalParentRelPos.2 == 1 entPhysicalParentRelPos.2 == 1
entPhysicalName.2 == 'B1' +
entPhysicalDescr.3 == "Ethernet Backplane 2" 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' +
3 slots within the chassis: 3 slots within the chassis:
entPhysicalDescr.4 == "Acme Hub Slot 1" entPhysicalDescr.4 == "Acme Hub Slot Type RB" |
Draft Entity MIB May 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' +
entPhysicalDescr.5 == "Acme Hub Slot 2" 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)
entPhysicalParentRelPos.5 == 2 entPhysicalParentRelPos.5 == 2
entPhysicalName.5 == 'Slot 2' +
entPhysicalDescr.6 == "Acme Hub Slot 3" entPhysicalDescr.6 == "Acme Hub Slot Type RB" |
entPhysicalVendorType.6 == acmeProducts.slotTypes.5 entPhysicalVendorType.6 == acmeProducts.slotTypes.5
entPhysicalContainedIn.6 == 1 entPhysicalContainedIn.6 == 1
Draft Entity MIB April 1996
entPhysicalClass.6 == container(5) entPhysicalClass.6 == container(5)
entPhysicalParentRelPos.6 == 3 entPhysicalParentRelPos.6 == 3
entPhysicalName.6 == 'Slot 3' +
Slot 1 contains a plug-in module with 4 10-BaseT ports: Slot 1 contains a plug-in module with 4 10-BaseT ports:
entPhysicalDescr.7 == "10Base-T Module Model 14" entPhysicalDescr.7 == "Acme 10Base-T Module 114 Rev A" |
entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32
entPhysicalContainedIn.7 == 4 entPhysicalContainedIn.7 == 4
entPhysicalClass.7 == module(9) entPhysicalClass.7 == module(9)
entPhysicalParentRelPos.7 == 1 entPhysicalParentRelPos.7 == 1
entPhysicalName.7 == 'M1' +
entPhysicalDescr.8 == "10Base-T Port 1" entPhysicalDescr.8 == "Acme 10Base-T Port RB Rev A" |
entPhysicalVendorType.8 == acmeProducts.portTypes.10 entPhysicalVendorType.8 == acmeProducts.portTypes.10
entPhysicalContainedIn.8 == 7 entPhysicalContainedIn.8 == 7
entPhysicalClass.8 == port(10) entPhysicalClass.8 == port(10)
entPhysicalParentRelPos.8 == 1 entPhysicalParentRelPos.8 == 1
entPhysicalName.8 == 'Ethernet-A' +
entPhysicalDescr.9 == "10Base-T Port 2" 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' +
entPhysicalDescr.10 == "10Base-T Port 3" 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
entPhysicalClass.10 == port(10) entPhysicalClass.10 == port(10)
entPhysicalParentRelPos.10 == 3 entPhysicalParentRelPos.10 == 3
entPhysicalName.10 == 'Ethernet-C' +
entPhysicalDescr.11 == "10Base-T Port 4" 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' +
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" 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' +
entPhysicalDescr.13 == "802.3 AUI Port 1" 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)
Draft Entity MIB April 1996
entPhysicalParentRelPos.13 == 1 entPhysicalParentRelPos.13 == 1
entPhysicalName.13 == 'AUI' +
entPhysicalDescr.14 == "10Base-T Port 2" entPhysicalDescr.14 == "Acme 10Base-T Port RD Rev B" |
entPhysicalVendorType.14 == acmeProducts.portTypes.10 entPhysicalVendorType.14 == acmeProducts.portTypes.14 |
entPhysicalContainedIn.14 == 12 entPhysicalContainedIn.14 == 12
entPhysicalClass.14 == port(10) entPhysicalClass.14 == port(10)
entPhysicalParentRelPos.14 == 2 entPhysicalParentRelPos.14 == 2
entPhysicalName.14 == 'E2' +
Logical entities -- entLogicalTable Logical entities -- entLogicalTable
Repeater 1--comprised of any ports attached to backplane 1 Repeater 1--comprised of any ports attached to backplane 1
entLogicalDescr.1 == "repeater1" 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 == "repeater2" 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
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 36, line 5 skipping to change at page 39, line 33
entLPPhysicalIndex.1.8 == 8 entLPPhysicalIndex.1.8 == 8
entLPPhysicalIndex.1.9 == 9 entLPPhysicalIndex.1.9 == 9
entLPPhysicalIndex.1.13 == 13 entLPPhysicalIndex.1.13 == 13
repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2
entLPPhysicalIndex.2.3 == 3 entLPPhysicalIndex.2.3 == 3
entLPPhysicalIndex.2.10 == 10 entLPPhysicalIndex.2.10 == 10
entLPPhysicalIndex.2.11 == 11 entLPPhysicalIndex.2.11 == 11
entLPPhysicalIndex.2.14 == 14 entLPPhysicalIndex.2.14 == 14
Draft Entity MIB April 1996
Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: Physical to Logical to MIB Alias Mappings -- entAliasMappingTable:
Repeater Port Identifier values are shared by both repeaters: Repeater Port Identifier values are shared by both repeaters:
entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1
entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2
entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3
entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4
entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1
entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2
Physical Containment Tree -- entPhysicalContainsTable Physical Containment Tree -- entPhysicalContainsTable
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
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 April 1996 Draft Entity MIB May 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 April 1996 Draft Entity MIB May 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 39, 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 April 1996 Draft Entity MIB May 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 40, 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 April 1996 Draft Entity MIB May 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 ................................. 8 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 .................................. 9 3.9 Re-Configuration of Entities .................................. 8
3.10 MIB Structure ................................................ 9 3.10 MIB Structure ................................................ 9
3.10.1 entityPhysical Group ....................................... 9
3.10.2 entityLogical Group ........................................ 9
3.10.3 entityMapping Group ........................................ 10
3.10.4 entityGeneral Group ........................................ 10
3.11 Multiple Agents .............................................. 10 3.11 Multiple Agents .............................................. 10
4 Definitions ..................................................... 11 4 Definitions ..................................................... 12
5 Usage Examples .................................................. 29 5 Usage Examples .................................................. 32
5.1 Router/Bridge ................................................. 29 5.1 Router/Bridge ................................................. 32
5.2 Repeaters ..................................................... 33 5.2 Repeaters ..................................................... 36
6 Acknowledgements ................................................ 37 6 Acknowledgements ................................................ 41
7 References ...................................................... 38 7 References ...................................................... 42
8 Security Considerations ......................................... 39 8 Security Considerations ......................................... 43
9 Authors' Addresses .............................................. 39 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/