Corrections/Evolutions for ULE draft (Ethernet type codes)

[Alain RITOUX]

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 
> marginal
> 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 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
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 
> MPEG-2.
> 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 
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.

Cheers.
Alain.