<draft-ietf-ptopomib-pdp-00.txt> Physical Topology Discovery Protocol and MIB 30 July 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 protocol, and an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a physical topology discovery protocol and managed objects used for Draft Physical Topology Discovery Protocol and MIB July 1997 managing the protocol. 2. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], - the protocol for accessing managed information. Textual conventions are defined in RFC 1903 [RFC1903], and conformance statements are defined in RFC 1904 [RFC1904]. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A semantically identical MIB conforming to the SNMPv1 SMI can be produced through the appropriate translation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Bierman/McCloghrie Expires January, 1998 [Page 2]
Draft Physical Topology Discovery Protocol and MIB July 1997 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 management information. This document specifies a discovery protocol, suitable for use with the Physical Topolgy MIB [PTOPO]. 3.1. Terms Some terms are used throughout this document: SNMP Agent This term refers to an SNMP agent co-located with a particular PDP Agent. Specifically, it refers to the SNMP Agent providing PDP MIB, Entity MIB, Interfaces MIB, and possibly PTOPO MIB support for a particular chassis. PDP Agent This term refers to a software entity which implements the PTOPO Discovery Protocol for a particular chassis. 3.2. Persistent Identifiers The PTOPO MIB utilizes non-volatile identifiers to distinguish individual chassis and port components. These identifiers are associated with external objects in order to relate topology information to the existing managed objects. In particular, an object from the Entity MIB or Interfaces MIB can be used as the 'reference-point' for a connection component identifier. 3.3. Relationship to the Physical Topology MIB The Physical Topology MIB [PTOPO] allows a PDP Agent to expose learned physical topology information, using a standard MIB. PDP is intended to fully support the PTOPO MIB. Bierman/McCloghrie Expires January, 1998 [Page 3]
Draft Physical Topology Discovery Protocol and MIB July 1997 3.4. Relationship to Entity MIB The Entity MIB [RFC2037] allows the physical component inventory and hierarchy to be identified. The chassis identifier strings passed in PDP messages identify entPhysicalTable entries, and implementation of the entPhysicalTable and entPhysicalXTable (found in 'Entity MIB Extensions for Persistent Component Identification' [ENTITY-EXT]) are required for SNMP agents which also implement the PDP MIB. 3.5. Relationship to Interfaces MIB The Interfaces MIB provides a standard mechanism for managing network interfaces. The port identifier strings passed in PDP messages identify ifTable (or entPhysicalTable) entries, and implementation of the ifTable and ifXTable [RFC1573] are required for SNMP agents which also implement the PDP MIB, for the ports which are represented in the Interfaces MIB. 4. PTOPO Discovery Protocol This section 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 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 address which can be used by an NMS to reach an SNMP agent on the device (via the indicated source port). 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. Bierman/McCloghrie Expires January, 1998 [Page 4]
Draft Physical Topology Discovery Protocol and MIB July 1997 4.1. Frame Encapsulation A OUI value an HDLC protocol value must be chosen to identify PDP messages. [TBD -- authority contact info on process and example] 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 ] 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. Bierman/McCloghrie Expires January, 1998 [Page 5]
Draft Physical Topology Discovery Protocol and MIB July 1997 - 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. 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. The type field consists of the 3 byte OUI of the naming authority, followed by one byte of padding. Bierman/McCloghrie Expires January, 1998 [Page 6]
Draft Physical Topology Discovery Protocol and MIB July 1997 A 2 byte field follows, and contains the length, in octets, of the value field contained in the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OIU-Specific-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Value byte 0 | ... repeated through value byte[Length-1] +-+-+-+-+-+-+-+-+ [ Figure 3 - TLV Format ] The header fields are defined as follows: OUI The identifier distinguishing the naming authority defining this TLV. Padding A single byte, set to zero, used for alignment. OUI-Specific-Type The integer value identifying the type of information contained in the value field. Length The length, in octets, of the value field to follow. Value A variable-length octet-string containing the instance-specific information for this TLV. Bierman/McCloghrie Expires January, 1998 [Page 7]
Draft Physical Topology Discovery Protocol and MIB July 1997 4.3. Standard TLV Definitions The standard PDP TLVs allow for a PDP agent to implement the PTOPO MIB for connections terminating on the local chassis. Bierman/McCloghrie Expires January, 1998 [Page 8]
Draft Physical Topology Discovery Protocol and MIB July 1997 The following table summarizes the TLVs defined in this document. +-------+------+-----------------+--------------------------------------+ | OUI | Type | TLV Name | Example Usage | +-------+------+-----------------+--------------------------------------+ | IETF | 1 | Chassis ID | "acme.rg1000-switch.0000c07cf297" | +-------+------+-----------------+--------------------------------------+ | IETF | 2 | Chassis Source | OID string of entPhysicalAlias.11 | +-------+------+-----------------+--------------------------------------+ | IETF | 3 | Port ID | "eth0/0/0" | +-------+------+-----------------+--------------------------------------+ | IETF | 4 | Port Source | OID string of ifAlias.21 | +-------+------+-----------------+--------------------------------------+ | IETF | 5 | Mgmt Address | { ipV4(1), 4, '0x01020304' } | +-------+------+-----------------+--------------------------------------+ [ Figure 4 - TLV Summary ] 4.3.1. Chassis ID 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..48] octets, representing the globally unique, non-volatile string identifying the chassis containing the PDP Agent. 4.3.2. Chassis Source The Chassis Source is a mandatory TLV which identifies the MIB object (implemented by the local PDP agent) which contains the chassis ID value specified in the Chassis ID TLV. The identifier is encoded as a DisplayString, and contains an ASCII representation of the instance OID identifying the variable containing the same string as specified in the Chassis ID TLV. For example, the instance entPhysicalAlias.19 is encoded into the value string "1.3.6.1.2.1.47.1.5.1.1.1.19", and the associated length field set to the integer value '27'. Bierman/McCloghrie Expires January, 1998 [Page 9]
Draft Physical Topology Discovery Protocol and MIB July 1997 4.3.3. Port ID The Port ID is a mandatory TLV which identifies the port component of the endpoint identifier associated with the transmitting PDP agent. If the specified port is an IEEE 802.3 Repeater port, then this TLV is optional. The identifier is encoded as a DisplayString, length [1..48] octets, representing the chassis-unique, non-volatile string identifying the source transmission port for this PDP message. 4.3.4. Port Source The Port Source is a mandatory TLV which identifies the MIB object (implemented by the local PDP agent) which contains the port ID value specified in the Port ID TLV. If the specified port is an IEEE 802.3 Repeater port, then this TLV is optional. The identifier is encoded as a DisplayString, and contains an ASCII representation of the instance OID identifying the variable containing the same string as specified in the Port ID TLV. For example, the instance ifAlias.14 is encoded into the value string "1.3.6.1.2.1.31.1.1.1.18.14", and the associated length field set to the integer value '26'. Bierman/McCloghrie Expires January, 1998 [Page 10]
Draft Physical Topology Discovery Protocol and MIB July 1997 4.3.5. Management Address The Management Address is a mandatory TLV which identifies a network address associated with the local PDP agent, which can be used to reach the agent on the port identified in the Port 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IANA AddressFamily | 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: IANA Address Family The enumerated value for the network address type identified in this TLV. Address Length The number of octets contained in the address string to follow. Address The binary string containing the network management address for this TLV. 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 January, 1998 [Page 11]
Draft Physical Topology Discovery Protocol and MIB July 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 five 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 should be updated to signal the change to an NMS. 4.4.3. Interface Shutdown Procedure In the event an interface, currently configured with PDP message transmission enabled, either becomes disabled, or the interface is administratively disabled, a final PDP message is transmitted with a time to live value of zero. After reception of such a PDP message, the PDP Agent must remove information in the PTOPO MIB associated with the indicated connection endpoint. 5. PTOPO Discovery Protocol MIB This section defines the MIB used to configure PDP agent behavior. 5.1. PDP MIB Definitions PDP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32 FROM SNMPv2-SMI RowStatus Bierman/McCloghrie Expires January, 1998 [Page 12]
Draft Physical Topology Discovery Protocol and MIB July 1997 FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF PhysicalIndex FROM ENTITY-MIB; pdpMIB MODULE-IDENTITY LAST-UPDATED "9707300000Z" 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 managing the Physical Topology Discovery Protocol." ::= { experimental xx } pdpMIBObjects OBJECT IDENTIFIER ::= { pdpMIB 1 } -- MIB groups pdpConfig OBJECT IDENTIFIER ::= { pdpMIBObjects 1 } -- -- *********************************************************** -- -- P T O P O P D P C O N F I G -- -- *********************************************************** -- -- The Physical Topology Discovery Protocol Configuration Group pdpAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), Bierman/McCloghrie Expires January, 1998 [Page 13]
Draft Physical Topology Discovery Protocol and MIB July 1997 disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administratively desired status of the physical topology discovery protocol. 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." ::= { pdpConfig 1 } pdpOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the physical topology discovery protocol." ::= { pdpConfig 2 } pdpMessageTxInterval OBJECT-TYPE SYNTAX Integer32 (5..32768) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The interval at which PDP advertisements 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 } ::= { pdpConfig 3 } pdpMessageTxHoldTime OBJECT-TYPE SYNTAX Integer32 (10..65535) UNITS "seconds" Bierman/McCloghrie Expires January, 1998 [Page 14]
Draft Physical Topology Discovery Protocol and MIB July 1997 MAX-ACCESS read-write STATUS current DESCRIPTION "The time-to-live value used in PDP advertisements 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 } ::= { pdpConfig 4 } pdpTxSuppressTable OBJECT-TYPE SYNTAX SEQUENCE OF PdpTxSuppressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table controlling PDP advertisement transmission on individual ports." ::= { pdpConfig 5 } pdpTxSuppressEntry OBJECT-TYPE SYNTAX PdpTxSuppressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "PDP advertisement transmission configuration information for a particular port. The port must be contained in the same chassis as the PDP agent. PDP advertisements will not be transmitted on this port, even if the port is enabled. 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 the 'local' chassis may be created in this table." INDEX { pdpTxSuppressChassisId, pdpTxSuppressPortId } ::= { pdpTxSuppressTable 1 } Bierman/McCloghrie Expires January, 1998 [Page 15]
Draft Physical Topology Discovery Protocol and MIB July 1997 PdpTxSuppressEntry ::= SEQUENCE { pdpTxSuppressChassisId PhysicalIndex, pdpTxSuppressPortId PhysicalIndex, pdpTxSuppressRowStatus RowStatus } pdpTxSuppressChassisId OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entPhysicalIndex value used to identify the chassis component associated with this entry." ::= { pdpTxSuppressEntry 1 } pdpTxSuppressPortId OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entPhysicalIndex value used to identify the port component associated with this entry." ::= { pdpTxSuppressEntry 2 } pdpTxSuppressRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry." ::= { pdpTxSuppressEntry 3 } -- conformance information pdpConformance OBJECT IDENTIFIER ::= { pdpMIB 2 } pdpCompliances OBJECT IDENTIFIER ::= { pdpConformance 1 } pdpGroups OBJECT IDENTIFIER ::= { pdpConformance 2 } -- compliance statements pdpCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement Bierman/McCloghrie Expires January, 1998 [Page 16]
Draft Physical Topology Discovery Protocol and MIB July 1997 the PDP MIB." MODULE -- this module MANDATORY-GROUPS { pdpConfigGroup } ::= { pdpCompliances 1 } -- MIB groupings pdpConfigGroup OBJECT-GROUP OBJECTS { pdpAdminStatus, pdpOperStatus, pdpMessageTxInterval, pdpMessageTxHoldTime, pdpTxSuppressRowStatus } STATUS current DESCRIPTION "The collection of objects which are used to configure the PTOPO Discovery Protocol implementation behavior. This group is mandatory for agents which implement the PTOPO Discovery Protocol." ::= { pdpGroups 1 } END 6. Acknowledgements The PTOPO Discovery Protocol is based on the Cisco Discovery Ptotocol. Bierman/McCloghrie Expires January, 1998 [Page 17]
Draft Physical Topology Discovery Protocol and MIB July 1997 7. References [ENTITY-EXT] Bierman, A., McCloghrie, K., "Entity MIB Extensions for Persistent Component Identification", draft-bierman-entmib-compid-00.txt, Cisco Systems, July 1997. [PTOPO] Bierman, A., Kones, K., "Physical Topology MIB", draft-ietf- ptopomib-mib-00.txt, Cisco Systems, Bay Networks, July 1997. [RFC1157] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [RFC1213] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [RFC1573] McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [RFC1902] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [RFC1903] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [RFC1904] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. [RFC1905] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Bierman/McCloghrie Expires January, 1998 [Page 18]
Draft Physical Topology Discovery Protocol and MIB July 1997 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2037] McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037, Cisco Systems, October 1996. Bierman/McCloghrie Expires January, 1998 [Page 19]
Draft Physical Topology Discovery Protocol and MIB July 1997 8. Security Considerations This protocol and associated MIB can expose the existence of MAC and network layer addresses used by devices within a given network. A network administrator may wish access to this management information, using SNMP access control mechanisms, and restrict PDP advertisement transmission to a particular set of ports, using the pdpTxSuppressTable. 9. 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 January, 1998 [Page 20]
Draft Physical Topology Discovery Protocol and MIB July 1997 Table of Contents 1 Introduction .................................................... 1 2 The SNMP Network Management Framework ........................... 2 2.1 Object Definitions ............................................ 2 3 Overview ........................................................ 3 3.1 Terms ......................................................... 3 3.2 Persistent Identifiers ........................................ 3 3.3 Relationship to the Physical Topology MIB ..................... 3 3.4 Relationship to Entity MIB .................................... 4 3.5 Relationship to Interfaces MIB ................................ 4 4 PTOPO Discovery Protocol ........................................ 4 4.1 Frame Encapsulation ........................................... 5 4.2 PDP Message Format ............................................ 5 4.2.1 PDP Header Format ........................................... 5 4.2.2 TLV Format .................................................. 6 4.3 Standard TLV Definitions ...................................... 8 4.3.1 Chassis ID .................................................. 9 4.3.2 Chassis Source .............................................. 9 4.3.3 Port ID ..................................................... 10 4.3.4 Port Source ................................................. 10 4.3.5 Management Address .......................................... 11 4.4 Protocol Operation ............................................ 11 4.4.1 Message Transmission ........................................ 12 4.4.2 Message Processing .......................................... 12 4.4.3 Interface Shutdown Procedure ................................ 12 5 PTOPO Discovery Protocol MIB .................................... 12 5.1 PDP MIB Definitions ........................................... 12 6 Acknowledgements ................................................ 17 7 References ...................................................... 18 8 Security Considerations ......................................... 20 9 Authors' Addresses .............................................. 20 Bierman/McCloghrie Expires January, 1998 [Page 21]
