Subject: Re: ROHC and ULE

From: John Border <[email-masked]>
Date: Wed, 08 Nov 2006 21:08:54 -0500

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 10 Nov 2006 17:36:34 +0000

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