Re: ULE extensions

["William StanisLaus" <williams77@rediffmail.com>]

Hi Alain and all,

I have a small concern here on 

> > < ----------------------------- SNDU ----------------------------- >
> > +-+-------------------------------------------------------+--------+
> > |D| Length | ENC |ETYPE |                PDU              | CRC-32 |
> > +-+-------------------------------------------------------+--------+
here, always ENC which is 2 bytes wasted even if we don't support ULE encryption. Also there is no provision for future extension of any other informations which can be added to the ULE header, say for example LLC_SNAP support, Section number(in case if any one of the intermediate MPEG1-TS packet is lost for a particular SNDU, Receiver can request that particular SNDU from the sender with Section number in ULE.. this might be for error detection, packet loss etc).

In the other approach, based on the extension header bit, we can add extension headers, which can chain more than one extension headers as well.
If there is no extension is required and if we are going to follow the simple approach, then  extension header bit is set to ZERO and there is no modification to the present ULE draft.


Best Regards,
William.

On Fri, 27 Feb 2004 Alain RITOUX wrote :
>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
>