Re: ULE encryption Support.

["HDClausen" <clausen@cosy.sbg.ac.at>]

> It is always a tough call to decide where the tradeoff point is between
> general capability and efficiency... when one sees that there might be
such
> extensions in the future one certainly should allow for the expansion to
> avoid the problem of versioning the recommendation.
>
The idea was always to have an encapsulation mechanism that is as  lean as
possible ("every bit counts on a satellite channel") but allows for any user
to encapsulate whatever next level protocol they can afford. So the
functionality should be primarily confined to segmentation and reassembly.
Everything else such as encryption or FEC should be done on the next level
of processing - meaning the next level header pretty much in the same manner
as IPv6 does on the network layer.


> For a more flexible method we could use the DSM-CC data carousel.. but
that
> is too flexible and has too much overhead...
>
agree

> In this case adding extension headers seems to be overkill because it
seems
> very remote that they will ever be used. The functional capability of this
> layer <should> be stable.
>
ULE should just provide a basic functionality and leave any extensions to
the next layer of processing. If people need that functionality they will
have to pay for the additional header fields without enforcing additional
overhead on the basic service.

> So, 1 bits can be escape.. and then define more in that...but a different
> structure would follow.
> But if you want more, two bits would provide ability to add 2 new
unforeseen
> extensions and then an escape to a different structure.  Three bits
provides
> 6 new explicitly defined versions, then the escape.
> .....
>
> Even conservatively, how many bits do we need for this just in case? Is 2
> enough? 3?
>
I vote for 1 bit - "next level header follows".

--Horst Clausen
NMT (formerly Univ. Salzburg)
>
> Art
> ::{)>
> Art Allison
> Director Advanced Engineering
> NAB
> 1771 N St NW
> Washington DC 20036
> 202 429 5418
>
>
> -----Original Message-----
> From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> Sent: Monday, March 01, 2004 3:18 PM
> To: ip-dvb@erg.abdn.ac.uk
> Subject: Re: ULE encryption Support.
>
>
> Art, I think the scheme being talked about is rather like IPv6
> extension headers. Devices that don't understand the extension
> headers, simply ignore the extensions and continue to process the packet.
> A similar thing could be done at the link layer for specific ULE payloads
> that would benefit from this. As you say, no requirements have yet been
> written for ULE that match this need, although they may appear sooner
> (or even later).
>
> The question that needs to be addressed by this WG is should ULE allow
> such extension headers to be defined in future?
>
> We don't have to define them now, but we will have to define the
> MECHANISM by
> which they can be later added. If we don't include this possibility now,
> we'd have to version the whole protocol to get this functionality later
> (this would have a serious deployment issues).
>
> Gorry
>
> Allison, Art wrote:
>
> >As to backwards compatibility, no mater how it is defined, the initial
> >products will not process and use newly defined data. So, even if the
> >original product can process the larger header, it can do nothing with
data
> >with a new meaning defined after the product is built:
> >With a bit = 0 it is the 'Rev0' standard device Gen0.
> >With a bit = 1 a Gen0 device cannot process the <new> data, but can
process
> >all Rev0 data.
> >With a series of bits, a Gen0 device cannot process the <new> data, but
can
> >process all Rev0 data.
> >At each header instance a different type can be signaled.
> >
> >Bits are bucks for broadcasters, and each one has a fixed pipe size, so
we
> >must resist sending any more than absolutely needed.  I can make a case
for
> >NO expansion bit, as the new service can be defined when the application
is
> >defined and new devices can process it -- but 1 bit per header is ok.
> >
> >Please help me see what I must be missing that justifies use of more
> bits...
> >Art
> >::{)>
> >Art Allison
> >Director Advanced Engineering
> >NAB
> >1771 N St NW
> >Washington DC 20036
> >202 429 5418
> >
> >
> >-----Original Message-----
> >From: Alain RITOUX [mailto:alain.ritoux@6wind.com]
> >Sent: Monday, March 01, 2004 12:08 PM
> >To: ip-dvb@erg.abdn.ac.uk
> >Subject: Re: ULE encryption Support.
> >
> >
> >
> >
> >Allison, Art wrote:
> >
> >
> >
> >>So, if we should not encrypt at this layer [agree with Alain] and we
> >>
> >>
> >should
> >
> >
> >>not put additional error correction at this layer.. it seems we no
longer
> >>have a reason to add more than a just-in-case escape bit just in case a
> >>yet-to-be-invented function is needed someday.
> >>
> >>
> >
> >Not totally agree. This "reserve" may have no usage now, but the
> >mechanism is not that heavy, and once it is done, it will allow
> >introduciton of "possible" ext headers in a backward-compatible
> >way, which seems to me worth the price.
> >
> >Cheers
> >Alain.
> >
> >
>