home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-ptopomib-mib-01.txt < prev    next >
Text File  |  1997-09-17  |  66KB  |  2,066 lines
  1.  
  2.  
  3.  
  4.  
  5. Draft                    Physical Topology MIB            September 1997
  6.  
  7.  
  8.                     <draft-ietf-ptopomib-mib-01.txt>
  9.                          Physical Topology MIB
  10.  
  11.  
  12.                            17 September 1997
  13.  
  14.  
  15.                               Andy Bierman
  16.                              Cisco Systems
  17.                            abierman@cisco.com
  18.  
  19.  
  20.                             Kendall S. Jones
  21.                               Bay Networks
  22.                          kjones@baynetworks.com
  23.  
  24.  
  25.  
  26.  
  27.  
  28.                           Status of this Memo
  29.  
  30.  
  31. This document is an Internet-Draft.  Internet-Drafts are working
  32. documents of the Internet Engineering Task Force (IETF), its areas, and
  33. its working groups.  Note that other groups may also distribute working
  34. documents as Internet-Drafts.
  35.  
  36. Internet-Drafts are draft documents valid for a maximum of six months
  37. and may be updated, replaced, or obsoleted by other documents at any
  38. time.  It is inappropriate to use Internet- Drafts as reference material
  39. or to cite them other than as ``work in progress.''
  40.  
  41. To learn the current status of any Internet-Draft, please check the
  42. ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
  43. Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  44. ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  45.  
  46.  
  47. 1.  Introduction
  48.  
  49. This memo defines an experimental portion of the Management Information
  50. Base (MIB) for use with network management protocols in the Internet
  51. community.  In particular, it describes managed objects used for
  52. managing physical topology identification and discovery.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Bierman/Jones              Expires March 1998                   [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Draft                    Physical Topology MIB            September 1997
  65.  
  66.  
  67. 2.  The SNMP Network Management Framework
  68.  
  69. The SNMP Network Management Framework presently consists of three major
  70. components.  They are:
  71.  
  72. o    the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for
  73.      describing and naming objects for the purpose of management.
  74.  
  75. o    the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed
  76.      objects for the Internet suite of protocols.
  77.  
  78. o    the protocol, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], - the
  79.      protocol for accessing managed information.
  80.  
  81. Textual conventions are defined in RFC 1903 [RFC1903], and conformance
  82. statements are defined in RFC 1904 [RFC1904].
  83.  
  84. The Framework permits new objects to be defined for the purpose of
  85. experimentation and evaluation.
  86.  
  87. This memo specifies a MIB module that is compliant to the SNMPv2 SMI.  A
  88. semantically identical MIB conforming to the SNMPv1 SMI can be produced
  89. through the appropriate translation.
  90.  
  91.  
  92. 2.1.  Object Definitions
  93.  
  94. Managed objects are accessed via a virtual information store, termed the
  95. Management Information Base or MIB.  Objects in the MIB are defined
  96. using the subset of Abstract Syntax Notation One (ASN.1) defined in the
  97. SMI.  In particular, each object type is named by an OBJECT IDENTIFIER,
  98. an administratively assigned name.  The object type together with an
  99. object instance serves to uniquely identify a specific instantiation of
  100. the object.  For human convenience, we often use a textual string,
  101. termed the descriptor, to refer to the object type.
  102.  
  103.  
  104. 3.  Overview
  105.  
  106. There is a need for a standardized means of representing the physical
  107. network connections pertaining to a given management domain.  A
  108. standardized discovery mechanism is also required to increase the
  109. likelihood of multi-vendor interoperability of such physical topology
  110. management information.
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Bierman/Jones              Expires March 1998                   [Page 2]
  118.  
  119.  
  120.  
  121.  
  122.  
  123. Draft                    Physical Topology MIB            September 1997
  124.  
  125.  
  126. The scope of the physical topology (PTOPO) mechanism is the
  127. identification of connections between two network ports. Network
  128. addresses of SNMP agents containing management information associated
  129. with each port can also be identified.
  130.  
  131.  
  132. 3.1.  Background and Concepts
  133.  
  134. The need to understand the physical relationships between devices in a
  135. network has always been an important aspect of network management.  With
  136. the increasing complexity of multi-segment and multi-media hubs and
  137. switching devices, and management applications that want to identify hot
  138. spots in the network, isolate complex faults (such as configuration
  139. problems) to the physical port, and manage virtual networks (VLANs), the
  140. need for accurate, timely, and system wide physical topology is becoming
  141. more and more critical to maintaining a mission critical network.
  142.  
  143. Most of today's management platforms do a good job at discovering the
  144. logical topology at the network layer but do not help much in
  145. understanding the actual physical interconnection.  This is due to a
  146. lack of standard topology mechanisms at the physical layer to collect
  147. the physical topology information as well as a standard MIB to return
  148. topology information to the management workstation.
  149.  
  150. Standard topology mechanisms exist for certain media types (such as
  151. FDDI) and proprietary mechanisms exist for other media such as shared
  152. media Ethernet, switched Ethernet, and Token Ring.  While standardizing
  153. these or other mechanisms for each of these technologies could be a
  154. painstaking task, standardizing a common MIB and a topology framework
  155. that allows co-existence of multiple topology mechanisms to populate
  156. these MIBs can go a long way toward achieving the goal of providing
  157. network-wide physical topology information at the network management
  158. workstation.  The topology framework should specify the core
  159. requirements for topology mechanisms in order to provide the data
  160. necessary to populate the common topology MIB.
  161.  
  162. These requirements form a set of guidelines to direct the eventual
  163. standardization of a set of topology mechanisms for the various
  164. communication media.  In the meantime, the common MIB will allow
  165. creation of physical topology databases which will allow applications to
  166. provide value added services on top of this rich set of data.
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176. Bierman/Jones              Expires March 1998                   [Page 3]
  177.  
  178.  
  179.  
  180.  
  181.  
  182. Draft                    Physical Topology MIB            September 1997
  183.  
  184.  
  185. 3.2.  Terms
  186.  
  187. Some terms are used throughout this document:
  188.  
  189. Physical Topology
  190.      Physical topology represents the topology model for layer 1 of the
  191.      OSI stack - the physical layer.  Physical topology consists of
  192.      identifying the devices on the network and how they are physically
  193.      interconnected.  By definition of this document, physical topology
  194.      does not imply a physical relationship between ports on the same
  195.      device.  Other means exist for determining these relationships
  196.      (e.g., Entity MIB).
  197.  
  198. Logical Topology
  199.      Logical topology indicates how devices are related based on some
  200.      system level attribute.  Often this is based on the OSI
  201.      communication layer.  For instance, network layer topology, or
  202.      layer 3 topology, uses network layer address hierarchies to
  203.      construct a topological relationship.  Management platforms
  204.      typically present Layer-3-based topology.  This is done by
  205.      'discovering' the IP addresses on a network and then grouping these
  206.      logically by the subnet portion of the address.  Other logical
  207.      views of topology include layer-2 based views based on VLAN
  208.      membership, and higher layer views such as workgroup membership.
  209.      Most higher-layer topology views use network address or user name
  210.      to represent members of the topology space.
  211.  
  212. Chassis
  213.      A chassis is a physical component which contains other physical
  214.      components.  It is identified by an entPhysicalEntry with an
  215.      entPhysicalClass value of 'chassis(3)' and an
  216.      entPhysicalContainedIn value of zero.  A chassis identifier
  217.      consists of a globally unique DisplayString.
  218.  
  219. Local Chassis
  220.      The particular chassis containing the SNMP agent implementing the
  221.      PTOPO MIB.
  222.  
  223. Port
  224.      A port is a physical component which can be connected to another
  225.      port through some medium.  It is identified by an entPhysicalEntry
  226.      with an entPhysicalClass value of 'port(10)'.  A port identifier
  227.      consists of a DisplayString which must be unique within the context
  228.      of the chassis which contains the port.
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235. Bierman/Jones              Expires March 1998                   [Page 4]
  236.  
  237.  
  238.  
  239.  
  240.  
  241. Draft                    Physical Topology MIB            September 1997
  242.  
  243.  
  244. Connection Endpoint
  245.      A connection endpoint consists of a physical port, which is
  246.      contained within a single physical chassis.
  247.  
  248. Connection Endpoint Identifier
  249.      A connection endpoint is identified by a globally unique chassis
  250.      identifier and a port identifier unique within the associated
  251.      chassis.
  252.  
  253. Connection
  254.      A connection consists of two physical ports, and the attached
  255.      physical medium, configured for the purpose of transferring network
  256.      traffic between the ports.  A connection is identified by its
  257.      endpoint identifiers.
  258.  
  259. Non-local Connection
  260.      A connection for which neither endpoint is located on the local
  261.      chassis.
  262.  
  263. Cloud
  264.      A cloud identifies a portion of the topology for which insufficient
  265.      information is known to completely infer the interconnection of
  266.      devices that make up that portion of the topology.
  267.  
  268. 3.3.  Functionality Goals
  269.  
  270. While the framework presented here is focused on physical topology, it
  271. may well be that the topology mechanisms and MIB described could be
  272. extended to include logical topology information as well.  That is not a
  273. focus of this memo at this time, although some consideration may be
  274. given to the framework itself and some notes may be included within this
  275. memo.  They will be clearly identified as work for further study.
  276.  
  277. The following goals can be described for the physical topology
  278. framework.
  279.  
  280.   -  Develop a common MIB that represents the physical topology
  281.      information available to any one agent in the network. The MIB
  282.      should provide enough topology information to allow a management
  283.      workstation to navigate across agents to build a complete physical
  284.      topology for an arbitrarily large network.
  285.  
  286.   -  Provide a set of requirements for topology mechanisms that can
  287.      populate the agent MIBs.  These requirements should allow for many
  288.      different standard and non-standard topology mechanisms to be used
  289.  
  290.  
  291.  
  292.  
  293.  
  294. Bierman/Jones              Expires March 1998                   [Page 5]
  295.  
  296.  
  297.  
  298.  
  299.  
  300. Draft                    Physical Topology MIB            September 1997
  301.  
  302.  
  303.      within a given network, with clear rules describing how these
  304.      mechanisms should interact.
  305.  
  306.   -  Specify, where appropriate, topology mechanisms for specific media
  307.      types.  Where standard or industry-accepted mechanisms exist,
  308.      indicate how these mechanisms can be used to populate the topology
  309.      MIBs.
  310.  
  311.   -  Provide a description of the management station procedures to
  312.      navigate among topology agents and gather topology information.
  313.  
  314. 3.4.  Design Goals
  315.  
  316. Several factors influenced the design of this physical topology
  317. function:
  318.  
  319.    - Simplicity
  320.      The physical topology discovery function should be as simple as
  321.      possible, exposing only the information needed to identify
  322.      connection endpoints and the SNMP agent(s) associated with each
  323.      connection endpoint.
  324.  
  325.    - Completeness
  326.      At least one standard discovery protocol capable of supporting the
  327.      standard physical topology MIB must be defined.  Multi-vendor
  328.      interoperability will not be achievable unless a simple and
  329.      extensible discovery protocol is available.
  330.  
  331.    - No Functional Overlap
  332.      Existing standard MIBs should be utilized whenever possible.
  333.      Physical topology information is tightly coupled to functionality
  334.      found in the Interfaces MIB [RFC1573] and Entity MIB [RFC2037].
  335.      New physical topology MIB objects should not duplicate these MIBs.
  336.  
  337.    - Identifier Stability
  338.      Connection endpoint identifiers must be persistent (i.e. stable
  339.      across device reboots). Dynamic primary key objects like ifIndex
  340.      and entPhysicalIndex are not suitable for table indices in a
  341.      physical topology MIB that is replicated and distributed throughout
  342.      a managed system.
  343.  
  344.    - Identifier Flexibility
  345.      Persistent string-based component identifiers should be supported
  346.      from many sources. Chassis identifiers may be found in the Entity
  347.      MIB, and port identifiers may be found in the Interfaces MIB or
  348.  
  349.  
  350.  
  351.  
  352.  
  353. Bierman/Jones              Expires March 1998                   [Page 6]
  354.  
  355.  
  356.  
  357.  
  358.  
  359. Draft                    Physical Topology MIB            September 1997
  360.  
  361.  
  362.      Entity MIB.
  363.  
  364.    - Partial Topology Support
  365.      Physical topology data for remote components may only be partially
  366.      available to an agent.  An enumerated INTEGER hierarchy of
  367.      component identifier types allows for incomplete physical
  368.      connection identifier information to be substituted with secondary
  369.      information such as unicast source MAC address or network address
  370.      associated with a particular port.  A PTOPO Agent maintains
  371.      information derived from the 'best' source of information for each
  372.      connection.  If a 'better' identifier source is detected, the PTOPO
  373.      entries are updated accordingly.
  374.  
  375.    - Low Polling Impact
  376.      Physical topology polling should be minimized through techniques
  377.      such as TimeFiltered data tables (from RMON-2 [RFC2021]), and
  378.      last-change notifications.
  379.  
  380.    - Agent Location Neutrality
  381.      The MIB should allow a single agent to represent information about
  382.      non-local connections and connections terminating on the local
  383.      chassis with the same MIB objects.
  384.  
  385.  
  386. 4.  Topology Framework
  387.  
  388. This section describes the physical topology framework in detail.
  389.  
  390.  
  391. 4.1.  Framework Overview
  392.  
  393. Several components make up the framework for physical topology.
  394.  
  395. Devices
  396.      The network devices, along with their physical connectivity, make
  397.      up the physical topology. Some of these devices (but maybe not all)
  398.      provide management agents that report their local physical topology
  399.      information to a manager via the physical topology MIB.  (Note that
  400.      implementation of the PTOPO MIB is required for entities which also
  401.      implement PDP.)
  402.  
  403.      These devices include communication infrastructure devices, such as
  404.      hubs, switches, and routers, as well as 'leaf' devices such as
  405.      workstations, printers, and servers.  Generally, user data passes
  406.      through infrastructure devices while leaf devices are sources and
  407.  
  408.  
  409.  
  410.  
  411.  
  412. Bierman/Jones              Expires March 1998                   [Page 7]
  413.  
  414.  
  415.  
  416.  
  417.  
  418. Draft                    Physical Topology MIB            September 1997
  419.  
  420.  
  421.      sinks of data.  Both types of devices may implement the physical
  422.      topology MIB, although implementation within leaf devices is much
  423.      less critical.
  424.  
  425. Topology Mechanisms
  426.      A topology mechanism allows the management agents to collect the
  427.      information required to populate the topology MIB. Many instances
  428.      of a particular topology mechanism may be in use on a given
  429.      network, and many different mechanisms may be employed.  In some
  430.      cases, multiple mechanisms may overlap across part of the physical
  431.      topology.  Agents may need to be configured so that they know which
  432.      mechanism(s) are in use on any given portion of the network.  Most
  433.      topology mechanisms need to be bounded to a subset of the network
  434.      to contain their impact on the network and allow the manager to
  435.      collect topology information for a limited subset of devices.
  436.  
  437.      Most topology mechanisms are naturally bounded by the media on
  438.      which they run (e.g. FDDI topology mechanism) or by routers in the
  439.      network that intentionally block these mechanisms from crossing
  440.      into other parts of the network.
  441.  
  442. Local Topology Data and the Local Topology MIB
  443.      Each managed device collects physical topology information from the
  444.      network, based on the topology mechanisms it is configured to use.
  445.      The data represents this agent's view of the physical network and
  446.      may or may not provide enough data to understand the local physical
  447.      topology surrounding this agent.  It may be necessary to gather
  448.      local topology data from a number of agents in order to completely
  449.      understand the local physical topology.  Part of the local topology
  450.      data collected must include the identification of other local
  451.      agents which may contain additional topology information.  The
  452.      definition of 'local' varies based on the topology mechanism or
  453.      mechanisms being used.
  454.  
  455. Manager Process
  456.      A manager is responsible for querying management agents to obtain
  457.      their local topology information and their knowledge of additional
  458.      local agents.  The manager might need to query some or all local
  459.      agents to build an accurate view of the physical network.
  460.  
  461. 4.1.1.  Topology Mechanisms
  462.  
  463. A topology mechanism is a means, possibly requiring some sort of
  464. protocol, by which devices determine topology information.  The formal
  465. requirement is that the mechanism should provide sufficient information
  466.  
  467.  
  468.  
  469.  
  470.  
  471. Bierman/Jones              Expires March 1998                   [Page 8]
  472.  
  473.  
  474.  
  475.  
  476.  
  477. Draft                    Physical Topology MIB            September 1997
  478.  
  479.  
  480. such that a manager can accurately determine the physical topology of a
  481. set of devices by querying all of those devices for their local view of
  482. the topology.  In other words, the mechanism may not be robust enough to
  483. allow the manager to accurately determine any part of the network by
  484. querying a single agent - rather it may need to query all agents to
  485. understand the topology.
  486.  
  487. Topology mechanisms can be active or passive.  Active mechanisms require
  488. a device to send and receive topology protocol packets.  These packets
  489. provide the device ID of the source of the packet and may also indicate
  490. out which port the packet was transmitted.  When receiving these
  491. packets, devices typically are required to identify on which port that
  492. packet was received.
  493.  
  494. Passive mechanisms take advantage of data on the network to populate the
  495. topology MIB.  By maintaining a list of device identifiers seen on each
  496. port of all devices in a network, it is possible to construct an
  497. accurate physical topology of the network.
  498.  
  499. A device can act as a boundary device or an intermediate point of a
  500. topology mechanism.  If it is a boundary device, it will prevent active
  501. topology mechanisms from passing through to other ports on that device.
  502. Routers are often boundary devices for active topology mechanisms.
  503. Boundary devices serve a critical role in containing topology mechanisms
  504. within a set of devices.  This limits the size of topology tables
  505. maintained by the agent, reduces calculations required by managers, and
  506. prevents proliferating topology protocols across the network.
  507.  
  508. It is possible to have ports that support more than one topology
  509. mechanism.  In general this simply allows the port to collect more
  510. robust topology information which should allow the manager to create
  511. more accurate physical topologies.  If the set of devices that support
  512. each mechanism has only minimal overlap, the manager may need to work
  513. with the union of the two sets which could increase the processing
  514. requirement substantially.
  515.  
  516. 4.1.2.  Manager Process
  517.  
  518. A manager uses the following process to determine the physical topology
  519. of a portion of the network using a common topology mechanism.  Limiting
  520. the manager process to those devices using a common mechanism is not
  521. required, but it does contain the effort and allows the topology to be
  522. built piece by piece in a methodical way.  The process described assumes
  523. that a single topology mechanism is in use across the set of devices
  524. over which physical topology is being determined.  Manager processing
  525.  
  526.  
  527.  
  528.  
  529.  
  530. Bierman/Jones              Expires March 1998                   [Page 9]
  531.  
  532.  
  533.  
  534.  
  535.  
  536. Draft                    Physical Topology MIB            September 1997
  537.  
  538.  
  539. for overlapping topology mechanisms is described subsequently.
  540.  
  541.   -  a manager first identifies a managed device on the network to begin
  542.      the physical topology collection process
  543.  
  544.   -  the manager chooses a port to begin the topology determination and
  545.      obtains the topology mechanism and instance for that port
  546.  
  547.   -  for each port on the device which use the same instance of this
  548.      topology mechanism, the manager obtains the topology data for that
  549.      port and any downstream agent identities.
  550.  
  551.   -  the manager then queries all downstream agents identified by this
  552.      device and repeats the previous step.
  553.  
  554.   -  the manager continues walking through the topology until it has no
  555.      other new agents identified and has collected topology data from
  556.      all agents.
  557.  
  558.   -  the manager then performs topology calculations as required based
  559.      on topology data returned to determine the actual physical topology
  560.      of this collection of devices.
  561.  
  562.   -  once this portion of the network has been mapped, the manager
  563.      should identify other ports on devices that are running a different
  564.      instance of the topology mechanism or a different topology
  565.      mechanism altogether and repeat the process to map that topology.
  566.  
  567.   -  following this iterative procedure, the physical topology of an
  568.      arbitrarily large network can be calculated.
  569.  
  570.  
  571. 5.  Physical Topology MIB
  572.  
  573. This section describes and defines the Physical Topology MIB.
  574.  
  575. 5.1.  Persistent Identifiers
  576.  
  577. The PTOPO MIB utilizes non-volatile identifiers to distinguish
  578. individual chassis and port components.  These identifiers are
  579. associated with external objects in order to relate topology information
  580. to the existing managed objects.
  581.  
  582. In particular, an object from the Entity MIB or Interfaces MIB can be
  583. used as the 'reference-point' for a connection component identifier.
  584.  
  585.  
  586.  
  587.  
  588.  
  589. Bierman/Jones              Expires March 1998                  [Page 10]
  590.  
  591.  
  592.  
  593.  
  594.  
  595. Draft                    Physical Topology MIB            September 1997
  596.  
  597.  
  598. The Physical Topology MIB uses two identifier types pertaining to the
  599. PTOPO MIB:
  600.  
  601.    - globally unique chassis identifiers.
  602.  
  603.    - port identifiers; unique only within the chassis which contains the
  604.      port.
  605.  
  606. Identifiers are stored as OCTET STRINGs, which are limited to 32 bytes
  607. in length, This supports flexible naming conventions and constrains the
  608. non-volatile storage requirements for an agent.
  609.  
  610. 5.2.  Relationship to Entity MIB
  611.  
  612. The Entity MIB [RFC2037] allows the physical component inventory and
  613. hierarchy to be identified. However, the Entity MIB does not provide
  614. persistent component identifiers, which are required for the PTOPO MIB.
  615. Therefore, an extension to the Entity MIB is defined [ENTITY-EXT] to
  616. provide that feature.  The new table augments the entPhysicalTable, and
  617. adds a read-write 'alias' identifier, similar to the ifAlias MIB object
  618. for interfaces.
  619.  
  620. For agents implementing the PTOPO MIB, this new object must be used to
  621. represent the chassis identifier. Port identifiers can be based on the
  622. entPhysicalAlias object associated with the port, but only if the port
  623. is not represented as an interface in the ifXTable.
  624.  
  625. Implementation of the entPhysicalGroup and entPhysicalXGroup is
  626. mandatory for SNMP agents which implement the PTOPO MIB.
  627.  
  628. 5.3.  Relationship to Interfaces MIB
  629.  
  630. The PTOPO MIB requires a persistent identifier for each port.  The
  631. Interfaces MIB [RFC1573] provides a standard mechanism for managing
  632. network interfaces. Unfortunately, not all ports which may be
  633. represented in the PTOPO MIB are also represented in the Interfaces MIB
  634. (e.g., repeater ports).
  635.  
  636. For agents which implement the PTOPO MIB, for each port represented in
  637. the Interfaces MIB, the agent must use the associated ifAlias value for
  638. the port identifier.  For each port not represented in the Interfaces
  639. MIB, the associated entPhysicalAlias value must be used for the port
  640. identifier.
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648. Bierman/Jones              Expires March 1998                  [Page 11]
  649.  
  650.  
  651.  
  652.  
  653.  
  654. Draft                    Physical Topology MIB            September 1997
  655.  
  656.  
  657. 5.4.  Relationship to RMON-2 MIB
  658.  
  659. The RMON-2 MIB [RFC2021] contains address mapping information which can
  660. be integrated with physical topology information. The physical ports
  661. identified in a physical topology MIB can be related to the MAC and
  662. network layer addresses found in the addressMapTable.
  663.  
  664. 5.5.  Relationship to Bridge MIB
  665.  
  666. The Bridge MIB [RFC1493] contains information which may relate to
  667. physical ports represented in the ptopoConnTable.  Entries in the
  668. dot1dBasePortTable and dot1dStpPortTable can by related to physical
  669. ports represented in the PTOPO MIB.  Also, bridge port MAC addresses may
  670. be used as chassis and port identifiers in some situations.
  671.  
  672. 5.6.  Relationship to Repeater MIB
  673.  
  674. The Repeater MIB [RFC2108] contains information which may relate to
  675. physical ports represented in the PTOPO MIB. Entries in the
  676. rptrPortTable and rptrMonitorPortTable can by related to physical ports
  677. represented in the ptopoConnTable.  Entries in the rptrInfoTable and
  678. rptrMonTable can be related to repeater backplanes possibly represented
  679. in the ptopoConnTable.
  680.  
  681. 5.7.  MIB Structure
  682.  
  683. The PTOPO MIB contains three MIB object groups:
  684.  
  685.   - ptopoData
  686.      Exposes physical topology data learned from discovery protocols
  687.      and/or manual configuration.
  688.  
  689.   - ptopoGeneral
  690.      Contains general information regarding PTOPO MIB status.
  691.  
  692.   - ptopoConfig
  693.      Contains configuration variables for the PTOPO MIB agent function.
  694.  
  695. 5.7.1.  ptopoData Group
  696.  
  697. This group contains a single table to identity physical topology data.
  698.  
  699. The ptopoConnTable contains information about the connections learned or
  700. configured on behalf of the PTOPO MIB SNMP Agent.
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707. Bierman/Jones              Expires March 1998                  [Page 12]
  708.  
  709.  
  710.  
  711.  
  712.  
  713. Draft                    Physical Topology MIB            September 1997
  714.  
  715.  
  716. 5.7.2.  ptopoGeneral Group
  717.  
  718. This group contains some scalar objects to report the status of the
  719. PTOPO MIB information currently known to the SNMP Agent. The global last
  720. change time, and table add and delete counters allow an NMS to set
  721. threshold alarms to trigger PTOPO polling.
  722.  
  723. 5.7.3.  ptopoConfig Group
  724.  
  725. This group contains tables to configure the behavior of the physical
  726. topology function.  The transmission of ptopoLastChange traps can be
  727. configured using the ptopoConfigTrapsEnabled scalar MIB object.
  728.  
  729. 5.8.  Physical Topology MIB Definitions
  730.  
  731. PTOPO-MIB DEFINITIONS ::= BEGIN
  732.  
  733. IMPORTS
  734.     MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32
  735.         FROM SNMPv2-SMI
  736.     TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue
  737.         FROM SNMPv2-TC
  738.     MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
  739.         FROM SNMPv2-CONF
  740.     TimeFilter
  741.         FROM RMON2-MIB
  742.     PhysicalIndex
  743.         FROM ENTITY-MIB;
  744.  
  745. ptopoMIB MODULE-IDENTITY
  746.     LAST-UPDATED "9709090000Z"
  747.     ORGANIZATION "IETF; PTOPOMIB Working Group"
  748.     CONTACT-INFO
  749.        "PTOPOMIB WG Discussion:
  750.         ptopo@3com.com
  751.         Subscription:
  752.         majordomo@3com.com
  753.           msg body: [un]subscribe ptopomib
  754.  
  755.         Andy Bierman
  756.         Cisco Systems Inc.
  757.         170 West Tasman Drive
  758.         San Jose, CA 95134
  759.         408-527-3711
  760.         abierman@cisco.com
  761.  
  762.  
  763.  
  764.  
  765.  
  766. Bierman/Jones              Expires March 1998                  [Page 13]
  767.  
  768.  
  769.  
  770.  
  771.  
  772. Draft                    Physical Topology MIB            September 1997
  773.  
  774.  
  775.         Kendall S. Jones
  776.         Bay Networks
  777.         4401 Great America Parkway
  778.         Santa Clara, CA 95134
  779.         408-495-7356
  780.         kjones@baynetworks.com"
  781.     DESCRIPTION
  782.             "The MIB module for physical topology information."
  783.     ::= { experimental xx }
  784.  
  785. ptopoMIBObjects   OBJECT IDENTIFIER ::= { ptopoMIB 1 }
  786.  
  787.  
  788. -- MIB groups
  789. ptopoData         OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 }
  790. ptopoGeneral      OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 }
  791. ptopoConfig       OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 }
  792.  
  793. -- textual conventions
  794.  
  795. --
  796. -- IANAAddrFamily TC copied from
  797. --   draft-ietf-disman-framework-00.txt
  798. -- Eventually, it will be included from a general TC module
  799. --
  800. IANAAddrFamily ::= TEXTUAL-CONVENTION
  801.     STATUS      current
  802.     DESCRIPTION
  803.             "An address family. Values are defined in Assigned Numbers,
  804.             RFC1700. Note that not all these values make sense in all
  805.             contexts where this type is used in this MIB, but they are
  806.             included for completeness."
  807.     REFERENCE
  808.             "Assigned Numbers, [RFC1700], ADDRESS FAMILY NUMBERS"
  809.     SYNTAX      INTEGER {
  810.                     other(0),
  811.                     ipV4(1),
  812.                     ipV6(2),
  813.                     nsap(3),
  814.                     hdlc(4),
  815.                     bbn1822(5),
  816.                     ieee802(6),
  817.                     e163(7),
  818.                     e164(8),
  819.                     f69(9),
  820.  
  821.  
  822.  
  823.  
  824.  
  825. Bierman/Jones              Expires March 1998                  [Page 14]
  826.  
  827.  
  828.  
  829.  
  830.  
  831. Draft                    Physical Topology MIB            September 1997
  832.  
  833.  
  834.                     x121(10),
  835.                     ipx(11),
  836.                     appleTalk(12),
  837.                     decnetIV(13),
  838.                     banyanVines(14),
  839.                     e164WithNsap(15)
  840.                 }
  841.  
  842. PtopoGenAddr ::= TEXTUAL-CONVENTION
  843.     STATUS      current
  844.     DESCRIPTION
  845.             "The value of an address."
  846.     SYNTAX      OCTET STRING (SIZE (0..20))
  847.  
  848. PtopoChassisIdType ::= TEXTUAL-CONVENTION
  849.     STATUS      current
  850.     DESCRIPTION
  851.             "This TC describes the source of a chassis identifier.
  852.  
  853.             The enumeration 'chasIdEntPhysicalAlias(1)' represents a
  854.             chassis identifier based on the value of entPhysicalAlias
  855.             for a chassis component (i.e., an entPhysicalClass value of
  856.             'chassis(3)').
  857.  
  858.             The enumeration 'chasIdIfAlias(2)' represents a chassis
  859.             identifier based on the value of ifAlias for an interface on
  860.             the containing chassis.
  861.  
  862.             The enumeration 'chasIdPortEntPhysicalAlias(3)' represents a
  863.             chassis identifier based on the value of entPhysicalAlias
  864.             for a port or backplane component (i.e., entPhysicalClass
  865.             value of 'port(10)' or 'backplane(4)'), within the
  866.             containing chassis.
  867.  
  868.             The enumeration 'chasIdMacAddress(4)' represents a chassis
  869.             identifier based on the value of a unicast source MAC
  870.             address (encoded in network byte order and IEEE 802.3
  871.             canonical bit order), of a port on the containing chassis.
  872.  
  873.             The enumeration 'chasIdPtopoGenAddr(5)' represents a chassis
  874.             identifier based on a network address, associated with a
  875.             particular chassis. The encoded address is actually composed
  876.             of two fields.  The first field is a single octet,
  877.             representing the IANAAddrFamily for the specific address
  878.             type, and the second field is the PtopoGenAddr address
  879.  
  880.  
  881.  
  882.  
  883.  
  884. Bierman/Jones              Expires March 1998                  [Page 15]
  885.  
  886.  
  887.  
  888.  
  889.  
  890. Draft                    Physical Topology MIB            September 1997
  891.  
  892.  
  893.             value."
  894.     SYNTAX      INTEGER {
  895.         chasIdEntPhysicalAlias(1),
  896.         chasIdIfAlias(2),
  897.         chasIdPortEntPhysicalAlias(3),
  898.         chasIdMacAddress(4),
  899.         chasIdPtopoGenAddr(5)
  900.     }
  901.  
  902. PtopoChassisId ::= TEXTUAL-CONVENTION
  903.     STATUS      current
  904.     DESCRIPTION
  905.             "This TC describes the format of a chassis identifier
  906.             string.  Objects of this type are always used with an
  907.             associated PtopoChassisIdType object, which identifies the
  908.             format of the particular PtopoChassisId object instance.
  909.  
  910.             If the associated PtopoChassisIdType object has a value of
  911.             'chasIdEntPhysicalAlias(1)', then the octet string
  912.             identifies a particular instance of the entPhysicalAlias
  913.             object for a chassis component (i.e., an entPhysicalClass
  914.             value of 'chassis(3)').
  915.  
  916.             If the associated PtopoChassisIdType object has a value of
  917.             'chasIdIfAlias(2)', then the octet string identifies a
  918.             particular instance of the ifAlias object for an interface
  919.             on the containing chassis.
  920.  
  921.             If the associated PtopoChassisIdType object has a value of
  922.             'chasIdPortEntPhysicalAlias(3)', then the octet string
  923.             identifies a particular instance of the entPhysicalAlias
  924.             object for a port or backplane component within the
  925.             containing chassis.
  926.  
  927.             If the associated PtopoChassisIdType object has a value of
  928.             'chasIdMacAddress(4)', then this string identifies a
  929.             particular unicast source MAC address (encoded in network
  930.             byte order and IEEE 802.3 canonical bit order), of a port on
  931.             the containing chassis.
  932.  
  933.             If the associated PtopoChassisIdType object has a value of
  934.             'chasIdPtopoGenAddr(5)', then this string identifies a
  935.             particular network address, encoded in network byte order,
  936.             associated with one or more ports on the containing chassis.
  937.             The first octet contains the IANAAddrFamily enumeration
  938.  
  939.  
  940.  
  941.  
  942.  
  943. Bierman/Jones              Expires March 1998                  [Page 16]
  944.  
  945.  
  946.  
  947.  
  948.  
  949. Draft                    Physical Topology MIB            September 1997
  950.  
  951.  
  952.             value for the specific address type, and octets 2 through N
  953.             contain the PtopoGenAddr address value in network byte
  954.             order."
  955.     SYNTAX      OCTET STRING (SIZE (1..32))
  956.  
  957. PtopoPortIdType ::= TEXTUAL-CONVENTION
  958.     STATUS      current
  959.     DESCRIPTION
  960.             "This TC describes the source of a particular type of port
  961.             identifier used in the PTOPO MIB.
  962.  
  963.             The enumeration 'portIdIfAlias(1)' represents a port
  964.             identifier based on the ifAlias MIB object.
  965.  
  966.             The enumeration 'portIdPortEntPhysicalAlias(2)' represents a
  967.             port identifier based on the value of entPhysicalAlias for a
  968.             port or backplane component (i.e., entPhysicalClass value of
  969.             'port(10)' or 'backplane(4)'), within the containing
  970.             chassis.
  971.  
  972.             The enumeration 'portIdMacAddr(3)' represents a port
  973.             identifier based on a unicast source MAC address, which has
  974.             been detected by the agent and associated with a particular
  975.             port.
  976.  
  977.             The enumeration 'portIdPtopoGenAddr(4)' represents a port
  978.             identifier based on a network address, detected by the agent
  979.             and associated with a particular port."
  980.     SYNTAX      INTEGER {
  981.         portIdIfAlias(1),
  982.         portIdEntPhysicalAlias(2),
  983.         portIdMacAddr(3),
  984.         portIdPtopoGenAddr(4)
  985.     }
  986.  
  987. PtopoPortId ::= TEXTUAL-CONVENTION
  988.     STATUS      current
  989.     DESCRIPTION
  990.             "This TC describes the format of a port identifier string.
  991.             Objects of this type are always used with an associated
  992.             PtopoPortIdType object, which identifies the format of the
  993.             particular PtopoPortId object instance.
  994.  
  995.             If the associated PtopoPortIdType object has a value of
  996.             'portIdIfAlias(1)', then the octet string identifies a
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002. Bierman/Jones              Expires March 1998                  [Page 17]
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008. Draft                    Physical Topology MIB            September 1997
  1009.  
  1010.  
  1011.             particular instance of the ifAlias object.
  1012.  
  1013.             If the associated PtopoPortIdType object has a value of
  1014.             'portIdEntPhysicalAlias(2)', then the octet string
  1015.             identifies a particular instance of the entPhysicalAlias
  1016.             object for a port component (i.e., entPhysicalClass value of
  1017.             'port(10)').
  1018.  
  1019.             If the associated PtopoPortIdType object has a value of
  1020.             'portIdMacAddr(3)', then this string identifies a particular
  1021.             unicast source MAC address associated with the port.
  1022.  
  1023.             If the associated PtopoPortIdType object has a value of
  1024.             'portIdPtopoGenAddr(4)', then this string identifies a
  1025.             network address associated with the port. The first octet
  1026.             contains the IANAAddrFamily enumeration value for the
  1027.             specific address type, and octets 2 through N contain the
  1028.             PtopoGenAddr address value in network byte order."
  1029.     SYNTAX      OCTET STRING (SIZE (1..32))
  1030.  
  1031.  
  1032. PtopoAddrSeenState ::= TEXTUAL-CONVENTION
  1033.     STATUS      current
  1034.     DESCRIPTION
  1035.             "This TC describes the state of address detection for a
  1036.             particular type of port identifier used in the PTOPO MIB.
  1037.  
  1038.             The enumeration 'not-used(1)' represents an entry for which
  1039.             the particular MIB object is not applicable to the remote
  1040.             connection endpoint, e.g. ptopoConnRemotePortType equals
  1041.             'portIdIfAlias(1)'.
  1042.  
  1043.             The enumeration 'unknown(2)' represents an entry for which
  1044.             the particular address collection state is not known.
  1045.  
  1046.             The enumeration 'one-addr(3)'  represents an entry for which
  1047.             exactly one source address (of the type indicated by the
  1048.             particular MIB object), has been detected.
  1049.  
  1050.             The enumeration 'multi-addr(4)'  represents an entry for
  1051.             which more than one source address (of the type indicated by
  1052.             the particular MIB object), has been detected."
  1053.     SYNTAX      INTEGER {
  1054.         not-used(1),
  1055.         unknown(2),
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061. Bierman/Jones              Expires March 1998                  [Page 18]
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067. Draft                    Physical Topology MIB            September 1997
  1068.  
  1069.  
  1070.         one-addr(3),
  1071.         multi-addr(4)
  1072.     }
  1073.  
  1074. --  ***********************************************************
  1075. --
  1076. --           P T O P O    D A T A     G R O U P
  1077. --
  1078. --  ***********************************************************
  1079.  
  1080. -- Connection Table
  1081.  
  1082. ptopoConnTable OBJECT-TYPE
  1083.     SYNTAX      SEQUENCE OF PtopoConnEntry
  1084.     MAX-ACCESS  not-accessible
  1085.     STATUS      current
  1086.     DESCRIPTION
  1087.             "This table contains one row per physical network connection
  1088.             known to this agent.  The agent may wish to ensure that only
  1089.             one ptopoConnEntry is present for each local port, or it may
  1090.             choose to maintain multiple ptopoConnEntries for the same
  1091.             local port.
  1092.  
  1093.             Entries based on lower numbered identifier types are
  1094.             preferred over higher numbered identifier types, i.e., lower
  1095.             values of the ptopoConnRemoteChassisType and
  1096.             ptopoConnRemotePortType objects."
  1097.     ::= { ptopoData 1 }
  1098.  
  1099.  
  1100. ptopoConnEntry       OBJECT-TYPE
  1101.     SYNTAX      PtopoConnEntry
  1102.     MAX-ACCESS  not-accessible
  1103.     STATUS      current
  1104.     DESCRIPTION
  1105.             "Information about a particular physical network connection.
  1106.             Entries may be created and deleted in this table, either
  1107.             manually or by the agent, if a physical topology discovery
  1108.             process is active."
  1109.     INDEX   {
  1110.         ptopoConnTimeMark,
  1111.         ptopoConnLocalChassis,
  1112.         ptopoConnLocalPort,
  1113.         ptopoConnIndex
  1114.     }
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120. Bierman/Jones              Expires March 1998                  [Page 19]
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126. Draft                    Physical Topology MIB            September 1997
  1127.  
  1128.  
  1129.     ::= { ptopoConnTable 1 }
  1130.  
  1131. PtopoConnEntry ::= SEQUENCE {
  1132.       ptopoConnTimeMark            TimeFilter,
  1133.       ptopoConnLocalChassis        PhysicalIndex,
  1134.       ptopoConnLocalPort           PhysicalIndex,
  1135.       ptopoConnIndex               Integer32,
  1136.       ptopoConnRemoteChassisType   PtopoChassisIdType,
  1137.       ptopoConnRemoteChassis       PtopoChassisId,
  1138.       ptopoConnRemotePortType      PtopoPortIdType,
  1139.       ptopoConnRemotePort          PtopoPortId,
  1140.       ptopoConnDiscAlgorithm       AutonomousType,
  1141.       ptopoConnAgentNetAddrType    IANAAddrFamily,
  1142.       ptopoConnAgentNetAddr        PtopoGenAddr,
  1143.       ptopoConnMultiMacSASeen      PtopoAddrSeenState,
  1144.       ptopoConnMultiNetSASeen      PtopoAddrSeenState,
  1145.       ptopoConnIsStatic            TruthValue,
  1146.       ptopoConnLastVerifyTime      TimeStamp,
  1147.       ptopoConnRowStatus           RowStatus
  1148. }
  1149.  
  1150. ptopoConnTimeMark  OBJECT-TYPE
  1151.     SYNTAX      TimeFilter
  1152.     MAX-ACCESS  not-accessible
  1153.     STATUS      current
  1154.     DESCRIPTION
  1155.             "A TimeFilter for this entry.  See the TimeFilter textual
  1156.             convention in RFC 2021 to see how this works."
  1157.     ::= { ptopoConnEntry 1 }
  1158.  
  1159. ptopoConnLocalChassis  OBJECT-TYPE
  1160.     SYNTAX      PhysicalIndex
  1161.     MAX-ACCESS  not-accessible
  1162.     STATUS      current
  1163.     DESCRIPTION
  1164.             "The entPhysicalIndex value used to identify the chassis
  1165.             component associated with the local connection endpoint."
  1166.     ::= { ptopoConnEntry 2 }
  1167.  
  1168. ptopoConnLocalPort     OBJECT-TYPE
  1169.     SYNTAX      PhysicalIndex
  1170.     MAX-ACCESS  not-accessible
  1171.     STATUS      current
  1172.     DESCRIPTION
  1173.             "The entPhysicalIndex value used to identify the port
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179. Bierman/Jones              Expires March 1998                  [Page 20]
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185. Draft                    Physical Topology MIB            September 1997
  1186.  
  1187.  
  1188.             component associated with the local connection endpoint."
  1189.     ::= { ptopoConnEntry 3 }
  1190.  
  1191. ptopoConnIndex    OBJECT-TYPE
  1192.     SYNTAX      Integer32  (1..2147483647)
  1193.     MAX-ACCESS  not-accessible
  1194.     STATUS      current
  1195.     DESCRIPTION
  1196.             "This object represents an arbitrary local integer value
  1197.             used by this agent to identify a particular connection
  1198.             instance, unique only for the indicated local connection
  1199.             endpoint.
  1200.  
  1201.             [ed. WG must decide on index re-use issue; Only one of the
  1202.             following two paragraphs will remain.]
  1203.  
  1204.             A particular ptopoConnIndex value may be reused in the event
  1205.             an entry is aged out and later re-learned with the same
  1206.             remote chassis and port identifiers.
  1207.  
  1208.             [ed. - OR]
  1209.  
  1210.             A particular ptopoConnIndex value may only be used once for
  1211.             a given (ptopoConnLocalChassis, ptopoConnLocalPort) pair,
  1212.             since the last reinitialization of the PTOPO agent."
  1213.     ::= { ptopoConnEntry 4 }
  1214.  
  1215. ptopoConnRemoteChassisType  OBJECT-TYPE
  1216.     SYNTAX      PtopoChassisIdType
  1217.     MAX-ACCESS  read-create
  1218.     STATUS      current
  1219.     DESCRIPTION
  1220.             "The type of encoding used to identify the chassis
  1221.             associated with the remote connection endpoint.
  1222.  
  1223.             This object may not be modified if the associated
  1224.             ptopoConnRowStatus object has a value of active(1)."
  1225.     ::= { ptopoConnEntry 5 }
  1226.  
  1227. ptopoConnRemoteChassis  OBJECT-TYPE
  1228.     SYNTAX      PtopoChassisId
  1229.     MAX-ACCESS  read-create
  1230.     STATUS      current
  1231.     DESCRIPTION
  1232.             "The string value used to identify the chassis component
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238. Bierman/Jones              Expires March 1998                  [Page 21]
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244. Draft                    Physical Topology MIB            September 1997
  1245.  
  1246.  
  1247.             associated with the remote connection endpoint.
  1248.  
  1249.             This object may not be modified if the associated
  1250.             ptopoConnRowStatus object has a value of active(1)."
  1251.     ::= { ptopoConnEntry 6 }
  1252.  
  1253. ptopoConnRemotePortType  OBJECT-TYPE
  1254.     SYNTAX      PtopoPortIdType
  1255.     MAX-ACCESS  read-create
  1256.     STATUS      current
  1257.     DESCRIPTION
  1258.             "The type of port identifier encoding used in the associated
  1259.             'ptopoConnRemotePort' object.
  1260.  
  1261.             This object may not be modified if the associated
  1262.             ptopoConnRowStatus object has a value of active(1)."
  1263.     ::= { ptopoConnEntry 7 }
  1264.  
  1265. ptopoConnRemotePort  OBJECT-TYPE
  1266.     SYNTAX      PtopoPortId
  1267.     MAX-ACCESS  read-create
  1268.     STATUS      current
  1269.     DESCRIPTION
  1270.             "The string value used to identify the port component
  1271.             associated with the remote connection endpoint.
  1272.  
  1273.             This object may not be modified if the associated
  1274.             ptopoConnRowStatus object has a value of active(1)."
  1275.     ::= { ptopoConnEntry 8 }
  1276.  
  1277. ptopoConnDiscAlgorithm OBJECT-TYPE
  1278.     SYNTAX      AutonomousType
  1279.     MAX-ACCESS  read-only
  1280.     STATUS      current
  1281.     DESCRIPTION
  1282.             "An indication of the algorithm used to discover the
  1283.             information contained in this conceptual row.
  1284.  
  1285.             A value of ptopoDiscoveryPDP indicates this entry was
  1286.             configured using the PTOPO Discovery Protocol.
  1287.  
  1288.             A value of ptopoDiscoveryLocal indicates this entry was
  1289.             configured by the local agent, without use of a discovery
  1290.             protocol.
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297. Bierman/Jones              Expires March 1998                  [Page 22]
  1298.  
  1299.  
  1300.  
  1301.  
  1302.  
  1303. Draft                    Physical Topology MIB            September 1997
  1304.  
  1305.  
  1306.             A value of { 0 0 } indicates this entry was created manually
  1307.             by an NMS via the associated RowStatus object. "
  1308.     ::= { ptopoConnEntry 9 }
  1309.  
  1310. ptopoConnAgentNetAddrType  OBJECT-TYPE
  1311.     SYNTAX      IANAAddrFamily
  1312.     MAX-ACCESS  read-create
  1313.     STATUS      current
  1314.     DESCRIPTION
  1315.             "This network address type of the associated
  1316.             ptopoConnNetAddr object, unless that object contains a zero
  1317.             length string.  In such a case, an NMS application should
  1318.             ignore any returned value for this object.
  1319.  
  1320.             This object may not be modified if the associated
  1321.             ptopoConnRowStatus object has a value of active(1)."
  1322.     ::= { ptopoConnEntry 10 }
  1323.  
  1324. ptopoConnAgentNetAddr  OBJECT-TYPE
  1325.     SYNTAX      PtopoGenAddr
  1326.     MAX-ACCESS  read-create
  1327.     STATUS      current
  1328.     DESCRIPTION
  1329.             "This object identifies a network address which may be used
  1330.             to reach an SNMP agent entity containing information for the
  1331.             chassis and port components represented by the associated
  1332.             'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects.
  1333.             If no such address is known, then this object shall contain
  1334.             an empty string.
  1335.  
  1336.             This object may not be modified if the associated
  1337.             ptopoConnRowStatus object has a value of active(1)."
  1338.     ::= { ptopoConnEntry 11 }
  1339.  
  1340. ptopoConnMultiMacSASeen  OBJECT-TYPE
  1341.     SYNTAX      PtopoAddrSeenState
  1342.     MAX-ACCESS  read-only
  1343.     STATUS      current
  1344.     DESCRIPTION
  1345.             "This object indicates if multiple unicast source MAC
  1346.             addresses have been detected by the agent from the remote
  1347.             connection endpoint, since the creation of this entry.
  1348.  
  1349.             If this entry has an associated ptopoConnRemoteChassisType
  1350.             and/or ptopoConnRemotePortType value other than
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356. Bierman/Jones              Expires March 1998                  [Page 23]
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362. Draft                    Physical Topology MIB            September 1997
  1363.  
  1364.  
  1365.             'portIdMacAddr(3)', then the value 'not-used(1)' is
  1366.             returned.
  1367.  
  1368.             Otherwise, one of the following conditions must be true:
  1369.  
  1370.             If the agent has not yet detected any unicast source MAC
  1371.             addresses from the remote port, then the value 'unknown(2)'
  1372.             is returned.
  1373.  
  1374.             If the agent has detected exactly one unicast source MAC
  1375.             address from the remote port, then the value 'one-addr(3)'
  1376.             is returned.
  1377.  
  1378.             If the agent has detected more than one unicast source MAC
  1379.             address from the remote port, then the value 'multi-addr(4)'
  1380.             is returned."
  1381.     ::= { ptopoConnEntry 12 }
  1382.  
  1383. ptopoConnMultiNetSASeen  OBJECT-TYPE
  1384.     SYNTAX      PtopoAddrSeenState
  1385.     MAX-ACCESS  read-only
  1386.     STATUS      current
  1387.     DESCRIPTION
  1388.             "This object indicates if multiple network layer source
  1389.             addresses have been detected by the agent from the remote
  1390.             connection endpoint, since the creation of this entry.
  1391.  
  1392.             If this entry has an associated ptopoConnRemoteChassisType
  1393.             or ptopoConnRemotePortType value other than
  1394.             'portIdGenAddr(4)' then the value 'not-used(1)' is returned.
  1395.  
  1396.             Otherwise, one of the following conditions must be true:
  1397.  
  1398.             If the agent has not yet detected any network source
  1399.             addresses of the appropriate type from the remote port, then
  1400.             the value 'unknown(2)' is returned.
  1401.  
  1402.             If the agent has detected exactly one network source address
  1403.             of the appropriate type from the remote port, then the value
  1404.             'one-addr(3)' is returned.
  1405.  
  1406.             If the agent has detected more than one network source
  1407.             address (of the same appropriate type) from the remote port,
  1408.             this the value 'multi-addr(4)' is returned."
  1409.     ::= { ptopoConnEntry 13 }
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415. Bierman/Jones              Expires March 1998                  [Page 24]
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421. Draft                    Physical Topology MIB            September 1997
  1422.  
  1423.  
  1424. ptopoConnIsStatic  OBJECT-TYPE
  1425.     SYNTAX      TruthValue
  1426.     MAX-ACCESS  read-create
  1427.     STATUS      current
  1428.     DESCRIPTION
  1429.             "This object identifies static ptopoConnEntries. If this
  1430.             object has the value 'true(1)', then this entry is not
  1431.             subject to any age-out mechanisms implemented by the agent.
  1432.  
  1433.             If this object has the value 'false(2)', then this entry is
  1434.             subject to all age-out mechanisms implemented by the agent.
  1435.  
  1436.             This object may not be modified if the associated
  1437.             ptopoConnRowStatus object has a value of active(1)."
  1438.     DEFVAL { false }
  1439.     ::= { ptopoConnEntry 14 }
  1440.  
  1441. ptopoConnLastVerifyTime  OBJECT-TYPE
  1442.     SYNTAX      TimeStamp
  1443.     MAX-ACCESS  read-only
  1444.     STATUS      current
  1445.     DESCRIPTION
  1446.             "If the associated value of ptopoConnIsStatic is equal to
  1447.             'false(2)', then this object contains the value of sysUpTime
  1448.             at the time the conceptual row was last verified by the
  1449.             agent, e.g. via reception of a PDP message pertaining to the
  1450.             associated remote chassis and port.
  1451.  
  1452.             If the associated value of ptopoConnIsStatic is equal to
  1453.             'true(1)', then this object shall contain the value of
  1454.             sysUpTime at the time this entry was last activated (i.e.,
  1455.             ptopoConnRowStatus set to 'active(1)')."
  1456.     ::= { ptopoConnEntry 15 }
  1457.  
  1458. ptopoConnRowStatus OBJECT-TYPE
  1459.     SYNTAX      RowStatus
  1460.     MAX-ACCESS  read-create
  1461.     STATUS      current
  1462.     DESCRIPTION
  1463.             "The status of this conceptual row."
  1464.     ::= { ptopoConnEntry 16 }
  1465.  
  1466.  
  1467. --  ***********************************************************
  1468. --
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474. Bierman/Jones              Expires March 1998                  [Page 25]
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480. Draft                    Physical Topology MIB            September 1997
  1481.  
  1482.  
  1483. --           P T O P O    G E N E R A L     G R O U P
  1484. --
  1485. --  ***********************************************************
  1486.  
  1487. -- last change time stamp for the whole MIB
  1488.  
  1489. ptopoLastChangeTime OBJECT-TYPE
  1490.     SYNTAX      TimeStamp
  1491.     MAX-ACCESS  read-only
  1492.     STATUS      current
  1493.     DESCRIPTION
  1494.             "The value of sysUpTime at the time a conceptual row is
  1495.             created, modified, or deleted in the ptopoConnTable.
  1496.  
  1497.             An NMS can use this object to reduce polling of the
  1498.             ptopoData group objects."
  1499.     ::= { ptopoGeneral 1 }
  1500.  
  1501. ptopoConnTabInserts OBJECT-TYPE
  1502.     SYNTAX      Counter32
  1503.     MAX-ACCESS  read-only
  1504.     STATUS      current
  1505.     DESCRIPTION
  1506.             "The number of times an entry has been inserted into the
  1507.             ptopoConnTable."
  1508.     ::= { ptopoGeneral 2 }
  1509.  
  1510. ptopoConnTabDeletes OBJECT-TYPE
  1511.     SYNTAX      Counter32
  1512.     MAX-ACCESS  read-only
  1513.     STATUS      current
  1514.     DESCRIPTION
  1515.             "The number of times an entry has been deleted from the
  1516.             ptopoConnTable."
  1517.     ::= { ptopoGeneral 3 }
  1518.  
  1519.  
  1520. ptopoConnTabDrops OBJECT-TYPE
  1521.     SYNTAX      Counter32
  1522.     MAX-ACCESS  read-only
  1523.     STATUS      current
  1524.     DESCRIPTION
  1525.             "The number of times an entry would have been added to the
  1526.             ptopoConnTable, (e.g., via information learned from PDP),
  1527.             but was not because of insufficient resources."
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533. Bierman/Jones              Expires March 1998                  [Page 26]
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539. Draft                    Physical Topology MIB            September 1997
  1540.  
  1541.  
  1542.     ::= { ptopoGeneral 4 }
  1543.  
  1544. ptopoConnTabReplaces OBJECT-TYPE
  1545.     SYNTAX      Counter32
  1546.     MAX-ACCESS  read-only
  1547.     STATUS      current
  1548.     DESCRIPTION
  1549.             "The number of times an entry for a particular connection
  1550.             has been replaced with an entry for the same local port, but
  1551.             different values for any of the following objects:
  1552.                 - ptopoConnRemoteChassisType
  1553.                 - ptopoConnRemoteChassis
  1554.                 - ptopoConnRemotePortType
  1555.                 - ptopoConnRemotePort"
  1556.     ::= { ptopoGeneral 5 }
  1557.  
  1558. ptopoConnTabAgeouts OBJECT-TYPE
  1559.     SYNTAX      Counter32
  1560.     MAX-ACCESS  read-only
  1561.     STATUS      current
  1562.     DESCRIPTION
  1563.             "The number of times an entry has been deleted from the
  1564.             ptopoConnTable because the information timeliness interval
  1565.             for that entry has expired."
  1566.     ::= { ptopoGeneral 6 }
  1567.  
  1568.  
  1569.  
  1570. --  ***********************************************************
  1571. --
  1572. --           P T O P O    C O N F I G     G R O U P
  1573. --
  1574. --  ***********************************************************
  1575.  
  1576. ptopoConfigTrapsEnabled OBJECT-TYPE
  1577.     SYNTAX      TruthValue
  1578.     MAX-ACCESS  read-write
  1579.     STATUS      current
  1580.     DESCRIPTION
  1581.             "This object controls the transmission of PTOPO traps.
  1582.  
  1583.             If the agent is capable of storing non-volatile
  1584.             configuration, then the value of this object must be
  1585.             restored after a re-initialization of the management
  1586.             system."
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592. Bierman/Jones              Expires March 1998                  [Page 27]
  1593.  
  1594.  
  1595.  
  1596.  
  1597.  
  1598. Draft                    Physical Topology MIB            September 1997
  1599.  
  1600.  
  1601.     DEFVAL { false }
  1602.     ::= { ptopoConfig 1 }
  1603.  
  1604. ptopoConfigMaxHoldTime OBJECT-TYPE
  1605.     SYNTAX      Integer32 (1..2147483647)
  1606.     UNITS       "seconds"
  1607.     MAX-ACCESS  read-write
  1608.     STATUS      current
  1609.     DESCRIPTION
  1610.             "This object specifies the desired time interval for which
  1611.             an agent will maintain dynamic ptopoConnEntries.
  1612.  
  1613.             After the specified number of seconds since the last time an
  1614.             entry was verified, in the absence of new verification
  1615.             (e.g., receipt of a PDP message), the agent shall remove the
  1616.             entry.  Note that entries may not always be removed
  1617.             immediately, but may possibly be removed at periodic garbage
  1618.             collection intervals.
  1619.  
  1620.             This object only affects dynamic ptopoConnEntries, i.e.  for
  1621.             which ptopoConnIsStatic equals 'false(2)'. Static entries
  1622.             are not aged out.
  1623.  
  1624.             Note that dynamic ptopoConnEntries may also be removed by
  1625.             the agent due to the expired timeliness of learned topology
  1626.             information (e.g., timeliness interval for a remote port
  1627.             expires).  The actual age-out interval for a given entry is
  1628.             defined by the following formula:
  1629.  
  1630.               age-out-time =
  1631.                 min(ptopoConfigMaxHoldTime, <entry-specific hold-time>)
  1632.  
  1633.             where <entry-specific hold-time> is determined by the
  1634.             discovery algorithm, and may be different for each entry.
  1635.             For entries discovered with PDP, this is the particular
  1636.             'time-to-live' value from the most recent PDP message
  1637.             associated with the entry."
  1638.     DEFVAL { 300 }
  1639.     ::= { ptopoConfig 2 }
  1640.  
  1641.  
  1642. -- PTOPO MIB Trap Definitions
  1643. ptopoMIBTraps       OBJECT IDENTIFIER ::= { ptopoMIB 2 }
  1644. ptopoMIBTrapPrefix  OBJECT IDENTIFIER ::= { ptopoMIBTraps 0 }
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651. Bierman/Jones              Expires March 1998                  [Page 28]
  1652.  
  1653.  
  1654.  
  1655.  
  1656.  
  1657. Draft                    Physical Topology MIB            September 1997
  1658.  
  1659.  
  1660. ptopoConfigChange NOTIFICATION-TYPE
  1661.     OBJECTS       {
  1662.         ptopoConnTabInserts,
  1663.         ptopoConnTabDeletes,
  1664.         ptopoConnTabDrops,
  1665.         ptopoConnTabReplaces,
  1666.         ptopoConnTabAgeouts
  1667.     }
  1668.     STATUS        current
  1669.     DESCRIPTION
  1670.             "A ptopoConfigChange trap is sent when the value of
  1671.             ptopoLastChangeTime changes. It can be utilized by an NMS to
  1672.             trigger physical topology table maintenance polls.
  1673.  
  1674.             An agent must not generate more than one ptopoConfigChange
  1675.             trap-event in a five second period, where a 'trap-event' is
  1676.             the transmission of a single trap PDU to a list of trap
  1677.             destinations.  If additional configuration changes occur
  1678.             within the five second throttling period, then these trap-
  1679.             events should be suppressed by the agent. An NMS should
  1680.             periodically check the value of ptopoLastChangeTime to
  1681.             detect any missed ptopoConfigChange trap-events, e.g. due to
  1682.             throttling or transmission loss."
  1683.    ::= { ptopoMIBTrapPrefix 1 }
  1684.  
  1685.  
  1686. -- PTOPO Registration Points
  1687.  
  1688. ptopoRegistrationPoints  OBJECT IDENTIFIER ::= { ptopoMIB 3 }
  1689.  
  1690.  
  1691. -- values used with ptopoConnDiscAlgorithm object
  1692. ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= { ptopoRegistrationPoints 1 }
  1693. ptopoDiscoveryPDP        OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 1 }
  1694. ptopoDiscoveryLocal      OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 2 }
  1695.  
  1696.  
  1697. -- conformance information
  1698. ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 }
  1699.  
  1700. ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 }
  1701. ptopoGroups      OBJECT IDENTIFIER ::= { ptopoConformance 2 }
  1702.  
  1703. -- compliance statements
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710. Bierman/Jones              Expires March 1998                  [Page 29]
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716. Draft                    Physical Topology MIB            September 1997
  1717.  
  1718.  
  1719. ptopoCompliance MODULE-COMPLIANCE
  1720.    STATUS  current
  1721.     DESCRIPTION
  1722.             "The compliance statement for SNMP entities which implement
  1723.             the PTOPO MIB."
  1724.     MODULE  -- this module
  1725.         MANDATORY-GROUPS {
  1726.                 ptopoDataGroup,
  1727.                 ptopoGeneralGroup,
  1728.                 ptopoConfigGroup,
  1729.                 ptopoNotificationsGroup
  1730.         }
  1731.     ::= { ptopoCompliances 1 }
  1732.  
  1733. -- MIB groupings
  1734.  
  1735. ptopoDataGroup   OBJECT-GROUP
  1736.     OBJECTS {
  1737.         ptopoConnRemoteChassisType,
  1738.         ptopoConnRemoteChassis,
  1739.         ptopoConnRemotePortType,
  1740.         ptopoConnRemotePort,
  1741.         ptopoConnDiscAlgorithm,
  1742.         ptopoConnAgentNetAddrType,
  1743.         ptopoConnAgentNetAddr,
  1744.         ptopoConnMultiMacSASeen,
  1745.         ptopoConnMultiNetSASeen,
  1746.         ptopoConnIsStatic,
  1747.         ptopoConnLastVerifyTime,
  1748.         ptopoConnRowStatus
  1749.     }
  1750.     STATUS  current
  1751.     DESCRIPTION
  1752.             "The collection of objects which are used to represent
  1753.             physical topology information for which a single agent
  1754.             provides management information.
  1755.  
  1756.             This group is mandatory for all implementations of the PTOPO
  1757.             MIB."
  1758.     ::= { ptopoGroups 1 }
  1759.  
  1760. ptopoGeneralGroup    OBJECT-GROUP
  1761.     OBJECTS {
  1762.         ptopoLastChangeTime,
  1763.         ptopoConnTabInserts,
  1764.  
  1765.  
  1766.  
  1767.  
  1768.  
  1769. Bierman/Jones              Expires March 1998                  [Page 30]
  1770.  
  1771.  
  1772.  
  1773.  
  1774.  
  1775. Draft                    Physical Topology MIB            September 1997
  1776.  
  1777.  
  1778.         ptopoConnTabDeletes,
  1779.         ptopoConnTabDrops,
  1780.         ptopoConnTabReplaces,
  1781.         ptopoConnTabAgeouts
  1782.     }
  1783.     STATUS  current
  1784.     DESCRIPTION
  1785.             "The collection of objects which are used to report the
  1786.             general status of the PTOPO MIB implementation.
  1787.  
  1788.             This group is mandatory for all agents which implement the
  1789.             PTOPO MIB."
  1790.     ::= { ptopoGroups 2 }
  1791.  
  1792. ptopoConfigGroup    OBJECT-GROUP
  1793.     OBJECTS {
  1794.         ptopoConfigTrapsEnabled,
  1795.         ptopoConfigMaxHoldTime
  1796.     }
  1797.     STATUS  current
  1798.     DESCRIPTION
  1799.             "The collection of objects which are used to configure the
  1800.             PTOPO MIB implementation behavior.
  1801.  
  1802.             This group is mandatory for agents which implement the PTOPO
  1803.             MIB."
  1804.     ::= { ptopoGroups 3 }
  1805.  
  1806.  
  1807. ptopoNotificationsGroup NOTIFICATION-GROUP
  1808.     NOTIFICATIONS {
  1809.         ptopoConfigChange
  1810.     }
  1811.     STATUS        current
  1812.     DESCRIPTION
  1813.             "The collection of notifications used to indicate PTOPO MIB
  1814.             data consistency and general status information.
  1815.  
  1816.             This group is mandatory for agents which implement the PTOPO
  1817.             MIB."
  1818.     ::= { ptopoGroups 4 }
  1819.  
  1820. END
  1821.  
  1822.  
  1823.  
  1824.  
  1825.  
  1826.  
  1827.  
  1828. Bierman/Jones              Expires March 1998                  [Page 31]
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834. Draft                    Physical Topology MIB            September 1997
  1835.  
  1836.  
  1837. 6.  References
  1838.  
  1839. [ENTITY-EXT]
  1840.      Bierman, A., McCloghrie, K., "Entity MIB Extensions for Persistent
  1841.      Component Identification", draft-bierman-entmib-compid-00.txt,
  1842.      Cisco Systems, July 1997.
  1843.  
  1844. [RFC1157]
  1845.      Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
  1846.      Management Protocol", RFC 1157, SNMP Research, Performance Systems
  1847.      International, MIT Laboratory for Computer Science, May 1990.
  1848.  
  1849. [RFC1213]
  1850.      McCloghrie, K., and M. Rose, Editors, "Management Information Base
  1851.      for Network Management of TCP/IP-based internets: MIB-II", STD 17,
  1852.      RFC 1213, Hughes LAN Systems, Performance Systems International,
  1853.      March 1991.
  1854.  
  1855. [RFC1493]
  1856.      E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie, "Definitions
  1857.      of Managed Objects for Bridges", RFC 1493, Cisco Systems, Inc.,
  1858.      Digital Equipment Corporation, Hughes LAN Systems, Inc., July 1993.
  1859.  
  1860. [RFC1573]
  1861.      McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution",
  1862.      RFC 1573, Hughes LAN Systems, FTP Software, January 1994.
  1863.  
  1864. [RFC1700]
  1865.      Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  1866.      USC/Information Sciences Institute, October 1994.
  1867.  
  1868. [RFC1902]
  1869.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1870.      S. Waldbusser, "Structure of Management Information for version 2
  1871.      of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
  1872.      January 1996.
  1873.  
  1874. [RFC1903]
  1875.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1876.      S. Waldbusser, "Textual Conventions for version 2 of the Simple
  1877.      Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
  1878.  
  1879. [RFC1904]
  1880.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1881.      S. Waldbusser, "Conformance Statements for version 2 of the Simple
  1882.  
  1883.  
  1884.  
  1885.  
  1886.  
  1887. Bierman/Jones              Expires March 1998                  [Page 32]
  1888.  
  1889.  
  1890.  
  1891.  
  1892.  
  1893. Draft                    Physical Topology MIB            September 1997
  1894.  
  1895.  
  1896.      Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
  1897.  
  1898. [RFC1905]
  1899.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1900.      S. Waldbusser, "Protocol Operations for version 2 of the Simple
  1901.      Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
  1902.  
  1903. [RFC2021]
  1904.      S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021,
  1905.      International Network Services, January 1997.
  1906.  
  1907. [RFC2037]
  1908.      McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037,
  1909.      Cisco Systems, October 1996.
  1910.  
  1911. [RFC2108]
  1912.      K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, "Definitions
  1913.      of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2",
  1914.      RFC 2108, 3Com Corporation, Madge Networks (Israel) Ltd., Coloma
  1915.      Communications, Cisco Systems Inc., February 1997.
  1916.  
  1917.  
  1918.  
  1919.  
  1920.  
  1921.  
  1922.  
  1923.  
  1924.  
  1925.  
  1926.  
  1927.  
  1928.  
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946. Bierman/Jones              Expires March 1998                  [Page 33]
  1947.  
  1948.  
  1949.  
  1950.  
  1951.  
  1952. Draft                    Physical Topology MIB            September 1997
  1953.  
  1954.  
  1955. 7.  Security Considerations
  1956.  
  1957. This MIB exposes information about the physical connectivity for a
  1958. particular portion of a network. A network administrator may wish to
  1959. restrict SNMP access to such information, but such agent security
  1960. configuration is beyond the scope of this document.
  1961.  
  1962. A network administrator may also wish to inhibit transmission of any
  1963. ptopoConfigChange traps by setting the ptopoConfigTrapsEnabled object to
  1964. 'false(2)'.
  1965.  
  1966.  
  1967. 8.  Authors' Addresses
  1968.  
  1969.      Andy Bierman
  1970.      Cisco Systems
  1971.      170 West Tasman Drive
  1972.      San Jose, CA 95134
  1973.      Phone: 408-527-3711
  1974.      Email: abierman@cisco.com
  1975.  
  1976.      Kendall S. Jones
  1977.      Bay Networks
  1978.      4401 Great America Parkway
  1979.      Santa Clara, CA 95134
  1980.      Phone: 408-495-7356
  1981.      Email: kjones@baynetworks.com
  1982.  
  1983.  
  1984.  
  1985.  
  1986.  
  1987.  
  1988.  
  1989.  
  1990.  
  1991.  
  1992.  
  1993.  
  1994.  
  1995.  
  1996.  
  1997.  
  1998.  
  1999.  
  2000.  
  2001.  
  2002.  
  2003.  
  2004.  
  2005. Bierman/Jones              Expires March 1998                  [Page 34]
  2006.  
  2007.  
  2008.  
  2009.  
  2010.  
  2011. Draft                    Physical Topology MIB            September 1997
  2012.  
  2013.  
  2014. Table of Contents
  2015.  
  2016.  
  2017. 1 Introduction ....................................................    1
  2018. 2 The SNMP Network Management Framework ...........................    2
  2019. 2.1 Object Definitions ............................................    2
  2020. 3 Overview ........................................................    2
  2021. 3.1 Background and Concepts .......................................    3
  2022. 3.2 Terms .........................................................    4
  2023. 3.3 Functionality Goals ...........................................    5
  2024. 3.4 Design Goals ..................................................    6
  2025. 4 Topology Framework ..............................................    7
  2026. 4.1 Framework Overview ............................................    7
  2027. 4.1.1 Topology Mechanisms .........................................    8
  2028. 4.1.2 Manager Process .............................................    9
  2029. 5 Physical Topology MIB ...........................................   10
  2030. 5.1 Persistent Identifiers ........................................   10
  2031. 5.2 Relationship to Entity MIB ....................................   11
  2032. 5.3 Relationship to Interfaces MIB ................................   11
  2033. 5.4 Relationship to RMON-2 MIB ....................................   12
  2034. 5.5 Relationship to Bridge MIB ....................................   12
  2035. 5.6 Relationship to Repeater MIB ..................................   12
  2036. 5.7 MIB Structure .................................................   12
  2037. 5.7.1 ptopoData Group .............................................   12
  2038. 5.7.2 ptopoGeneral Group ..........................................   13
  2039. 5.7.3 ptopoConfig Group ...........................................   13
  2040. 5.8 Physical Topology MIB Definitions .............................   13
  2041. 6 References ......................................................   32
  2042. 7 Security Considerations .........................................   34
  2043. 8 Authors' Addresses ..............................................   34
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064. Bierman/Jones              Expires March 1998                  [Page 35]
  2065.  
  2066.