

                    <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]