From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2922.txt | 1795 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1795 insertions(+) create mode 100644 doc/rfc/rfc2922.txt (limited to 'doc/rfc/rfc2922.txt') diff --git a/doc/rfc/rfc2922.txt b/doc/rfc/rfc2922.txt new file mode 100644 index 0000000..f952181 --- /dev/null +++ b/doc/rfc/rfc2922.txt @@ -0,0 +1,1795 @@ + + + + + + +Network Working Group A. Bierman +Request for Comments: 2922 Cisco Systems, Inc. +Category: Informational K. Jones + Nortel Networks + September 2000 + + + Physical Topology MIB + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + 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 managing + physical topology identification and discovery. + +Table of Contents + + 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 Framework + + The SNMP Management Framework presently consists of five major + components: + + o An overall architecture, described in RFC 2571 [RFC2571]. + + o Mechanisms for describing and naming objects and events for + the purpose of management. The first version of this + Structure of Management Information (SMI) is called SMIv1 + and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC + 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 called + SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A + second version of the SNMP message protocol, which is not an + Internet standards track protocol, is called SNMPv2c and + described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The + third version of the message protocol is called SNMPv3 and + described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC + 2574 [RFC2574]. + + o Protocol operations for accessing management information. + The first set of protocol operations and associated PDU + formats is described in STD 15, RFC 1157 [RFC1157]. A + second set of protocol operations and associated PDU formats + is described in RFC 1905 [RFC1905]. + + o A set of fundamental applications described in RFC 2573 + [RFC2573] and the view-based access control mechanism + described in RFC 2575 [RFC2575]. + + A more detailed introduction to the current SNMP Management Framework + can be found in RFC 2570 [RFC2570]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. Objects in the MIB are + 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. A + MIB conforming to the SMIv1 can be produced through the appropriate + translations. The resulting translated MIB must be semantically + equivalent, except where objects or events are omitted because no + translation is possible (use of Counter64). Some machine readable + information in SMIv2 will be converted into textual descriptions in + SMIv1 during the translation process. However, this loss of machine + readable information is not considered to change the semantics of the + MIB. + +2. Overview + + There is a need for a standardized means of representing the physical + network connections pertaining to a given management domain. The + Physical Topology MIB (PTOPO-MIB) provides a standard way to identify + connections between network ports and to discover network addresses + of SNMP agents containing management information associated with each + port. + + A topology mechanism is used to discover the information required by + the PTOPO-MIB. There is a need for a standardized topology mechanism + to increase the likelihood of multi-vendor interoperability of such + physical topology management information. The PTOPO-MIB does not, + however, specify or restrict the discovery mechanism(s) used for an + implementation of the PTOPO-MIB. 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. Rather than specifying mechanisms for each type of + technology, the PTOPO-MIB allows co-existence of multiple topology + mechanisms. The required objects of the PTOPO-MIB define the core + requirements for any topology mechanism. + + 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. + +2.1. 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 + + + +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 physical + topology is independent of logical topology, which associates + ports based on higher layer attributes, such as network layer + address. + + 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 SnmpAdminString. + + 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 an SnmpAdminString which must be + unique within the context of the chassis which contains the + port. + + 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. + + + + + + + + +Bierman & Jones Informational [Page 4] + +RFC 2922 Physical Topology MIB September 2000 + + + 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. + + +2.2. 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. However, the + PTOPO MIB should not specify or restrict the topology discovery + mechanisms an agent can use. + + - No Functional Overlap + Existing standard MIBs should be utilized whenever possible. + Physical topology information is tightly coupled to + functionality found in the Interfaces MIB [RFC2233] and Entity + MIB [RFC2737]. 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 [RFC2737], and port identifiers may be found + in the Interfaces MIB [RFC2233] or Entity MIB [RFC2737]. + + + + + + +Bierman & Jones Informational [Page 5] + +RFC 2922 Physical Topology MIB September 2000 + + + - 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. + It is an implementation specific matter whether a PTOPO agent + replaces 'old' entries or retains them, however an agent must + remove information known to be incorrect. + + - Low Polling Impact + Physical topology polling should be minimized through + techniques such as TimeFiltered data tables (from RMON-2 + [RFC2021]), and last-change notifications. + +3. Topology Framework + + This section describes the physical topology framework in detail. + +3.1. Devices and Topology Agents + + 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. + + 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 + sinks of data. Both types of devices may implement the physical + topology MIB, although implementation within leaf devices is much + less critical. + + Each managed device collects physical topology information from the + 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 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. + + + + + + +Bierman & Jones Informational [Page 6] + +RFC 2922 Physical Topology MIB September 2000 + + +3.2. Topology Mechanisms + + A topology mechanism is a means, possibly requiring some sort of + protocol, by which devices determine topology information. The + topology mechanism must provide sufficient information to populate + the MIB described later in this document. + + 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 populate + the PTOPO-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 with individual ports supporting more than one + topology mechanism. In general, this simply allows the port to + collect more robust topology information. 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 limit the size of + topology tables maintained by the agent. Topology mechanisms are + often naturally bounded by the media on which they run (e.g. FDDI + topology mechanism) or by routers in the network that intentionally + block the mechanism from crossing into other parts of the network. + +3.3. Future Considerations + + 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. + +4. Physical Topology MIB + + This section describes and defines the Physical Topology MIB. + + + + + + +Bierman & Jones Informational [Page 7] + +RFC 2922 Physical Topology MIB September 2000 + + +4.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 [RFC2737] or Interfaces + MIB [RFC2233] can be used as the 'reference-point' for a connection + component identifier. + + 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. + +4.2. Relationship to Entity MIB + + The first version of the Entity MIB [RFC2037] allows the physical + component inventory and hierarchy to be identified. However, this + MIB does not provide persistent component identifiers, which are + required for the PTOPO MIB. Therefore, version 2 of the Entity MIB + [RFC2737] is required to support that feature. Specifically, the + entPhysicalAlias object is utilized as a persistent chassis + identifier. + + 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 [RFC2737] and the + entPhysicalAlias object [RFC2737] are mandatory for SNMP agents which + implement the PTOPO MIB. No other objects must be implemented from + 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 MIB + + The PTOPO MIB requires a persistent identifier for each port. The + Interfaces MIB [RFC2233] 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 also + 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. Note that the PTOPO MIB requires only + minimal support from the Interfaces MIB. Specifically, the ' + ifGeneralInformationGroup' level of conformance must be provided for + each port also identified in the PTOPO MIB. The agent may choose to + support these objects with read-only access, as specified in the + conformance section of the Interfaces MIB. + +4.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. + +4.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. + +4.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. + + + + + + + + + +Bierman & Jones Informational [Page 9] + +RFC 2922 Physical Topology MIB September 2000 + + +4.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. + +4.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. + +4.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. + +4.7.3. ptopoConfig Group + + This group contains tables to configure the behavior of the physical + topology function. The transmission of ptopoLastChange notifications + can be configured using the ptopoConfigTrapInterval scalar MIB + object. + +4.8. Physical Topology MIB Definitions + +PTOPO-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + Integer32, Counter32, mib-2 + FROM SNMPv2-SMI + TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue + FROM SNMPv2-TC + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + + + +Bierman & Jones Informational [Page 10] + +RFC 2922 Physical Topology MIB September 2000 + + + FROM SNMPv2-CONF + TimeFilter + FROM RMON2-MIB + PhysicalIndex + FROM ENTITY-MIB + AddressFamilyNumbers + FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB; + +ptopoMIB MODULE-IDENTITY + LAST-UPDATED "200009210000Z" + 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 + + Kendall S. Jones + Nortel Networks + 4401 Great America Parkway + Santa Clara, CA 95054 + 408-495-7356 + kejones@nortelnetworks.com" + DESCRIPTION + "The MIB module for physical topology information." + REVISION "200009210000Z" + DESCRIPTION + "Initial Version of the Physical Topology MIB. This version + published as RFC 2922." + ::= { mib-2 79 } + +ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 } + + +-- MIB groups +ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 } +ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 } +ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 } + +-- textual conventions + + + +Bierman & Jones Informational [Page 11] + +RFC 2922 Physical Topology MIB September 2000 + + +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 IANA AddressFamilyNumbers value for the + specific address type, and the second field is the + PtopoGenAddr address value." + SYNTAX INTEGER { + chasIdEntPhysicalAlias(1), + chasIdIfAlias(2), + chasIdPortEntPhysicalAlias(3), + chasIdMacAddress(4), + chasIdPtopoGenAddr(5) + } + +PtopoChassisId ::= TEXTUAL-CONVENTION + STATUS current + + + +Bierman & Jones Informational [Page 12] + +RFC 2922 Physical Topology MIB September 2000 + + + 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 IANA Address Family Numbers + 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)) + +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. + + + + +Bierman & Jones Informational [Page 13] + +RFC 2922 Physical Topology MIB September 2000 + + + 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 + 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 IANA AddressFamilyNumbers enumeration value for + the specific address type, and octets 2 through N contain + + + +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-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 'notUsed(1)' represents an entry for which + the particular MIB object is not applicable to the remote + connection endpoint, + + The enumeration 'unknown(2)' represents an entry for which + the particular address collection state is not known. + + The enumeration 'oneAddr(3)' represents an entry for which + exactly one source address (of the type indicated by the + particular MIB object), has been detected. + + The enumeration 'multiAddr(4)' represents an entry for + which more than one source address (of the type indicated by + the particular MIB object), has been detected. + + An agent is expected to set the initial state of the + PtopoAddrSeenState to 'notUsed(1)' or 'unknown(2)'. + + Note that the PTOPO MIB does not restrict or specify the + means in which the PtopoAddrSeenState is known to an agent. + In particular, an agent may detect this information through + configuration data, or some means other than directly + 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 P +-- +-- *********************************************************** + +-- Connection Table + + + + +Bierman & Jones Informational [Page 15] + +RFC 2922 Physical Topology MIB September 2000 + + +ptopoConnTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtopoConnEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains one or more rows 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 + } + ::= { 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 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 + 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. + + A particular ptopoConnIndex value may be reused in the event + an entry is aged out and later re-learned with the same (or + different) remote chassis and port identifiers. + + An agent is encouraged to assign monotonically increasing + index values to new entries, starting with one, after each + + + +Bierman & Jones Informational [Page 17] + +RFC 2922 Physical Topology MIB September 2000 + + + reboot. It is considered unlikely that the ptopoConnIndex + will wrap between reboots." + ::= { 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 + 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. + + + + +Bierman & Jones Informational [Page 18] + +RFC 2922 Physical Topology MIB September 2000 + + + 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 ptopoDiscoveryLocal indicates this entry was + configured by the local agent, without use of a discovery + protocol. + + 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 AddressFamilyNumbers + 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)." + + + +Bierman & Jones Informational [Page 19] + +RFC 2922 Physical Topology MIB September 2000 + + + ::= { 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 + '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 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 'oneAddr(3)' is + returned. + + If the agent has detected more than one unicast source MAC + address from the remote port, then the value 'multiAddr(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 'notUsed(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. + + + +Bierman & Jones Informational [Page 20] + +RFC 2922 Physical Topology MIB September 2000 + + + If the agent has detected exactly one network source address + of the appropriate type from the remote port, then the value + 'oneAddr(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 'multiAddr(4)' is returned." + ::= { ptopoConnEntry 13 } + +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 topology protocol 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 + + + +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 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 + UNITS "table entries" + 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 + UNITS "table entries" + 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 + UNITS "table entries" + MAX-ACCESS read-only + + + +Bierman & Jones Informational [Page 22] + +RFC 2922 Physical Topology MIB September 2000 + + + STATUS current + DESCRIPTION + "The number of times an entry would have been added to the + ptopoConnTable, (e.g., via information learned from a + topology protocol), but was not because of insufficient + resources." + ::= { ptopoGeneral 4 } + +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 5 } + +-- *********************************************************** +-- +-- P T O P O C O N F I G G R O U P +-- +-- *********************************************************** + +ptopoConfigTrapInterval OBJECT-TYPE + SYNTAX Integer32 (0 | 5..3600) + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object controls the transmission of PTOPO + notifications. + + If this object has a value of zero, then no + ptopoConfigChange notifications will be transmitted by the + agent. + + If this object has a non-zero value, then the agent must not + generate more than one ptopoConfigChange trap-event in the + indicated period, where a 'trap-event' is the transmission + of a single notification PDU type to a list of notification + destinations. If additional configuration changes occur + within the indicated throttling period, then these trap- + events must 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. + + + + +Bierman & Jones Informational [Page 23] + +RFC 2922 Physical Topology MIB September 2000 + + + If notification transmission is enabled, the suggested + default throttling period is 60 seconds, but transmission + should be disabled by default. + + 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." + DEFVAL { 0 } + ::= { 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 topology protocol 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, ) + + where is determined by the + discovery algorithm, and may be different for each entry." + DEFVAL { 300 } + ::= { ptopoConfig 2 } + + +-- PTOPO MIB Notification Definitions +ptopoMIBNotifications OBJECT IDENTIFIER ::= { ptopoMIB 2 } +ptopoMIBTrapPrefix OBJECT IDENTIFIER ::= + + + +Bierman & Jones Informational [Page 24] + +RFC 2922 Physical Topology MIB September 2000 + + + { ptopoMIBNotifications 0 } + +ptopoConfigChange NOTIFICATION-TYPE + OBJECTS { + ptopoConnTabInserts, + ptopoConnTabDeletes, + ptopoConnTabDrops, + ptopoConnTabAgeouts + } + STATUS current + DESCRIPTION + "A ptopoConfigChange notification is sent when the value of + ptopoLastChangeTime changes. It can be utilized by an NMS to + trigger physical topology table maintenance polls. + + Note that transmission of ptopoConfigChange notifications + are throttled by the agent, as specified by the + 'ptopoConfigTrapInterval' object." + ::= { ptopoMIBTrapPrefix 1 } + + +-- PTOPO Registration Points +ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 } + +-- values used with ptopoConnDiscAlgorithm object +ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= + { ptopoRegistrationPoints 1 } + +ptopoDiscoveryLocal OBJECT IDENTIFIER ::= + { ptopoDiscoveryMechanisms 1 } + + +-- conformance information +ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 } + +ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 } +ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 } + + +-- compliance statements +ptopoCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities which implement + the PTOPO MIB." + MODULE -- this module + MANDATORY-GROUPS { + ptopoDataGroup, + + + +Bierman & Jones Informational [Page 25] + +RFC 2922 Physical Topology MIB September 2000 + + + 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, + ptopoConnTabDeletes, + ptopoConnTabDrops, + 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 } + + + +Bierman & Jones Informational [Page 26] + +RFC 2922 Physical Topology MIB September 2000 + + +ptopoConfigGroup OBJECT-GROUP + OBJECTS { + ptopoConfigTrapInterval, + 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 + +5. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + + + +Bierman & Jones Informational [Page 27] + +RFC 2922 Physical Topology MIB September 2000 + + + this standard. Please address the information to the IETF Executive + Director. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + +6. Acknowledgements + + The PTOPO Discovery Protocol is a product of the IETF PTOPOMIB + Working Group. + +7. References + + [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification + 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 with + 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 the + 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 Network + 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 Simple + Network Management Protocol (SNMPv2)", RFC 1904, January + 1996. + + [RFC1905] 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. + + [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Transport Mappings for Version 2 of the Simple Network + 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 IEEE + 802.3 Repeater Devices using SMIv2", RFC 2108, February + 1997. + + [RFC2233] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group + MIB using SMIv2", RFC 2233, November 1997. + + [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, + "Introduction to Version 3 of the Internet-standard + Network Management Framework", RFC 2570, April 1999. + + [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An + 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 Simple + Network Management Protocol (SNMP)", RFC 2572, April + 1999. + + [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 + Applications", RFC 2573, April 1999. + + [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + 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-based + Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP)", RFC 2575, April 1999. + + [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M. and S. Waldbusser, "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, April + 1999. + + [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M. and S. Waldbusser, "Textual Conventions for + SMIv2", STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M. and S. Waldbusser, "Conformance Statements for + 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 Considerations + + There are a number of management objects defined in this MIB that + have a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. + + There are a number of managed objects in this MIB that may contain + sensitive information. These are: + + read-create objects: ptopoConnRemoteChassisType + ptopoConnRemoteChassis ptopoConnRemotePortType + ptopoConnRemotePort ptopoConnAgentNetAddrType + ptopoConnAgentNetAddr ptopoConnIsStatic + ptopoConfigTrapInterval ptopoConfigMaxHoldTime + + read-only objects: ptopoConnDiscAlgorithm + ptopoConnMultiMacSASeen ptopoConnMultiNetSASeen + ptopoConnLastVerifyTime ptopoLastChangeTime + + notifications: ptopoConfigChange + + These MIB objects expose information about the physical connectivity + 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 any + ptopoConfigChange notification by setting the ptopoConfigTrapInterval + object to zero. + + It is thus important to control even GET access to these objects and + possibly to even encrypt the values of these object when sending them + over the network via SNMP. Not all versions of SNMP provide features + for such a secure environment. + + SNMPv1 by itself is not a secure environment. Even if the network + itself is secure (for example by using IPSec), even then, there is no + control as to who on the secure network is allowed to access and + GET/SET (read/change/create/delete) the objects in this MIB. + + It is recommended that the implementers consider the security + features as provided by the SNMPv3 framework. Specifically, the use + 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 SNMP + entity giving access to an instance of this MIB, is properly + configured to give access to the objects only to those principals + (users) that have legitimate rights to indeed GET or SET + (change/create/delete) them. + +9. Authors' Addresses + + Andy Bierman + Cisco Systems + 170 West Tasman Drive + San Jose, CA USA 95134 + + Phone: +1 408-527-3711 + EMail: abierman@cisco.com + + + Kendall S. Jones + Nortel Networks + 4401 Great America Parkway + Santa Clara, CA USA 95054 + + Phone: +1 408-495-7356 + EMail: kejones@nortelnetworks.com + + + + + + + + +Bierman & Jones Informational [Page 31] + +RFC 2922 Physical Topology MIB September 2000 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Bierman & Jones Informational [Page 32] + -- cgit v1.2.3