[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ULE extensions



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