Corrections/Evolutions for ULE draft (Ethernet type codes)
gorry at erg.abdn.ac.uk
Mon Sep 1 18:41:40 BST 2003
Ethertypes were originally by Xerox under the DIX framewwork.
After sepcification of IEEE 802.3, Ethertypes less than 1500,
became a length indicator that was user to discriminate LLC frames.
Hence any Ethertype <= 1500 is an LLC frame, and the Ethertype value
indicates the LENGTH of the payload.
Historic note, when this was done, some protocols had DIX Ethertypes
less than 1500, these were re-assigned to the IEEE, and new values
allocated for the protocols.
So, if we adopt this scheme, all values less than 1500 would be
IANA assigned (if we can get the IETF to agree) and all values
above 1500 would follow the IEEE/DIX type assignments for Ethernet.
If we wished to support LLC - then we would add one IANA assigned
type to indicate this, and the Length would already be carried in
the SNDU header - there are no we have two separate realms.
Alain RITOUX wrote:
> Gorry Fairhurst wrote:
>> A) OK. so my take on the type field is:
>> (i) I don't worry about using 1B rather than 2B for a type field.
>> There's no
>> real added CPU cost, and the extra bandwidth consumed on the link is
>> for just one byte. I vote we stick for 2B.
>> (ii) I like Ethernet-style type fields, because most devices
>> communicate using
>> these values, it's easy to find the appropriate set of types, and
>> they cover
>> most uses - albeit no support for ROHC, etc, as in (thread below).
>> (iii) Finally, I note there is an overlap in function in ULE and also
>> in the
>> alterantive ID on encapsulation. Both current specs include
>> separate length and type fields. If the type field is small,
>> then this also indicates length (according to IEEE 802 LLC).
>> So, the SNDU would have two length fields. I don't like this
>> - it gives the opportunity for one of these values
>> to be wrong - always risky for an implementation.
> I don't understand the link between type field and length ? maybe because
> niot really familiar with LLC.
>> So, I propose we re-define the type field this way:
>> Small type values: IANA Assigned, using a registry.
>> - In this space we may define any other specific type we need.
>> Examples are:
>> LLC header follows in SNDU
>> Control packet for link testing ROHC type ***if***
>> required, ***and*** no Ether type assigned
>> Large type values: To follow DIX/IEEE assignements (not using LLC).
>> Is this clever /stupid /ok?
> To have separate realms, is good for we don't have to rely on missing
> to be defined elsewhere and allows to keep ether-like type to be used, so
> keeping ythis encpas wide open for many things, wiothotu any new stuff
> to be
> defined ;-)
> So that's fine for me, but how do we see wether a type field is small or
> big type ? is there for example a first byte value forbidden in
> ether-type ?
> About control packets for link testing, what do you have in mind ? for I
> wouldn't go into the PPP-LCP-NCP direction ...
>> B) Now, the length issue:
>> OK, so we could argue about whether MPEG-2 will ever be at the "core"
>> or not, but the key point was that if ***ANY*** parts of the Internet
>> evolve to use a large PMTU, then it would be better to allow it over
>> If this happens to be a satellite link, the larger MSS would
>> benefit TCP. Since the IETF has started work on next generation PMTUD,
>> we should allow operators in future support this. In short:
> Yep, if no link provides it, MTU will never increase :-( with what
> i've heard
> about some errors, I'm fine wiht 16 K. so wiith this the 2 MSB of this
> field should be defined as : MUST be set to 0 by the sender, and MUST be
> ignored by the receiver.
More information about the Ip-dvb