The RMON WG met in two formal sessions during the San Diego
IETF meeting. Issues from both RFC 1271 and the developing
Token Ring MIB were discussed. What follows is an encapsu-
lation of the discussions
Interoperability Interoperation between two or more indepen-
dent implementations is a requirement for an RFC to become a
full Internet standard (RFC 1310). Accordingly, Mike
Erlinger and Steve Waldbusser discussed their attempt to
organize two interoperability testing sessions for Ethernet
RMON probes and managers.
1. Week of May 25th (after InterOp) at CMU in Pitts-
burgh
2. Week of Jul 20th (after IETF) at Frontier Software
in Boston
It was noted that these interoperability activities
were being organized outside of the auspices of the
IETF and that Mike and Steve were reporting on their
progress as part of the IETF WG meeting.
The first draft of a token ring RMON MIB was created about
6-weeks prior to the IETF at a WG session in Fullerton CA by
combining the Novell and ProTools MIBs. This draft was
reviewed with the results described below. The goal is for
the editor to have an updated draft on the mailing list by
the middle of April, and an Internet Draft by the end of
April.
o+ ringOrder Table
The MIB editor had left out the ring-order table
because he believed the information could be
easily obtained from the ring station table. The
WG felt that the table was so useful that it was
more than worth the small amount of extra complex-
ity it added. It will be put back in.
o+ ringStationControl Table
Text needs to be added to indicated that the
ringStationControl Table and the ringStation Table
are associated (ifInterface).
o+ The MAC Address of the active monitor will be
added to the ringStationControl Table.
o+ NAUN
Needs to be added to the ringOrder Table and the
ringStation Table.
o+ Data Packet
Text needs to be added indicating that a Data
Packet is NOT a MAC Packet.
o+ tokenStats
remove the words "including those in bad MAC Pack-
ets"
o+ The AllRoutesBroadcastPckts variable was deleted
from the basic stats because it already exists in
the source routing group.
o+ host Table
Define a Station Address as "Station MAC Address
minus Source Routing Bits"
o+ matrix Table
Make sure to indicate that Station Address (MAC
Address) does NOT include Source Routing Bits
o+ MAC vs LLC
Make sure that MAC vs. LLC vs. Other is well
defined as far as packet types. The token ring
standard will be checked for the correct wording.
o+ In/out line errors
Add burst and in/out line errors (similar to bea-
cons) back into error list in the ringStation
Table, since this can improve the ability to
correctly identify a problem domain.
There was a lot of discussion about whether the TR MIB
should be usable by a non-promiscuous probe. After
much debate it was decided that token ring was signifi-
cantly different from Ethernet and that all of the use-
ful fault management and configuration info could be
acquired by just examining MAC frames (without the
overhead of promiscuous mode). Accordingly, the WG
decided to repartition the token ring MIB into (essen-
tially) four groups:
1. Promiscuous stats (frames, octets, size distri-
bution, etc.)
2. MAC layer stuff (ring station table, ring order
table, augmented with MAC layer counts which were
previously in the stats group - these would be
added to the ring station control table).
3. Ring configuration information that required
active gathering methods.
4. Source routing stats
For each entry in the History control table both a
promiscuous history and a MAC layer history (with the
same parameters) will be generated iff appropriate.
The Config table will be split into a control table
(containing the "push buttons" update-stats and
remove-station and a time of last update), and a data
table which contains the actual data. All columns must
be present in the data table, but the row only comes
into existence (or is updated) when the button is
actively pushed in the control table.
