Corrections/Evolutions for ULE draft (Ethernet type codes)
alain.ritoux at 6wind.com
Mon Sep 1 17:41:30 BST 2003
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
> 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 types
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
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
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 significantly
> 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
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