Re: ROHC and ULE

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

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