ward@hao.UUCP (Mike Ward) (04/12/84)
[]
I have been lead to believe that there is some difference between Ethernet
and the IEEE 802.3 standard. I would appreciate any comments on this,
especially pointers to reference material.
--
Michael Ward, NCAR/SCD
UUCP: {hplabs,nbires,brl-bmd,seismo,menlo70}!hao!ward
BELL: 303-497-1252
USPS: POB 3000, Boulder, CO 80307rpw3@fortune.UUCP (04/14/84)
#R:hao:-91700:fortune:5900014:000:3646
fortune!rpw3 Apr 13 19:35:00 1984
IEEE 802.3 vs. Ethernet.
If you look at 802.3 (the one I reference is Draft C, Dec'82), they may
seem on the surface to be different, but practically speaking, as long
as you are using the options ("implementation choices") that correspond
to Ethernet, there is only one apparently irreconcilable difference, and
that one can be freebled (see below). So, in practice, they are the same.
(Manufacturers of Ethernet controllers (V 2.0) who claim IEEE 802.3
compatibility are not lying.)
First, note that Version 2.0 of the Ethernet D/I/X spec DID contain several
changes from the 1.0 spec, some of which were to bring it more closely in
line with 802.3. The most noted differences are the addition of the
transceiver "heartbeat" (collision-detect testing) [which was discussed in
an earlier note], and the tightening of the transceiver drive current spec
(to allow repeaters to work).
The big difference: In the packet frame where Ethernet calls for the
"type field", 802.3 calls for a "length field". (The D/I/X spec calls
for length to be determined from the actual duration of the packet.)
Now this would be "terrible", except that:
1. The 802.3 length field must be valid for the frame to be
received. (46 <= "valid" <= 1518). Seeing a frame with an
invalid length field may cause the network error counts of
an 802.3 system to go up, but it does no harm. The standard
requires the controller to ignore such frames (except for
counting them).
2. All of the Xerox-registered XNS types are INVALID length fields
(0x600 = 1536, or greater, when read with the 802.3 byte order).
[The exception, 0x200 = Experimental PUP, is not an official number.]
Xerox has now permanently reserved all "types" which look like
valid 802.3 length fields to be "802.3-specific types".
3. Therefore, Ethernet software can be written to handle both.
(802.3 software cannot handle Ethernet packets, but as long
as the Ethernet stations can send/receive to/from the 802.3
guys, who cares?)
<<FLAME ON>>
The entire history of the internetwork datagram "style" has shown the very
real practical importance in each protocol layer of a type field which has
a reserved location but which is otherwise uninterpreted by that layer.
This allows multiple protocols of level "N" to share a common level "N-1"
protocol. Examples: The XNS and DoD IP/TCP protocol suites can cheerfully
co-exist on the same physical Ethernet cable, since they have different
frame (packet) types. Other, experimental, or proprietary protocols can
likewise share with the XNS & IP/TCP families. Many DIFFERENT transport
protocols share the XNS ITP datagram protocol; likewise several transport
protocols share the DoD IP protocol.
Why the IEEE 802 committee decided to abandon this important principle
is beyond me. (Probably because they, like many standards bodies before
them, cannot tolerate the pluralism of multiple protocol suites, but must
insist on ONE "right" way to do it. Pessimistic prediction: Look for a SINGLE
permitted type in the next layer standard.)
<<FLAME OFF>>
In any case, from the point of view of Ethernet, those length fields are
just 1518-46+1 new "types" (one for each length), and so can be accommodated.
(Showing the robustness of the "type" mechanism. QED.)
All of the hardware vendors I know of are advertising "IEEE 802.3/Ethernet
compatible". And they are right. (And anybody who builds 802.3-only gear
is just being petty.)
Rob Warnock
UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065