Draft PTOPO Discovery Protocol and MIB September 1997 Physical Topology Discovery Protocol and MIB 17 September 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 Bierman/McCloghrie Expires March 1998 [Page 1] Draft PTOPO Discovery Protocol and MIB September 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. 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 Bierman/McCloghrie Expires March 1998 [Page 2] Draft PTOPO Discovery Protocol and MIB September 1997 likelihood of multi-vendor interoperability of such physical topology management information. This document specifies a discovery protocol, suitable for use with the Physical Topology 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. 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 Bierman/McCloghrie Expires March 1998 [Page 3] Draft PTOPO Discovery Protocol and MIB September 1997 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 independent protocol intended to be run on routers, bridges, access servers, switches, repeaters, 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 the same set on interfaces. 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. 4.1. Frame Encapsulation The following open issues are under consideration by the working group: An EtherType value must be selected to identify PDP messages transmitted over DIX Ethernet, and IEEE 802.3,802.5 media types Bierman/McCloghrie Expires March 1998 [Page 4] Draft PTOPO Discovery Protocol and MIB September 1997 (using LLC/SNAP encapsulation). A multicast MAC address must be selected for the destination address (DA) field in PDP messages transmitted over DIX Ethernet, IEEE 802.3, and IEEE 802.5 media types. 4.2. PDP Forwarding If at all possible, PDP agents are not supposed to forward PDP messages received on any port. However, some devices, such as repeaters, cannot examine each frame received on an interface or port. Such a device will allow PDP messages to be retransmitted on one or more local ports, and will transmit its own PDP messages on those ports as well. These agents are termed 'forwarding' PDP agents. PDP agents located on devices which examine each frame before retransmitting it (e.g., routers and bridges), are expected to process received PDP messages and not retransmit them on any local port. These agents are termed 'non-forwarding' PDP agents. An NMS may find physical topology information about the same physical port, represented by several PTOPO agents. This may occur for one of several reasons, including a mixture of forwarding and non-forwarding PDP agents within a network. 4.3. PDP Message Format The basic PDP packet consists of a header, followed by a variable number of variable bindings in an ASN.1/BER encoded 'VarBindList', as indicated in Figure 1. +------------+--------------------------------------+ | header | (ASN.1/BER) VarBindList | +------------+--------------------------------------+ [ Figure 1 -- Basic PDP Message Format ] 4.3.1. PDP Header Format The PDP header is a 6 byte header, in network byte order, containing 4 fields, as shown in figure 2: Bierman/McCloghrie Expires March 1998 [Page 5] Draft PTOPO Discovery Protocol and MIB September 1997 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 An optional one's complement of the one's complement checksum of the entire PDP message. An entity generating PDP messages shall set this field to zero if the checksum is omitted. An entity receiving PDP messages must skip the checksum validation if this field is zero, otherwise the checksum is calculated and compared to the value of this field. Messages containing incorrect checksums must be ignored. (See section 4.5.2.3 for a detailed description of checksum processing.) Bierman/McCloghrie Expires March 1998 [Page 6] Draft PTOPO Discovery Protocol and MIB September 1997 4.3.2. PDP PDU Encoding Following the PDP header is an SNMP varbind list encoded in ASN.1/BER [ref. TBD], also referred to as the PDP protocol data unit (PDP-PDU). The invidual MIB instances contained in a PDP PDU are referred to as PDP data elements. The standard PDP data elements, defined in the PDP Data MIB, are encoded as a VarBindList in each PDP message. This data enables a PDP agent to implement the PTOPO MIB for connections terminating on the local chassis. This section defines the ASN.1 syntax specific to the PDP message. Refer to the Protocol Operations specification [RFC1905] for a complete definition of the 'VarBindList' construct. Note that PDP places no constraints on which MIB instances may be included in a particular VarBindList. PDP-PDU DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY FROM SNMPv2-SMI VarBindList FROM SNMPv2-PDU; PDPv1-PDU MODULE-IDENTITY LAST-UPDATED "9709150000Z" 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 Keith McCloghrie Bierman/McCloghrie Expires March 1998 [Page 7] Draft PTOPO Discovery Protocol and MIB September 1997 Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 408-526-5260 kzm@cisco.com" DESCRIPTION "The definition module for version 1 of the PTOPO Discovery Protocol PDU syntax." ::= { experimental xx } PDP-PDU ::= SEQUENCE { pdp-variable-bindings VarBindList } END 4.4. PDP Data MIB This section defines the standard data elements which may be contained in PDP messages. These elements are defined as MIB objects, but are only intended to be encoded into PDP PDUs, and not intended to be instrumented by an SNMP agent. The MIB defines six standard data elements: - Chassis ID - Chassis ID Type - Port ID - Port ID Type - Management Address Type - Management Address 4.4.1. Definitions PDP-DATA-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF Bierman/McCloghrie Expires March 1998 [Page 8] Draft PTOPO Discovery Protocol and MIB September 1997 IANAAddrFamily, PtopoGenAddr, PtopoChassisIdType, PtopoChassisId, PtopoPortIdType, PtopoPortId FROM PTOPO-MIB; pdpDataMIB MODULE-IDENTITY LAST-UPDATED "9709150000Z" 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 Keith McCloghrie Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 408-526-5260 kzm@cisco.com" DESCRIPTION "The MIB module for describing PDP data elements." ::= { experimental xx } pdpDataMIBObjects OBJECT IDENTIFIER ::= { pdpDataMIB 1 } -- MIB groups pdpDataElements OBJECT IDENTIFIER ::= { pdpDataMIBObjects 1 } -- -- *********************************************************** -- -- P D P D A T A E L E M E N T S -- -- *********************************************************** -- Bierman/McCloghrie Expires March 1998 [Page 9] Draft PTOPO Discovery Protocol and MIB September 1997 pdpChassisIdType OBJECT-TYPE SYNTAX PtopoChassisIdType MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the type of chassis component identifier contained in the pdpChassisId object, within a given PDP message." ::= { pdpDataElements 1 } pdpChassisId OBJECT-TYPE SYNTAX PtopoChassisId MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the chassis component of the particular connection endpoint identifier containing the PDP agent transmitting PDP messages. If the chassis ID is unknown for the entry, then this object will contain an empty string." ::= { pdpDataElements 2 } pdpPortIdType OBJECT-TYPE SYNTAX PtopoPortIdType MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the type of port component identifier contained in the pdpPortId object, within a given PDP message." ::= { pdpDataElements 3 } pdpPortId OBJECT-TYPE SYNTAX PtopoPortId MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the port component of a particular connection endpoint identifier, associated with the port chosen for transmission of a given PDP message. For PDP agents contained within repeaters or concentrators, this object may identify the backplane component chosen for transmission of a given PDP message, instead of a specific Bierman/McCloghrie Expires March 1998 [Page 10] Draft PTOPO Discovery Protocol and MIB September 1997 port component (attached to the identified backplane). If the port ID is unknown for the entry, then this object will contain an empty string." ::= { pdpDataElements 4 } pdpMgmtAddrType OBJECT-TYPE SYNTAX IANAAddrFamily MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the type of network address contained in the pdpMgmtAddr object, within a given PDP message." ::= { pdpDataElements 5 } pdpMgmtAddr OBJECT-TYPE SYNTAX PtopoGenAddr MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies a particular network address, associated with an SNMP agent which contains additional information pertaining to the connection endpoint identified in a given PDP message. If a management address is unknown for the endpoint described in a given PDP message, then this object will contain an empty string." ::= { pdpDataElements 6 } -- conformance information pdpDataConformance OBJECT IDENTIFIER ::= { pdpDataMIB 2 } pdpDataCompliances OBJECT IDENTIFIER ::= { pdpDataConformance 1 } pdpDataGroups OBJECT IDENTIFIER ::= { pdpDataConformance 2 } -- compliance statements pdpDataCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Bierman/McCloghrie Expires March 1998 [Page 11] Draft PTOPO Discovery Protocol and MIB September 1997 PTOPO Discovery Protocol." MODULE -- this module MANDATORY-GROUPS { pdpPtopoDataGroup } ::= { pdpDataCompliances 1 } -- MIB groupings pdpPtopoDataGroup OBJECT-GROUP OBJECTS { pdpChassisIdType, pdpChassisId, pdpPortIdType, pdpPortId, pdpMgmtAddrType, pdpMgmtAddr } STATUS current DESCRIPTION "The collection of objects which identify connection endpoint data elements, as used in the PTOPO Discovery Protocol, and represented in the PTOPO MIB. This group is mandatory for agents which implement the PTOPO Discovery Protocol." ::= { pdpDataGroups 1 } END 4.5. Protocol Operation An active PDP Agent must perform the following tasks: - transmit PDP messages - process received PDP messages - maintain an instance of the PDP MIB - maintain an instance of the PTOPO MIB - maintain appropriate ifEntry and/or entPhysicalEntry instances - implement ifAlias and/or entPhysicalAlias MIB objects Bierman/McCloghrie Expires March 1998 [Page 12] Draft PTOPO Discovery Protocol and MIB September 1997 4.5.1. Protocol Initialization Upon system reinitialization, the following tasks are performed by the PDP agent: Non-volatile configuration for the PDP MIB is retrieved if applicable, otherwise appropriate default values are assigned to all PDP configuration variables. If pdpAdminStatus is equal to 'disabled(2)', then PDP initialization is terminated (until such time that the pdpAdminStatus object is set to 'enabled(1)'), otherwise continue. Internal (implementation-specific) data structures are initialized. such that appropriate local physical topology information and PDP transmission parameters are set. 4.5.2. Message Encoding This section does not assume a particular buffering strategy, and such details are omitted. 4.5.2.1. Header Fields The version field is set to one (0x01). The flags field is set to zero (0x00). The time-to-live field is set to the value obtained by the following formula: TTL = min(65535, (pdpMessageTxInterval * pdpMessageTxHoldMultiplier)) The checksum is set to zero (0x0000). If checksums are implemented by the PDP agent, then this field will be set again later. 4.5.2.2. VarBindList Each message must contain one instance of each of the six mandatory PDP-PDU data elements, defined in the PDP Data MIB. Additional data elements may be added as maximum frame size permits. Bierman/McCloghrie Expires March 1998 [Page 13] Draft PTOPO Discovery Protocol and MIB September 1997 ASN.1/BER encoding is defined in [TBD], and is outside the scope of this document. 4.5.2.3. Checksum If checksums are implemented by the PDP agent, then a simple UDP-style checksum is calculated for the PDP message (i.e., concatenated header and ASN.1/BER encoded VarBindList). If the PDP message length is odd, then a zero-valued octet is appended to the PDP message. This padding is done only for PDP checksum calculation, and the additional octet is not transmitted with the PDP message. A 16-bit unsigned integer temporary variable is initialized to zero. Each unsigned 16-bit word of the PDP message is added to the temporary variable, and any overflows are ignored. The ones-complement (i.e., all bits reversed) of the temporary variable is written to the checksum field, in network byte order. 4.5.3. Message Transmission An active PDP agent must transmit a PDP message out each appropriate port, once each message interval, as determined by the pdpMessageTxInterval MIB object. Messages transmitted on repeater devices may be sent for each repeater backplane, once per message interval. Actual transmission intervals should be jittered to prevent synchronization effects. Regarding the transmission of a single PDP message, for the indicated physical interface contained in the local system: The PDP agent checks for the existence of a pdpSuppressEntry for the port. If an entry exists then this port is skipped, otherwise continue. The PDP message is encapsulated as appropriate for the port. The MAC header is filled in with appropriate SA and DA and EtherType fields. (Ignoring LLC/SNAP details). Bierman/McCloghrie Expires March 1998 [Page 14] Draft PTOPO Discovery Protocol and MIB September 1997 The frame is transmitted or passed to a lower layer for transmission. The pdpStatsOutPkts counter is incremented for the indicated local port. 4.5.4. Received Message Processing An active PDP agent must process PDP messages received on each appropriate port, as such messages arrive. The following sections refer to the reception of a single PDP message, for the indicated physical interface contained in the local system: 4.5.4.1. Header Fields The PDP message and the chassis/port indices associated with the receiving port are retrieved. The PDP version and flags field are checked. The version should equal one (0x01) and the flags should equal zero (0x00). If not, the pdpStatsInErrors counter for the receiving port is incremented and processing is terminated; otherwise continue. 4.5.4.2. Checksum If the checksum field is zero then continue, otherwise verify the checksum with the following procedure: The value of checksum is saved in a temporary variable. The checksum field is set to zero. If the PDP message length is odd, then a zero-valued octet is conceptually appended to the PDP message. This padding is done only for PDP checksum calculation. A 16-bit unsigned integer temporary variable is initialized to zero. Each unsigned 16-bit word of the PDP message is added to temporary variable, and any overflows are ignored. Bierman/McCloghrie Expires March 1998 [Page 15] Draft PTOPO Discovery Protocol and MIB September 1997 The ones-complement (i.e., all bits reversed) of this temporary variable is compared to the saved checksum field. If they are different, then the pdpStatsInErrors counter for the receiving port is incremented, and processing is terminated. Otherwise, the checksum is valid, so continue. 4.5.4.3. VarBindList The ASN.1/BER portion of the message is decoded. (Such parsing techniques are beyond the scope of this document.) If this portion of the PDP message is not properly encoded, as defined in the PDP Data MIB, then the pdpStatsInErrors counter for the receiving port is incremented, and processing is terminated; otherwise continue. The list of data elements is examined. The agent must skip and ignore PDU data elements unknown to the agent. If any of the mandatory data elements are missing, then the pdpStatsInErrors counter for the receiving port is incremented, and processing is terminated; otherwise continue. The pdpStatsInPkts counter is incremented for the receiving port. 4.5.4.4. PTOPO MIB Update If the time-to-live field in the PDP message header is zero then execute this interface shutdown procedure, described below. Processing of the PDP message is now complete. If the time-to-live field is non-zero, then the appropriate ptopoConnEntry is found or created, based on the data elements included in the PDP message. If the indicated entry is dynamic (i.e., ptopoConnIsStatic is true), then the current sysUpTime value is stored in the ptopoConnLastVerifyTime field for the entry. If a ptopoConnEntry was added then the ptopoConnTabInserts counter is incremented. If a ptopoConnEntry of one type was replaced with an entry of a different type, then the ptopoConnTabReplaces counter is incremented. If any ptopoConnEntry was added or deleted, or if information other than the ptopoConnLastVerifyTime changed for any entry due to the processing of this PDP message, then the ptopoLastChangeTime object is set with the Bierman/McCloghrie Expires March 1998 [Page 16] Draft PTOPO Discovery Protocol and MIB September 1997 current sysUpTime, and a ptopoConfigChange trap event is generated. (See the PTOPO MIB for information on ptopoConfigChange trap generation.) 4.5.5. Interface Shutdown Procedure A special procedure exists for the case in which a PDP agent knows a particular port is about to become non-operational. 4.5.5.1. PDP Shutdown Transmission In the event an interface, currently configured with PDP message transmission enabled, either becomes disabled for PDP activity, or the interface is administratively disabled, a final PDP message is transmitted with a time to live value of zero (before the interface is disabled). This message is only sent if pdpOperStatus is enabled and no pdpSuppressEntry exists for the indicated local interface. In the event the pdpOperStatus is transitioning to the disabled state, then this shutdown procedure should be executed for all local interfaces. 4.5.5.2. PDP Shutdown Reception After reception of a valid PDP message with a time-to-live value equal to zero, the PDP Agent must remove all information in the PTOPO MIB learned from the particular PDP agent, which is associated with the indicated remote connection endpoint. If any entries are found, the ptopoConnTabDeletes counter is incremented for each deleted entry. This procedure is only followed if pdpOperStatus is in the enabled state and no pdpSuppressEntry exists for the local interface on which the PDP message was received. 5. PTOPO Discovery Protocol MIB This section defines the MIB used to configure PDP agent behavior. Bierman/McCloghrie Expires March 1998 [Page 17] Draft PTOPO Discovery Protocol and MIB September 1997 5.1. Definitions PDP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32 FROM SNMPv2-SMI RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF PhysicalIndex FROM ENTITY-MIB; pdpMIB MODULE-IDENTITY LAST-UPDATED "9707300000Z" 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 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 Bierman/McCloghrie Expires March 1998 [Page 18] Draft PTOPO Discovery Protocol and MIB September 1997 pdpConfig OBJECT IDENTIFIER ::= { pdpMIBObjects 1 } pdpStats OBJECT IDENTIFIER ::= { pdpMIBObjects 2 } PdpPortIdType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of index value used to represent a port component. If an object of this type has a value of 'ifIndexType(1)', then the associated 'port ID' value represents an ifEntry, with the same ifIndex value. If an object of this type has a value of 'entPhysicalIndexType(2)', then the associated 'port ID' value represents an entPhysicalEntry, with the same entPhysicalIndex value." SYNTAX INTEGER { ifIndexType(1), entPhysicalIndexType(2) } -- -- *********************************************************** -- -- P D P C O N F I G -- -- *********************************************************** -- -- The Physical Topology Discovery Protocol Configuration Group pdpAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administratively desired status of the the local PDP 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 Bierman/McCloghrie Expires March 1998 [Page 19] Draft PTOPO Discovery Protocol and MIB September 1997 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 local PDP agent." ::= { pdpConfig 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 PDP 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 } pdpMessageTxHoldMultiplier OBJECT-TYPE SYNTAX Integer32 (2..10) MAX-ACCESS read-write STATUS current DESCRIPTION "The time-to-live value expressed as a multiple of the pdpMessageTxInterval object. The actual time-to-live value used in PDP messages, transmitted on behalf of this PDP agent, can be expressed by the following formula: TTL = min(65535, (pdpMessageTxInterval * pdpMessageTxHoldMultiplier)) For example, if the value of pdpMessageTxInterval is '60', and the value of pdpMessageTxHoldMultiplier is '3', then the value '180' is encoded in the TTL field in the PDP header. Bierman/McCloghrie Expires March 1998 [Page 20] Draft PTOPO Discovery Protocol and MIB September 1997 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 { 3 } ::= { pdpConfig 4 } pdpTxWithChecksum OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the optional checksum field is generated for the PDP messages transmitted by this PDP agent. If this object has the value 'true(1)', then this PDP agent generates a (non-zero) valid PDP checksum for each transmitted PDP message. If this object has the value 'false(2)', then this PDP agent sets the PDP checksum to zero in each transmitted PDP message." ::= { pdpConfig 5 } -- -- PdpSuppressTable: -- Disable PDP activity on individual local ports pdpSuppressTable OBJECT-TYPE SYNTAX SEQUENCE OF PdpSuppressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table controlling PDP message transmission on individual interfaces, ports, or backplanes." ::= { pdpConfig 6 } pdpSuppressEntry OBJECT-TYPE SYNTAX PdpSuppressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "PDP message configuration information for a particular port. The port must be contained in the same chassis as the PDP agent. PDP messages will not be transmitted or received on the indicated port, even if the port is enabled. Bierman/McCloghrie Expires March 1998 [Page 21] Draft PTOPO Discovery Protocol and MIB September 1997 If the agent is capable of storing non-volatile configuration, then each active pdpSuppressEntry must be re-created after a re-initialization of the management system. An agent should store enough information about the associated entPhysicalEntry (e.g., entPhysicalAlias) or ifEntry (e.g. ifAlias), to properly re-create the entry, even if the pdpSuppressChassisId and/or pdpSuppressPortId values change across a system re-initialization." INDEX { pdpSuppressChassisId, pdpSuppressPortIdType, pdpSuppressPortId } ::= { pdpSuppressTable 1 } PdpSuppressEntry ::= SEQUENCE { pdpSuppressChassisId PhysicalIndex, pdpSuppressPortIdType PdpPortIdType, pdpSuppressPortId Integer32, pdpSuppressRowStatus RowStatus } pdpSuppressChassisId OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entPhysicalIndex value used to identify the chassis component associated with this entry. The associated entPhysicalEntry must be active, and the associated entPhysicalClass object must be equal to 'chassis(3)'." ::= { pdpSuppressEntry 1 } pdpSuppressPortIdType OBJECT-TYPE SYNTAX PdpPortIdType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of index value contained in the associated pdpSuppressPortId object." ::= { pdpSuppressEntry 2 } pdpSuppressPortId OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible Bierman/McCloghrie Expires March 1998 [Page 22] Draft PTOPO Discovery Protocol and MIB September 1997 STATUS current DESCRIPTION "The index value used to identify the port component of this entry. The type of index value depends on the pdpSuppressPortIdType value for this entry. If the associated pdpSuppressPortIdType is equal to 'ifIndexType(1)', then this pdpSuppressPortId represents an ifEntry with the same ifIndex value. The associated ifEntry must be active, and represent a physical interface on the local chassis. If the associated pdpSuppressPortIdType is equal to 'entPhysicalIndexType(2)', then this pdpSuppressPortId represents an entPhysicalEntry with the same entPhysicalIndex value. The associated entPhysicalEntry must be active, and the associated entPhysicalClass object must be equal to 'port(10)' or 'backplane(4)'." ::= { pdpSuppressEntry 3 } pdpSuppressRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry." ::= { pdpSuppressEntry 4 } -- -- *********************************************************** -- -- P D P S T A T S -- -- *********************************************************** -- -- PDP Stats Group pdpStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PdpStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing PDP statistics for individual ports. Entries are not required to exist in this table while the Bierman/McCloghrie Expires March 1998 [Page 23] Draft PTOPO Discovery Protocol and MIB September 1997 pdpAdminStatus or pdpOperStatus objects are equal to 'disabled(2)'. Entries are not required to exist in this table if a corresponding entry (with identical index values) exists in the pdpSuppressTable." ::= { pdpStats 1 } pdpStatsEntry OBJECT-TYPE SYNTAX PdpStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "PDP message statistics for a particular port. The port must be contained in the same chassis as the PDP agent." INDEX { pdpStatsChassisId, pdpStatsPortIdType, pdpStatsPortId } ::= { pdpStatsTable 1 } PdpStatsEntry ::= SEQUENCE { pdpStatsChassisId PhysicalIndex, pdpStatsPortIdType PdpPortIdType, pdpStatsPortId Integer32, pdpStatsInPkts Counter32, pdpStatsInErrors Counter32, pdpStatsOutPkts Counter32 } pdpStatsChassisId OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entPhysicalIndex value used to identify the chassis component associated with this entry. The associated entPhysicalEntry must be active, and the associated entPhysicalClass object must be equal to 'chassis(3)'." ::= { pdpStatsEntry 1 } pdpStatsPortIdType OBJECT-TYPE SYNTAX PdpPortIdType MAX-ACCESS not-accessible Bierman/McCloghrie Expires March 1998 [Page 24] Draft PTOPO Discovery Protocol and MIB September 1997 STATUS current DESCRIPTION "The type of index value contained in the associated pdpStatsPortId object." ::= { pdpStatsEntry 2 } pdpStatsPortId OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value used to identify the port component of this entry. The type of index value depends on the pdpStatsPortType value for this entry. If the associated pdpStatsPortIdType is equal to 'ifIndexType(1)', then this pdpStatsPortId represents an ifEntry with the same ifIndex value. The associated ifEntry must be active, and represent a physical interface on the local chassis. If the associated pdpStatsPortIdType is equal to 'entPhysicalIndexType(2)', then this pdpStatsPortId represents an entPhysicalEntry with the same entPhysicalIndex value. The associated entPhysicalEntry must be active, and the associated entPhysicalClass object must be equal to 'port(10)' or 'backplane(4)'." ::= { pdpStatsEntry 3 } pdpStatsInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid PDP messages received by this PDP agent on the indicated port, while this PDP agent is enabled." ::= { pdpStatsEntry 4 } pdpStatsInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid PDP messages received by this PDP agent on the indicated port, while this PDP agent is Bierman/McCloghrie Expires March 1998 [Page 25] Draft PTOPO Discovery Protocol and MIB September 1997 enabled. A PDP message may be invalid for several reasons, including: - invalid MAC header; length or DA fields - invalid PDP header; version or flags fields - invalid PDP VarBindList ASN.1/BER encoding - invalid or missing PDP VarBindList data elements" ::= { pdpStatsEntry 5 } pdpStatsOutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of PDP messages transmitted by this PDP agent on the indicated port." ::= { pdpStatsEntry 6 } -- 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 the PDP MIB." MODULE -- this module MANDATORY-GROUPS { pdpConfigGroup, pdpStatsGroup } ::= { pdpCompliances 1 } -- MIB groupings pdpConfigGroup OBJECT-GROUP OBJECTS { pdpAdminStatus, pdpOperStatus, pdpMessageTxInterval, pdpMessageTxHoldMultiplier, pdpTxWithChecksum, Bierman/McCloghrie Expires March 1998 [Page 26] Draft PTOPO Discovery Protocol and MIB September 1997 pdpSuppressRowStatus } 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 } pdpStatsGroup OBJECT-GROUP OBJECTS { pdpStatsInPkts, pdpStatsInErrors, pdpStatsOutPkts } STATUS current DESCRIPTION "The collection of objects which are used to represent PTOPO Discovery Protocol statistics. This group is mandatory for agents which implement the PTOPO Discovery Protocol." ::= { pdpGroups 2 } END 6. Acknowledgements The PTOPO Discovery Protocol is a product of the IETF PTOPOMIB Working Group. Bierman/McCloghrie Expires March 1998 [Page 27] Draft PTOPO Discovery Protocol and MIB September 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 March 1998 [Page 28] Draft PTOPO Discovery Protocol and MIB September 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 March 1998 [Page 29] Draft PTOPO Discovery Protocol and MIB September 1997 8. Security Considerations This protocol and associated MIB can expose the existence of physical components, MAC layer addresses, and network layer addresses, pertaining to devices within a given network. A network administrator may wish to restrict access to this management information, using SNMP access control mechanisms, and restrict PDP message processing to a particular set of ports, by configuring entries in the pdpSuppressTable. 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 March 1998 [Page 30] Draft PTOPO Discovery Protocol and MIB September 1997 Table of Contents 1 Introduction .................................................... 1 2 The SNMP Network Management Framework ........................... 2 2.1 Object Definitions ............................................ 2 3 Overview ........................................................ 2 3.1 Terms ......................................................... 3 3.2 Persistent Identifiers ........................................ 3 3.3 Relationship to the Physical Topology MIB ..................... 3 3.4 Relationship to Entity MIB .................................... 3 3.5 Relationship to Interfaces MIB ................................ 4 4 PTOPO Discovery Protocol ........................................ 4 4.1 Frame Encapsulation ........................................... 4 4.2 PDP Forwarding ................................................ 5 4.3 PDP Message Format ............................................ 5 4.3.1 PDP Header Format ........................................... 5 4.3.2 PDP PDU Encoding ............................................ 7 4.4 PDP Data MIB .................................................. 8 4.4.1 Definitions ................................................. 8 4.5 Protocol Operation ............................................ 12 4.5.1 Protocol Initialization ..................................... 13 4.5.2 Message Encoding ............................................ 13 4.5.2.1 Header Fields ............................................. 13 4.5.2.2 VarBindList ............................................... 13 4.5.2.3 Checksum .................................................. 14 4.5.3 Message Transmission ........................................ 14 4.5.4 Received Message Processing ................................. 15 4.5.4.1 Header Fields ............................................. 15 4.5.4.2 Checksum .................................................. 15 4.5.4.3 VarBindList ............................................... 16 4.5.4.4 PTOPO MIB Update .......................................... 16 4.5.5 Interface Shutdown Procedure ................................ 17 4.5.5.1 PDP Shutdown Transmission ................................. 17 4.5.5.2 PDP Shutdown Reception .................................... 17 5 PTOPO Discovery Protocol MIB .................................... 17 5.1 Definitions ................................................... 18 6 Acknowledgements ................................................ 27 7 References ...................................................... 28 8 Security Considerations ......................................... 30 9 Authors' Addresses .............................................. 30 Bierman/McCloghrie Expires March 1998 [Page 31]