2.4.10 Physical Topology MIB (ptopomib)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.


Ken Jones <kjones@baynetworks.com>

Operations and Management Area Director(s):

John Curran <jcurran@bbn.com>
Michael O''Dell <mo@uu.net>

Operations and Management Area Advisor:

John Curran <jcurran@bbn.com>

Mailing Lists:

General Discussion: ptopo@3com.com
To Subscribe: ptopo-request@3com.com
Archive: ftp ftp.3com.com (login: ptopo, passwd: ptopo)

Description of Working Group:

Document Editor: Gilbert Ho (Gilbert_Ho@3mail.3com.com)

The goals of this working group are:

To agree on and document the common framework/model for discussing physical topology o to standardize a set of managed objects that provide physical topology information o to document media specific mechanisms to communicate topology information.

The managed objects should provide sufficient information to allow a management workstation to navigate across a set of agents in order to learn the topology of arbitrarily large networks, and these objects should be as independent as possible from the specific underlying networking media which comprise the network. These objects will be the minimum necessary to provide the ability to support the physical topology discovery, and will be consistent with the SNMP framework and existing SNMP standards.

In defining these objects, it is anticipated that the working group will leverage existing work for representing port-based information, such as in the Repeater MIB (RFC 1516 or later) and may also leverage work in the entity MIB for describing logical and physical relationships.

The working group will define the general requirements for topology mechanisms in order to support the proposed MIB. It will also identify existing topology mechanisms for common LAN media types and may propose new topology mechanisms for LAN media types where required. It is a goal of the common topology MIB to allow the use of either standard or proprietary topology mechanisms within the underlying media.

At this time, it is not a goal of the working group to support the collection or representation of logical topology information, such as VLAN configuration or subnet structure. It is anticipated that this could be an area for future work items, so some consideration will be given to extensibility of the models and to the MIB. However, this consideration must not be allowed to impede progress on the primary focus of physical connectivity.

Goals and Milestones:

Oct 96


Working Group formation approved by IESG Solicit input (proprietary MIBs, model)

Nov 96


Hold Interim meeting in San Jose

Nov 96


Post Internet-Draft for topology MIB

Nov 96


Post Internet-Draft for topology model

Dec 96


Working Group meeting at IETF-San Jose to review the initial IDs

Feb 97


Post revised Internet-Draft(s)

Mar 97


Review Internet-Draft(s) at IETF meeting

Jun 97


Submit final version of Internet-Draft(s) to IESG for consideration as a Proposed Standard


No Request For Comments

Current Meeting Report

Minutes of the PTOPOMIB WG Meeting

Reported by Andy Bierman


The PTOPOMIB WG met to advance progress on all I-Ds under development:

· PTOPO Discovery Protocol and MIB (PDP)
· Entity MIB Extensions for Persistent Identifiers

Review Material:

(1) Physical Topology MIB <draft-ietf-ptopomib-mib-00.txt>
(2) Physical Topology Discovery Protocol and MIB <draft-ietf-ptopomib-pdp-00.txt>
(3) Entity MIB Extensions for Persistent Component Identification <draft-bierman-entmib-compid-00.txt>


Agenda Bashing
Issues - PTOPO MIB I-D
Issues - PDP I-D
Presentation: Physical Topology with standard MIBs (Nick Dawes - Loran)
Issues - Entity MIB I-D


This section contains a somewhat temporal account of WG issues and discussions during the two meetings.


a) Replacement of ptopoConnEntries

The current draft specifies that only one type of component identifier should be present for each connection endpoint. Entries with higher values of the ptopoChassisIdType or PtopoPortIdType INDEX component are supposed to be replaced by identifier types with lower values (if and when such information is learned by the PTOPO agent).

The WG decided that it is desirable to allow an agent to maintain multiple entries for the same connection, although this is not mandatory. The MIB indexing will be modified (see sec. 1.7) to allow an arbitrary number of ptopoConnTable entries for each local port.

b) NULL Identifier Types

The WG discussed a proposal to allow NULL identifiers for both chassis and port components. After much discussion the WG decided there were enough identifier types to allow a PTOPO agent to identify each component with a non-NULL string. In the general sense, a NULL identifier in the PTOPO MIB will be reserved to indicate the "don't know" value.

c) Repeater Backplanes

Since repeaters must transmit PDP advertisements out all ports attached to the same shared backplane, it is not possible to identify a single port in the PDP Port ID TLV and ptopoPortId MIB object.

The WG decided that entPhysicalEntries with an associated entPhysicalClass value of 'backplane(4)' should be supported in the PTOPO MIB and PDP. Repeaters that generate PDP advertisements should use the appropriate backplane entPhysicalEntry in the PortID TLV, if the Entity MIB is implemented.

d) PTOPO Traps

A default value of 'false(2)' will be specified for the ptopoConfigTrapsEnabled scalar object. Text will also be added to the security section regarding this issue.

e) SNMPv3 Alignment

The ptopoConnNetAddr object specifies only a network address of an SNMP agent containing information associated with the remote endpoint. The WG discussed the need for additional MIB objects to support SNMPv3 command-initiator functions in a secure environment.

