Re: fddi encapsulation woes

[Dave Katz <[e-mail]>]

>Several vendors have proposed that IEEE 802.x traffic (e.g. OSI) on FDDI
>be carried as:
>
>    MAC header | length | 802.x packet ...
 
I'd be interested to hear who is proposing this...
 
The length field is present in 802.3 because, unlike all other 802
media (and FDDI), the information length is not self-encoding (due to the
need to pad to a minimum frame size).  There is no architectural reason
why the information length should be explicitly carried - the hardware
will tell you (after subtracting frame overhead).

I would make the claim that standardization of such a field belongs
to ANSI, as it is outside the 802 headers and protocols.  Adding this
field will be an utter disaster unless it is standardized by ANSI
(and it seems like a bad idea to me).

Allowing both framing conventions would be a *terrible* idea, assuming
that it was possible to differentiate the two formats dynamically, which
it's not, assuming that 802.2 is used for more than just Ethernet encapsulation
and OSI.

The trends regarding 802.3 vs. Ethernet on bridges to FDDI is that the SNAP
format with OUI=0-0-0 means encapsulated Ethernet, and anything else is
802.3.  Thus, anything running on an LSAP other than hex 'AA' ends up
as 802.3.  This works reversibly as long as the SNAP/0-0-0 format is not
used on 802.3 (which, in general, it is not, although I've heard that
Appletalk II is doing this).  IP stations that use 802.3/RFC1042 framing
need to be able to receive both types of framing in the face of bridges
(I believe that this will be mandated when the 1042 revision is complete).