As per Relevance of the word software, we have this rfc below:
Network Working Group F.
Request for Comments: 1369 FTP
October 1992
Implementation Notes and Experience
The Internet Ethernet
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
Table of
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.
The Ethernet MIB Working group has been tasked with the following
work items
1) Develop a document explaining the rationale for
MANDATORY status to MIB variables which are optional
the relevant IEEE 802.3 specification (the
basis for the Internet Ethernet MIB). This shall not be
standards-track document
(2) Develop an implementation report on the Ethernet MIB
This report shall cover MIB variables which
implemented in both Ethernet interface chips, and
software (i.e., drivers), and discuss the
pertaining to both. This report shall also
field experience with the MIB variables,
concentrating on those variables which are in dispute
This document shall not be a standards-track document
While the Ethernet MIB is progressing through
standardization process, this document shall
periodically updated to reflect the latest
and operational experience
Kastenholz [Page 1]
RFC 1369 Ethernet MIB Implementations October 1992
This document reflects the currently known status of 11
implementations of the MIB by 7 different vendors on 7
Ethernet interface chips
2.
There are some interesting points to be noted from this information
1) Only 4 variables are actually implemented in
implementations: AlignmentErrors, FCSErrors
ExcessiveCollisions and InternalMacTransmitErrors
2) There were another five variables implemented in all
one of the reported implementations
SingleCollisionFrames, MultipleCollisionFrames
LateCollisions, FrameTooLongs, and CarrierSenseErrors
Three of these variables exist in implementations
use the same chip as the implementation that does
contain the variable. Specifically
A) SingleCollisionFrames is not implemented
implementation number 3, which uses the AMD LANCE
However, other AMD LANCE implementations (7, 8, and 10)
do implement the variable, implying that it
available on the LANCE
B) MultipleCollisionFrames is not implemented
implementation number 3, which uses the AMD LANCE
However, other AMD LANCE implementations (7, 8, and 10)
do implement the variable, implying that it
available on the LANCE
C) LateCollisions is not implemented in
number 1, which uses the Intel 82586. However,
Intel 82586 based implementation (11) does
the variable, implying that it is available on
Intel 82586.
D) CarrierSenseErrors is not implemented on
number 2, which is based on the Fujitsu 86950 chip
However, there is only one implementation based on
chip and I have not been able to locate a data sheet
this part so no conclusion can be drawn at this time
E) FrameTooLongs is not implemented on
number 5, which is based on the National NIC 8390 chip
However, there is only one implementation based on
Kastenholz [Page 2]
RFC 1369 Ethernet MIB Implementations October 1992
chip and I have not been able to locate a data sheet
this part. It should also be noted that this
is easily maintained by software as a "driver-level
function
(3) Of the 22 variables in the MIB, 11, or 1/2 of
variables, were implemented in about 1/2 or less of
implementations
4) The number of variables implemented per
ranges from a low of 11 to a high of 16. The
number of variables truly implemented is 12.8.
5) The IEEE 802.3 encapsulation-specific
(InRangeLengthErrors, and OutOfRangeLengthFields) are
2 and 0 implementations respectively
3.
From this, the author concludes that
The control variables (IntializeMAC, etc.) are not
implemented, but this may be due to an aversion to
writable variables until security is in place
One vendor has stated that the reason that these variables were
implemented was that the vendor did not believe the variables to
useful, and that they were hard to implement. Furthermore,
vendor has recommended dropping the variables entirely
The two IEEE 802.3 encapsulation variables (InRangeLengthErrors
OutOfRangeLengthFields) are barely implemented. In Santa Fe,
Working group discussed moving them to an optional, 802.3 specific
group. The author believes that this is justified by
implementation data
The collision histogram variables are also barely implemented.
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
InternalMacReceiveErrors) are in 8 or 9 implementations
Kastenholz [Page 3]
RFC 1369 Ethernet MIB Implementations October 1992
It should be noted that one of the two systems that do not
DeferredTransmissions is based on the AMD LANCE, and other AMD
based systems do implement this counter, leading to the
that DeferredTransmissions could easily be on all but one of
implementations
The other such variable, InternalMacReceiveErrors, is a
catchall for all other errors. If no other errors are detected by
hardware or software then returning 0 for the counter is
acceptable
This all seems to imply either
1) Splitting the statistics group into two groups, one
which is optional and contains SQETestErrors
ExcessiveDeferrals,
2) Eliminating SQETestErrors and ExcessiveDeferrals)
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
may not be appropriate to call this widespread implementation
However, it seems to be safe to conclude that the non-
of these variables is due to local implementation
rather than a fundamental lack of support for the variable
4. Final
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
standard mib. There are effectively no
of this object, and some chips were reported to return
incorrect value for the TDR count
2) The dot3StatsInRangeLengthErrors object and
dot3StatsOutOfRangeLengthFields object will be
from the MIB. These objects were not widely
and their utility in diagnosing network problems
strongly questioned
3) The dot3InitializeMac object, the dot3
object, the dot3MulticastReceiveStatus object, and
dot3TxEnabled object will be deprecated from the MIB
These objects were not widely implemented and
utility in diagnosing network problems was
Kastenholz [Page 4]
RFC 1369 Ethernet MIB Implementations October 1992
questioned
4) The dot3StatsExcessiveDeferrals object will be
from the MIB. Only one system implemented this object
Furthermore, its exact definition was called into question
5) The dot3StatsSQETestErrors object received
implementations. However, the working group
supported its retention in the MIB on the basis
certain forms of transceiver and cable errors that
not uncommon can only be detected with this counter
6) The collision histogram table (dot3CollTable) will
kept as an optional group, even though the objects
not widely implemented nor is there hardware support
all reported chips
5. Implementation
The following raw data has been provided by vendors, each
an implementation of the Ethernet MIB. Each reported
has a separate column in the following table. For
implementation/MIB Variable, a single character code has been
indicating the rough implementation status of the variable.
codes are
Y Fully implemented, reports a truthful count,
indication of state. All values may be written to
variable with the expected action occurring
N Not implemented at all. Would return a noSuchName
if accessed
C Implemented but returns a constant value for gets
returns a badValue error for any set attempt to set
variable to a value other than this constant (
variables only).
Kastenholz [Page 5]
RFC 1369 Ethernet MIB Implementations October 1992
MIB
Variable 1 2 3 4 5 6 7 8 9 10 11
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
collision
2 Not supported by the chip, detected solely in software
3 But set to disabled(2) ->
4 Underlying TDR function not implemented on this chip
5 Only counts frames too short though
6 Due to Ethernet
7 Implementation does not support set operations
reports the correct value for these
Kastenholz [Page 6]
RFC 1369 Ethernet MIB Implementations October 1992
The implementations are
Implementation Vendor
1 1 Intel 82586
2 1 Fujitsu 86950
3 2
4 3 AMD
5 4 National NIC 8390
6 4 Intel 82596
7 4 AMD
8 5 AMD
9 5 AMD
10 6 AMD
11 7 Intel 82586
6. Security
Security issues are not discussed in this memo
7. Author's
Frank J.
FTP
2 High
North Andover Mass 01845
Phone: 508-685-4000
EMail: kasten@ftp.
Kastenholz [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
