Implementation Notes and Experience for the Internet Ethernet MIB
A 1992 report on which Ethernet MIB variables vendors actually built, and what the working group decided to drop.
Kastenholz, F., "Implementation Notes and Experience for the Internet Ethernet MIB", RFC 1369, DOI 10.17487/RFC1369, October 1992, <https://www.rfc-editor.org/info/rfc1369>.
@misc{rfc1369,
series = {Request for Comments},
number = 1369,
howpublished = {RFC 1369},
publisher = {RFC Editor},
doi = {10.17487/RFC1369},
url = {https://www.rfc-editor.org/info/rfc1369},
author = {F. Kastenholz},
title = {{Implementation Notes and Experience for the Internet Ethernet MIB}},
pagetotal = 7,
year = 1992,
month = oct,
} RFC text
Contents
Network Working Group F. Kastenholz
Request for Comments: 1369 FTP Software
October 1992
Implementation Notes and Experience for
The Internet Ethernet MIB
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Table of Contents
1. Introduction ................................................ 1
2. Observations ................................................ 2
3. Conclusions ................................................. 3
4. Final Action ................................................ 4
5. Implementation Data ......................................... 5
6. Security Considerations ..................................... 7
7. Author's Address ............................................ 7
1. Introduction
The Ethernet MIB Working group has been tasked with the following two
work items:
1) Develop a document explaining the rationale for assigning
MANDATORY status to MIB variables which are optional in
the relevant IEEE 802.3 specification (the technical
basis for the Internet Ethernet MIB). This shall not be a
standards-track document.
(2) Develop an implementation report on the Ethernet MIB.
This report shall cover MIB variables which are
implemented in both Ethernet interface chips, and in
software (i.e., drivers), and discuss the issues
pertaining to both. This report shall also summarize
field experience with the MIB variables, especially
concentrating on those variables which are in dispute.
This document shall not be a standards-track document.
While the Ethernet MIB is progressing through the
standardization process, this document shall be
periodically updated to reflect the latest implementation
and operational experience.
This document reflects the currently known status of 11 different
implementations of the MIB by 7 different vendors on 7 different
Ethernet interface chips.
2. Observations
There are some interesting points to be noted from this information:
1) Only 4 variables are actually implemented in all
implementations: AlignmentErrors, FCSErrors,
ExcessiveCollisions and InternalMacTransmitErrors.
2) There were another five variables implemented in all but
one of the reported implementations,
SingleCollisionFrames, MultipleCollisionFrames,
LateCollisions, FrameTooLongs, and CarrierSenseErrors.
Three of these variables exist in implementations that
use the same chip as the implementation that does not
contain the variable. Specifically:
A) SingleCollisionFrames is not implemented in
implementation number 3, which uses the AMD LANCE.
However, other AMD LANCE implementations (7, 8, and 10)
do implement the variable, implying that it is
available on the LANCE.
B) MultipleCollisionFrames is not implemented in
implementation number 3, which uses the AMD LANCE.
However, other AMD LANCE implementations (7, 8, and 10)
do implement the variable, implying that it is
available on the LANCE.
C) LateCollisions is not implemented in implementation
number 1, which uses the Intel 82586. However, another
Intel 82586 based implementation (11) does implement
the variable, implying that it is available on the
Intel 82586.
D) CarrierSenseErrors is not implemented on implementation
number 2, which is based on the Fujitsu 86950 chip.
However, there is only one implementation based on this
chip and I have not been able to locate a data sheet on
this part so no conclusion can be drawn at this time.
E) FrameTooLongs is not implemented on implementation
number 5, which is based on the National NIC 8390 chip.
However, there is only one implementation based on this
chip and I have not been able to locate a data sheet on
this part. It should also be noted that this variable
is easily maintained by software as a "driver-level"
function.
(3) Of the 22 variables in the MIB, 11, or 1/2 of the
variables, were implemented in about 1/2 or less of the
implementations.
4) The number of variables implemented per implementation
ranges from a low of 11 to a high of 16. The average
number of variables truly implemented is 12.8.
5) The IEEE 802.3 encapsulation-specific variables
(InRangeLengthErrors, and OutOfRangeLengthFields) are in
2 and 0 implementations respectively.
3. Conclusions
From this, the author concludes that:
The control variables (IntializeMAC, etc.) are not widely
implemented, but this may be due to an aversion to implementing
writable variables until security is in place.
One vendor has stated that the reason that these variables were not
implemented was that the vendor did not believe the variables to be
useful, and that they were hard to implement. Furthermore, this
vendor has recommended dropping the variables entirely.
The two IEEE 802.3 encapsulation variables (InRangeLengthErrors and
OutOfRangeLengthFields) are barely implemented. In Santa Fe, the
Working group discussed moving them to an optional, 802.3 specific,
group. The author believes that this is justified by this
implementation data.
The collision histogram variables are also barely implemented. They
should be in their own optional group -- and they are.
Of the remaining 13 statistical variables, 9 of them are in 10 or 11
implementations. This is good.
Two of them (SQETestErrors and ExcessiveDeferrals) are in 3 and 1
implementations, respectively. This is bad.
The remaining variables (DeferredTransmissions and
InternalMacReceiveErrors) are in 8 or 9 implementations.
It should be noted that one of the two systems that do not implement
DeferredTransmissions is based on the AMD LANCE, and other AMD LANCE
based systems do implement this counter, leading to the conclusion
that DeferredTransmissions could easily be on all but one of the
implementations.
The other such variable, InternalMacReceiveErrors, is a general
catchall for all other errors. If no other errors are detected by the
hardware or software then returning 0 for the counter is perfectly
acceptable.
This all seems to imply either:
1) Splitting the statistics group into two groups, one of
which is optional and contains SQETestErrors and
ExcessiveDeferrals, or
2) Eliminating SQETestErrors and ExcessiveDeferrals) from
the MIB.
The variables with 8 or 9 implementations are a bit more problematic.
They are implemented in more than 2/3s of the implementations, but it
may not be appropriate to call this widespread implementation.
However, it seems to be safe to conclude that the non-implementations
of these variables is due to local implementation considerations
rather than a fundamental lack of support for the variable.
4. Final Action
After consideration at the San Diego IETF Meeting on 17 March 1992,
the Ethernet MIB Working Group made the following recommendations:
1) The dot3TestTdrValue object will be deprecated from the
standard mib. There are effectively no implementations
of this object, and some chips were reported to return an
incorrect value for the TDR count.
2) The dot3StatsInRangeLengthErrors object and the
dot3StatsOutOfRangeLengthFields object will be deprecated
from the MIB. These objects were not widely implemented
and their utility in diagnosing network problems was
strongly questioned.
3) The dot3InitializeMac object, the dot3MacSubLayerStatus
object, the dot3MulticastReceiveStatus object, and the
dot3TxEnabled object will be deprecated from the MIB.
These objects were not widely implemented and their
utility in diagnosing network problems was strongly
questioned.
4) The dot3StatsExcessiveDeferrals object will be deprecated
from the MIB. Only one system implemented this object.
Furthermore, its exact definition was called into question.
5) The dot3StatsSQETestErrors object received few
implementations. However, the working group strongly
supported its retention in the MIB on the basis that
certain forms of transceiver and cable errors that are
not uncommon can only be detected with this counter.
6) The collision histogram table (dot3CollTable) will be
kept as an optional group, even though the objects are
not widely implemented nor is there hardware support on
all reported chips.
5. Implementation Data
The following raw data has been provided by vendors, each developing
an implementation of the Ethernet MIB. Each reported implementation
has a separate column in the following table. For each
implementation/MIB Variable, a single character code has been entered
indicating the rough implementation status of the variable. These
codes are:
Y Fully implemented, reports a truthful count, or
indication of state. All values may be written to the
variable with the expected action occurring.
N Not implemented at all. Would return a noSuchName error
if accessed.
C Implemented but returns a constant value for gets and
returns a badValue error for any set attempt to set the
variable to a value other than this constant (writable
variables only).
MIB Implementation
Variable 1 2 3 4 5 6 7 8 9 10 11 Yesses
InitializeMac C C Y Y Y Y Y C7 C7 N Y 6
MacSubLayerStatus C C Y Y Y Y Y C7 C7 N C 5
MulticastReceiveStatus C C Y C3 Y C C C7 C7 N C 2
TxEnabled C C Y Y Y Y Y C7 C7 N C 5
TestTdrValue C 1 C C4 C C C C4 C4 N C 1
AlignmentErrors Y Y Y Y Y Y Y Y Y Y Y 11
FCSErrors Y Y Y Y Y Y Y Y Y Y Y 11
SingleCollisionFrames Y Y Y N Y Y Y Y Y Y Y 10
MultipleCollisionFrames Y Y Y N Y Y Y Y Y Y Y 10
SQETestErrors Y C C C Y C C C C Y C 3
DeferredTransmissions Y C Y N Y Y Y Y Y Y Y 9
LateCollisions C Y Y Y Y Y Y Y Y Y Y 10
ExcessiveCollisions Y Y Y Y Y Y Y Y Y Y Y 11
InternalMacTransmitErrors Y Y Y Y Y Y Y Y Y Y Y 11
CarrierSenseErrors Y C Y Y Y Y Y Y Y Y Y 10
ExcessiveDeferrals C C Y C C C C C C N C 1
FrameTooLongs Y Y2 Y Y C Y Y Y Y Y Y 10
InRangeLengthErrors C C C N5 C Y Y C C N C 2
OutOfRangeLengthFields C C C C6 C C C C C N C 0
InternalMacReceiveErrors Y Y Y Y Y C C Y Y Y C 8
CollCount Y Y C N N N N C C N Y 3
CollFrequencies Y Y C N N N N C C N Y 3
Yesses 13 11 16 11 15 14 14 11 11 12 13
Notes:
1 does not implement TDR test, but reports TDR from last
collision!
2 Not supported by the chip, detected solely in software.
3 But set to disabled(2) -> badValue
4 Underlying TDR function not implemented on this chip.
5 Only counts frames too short though.
6 Due to Ethernet encapsulation
7 Implementation does not support set operations but
reports the correct value for these.
The implementations are:
Implementation Vendor Chip
1 1 Intel 82586
2 1 Fujitsu 86950
3 2 Sonic
4 3 AMD Lance
5 4 National NIC 8390C
6 4 Intel 82596
7 4 AMD Lance
8 5 AMD Lance
9 5 AMD ILACC
10 6 AMD Lance
11 7 Intel 82586
6. Security Considerations
Security issues are not discussed in this memo.
7. Author's Address
Frank J. Kastenholz
FTP Software
2 High Street
North Andover Mass 01845
Phone: 508-685-4000
EMail: kasten@ftp.com
AI ELI5
On this page
§1Purpose of the Report
The Ethernet MIB Working Group was given two tasks: explain why some variables that are optional in the IEEE 802.3 specification got MANDATORY status in the Internet Ethernet MIB, and produce an implementation report. Neither document is on the standards track.
The report covers variables implemented in Ethernet interface chips and in software drivers, and summarizes field experience, especially for variables in dispute. It reflects 11 implementations of the MIB by 7 vendors on 7 Ethernet interface chips, and was meant to be updated while the MIB moved through standardization.
Some companies built the same set of Ethernet counters. This paper checks which ones they really built so the list can be made sensible.
§2Observations from the Data
Only 4 variables are implemented in every implementation: AlignmentErrors, FCSErrors, ExcessiveCollisions and InternalMacTransmitErrors. Five more are in all but one: SingleCollisionFrames, MultipleCollisionFrames, LateCollisions, FrameTooLongs and CarrierSenseErrors.
Where a variable is missing from one implementation, the author often finds the same chip supports it elsewhere. For example, implementation 3 lacks SingleCollisionFrames although other AMD LANCE implementations (7, 8 and 10) have it, so the chip can provide it. FrameTooLongs is easily kept by software as a driver-level function.
Of the 22 variables, 11 were implemented in about half or fewer of the implementations. Each implementation provides between 11 and 16 variables, an average of 12.8. The two IEEE 802.3 encapsulation-specific variables appear in 2 and 0 implementations.
Only a few counters were built by everybody. When one company skipped a counter that others built on the same chip, it was usually just a choice, not a limit of the hardware.
§3Conclusions
The control variables such as InitializeMac are not widely implemented, possibly because vendors avoid writable variables until security is in place. One vendor found them hard to implement and not useful, and recommended dropping them.
The two 802.3 encapsulation variables and the collision histogram variables are barely implemented. The author supports moving the first pair to an optional group, and the histogram variables already sit in their own optional group.
Of the remaining 13 statistical variables, 9 are in 10 or 11 implementations. SQETestErrors and ExcessiveDeferrals are in 3 and 1. DeferredTransmissions and InternalMacReceiveErrors are in 8 or 9, which the author attributes to local implementation choices rather than a lack of support. The suggested options are to split the statistics group so the two rare variables are optional, or to remove them.
Counters that nearly everyone built are clearly useful. Counters almost nobody built might belong in an optional bin, or be thrown out.
§4Final Action
At the San Diego IETF Meeting on 17 March 1992 the working group made six recommendations:
dot3TestTdrValueis deprecated; it has effectively no implementations and some chips return a wrong value.dot3StatsInRangeLengthErrorsanddot3StatsOutOfRangeLengthFieldsare deprecated.dot3InitializeMac,dot3MacSubLayerStatus,dot3MulticastReceiveStatusanddot3TxEnabledare deprecated.dot3StatsExcessiveDeferralsis deprecated; only one system implemented it and its definition was questioned.dot3StatsSQETestErrorsis kept, because some transceiver and cable errors can only be detected with this counter.- The collision histogram table
dot3CollTablestays as an optional group.
The group threw out the counters nobody used, but kept one rarely built counter because it catches problems nothing else can.
§5The Implementation Table
The raw data is a table with one column per implementation and one row per MIB variable. Each cell is a code: Y for fully implemented, N for not implemented (it would return a noSuchName error), and C for implemented but returning a constant, with a badValue error for any set to a different value.
Footnotes explain quirks, such as an implementation that does not run a TDR test but reports the TDR value from the last collision, or one that detects a variable solely in software. The chips listed include the Intel 82586, Fujitsu 86950, Sonic, AMD Lance, National NIC 8390C, Intel 82596 and AMD ILACC. The memo says security issues are not discussed.
A big grid shows each company down one side and each counter across the top, with a letter saying whether the counter really worked, was missing, or was faked with a fixed number.
- YFully implemented — Reports a truthful count or state; writable variables accept all values.
- NNot implemented — Would return a noSuchName error if accessed.
- CConstant — Returns a constant for gets and a badValue error for sets to any other value.