[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Corrections/Evolutions for ULE draft (Ethernet type codes)


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.

Gorry

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 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.