ULE extensions

[Gorry Fairhurst]

William StanisLaus wrote:

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

No that's not what I meant, here is the suggestion:

The basic ULE frame type in this hypothetical example would be 
"ENCRYPTED-CONTENT"
some well known code-point. This adds a null (zero byte) header, 
followed by a new type field.

The new type field that follows carries the TYPE of the ULE payload 
being transported over the link.
- Of course, you could define another TYPE value at this point too,
such as bridging, but that also adds more overhead.

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

Why would you neeed LLC_SNAP?

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

Ok, if you wanted to add other functions, you can define more headers....

>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.
>  
>
You can do it both ways....

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