Subject: Re: ULE extensions

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 01 Mar 2004 13:50:30 +0000

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

---

From: Alain RITOUX <[email-masked]>
Date: Mon, 01 Mar 2004 15:59:03 +0100

> such as bridging, but that also adds more overhead.

OK I got it.
I fact, if there is a code point for that with well known/defined data,
the the "encrypt" thing can de fully done.

What William and I were proposing was a more generic mechanism,
available for extension-to-come. So what we proposed was to introduce
an Extension Header format :

- The presence of extension headers is specified by  a bit
   in ULE header
- Each extension header has a bit telling whether what follows is the
   payload or another extension header.
- Each extension header includes its own length, so Ext Header chain
   can be parsed blindly
- Each Extension Header includes its own type, and this type has
   a field indicating what to do if this type is unknown.
     + drop SNDU
     + ignore, and parse blindly to the next (if present) Ext Header
       or to the playload.

In fact the generic Ext Header processing would then be MANDATORY
It will allow implem to parse blindly unknwon Ext Headers

The "encryption" stuff can easily fit into this generic scheme
with the same overhead. The plus is that it would be able to live
its own life independanlty from (ExtHdr aware)ULE base specs.

What is the feeling of the WG on this header chaining ?

Cheers.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11