These objects (e.g., engineID, contextName, securityModel, and securityName) will not be added in the next draft of the MIB. The current table does not include community strings either. It is considered a security risk and burden to add this support to the PTOPO MIB and PDP.

f) ptopoChassisId and ptopoPortId TCs

The TCs, which define PTOPO chassis and port identifier strings, will have a max length of 32 octets, instead of 48 octets.

g) ptopoConnTable INDEX

In order to allow an agent some flexibility to maintain multiple endpoint entries (more than 2) per connection, the indexing of the ptopoConnTable will be redone. The table will now be indexed by 4 integers:

INDEX { ptopoTimeMark, ptopoConnLocalChassis, ptopoConnLocalPort, and ptopoConnIndex }

*** NEW WG ISSUE ***
Local Index Uniqueness Requirements:

No Index Reuse:
The simple arbitrary local integer (ptopoConnIndex) must be unique for a given {chassis, port} pair. An agent must insure that each index is used at most one time per port between agent reboots. New index values must be used each time an entry is added to the table. This restricts the number of significant topology config changes to 4 billion per port, but it makes the MIB easier to use for an NMS.

Allow Index Reuse:
Some of the same usage and limitations as the first approach except that an agent is permitted (required?) to reuse a ptopoConnIndex value for an entry that has been aged out and then subsequently re-learned. The new entry must have the exact same semantics as the previous one at the time it was aged out.

The WG must decide which approach to use so the Editor can write the text.

h) Last Verification Timestamp

A MIB object will be added to the ptopoConnEntry to indicate the value of sysUpTime when the indicated entry was last verified by the PTOPO agent (e.g., by receipt of a PDP msg).

i) Max Desired Hold Time

A scalar MIB object will be added to the ptopoConfig group called 'ptopoMaxDesiredConnHoldTime', which will specify the number of seconds a PTOPO agent should maintain connection information in the absence of entry verification.

If an entry exceeds the configured threshold, i.e., cur_sysUpTime > (ptopoConnLastVerifyTime + (ptopoMaxDesiredHoldTime * 100)) then the PTOPO agent is expected to remove the entry. Note that an agent is permitted to remove entries using periodic garbage collection, so entries may not be deleted at the instant the age-out threshold is exceeded.

j) Statically Configured ptopoConnEntries

Entries that are statically configured by an NMS are not subject to the garbage collection described in previous sections. Static entries are indicated by a new read-create MIB object in the ptopoConnEntry called 'ptopoConnIsStatic', with SYNTAX TruthValue. There isn't any one appropriate DEFVAL, but entries with an associated ptopoConnDiscAlgorithm value of { 0 0 } (conf by NMS) are most likely static entries.

k) New MIB Counters

Three new scalar counters will be added to the ptopoConfig group to help an NMS identify PTOPO agent activity regarding garbage collection and topology changes. The ptopoConnTabInserts and ptopoConnTabDeletes counters will remain exactly as defined.

A 'drop count' object will be added called ptopoConnTabDrops. This counter indicates the number of times a PTOPO agent detected a situation in which information would have been added to the ptopoConnTable, but wasn't because of insufficient resources.

A 'replace count' object will be added called ptopoConnTabReplaces. This counter indicates the number of times remote endpoint information of one identifier type has been replaced by information of a different identifier type.

An 'age-out count' object will be added called ptopoConnTabAgeOuts. This counter indicates the number of times an entry has been removed because the max desired hold time for the entry was exceeded.

The ptopoConnConfigChange notification will be updated to include the new counters.

l) ptopoConnNetAddr Name Change

This object specifies a network address of an SNMP agent that contains information associated with a remote connection endpoint. The object will be renamed to ptopoConnAgentNetAddr.

m) ptopoConnChassis1,2 and ptopoConnPort1,2 Name Change

The chassis and port identifier objects will be renamed to differentiate between 'local' and 'remote' connection endpoints. For example, ptopoConnChassis1 will become ptopoConnLocalChassis and ptopoConnChassis2 will become ptopoConnRemoteChassis.

n) TLV Support in the ptopoConnTable

The WG discussed a proposal to add MIB objects to support vendor-specific MIB placeholders in the PTOPO MIB. The WG decided that even though PDP supports vendor-specific TLVs, the standard PTOPO MIB should not. Such objects should be defined in a vendor's proprietary MIBs.

o) Topology Server MIB

The WG recognizes that an aggregation of information gathered from potentially many PTOPO agents are needed for applications to present complete physical topology maps, and that future MIB work, possibly in the DISMAN WG, is needed to effectively deploy a standard topology server MIB.

p) NVRAM Requirements

The MIB will be updated to require agents who support NV storage of static ptopoConnTable entries to recreate the exact semantics upon agent restart, except that none of the same index values have to be reused.


a) Multiple Sources for ChassisID and PortID TLVs

Since the PTOPO MIB supports multiple identifier types, the chassis and port identifiers used in PDP TLVs should also support this feature. The ability to associate an identifier with any MIB object is already supported. It is an implementation specific matter as to how co-located PDP and PTOPO agents convert these OIDs to PTOPO identifier types.

