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

Re: ULE Extension Headers



Hi William,

First thanks, for drafting. I have seval concerns :

- Destination Address Field

You propose to make it become one of the extension headers, and I
admit I had the same idea, but I think extension headers should
be reserved for additinal data that are not usually present in SNDU,
because such mechanism has an extra cost (2 bytes).

The current definition of ULE, makes the Dest Add field a MUST for all
unicast traffic. So the bit gained in ULE header finally gives extra
overhead of 2 bytes, and if it is for 90% (no idea about the value ;-))
of ULE SNDU, it's an heavy cost.

So I would be in favour of keeping the destination Address bit,
and create th Extension header bit separate (i.e. stealing one more
bit from length field).

- The Ext Header format

Why 4 bits for ext header type ? It makes following info (length, data
..) not aligned on byte boundary. I would prefer 8 bits type.

- The Ext Header Processing

You state that ext header processing (I mean internal processing, not
blind parse) is not mandatory, but I think that ext header that changes
payload semantic should be made mandatory (i.e. cause the SNDU to be
dropped if type is not known).
For that I would propose (with an 8 bit type) to split ext header type
byte in
  1 bit do idicate behaviour (drop/process next)
  7 bits for exte headertype itself





... snip ...
        4.5 Type Field
        <no change>, Even if the extension headers are present, the Type Field
carries the final SNDU payload type, i.e. even the payload is scrambled
        IP packet, it SHOULD have the value of 0x0800 in case of IPv4
==> it MUST have the value of 0x800 in case of IPv4



        4.6.2 Next Extension header present field

        The most significant bit of the extension header Length Field carries
        the value of the Next Extension Header Present Field, the N-bit.
        A Value of 0 indicates the absence of next extension header. Otherwise
        a value of 1 indicates presence of extension header.

        By default, the N-bit value MUST be set to a value 0. i.e.
        next extension header doesn't exist.
Wherever this bit is, it would be better to have the ULE-end-indicator /
padding values, make this bit tell "no extension headers"

So the opposite value would do it:

  A Value of 1 indicates the absence of next extension header. Otherwise
  a value of 0 indicates presence of extension header.

  By default, the N-bit value MUST be set to a value 0. i.e.
  next extension header doesn't exist.



        4.6.3 Extension header Length

	The 7-bit value that indicates the extension header value length, in bytes,
        for the Extension header of ULE.
Precision to add : This Length does NOT include the first two bytes of
Extension Header (type-length pair).


Cheers.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com