[mod.protocols.tcp-ip] the length of 802.3 + 802.2 header

Provan@LLL-MFE.ARPA (08/21/86)

this isn't quite the right mailing list for this, but i'm sure i'll get
a correct answer from someone reading this...

i've gone over it a hundred times, and i swear the length of the header
on an 802.2 type 1 packet is 17 bytes: 14 bytes for the 802.3 (aka
"ethernet") header and 3 bytes for the 802.2 header.  that is, the data
will begin at byte number 18 (if the first byte is "1") of the
transmitted packet.  maybe it's my ARPAnet training, but a header with
an odd number of bytes is so incredible that i just can't believe it.
could someone please confirm that this is, in fact, correct, or, even
better, point out where i'm making my mistake and show me why it's
really an even number?  i'd appreciate it.
							don

jas@BRUBECK.PROTEON.COM (08/22/86)

Your measurements of the length of a LLC Class 1 header are completely
correct. It is 3 bytes long!

This is all in the spirit of the ISO OSI protocol families. No attempt is
made in any of the protocols to preserve 'nice' alignment of fields longer
than one byte. Perhaps they consider density more important than performance.
Remember that on X.25 in Europe you often pay by the byte. The Connectionless
Internet protocol has a very small fixed-format header, which does not
even contain the destination address. Since the destination address is
variable-length, it is the variable part of the header.

In general, the first code any ISO OSI implementor has to write is the
stuff that serially parses the headers. Most of the variable length fields
are of the format:
	byte	type
	byte	length
	var	data[]
You parse them serially, from beginning to end.

Given this mindset, the 802.2 people probably saw no reason to have an
even length header, as things would get odd soon enough. Also, why waste
a byte.

As for those of us who designed protocols for efficiency, we're out of
luck. One strategy is to receive 802.2-grams on an odd boundary, so that
the LLC1/IP pairing will wind up well aligned. Other protocols don't
care, so this wins.

(Just for more fun, when you use the SNAP protocol for extending
the protocol ID [ie. SAP], the header becomes even length again. Aauugh!)

					john shriver
					proteon

p.s. I suspect the whole 802.2 mess will be one of the active discussion
topics at the Implementor's Workshop...
-------

jqj@GVAX.CS.CORNELL.EDU (J Q Johnson) (08/23/86)

I don't completely see why the fuss over odd sized headers.  Presumably,
the encapsulation of the contained protocol is a separate standardization
issue from the header formats.  Just as 4.2bsd chose a nonobvious
encapsulation for ip on Ethernet (trailers), we could legislate that
ip under 802.2 is required to include an adequate number of pad bytes
to force word (or whatever) alignment.  I don't care much if OSI IP is
slow -- I plan to continue to run tcp/ip at least until it becomes
feasible to put a barrel shifter in my Ethernet interfaces!  However,
I will need to use 802.2 and saps as transports...