Draft Physical Topology MIB September 1997
<draft-ietf-ptopomib-mib-01.txt>
Physical Topology MIB
17 September 1997
Andy Bierman
Cisco Systems
abierman@cisco.com
Kendall S. Jones
Bay Networks
kjones@baynetworks.com
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
1. Introduction
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing physical topology identification and discovery.
Bierman/Jones Expires March 1998 [Page 1]
Draft Physical Topology MIB September 1997
2. The SNMP Network Management Framework
The SNMP Network Management Framework presently consists of three major
components. They are:
o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for
describing and naming objects for the purpose of management.
o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed
objects for the Internet suite of protocols.
o the protocol, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], - the
protocol for accessing managed information.
Textual conventions are defined in RFC 1903 [RFC1903], and conformance
statements are defined in RFC 1904 [RFC1904].
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A
semantically identical MIB conforming to the SNMPv1 SMI can be produced
through the appropriate translation.
2.1. Object Definitions
Managed objects are accessed via a virtual information store, termed the
Management Information Base or MIB. Objects in the MIB are defined
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,
an administratively assigned name. The object type together with an
object instance serves to uniquely identify a specific instantiation of
the object. For human convenience, we often use a textual string,
termed the descriptor, to refer to the object type.
3. Overview
There is a need for a standardized means of representing the physical
network connections pertaining to a given management domain. A
standardized discovery mechanism is also required to increase the
likelihood of multi-vendor interoperability of such physical topology
management information.
Bierman/Jones Expires March 1998 [Page 2]
Draft Physical Topology MIB September 1997
The scope of the physical topology (PTOPO) mechanism is the
identification of connections between two network ports. Network
addresses of SNMP agents containing management information associated
with each port can also be identified.
3.1. Background and Concepts
The need to understand the physical relationships between devices in a
network has always been an important aspect of network management. With
the increasing complexity of multi-segment and multi-media hubs and
switching devices, and management applications that want to identify hot
spots in the network, isolate complex faults (such as configuration
problems) to the physical port, and manage virtual networks (VLANs), the
need for accurate, timely, and system wide physical topology is becoming
more and more critical to maintaining a mission critical network.
Most of today's management platforms do a good job at discovering the
logical topology at the network layer but do not help much in
understanding the actual physical interconnection. This is due to a
lack of standard topology mechanisms at the physical layer to collect
the physical topology information as well as a standard MIB to return
topology information to the management workstation.
Standard topology mechanisms exist for certain media types (such as
FDDI) and proprietary mechanisms exist for other media such as shared
media Ethernet, switched Ethernet, and Token Ring. While standardizing
these or other mechanisms for each of these technologies could be a
painstaking task, standardizing a common MIB and a topology framework
that allows co-existence of multiple topology mechanisms to populate
these MIBs can go a long way toward achieving the goal of providing
network-wide physical topology information at the network management
workstation. The topology framework should specify the core
requirements for topology mechanisms in order to provide the data
necessary to populate the common topology MIB.
These requirements form a set of guidelines to direct the eventual
standardization of a set of topology mechanisms for the various
communication media. In the meantime, the common MIB will allow
creation of physical topology databases which will allow applications to
provide value added services on top of this rich set of data.
Bierman/Jones Expires March 1998 [Page 3]
Draft Physical Topology MIB September 1997
3.2. Terms
Some terms are used throughout this document:
Physical Topology
Physical topology represents the topology model for layer 1 of the
OSI stack - the physical layer. Physical topology consists of
identifying the devices on the network and how they are physically
interconnected. By definition of this document, physical topology
does not imply a physical relationship between ports on the same
device. Other means exist for determining these relationships
(e.g., Entity MIB).
Logical Topology
Logical topology indicates how devices are related based on some
system level attribute. Often this is based on the OSI
communication layer. For instance, network layer topology, or
layer 3 topology, uses network layer address hierarchies to
construct a topological relationship. Management platforms
typically present Layer-3-based topology. This is done by
'discovering' the IP addresses on a network and then grouping these
logically by the subnet portion of the address. Other logical
views of topology include layer-2 based views based on VLAN
membership, and higher layer views such as workgroup membership.
Most higher-layer topology views use network address or user name
to represent members of the topology space.
Chassis
A chassis is a physical component which contains other physical
components. It is identified by an entPhysicalEntry with an
entPhysicalClass value of 'chassis(3)' and an
entPhysicalContainedIn value of zero. A chassis identifier
consists of a globally unique DisplayString.
Local Chassis
The particular chassis containing the SNMP agent implementing the
PTOPO MIB.
Port
A port is a physical component which can be connected to another
port through some medium. It is identified by an entPhysicalEntry
with an entPhysicalClass value of 'port(10)'. A port identifier
consists of a DisplayString which must be unique within the context
of the chassis which contains the port.
Bierman/Jones Expires March 1998 [Page 4]
Draft Physical Topology MIB September 1997
Connection Endpoint
A connection endpoint consists of a physical port, which is
contained within a single physical chassis.
Connection Endpoint Identifier
A connection endpoint is identified by a globally unique chassis
identifier and a port identifier unique within the associated
chassis.
Connection
A connection consists of two physical ports, and the attached
physical medium, configured for the purpose of transferring network
traffic between the ports. A connection is identified by its
endpoint identifiers.
Non-local Connection
A connection for which neither endpoint is located on the local
chassis.
Cloud
A cloud identifies a portion of the topology for which insufficient
information is known to completely infer the interconnection of
devices that make up that portion of the topology.
3.3. Functionality Goals
While the framework presented here is focused on physical topology, it
may well be that the topology mechanisms and MIB described could be
extended to include logical topology information as well. That is not a
focus of this memo at this time, although some consideration may be
given to the framework itself and some notes may be included within this
memo. They will be clearly identified as work for further study.
The following goals can be described for the physical topology
framework.
- Develop a common MIB that represents the physical topology
information available to any one agent in the network. The MIB
should provide enough topology information to allow a management
workstation to navigate across agents to build a complete physical
topology for an arbitrarily large network.
- Provide a set of requirements for topology mechanisms that can
populate the agent MIBs. These requirements should allow for many
different standard and non-standard topology mechanisms to be used
Bierman/Jones Expires March 1998 [Page 5]
Draft Physical Topology MIB September 1997
within a given network, with clear rules describing how these
mechanisms should interact.
- Specify, where appropriate, topology mechanisms for specific media
types. Where standard or industry-accepted mechanisms exist,
indicate how these mechanisms can be used to populate the topology
MIBs.
- Provide a description of the management station procedures to
navigate among topology agents and gather topology information.
3.4. Design Goals
Several factors influenced the design of this physical topology
function:
- Simplicity
The physical topology discovery function should be as simple as
possible, exposing only the information needed to identify
connection endpoints and the SNMP agent(s) associated with each
connection endpoint.
- Completeness
At least one standard discovery protocol capable of supporting the
standard physical topology MIB must be defined. Multi-vendor
interoperability will not be achievable unless a simple and
extensible discovery protocol is available.
- No Functional Overlap
Existing standard MIBs should be utilized whenever possible.
Physical topology information is tightly coupled to functionality
found in the Interfaces MIB [RFC1573] and Entity MIB [RFC2037].
New physical topology MIB objects should not duplicate these MIBs.
- Identifier Stability
Connection endpoint identifiers must be persistent (i.e. stable
across device reboots). Dynamic primary key objects like ifIndex
and entPhysicalIndex are not suitable for table indices in a
physical topology MIB that is replicated and distributed throughout
a managed system.
- Identifier Flexibility
Persistent string-based component identifiers should be supported
from many sources. Chassis identifiers may be found in the Entity
MIB, and port identifiers may be found in the Interfaces MIB or
Bierman/Jones Expires March 1998 [Page 6]
Draft Physical Topology MIB September 1997
Entity MIB.
- Partial Topology Support
Physical topology data for remote components may only be partially
available to an agent. An enumerated INTEGER hierarchy of
component identifier types allows for incomplete physical
connection identifier information to be substituted with secondary
information such as unicast source MAC address or network address
associated with a particular port. A PTOPO Agent maintains
information derived from the 'best' source of information for each
connection. If a 'better' identifier source is detected, the PTOPO
entries are updated accordingly.
- Low Polling Impact
Physical topology polling should be minimized through techniques
such as TimeFiltered data tables (from RMON-2 [RFC2021]), and
last-change notifications.
- Agent Location Neutrality
The MIB should allow a single agent to represent information about
non-local connections and connections terminating on the local
chassis with the same MIB objects.
4. Topology Framework
This section describes the physical topology framework in detail.
4.1. Framework Overview
Several components make up the framework for physical topology.
Devices
The network devices, along with their physical connectivity, make
up the physical topology. Some of these devices (but maybe not all)
provide management agents that report their local physical topology
information to a manager via the physical topology MIB. (Note that
implementation of the PTOPO MIB is required for entities which also
implement PDP.)
These devices include communication infrastructure devices, such as
hubs, switches, and routers, as well as 'leaf' devices such as
workstations, printers, and servers. Generally, user data passes
through infrastructure devices while leaf devices are sources and
Bierman/Jones Expires March 1998 [Page 7]
Draft Physical Topology MIB September 1997
sinks of data. Both types of devices may implement the physical
topology MIB, although implementation within leaf devices is much
less critical.
Topology Mechanisms
A topology mechanism allows the management agents to collect the
information required to populate the topology MIB. Many instances
of a particular topology mechanism may be in use on a given
network, and many different mechanisms may be employed. In some
cases, multiple mechanisms may overlap across part of the physical
topology. Agents may need to be configured so that they know which
mechanism(s) are in use on any given portion of the network. Most
topology mechanisms need to be bounded to a subset of the network
to contain their impact on the network and allow the manager to
collect topology information for a limited subset of devices.
Most topology mechanisms are naturally bounded by the media on
which they run (e.g. FDDI topology mechanism) or by routers in the
network that intentionally block these mechanisms from crossing
into other parts of the network.
Local Topology Data and the Local Topology MIB
Each managed device collects physical topology information from the
network, based on the topology mechanisms it is configured to use.
The data represents this agent's view of the physical network and
may or may not provide enough data to understand the local physical
topology surrounding this agent. It may be necessary to gather
local topology data from a number of agents in order to completely
understand the local physical topology. Part of the local topology
data collected must include the identification of other local
agents which may contain additional topology information. The
definition of 'local' varies based on the topology mechanism or
mechanisms being used.
Manager Process
A manager is responsible for querying management agents to obtain
their local topology information and their knowledge of additional
local agents. The manager might need to query some or all local
agents to build an accurate view of the physical network.
4.1.1. Topology Mechanisms
A topology mechanism is a means, possibly requiring some sort of
protocol, by which devices determine topology information. The formal
requirement is that the mechanism should provide sufficient information
Bierman/Jones Expires March 1998 [Page 8]
Draft Physical Topology MIB September 1997
such that a manager can accurately determine the physical topology of a
set of devices by querying all of those devices for their local view of
the topology. In other words, the mechanism may not be robust enough to
allow the manager to accurately determine any part of the network by
querying a single agent - rather it may need to query all agents to
understand the topology.
Topology mechanisms can be active or passive. Active mechanisms require
a device to send and receive topology protocol packets. These packets
provide the device ID of the source of the packet and may also indicate
out which port the packet was transmitted. When receiving these
packets, devices typically are required to identify on which port that
packet was received.
Passive mechanisms take advantage of data on the network to populate the
topology MIB. By maintaining a list of device identifiers seen on each
port of all devices in a network, it is possible to construct an
accurate physical topology of the network.
A device can act as a boundary device or an intermediate point of a
topology mechanism. If it is a boundary device, it will prevent active
topology mechanisms from passing through to other ports on that device.
Routers are often boundary devices for active topology mechanisms.
Boundary devices serve a critical role in containing topology mechanisms
within a set of devices. This limits the size of topology tables
maintained by the agent, reduces calculations required by managers, and
prevents proliferating topology protocols across the network.
It is possible to have ports that support more than one topology
mechanism. In general this simply allows the port to collect more
robust topology information which should allow the manager to create
more accurate physical topologies. If the set of devices that support
each mechanism has only minimal overlap, the manager may need to work
with the union of the two sets which could increase the processing
requirement substantially.
4.1.2. Manager Process
A manager uses the following process to determine the physical topology
of a portion of the network using a common topology mechanism. Limiting
the manager process to those devices using a common mechanism is not
required, but it does contain the effort and allows the topology to be
built piece by piece in a methodical way. The process described assumes
that a single topology mechanism is in use across the set of devices
over which physical topology is being determined. Manager processing
Bierman/Jones Expires March 1998 [Page 9]
Draft Physical Topology MIB September 1997
for overlapping topology mechanisms is described subsequently.
- a manager first identifies a managed device on the network to begin
the physical topology collection process
- the manager chooses a port to begin the topology determination and
obtains the topology mechanism and instance for that port
- for each port on the device which use the same instance of this
topology mechanism, the manager obtains the topology data for that
port and any downstream agent identities.
- the manager then queries all downstream agents identified by this
device and repeats the previous step.
- the manager continues walking through the topology until it has no
other new agents identified and has collected topology data from
all agents.
- the manager then performs topology calculations as required based
on topology data returned to determine the actual physical topology
of this collection of devices.
- once this portion of the network has been mapped, the manager
should identify other ports on devices that are running a different
instance of the topology mechanism or a different topology
mechanism altogether and repeat the process to map that topology.
- following this iterative procedure, the physical topology of an
arbitrarily large network can be calculated.
5. Physical Topology MIB
This section describes and defines the Physical Topology MIB.
5.1. Persistent Identifiers
The PTOPO MIB utilizes non-volatile identifiers to distinguish
individual chassis and port components. These identifiers are
associated with external objects in order to relate topology information
to the existing managed objects.
In particular, an object from the Entity MIB or Interfaces MIB can be
used as the 'reference-point' for a connection component identifier.
Bierman/Jones Expires March 1998 [Page 10]
Draft Physical Topology MIB September 1997
The Physical Topology MIB uses two identifier types pertaining to the
PTOPO MIB:
- globally unique chassis identifiers.
- port identifiers; unique only within the chassis which contains the
port.
Identifiers are stored as OCTET STRINGs, which are limited to 32 bytes
in length, This supports flexible naming conventions and constrains the
non-volatile storage requirements for an agent.
5.2. Relationship to Entity MIB
The Entity MIB [RFC2037] allows the physical component inventory and
hierarchy to be identified. However, the Entity MIB does not provide
persistent component identifiers, which are required for the PTOPO MIB.
Therefore, an extension to the Entity MIB is defined [ENTITY-EXT] to
provide that feature. The new table augments the entPhysicalTable, and
adds a read-write 'alias' identifier, similar to the ifAlias MIB object
for interfaces.
For agents implementing the PTOPO MIB, this new object must be used to
represent the chassis identifier. Port identifiers can be based on the
entPhysicalAlias object associated with the port, but only if the port
is not represented as an interface in the ifXTable.
Implementation of the entPhysicalGroup and entPhysicalXGroup is
mandatory for SNMP agents which implement the PTOPO MIB.
5.3. Relationship to Interfaces MIB
The PTOPO MIB requires a persistent identifier for each port. The
Interfaces MIB [RFC1573] provides a standard mechanism for managing
network interfaces. Unfortunately, not all ports which may be
represented in the PTOPO MIB are also represented in the Interfaces MIB
(e.g., repeater ports).
For agents which implement the PTOPO MIB, for each port represented in
the Interfaces MIB, the agent must use the associated ifAlias value for
the port identifier. For each port not represented in the Interfaces
MIB, the associated entPhysicalAlias value must be used for the port
identifier.
Bierman/Jones Expires March 1998 [Page 11]
Draft Physical Topology MIB September 1997
5.4. Relationship to RMON-2 MIB
The RMON-2 MIB [RFC2021] contains address mapping information which can
be integrated with physical topology information. The physical ports
identified in a physical topology MIB can be related to the MAC and
network layer addresses found in the addressMapTable.
5.5. Relationship to Bridge MIB
The Bridge MIB [RFC1493] contains information which may relate to
physical ports represented in the ptopoConnTable. Entries in the
dot1dBasePortTable and dot1dStpPortTable can by related to physical
ports represented in the PTOPO MIB. Also, bridge port MAC addresses may
be used as chassis and port identifiers in some situations.
5.6. Relationship to Repeater MIB
The Repeater MIB [RFC2108] contains information which may relate to
physical ports represented in the PTOPO MIB. Entries in the
rptrPortTable and rptrMonitorPortTable can by related to physical ports
represented in the ptopoConnTable. Entries in the rptrInfoTable and
rptrMonTable can be related to repeater backplanes possibly represented
in the ptopoConnTable.
5.7. MIB Structure
The PTOPO MIB contains three MIB object groups:
- ptopoData
Exposes physical topology data learned from discovery protocols
and/or manual configuration.
- ptopoGeneral
Contains general information regarding PTOPO MIB status.
- ptopoConfig
Contains configuration variables for the PTOPO MIB agent function.
5.7.1. ptopoData Group
This group contains a single table to identity physical topology data.
The ptopoConnTable contains information about the connections learned or
configured on behalf of the PTOPO MIB SNMP Agent.
Bierman/Jones Expires March 1998 [Page 12]
Draft Physical Topology MIB September 1997
5.7.2. ptopoGeneral Group
This group contains some scalar objects to report the status of the
PTOPO MIB information currently known to the SNMP Agent. The global last
change time, and table add and delete counters allow an NMS to set
threshold alarms to trigger PTOPO polling.
5.7.3. ptopoConfig Group
This group contains tables to configure the behavior of the physical
topology function. The transmission of ptopoLastChange traps can be
configured using the ptopoConfigTrapsEnabled scalar MIB object.
5.8. Physical Topology MIB Definitions
PTOPO-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
TimeFilter
FROM RMON2-MIB
PhysicalIndex
FROM ENTITY-MIB;
ptopoMIB MODULE-IDENTITY
LAST-UPDATED "9709090000Z"
ORGANIZATION "IETF; PTOPOMIB Working Group"
CONTACT-INFO
"PTOPOMIB WG Discussion:
ptopo@3com.com
Subscription:
majordomo@3com.com
msg body: [un]subscribe ptopomib
Andy Bierman
Cisco Systems Inc.
170 West Tasman Drive
San Jose, CA 95134
408-527-3711
abierman@cisco.com
Bierman/Jones Expires March 1998 [Page 13]
Draft Physical Topology MIB September 1997
Kendall S. Jones
Bay Networks
4401 Great America Parkway
Santa Clara, CA 95134
408-495-7356
kjones@baynetworks.com"
DESCRIPTION
"The MIB module for physical topology information."
::= { experimental xx }
ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 }
-- MIB groups
ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 }
ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 }
ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 }
-- textual conventions
--
-- IANAAddrFamily TC copied from
-- draft-ietf-disman-framework-00.txt
-- Eventually, it will be included from a general TC module
--
IANAAddrFamily ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An address family. Values are defined in Assigned Numbers,
RFC1700. Note that not all these values make sense in all
contexts where this type is used in this MIB, but they are
included for completeness."
REFERENCE
"Assigned Numbers, [RFC1700], ADDRESS FAMILY NUMBERS"
SYNTAX INTEGER {
other(0),
ipV4(1),
ipV6(2),
nsap(3),
hdlc(4),
bbn1822(5),
ieee802(6),
e163(7),
e164(8),
f69(9),
Bierman/Jones Expires March 1998 [Page 14]
Draft Physical Topology MIB September 1997
x121(10),
ipx(11),
appleTalk(12),
decnetIV(13),
banyanVines(14),
e164WithNsap(15)
}
PtopoGenAddr ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of an address."
SYNTAX OCTET STRING (SIZE (0..20))
PtopoChassisIdType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes the source of a chassis identifier.
The enumeration 'chasIdEntPhysicalAlias(1)' represents a
chassis identifier based on the value of entPhysicalAlias
for a chassis component (i.e., an entPhysicalClass value of
'chassis(3)').
The enumeration 'chasIdIfAlias(2)' represents a chassis
identifier based on the value of ifAlias for an interface on
the containing chassis.
The enumeration 'chasIdPortEntPhysicalAlias(3)' represents a
chassis identifier based on the value of entPhysicalAlias
for a port or backplane component (i.e., entPhysicalClass
value of 'port(10)' or 'backplane(4)'), within the
containing chassis.
The enumeration 'chasIdMacAddress(4)' represents a chassis
identifier based on the value of a unicast source MAC
address (encoded in network byte order and IEEE 802.3
canonical bit order), of a port on the containing chassis.
The enumeration 'chasIdPtopoGenAddr(5)' represents a chassis
identifier based on a network address, associated with a
particular chassis. The encoded address is actually composed
of two fields. The first field is a single octet,
representing the IANAAddrFamily for the specific address
type, and the second field is the PtopoGenAddr address
Bierman/Jones Expires March 1998 [Page 15]
Draft Physical Topology MIB September 1997
value."
SYNTAX INTEGER {
chasIdEntPhysicalAlias(1),
chasIdIfAlias(2),
chasIdPortEntPhysicalAlias(3),
chasIdMacAddress(4),
chasIdPtopoGenAddr(5)
}
PtopoChassisId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes the format of a chassis identifier
string. Objects of this type are always used with an
associated PtopoChassisIdType object, which identifies the
format of the particular PtopoChassisId object instance.
If the associated PtopoChassisIdType object has a value of
'chasIdEntPhysicalAlias(1)', then the octet string
identifies a particular instance of the entPhysicalAlias
object for a chassis component (i.e., an entPhysicalClass
value of 'chassis(3)').
If the associated PtopoChassisIdType object has a value of
'chasIdIfAlias(2)', then the octet string identifies a
particular instance of the ifAlias object for an interface
on the containing chassis.
If the associated PtopoChassisIdType object has a value of
'chasIdPortEntPhysicalAlias(3)', then the octet string
identifies a particular instance of the entPhysicalAlias
object for a port or backplane component within the
containing chassis.
If the associated PtopoChassisIdType object has a value of
'chasIdMacAddress(4)', then this string identifies a
particular unicast source MAC address (encoded in network
byte order and IEEE 802.3 canonical bit order), of a port on
the containing chassis.
If the associated PtopoChassisIdType object has a value of
'chasIdPtopoGenAddr(5)', then this string identifies a
particular network address, encoded in network byte order,
associated with one or more ports on the containing chassis.
The first octet contains the IANAAddrFamily enumeration
Bierman/Jones Expires March 1998 [Page 16]
Draft Physical Topology MIB September 1997
value for the specific address type, and octets 2 through N
contain the PtopoGenAddr address value in network byte
order."
SYNTAX OCTET STRING (SIZE (1..32))
PtopoPortIdType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes the source of a particular type of port
identifier used in the PTOPO MIB.
The enumeration 'portIdIfAlias(1)' represents a port
identifier based on the ifAlias MIB object.
The enumeration 'portIdPortEntPhysicalAlias(2)' represents a
port identifier based on the value of entPhysicalAlias for a
port or backplane component (i.e., entPhysicalClass value of
'port(10)' or 'backplane(4)'), within the containing
chassis.
The enumeration 'portIdMacAddr(3)' represents a port
identifier based on a unicast source MAC address, which has
been detected by the agent and associated with a particular
port.
The enumeration 'portIdPtopoGenAddr(4)' represents a port
identifier based on a network address, detected by the agent
and associated with a particular port."
SYNTAX INTEGER {
portIdIfAlias(1),
portIdEntPhysicalAlias(2),
portIdMacAddr(3),
portIdPtopoGenAddr(4)
}
PtopoPortId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes the format of a port identifier string.
Objects of this type are always used with an associated
PtopoPortIdType object, which identifies the format of the
particular PtopoPortId object instance.
If the associated PtopoPortIdType object has a value of
'portIdIfAlias(1)', then the octet string identifies a
Bierman/Jones Expires March 1998 [Page 17]
Draft Physical Topology MIB September 1997
particular instance of the ifAlias object.
If the associated PtopoPortIdType object has a value of
'portIdEntPhysicalAlias(2)', then the octet string
identifies a particular instance of the entPhysicalAlias
object for a port component (i.e., entPhysicalClass value of
'port(10)').
If the associated PtopoPortIdType object has a value of
'portIdMacAddr(3)', then this string identifies a particular
unicast source MAC address associated with the port.
If the associated PtopoPortIdType object has a value of
'portIdPtopoGenAddr(4)', then this string identifies a
network address associated with the port. The first octet
contains the IANAAddrFamily enumeration value for the
specific address type, and octets 2 through N contain the
PtopoGenAddr address value in network byte order."
SYNTAX OCTET STRING (SIZE (1..32))
PtopoAddrSeenState ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes the state of address detection for a
particular type of port identifier used in the PTOPO MIB.
The enumeration 'not-used(1)' represents an entry for which
the particular MIB object is not applicable to the remote
connection endpoint, e.g. ptopoConnRemotePortType equals
'portIdIfAlias(1)'.
The enumeration 'unknown(2)' represents an entry for which
the particular address collection state is not known.
The enumeration 'one-addr(3)' represents an entry for which
exactly one source address (of the type indicated by the
particular MIB object), has been detected.
The enumeration 'multi-addr(4)' represents an entry for
which more than one source address (of the type indicated by
the particular MIB object), has been detected."
SYNTAX INTEGER {
not-used(1),
unknown(2),
Bierman/Jones Expires March 1998 [Page 18]
Draft Physical Topology MIB September 1997
one-addr(3),
multi-addr(4)
}
-- ***********************************************************
--
-- P T O P O D A T A G R O U P
--
-- ***********************************************************
-- Connection Table
ptopoConnTable OBJECT-TYPE
SYNTAX SEQUENCE OF PtopoConnEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains one row per physical network connection
known to this agent. The agent may wish to ensure that only
one ptopoConnEntry is present for each local port, or it may
choose to maintain multiple ptopoConnEntries for the same
local port.
Entries based on lower numbered identifier types are
preferred over higher numbered identifier types, i.e., lower
values of the ptopoConnRemoteChassisType and
ptopoConnRemotePortType objects."
::= { ptopoData 1 }
ptopoConnEntry OBJECT-TYPE
SYNTAX PtopoConnEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular physical network connection.
Entries may be created and deleted in this table, either
manually or by the agent, if a physical topology discovery
process is active."
INDEX {
ptopoConnTimeMark,
ptopoConnLocalChassis,
ptopoConnLocalPort,
ptopoConnIndex
}
Bierman/Jones Expires March 1998 [Page 19]
Draft Physical Topology MIB September 1997
::= { ptopoConnTable 1 }
PtopoConnEntry ::= SEQUENCE {
ptopoConnTimeMark TimeFilter,
ptopoConnLocalChassis PhysicalIndex,
ptopoConnLocalPort PhysicalIndex,
ptopoConnIndex Integer32,
ptopoConnRemoteChassisType PtopoChassisIdType,
ptopoConnRemoteChassis PtopoChassisId,
ptopoConnRemotePortType PtopoPortIdType,
ptopoConnRemotePort PtopoPortId,
ptopoConnDiscAlgorithm AutonomousType,
ptopoConnAgentNetAddrType IANAAddrFamily,
ptopoConnAgentNetAddr PtopoGenAddr,
ptopoConnMultiMacSASeen PtopoAddrSeenState,
ptopoConnMultiNetSASeen PtopoAddrSeenState,
ptopoConnIsStatic TruthValue,
ptopoConnLastVerifyTime TimeStamp,
ptopoConnRowStatus RowStatus
}
ptopoConnTimeMark OBJECT-TYPE
SYNTAX TimeFilter
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A TimeFilter for this entry. See the TimeFilter textual
convention in RFC 2021 to see how this works."
::= { ptopoConnEntry 1 }
ptopoConnLocalChassis OBJECT-TYPE
SYNTAX PhysicalIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entPhysicalIndex value used to identify the chassis
component associated with the local connection endpoint."
::= { ptopoConnEntry 2 }
ptopoConnLocalPort OBJECT-TYPE
SYNTAX PhysicalIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entPhysicalIndex value used to identify the port
Bierman/Jones Expires March 1998 [Page 20]
Draft Physical Topology MIB September 1997
component associated with the local connection endpoint."
::= { ptopoConnEntry 3 }
ptopoConnIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object represents an arbitrary local integer value
used by this agent to identify a particular connection
instance, unique only for the indicated local connection
endpoint.
[ed. WG must decide on index re-use issue; Only one of the
following two paragraphs will remain.]
A particular ptopoConnIndex value may be reused in the event
an entry is aged out and later re-learned with the same
remote chassis and port identifiers.
[ed. - OR]
A particular ptopoConnIndex value may only be used once for
a given (ptopoConnLocalChassis, ptopoConnLocalPort) pair,
since the last reinitialization of the PTOPO agent."
::= { ptopoConnEntry 4 }
ptopoConnRemoteChassisType OBJECT-TYPE
SYNTAX PtopoChassisIdType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of encoding used to identify the chassis
associated with the remote connection endpoint.
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 5 }
ptopoConnRemoteChassis OBJECT-TYPE
SYNTAX PtopoChassisId
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The string value used to identify the chassis component
Bierman/Jones Expires March 1998 [Page 21]
Draft Physical Topology MIB September 1997
associated with the remote connection endpoint.
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 6 }
ptopoConnRemotePortType OBJECT-TYPE
SYNTAX PtopoPortIdType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of port identifier encoding used in the associated
'ptopoConnRemotePort' object.
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 7 }
ptopoConnRemotePort OBJECT-TYPE
SYNTAX PtopoPortId
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The string value used to identify the port component
associated with the remote connection endpoint.
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 8 }
ptopoConnDiscAlgorithm OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of the algorithm used to discover the
information contained in this conceptual row.
A value of ptopoDiscoveryPDP indicates this entry was
configured using the PTOPO Discovery Protocol.
A value of ptopoDiscoveryLocal indicates this entry was
configured by the local agent, without use of a discovery
protocol.
Bierman/Jones Expires March 1998 [Page 22]
Draft Physical Topology MIB September 1997
A value of { 0 0 } indicates this entry was created manually
by an NMS via the associated RowStatus object. "
::= { ptopoConnEntry 9 }
ptopoConnAgentNetAddrType OBJECT-TYPE
SYNTAX IANAAddrFamily
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This network address type of the associated
ptopoConnNetAddr object, unless that object contains a zero
length string. In such a case, an NMS application should
ignore any returned value for this object.
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 10 }
ptopoConnAgentNetAddr OBJECT-TYPE
SYNTAX PtopoGenAddr
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object identifies a network address which may be used
to reach an SNMP agent entity containing information for the
chassis and port components represented by the associated
'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects.
If no such address is known, then this object shall contain
an empty string.
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 11 }
ptopoConnMultiMacSASeen OBJECT-TYPE
SYNTAX PtopoAddrSeenState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates if multiple unicast source MAC
addresses have been detected by the agent from the remote
connection endpoint, since the creation of this entry.
If this entry has an associated ptopoConnRemoteChassisType
and/or ptopoConnRemotePortType value other than
Bierman/Jones Expires March 1998 [Page 23]
Draft Physical Topology MIB September 1997
'portIdMacAddr(3)', then the value 'not-used(1)' is
returned.
Otherwise, one of the following conditions must be true:
If the agent has not yet detected any unicast source MAC
addresses from the remote port, then the value 'unknown(2)'
is returned.
If the agent has detected exactly one unicast source MAC
address from the remote port, then the value 'one-addr(3)'
is returned.
If the agent has detected more than one unicast source MAC
address from the remote port, then the value 'multi-addr(4)'
is returned."
::= { ptopoConnEntry 12 }
ptopoConnMultiNetSASeen OBJECT-TYPE
SYNTAX PtopoAddrSeenState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates if multiple network layer source
addresses have been detected by the agent from the remote
connection endpoint, since the creation of this entry.
If this entry has an associated ptopoConnRemoteChassisType
or ptopoConnRemotePortType value other than
'portIdGenAddr(4)' then the value 'not-used(1)' is returned.
Otherwise, one of the following conditions must be true:
If the agent has not yet detected any network source
addresses of the appropriate type from the remote port, then
the value 'unknown(2)' is returned.
If the agent has detected exactly one network source address
of the appropriate type from the remote port, then the value
'one-addr(3)' is returned.
If the agent has detected more than one network source
address (of the same appropriate type) from the remote port,
this the value 'multi-addr(4)' is returned."
::= { ptopoConnEntry 13 }
Bierman/Jones Expires March 1998 [Page 24]
Draft Physical Topology MIB September 1997
ptopoConnIsStatic OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object identifies static ptopoConnEntries. If this
object has the value 'true(1)', then this entry is not
subject to any age-out mechanisms implemented by the agent.
If this object has the value 'false(2)', then this entry is
subject to all age-out mechanisms implemented by the agent.
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
DEFVAL { false }
::= { ptopoConnEntry 14 }
ptopoConnLastVerifyTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the associated value of ptopoConnIsStatic is equal to
'false(2)', then this object contains the value of sysUpTime
at the time the conceptual row was last verified by the
agent, e.g. via reception of a PDP message pertaining to the
associated remote chassis and port.
If the associated value of ptopoConnIsStatic is equal to
'true(1)', then this object shall contain the value of
sysUpTime at the time this entry was last activated (i.e.,
ptopoConnRowStatus set to 'active(1)')."
::= { ptopoConnEntry 15 }
ptopoConnRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row."
::= { ptopoConnEntry 16 }
-- ***********************************************************
--
Bierman/Jones Expires March 1998 [Page 25]
Draft Physical Topology MIB September 1997
-- P T O P O G E N E R A L G R O U P
--
-- ***********************************************************
-- last change time stamp for the whole MIB
ptopoLastChangeTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time a conceptual row is
created, modified, or deleted in the ptopoConnTable.
An NMS can use this object to reduce polling of the
ptopoData group objects."
::= { ptopoGeneral 1 }
ptopoConnTabInserts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an entry has been inserted into the
ptopoConnTable."
::= { ptopoGeneral 2 }
ptopoConnTabDeletes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an entry has been deleted from the
ptopoConnTable."
::= { ptopoGeneral 3 }
ptopoConnTabDrops OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an entry would have been added to the
ptopoConnTable, (e.g., via information learned from PDP),
but was not because of insufficient resources."
Bierman/Jones Expires March 1998 [Page 26]
Draft Physical Topology MIB September 1997
::= { ptopoGeneral 4 }
ptopoConnTabReplaces OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an entry for a particular connection
has been replaced with an entry for the same local port, but
different values for any of the following objects:
- ptopoConnRemoteChassisType
- ptopoConnRemoteChassis
- ptopoConnRemotePortType
- ptopoConnRemotePort"
::= { ptopoGeneral 5 }
ptopoConnTabAgeouts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an entry has been deleted from the
ptopoConnTable because the information timeliness interval
for that entry has expired."
::= { ptopoGeneral 6 }
-- ***********************************************************
--
-- P T O P O C O N F I G G R O U P
--
-- ***********************************************************
ptopoConfigTrapsEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object controls the transmission of PTOPO traps.
If the agent is capable of storing non-volatile
configuration, then the value of this object must be
restored after a re-initialization of the management
system."
Bierman/Jones Expires March 1998 [Page 27]
Draft Physical Topology MIB September 1997
DEFVAL { false }
::= { ptopoConfig 1 }
ptopoConfigMaxHoldTime OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the desired time interval for which
an agent will maintain dynamic ptopoConnEntries.
After the specified number of seconds since the last time an
entry was verified, in the absence of new verification
(e.g., receipt of a PDP message), the agent shall remove the
entry. Note that entries may not always be removed
immediately, but may possibly be removed at periodic garbage
collection intervals.
This object only affects dynamic ptopoConnEntries, i.e. for
which ptopoConnIsStatic equals 'false(2)'. Static entries
are not aged out.
Note that dynamic ptopoConnEntries may also be removed by
the agent due to the expired timeliness of learned topology
information (e.g., timeliness interval for a remote port
expires). The actual age-out interval for a given entry is
defined by the following formula:
age-out-time =
min(ptopoConfigMaxHoldTime, <entry-specific hold-time>)
where <entry-specific hold-time> is determined by the
discovery algorithm, and may be different for each entry.
For entries discovered with PDP, this is the particular
'time-to-live' value from the most recent PDP message
associated with the entry."
DEFVAL { 300 }
::= { ptopoConfig 2 }
-- PTOPO MIB Trap Definitions
ptopoMIBTraps OBJECT IDENTIFIER ::= { ptopoMIB 2 }
ptopoMIBTrapPrefix OBJECT IDENTIFIER ::= { ptopoMIBTraps 0 }
Bierman/Jones Expires March 1998 [Page 28]
Draft Physical Topology MIB September 1997
ptopoConfigChange NOTIFICATION-TYPE
OBJECTS {
ptopoConnTabInserts,
ptopoConnTabDeletes,
ptopoConnTabDrops,
ptopoConnTabReplaces,
ptopoConnTabAgeouts
}
STATUS current
DESCRIPTION
"A ptopoConfigChange trap is sent when the value of
ptopoLastChangeTime changes. It can be utilized by an NMS to
trigger physical topology table maintenance polls.
An agent must not generate more than one ptopoConfigChange
trap-event in a five second period, where a 'trap-event' is
the transmission of a single trap PDU to a list of trap
destinations. If additional configuration changes occur
within the five second throttling period, then these trap-
events should be suppressed by the agent. An NMS should
periodically check the value of ptopoLastChangeTime to
detect any missed ptopoConfigChange trap-events, e.g. due to
throttling or transmission loss."
::= { ptopoMIBTrapPrefix 1 }
-- PTOPO Registration Points
ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 }
-- values used with ptopoConnDiscAlgorithm object
ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= { ptopoRegistrationPoints 1 }
ptopoDiscoveryPDP OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 1 }
ptopoDiscoveryLocal OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 2 }
-- conformance information
ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 }
ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 }
ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 }
-- compliance statements
Bierman/Jones Expires March 1998 [Page 29]
Draft Physical Topology MIB September 1997
ptopoCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which implement
the PTOPO MIB."
MODULE -- this module
MANDATORY-GROUPS {
ptopoDataGroup,
ptopoGeneralGroup,
ptopoConfigGroup,
ptopoNotificationsGroup
}
::= { ptopoCompliances 1 }
-- MIB groupings
ptopoDataGroup OBJECT-GROUP
OBJECTS {
ptopoConnRemoteChassisType,
ptopoConnRemoteChassis,
ptopoConnRemotePortType,
ptopoConnRemotePort,
ptopoConnDiscAlgorithm,
ptopoConnAgentNetAddrType,
ptopoConnAgentNetAddr,
ptopoConnMultiMacSASeen,
ptopoConnMultiNetSASeen,
ptopoConnIsStatic,
ptopoConnLastVerifyTime,
ptopoConnRowStatus
}
STATUS current
DESCRIPTION
"The collection of objects which are used to represent
physical topology information for which a single agent
provides management information.
This group is mandatory for all implementations of the PTOPO
MIB."
::= { ptopoGroups 1 }
ptopoGeneralGroup OBJECT-GROUP
OBJECTS {
ptopoLastChangeTime,
ptopoConnTabInserts,
Bierman/Jones Expires March 1998 [Page 30]
Draft Physical Topology MIB September 1997
ptopoConnTabDeletes,
ptopoConnTabDrops,
ptopoConnTabReplaces,
ptopoConnTabAgeouts
}
STATUS current
DESCRIPTION
"The collection of objects which are used to report the
general status of the PTOPO MIB implementation.
This group is mandatory for all agents which implement the
PTOPO MIB."
::= { ptopoGroups 2 }
ptopoConfigGroup OBJECT-GROUP
OBJECTS {
ptopoConfigTrapsEnabled,
ptopoConfigMaxHoldTime
}
STATUS current
DESCRIPTION
"The collection of objects which are used to configure the
PTOPO MIB implementation behavior.
This group is mandatory for agents which implement the PTOPO
MIB."
::= { ptopoGroups 3 }
ptopoNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
ptopoConfigChange
}
STATUS current
DESCRIPTION
"The collection of notifications used to indicate PTOPO MIB
data consistency and general status information.
This group is mandatory for agents which implement the PTOPO
MIB."
::= { ptopoGroups 4 }
END
Bierman/Jones Expires March 1998 [Page 31]
Draft Physical Topology MIB September 1997
6. References
[ENTITY-EXT]
Bierman, A., McCloghrie, K., "Entity MIB Extensions for Persistent
Component Identification", draft-bierman-entmib-compid-00.txt,
Cisco Systems, July 1997.
[RFC1157]
Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
Management Protocol", RFC 1157, SNMP Research, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[RFC1213]
McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991.
[RFC1493]
E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie, "Definitions
of Managed Objects for Bridges", RFC 1493, Cisco Systems, Inc.,
Digital Equipment Corporation, Hughes LAN Systems, Inc., July 1993.
[RFC1573]
McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution",
RFC 1573, Hughes LAN Systems, FTP Software, January 1994.
[RFC1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[RFC1902]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[RFC1903]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC1904]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Conformance Statements for version 2 of the Simple
Bierman/Jones Expires March 1998 [Page 32]
Draft Physical Topology MIB September 1997
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Protocol Operations for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC2021]
S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021,
International Network Services, January 1997.
[RFC2037]
McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037,
Cisco Systems, October 1996.
[RFC2108]
K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, "Definitions
of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2",
RFC 2108, 3Com Corporation, Madge Networks (Israel) Ltd., Coloma
Communications, Cisco Systems Inc., February 1997.
Bierman/Jones Expires March 1998 [Page 33]
Draft Physical Topology MIB September 1997
7. Security Considerations
This MIB exposes information about the physical connectivity for a
particular portion of a network. A network administrator may wish to
restrict SNMP access to such information, but such agent security
configuration is beyond the scope of this document.
A network administrator may also wish to inhibit transmission of any
ptopoConfigChange traps by setting the ptopoConfigTrapsEnabled object to
'false(2)'.
8. Authors' Addresses
Andy Bierman
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: 408-527-3711
Email: abierman@cisco.com
Kendall S. Jones
Bay Networks
4401 Great America Parkway
Santa Clara, CA 95134
Phone: 408-495-7356
Email: kjones@baynetworks.com
Bierman/Jones Expires March 1998 [Page 34]
Draft Physical Topology MIB September 1997
Table of Contents
1 Introduction .................................................... 1
2 The SNMP Network Management Framework ........................... 2
2.1 Object Definitions ............................................ 2
3 Overview ........................................................ 2
3.1 Background and Concepts ....................................... 3
3.2 Terms ......................................................... 4
3.3 Functionality Goals ........................................... 5
3.4 Design Goals .................................................. 6
4 Topology Framework .............................................. 7
4.1 Framework Overview ............................................ 7
4.1.1 Topology Mechanisms ......................................... 8
4.1.2 Manager Process ............................................. 9
5 Physical Topology MIB ........................................... 10
5.1 Persistent Identifiers ........................................ 10
5.2 Relationship to Entity MIB .................................... 11
5.3 Relationship to Interfaces MIB ................................ 11
5.4 Relationship to RMON-2 MIB .................................... 12
5.5 Relationship to Bridge MIB .................................... 12
5.6 Relationship to Repeater MIB .................................. 12
5.7 MIB Structure ................................................. 12
5.7.1 ptopoData Group ............................................. 12
5.7.2 ptopoGeneral Group .......................................... 13
5.7.3 ptopoConfig Group ........................................... 13
5.8 Physical Topology MIB Definitions ............................. 13
6 References ...................................................... 32
7 Security Considerations ......................................... 34
8 Authors' Addresses .............................................. 34
Bierman/Jones Expires March 1998 [Page 35]