| OID | 1.3.6.1.2.1.47.1.3.1 |
| Module | ENTITY-MIB (CISCO) |
| Nom | entLPMappingTable |
| Status | current |
| Description | This table contains zero or more rows of logical entity to
physical equipment associations. For each logical entity
known by this agent, there are zero or more mappings to the
physical resources, which are used to realize that logical
entity.
An agent should limit the number and nature of entries in
this table such that only meaningful and non-redundant
information is returned. For example, in a system that
contains a single power supply, mappings between logical
entities and the power supply are not useful and should not
be included.
Also, only the most appropriate physical component, which is
closest to the root of a particular containment tree, should
be identified in an entLPMapping entry.
For example, suppose a bridge is realized on a particular
module, and all ports on that module are ports on this
bridge. A mapping between the bridge and the module would
be useful, but additional mappings between the bridge and
each of the ports on that module would be redundant (because
the entPhysicalContainedIn hierarchy can provide the same
information). On the other hand, if more than one bridge
were utilizing ports on this module, then mappings between
each bridge and the ports it used would be appropriate.
Also, in the case of a single backplane repeater, a mapping
for the backplane to the single repeater entity is not
necessary. |
| Module | ENTITY-MIB (DELL) |
| Nom | entLPMappingTable |
| Status | current |
| Description | This table contains zero or more rows of logical entity to
physical equipment associations. For each logical entity
known by this agent, there are zero or more mappings to the
physical resources which are used to realize that logical
entity.
An agent should limit the number and nature of entries in
this table such that only meaningful and non-redundant
information is returned. For example, in a system which
contains a single power supply, mappings between logical
entities and the power supply are not useful and should not
be included.
Also, only the most appropriate physical component which is
closest to the root of a particular containment tree should
be identified in an entLPMapping entry.
For example, suppose a bridge is realized on a particular
module, and all ports on that module are ports on this
bridge. A mapping between the bridge and the module would be
useful, but additional mappings between the bridge and each
of the ports on that module would be redundant (since the
entPhysicalContainedIn hierarchy can provide the same
information). If, on the other hand, more than one bridge
was utilizing ports on this module, then mappings between
each bridge and the ports it used would be appropriate.
Also, in the case of a single backplane repeater, a mapping
for the backplane to the single repeater entity is not
necessary. |
| Module | ENTITY-MIB (ietf) |
| Nom | entLPMappingTable |
| Status | current |
| Description | This table contains zero or more rows of logical entity to
physical equipment associations. For each logical entity
known by this agent, there are zero or more mappings to the
physical resources, which are used to realize that logical
entity.
An agent should limit the number and nature of entries in
this table such that only meaningful and non-redundant
information is returned. For example, in a system that
contains a single power supply, mappings between logical
entities and the power supply are not useful and should not
be included.
Also, only the most appropriate physical component, which is
closest to the root of a particular containment tree, should
be identified in an entLPMapping entry.
For example, suppose a bridge is realized on a particular
module, and all ports on that module are ports on this
bridge. A mapping between the bridge and the module would
be useful, but additional mappings between the bridge and
each of the ports on that module would be redundant (because
the entPhysicalContainedIn hierarchy can provide the same
information). On the other hand, if more than one bridge
were utilizing ports on this module, then mappings between
each bridge and the ports it used would be appropriate.
Also, in the case of a single backplane repeater, a mapping
for the backplane to the single repeater entity is not
necessary. |
| Module | ENTITY-MIB (Alcatel) |
| Nom | entLPMappingTable |
| Status | current |
| Description | This table contains zero or more rows of logical entity to
physical equipment associations. For each logical entity
known by this agent, there are zero or more mappings to the
physical resources, which are used to realize that logical
entity.
An agent should limit the number and nature of entries in
this table such that only meaningful and non-redundant
information is returned. For example, in a system that
contains a single power supply, mappings between logical
entities and the power supply are not useful and should not
be included.
Also, only the most appropriate physical component, which is
closest to the root of a particular containment tree, should
be identified in an entLPMapping entry.
For example, suppose a bridge is realized on a particular
module, and all ports on that module are ports on this
bridge. A mapping between the bridge and the module would
be useful, but additional mappings between the bridge and
each of the ports on that module would be redundant (because
the entPhysicalContainedIn hierarchy can provide the same
information). On the other hand, if more than one bridge
were utilizing ports on this module, then mappings between
each bridge and the ports it used would be appropriate.
Also, in the case of a single backplane repeater, a mapping
for the backplane to the single repeater entity is not
necessary. |
| Module | ENTITY-MIB (Force10-9.14.2.1) |
| Nom | entLPMappingTable |
| Status | current |
| Description | This table contains zero or more rows of logical entity to
physical equipment associations. For each logical entity
known by this agent, there are zero or more mappings to the
physical resources, which are used to realize that logical
entity.
An agent should limit the number and nature of entries in
this table such that only meaningful and non-redundant
information is returned. For example, in a system that
contains a single power supply, mappings between logical
entities and the power supply are not useful and should not
be included.
Also, only the most appropriate physical component, which is
closest to the root of a particular containment tree, should
be identified in an entLPMapping entry.
For example, suppose a bridge is realized on a particular
module, and all ports on that module are ports on this
bridge. A mapping between the bridge and the module would
be useful, but additional mappings between the bridge and
each of the ports on that module would be redundant (because
the entPhysicalContainedIn hierarchy can provide the same
information). On the other hand, if more than one bridge
were utilizing ports on this module, then mappings between
each bridge and the ports it used would be appropriate.
Also, in the case of a single backplane repeater, a mapping
for the backplane to the single repeater entity is not
necessary. |
| Module | ENTITY-MIB (Nexans) |
| Nom | entLPMappingTable |
| Status | current |
| Description | This table contains zero or more rows of logical entity to
physical equipment associations. For each logical entity
known by this agent, there are zero or more mappings to the
physical resources, which are used to realize that logical
entity.
An agent should limit the number and nature of entries in
this table such that only meaningful and non-redundant
information is returned. For example, in a system that
contains a single power supply, mappings between logical
entities and the power supply are not useful and should not
be included.
Also, only the most appropriate physical component, which is
closest to the root of a particular containment tree, should
be identified in an entLPMapping entry.
For example, suppose a bridge is realized on a particular
module, and all ports on that module are ports on this
bridge. A mapping between the bridge and the module would
be useful, but additional mappings between the bridge and
each of the ports on that module would be redundant (because
the entPhysicalContainedIn hierarchy can provide the same
information). On the other hand, if more than one bridge
were utilizing ports on this module, then mappings between
each bridge and the ports it used would be appropriate.
Also, in the case of a single backplane repeater, a mapping
for the backplane to the single repeater entity is not
necessary. |