[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ROHC and ULE
Just to say, that the LLC mode was originally proposed for compatibility
with bridged LAN segments (e.g. WiFi).
My take (as a WG member) would be to reconsider this in the case for direct
ULE transmission and look for a direct ULE-Type assignment from IANA rather
than an LLC Type assignment from IEEE.
Gorry
On 9/11/06 02:08, "John Border" <border@hns.com> wrote:
>
> Carsten,
>
> This popped back to the top of my stack and finally re-read the
> presentation you gave. Where did ROHC go with 802.3? Is there a
> length-field encoding? Our draft proposes just a new EtherType. Your
> presentation implies there may be issues with just taking this simple
> approach...
>
>
> John
>
>
> Carsten Bormann wrote:
>
>> Hi Cedric,
>>
>> a couple of comments.
>>
>> I have made a couple of proposals at previous IPDVB meetings how to
>> integrate ROHC into ULE.
>> E.g., see http://www3.ietf.org/proceedings/05mar/slides/ipdvb-0.pdf
>> The most important input that would be useful at this point is how
>> ROHC will be used in actual systems, see below.
>>
>>
>>> Now, how having a multicast addressing to work with ROHC remains an
>>> open
>>> issue, but at least a basic solution would be the use of unidirectional
>>> mode (no need to acknowdege)
>>
>>
>> ROHC works fine in U-mode on unidirectional channels.
>> On a satellite link, the high delay for a context repair may actually
>> make this the best mode to look at.
>>
>>> Negociation of parameters between compressor and decompressor
>>> This point does not appear to be address in the document yet, but
>>> how to
>>> make the negociation is a real issue for the implementation of ROHC
>>> over
>>> ULE. Probably some propositions should be discussed here ? (e.g. use of
>>> default parameters according to the type of DVB network ? PPP
>>> replacement ?
>>> use of SI tables ? etc...)
>>
>>
>> We could probably come up with some default values. You would still
>> need to look at capacity points such as number of CIDs.
>> These could be "announced" (as opposed to "negotiated").
>>
>>> ROHC recommendation
>>> We strongly believe that one of the output of the task shall be ROHC
>>> usage
>>> recommendations. This can be either parameters values proposition or
>>> analysis of the best suited mode depending on different scenarios
>>> (namely
>>> unidr system, satcom systems with a return link, in both mesh and star
>>> topologies)
>>
>>
>> I'm happy to do this work if enough people are interested.
>>
>>> ROHC adaptation
>>> A interesting point to investigate can be ROHC adaptation to fit the
>>> satellite systems and the ULE stack. Two approaches can be foreseen.
>>> The
>>> first one is dedicated to simplification of the compression scheme,
>>
>>
>> Actually, we have just done that:
>>
>> draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt
>>
>> "...The RoHCv2 specification introduce a number of
>> simplifications to the rules and algorithms that govern the
>> behavior of the
>> compression endpoints..."
>>
>>> and the
>>> second one to the optimisation of ROHC in this context.
>>
>>
>> see above/below...
>>
>>>
>>> ULE over ROHC ?
>>> This has never been proposed, but maybe the compression gain could be
>>> pushed a little more, if new ROHC profiles integrating ULE (i.e.. x/
>>> IP/ULE)
>>> were supported ? What would be the main barriers for such an approach ?
>>
>>
>> These would probably be easy to add to ROHCv2.
>>
>> Gruesse, Carsten
>>
>>
>>
>
>