[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ULE encryption Support.
Hi,
Art, the proposal for extension bit, works like a chain header.. i.e.
Please refer the Alain's previous post.
Regards,
William
<snip>
>>
>> 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.
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.
-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
Behalf Of Allison, Art
Sent: Tuesday, March 02, 2004 3:41 AM
To: 'ip-dvb@erg.abdn.ac.uk'
Subject: RE: ULE encryption Support.
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.
For a more flexible method we could use the DSM-CC data carousel.. but that
is too flexible and has too much overhead...
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.
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?
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.
>
>
***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************