Re: ULE Extension Headers

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

There's lots of ideas in here.  Here are my thoughts for the melting pot...

Alain RITOUX wrote:

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

I agree, it is common to have a destination address.
It also is one that could in future  be deserving of hardware support
- that's also a (small) motive for a fixed position within the header.

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

Yes - there's a processor cost in this. Is there also cost in a one-bit flag
to indicate extensions present - which has to be parsed every SNDU?

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

Yes - but we already have these (mandatory) extensions supported using
the private (IANA assigned) Type field, as in bridging.

I do like Bernhard's email suggesting a renaming of the current Type-1 
field as
"next-header", I was unhappy with the names Type-1 and Type-2.

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