As per Relevance of the word associated, we have this rfc below:
Network Working Group A.
Request for Comments: 2922 Cisco Systems, Inc
Category: Informational K.
Nortel
September 2000
Physical Topology
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo defines a 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
physical topology identification and discovery
Table of
1 The SNMP Network Management Framework ............................2
2 Overview .........................................................3
2.1 Terms ..........................................................3
2.2 Design Goals ...................................................5
3 Topology Framework ...............................................6
3.1 Devices and Topology Agents ....................................6
3.2 Topology Mechanisms ............................................7
3.3 Future Considerations ..........................................7
4 Physical Topology MIB ............................................7
4.1 Persistent Identifiers .........................................8
4.2 Relationship to Entity MIB .....................................8
4.3 Relationship to Interfaces MIB .................................9
4.4 Relationship to RMON-2 MIB .....................................9
4.5 Relationship to Bridge MIB .....................................9
4.6 Relationship to Repeater MIB ...................................9
4.7 MIB Structure .................................................10
4.7.1 ptopoData Group .............................................10
4.7.2 ptopoGeneral Group ..........................................10
4.7.3 ptopoConfig Group ...........................................10
4.8 Physical Topology MIB Definitions .............................10
Bierman & Jones Informational [Page 1]
RFC 2922 Physical Topology MIB September 2000
5 Intellectual Property ...........................................27
6 Acknowledgements ................................................28
7 References ......................................................28
8 Security Considerations .........................................30
9 Authors' Addresses ..............................................31
10 Full Copyright Statement .......................................32
1. The SNMP Network Management
The SNMP Management Framework presently consists of five
components
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events
the purpose of management. The first version of
Structure of Management Information (SMI) is called SMIv
and described in STD 16, RFC 1155 [RFC1155], STD 16,
1212 [RFC1212] and RFC 1215 [RFC1215]. The second version
called SMIv2, is described in STD 58, RFC 2578 [RFC2578],
STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
o Message protocols for transferring management information
The first version of the SNMP message protocol is
SNMPv1 and described in STD 15, RFC 1157 [RFC1157].
second version of the SNMP message protocol, which is not
Internet standards track protocol, is called SNMPv2c
described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906].
third version of the message protocol is called SNMPv3
described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and
2574 [RFC2574].
o Protocol operations for accessing management information
The first set of protocol operations and associated
formats is described in STD 15, RFC 1157 [RFC1157].
second set of protocol operations and associated PDU
is described in RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control
described in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI
Bierman & Jones Informational [Page 2]
RFC 2922 Physical Topology MIB September 2000
This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
translation is possible (use of Counter64). Some machine
information in SMIv2 will be converted into textual descriptions
SMIv1 during the translation process. However, this loss of
readable information is not considered to change the semantics of
MIB
2.
There is a need for a standardized means of representing the
network connections pertaining to a given management domain.
Physical Topology MIB (PTOPO-MIB) provides a standard way to
connections between network ports and to discover network
of SNMP agents containing management information associated with
port
A topology mechanism is used to discover the information required
the PTOPO-MIB. There is a need for a standardized topology
to increase the likelihood of multi-vendor interoperability of
physical topology management information. The PTOPO-MIB does not
however, specify or restrict the discovery mechanism(s) used for
implementation of the PTOPO-MIB. Topology mechanisms exist
certain media types (such as FDDI) and proprietary mechanisms
for other media such as shared media Ethernet, switched Ethernet,
Token Ring. Rather than specifying mechanisms for each type
technology, the PTOPO-MIB allows co-existence of multiple
mechanisms. The required objects of the PTOPO-MIB define the
requirements for any topology mechanism
The scope of the physical topology (PTOPO) mechanism is
identification of connections between two network ports.
addresses of SNMP agents containing management information
with each port can also be identified
2.1.
Some terms are used throughout this document
Physical
Physical topology represents the topology model for layer 1
the OSI stack - the physical layer. Physical topology
of identifying the devices on the network and how they
physically interconnected. By definition of this document
physical topology does not imply a physical
between ports on the same device. Other means exist
Bierman & Jones Informational [Page 3]
RFC 2922 Physical Topology MIB September 2000
determining these relationships (e.g., Entity MIB [RFC2737])
exist for determining these relationships. Note that
topology is independent of logical topology, which
ports based on higher layer attributes, such as network
address
A chassis is a physical component which contains other
components. It is identified by an entPhysicalEntry with
entPhysicalClass value of 'chassis(3)' and
entPhysicalContainedIn value of zero. A chassis
consists of a globally unique SnmpAdminString
Local
The particular chassis containing the SNMP agent
the PTOPO MIB
A port is a physical component which can be connected
another port through some medium. It is identified by
entPhysicalEntry with an entPhysicalClass value of 'port(10)'.
A port identifier consists of an SnmpAdminString which must
unique within the context of the chassis which contains
port
Connection
A connection endpoint consists of a physical port, which
contained within a single physical chassis
Connection Endpoint
A connection endpoint is identified by a globally
chassis identifier and a port identifier unique within
associated chassis
A connection consists of two physical ports, and the
physical medium, configured for the purpose of
network traffic between the ports. A connection is
by its endpoint identifiers
Non-local
A connection for which neither endpoint is located on the
chassis
Bierman & Jones Informational [Page 4]
RFC 2922 Physical Topology MIB September 2000
A cloud identifies a portion of the topology for
insufficient information is known to completely infer
interconnection of devices that make up that portion of
topology
2.2. Design
Several factors influenced the design of this physical
function
-
The physical topology discovery function should be as simple
possible, exposing only the information needed to
connection endpoints and the SNMP agent(s) associated with
connection endpoint
-
At least one standard discovery protocol capable of
the standard physical topology MIB must be defined. Multi
vendor interoperability will not be achievable unless a
and extensible discovery protocol is available. However,
PTOPO MIB should not specify or restrict the topology
mechanisms an agent can use
- No Functional
Existing standard MIBs should be utilized whenever possible
Physical topology information is tightly coupled
functionality found in the Interfaces MIB [RFC2233] and
MIB [RFC2737]. New physical topology MIB objects should
duplicate these MIBs
- Identifier
Connection endpoint identifiers must be persistent (i.e.
across device reboots). Dynamic primary key objects
ifIndex and entPhysicalIndex are not suitable for table
in a physical topology MIB that is replicated and
throughout a managed system
- Identifier
Persistent string-based component identifiers should
supported from many sources. Chassis identifiers may be
in the Entity MIB [RFC2737], and port identifiers may be
in the Interfaces MIB [RFC2233] or Entity MIB [RFC2737].
Bierman & Jones Informational [Page 5]
RFC 2922 Physical Topology MIB September 2000
- Partial Topology
Physical topology data for remote components may only
partially available to an agent. An enumerated
hierarchy of component identifier types allows for
physical connection identifier information to be
with secondary information such as unicast source MAC
or network address associated with a particular port. A
Agent maintains information derived from the 'best' source
information for each connection. If a 'better'
source is detected, the PTOPO entries are updated accordingly
It is an implementation specific matter whether a PTOPO
replaces 'old' entries or retains them, however an agent
remove information known to be incorrect
- Low Polling
Physical topology polling should be minimized
techniques such as TimeFiltered data tables (from RMON-2
[RFC2021]), and last-change notifications
3. Topology
This section describes the physical topology framework in detail
3.1. Devices and Topology
The network devices, along with their physical connectivity, make
the physical topology. Some of these devices (but maybe not all
provide management agents that report their local physical
information to a manager via the physical topology MIB
These devices include communication infrastructure devices, such
hubs, switches, and routers, as well as 'leaf' devices such
workstations, printers, and servers. Generally, user data
through infrastructure devices while leaf devices are sources
sinks of data. Both types of devices may implement the
topology MIB, although implementation within leaf devices is
less critical
Each managed device collects physical topology information from
network, based on the topology mechanism(s) it is configured to use
The data represents this agent's local view of the physical network
Part of the topology data collected must include the
of other local agents which may contain additional
information. The definition of 'local' varies based on the
mechanism or mechanisms being used
Bierman & Jones Informational [Page 6]
RFC 2922 Physical Topology MIB September 2000
3.2. Topology
A topology mechanism is a means, possibly requiring some sort
protocol, by which devices determine topology information.
topology mechanism must provide sufficient information to
the MIB described later in this document
Topology mechanisms can be active or passive. Active
require a device to send and receive topology protocol packets
These packets provide the device ID of the source of the packet
may also indicate out which port the packet was transmitted.
receiving these packets, devices typically are required to
on which port that packet was received
Passive mechanisms take advantage of data on the network to
the topology MIB. By maintaining a list of device identifiers
on each port of all devices in a network, it is possible to
the PTOPO-MIB
Many instances of a particular topology mechanism may be in use on
given network, and many different mechanisms may be employed.
some cases, multiple mechanisms may overlap across part of
physical topology with individual ports supporting more than
topology mechanism. In general, this simply allows the port
collect more robust topology information. Agents may need to
configured so that they know which mechanism(s) are in use on
given portion of the network
Most topology mechanisms need to be bounded to a subset of
network to contain their impact on the network and limit the size
topology tables maintained by the agent. Topology mechanisms
often naturally bounded by the media on which they run (e.g.
topology mechanism) or by routers in the network that
block the mechanism from crossing into other parts of the network
3.3. Future
While the framework presented here is focused on physical topology
it may well be that the topology mechanisms and MIB described
be extended to include logical topology information as well. That
not a focus of this memo
4. Physical Topology
This section describes and defines the Physical Topology MIB
Bierman & Jones Informational [Page 7]
RFC 2922 Physical Topology MIB September 2000
4.1. Persistent
The PTOPO MIB utilizes non-volatile identifiers to
individual chassis and port components. These identifiers
associated with external objects in order to relate
information to the existing managed objects
In particular, an object from the Entity MIB [RFC2737] or
MIB [RFC2233] can be used as the 'reference-point' for a
component identifier
The Physical Topology MIB uses two identifier types pertaining to
PTOPO MIB
- globally unique chassis identifiers
- port identifiers; unique only within the chassis which
the port
Identifiers are stored as OCTET STRINGs, which are limited to 32
bytes in length, This supports flexible naming conventions
constrains the non-volatile storage requirements for an agent
4.2. Relationship to Entity
The first version of the Entity MIB [RFC2037] allows the
component inventory and hierarchy to be identified. However,
MIB does not provide persistent component identifiers, which
required for the PTOPO MIB. Therefore, version 2 of the Entity
[RFC2737] is required to support that feature. Specifically,
entPhysicalAlias object is utilized as a persistent
identifier
For agents implementing the PTOPO MIB, this new object must be
to represent the chassis identifier. Port identifiers can be
on the entPhysicalAlias object associated with the port, but only
the port is not represented as an interface in the ifXTable
Implementation of the entPhysicalGroup [RFC2737] and
entPhysicalAlias object [RFC2737] are mandatory for SNMP agents
implement the PTOPO MIB. No other objects must be implemented
these MIBs to support the physical topology function
Bierman & Jones Informational [Page 8]
RFC 2922 Physical Topology MIB September 2000
4.3. Relationship to Interfaces
The PTOPO MIB requires a persistent identifier for each port.
Interfaces MIB [RFC2233] provides a standard mechanism for
network interfaces. Unfortunately, not all ports which may
represented in the PTOPO MIB are also represented in the
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
ifAlias value for the port identifier. For each port not
in the Interfaces MIB, the associated entPhysicalAlias value must
used for the port identifier. Note that the PTOPO MIB requires
minimal support from the Interfaces MIB. Specifically, the '
ifGeneralInformationGroup' level of conformance must be provided
each port also identified in the PTOPO MIB. The agent may choose
support these objects with read-only access, as specified in
conformance section of the Interfaces MIB
4.4. Relationship to RMON-2
The RMON-2 MIB [RFC2021] contains address mapping information
can be integrated with physical topology information. The
ports identified in a physical topology MIB can be related to the
and network layer addresses found in the addressMapTable
4.5. Relationship to Bridge
The Bridge MIB [RFC1493] contains information which may relate
physical ports represented in the ptopoConnTable. Entries in
dot1dBasePortTable and dot1dStpPortTable can by related to
ports represented in the PTOPO MIB. Also, bridge port MAC
may be used as chassis and port identifiers in some situations
4.6. Relationship to Repeater
The Repeater MIB [RFC2108] contains information which may relate
physical ports represented in the PTOPO MIB. Entries in
rptrPortTable and rptrMonitorPortTable can by related to
ports represented in the ptopoConnTable. Entries in
rptrInfoTable and rptrMonTable can be related to repeater
possibly represented in the ptopoConnTable
Bierman & Jones Informational [Page 9]
RFC 2922 Physical Topology MIB September 2000
4.7. MIB
The PTOPO MIB contains three MIB object groups
-
Exposes physical topology data learned from discovery
and/or manual configuration
-
Contains general information regarding PTOPO MIB status
-
Contains configuration variables for the PTOPO MIB
function
4.7.1. ptopoData
This group contains a single table to identity physical
data
The ptopoConnTable contains information about the connections
or configured on behalf of the PTOPO MIB SNMP Agent
4.7.2. ptopoGeneral
This group contains some scalar objects to report the status of
PTOPO MIB information currently known to the SNMP Agent. The
last change time, and table add and delete counters allow an NMS
set threshold alarms to trigger PTOPO polling
4.7.3. ptopoConfig
This group contains tables to configure the behavior of the
topology function. The transmission of ptopoLastChange
can be configured using the ptopoConfigTrapInterval scalar
object
4.8. Physical Topology MIB
PTOPO-MIB DEFINITIONS ::=
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE
Integer32, Counter32, mib-2
FROM SNMPv2-
TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp,
FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-
Bierman & Jones Informational [Page 10]
RFC 2922 Physical Topology MIB September 2000
FROM SNMPv2-
FROM RMON2-
FROM ENTITY-
FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB
ptopoMIB MODULE-
LAST-UPDATED "200009210000Z
ORGANIZATION "IETF; PTOPOMIB Working Group
CONTACT-
"PTOPOMIB WG Discussion
ptopo@3com.
Subscription
majordomo@3com.
msg body: [un]subscribe
Andy
Cisco Systems Inc
170 West Tasman
San Jose, CA 95134
408-527-3711
abierman@cisco.
Kendall S.
Nortel
4401 Great America
Santa Clara, CA 95054
408-495-7356
kejones@nortelnetworks.com
"The MIB module for physical topology information."
REVISION "200009210000Z
"Initial Version of the Physical Topology MIB. This
published as RFC 2922."
::= { mib-2 79 }
ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 }
-- MIB
ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 }
ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 }
ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 }
-- textual
Bierman & Jones Informational [Page 11]
RFC 2922 Physical Topology MIB September 2000
PtopoGenAddr ::= TEXTUAL-
STATUS
"The value of an address."
SYNTAX OCTET STRING (SIZE (0..20))
PtopoChassisIdType ::= TEXTUAL-
STATUS
"This TC describes the source of a chassis identifier
The enumeration 'chasIdEntPhysicalAlias(1)' represents
chassis identifier based on the value of
for a chassis component (i.e., an entPhysicalClass value
'chassis(3)').
The enumeration 'chasIdIfAlias(2)' represents a
identifier based on the value of ifAlias for an
on the containing chassis
The enumeration 'chasIdPortEntPhysicalAlias(3)'
a chassis identifier based on the value of
for a port or backplane component (i.e.,
value of 'port(10)' or 'backplane(4)'), within
containing chassis
The enumeration 'chasIdMacAddress(4)' represents a
identifier based on the value of a unicast source
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
chassis identifier based on a network address,
with a particular chassis. The encoded address is
composed of two fields. The first field is a single octet
representing the IANA AddressFamilyNumbers value for
specific address type, and the second field is
PtopoGenAddr address value."
SYNTAX INTEGER {
chasIdEntPhysicalAlias(1),
chasIdIfAlias(2),
chasIdPortEntPhysicalAlias(3),
chasIdMacAddress(4),
chasIdPtopoGenAddr(5)
}
PtopoChassisId ::= TEXTUAL-
STATUS
Bierman & Jones Informational [Page 12]
RFC 2922 Physical Topology MIB September 2000
"This TC describes the format of a chassis
string. Objects of this type are always used with
associated PtopoChassisIdType object, which identifies
format of the particular PtopoChassisId object instance
If the associated PtopoChassisIdType object has a value
'chasIdEntPhysicalAlias(1)', then the octet
identifies a particular instance of the
object for a chassis component (i.e., an
value of 'chassis(3)').
If the associated PtopoChassisIdType object has a value
'chasIdIfAlias(2)', then the octet string identifies
particular instance of the ifAlias object for an
on the containing chassis
If the associated PtopoChassisIdType object has a value
'chasIdPortEntPhysicalAlias(3)', then the octet
identifies a particular instance of the
object for a port or backplane component within
containing chassis
If the associated PtopoChassisIdType object has a value
'chasIdMacAddress(4)', then this string identifies
particular unicast source MAC address (encoded in
byte order and IEEE 802.3 canonical bit order), of a port
the containing chassis
If the associated PtopoChassisIdType object has a value
'chasIdPtopoGenAddr(5)', then this string identifies
particular network address, encoded in network byte order
associated with one or more ports on the containing chassis
The first octet contains the IANA Address Family
enumeration value for the specific address type, and
2 through N contain the PtopoGenAddr address value
network byte order."
SYNTAX OCTET STRING (SIZE (1..32))
PtopoPortIdType ::= TEXTUAL-
STATUS
"This TC describes the source of a particular type of
identifier used in the PTOPO MIB
The enumeration 'portIdIfAlias(1)' represents a
identifier based on the ifAlias MIB object
Bierman & Jones Informational [Page 13]
RFC 2922 Physical Topology MIB September 2000
The enumeration 'portIdPortEntPhysicalAlias(2)' represents
port identifier based on the value of entPhysicalAlias for
port or backplane component (i.e., entPhysicalClass value
'port(10)' or 'backplane(4)'), within the
chassis
The enumeration 'portIdMacAddr(3)' represents a
identifier based on a unicast source MAC address, which
been detected by the agent and associated with a
port
The enumeration 'portIdPtopoGenAddr(4)' represents a
identifier based on a network address, detected by the
and associated with a particular port."
SYNTAX INTEGER {
portIdIfAlias(1),
portIdEntPhysicalAlias(2),
portIdMacAddr(3),
portIdPtopoGenAddr(4)
}
PtopoPortId ::= TEXTUAL-
STATUS
"This TC describes the format of a port identifier string
Objects of this type are always used with an
PtopoPortIdType object, which identifies the format of
particular PtopoPortId object instance
If the associated PtopoPortIdType object has a value
'portIdIfAlias(1)', then the octet string identifies
particular instance of the ifAlias object
If the associated PtopoPortIdType object has a value
'portIdEntPhysicalAlias(2)', then the octet
identifies a particular instance of the
object for a port component (i.e., entPhysicalClass value
'port(10)').
If the associated PtopoPortIdType object has a value
'portIdMacAddr(3)', then this string identifies a
unicast source MAC address associated with the port
If the associated PtopoPortIdType object has a value
'portIdPtopoGenAddr(4)', then this string identifies
network address associated with the port. The first
contains the IANA AddressFamilyNumbers enumeration value
the specific address type, and octets 2 through N
Bierman & Jones Informational [Page 14]
RFC 2922 Physical Topology MIB September 2000
the PtopoGenAddr address value in network byte order."
SYNTAX OCTET STRING (SIZE (1..32))
PtopoAddrSeenState ::= TEXTUAL-
STATUS
"This TC describes the state of address detection for
particular type of port identifier used in the PTOPO MIB
The enumeration 'notUsed(1)' represents an entry for
the particular MIB object is not applicable to the
connection endpoint
The enumeration 'unknown(2)' represents an entry for
the particular address collection state is not known
The enumeration 'oneAddr(3)' represents an entry for
exactly one source address (of the type indicated by
particular MIB object), has been detected
The enumeration 'multiAddr(4)' represents an entry
which more than one source address (of the type indicated
the particular MIB object), has been detected
An agent is expected to set the initial state of
PtopoAddrSeenState to 'notUsed(1)' or 'unknown(2)'.
Note that the PTOPO MIB does not restrict or specify
means in which the PtopoAddrSeenState is known to an agent
In particular, an agent may detect this information
configuration data, or some means other than
monitoring all port traffic."
SYNTAX INTEGER {
notUsed(1),
unknown(2),
oneAddr(3),
multiAddr(4)
}
-- ***********************************************************
--
-- P T O P O D A T A G R O U
--
-- ***********************************************************
-- Connection
Bierman & Jones Informational [Page 15]
RFC 2922 Physical Topology MIB September 2000
ptopoConnTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"This table contains one or more rows per physical
connection known to this agent. The agent may wish
ensure that only one ptopoConnEntry is present for
local port, or it may choose to maintain
ptopoConnEntries for the same local port
Entries based on lower numbered identifier types
preferred over higher numbered identifier types, i.e.,
values of the ptopoConnRemoteChassisType
ptopoConnRemotePortType objects."
::= { ptopoData 1 }
ptopoConnEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"Information about a particular physical network connection
Entries may be created and deleted in this table,
manually or by the agent, if a physical topology
process is active."
INDEX {
ptopoConnTimeMark
ptopoConnLocalChassis
ptopoConnLocalPort
}
::= { ptopoConnTable 1 }
PtopoConnEntry ::= SEQUENCE {
ptopoConnTimeMark TimeFilter
ptopoConnLocalChassis PhysicalIndex
ptopoConnLocalPort PhysicalIndex
ptopoConnIndex Integer32,
ptopoConnRemoteChassisType PtopoChassisIdType
ptopoConnRemoteChassis PtopoChassisId
ptopoConnRemotePortType PtopoPortIdType
ptopoConnRemotePort PtopoPortId
ptopoConnDiscAlgorithm AutonomousType
ptopoConnAgentNetAddrType AddressFamilyNumbers
ptopoConnAgentNetAddr PtopoGenAddr
ptopoConnMultiMacSASeen PtopoAddrSeenState
ptopoConnMultiNetSASeen PtopoAddrSeenState
Bierman & Jones Informational [Page 16]
RFC 2922 Physical Topology MIB September 2000
ptopoConnIsStatic TruthValue
ptopoConnLastVerifyTime TimeStamp
ptopoConnRowStatus
ptopoConnTimeMark OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A TimeFilter for this entry. See the TimeFilter
convention in RFC 2021 to see how this works."
::= { ptopoConnEntry 1 }
ptopoConnLocalChassis OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The entPhysicalIndex value used to identify the
component associated with the local connection endpoint."
::= { ptopoConnEntry 2 }
ptopoConnLocalPort OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The entPhysicalIndex value used to identify the
component associated with the local connection endpoint."
::= { ptopoConnEntry 3 }
ptopoConnIndex OBJECT-
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-
STATUS
"This object represents an arbitrary local integer
used by this agent to identify a particular
instance, unique only for the indicated local
endpoint
A particular ptopoConnIndex value may be reused in the
an entry is aged out and later re-learned with the same (
different) remote chassis and port identifiers
An agent is encouraged to assign monotonically
index values to new entries, starting with one, after
Bierman & Jones Informational [Page 17]
RFC 2922 Physical Topology MIB September 2000
reboot. It is considered unlikely that the
will wrap between reboots."
::= { ptopoConnEntry 4 }
ptopoConnRemoteChassisType OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The type of encoding used to identify the
associated with the remote connection endpoint
This object may not be modified if the
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 5 }
ptopoConnRemoteChassis OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The string value used to identify the chassis
associated with the remote connection endpoint
This object may not be modified if the
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 6 }
ptopoConnRemotePortType OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The type of port identifier encoding used in the
'ptopoConnRemotePort' object
This object may not be modified if the
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 7 }
ptopoConnRemotePort OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The string value used to identify the port
associated with the remote connection endpoint
Bierman & Jones Informational [Page 18]
RFC 2922 Physical Topology MIB September 2000
This object may not be modified if the
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 8 }
ptopoConnDiscAlgorithm OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"An indication of the algorithm used to discover
information contained in this conceptual row
A value of ptopoDiscoveryLocal indicates this entry
configured by the local agent, without use of a
protocol
A value of { 0 0 } indicates this entry was created
by an NMS via the associated RowStatus object. "
::= { ptopoConnEntry 9 }
ptopoConnAgentNetAddrType OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"This network address type of the
ptopoConnNetAddr object, unless that object contains a
length string. In such a case, an NMS application
ignore any returned value for this object
This object may not be modified if the
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 10 }
ptopoConnAgentNetAddr OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"This object identifies a network address which may be
to reach an SNMP agent entity containing information for
chassis and port components represented by the
'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects
If no such address is known, then this object shall
an empty string
This object may not be modified if the
ptopoConnRowStatus object has a value of active(1)."
Bierman & Jones Informational [Page 19]
RFC 2922 Physical Topology MIB September 2000
::= { ptopoConnEntry 11 }
ptopoConnMultiMacSASeen OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"This object indicates if multiple unicast source
addresses have been detected by the agent from the
connection endpoint, since the creation of this entry
If this entry has an associated
and/or ptopoConnRemotePortType value other
'portIdMacAddr(3)', then the value 'notUsed(1)' is returned
Otherwise, one of the following conditions must be true
If the agent has not yet detected any unicast source
addresses from the remote port, then the value 'unknown(2)'
is returned
If the agent has detected exactly one unicast source
address from the remote port, then the value 'oneAddr(3)'
returned
If the agent has detected more than one unicast source
address from the remote port, then the value 'multiAddr(4)'
is returned."
::= { ptopoConnEntry 12 }
ptopoConnMultiNetSASeen OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"This object indicates if multiple network layer
addresses have been detected by the agent from the
connection endpoint, since the creation of this entry
If this entry has an associated
or ptopoConnRemotePortType value other
'portIdGenAddr(4)' then the value 'notUsed(1)' is returned
Otherwise, one of the following conditions must be true
If the agent has not yet detected any network
addresses of the appropriate type from the remote port,
the value 'unknown(2)' is returned
Bierman & Jones Informational [Page 20]
RFC 2922 Physical Topology MIB September 2000
If the agent has detected exactly one network source
of the appropriate type from the remote port, then the
'oneAddr(3)' is returned
If the agent has detected more than one network
address (of the same appropriate type) from the remote port
this the value 'multiAddr(4)' is returned."
::= { ptopoConnEntry 13 }
ptopoConnIsStatic OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"This object identifies static ptopoConnEntries. If
object has the value 'true(1)', then this entry is
subject to any age-out mechanisms implemented by the agent
If this object has the value 'false(2)', then this entry
subject to all age-out mechanisms implemented by the agent
This object may not be modified if the
ptopoConnRowStatus object has a value of active(1)."
DEFVAL { false }
::= { ptopoConnEntry 14 }
ptopoConnLastVerifyTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"If the associated value of ptopoConnIsStatic is equal
'false(2)', then this object contains the value of
at the time the conceptual row was last verified by
agent, e.g., via reception of a topology protocol message
pertaining to the associated remote chassis and port
If the associated value of ptopoConnIsStatic is equal
'true(1)', then this object shall contain the value
sysUpTime at the time this entry was last activated (i.e.,
ptopoConnRowStatus set to 'active(1)')."
::= { ptopoConnEntry 15 }
ptopoConnRowStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
Bierman & Jones Informational [Page 21]
RFC 2922 Physical Topology MIB September 2000
"The status of this conceptual row."
::= { ptopoConnEntry 16 }
-- ***********************************************************
--
-- P T O P O G E N E R A L G R O U
--
-- ***********************************************************
-- last change time stamp for the whole
ptopoLastChangeTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The value of sysUpTime at the time a conceptual row
created, modified, or deleted in the ptopoConnTable
An NMS can use this object to reduce polling of
ptopoData group objects."
::= { ptopoGeneral 1 }
ptopoConnTabInserts OBJECT-
SYNTAX Counter32
UNITS "table entries
MAX-ACCESS read-
STATUS
"The number of times an entry has been inserted into
ptopoConnTable."
::= { ptopoGeneral 2 }
ptopoConnTabDeletes OBJECT-
SYNTAX Counter32
UNITS "table entries
MAX-ACCESS read-
STATUS
"The number of times an entry has been deleted from
ptopoConnTable."
::= { ptopoGeneral 3 }
ptopoConnTabDrops OBJECT-
SYNTAX Counter32
UNITS "table entries
MAX-ACCESS read-
Bierman & Jones Informational [Page 22]
RFC 2922 Physical Topology MIB September 2000
STATUS
"The number of times an entry would have been added to
ptopoConnTable, (e.g., via information learned from
topology protocol), but was not because of
resources."
::= { ptopoGeneral 4 }
ptopoConnTabAgeouts OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of times an entry has been deleted from
ptopoConnTable because the information timeliness
for that entry has expired."
::= { ptopoGeneral 5 }
-- ***********************************************************
--
-- P T O P O C O N F I G G R O U
--
-- ***********************************************************
ptopoConfigTrapInterval OBJECT-
SYNTAX Integer32 (0 | 5..3600)
UNITS "seconds
MAX-ACCESS read-
STATUS
"This object controls the transmission of
notifications
If this object has a value of zero, then
ptopoConfigChange notifications will be transmitted by
agent
If this object has a non-zero value, then the agent must
generate more than one ptopoConfigChange trap-event in
indicated period, where a 'trap-event' is the
of a single notification PDU type to a list of
destinations. If additional configuration changes
within the indicated throttling period, then these trap
events must be suppressed by the agent. An NMS
periodically check the value of ptopoLastChangeTime
detect any missed ptopoConfigChange trap-events, e.g. due
throttling or transmission loss
Bierman & Jones Informational [Page 23]
RFC 2922 Physical Topology MIB September 2000
If notification transmission is enabled, the
default throttling period is 60 seconds, but
should be disabled by default
If the agent is capable of storing non-
configuration, then the value of this object must
restored after a re-initialization of the
system."
DEFVAL { 0 }
::= { ptopoConfig 1 }
ptopoConfigMaxHoldTime OBJECT-
SYNTAX Integer32 (1..2147483647)
UNITS "seconds
MAX-ACCESS read-
STATUS
"This object specifies the desired time interval for
an agent will maintain dynamic ptopoConnEntries
After the specified number of seconds since the last time
entry was verified, in the absence of new
(e.g., receipt of a topology protocol message), the
shall remove the entry. Note that entries may not always
removed immediately, but may possibly be removed at
garbage collection intervals
This object only affects dynamic ptopoConnEntries, i.e.
which ptopoConnIsStatic equals 'false(2)'. Static
are not aged out
Note that dynamic ptopoConnEntries may also be removed
the agent due to the expired timeliness of learned
information (e.g., timeliness interval for a remote
expires). The actual age-out interval for a given entry
defined by the following formula
age-out-time =
min(ptopoConfigMaxHoldTime, specific hold-time>)
where specific hold-time> is determined by
discovery algorithm, and may be different for each entry."
DEFVAL { 300 }
::= { ptopoConfig 2 }
-- PTOPO MIB Notification
ptopoMIBNotifications OBJECT IDENTIFIER ::= { ptopoMIB 2 }
ptopoMIBTrapPrefix OBJECT IDENTIFIER ::=
Bierman & Jones Informational [Page 24]
RFC 2922 Physical Topology MIB September 2000
{ ptopoMIBNotifications 0 }
ptopoConfigChange NOTIFICATION-
OBJECTS {
ptopoConnTabInserts
ptopoConnTabDeletes
ptopoConnTabDrops
}
STATUS
"A ptopoConfigChange notification is sent when the value
ptopoLastChangeTime changes. It can be utilized by an NMS
trigger physical topology table maintenance polls
Note that transmission of ptopoConfigChange
are throttled by the agent, as specified by
'ptopoConfigTrapInterval' object."
::= { ptopoMIBTrapPrefix 1 }
-- PTOPO Registration
ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 }
-- values used with ptopoConnDiscAlgorithm
ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::=
{ ptopoRegistrationPoints 1 }
ptopoDiscoveryLocal OBJECT IDENTIFIER ::=
{ ptopoDiscoveryMechanisms 1 }
-- conformance
ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 }
ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 }
ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 }
-- compliance
ptopoCompliance MODULE-
STATUS
"The compliance statement for SNMP entities which
the PTOPO MIB."
MODULE -- this
MANDATORY-GROUPS {
ptopoDataGroup
Bierman & Jones Informational [Page 25]
RFC 2922 Physical Topology MIB September 2000
ptopoGeneralGroup
ptopoConfigGroup
}
::= { ptopoCompliances 1 }
-- MIB
ptopoDataGroup OBJECT-
OBJECTS {
ptopoConnRemoteChassisType
ptopoConnRemoteChassis
ptopoConnRemotePortType
ptopoConnRemotePort
ptopoConnDiscAlgorithm
ptopoConnAgentNetAddrType
ptopoConnAgentNetAddr
ptopoConnMultiMacSASeen
ptopoConnMultiNetSASeen
ptopoConnIsStatic
ptopoConnLastVerifyTime
}
STATUS
"The collection of objects which are used to
physical topology information for which a single
provides management information
This group is mandatory for all implementations of the
MIB."
::= { ptopoGroups 1 }
ptopoGeneralGroup OBJECT-
OBJECTS {
ptopoLastChangeTime
ptopoConnTabInserts
ptopoConnTabDeletes
ptopoConnTabDrops
}
STATUS
"The collection of objects which are used to report
general status of the PTOPO MIB implementation
This group is mandatory for all agents which implement
PTOPO MIB."
::= { ptopoGroups 2 }
Bierman & Jones Informational [Page 26]
RFC 2922 Physical Topology MIB September 2000
ptopoConfigGroup OBJECT-
OBJECTS {
ptopoConfigTrapInterval
}
STATUS
"The collection of objects which are used to configure
PTOPO MIB implementation behavior
This group is mandatory for agents which implement the
MIB."
::= { ptopoGroups 3 }
ptopoNotificationsGroup NOTIFICATION-
NOTIFICATIONS {
}
STATUS
"The collection of notifications used to indicate PTOPO
data consistency and general status information
This group is mandatory for agents which implement the
MIB."
::= { ptopoGroups 4 }
5. Intellectual
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
Bierman & Jones Informational [Page 27]
RFC 2922 Physical Topology MIB September 2000
this standard. Please address the information to the IETF
Director
The IETF has been notified of intellectual property rights claimed
regard to some or all of the specification contained in
document. For more information consult the online list of
rights
6.
The PTOPO Discovery Protocol is a product of the IETF
Working Group
7.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and
of Management Information for TCP/IP-based Internets",
STD 16, RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1215] Rose, M., "A Convention for Defining Traps for use
the SNMP", RFC 1215, March 1991.
[RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K
McCloghrie, "Definitions of Managed Objects for Bridges",
RFC 1493, July 1993.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Introduction to Community-based SNMPv2", January 1996.
[RFC1902] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Structure of Management Information for version 2 of
Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Textual Conventions for version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1903, January 1996.
Bierman & Jones Informational [Page 28]
RFC 2922 Physical Topology MIB September 2000
[RFC1904] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Conformance Statements for version 2 of the
Network Management Protocol (SNMPv2)", RFC 1904,
1996.
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Protocol Operations for Version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Transport Mappings for Version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)",
RFC 2021, January 1997.
[RFC2037] McCloghrie, K. and A. Bierman, "Entity MIB using SMIv2",
RFC 2037, October 1996.
[RFC2108] de Graaf, K., Romascanu, D., McMaster, D. and K
McCloghrie, "Definitions of Managed Objects for
802.3 Repeater Devices using SMIv2", RFC 2108,
1997.
[RFC2233] McCloghrie, K. and F. Kastenholtz, "The Interfaces
MIB using SMIv2", RFC 2233, November 1997.
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart
"Introduction to Version 3 of the Internet-
Network Management Framework", RFC 2570, April 1999.
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999.
[RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen
"Message Processing and Dispatching for the
Network Management Protocol (SNMP)", RFC 2572,
1999.
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv
Applications", RFC 2573, April 1999.
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security
(USM) for version 3 of the Simple Network
Protocol (SNMPv3)", RFC 2574, April 1999.
Bierman & Jones Informational [Page 29]
RFC 2922 Physical Topology MIB September 2000
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-
Access Control Model (VACM) for the Simple
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of
Information Version 2 (SMIv2)", STD 58, RFC 2578,
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)",
RFC 2737, Cisco Systems, December 1999.
8. Security
There are a number of management objects defined in this MIB
have a MAX-ACCESS clause of read-write and/or read-create.
objects may be considered sensitive or vulnerable in some
environments. The support for SET operations in a non-
environment without proper protection can have a negative effect
network operations
There are a number of managed objects in this MIB that may
sensitive information. These are
read-create objects:
ptopoConnRemoteChassis
ptopoConnRemotePort
ptopoConnAgentNetAddr
ptopoConfigTrapInterval
read-only objects:
ptopoConnMultiMacSASeen
ptopoConnLastVerifyTime
notifications:
These MIB objects expose information about the physical
for a particular portion of a network
Bierman & Jones Informational [Page 30]
RFC 2922 Physical Topology MIB September 2000
A network administrator may also wish to inhibit transmission of
ptopoConfigChange notification by setting the
object to zero
It is thus important to control even GET access to these objects
possibly to even encrypt the values of these object when sending
over the network via SNMP. Not all versions of SNMP provide
for such a secure environment
SNMPv1 by itself is not a secure environment. Even if the
itself is secure (for example by using IPSec), even then, there is
control as to who on the secure network is allowed to access
GET/SET (read/change/create/delete) the objects in this MIB
It is recommended that the implementers consider the
features as provided by the SNMPv3 framework. Specifically, the
of the User-based Security Model RFC 2574 [RFC2574] and the View
based Access Control Model RFC 2575 [RFC2575] is recommended
It is then a customer/user responsibility to ensure that the
entity giving access to an instance of this MIB, is
configured to give access to the objects only to those
(users) that have legitimate rights to indeed GET or
(change/create/delete) them
9. Authors'
Andy
Cisco
170 West Tasman
San Jose, CA USA 95134
Phone: +1 408-527-3711
EMail: abierman@cisco.
Kendall S.
Nortel
4401 Great America
Santa Clara, CA USA 95054
Phone: +1 408-495-7356
EMail: kejones@nortelnetworks.
Bierman & Jones Informational [Page 31]
RFC 2922 Physical Topology MIB September 2000
10. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Bierman & Jones Informational [Page 32]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