b) PDP Forwarding

Text will be added to the document further clarifying the differences between 'PDP forwarding' and 'PDP non-forwarding' types of PTOPO implementations. An agent may contain entries representing ports not directly attached to the indicated local chassis. An agent may wish to limit and even suppress such entries, but this is not required.

c) Selection of MAC address

In the event a MAC address is used in a chassis (or even a port) identifier TLV, the agent may have to make an implementation-specific decision as to which address to choose if more than one is available.

d) Elements of Procedure Appendix

An appendix will be added to the document to demonstrate how a PTOPO agent may use information from a co-located PDP agent to populate the PTOPO MIB.

e) PDP Checksum

The checksum in each PDP message operates exactly as a UDP checksum. The PDP message is encoded with a checksum value of zero. Then the ones-complement of the ones-complement addition of the encoded message is rewritten to the checksum location in the message.

The checksum is optional, and the value zero is reserved to indicate the checksum is not in use.

f) ASN.1 Encoding vs. TLV Encoding

The WG discussed a proposal to use ASN.1 and a pseudo-MIB to describe the PDP message format and encoding. Proponents think it is overall simpler to encode the PDP message payload as a varbind list in ASN.1/BER encoding, rather than a list of TLVs in network byte order.

The WG held a straw vote on which encoding to use:

ASN.1 6
Don't care approx . 35

The WG decided to use ASN.1 encoding in PDP and describe the PDP parameters using a pseudo-MIB (not actually implemented by any SNMP agent) based on this straw poll.

Since the document editor doesn't know how to write a MIB object for a UDP-style checksum (along with requisite encoding hacks), the PDP header and checksum need to be outside the portion of the PDU encoded as an ASN.1/BER varbind list. Only the encoding of the TLV portion of the PDU will be affected by this change.

g) Management Address TLV

A proposal was made to make the mandatory management address TLV an optional TLV. As a compromise, the TLV will remain mandatory, but an empty string may be used for the "don't know" value.

h) default Timer Values

A proposal was made to change the DEFVAL for the PDP transmission interval from 60 to 10 seconds. Some wanted to raise the DEFVAL even higher than 60 seconds. The WG agreed to leave the DEFVAL at 60, noting that an agent may be configure any legal DEFVAL in implementation.

i) Replace pdpMessageTxHoldTime

This object will be changed to indicate a multiplier value, used with the pdpMessageTxInterval object to derive the same semantics, except that illegal configurations will be avoided. The DEFVAL will be 3, and the same index range will be maintained.

j) Authenticated Discovery Protocol

A proposal was made to support the ability to encode the PDP messages as auth/no-priv or auth/priv SNMPv3 PDUs. This was rejected due to increased complexity and the inability to do administration such as discovery protocol.

k) pdpTxSuppressTable Changes

The table used to suppress PDP message transmission will be generalized to suppress PDP transmission and processing of any PDP messages received on a particular port. The table will be renamed to 'pdpSuppressTable'.

l) PDP MAC Group Address

An appropriate group address must be chosen for PDP messages. Keith McCloghrie volunteered to act as WG liaison to the IEEE 802.1 sub-working group and pursue the matter further.

The IETF may have a group address allocated that can be used for PDP. This option will be pursued by the WG as well.

III. Physical Topology Discovery using Standard MIBs

Nick Dawes of Loran reported on implementation experience regarding the discovery of physical topology using MIBs commonly found on various network devices.

The important features of this SW include:

· use of probability-based weighting factor to help resolve data conflicts from multiple sources, which can occur in the normal operation of the network.
· designed for minimal impact on network traffic; polling gated by max-desired-bandwidth (as a percentage of bandwidth); only minimum set of required MIB objects actually retrieved from each agent.

IV. Entity MIB Requirements

a) entPhysicalAlias object

The max length of this string will be 32 octets instead of 48, to match other changes made in the PTOPO MIB. The string will be based on the UTF-8 based SnmpAdminString, defined by the SNMPv3 WG.

b) Entity MIB Document Advancement

The Entity MIB WG needs to do extensive work to support SNMPv3 and investigate RFC 2037 implementation experience. Therefore, the PTOPOMIB WG wants the ENTMIB WG to phase the

upcoming controversial work, and publish a simple augmentation to RFC 2037, containing just the entPhysicalAlias extension defined in draft-bierman-entmib-compid-00.txt.

The ENTMIB WG Chair will discuss re-activation with the Area Director, and report back to the PTOPOMIB WG.

V. Meeting Resolutions

a) Document Advancement

New versions of the PTOPO MIB and PDP I-Ds will be published by 17sep97, which will then be discussed on the mailing list.

The Entity MIB WG will hopefully be restarted in time to hold a first meeting at the next IETF in December.

The group MAC address issues will be discussed on the mailing list and hopefully resolved at the next IETF.

b) Interim Meeting

No interim meeting has been planned at this time. A charter extension has been requested instead. Hopefully the WG can complete the current charter soon after the December IETF meeting.


None Received

Attendees List

go to list

Previous PageNext Page