ULE extensions

[Alain RITOUX <alain.ritoux@6wind.com>]

Hello William and all,

(I changed the title to separate thread for ULE extension, from
thread about encryption)


> Further to the extension header for ULE, 
> it can be made option as we have for destination mac address, without effecting any implementation and design 
>
> -  [Dest Mac Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx]
>
> we can change 15 bits of payload length into 14 bits.. which is much more than the present DSMCC payload/section length, which is 12 bits.
> with that bit we can define any extension header is present for any future updations to the ULE, 
> the Ext. Header is defined as
>    +---+--------+---//  ..... // ----+
>    |EHT| NHB & L| Ext.Header params  |
>    +---+--------+---//  .... // ----+
>    
>    where, EHT = 1 byte of extension header type field. Which has to be defined, might be ULE specific.
>           L   = LSB 7 bit of ext. header parameter length, i.e. supports 127 bytes.
>           NHB = MSB 1 bit contains if there is any other extension header present.
> 	  Ext.Header params = variable length based on the ext. header parameter length.

If I understand correctly, the type field in the ULE header remains
unchanged, and indicates the final payload. The EHT is from a different
namespace.

So the deal is
 (1 bit of ULE length) + (1 bit in ExtHdr length) dealed for
 (1 byte in each ExtHdr)

This seems VERY good to me.

If we also compare with Gorry's last proposal,

> < ----------------------------- SNDU ----------------------------- >
> +-+-------------------------------------------------------+--------+
> |D| Length | ENC |ETYPE |                PDU              | CRC-32 |
> +-+-------------------------------------------------------+--------+
>
> Where ENC = a predefined 2B TYPE  value, and ETYPE is the 2B type
> field Corresponding to the PDU. Several ENC values could be specified.
> Additional overhead = 2B.

it has the very same overhead, but keeps the possibility
  - to chain headers.
  - to make them blindly parsable.

Indeed if some extension are mandatory, we can still, with
this new extension model, split the naming space in 2 parts :

 <128  - Optional ExtHeader  : if unknown, skip and process next
>=128  - Mandatory ExtHeader : if unknown, drop SNDU


So I'm in favour of this 3rd extention scheme (until of course somebody
finds a way to gain one more byte ;-))

[
 And just a word about encryption : if it is done by such an ExtHdr
 format, it just has to use a "Mandatory Ext Header", and the ULE
 specs just has to define this ext mechanism. The "how" and "why"
 use encryption will not be linked to ULE, but to ULE-security-extension
 and described in the separate I-D

 please any response to this part should start an other thread
]

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