Re: ULE extension headers

["Marie-Jose Montpetit" <mariejose.montpetit@verizon.net>]

I also had thought of IPv6 type extensions and I believe have something written somewhere about it. I think the experimental values are fine as I would like to use some of this to "try" things out for address resolution and QoS support and control services related to onboard processing satellites and broadband wireless networks.

Marie-Jose
----- Original Message ----- 
From: <alain.ritoux@6wind.com>
To: <ip-dvb@erg.abdn.ac.uk>
Sent: Tuesday, February 10, 2004 3:25 AM
Subject: ULE extension headers


>
>
> Marie-Jose Montpetit wrote:
>
> > I support the adoption of the ID as WG document. I also suggest for
point 5)
> > extension headers in ULE for future services.
> >
>
> I agree with an extension header for future services.
>
> I would propose to do it in an IPv6-style, using some values in the 
> 1-1500 part of next header, to signal the extention header(s). Such 
> headers could then have a fixed and well known begining :
>     +---+---+---+--//  ..... // ----+
>     |   NH  | L |  extension value  |
>     +---+---+---+--//  ..... // ----+
>
>   NH : 2 bytes, defines the type of next field which could then be,
>        a classical ULE payload (0x800 for IPv4 ...) or even another
>        extension header.
>   L  : length in bytes of the header.
>
> Even some values range could be reseved for that purpose, that would 
> allow implementation to be compatible with still not known extensions. 
> And even that would indicate the behaviour if extension is not known.
>
> exemple :
> 1280 <= type field < 1304  :  optional extension, if not known,
>                                just skip  and process next 1304 <= 
> type field < 1408  :  critical extension, if not known, stop
>                                processing, drop ULE SNDU, and possibly
>                                report an error to emitter
>                               (if possible, but how ??, usefull ??,  
> ..)
>
> I chose those values as exemple because
>    - they are in the 1-500 range
>    - they have a nice bit pattern and can be checked with a single AND
>
>
> Still about the type field :
> I think it would be good to reseve a certain range of these values, 
> for experimental uses, which would garanty  that (if respected ;-))) 
> there would be no conflict with due reserved values. 1408 <= type 
> field < 1472  :  reseved for experimental purpose, In
>                                operational use, such SNDU MUST be
>                                silently dropped.
>
> All this is very little implementation and keeps the door opened for 
> any future services.
>
> Your thoughts about this ?
>
> Regards.
> Alain.
> --
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com
>
>