INTERNET DRAFT Physical Topology MIB and Discovery Protocol Proposal 25 March 1997 Andy Bierman Cisco Systems Inc. abierman@cisco.com Keith McCloghrie Cisco Systems Inc. kzm@cisco.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 1. Introduction This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. Draft Physical Topology MIB and Discovery Protocol March 1997 2. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1], - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the protocol for accessing managed information. Textual conventions are defined in RFC 1903 [3], and conformance statements are defined in RFC 1904 [5]. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A semantically identical MIB conforming to the SNMPv1 SMI can be produced through the appropriate translation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. 3. Overview There is a need for a standardized way of representing the physical network connections pertaining to a given management domain. A standardized discovery mechanism is also required to increase the likelihood of multi-vendor interoperability of such physical topology Bierman/McCloghrie Expires September 25, 1997 [Page 2] Draft Physical Topology MIB and Discovery Protocol March 1997 management information. The scope of the physical topology (PTOPO) mechanism is the identification of physical connections between two network ports. Network addresses of SNMP agents containing management information associated with each port can also be identified. This document contains three main sections: Physical Topology Discovery Protocol The PTOPO Discovery Protocol (PDP) is defined, which provides a simple and interoperable means of supporting the MIB objects defined in the PTOPO MIB. Entity MIB Extension The Entity MIB physical inventory and interface mapping information is utilized in the PTOPO MIB, and an extension module is defined to provide persistent names for physical components. Physical Topology MIB The PTOPO MIB is used for configuring the physical topology function and retrieving learned physical topology information. 3.1. Terms Some terms are used throughout this document: 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. Chassis Identifier A non-volatile DisplayString, unique within a particular administrative domain, used to name a chassis. Preferably, this is a globally unique string as well. Local Chassis The particular chassis containing an SNMP agent implementing the PTOPO MIB and associated Entity MIB. Port A port is a physical component which can be connected to another Bierman/McCloghrie Expires September 25, 1997 [Page 3] Draft Physical Topology MIB and Discovery Protocol March 1997 port through some medium. It is identified by an entPhysicalEntry with an entPhysicalClass value of 'port(10)'. Port Identifier A port identifier consists of a non-volatile DisplayString, which must be unique within the context of the chassis which contains the port. Physical Connection Endpoint Identifier A physical connection endpoint consists of a physical port, which is contained within a single physical chassis. It is distinguished by its chassis identifier and port identifier strings. Physical Connection A physical connection consists of two physical ports, each in a different chassis, configured for the purpose of transferring network traffic between the ports. A physical connection is identified by its endpoints. 3.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 physical connection endpoints and the SNMP agent(s) associated with each physical connection endpoint. The PTOPO MIB and discovery protocol provide neighbor discovery. Only physical connections terminating on a local chassis are supported. This allows the MIB and protocol to be bounded and simple, since topology information does not have to be forwarded. Completeness At least one standard discovery protocol capable of supporting the standard physical topology MIB must be defined. Multi-vendor interoperability will not be achievable unless a simple and extensible discovery protocol is available. No Functional Overlap Existing standard MIBs should be utilized whenever possible. Physical topology information is tightly coupled to functionality found in the Interfaces MIB [7] and Entity MIB [8]. New physical Bierman/McCloghrie Expires September 25, 1997 [Page 4] Draft Physical Topology MIB and Discovery Protocol March 1997 topology MIB objects should not duplicate these MIBs. Identifier Stability Physical connection endpoint identifiers must be persistent (i.e. stable across device reboots). Dynamic primary key objects like ifIndex and entPhysicalIndex are not suitable for representing physical topology information for remote ports. Low Polling Impact Physical topology polling should be minimized through techniques such as TimeFiltered data tables (from RMON-2 [9]), and last-change notifications. 3.3. Persistent Identifiers The PTOPO MIB utilizes non-volatile identifiers to distinguish individual chassis and port components. These identifiers are associated with entries in the entPhysicalTable, and identified by a new non-volatile name string. Identifiers are DisplayStrings, which are limited to 32 bytes in length, This supports flexible naming conventions and constrains the non- volatile storage requirements for an agent. 3.4. Relationship to Entity MIB The Entity MIB [8] allows the physical component inventory and hierarchy to be identified. The physical connection component identifiers defined in this MIB are related to entPhysicalTable entries, and the implementation of the entPhysicalTable and probably entAliasMappingTable are required to implement the PTOPO MIB. The Entity MIB does not provide persistent component identifiers, which are required for the PTOPO MIB. Therefore, an extension to the Entity MIB is defined in this document to provide that feature. The new table augments the entPhysicalTable, and adds a read-only non-volatile identifier for physical components, suitable for supporting the Chassis ID and Port ID requirements of the PTOPO MIB. Bierman/McCloghrie Expires September 25, 1997 [Page 5] Draft Physical Topology MIB and Discovery Protocol March 1997 3.5. Relationship to Interfaces MIB The Interfaces MIB 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 maximum flexibility, the Entity MIB is used to identify ports instead of the Interfaces MIB. However, if a port is represented in both MIBs, then an entAliasMappingEntry must also be present, indicating the relationship. For example, if the port is identified as entPhysicalEntry.33 and ifEntry.6, then the instance entAliasMappingIdentifier.33.0 would contain the value 'ifIndex.6'. 3.6. Relationship to RMON-2 MIB The RMON-2 MIB ([9],[10]) 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 Bierman/McCloghrie Expires September 25, 1997 [Page 6] Draft Physical Topology MIB and Discovery Protocol March 1997 4. PTOPO Discovery Protocol This document defines a discovery protocol, suitable for supporting the data requirements of the PTOPO MIB. The PTOPO Discovery Protocol (PDP) is a media and protocol independent protocol intended to be run on routers, bridges, access servers, switches, etc., allowing a PDP agent to learn SNMP reachability and physical connection endpoint information from adjacent devices. PDP runs on various media that support Subnetwork Access Protocol (SNAP), and runs over the data-link layer only, allowing two systems running different network layer protocols can learn about each other. Each device configured with an active PDP Agent sends periodic messages to a multicast MAC address on all physical interfaces enabled for PDP transmission, and listens for PDP messages on all operational ports. Each PDP message contains information identifying the source port as a PTOPO connection endpoint identifier. It also contains at least one network layer address which can be used by an NMS to reach an SNMP agent on the device. Each PDP message contains a configurable time-to-live value, which tells the recipient PDP agent when to discard each element of learned topology information. 4.1. Frame Encapsulation A OUI value and HDLC protocol value must be chosen to identify PDP messages [TBD]. 4.2. PDP Message Format The basic PDP packet consists of a header, followed by a variable number of type/length/value (TLV) triplets, as indicated in Figure 1. +------------------+----------+---...--+----------+ | header | TLV 1 | ..... | TLV N | +------------------+----------+---...--+----------+ [ Figure 1 -- Basic PDP Message Format ] Bierman/McCloghrie Expires September 25, 1997 [Page 7] Draft Physical Topology MIB and Discovery Protocol March 1997 4.2.1. PDP Header Format The PDP header is a 6 byte header containing 4 fields, as shown in figure 2: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Flags | Time To Live | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ figure 2 -- PDP Message Format ] The PDP header contains the following fields: Version The PDP protocol version number, set to 0x01 for this version of the protocol. Flags The PDP flags field provide for future header extensions and keep the header word-aligned for easier processing. No flag definition bits are defined at this time. This field must be set to zero in all version 1 PDP messages. Time to live The number of seconds the information in this PDP message should be regarded as valid by the recipient. Agents of the PTOPO MIB must not return MIB information based on expired PDP messages. The valid range is 0 to 65535 for this field. Checksum The one's complement of the one's complement checksum of the entire PDP message. PDP messages containing incorrect checksums must be ignored by the recipient. Bierman/McCloghrie Expires September 25, 1997 [Page 8] Draft Physical Topology MIB and Discovery Protocol March 1997 4.2.2. TLV Format Following the PDP header are a variable number of TLVs, depending on implementation and maximum message size. See figure 3 for TLV field layout. Type This field contains of the 2 byte SNMP Enterprise ID of the naming authority, followed by a 2 byte type identifier. Length This field contains the length, in bytes, of the value field. Value This is a variable-length string [0..65535] bytes, (limited by maximum frame size), of unsigned characters. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SNMP Enterprise ID | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value byte 0 | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ Figure 3 - TLV Format ] The header fields are defined as follows: SNMP Enterprise ID The identifier distinguishing the naming authority defining this TLV, as defined by IANA in the Assigned Numbers Document [11]. Type The integer value identifying the type of information contained in the value field. Length The length, in bytes, of the value field to follow. Bierman/McCloghrie Expires September 25, 1997 [Page 9] Draft Physical Topology MIB and Discovery Protocol March 1997 Value A variable-length octet-string containing the instance-specific information for this TLV. 4.3. Standard TLV Definitions The standard PDP TLVs allow for a PDP agent to implement the PTOPO MIB for physical connections terminating on the local chassis. The following table summarizes the TLVs defined in this document. +------------+------+---------------+------------------------------------+ | Enterprise | Type | TLV Name | Example Usage | +------------+------+---------------+------------------------------------+ | IETF | 1 | Chassis ID | "acme.rg1000-switch.0000c07cf297" | +------------+------+---------------+------------------------------------+ | IETF | 2 | Port ID | "eth0/0/0" | +------------+------+---------------+------------------------------------+ | IETF | 3 | Mgmt Address | { ipV4(1), 4, '0x01020304' } | +------------+------+---------------+------------------------------------+ [ Figure 4 - TLV Summary ] 4.3.1. Chassis ID TLV The Chassis ID is a mandatory TLV which identifies the chassis component of the endpoint identifier associated with the transmitting PDP agent. It is a DisplayString, length [1..32] bytes, representing the entPhysicalNVName value for the chassis containing the PDP Agent. 4.3.2. Port ID TLV The Port ID is a mandatory TLV which identifies the port component of the endpoint identifier associated with the transmitting PDP agent. It is a DisplayString, length [1..32] bytes, representing the entPhysicalNVName value identifying the source transmission port for a PDP message. Bierman/McCloghrie Expires September 25, 1997 [Page 10] Draft Physical Topology MIB and Discovery Protocol March 1997 4.3.3. Management Address TLV The Management Address is a mandatory TLV which identifies a network address associated with the local PDP agent, which can be used to reach an SNMP agent associated with the chassis identified in the Chassis ID TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PTOPO NetAddrType | Address Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 0 1 2 3 4 5 6 7 8 9 ..... +-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+ | Addr byte 1 | ... | Addr byte N | +-+-+-+-+-+-+-+-+-+-+-+ .....-+-+-+-+-+-+-+-+-+-+ [ Figure 5 -- Management Address TLV Format ] The Management Address fields are defined as follows: PTOPO NetAddrType The enumerated value for the network address type identified in this TLV. Address Length The number of bytes contained in the address string to follow. Address The binary string containing the network management address. 4.4. Protocol Operation An active PDP Agent must transmit PDP messages, process received PDP messages, and maintain an instance of the PTOPO MIB containing the information learned from received PDP messages. During processing of received PDP messages, a PDP Agent must skip and ignore TLVs unknown to the agent. Bierman/McCloghrie Expires September 25, 1997 [Page 11] Draft Physical Topology MIB and Discovery Protocol March 1997 4.4.1. Message Transmission An active PDP agent must transmit a PDP message out each interface configured for PDP transmission, once each time interval specified in the pdpMessageTxInterval MIB object. Actual transmission intervals are jittered to prevent synchronization effects. Each message is sent with a time-to-live field equal to the value of pdpMessageTxHoldTime MIB object, and must contain at least the three mandatory IETF TLVs supporting the PTOPO MIB. Additional proprietary TLVs may be added, as maximum frame size permits. 4.4.2. Message Processing Upon reception of a PDP message, and verifying the message checksum to be correct, the TLV information is extracted, and relevant PTOPO MIB information is updated. If an entry is added, deleted, or modified, the appropriate TimeFilter and last change time internal variables are updated to signal the change to an NMS. PDP messages must not be forwarded by the receiving PDP Agent. 4.4.3. Interface Startup Procedure In the event an interface becomes operationally enabled and enabled for PDP message transmission, the initial PDP message is generated right away, and it is transmitted three times, at one second intervals. This reduces the convergence delay due to lost packets during system startup. 4.4.4. Interface Shutdown Procedure In the event an interface becomes administratively disabled, and/or disabled for PDP message transmission, a final PDP message is transmitted with a time to live value of zero, before the interface is disabled. Upon reception of such a PDP message, a PDP Agent must remove information in the PTOPO MIB associated with the indicated remote physical connection endpoint. Bierman/McCloghrie Expires September 25, 1997 [Page 12] Draft Physical Topology MIB and Discovery Protocol March 1997 5. Entity MIB Extensions The Entity MIB is used to identify chassis and port components, and component relationships for one or more chassis 'component-trees'. This document defines an extension to the Entity MIB, which augments the entPhysicalTable and provides a source for non-volatile string-based component identifiers, suitable for use in an implementation of the PTOPO MIB. 5.1. Entity Physical Extensions Group This group contains a single table, called the entPhysicalXTable, which augments the entPhysicalTable. Each entPhysicalXEntry provides a DisplayString which can be used by an NMS as a non-volatile alias string for the physical component. 5.2. EntityX MIB Definitions ENTITY-MIB-EXTENSIONS DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF entPhysicalEntry FROM ENTITY-MIB; entityXMIB MODULE-IDENTITY LAST-UPDATED "9703170000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Andy Bierman Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 408-527-3711 abierman@cisco.com Keith McCloghrie Bierman/McCloghrie Expires September 25, 1997 [Page 13] Draft Physical Topology MIB and Discovery Protocol March 1997 Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 408-526-5260 kzm@cisco.com" DESCRIPTION "The extension MIB module for physical entity information." ::= { experimental xx } -- *********************************************************** -- -- E N T I T Y P H Y S I C A L E X T E N S I O N S -- -- *********************************************************** -- entPhysicalTable extensions entityXMIBObjects ::= OBJECT IDENTIFIER { entityXMIB 1 } entityPhysicalX ::= OBJECT IDENTIFIER { entityXMIBObjects 1 } entPhysicalXTable OBJECT-TYPE SYNTAX SEQUENCE OF EntPhysicalXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per physical element represented in the entPhysicalTable." ::= { entityPhysicalX 1 } entPhysicalXEntry OBJECT-TYPE SYNTAX EntPhysicalXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular physical entity. Each entry provides an object (entPhysicalNVName) to help an NMS uniquely identify a physical entity with a DisplayString stored in non-volatile and re-created after a reboot." AUGMENTS { entPhysicalEntry } ::= { entPhysicalXTable 1 } EntPhysicalXEntry ::= SEQUENCE { entPhysicalNVName DisplayString } Bierman/McCloghrie Expires September 25, 1997 [Page 14] Draft Physical Topology MIB and Discovery Protocol March 1997 entPhysicalNVName OBJECT-TYPE SYNTAX DisplayString (SIZE(1..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a non-volatile name for the physical entity. On the first instantiation of an physical entity, the value of entPhysicalNVName is configured by the agent to a string of suitable uniqueness for the indicated component type. For components with an associated entPhysicalClass value of 'chassis(3)', this object should be set to a string that is unique within the administrative domain, and preferably globally unique. For components with an associated entPhysicalClass value other than 'chassis(3)', this object should be set to a string that is unique within the particular chassis which contains the component. The value in the entPhysicalNVName instance must be associated with the same physical entity for as long as that entity remains instantiated, including across all re- initializations/reboots of the network management system, including those which result in a change of the physical entity's entPhysicalIndex value." ::= { entPhysicalXEntry 1 } -- conformance information entityXConformance OBJECT IDENTIFIER ::= { entityXMIB 2 } entityXCompliances OBJECT IDENTIFIER ::= { entityXConformance 1 } entityXGroups OBJECT IDENTIFIER ::= { entityXConformance 2 } -- compliance statements entityXPhysicalCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the entPhysicalXTable Entity MIB extension." MODULE -- this module MANDATORY-GROUPS { entityPhysicalXGroup } ::= { entityXCompliances 1 } Bierman/McCloghrie Expires September 25, 1997 [Page 15] Draft Physical Topology MIB and Discovery Protocol March 1997 -- MIB groupings entityPhysicalXGroup OBJECT-GROUP OBJECTS { entPhysicalNVName } STATUS current DESCRIPTION "The collection of objects which are used to represent extended physical component information for which a single agent provides management information." ::= { entityXGroups 1 } END Bierman/McCloghrie Expires September 25, 1997 [Page 16] Draft Physical Topology MIB and Discovery Protocol March 1997 6. Physical Topology MIB The Physical Topology MIB provides information about remote ports (either learned or configured) and physical connections between local ports and remote ports. Since the PTOPO MIB utilizes the Entity MIB and EntityX MIB, multiple chassis components can be supported by a single SNMP agent, but only one SNMP agent per chassis is supported by the PTOPO MIB. Physical connections between ports on devices represented by the same Entity MIB implementation should be modeled in the Entity MIB instead of the PTOPO MIB. For performance reasons, the identifier strings for local components are replaced with the entPhysicalIndex mappings whenever used as an index value. The PTOPO MIB agent and Entity MIB agent represent the same physical resources, and therefore are considered to fate-share (i.e. reset together upon a reinitialization of the management system). 6.1. PTOPO MIB Structure The PTOPO MIB contains five MIB 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. ptopoPdpConfig Contains configuration variables for the PTOPO Discovery Protocol Agent function. ptopoNotifications Contains trap definitions transmitted on behalf of the PTOPO MIB Agent. Bierman/McCloghrie Expires September 25, 1997 [Page 17] Draft Physical Topology MIB and Discovery Protocol March 1997 6.1.1. ptopoData Group This group contains two tables to identity physical topology data. The ptopoPortTable contains information about the remote physical connection endpoints learned or configured on behalf of the PTOPO MIB SNMP Agent. The ptopoConnTable contains information about the physical connections learned or configured on behalf of the PTOPO MIB SNMP Agent. 6.1.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 ptopoData group polling. 6.1.3. ptopoConfig Group This group contains objects to configure the behavior of the physical topology function. The transmission of ptopoLastChange traps can be configured using the ptopoConfigTrapsEnabled scalar MIB object. 6.1.4. ptopoPdpConfig Group This group contains objects to configure the behavior of the PTOPO Discovery Protocol (PDP) Agent function. The protocol can be globally enabled or disabled. Transmission of PDP messages can also be enabled or disabled on individual interfaces. This group is implemented only by SNMP Agents also acting as PDP Agents. 6.1.5. ptopoNotifications Group This group contains notification definitions relating to the overall status of the PTOPO MIB agent. A single trap is defined, the ptopoConfigChange trap, indicating any modification of the ptopoPortTable or ptopoConnTable. Bierman/McCloghrie Expires September 25, 1997 [Page 18] Draft Physical Topology MIB and Discovery Protocol March 1997 6.2. Physical Topology MIB Definitions PTOPO-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, DisplayString, TimeStamp, TruthValue, AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF TimeFilter FROM RMON2-MIB; ptopoMIB MODULE-IDENTITY LAST-UPDATED "9703250000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Andy Bierman Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 408-527-3711 abierman@cisco.com Keith McCloghrie Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 408-526-5260 kzm@cisco.com" DESCRIPTION "The MIB module for physical topology information." ::= { experimental xx } ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 } -- MIB groups ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 } ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 } ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 } ptopoPdpConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 4 } Bierman/McCloghrie Expires September 25, 1997 [Page 19] Draft Physical Topology MIB and Discovery Protocol March 1997 -- textual conventions -- -- NetAddrType TC -- -- Enumerations distinguishing network-layer address types -- Eventually, they might be included from a general TC module -- NetAddrType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An enumeration identifying a network address type." SYNTAX INTEGER { ipV4 (1), decnet (2), pup (3), chaos (4), xns (5), x121 (6), appletalk (7), clns (8), lat (9), vines (10), cons (11), apollo (12), stun (13), novell (14), qllc (15), snapshot (16), atmIlmi (17), bstun (18), x25pvc (19), ipV6(20), unknown (65535) } NetAddr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Octet string representing a network layer address. The length and format of the address is protocol dependent as follows: ipV4 4 octets decnet 2 octets pup obsolete Bierman/McCloghrie Expires September 25, 1997 [Page 20] Draft Physical Topology MIB and Discovery Protocol March 1997 chaos 2 octets xns 10 octets first 4 octets are the net number last 6 octets are the host number x121 appletalk 3 octets first 2 octets are the net number last octet is the host number clns lat vines 6 octets first 4 octets are the net number last 2 octets are the host number cons apollo 10 octets first 4 octets are the net number last 6 octets are the host number stun 8 octets novell 10 octets first 4 octets are the net number last 6 octets are the host number qllc 6 octets bstun 1 octet - bi-sync serial tunnel snapshot 1 octet atmIlmi 4 octets x25 pvc 2 octets (12 bits) ipV6 16 octets" SYNTAX OCTET STRING (SIZE (0..20)) -- *********************************************************** -- -- P T O P O D A T A G R O U P -- -- *********************************************************** -- Port Name Table ptopoPortTable OBJECT-TYPE SYNTAX SEQUENCE OF PtopoPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per port identifier known to this agent." ::= { ptopoData 1 } Bierman/McCloghrie Expires September 25, 1997 [Page 21] Draft Physical Topology MIB and Discovery Protocol March 1997 ptopoPortEntry OBJECT-TYPE SYNTAX PtopoPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular remote physical port. Entries may be created and deleted in this table, either manually or by the agent (if a physical topology discovery process is active)." INDEX { ptopoPortTimeMark, ptopoChassisID, ptopoPortID } ::= { ptopoPortTable 1 } PtopoPortEntry ::= SEQUENCE { ptopoPortTimeMark TimeFilter, ptopoChassisID DisplayString, ptopoPortID DisplayString, ptopoAgentNetAddrType NetAddrType, ptopoAgentNetAddr NetAddr, ptopoPortDiscAlgorithm AutonomousType, ptopoPortRowStatus RowStatus } ptopoPortTimeMark 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." ::= { ptopoPortEntry 1 } ptopoChassisID OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The non-volatile identifier string for the indicated chassis. Note that this string is used to identify the chassis, not a particular agent containing management information on behalf of the chassis. All agents representing the same chassis information must identify the chassis with the same value of ptopoChassisID. Bierman/McCloghrie Expires September 25, 1997 [Page 22] Draft Physical Topology MIB and Discovery Protocol March 1997 This object refers to the remote entPhysicalEntry with the same value of entPhysicalNVName as this ptopoChassisID value." ::= { ptopoPortEntry 2 } ptopoPortID OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The non-volatile identifier string for the indicated port. Note that this string must be unique only within the scope of a particular chassis. All agents representing the same port information must identify the port with the same value of ptopoChassisID and ptopoPortID. This object refers to the remote entPhysicalEntry with the same value of entPhysicalNVName as this ptopoPortID value." ::= { ptopoPortEntry 3 } ptopoAgentNetAddrType OBJECT-TYPE SYNTAX NetAddrType MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the network address type of the ptopoAgentNetAddr object. This object may not be modified if the associated ptopoPortRowStatus object has a value of active(1)." ::= { ptopoPortEntry 4 } ptopoAgentNetAddr OBJECT-TYPE SYNTAX NetAddr MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies a network address which may be used to reach an SNMP agent entity on the indicated port. This object may not be modified if the associated ptopoPortRowStatus object has a value of active(1)." ::= { ptopoPortEntry 5 } ptopoPortDiscAlgorithm OBJECT-TYPE Bierman/McCloghrie Expires September 25, 1997 [Page 23] Draft Physical Topology MIB and Discovery Protocol March 1997 SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of the algorithm used to discover this information. Valid values include the following OBJECT IDENTIFIERs: A value of ptopoDiscoveryPDP indicates this entry was configured using the PTOPO Discovery Protocol. A value of ptopoDiscoveryLocal indicates this entry was configured by the local agent, without use of a discovery protocol. A value of { 0 0 } indicates this entry was created manually by an NMS via the associated RowStatus object. This object may not be modified if the associated ptopoPortRowStatus object has a value of active(1)." ::= { ptopoPortEntry 6 } ptopoPortRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row." ::= { ptopoPortEntry 7 } -- Physical Connection Table ptopoConnTable OBJECT-TYPE SYNTAX SEQUENCE OF PtopoConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per physical network connection known to this agent. The agent must ensure that duplicate connections are not present in the table at any time." ::= { ptopoData 2 } ptopoConnEntry OBJECT-TYPE SYNTAX PtopoConnEntry Bierman/McCloghrie Expires September 25, 1997 [Page 24] Draft Physical Topology MIB and Discovery Protocol March 1997 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, ptopoConnChassis1, ptopoConnPort1, ptopoConnChassis2, ptopoConnPort2 } ::= { ptopoConnTable 1 } PtopoConnEntry ::= SEQUENCE { ptopoConnTimeMark TimeFilter, ptopoConnChassis1 Integer32, ptopoConnPort1 Integer32, ptopoConnChassis2 DisplayString, ptopoConnPort2 DisplayString, ptopoConnDiscAlgorithm AutonomousType, 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 } ptopoConnChassis1 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the value of entPhysicalIndex used to represent the particular local chassis component, which is associated with the first endpoint in this physical connection." ::= { ptopoConnEntry 2 } ptopoConnPort1 OBJECT-TYPE Bierman/McCloghrie Expires September 25, 1997 [Page 25] Draft Physical Topology MIB and Discovery Protocol March 1997 SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the value of entPhysicalIndex used to represent the particular local port component, which is associated with the first endpoint in this physical connection." ::= { ptopoConnEntry 3 } ptopoConnChassis2 OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The chassis identifier string for the remote chassis associated with the second endpoint in this physical connection. This value will contain the same value as exactly one instance of the entPhysicalNVName object on the remote agent representing the remote chassis." ::= { ptopoConnEntry 4 } ptopoConnPort2 OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The port ID string for the port associated with the second endpoint in this physical connection. This value will contain the same value as exactly one instance of the entPhysicalNVName object on the remote agent representing the remote port, which is contained in the same chassis as identified by the ptopoConnChassis2 object." ::= { ptopoConnEntry 5 } ptopoConnDiscAlgorithm OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of the algorithm used to discover this Bierman/McCloghrie Expires September 25, 1997 [Page 26] Draft Physical Topology MIB and Discovery Protocol March 1997 information. A value of ptopoDiscoveryPDP indicates this entry was configured using the PTOPO Discovery Protocol. A value of ptopoDiscoveryLocal indicates this entry was configured by the local agent, without use of a discovery protocol. A value of { 0 0 } indicates this entry was created manually by an NMS via the associated RowStatus object. This object may not be modified if the associated ptopoPortRowStatus object has a value of active(1)." ::= { ptopoConnEntry 6 } ptopoConnRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. If the agent is capable of non-volatile storage of the ptopoConnTable, and the active entry was configured manually, then this entry must be restored after a re- initialization of the management system." ::= { ptopoConnEntry 7 } -- *********************************************************** -- -- 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 was last created, modified, or deleted in any of these tables: - ptopoPortTable - ptopoConnTable Bierman/McCloghrie Expires September 25, 1997 [Page 27] Draft Physical Topology MIB and Discovery Protocol March 1997 An NMS can use this object to reduce polling of the ptopoData group objects." ::= { ptopoGeneral 1 } ptopoPortTabInserts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an entry has been inserted into the ptopoPortTable." ::= { ptopoGeneral 2 } ptopoPortTabDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an entry has been deleted from the ptopoPortTable." ::= { ptopoGeneral 3 } ptopoConnTabInserts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an entry has been inserted into the ptopoConnTable." ::= { ptopoGeneral 4 } ptopoConnTabDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an entry has been deleted from the ptopoConnTable." ::= { ptopoGeneral 5 } -- *********************************************************** -- -- P T O P O C O N F I G G R O U P -- -- *********************************************************** Bierman/McCloghrie Expires September 25, 1997 [Page 28] Draft Physical Topology MIB and Discovery Protocol March 1997 ptopoConfigTrapsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the transmission of PTOPO notifications. 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 { true } ::= { ptopoConfig 1 } -- -- *********************************************************** -- -- P T O P O P D P C O N F I G -- -- *********************************************************** -- -- The Physical Topology Discovery Protocol Configuration Group pdpVersion OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The version number used in PDP messages transmitted on behalf of this PDP Agent." ::= { ptopoPdpConfig 1 } pdpAgentEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The current PDP Agent status. If this object has a value of 'true(1)', then the PDP Agent will transmit PDP messages for the enabled ports, and process messages received from other PDP Agents. If this object has a value of 'false(2)', then the PDP Agent Bierman/McCloghrie Expires September 25, 1997 [Page 29] Draft Physical Topology MIB and Discovery Protocol March 1997 will not transmit any PDP messages, and will not process messages received from other PDP Agents. 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." ::= { ptopoPdpConfig 2 } pdpMessageTxInterval OBJECT-TYPE SYNTAX Integer32 (5..32768) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The interval at which PDP messages are transmitted on behalf of this agent. 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 { 60 } ::= { ptopoPdpConfig 3 } pdpMessageTxHoldTime OBJECT-TYPE SYNTAX Integer32 (10..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The time-to-live value used in PDP messages transmitted on behalf of this agent. 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 { 180 } ::= { ptopoPdpConfig 4 } pdpTxSuppressTable OBJECT-TYPE SYNTAX SEQUENCE OF PdpTxSuppressEntry MAX-ACCESS not-accessible STATUS current Bierman/McCloghrie Expires September 25, 1997 [Page 30] Draft Physical Topology MIB and Discovery Protocol March 1997 DESCRIPTION "A table for suppressing PDP message transmission on individual ports." ::= { ptopoPdpConfig 5 } pdpTxSuppressEntry OBJECT-TYPE SYNTAX PdpTxSuppressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "PDP message transmission suppression configuration information for the indicated port. The port must be contained in the same chassis as the PDP agent. PDP messages will not be transmitted on the indicated port, even if the port is enabled (e.g., ifOperStatus = 'up(1)'). If the agent is capable of storing non-volatile configuration, then each active pdpTxSuppressEntry must be re-created after a re-initialization of the management system. Only entries pertaining to a local chassis may be created in this table." INDEX { pdpTxSuppressPortIndex } ::= { pdpTxSuppressTable 1 } PdpTxSuppressEntry ::= SEQUENCE { pdpTxSuppressPortIndex Integer32, pdpTxSuppressRowStatus RowStatus } pdpTxSuppressPortIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the value of entPhysicalIndex used to represent the particular local port component associated with this PDP message configuration. PDP messages are not to be transmitted on the indicated port if this entry is in the active state." ::= { pdpTxSuppressEntry 1 } pdpTxSuppressRowStatus OBJECT-TYPE Bierman/McCloghrie Expires September 25, 1997 [Page 31] Draft Physical Topology MIB and Discovery Protocol March 1997 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry." ::= { pdpTxSuppressEntry 2 } -- -- *********************************************************** -- -- P T O P O D I S C O V E R Y A L G O R I T M S -- -- *********************************************************** -- -- The Physical Topology Discovery Types ptopoDiscoveryTypes OBJECT IDENTIFIER ::= { ptopoMIB 2 } ptopoDiscoveryPDP OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates the associated PTOPO MIB element was discovered using Version 1 of the PTOPO Discovery Protocol." ::= { ptopoDiscoveryTypes 1 } ptopoDiscoveryLocal OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates the associated PTOPO MIB element was not discovered, but rather configured using unspecified means by the local agent. This enumeration is not used if the PTOPO management element was configured as a result of SNMP Set operations." ::= { ptopoDiscoveryTypes 2 } -- -- *********************************************************** -- -- P T O P O N O T I F I C A T I O N S -- -- *********************************************************** -- -- The Physical Topology Notification Group ptopoMIBTraps OBJECT IDENTIFIER ::= { ptopoMIB 3 } Bierman/McCloghrie Expires September 25, 1997 [Page 32] Draft Physical Topology MIB and Discovery Protocol March 1997 ptopoMIBTrapPrefix OBJECT IDENTIFIER ::= { ptopoMIBTraps 0 } ptopoConfigChange NOTIFICATION-TYPE OBJECTS { ptopoPortTabInserts, ptopoPortTabDeletes, ptopoConnTabInserts, ptopoConnTabDeletes } STATUS current DESCRIPTION "A ptopoConfigChange trap is sent when the value of ptopoLastChangeTime changes. It can be utilized by an NMS to trigger physical topology table maintenance polls. An agent must not generate more than one ptopoConfigChange 'trap-event' in a five second period, where a 'trap-event' is the transmission of a single trap PDU to a list of trap destinations. If additional configuration changes occur within the five second 'throttling' period, then these trap-events should be suppressed by the agent. An NMS should periodically check the value of ptopoLastChangeTime to detect any missed ptopoConfigChange trap-events, e.g. due to throttling or transmission loss." ::= { ptopoMIBTrapPrefix 1 } -- 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, ptopoGeneralGroup, ptopoConfigGroup, ptopoNotificationsGroup } ::= { ptopoCompliances 1 } -- MIB groupings ptopoDataGroup OBJECT-GROUP OBJECTS { ptopoAgentNetAddrType, Bierman/McCloghrie Expires September 25, 1997 [Page 33] Draft Physical Topology MIB and Discovery Protocol March 1997 ptopoAgentNetAddr, ptopoPortDiscAlgorithm, ptopoPortRowStatus, ptopoConnLastChangeTime, ptopoConnDiscAlgorithm, 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, ptopoPortTabInserts, ptopoPortTabDeletes, ptopoConnTabInserts, ptopoConnTabDeletes } STATUS current DESCRIPTION "The collection of objects which are used to report the general status of the PTOPO MIB implementation. This group is mandatory for all agents which implement the PTOPO MIB." ::= { ptopoGroups 2 } ptopoConfigGroup OBJECT-GROUP OBJECTS { ptopoConfigTrapsEnabled } 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." Bierman/McCloghrie Expires September 25, 1997 [Page 34] Draft Physical Topology MIB and Discovery Protocol March 1997 ::= { ptopoGroups 3 } ptopoPdpConfigGroup OBJECT-GROUP OBJECTS { pdpVersion, pdpAgentEnabled, pdpMessageTxInterval, pdpMessageTxHoldTime, pdpTxSuppressRowStatus } STATUS current DESCRIPTION "The collection of objects which are used to configure the PTOPO Discovery Protocol Agent behavior. This group is mandatory for agents which implement the PTOPO Discovery Protocol." ::= { ptopoGroups 4 } ptopoNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { ptopoConfigChange } STATUS current DESCRIPTION "The collection of notifications used to indicate PTOPO MIB data consistency and general status information." ::= { ptopoGroups 5 } END 7. Acknowledgements This document is based on the Cisco Discovery Protocol (CDP) [12], developed at Cisco Systems by Dino Farinacci and Keith McCloghrie. 8. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, Bierman/McCloghrie Expires September 25, 1997 [Page 35] Draft Physical Topology MIB and Discovery Protocol March 1997 RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [5] SNMPv2 Working Group, 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. [6] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [7] McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [8] McCloghrie, K., and Bierman, A., "Entity MIB Using SMIv2", RFC 2037, Cisco Systems, October 1996. [9] Waldbusser S., "Remote Network Monitoring MIB Version 2 using SMIv2", RFC 2021, INS, January 1997. [10] Bierman A., and Iddon, R., "Remote Network Monitoring MIB Protocol Identifiers", RFC 2074, Cisco Systems, 3Com/AXON Networks, January 1997. [11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [12] Farinacci, D. & McCloghrie, K., "Cisco Discovery Protocol (CDP)", Internal Cisco Document, Cisco Systems, August 1996. 9. Security Considerations This document defines mechanisms which can potentially expose physical topology and connectivity information pertaining to particular networks. A network administrator should take care to restrict PTOPO Discovery Bierman/McCloghrie Expires September 25, 1997 [Page 36] Draft Physical Topology MIB and Discovery Protocol March 1997 Protocol message transmission and PTOPO MIB trap transmission to interfaces deemed appropriate to carry packets containing such information. A network administrator should also utilize access control to prevent inappropriate manual configuration of the writable objects defined in this document. 10. Authors' Addresses Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: 408-527-3711 Email: abierman@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: 408-526-5260 Email: kzm@cisco.com Bierman/McCloghrie Expires September 25, 1997 [Page 37] Draft Physical Topology MIB and Discovery Protocol March 1997 Table of Contents 1 Introduction .................................................... 1 2 The SNMP Network Management Framework ........................... 2 2.1 Object Definitions ............................................ 2 3 Overview ........................................................ 2 3.1 Terms ......................................................... 3 3.2 Design Goals .................................................. 4 3.3 Persistent Identifiers ........................................ 5 3.4 Relationship to Entity MIB .................................... 5 3.5 Relationship to Interfaces MIB ................................ 6 3.6 Relationship to RMON-2 MIB .................................... 6 4 PTOPO Discovery Protocol ........................................ 7 4.1 Frame Encapsulation ........................................... 7 4.2 PDP Message Format ............................................ 7 4.2.1 PDP Header Format ........................................... 8 4.2.2 TLV Format .................................................. 9 4.3 Standard TLV Definitions ...................................... 10 4.3.1 Chassis ID TLV .............................................. 10 4.3.2 Port ID TLV ................................................. 10 4.3.3 Management Address TLV ...................................... 11 4.4 Protocol Operation ............................................ 11 4.4.1 Message Transmission ........................................ 12 4.4.2 Message Processing .......................................... 12 4.4.3 Interface Startup Procedure ................................. 12 4.4.4 Interface Shutdown Procedure ................................ 12 5 Entity MIB Extensions ........................................... 13 5.1 Entity Physical Extensions Group .............................. 13 5.2 EntityX MIB Definitions ....................................... 13 6 Physical Topology MIB ........................................... 17 6.1 PTOPO MIB Structure ........................................... 17 6.1.1 ptopoData Group ............................................. 18 6.1.2 ptopoGeneral Group .......................................... 18 6.1.3 ptopoConfig Group ........................................... 18 6.1.4 ptopoPdpConfig Group ........................................ 18 6.1.5 ptopoNotifications Group .................................... 18 6.2 Physical Topology MIB Definitions ............................. 19 7 Acknowledgements ................................................ 35 8 References ...................................................... 35 9 Security Considerations ......................................... 36 10 Authors' Addresses ............................................. 37 Bierman/McCloghrie Expires September 25, 1997 [Page 38]