Re: [rohc] operating assumptions (section 4.1)

[Mikael Degermark <micke@CS.Arizona.EDU>]

Zhigang & others, 

I am going over the document right now, and have changed section 4.6 into
the 
following. I'll attempt a merge with 4.1.

Micke

4.6.  Requirements on lower layers

This chapter lists general ROHC requirements on an underlying link layer. See also the ROHC lower layer requirements document [LLG].

Framing

The link layer MUST provide framing, which makes it possible to distinguish individual frames.

Length

The link layer MUST indicate the length of frames to the decompressor. There is no length information in compressed packet headers.

Error protection

The ROHC scheme has been designed to cope with residual errors in the headers delivered to the decompressor. However, the lower layer MUST NOT deliver a residual bit error rate larger than 1e-5.

It is RECOMMENDED that at least the header part of frames are protected using strong checksums. The error protection SHOULD ensure that packets with errors in the header part are never delivered.

Negotiation

In addition to the packet handling mechanisms above, the link layer MUST provide a way to negotiate header compression parameters.

At 09:52 AM 9/8/00 -0500, zhigang.liu@nokia.com wrote:
>Hello Folks,
>
>In the current rohc draft (ver 01), there are two sections that
seem
>to be redundant to each other: 4.1. Operating assumptions and 
>4.6. Requirements on lower layers.
>
>I guess it's probably an unintentional result of on-going editorial
>work when we merged different proposals, as the case for many other
>sections. Since lower layer guideline will address the issues in a
>separate draft, I'd like to suggest that we keep the section 4.1
>"operating assumptions" and remove section 4.6.
>
>I list at the end of this email some assumptions that are at least
>needed for rohc protocol. Please give comments on whether they are
>sufficient, so that we can finalize this section.
>
>I'm also working on the 4.5 encoding methods (merging texts
addressing
>the same issue, adding some text e.g. offset IP-ID encoding, etc).
It
>will probably be ready next Monday. 
>
>Br,
>Zhigang
>
>------------------------------------------------------------------
>
>4.1.  Operating assumptions
>
>packet length: the link layer can provide the length of a compressed
packet.
>
>(it is beneficial but not required to provide the length of a
feedback
>packet)
>
>error detection: the link layer can provide reasonably good error
detection 
>for compressed headers and feedback packets. (Error protection is
>beneficial but not required.)
>
>in order delivery: the link layer between the compressor and
decompressor 
>preserves the order of packets being transmitted, i.e. the
decompressor 
>(compressor) will receives the packets in the order they were sent by
the 
>compressor (decompressor). (Note that packet misordering before
compressor
>can be handled by rohc protocol)
>---
>Mailing list for Robust Header Compression WG
>Archive:
http://www.cdt.luth.se/rohc/
>