[rohc] Short summary of the new ROHCv2 profiles: draft-pelletier-rohc-rohcv2-profiles-00.txt

["Ghyslain Pelletier \(LU/EAB\)" <[e-mail]>]

RoHCers,

We have submitted a new set of ROHC profiles (ROHCv2), draft-pelletier-rohc-rohcv2-profiles-00.txt.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pelletier-rohc-rohcv2-profiles-00.txt

One of the objectives of these new profile definitions is to create simpler compression profiles,  that handle more flexibly robustness in terms of both out-of-order delivery and  consecutive packet losses.

The packet formats have been defined using the formal notation for ROHC (ROHC-FN).

Below is a summary of the main "features" of draft-pelletier-rohcv2-profiles-00.txt

Comments welcome. We would like to have support and re-submit this draft as a working group document after the July meeting. I assume that this draft will be a topic for the RoHC session in Montreal.

/Ghyslain and Kristofer

o (De)Compression logic
-----------------------

In general, most of the logic is inspired from the ROHC-TCP profile. Some changes depart from 3095-logic, especially with respect to how the decompressor is allowed to attempt decompression of packets (i.e. the decompressor state machine). Somewhat stricter rules are also introduced, with respect to CRC-8, CRC-3 and  CRC-7. Of interest for comments is the state diagram in section "5.3.1. Decompressor State Machine":

                                                          CRC-8(IR) or
                                                          CRC-8(IR-DYN)
                                                          Validation
                             CRC-8(IR) or                 CRC-7(CO) or
    CRC-8(IR)  CRC-8(IR)     CRC-8(IR-DYN)  CRC-7(CO)     CRC-3(CO)
    Failure    Validation    Validation     Verification  Verification
    +--->---+  +-->---->--+  +-->----->--+  +-->---->--+  +-->---->--+
    |       |  |          |  |           |  |          |  |          |
    |       v  |          v  |           v  |          v  |          v
   +-----------------+  +----------------------+  +-------------------+
   | No Context (NC) |  | Initial Context (IC) |  | Full Context (FC) |
   +-----------------+  +----------------------+  +-------------------+
       ^                 | ^ CRC-7(CO)      | ^                 |
       | Static Context  | | Failure or     | | Context Damage  |
       | Damage Detected | | PT not allowed | | Detected        |
       +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+

Note that the SC state has been replaced with the IC state, for which transitions to and from are now different and more geared towards robustness. See more in 5.3.1.

We've also added some mechanisms to improve robustness against out-of-order delivery. For fields that are not LSB encoded, it is based on the definition of the optimistic approachh and the reordering depth that the compressor wants to provide robustness for, and for LSB encoded fields it is based on a new control field that defines a ratio between the robustness to losses and the robusntess to reordering in the interpretation interval of the LSB encoding.

More specifically, no reordering, quarter interval, half interval and three quarter interval can be used for the interpretation interval offset. More details on the  definition of the packet formats. 

o Packet formats:
-----------------

The packet formats follow the guidelines from draft-ietf-rohc-rfc3095bis-improvements-02.txt.

With the following we'd like to provide some additional descriptions of the packet  formats. Lots of inspiration has been taken from the ROHC-TCP profile and the compression  of all extension headers is 100% identical to that in ROHC-TCP.

The packet formats are an inital attempt for this draft and the authors encourage discussion on how these should look in the final version. But since we want to keep  things simple, the packet formats have much less optional fields (apart from co_common,  which is the "utility" packet) and therefore, it should be easier to both implement and test the specification.
 
Here's a quick description of the packet formats (this applies to all profiles covered in  the RoHCv2 draft):

PT-0:
- pt_0_crc3, MSN-only packet w/ 3-bit CRC (identical to 3095 UO-0)
- pt_0_crc7, MSN-only packet w/ 7-bit CRC

PT-1: (3-bit CRC)
Carries one LSB-coded field other than MSN (either TS or IP-ID)
- pt_1_rnd, used for non-sequential IP-ID (UO-1-replacement from 3095)
- pt_1_seq_id, used for sequential IP-ID (UO-1-ID-replacement from 3095)
- pt_1_seq_ts (only for UDP/RTP and UDP-Lite/RTP profiles) (UO-1-TS-replacement from  3095)

PT-2: (7-bit CRC)
Carries one LSB-coded field other than MSN (either TS or IP-ID)
Also carry the M-bit (only for UDP/RTP and UDP-Lite/RTP profiles)
- pt_2_rnd, used for non-sequential IP-ID, (UOR-2-replacement from 3095)
- pt_2_seq_id, used for sequential IP-ID (UOR-2-ID-replacement from 3095))
- pt_2_seq_ts (only for UDP/RTP and UDP-Lite/RTP profiles) (UOR-2-TS-replacement from  3095)

co_common: (7-bit CRC)
- Replacement for 3095 "UOR-2-with-extension-3"
- Can carry practically everything from the dynamic chain of innermost
  IP header and "endpoint headers". Can also carry TOS/TC and
  TTL/HopLimit of outer IP headers.
- We have added an additional CRC3, which covers some of the control
  fields to avoid the decompressor sending ACKs on packets that
  contained a bad control field which was not used during the decompression.

IR-DYN/IR:
- Only small changes compared to v1, but some added control fields and
  more efficient compression of other fields (such as IP version field)

IR-PD (IR packet):
- Since 3095 offered too many conbinations of so-called frame stealing
  packets, we decided to simplify things and redefine the "D-bit" in
  the IR so that it define a packet where the payload has been
  explicitly dropped. We now also allow the compression of payload-less
  packets with the RTP profile, which removes some of the many
  IR-specific options.

--
 Ghyslain Pelletier, Dipl. Ing.
 Wireless IP Optimizations
 Ericsson Research, Corporate Unit

 Ericsson AB, Laboratoriegränd 11
 Box 920, S-97128 Luleå, SWEDEN
 Phone : +46 (0)  8 404 29 43
 Mobile: [phone]
 Ghyslain.Pelletier at ericsson.com
 http://www.ericsson.com

-----------------------------------
 The opinions expressed in this
 message are my personal opinions.
 These opinions are not
 necessarily those of my employer,
 unless stated otherwise.
-----------------------------------


_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc