Draft                    Physical Topology MIB            September 1997


                    <draft-ietf-ptopomib-mib-01.txt>
                         Physical Topology MIB


                           17 September 1997


                              Andy Bierman
                             Cisco Systems
                           abierman@cisco.com


                            Kendall S. Jones
                              Bay Networks
                         kjones@baynetworks.com





                          Status of this Memo


This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups.  Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).


1.  Introduction

This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community.  In particular, it describes managed objects used for
managing physical topology identification and discovery.





Bierman/Jones              Expires March 1998                   [Page 1]


Draft                    Physical Topology MIB            September 1997


2.  The SNMP Network Management Framework

The SNMP Network Management Framework presently consists of three major
components.  They are:

o    the SMI, described in RFC 1902 [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 means 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.






Bierman/Jones              Expires March 1998                   [Page 2]


Draft                    Physical Topology MIB            September 1997


The scope of the physical topology (PTOPO) mechanism is the
identification of connections between two network ports. Network
addresses of SNMP agents containing management information associated
with each port can also be identified.


3.1.  Background and Concepts

The need to understand the physical relationships between devices in a
network has always been an important aspect of network management.  With
the increasing complexity of multi-segment and multi-media hubs and
switching devices, and management applications that want to identify hot
spots in the network, isolate complex faults (such as configuration
problems) to the physical port, and manage virtual networks (VLANs), the
need for accurate, timely, and system wide physical topology is becoming
more and more critical to maintaining a mission critical network.

Most of today's management platforms do a good job at discovering the
logical topology at the network layer but do not help much in
understanding the actual physical interconnection.  This is due to a
lack of standard topology mechanisms at the physical layer to collect
the physical topology information as well as a standard MIB to return
topology information to the management workstation.

Standard topology mechanisms exist for certain media types (such as
FDDI) and proprietary mechanisms exist for other media such as shared
media Ethernet, switched Ethernet, and Token Ring.  While standardizing
these or other mechanisms for each of these technologies could be a
painstaking task, standardizing a common MIB and a topology framework
that allows co-existence of multiple topology mechanisms to populate
these MIBs can go a long way toward achieving the goal of providing
network-wide physical topology information at the network management
workstation.  The topology framework should specify the core
requirements for topology mechanisms in order to provide the data
necessary to populate the common topology MIB.

These requirements form a set of guidelines to direct the eventual
standardization of a set of topology mechanisms for the various
communication media.  In the meantime, the common MIB will allow
creation of physical topology databases which will allow applications to
provide value added services on top of this rich set of data.









Bierman/Jones              Expires March 1998                   [Page 3]


Draft                    Physical Topology MIB            September 1997


3.2.  Terms

Some terms are used throughout this document:

Physical Topology
     Physical topology represents the topology model for layer 1 of the
     OSI stack - the physical layer.  Physical topology consists of
     identifying the devices on the network and how they are physically
     interconnected.  By definition of this document, physical topology
     does not imply a physical relationship between ports on the same
     device.  Other means exist for determining these relationships
     (e.g., Entity MIB).

Logical Topology
     Logical topology indicates how devices are related based on some
     system level attribute.  Often this is based on the OSI
     communication layer.  For instance, network layer topology, or
     layer 3 topology, uses network layer address hierarchies to
     construct a topological relationship.  Management platforms
     typically present Layer-3-based topology.  This is done by
     'discovering' the IP addresses on a network and then grouping these
     logically by the subnet portion of the address.  Other logical
     views of topology include layer-2 based views based on VLAN
     membership, and higher layer views such as workgroup membership.
     Most higher-layer topology views use network address or user name
     to represent members of the topology space.

Chassis
     A chassis is a physical component which contains other physical
     components.  It is identified by an entPhysicalEntry with an
     entPhysicalClass value of 'chassis(3)' and an
     entPhysicalContainedIn value of zero.  A chassis identifier
     consists of a globally unique DisplayString.

Local Chassis
     The particular chassis containing the SNMP agent implementing the
     PTOPO MIB.

Port
     A port is a physical component which can be connected to another
     port through some medium.  It is identified by an entPhysicalEntry
     with an entPhysicalClass value of 'port(10)'.  A port identifier
     consists of a DisplayString which must be unique within the context
     of the chassis which contains the port.






Bierman/Jones              Expires March 1998                   [Page 4]


Draft                    Physical Topology MIB            September 1997


Connection Endpoint
     A connection endpoint consists of a physical port, which is
     contained within a single physical chassis.

Connection Endpoint Identifier
     A connection endpoint is identified by a globally unique chassis
     identifier and a port identifier unique within the associated
     chassis.

Connection
     A connection consists of two physical ports, and the attached
     physical medium, configured for the purpose of transferring network
     traffic between the ports.  A connection is identified by its
     endpoint identifiers.

Non-local Connection
     A connection for which neither endpoint is located on the local
     chassis.

Cloud
     A cloud identifies a portion of the topology for which insufficient
     information is known to completely infer the interconnection of
     devices that make up that portion of the topology.

3.3.  Functionality Goals

While the framework presented here is focused on physical topology, it
may well be that the topology mechanisms and MIB described could be
extended to include logical topology information as well.  That is not a
focus of this memo at this time, although some consideration may be
given to the framework itself and some notes may be included within this
memo.  They will be clearly identified as work for further study.

The following goals can be described for the physical topology
framework.

  -  Develop a common MIB that represents the physical topology
     information available to any one agent in the network. The MIB
     should provide enough topology information to allow a management
     workstation to navigate across agents to build a complete physical
     topology for an arbitrarily large network.

  -  Provide a set of requirements for topology mechanisms that can
     populate the agent MIBs.  These requirements should allow for many
     different standard and non-standard topology mechanisms to be used





Bierman/Jones              Expires March 1998                   [Page 5]


Draft                    Physical Topology MIB            September 1997


     within a given network, with clear rules describing how these
     mechanisms should interact.

  -  Specify, where appropriate, topology mechanisms for specific media
     types.  Where standard or industry-accepted mechanisms exist,
     indicate how these mechanisms can be used to populate the topology
     MIBs.

  -  Provide a description of the management station procedures to
     navigate among topology agents and gather topology information.

3.4.  Design Goals

Several factors influenced the design of this physical topology
function:

   - Simplicity
     The physical topology discovery function should be as simple as
     possible, exposing only the information needed to identify
     connection endpoints and the SNMP agent(s) associated with each
     connection endpoint.

   - Completeness
     At least one standard discovery protocol capable of supporting the
     standard physical topology MIB must be defined.  Multi-vendor
     interoperability will not be achievable unless a simple and
     extensible discovery protocol is available.

   - No Functional Overlap
     Existing standard MIBs should be utilized whenever possible.
     Physical topology information is tightly coupled to functionality
     found in the Interfaces MIB [RFC1573] and Entity MIB [RFC2037].
     New physical topology MIB objects should not duplicate these MIBs.

   - Identifier Stability
     Connection endpoint identifiers must be persistent (i.e. stable
     across device reboots). Dynamic primary key objects like ifIndex
     and entPhysicalIndex are not suitable for table indices in a
     physical topology MIB that is replicated and distributed throughout
     a managed system.

   - Identifier Flexibility
     Persistent string-based component identifiers should be supported
     from many sources. Chassis identifiers may be found in the Entity
     MIB, and port identifiers may be found in the Interfaces MIB or





Bierman/Jones              Expires March 1998                   [Page 6]


Draft                    Physical Topology MIB            September 1997


     Entity MIB.

   - Partial Topology Support
     Physical topology data for remote components may only be partially
     available to an agent.  An enumerated INTEGER hierarchy of
     component identifier types allows for incomplete physical
     connection identifier information to be substituted with secondary
     information such as unicast source MAC address or network address
     associated with a particular port.  A PTOPO Agent maintains
     information derived from the 'best' source of information for each
     connection.  If a 'better' identifier source is detected, the PTOPO
     entries are updated accordingly.

   - Low Polling Impact
     Physical topology polling should be minimized through techniques
     such as TimeFiltered data tables (from RMON-2 [RFC2021]), and
     last-change notifications.

   - Agent Location Neutrality
     The MIB should allow a single agent to represent information about
     non-local connections and connections terminating on the local
     chassis with the same MIB objects.


4.  Topology Framework

This section describes the physical topology framework in detail.


4.1.  Framework Overview

Several components make up the framework for physical topology.

Devices
     The network devices, along with their physical connectivity, make
     up the physical topology. Some of these devices (but maybe not all)
     provide management agents that report their local physical topology
     information to a manager via the physical topology MIB.  (Note that
     implementation of the PTOPO MIB is required for entities which also
     implement PDP.)

     These devices include communication infrastructure devices, such as
     hubs, switches, and routers, as well as 'leaf' devices such as
     workstations, printers, and servers.  Generally, user data passes
     through infrastructure devices while leaf devices are sources and





Bierman/Jones              Expires March 1998                   [Page 7]


Draft                    Physical Topology MIB            September 1997


     sinks of data.  Both types of devices may implement the physical
     topology MIB, although implementation within leaf devices is much
     less critical.

Topology Mechanisms
     A topology mechanism allows the management agents to collect the
     information required to populate the topology MIB. Many instances
     of a particular topology mechanism may be in use on a given
     network, and many different mechanisms may be employed.  In some
     cases, multiple mechanisms may overlap across part of the physical
     topology.  Agents may need to be configured so that they know which
     mechanism(s) are in use on any given portion of the network.  Most
     topology mechanisms need to be bounded to a subset of the network
     to contain their impact on the network and allow the manager to
     collect topology information for a limited subset of devices.

     Most topology mechanisms are naturally bounded by the media on
     which they run (e.g. FDDI topology mechanism) or by routers in the
     network that intentionally block these mechanisms from crossing
     into other parts of the network.

Local Topology Data and the Local Topology MIB
     Each managed device collects physical topology information from the
     network, based on the topology mechanisms it is configured to use.
     The data represents this agent's view of the physical network and
     may or may not provide enough data to understand the local physical
     topology surrounding this agent.  It may be necessary to gather
     local topology data from a number of agents in order to completely
     understand the local physical topology.  Part of the local topology
     data collected must include the identification of other local
     agents which may contain additional topology information.  The
     definition of 'local' varies based on the topology mechanism or
     mechanisms being used.

Manager Process
     A manager is responsible for querying management agents to obtain
     their local topology information and their knowledge of additional
     local agents.  The manager might need to query some or all local
     agents to build an accurate view of the physical network.

4.1.1.  Topology Mechanisms

A topology mechanism is a means, possibly requiring some sort of
protocol, by which devices determine topology information.  The formal
requirement is that the mechanism should provide sufficient information





Bierman/Jones              Expires March 1998                   [Page 8]


Draft                    Physical Topology MIB            September 1997


such that a manager can accurately determine the physical topology of a
set of devices by querying all of those devices for their local view of
the topology.  In other words, the mechanism may not be robust enough to
allow the manager to accurately determine any part of the network by
querying a single agent - rather it may need to query all agents to
understand the topology.

Topology mechanisms can be active or passive.  Active mechanisms require
a device to send and receive topology protocol packets.  These packets
provide the device ID of the source of the packet and may also indicate
out which port the packet was transmitted.  When receiving these
packets, devices typically are required to identify on which port that
packet was received.

Passive mechanisms take advantage of data on the network to populate the
topology MIB.  By maintaining a list of device identifiers seen on each
port of all devices in a network, it is possible to construct an
accurate physical topology of the network.

A device can act as a boundary device or an intermediate point of a
topology mechanism.  If it is a boundary device, it will prevent active
topology mechanisms from passing through to other ports on that device.
Routers are often boundary devices for active topology mechanisms.
Boundary devices serve a critical role in containing topology mechanisms
within a set of devices.  This limits the size of topology tables
maintained by the agent, reduces calculations required by managers, and
prevents proliferating topology protocols across the network.

It is possible to have ports that support more than one topology
mechanism.  In general this simply allows the port to collect more
robust topology information which should allow the manager to create
more accurate physical topologies.  If the set of devices that support
each mechanism has only minimal overlap, the manager may need to work
with the union of the two sets which could increase the processing
requirement substantially.

4.1.2.  Manager Process

A manager uses the following process to determine the physical topology
of a portion of the network using a common topology mechanism.  Limiting
the manager process to those devices using a common mechanism is not
required, but it does contain the effort and allows the topology to be
built piece by piece in a methodical way.  The process described assumes
that a single topology mechanism is in use across the set of devices
over which physical topology is being determined.  Manager processing





Bierman/Jones              Expires March 1998                   [Page 9]


Draft                    Physical Topology MIB            September 1997


for overlapping topology mechanisms is described subsequently.

  -  a manager first identifies a managed device on the network to begin
     the physical topology collection process

  -  the manager chooses a port to begin the topology determination and
     obtains the topology mechanism and instance for that port

  -  for each port on the device which use the same instance of this
     topology mechanism, the manager obtains the topology data for that
     port and any downstream agent identities.

  -  the manager then queries all downstream agents identified by this
     device and repeats the previous step.

  -  the manager continues walking through the topology until it has no
     other new agents identified and has collected topology data from
     all agents.

  -  the manager then performs topology calculations as required based
     on topology data returned to determine the actual physical topology
     of this collection of devices.

  -  once this portion of the network has been mapped, the manager
     should identify other ports on devices that are running a different
     instance of the topology mechanism or a different topology
     mechanism altogether and repeat the process to map that topology.

  -  following this iterative procedure, the physical topology of an
     arbitrarily large network can be calculated.


5.  Physical Topology MIB

This section describes and defines the Physical Topology MIB.

5.1.  Persistent Identifiers

The PTOPO MIB utilizes non-volatile identifiers to distinguish
individual chassis and port components.  These identifiers are
associated with external objects in order to relate topology information
to the existing managed objects.

In particular, an object from the Entity MIB or Interfaces MIB can be
used as the 'reference-point' for a connection component identifier.





Bierman/Jones              Expires March 1998                  [Page 10]


Draft                    Physical Topology MIB            September 1997


The Physical Topology MIB uses two identifier types pertaining to the
PTOPO MIB:

   - globally unique chassis identifiers.

   - port identifiers; unique only within the chassis which contains the
     port.

Identifiers are stored as OCTET STRINGs, which are limited to 32 bytes
in length, This supports flexible naming conventions and constrains the
non-volatile storage requirements for an agent.

5.2.  Relationship to Entity MIB

The Entity MIB [RFC2037] allows the physical component inventory and
hierarchy to be identified. However, the Entity MIB does not provide
persistent component identifiers, which are required for the PTOPO MIB.
Therefore, an extension to the Entity MIB is defined [ENTITY-EXT] to
provide that feature.  The new table augments the entPhysicalTable, and
adds a read-write 'alias' identifier, similar to the ifAlias MIB object
for interfaces.

For agents implementing the PTOPO MIB, this new object must be used to
represent the chassis identifier. Port identifiers can be based on the
entPhysicalAlias object associated with the port, but only if the port
is not represented as an interface in the ifXTable.

Implementation of the entPhysicalGroup and entPhysicalXGroup is
mandatory for SNMP agents which implement the PTOPO MIB.

5.3.  Relationship to Interfaces MIB

The PTOPO MIB requires a persistent identifier for each port.  The
Interfaces MIB [RFC1573] provides a standard mechanism for managing
network interfaces. Unfortunately, not all ports which may be
represented in the PTOPO MIB are also represented in the Interfaces MIB
(e.g., repeater ports).

For agents which implement the PTOPO MIB, for each port represented in
the Interfaces MIB, the agent must use the associated ifAlias value for
the port identifier.  For each port not represented in the Interfaces
MIB, the associated entPhysicalAlias value must be used for the port
identifier.







Bierman/Jones              Expires March 1998                  [Page 11]


Draft                    Physical Topology MIB            September 1997


5.4.  Relationship to RMON-2 MIB

The RMON-2 MIB [RFC2021] contains address mapping information which can
be integrated with physical topology information. The physical ports
identified in a physical topology MIB can be related to the MAC and
network layer addresses found in the addressMapTable.

5.5.  Relationship to Bridge MIB

The Bridge MIB [RFC1493] contains information which may relate to
physical ports represented in the ptopoConnTable.  Entries in the
dot1dBasePortTable and dot1dStpPortTable can by related to physical
ports represented in the PTOPO MIB.  Also, bridge port MAC addresses may
be used as chassis and port identifiers in some situations.

5.6.  Relationship to Repeater MIB

The Repeater MIB [RFC2108] contains information which may relate to
physical ports represented in the PTOPO MIB. Entries in the
rptrPortTable and rptrMonitorPortTable can by related to physical ports
represented in the ptopoConnTable.  Entries in the rptrInfoTable and
rptrMonTable can be related to repeater backplanes possibly represented
in the ptopoConnTable.

5.7.  MIB Structure

The PTOPO MIB contains three MIB object groups:

  - ptopoData
     Exposes physical topology data learned from discovery protocols
     and/or manual configuration.

  - ptopoGeneral
     Contains general information regarding PTOPO MIB status.

  - ptopoConfig
     Contains configuration variables for the PTOPO MIB agent function.

5.7.1.  ptopoData Group

This group contains a single table to identity physical topology data.

The ptopoConnTable contains information about the connections learned or
configured on behalf of the PTOPO MIB SNMP Agent.






Bierman/Jones              Expires March 1998                  [Page 12]


Draft                    Physical Topology MIB            September 1997


5.7.2.  ptopoGeneral Group

This group contains some scalar objects to report the status of the
PTOPO MIB information currently known to the SNMP Agent. The global last
change time, and table add and delete counters allow an NMS to set
threshold alarms to trigger PTOPO polling.

5.7.3.  ptopoConfig Group

This group contains tables to configure the behavior of the physical
topology function.  The transmission of ptopoLastChange traps can be
configured using the ptopoConfigTrapsEnabled scalar MIB object.

5.8.  Physical Topology MIB Definitions

PTOPO-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32
        FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue
        FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
        FROM SNMPv2-CONF
    TimeFilter
        FROM RMON2-MIB
    PhysicalIndex
        FROM ENTITY-MIB;

ptopoMIB MODULE-IDENTITY
    LAST-UPDATED "9709090000Z"
    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





Bierman/Jones              Expires March 1998                  [Page 13]


Draft                    Physical Topology MIB            September 1997


        Kendall S. Jones
        Bay Networks
        4401 Great America Parkway
        Santa Clara, CA 95134
        408-495-7356
        kjones@baynetworks.com"
    DESCRIPTION
            "The MIB module for physical topology information."
    ::= { experimental xx }

ptopoMIBObjects   OBJECT IDENTIFIER ::= { ptopoMIB 1 }


-- MIB groups
ptopoData         OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 }
ptopoGeneral      OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 }
ptopoConfig       OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 }

-- textual conventions

--
-- IANAAddrFamily TC copied from
--   draft-ietf-disman-framework-00.txt
-- Eventually, it will be included from a general TC module
--
IANAAddrFamily ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "An address family. Values are defined in Assigned Numbers,
            RFC1700. Note that not all these values make sense in all
            contexts where this type is used in this MIB, but they are
            included for completeness."
    REFERENCE
            "Assigned Numbers, [RFC1700], ADDRESS FAMILY NUMBERS"
    SYNTAX      INTEGER {
                    other(0),
                    ipV4(1),
                    ipV6(2),
                    nsap(3),
                    hdlc(4),
                    bbn1822(5),
                    ieee802(6),
                    e163(7),
                    e164(8),
                    f69(9),





Bierman/Jones              Expires March 1998                  [Page 14]


Draft                    Physical Topology MIB            September 1997


                    x121(10),
                    ipx(11),
                    appleTalk(12),
                    decnetIV(13),
                    banyanVines(14),
                    e164WithNsap(15)
                }

PtopoGenAddr ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "The value of an address."
    SYNTAX      OCTET STRING (SIZE (0..20))

PtopoChassisIdType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "This TC describes the source of a chassis identifier.

            The enumeration 'chasIdEntPhysicalAlias(1)' represents a
            chassis identifier based on the value of entPhysicalAlias
            for a chassis component (i.e., an entPhysicalClass value of
            'chassis(3)').

            The enumeration 'chasIdIfAlias(2)' represents a chassis
            identifier based on the value of ifAlias for an interface on
            the containing chassis.

            The enumeration 'chasIdPortEntPhysicalAlias(3)' represents a
            chassis identifier based on the value of entPhysicalAlias
            for a port or backplane component (i.e., entPhysicalClass
            value of 'port(10)' or 'backplane(4)'), within the
            containing chassis.

            The enumeration 'chasIdMacAddress(4)' represents a chassis
            identifier based on the value of a unicast source MAC
            address (encoded in network byte order and IEEE 802.3
            canonical bit order), of a port on the containing chassis.

            The enumeration 'chasIdPtopoGenAddr(5)' represents a chassis
            identifier based on a network address, associated with a
            particular chassis. The encoded address is actually composed
            of two fields.  The first field is a single octet,
            representing the IANAAddrFamily for the specific address
            type, and the second field is the PtopoGenAddr address





Bierman/Jones              Expires March 1998                  [Page 15]


Draft                    Physical Topology MIB            September 1997


            value."
    SYNTAX      INTEGER {
        chasIdEntPhysicalAlias(1),
        chasIdIfAlias(2),
        chasIdPortEntPhysicalAlias(3),
        chasIdMacAddress(4),
        chasIdPtopoGenAddr(5)
    }

PtopoChassisId ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "This TC describes the format of a chassis identifier
            string.  Objects of this type are always used with an
            associated PtopoChassisIdType object, which identifies the
            format of the particular PtopoChassisId object instance.

            If the associated PtopoChassisIdType object has a value of
            'chasIdEntPhysicalAlias(1)', then the octet string
            identifies a particular instance of the entPhysicalAlias
            object for a chassis component (i.e., an entPhysicalClass
            value of 'chassis(3)').

            If the associated PtopoChassisIdType object has a value of
            'chasIdIfAlias(2)', then the octet string identifies a
            particular instance of the ifAlias object for an interface
            on the containing chassis.

            If the associated PtopoChassisIdType object has a value of
            'chasIdPortEntPhysicalAlias(3)', then the octet string
            identifies a particular instance of the entPhysicalAlias
            object for a port or backplane component within the
            containing chassis.

            If the associated PtopoChassisIdType object has a value of
            'chasIdMacAddress(4)', then this string identifies a
            particular unicast source MAC address (encoded in network
            byte order and IEEE 802.3 canonical bit order), of a port on
            the containing chassis.

            If the associated PtopoChassisIdType object has a value of
            'chasIdPtopoGenAddr(5)', then this string identifies a
            particular network address, encoded in network byte order,
            associated with one or more ports on the containing chassis.
            The first octet contains the IANAAddrFamily enumeration





Bierman/Jones              Expires March 1998                  [Page 16]


Draft                    Physical Topology MIB            September 1997


            value for the specific address type, and octets 2 through N
            contain the PtopoGenAddr address value in network byte
            order."
    SYNTAX      OCTET STRING (SIZE (1..32))

PtopoPortIdType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "This TC describes the source of a particular type of port
            identifier used in the PTOPO MIB.

            The enumeration 'portIdIfAlias(1)' represents a port
            identifier based on the ifAlias MIB object.

            The enumeration 'portIdPortEntPhysicalAlias(2)' represents a
            port identifier based on the value of entPhysicalAlias for a
            port or backplane component (i.e., entPhysicalClass value of
            'port(10)' or 'backplane(4)'), within the containing
            chassis.

            The enumeration 'portIdMacAddr(3)' represents a port
            identifier based on a unicast source MAC address, which has
            been detected by the agent and associated with a particular
            port.

            The enumeration 'portIdPtopoGenAddr(4)' represents a port
            identifier based on a network address, detected by the agent
            and associated with a particular port."
    SYNTAX      INTEGER {
        portIdIfAlias(1),
        portIdEntPhysicalAlias(2),
        portIdMacAddr(3),
        portIdPtopoGenAddr(4)
    }

PtopoPortId ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "This TC describes the format of a port identifier string.
            Objects of this type are always used with an associated
            PtopoPortIdType object, which identifies the format of the
            particular PtopoPortId object instance.

            If the associated PtopoPortIdType object has a value of
            'portIdIfAlias(1)', then the octet string identifies a





Bierman/Jones              Expires March 1998                  [Page 17]


Draft                    Physical Topology MIB            September 1997


            particular instance of the ifAlias object.

            If the associated PtopoPortIdType object has a value of
            'portIdEntPhysicalAlias(2)', then the octet string
            identifies a particular instance of the entPhysicalAlias
            object for a port component (i.e., entPhysicalClass value of
            'port(10)').

            If the associated PtopoPortIdType object has a value of
            'portIdMacAddr(3)', then this string identifies a particular
            unicast source MAC address associated with the port.

            If the associated PtopoPortIdType object has a value of
            'portIdPtopoGenAddr(4)', then this string identifies a
            network address associated with the port. The first octet
            contains the IANAAddrFamily enumeration value for the
            specific address type, and octets 2 through N contain the
            PtopoGenAddr address value in network byte order."
    SYNTAX      OCTET STRING (SIZE (1..32))


PtopoAddrSeenState ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "This TC describes the state of address detection for a
            particular type of port identifier used in the PTOPO MIB.

            The enumeration 'not-used(1)' represents an entry for which
            the particular MIB object is not applicable to the remote
            connection endpoint, e.g. ptopoConnRemotePortType equals
            'portIdIfAlias(1)'.

            The enumeration 'unknown(2)' represents an entry for which
            the particular address collection state is not known.

            The enumeration 'one-addr(3)'  represents an entry for which
            exactly one source address (of the type indicated by the
            particular MIB object), has been detected.

            The enumeration 'multi-addr(4)'  represents an entry for
            which more than one source address (of the type indicated by
            the particular MIB object), has been detected."
    SYNTAX      INTEGER {
        not-used(1),
        unknown(2),





Bierman/Jones              Expires March 1998                  [Page 18]


Draft                    Physical Topology MIB            September 1997


        one-addr(3),
        multi-addr(4)
    }

--  ***********************************************************
--
--           P T O P O    D A T A     G R O U P
--
--  ***********************************************************

-- Connection Table

ptopoConnTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF PtopoConnEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "This table contains one row per physical network connection
            known to this agent.  The agent may wish to ensure that only
            one ptopoConnEntry is present for each local port, or it may
            choose to maintain multiple ptopoConnEntries for the same
            local port.

            Entries based on lower numbered identifier types are
            preferred over higher numbered identifier types, i.e., lower
            values of the ptopoConnRemoteChassisType and
            ptopoConnRemotePortType objects."
    ::= { ptopoData 1 }


ptopoConnEntry       OBJECT-TYPE
    SYNTAX      PtopoConnEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "Information about a particular physical network connection.
            Entries may be created and deleted in this table, either
            manually or by the agent, if a physical topology discovery
            process is active."
    INDEX   {
        ptopoConnTimeMark,
        ptopoConnLocalChassis,
        ptopoConnLocalPort,
        ptopoConnIndex
    }





Bierman/Jones              Expires March 1998                  [Page 19]


Draft                    Physical Topology MIB            September 1997


    ::= { ptopoConnTable 1 }

PtopoConnEntry ::= SEQUENCE {
      ptopoConnTimeMark            TimeFilter,
      ptopoConnLocalChassis        PhysicalIndex,
      ptopoConnLocalPort           PhysicalIndex,
      ptopoConnIndex               Integer32,
      ptopoConnRemoteChassisType   PtopoChassisIdType,
      ptopoConnRemoteChassis       PtopoChassisId,
      ptopoConnRemotePortType      PtopoPortIdType,
      ptopoConnRemotePort          PtopoPortId,
      ptopoConnDiscAlgorithm       AutonomousType,
      ptopoConnAgentNetAddrType    IANAAddrFamily,
      ptopoConnAgentNetAddr        PtopoGenAddr,
      ptopoConnMultiMacSASeen      PtopoAddrSeenState,
      ptopoConnMultiNetSASeen      PtopoAddrSeenState,
      ptopoConnIsStatic            TruthValue,
      ptopoConnLastVerifyTime      TimeStamp,
      ptopoConnRowStatus           RowStatus
}

ptopoConnTimeMark  OBJECT-TYPE
    SYNTAX      TimeFilter
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "A TimeFilter for this entry.  See the TimeFilter textual
            convention in RFC 2021 to see how this works."
    ::= { ptopoConnEntry 1 }

ptopoConnLocalChassis  OBJECT-TYPE
    SYNTAX      PhysicalIndex
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "The entPhysicalIndex value used to identify the chassis
            component associated with the local connection endpoint."
    ::= { ptopoConnEntry 2 }

ptopoConnLocalPort     OBJECT-TYPE
    SYNTAX      PhysicalIndex
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "The entPhysicalIndex value used to identify the port





Bierman/Jones              Expires March 1998                  [Page 20]


Draft                    Physical Topology MIB            September 1997


            component associated with the local connection endpoint."
    ::= { ptopoConnEntry 3 }

ptopoConnIndex    OBJECT-TYPE
    SYNTAX      Integer32  (1..2147483647)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "This object represents an arbitrary local integer value
            used by this agent to identify a particular connection
            instance, unique only for the indicated local connection
            endpoint.

            [ed. WG must decide on index re-use issue; Only one of the
            following two paragraphs will remain.]

            A particular ptopoConnIndex value may be reused in the event
            an entry is aged out and later re-learned with the same
            remote chassis and port identifiers.

            [ed. - OR]

            A particular ptopoConnIndex value may only be used once for
            a given (ptopoConnLocalChassis, ptopoConnLocalPort) pair,
            since the last reinitialization of the PTOPO agent."
    ::= { ptopoConnEntry 4 }

ptopoConnRemoteChassisType  OBJECT-TYPE
    SYNTAX      PtopoChassisIdType
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "The type of encoding used to identify the chassis
            associated with the remote connection endpoint.

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 5 }

ptopoConnRemoteChassis  OBJECT-TYPE
    SYNTAX      PtopoChassisId
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "The string value used to identify the chassis component





Bierman/Jones              Expires March 1998                  [Page 21]


Draft                    Physical Topology MIB            September 1997


            associated with the remote connection endpoint.

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 6 }

ptopoConnRemotePortType  OBJECT-TYPE
    SYNTAX      PtopoPortIdType
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "The type of port identifier encoding used in the associated
            'ptopoConnRemotePort' object.

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 7 }

ptopoConnRemotePort  OBJECT-TYPE
    SYNTAX      PtopoPortId
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "The string value used to identify the port component
            associated with the remote connection endpoint.

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 8 }

ptopoConnDiscAlgorithm OBJECT-TYPE
    SYNTAX      AutonomousType
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "An indication of the algorithm used to discover the
            information contained in this conceptual row.

            A value of ptopoDiscoveryPDP indicates this entry was
            configured using the PTOPO Discovery Protocol.

            A value of ptopoDiscoveryLocal indicates this entry was
            configured by the local agent, without use of a discovery
            protocol.






Bierman/Jones              Expires March 1998                  [Page 22]


Draft                    Physical Topology MIB            September 1997


            A value of { 0 0 } indicates this entry was created manually
            by an NMS via the associated RowStatus object. "
    ::= { ptopoConnEntry 9 }

ptopoConnAgentNetAddrType  OBJECT-TYPE
    SYNTAX      IANAAddrFamily
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "This network address type of the associated
            ptopoConnNetAddr object, unless that object contains a zero
            length string.  In such a case, an NMS application should
            ignore any returned value for this object.

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 10 }

ptopoConnAgentNetAddr  OBJECT-TYPE
    SYNTAX      PtopoGenAddr
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "This object identifies a network address which may be used
            to reach an SNMP agent entity containing information for the
            chassis and port components represented by the associated
            'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects.
            If no such address is known, then this object shall contain
            an empty string.

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 11 }

ptopoConnMultiMacSASeen  OBJECT-TYPE
    SYNTAX      PtopoAddrSeenState
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "This object indicates if multiple unicast source MAC
            addresses have been detected by the agent from the remote
            connection endpoint, since the creation of this entry.

            If this entry has an associated ptopoConnRemoteChassisType
            and/or ptopoConnRemotePortType value other than





Bierman/Jones              Expires March 1998                  [Page 23]


Draft                    Physical Topology MIB            September 1997


            'portIdMacAddr(3)', then the value 'not-used(1)' is
            returned.

            Otherwise, one of the following conditions must be true:

            If the agent has not yet detected any unicast source MAC
            addresses from the remote port, then the value 'unknown(2)'
            is returned.

            If the agent has detected exactly one unicast source MAC
            address from the remote port, then the value 'one-addr(3)'
            is returned.

            If the agent has detected more than one unicast source MAC
            address from the remote port, then the value 'multi-addr(4)'
            is returned."
    ::= { ptopoConnEntry 12 }

ptopoConnMultiNetSASeen  OBJECT-TYPE
    SYNTAX      PtopoAddrSeenState
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "This object indicates if multiple network layer source
            addresses have been detected by the agent from the remote
            connection endpoint, since the creation of this entry.

            If this entry has an associated ptopoConnRemoteChassisType
            or ptopoConnRemotePortType value other than
            'portIdGenAddr(4)' then the value 'not-used(1)' is returned.

            Otherwise, one of the following conditions must be true:

            If the agent has not yet detected any network source
            addresses of the appropriate type from the remote port, then
            the value 'unknown(2)' is returned.

            If the agent has detected exactly one network source address
            of the appropriate type from the remote port, then the value
            'one-addr(3)' is returned.

            If the agent has detected more than one network source
            address (of the same appropriate type) from the remote port,
            this the value 'multi-addr(4)' is returned."
    ::= { ptopoConnEntry 13 }





Bierman/Jones              Expires March 1998                  [Page 24]


Draft                    Physical Topology MIB            September 1997


ptopoConnIsStatic  OBJECT-TYPE
    SYNTAX      TruthValue
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "This object identifies static ptopoConnEntries. If this
            object has the value 'true(1)', then this entry is not
            subject to any age-out mechanisms implemented by the agent.

            If this object has the value 'false(2)', then this entry is
            subject to all age-out mechanisms implemented by the agent.

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    DEFVAL { false }
    ::= { ptopoConnEntry 14 }

ptopoConnLastVerifyTime  OBJECT-TYPE
    SYNTAX      TimeStamp
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "If the associated value of ptopoConnIsStatic is equal to
            'false(2)', then this object contains the value of sysUpTime
            at the time the conceptual row was last verified by the
            agent, e.g. via reception of a PDP message pertaining to the
            associated remote chassis and port.

            If the associated value of ptopoConnIsStatic is equal to
            'true(1)', then this object shall contain the value of
            sysUpTime at the time this entry was last activated (i.e.,
            ptopoConnRowStatus set to 'active(1)')."
    ::= { ptopoConnEntry 15 }

ptopoConnRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "The status of this conceptual row."
    ::= { ptopoConnEntry 16 }


--  ***********************************************************
--





Bierman/Jones              Expires March 1998                  [Page 25]


Draft                    Physical Topology MIB            September 1997


--           P T O P O    G E N E R A L     G R O U P
--
--  ***********************************************************

-- last change time stamp for the whole MIB

ptopoLastChangeTime OBJECT-TYPE
    SYNTAX      TimeStamp
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The value of sysUpTime at the time a conceptual row is
            created, modified, or deleted in the ptopoConnTable.

            An NMS can use this object to reduce polling of the
            ptopoData group objects."
    ::= { ptopoGeneral 1 }

ptopoConnTabInserts OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The number of times an entry has been inserted into the
            ptopoConnTable."
    ::= { ptopoGeneral 2 }

ptopoConnTabDeletes OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The number of times an entry has been deleted from the
            ptopoConnTable."
    ::= { ptopoGeneral 3 }


ptopoConnTabDrops OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The number of times an entry would have been added to the
            ptopoConnTable, (e.g., via information learned from PDP),
            but was not because of insufficient resources."





Bierman/Jones              Expires March 1998                  [Page 26]


Draft                    Physical Topology MIB            September 1997


    ::= { ptopoGeneral 4 }

ptopoConnTabReplaces OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The number of times an entry for a particular connection
            has been replaced with an entry for the same local port, but
            different values for any of the following objects:
                - ptopoConnRemoteChassisType
                - ptopoConnRemoteChassis
                - ptopoConnRemotePortType
                - ptopoConnRemotePort"
    ::= { ptopoGeneral 5 }

ptopoConnTabAgeouts OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The number of times an entry has been deleted from the
            ptopoConnTable because the information timeliness interval
            for that entry has expired."
    ::= { ptopoGeneral 6 }



--  ***********************************************************
--
--           P T O P O    C O N F I G     G R O U P
--
--  ***********************************************************

ptopoConfigTrapsEnabled OBJECT-TYPE
    SYNTAX      TruthValue
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            "This object controls the transmission of PTOPO traps.

            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."





Bierman/Jones              Expires March 1998                  [Page 27]


Draft                    Physical Topology MIB            September 1997


    DEFVAL { false }
    ::= { ptopoConfig 1 }

ptopoConfigMaxHoldTime OBJECT-TYPE
    SYNTAX      Integer32 (1..2147483647)
    UNITS       "seconds"
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            "This object specifies the desired time interval for which
            an agent will maintain dynamic ptopoConnEntries.

            After the specified number of seconds since the last time an
            entry was verified, in the absence of new verification
            (e.g., receipt of a PDP message), the agent shall remove the
            entry.  Note that entries may not always be removed
            immediately, but may possibly be removed at periodic garbage
            collection intervals.

            This object only affects dynamic ptopoConnEntries, i.e.  for
            which ptopoConnIsStatic equals 'false(2)'. Static entries
            are not aged out.

            Note that dynamic ptopoConnEntries may also be removed by
            the agent due to the expired timeliness of learned topology
            information (e.g., timeliness interval for a remote port
            expires).  The actual age-out interval for a given entry is
            defined by the following formula:

              age-out-time =
                min(ptopoConfigMaxHoldTime, <entry-specific hold-time>)

            where <entry-specific hold-time> is determined by the
            discovery algorithm, and may be different for each entry.
            For entries discovered with PDP, this is the particular
            'time-to-live' value from the most recent PDP message
            associated with the entry."
    DEFVAL { 300 }
    ::= { ptopoConfig 2 }


-- PTOPO MIB Trap Definitions
ptopoMIBTraps       OBJECT IDENTIFIER ::= { ptopoMIB 2 }
ptopoMIBTrapPrefix  OBJECT IDENTIFIER ::= { ptopoMIBTraps 0 }






Bierman/Jones              Expires March 1998                  [Page 28]


Draft                    Physical Topology MIB            September 1997


ptopoConfigChange NOTIFICATION-TYPE
    OBJECTS       {
        ptopoConnTabInserts,
        ptopoConnTabDeletes,
        ptopoConnTabDrops,
        ptopoConnTabReplaces,
        ptopoConnTabAgeouts
    }
    STATUS        current
    DESCRIPTION
            "A ptopoConfigChange trap is sent when the value of
            ptopoLastChangeTime changes. It can be utilized by an NMS to
            trigger physical topology table maintenance polls.

            An agent must not generate more than one ptopoConfigChange
            trap-event in a five second period, where a 'trap-event' is
            the transmission of a single trap PDU to a list of trap
            destinations.  If additional configuration changes occur
            within the five second throttling period, then these trap-
            events should be suppressed by the agent. An NMS should
            periodically check the value of ptopoLastChangeTime to
            detect any missed ptopoConfigChange trap-events, e.g. due to
            throttling or transmission loss."
   ::= { ptopoMIBTrapPrefix 1 }


-- PTOPO Registration Points

ptopoRegistrationPoints  OBJECT IDENTIFIER ::= { ptopoMIB 3 }


-- values used with ptopoConnDiscAlgorithm object
ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= { ptopoRegistrationPoints 1 }
ptopoDiscoveryPDP        OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 1 }
ptopoDiscoveryLocal      OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 2 }


-- conformance information
ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 }

ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 }
ptopoGroups      OBJECT IDENTIFIER ::= { ptopoConformance 2 }

-- compliance statements






Bierman/Jones              Expires March 1998                  [Page 29]


Draft                    Physical Topology MIB            September 1997


ptopoCompliance MODULE-COMPLIANCE
   STATUS  current
    DESCRIPTION
            "The compliance statement for SNMP entities which implement
            the PTOPO MIB."
    MODULE  -- this module
        MANDATORY-GROUPS {
                ptopoDataGroup,
                ptopoGeneralGroup,
                ptopoConfigGroup,
                ptopoNotificationsGroup
        }
    ::= { ptopoCompliances 1 }

-- MIB groupings

ptopoDataGroup   OBJECT-GROUP
    OBJECTS {
        ptopoConnRemoteChassisType,
        ptopoConnRemoteChassis,
        ptopoConnRemotePortType,
        ptopoConnRemotePort,
        ptopoConnDiscAlgorithm,
        ptopoConnAgentNetAddrType,
        ptopoConnAgentNetAddr,
        ptopoConnMultiMacSASeen,
        ptopoConnMultiNetSASeen,
        ptopoConnIsStatic,
        ptopoConnLastVerifyTime,
        ptopoConnRowStatus
    }
    STATUS  current
    DESCRIPTION
            "The collection of objects which are used to represent
            physical topology information for which a single agent
            provides management information.

            This group is mandatory for all implementations of the PTOPO
            MIB."
    ::= { ptopoGroups 1 }

ptopoGeneralGroup    OBJECT-GROUP
    OBJECTS {
        ptopoLastChangeTime,
        ptopoConnTabInserts,





Bierman/Jones              Expires March 1998                  [Page 30]


Draft                    Physical Topology MIB            September 1997


        ptopoConnTabDeletes,
        ptopoConnTabDrops,
        ptopoConnTabReplaces,
        ptopoConnTabAgeouts
    }
    STATUS  current
    DESCRIPTION
            "The collection of objects which are used to report the
            general status of the PTOPO MIB implementation.

            This group is mandatory for all agents which implement the
            PTOPO MIB."
    ::= { ptopoGroups 2 }

ptopoConfigGroup    OBJECT-GROUP
    OBJECTS {
        ptopoConfigTrapsEnabled,
        ptopoConfigMaxHoldTime
    }
    STATUS  current
    DESCRIPTION
            "The collection of objects which are used to configure the
            PTOPO MIB implementation behavior.

            This group is mandatory for agents which implement the PTOPO
            MIB."
    ::= { ptopoGroups 3 }


ptopoNotificationsGroup NOTIFICATION-GROUP
    NOTIFICATIONS {
        ptopoConfigChange
    }
    STATUS        current
    DESCRIPTION
            "The collection of notifications used to indicate PTOPO MIB
            data consistency and general status information.

            This group is mandatory for agents which implement the PTOPO
            MIB."
    ::= { ptopoGroups 4 }

END







Bierman/Jones              Expires March 1998                  [Page 31]


Draft                    Physical Topology MIB            September 1997


6.  References

[ENTITY-EXT]
     Bierman, A., McCloghrie, K., "Entity MIB Extensions for Persistent
     Component Identification", draft-bierman-entmib-compid-00.txt,
     Cisco Systems, 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.

[RFC1493]
     E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie, "Definitions
     of Managed Objects for Bridges", RFC 1493, Cisco Systems, Inc.,
     Digital Equipment Corporation, Hughes LAN Systems, Inc., July 1993.

[RFC1573]
     McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution",
     RFC 1573, Hughes LAN Systems, FTP Software, January 1994.

[RFC1700]
     Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
     USC/Information Sciences Institute, October 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





Bierman/Jones              Expires March 1998                  [Page 32]


Draft                    Physical Topology MIB            September 1997


     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
     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[RFC2021]
     S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021,
     International Network Services, January 1997.

[RFC2037]
     McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037,
     Cisco Systems, October 1996.

[RFC2108]
     K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, "Definitions
     of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2",
     RFC 2108, 3Com Corporation, Madge Networks (Israel) Ltd., Coloma
     Communications, Cisco Systems Inc., February 1997.






























Bierman/Jones              Expires March 1998                  [Page 33]


Draft                    Physical Topology MIB            September 1997


7.  Security Considerations

This MIB exposes information about the physical connectivity for a
particular portion of a network. A network administrator may wish to
restrict SNMP access to such information, but such agent security
configuration is beyond the scope of this document.

A network administrator may also wish to inhibit transmission of any
ptopoConfigChange traps by setting the ptopoConfigTrapsEnabled object to
'false(2)'.


8.  Authors' Addresses

     Andy Bierman
     Cisco Systems
     170 West Tasman Drive
     San Jose, CA 95134
     Phone: 408-527-3711
     Email: abierman@cisco.com

     Kendall S. Jones
     Bay Networks
     4401 Great America Parkway
     Santa Clara, CA 95134
     Phone: 408-495-7356
     Email: kjones@baynetworks.com























Bierman/Jones              Expires March 1998                  [Page 34]


Draft                    Physical Topology 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 Background and Concepts .......................................    3
3.2 Terms .........................................................    4
3.3 Functionality Goals ...........................................    5
3.4 Design Goals ..................................................    6
4 Topology Framework ..............................................    7
4.1 Framework Overview ............................................    7
4.1.1 Topology Mechanisms .........................................    8
4.1.2 Manager Process .............................................    9
5 Physical Topology MIB ...........................................   10
5.1 Persistent Identifiers ........................................   10
5.2 Relationship to Entity MIB ....................................   11
5.3 Relationship to Interfaces MIB ................................   11
5.4 Relationship to RMON-2 MIB ....................................   12
5.5 Relationship to Bridge MIB ....................................   12
5.6 Relationship to Repeater MIB ..................................   12
5.7 MIB Structure .................................................   12
5.7.1 ptopoData Group .............................................   12
5.7.2 ptopoGeneral Group ..........................................   13
5.7.3 ptopoConfig Group ...........................................   13
5.8 Physical Topology MIB Definitions .............................   13
6 References ......................................................   32
7 Security Considerations .........................................   34
8 Authors' Addresses ..............................................   34




















Bierman/Jones              Expires March 1998                  [Page 35]