[rohc] Updating draft-ietf-rohc-rfc3095bis-framework-01.txt: Summary of proposed changes

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

RoHCers,

I'm in the process of updating the draft that separately defines the ROHC framework, draft-ietf-rohc-rfc3095bis-framework-01.txt. We're targeting a submission on time for the Montreal meeting deadline, i.e. ... tomorrow Monday morning in a few hours from now!

Although it is short notice, I thought I would send a summary of the proposed updates to the list. Would someone comment against these changes even after the draft is submitted, we can always undo the changes in a later version would we reach a better agreement. These proposed changes will thus likely make it in the submission -01, but there are still very open to comments.

Most of the changes are related to aligning the framework draft with the ROHCv2 profiles (draft-draft-pelletier-rohc-rohcv2-profiles-00.txt).

/Ghyslain, on behalf of Kristofer and Lars-Erik

Summary of the proposed changes:
--------------------------------

Most of the changes are meant to harmonize the framework draft with the recently submitted ROHCv2 profiles.

1) Editorial: deletion of RTT definition (not used)
2) Definition of robustness should include robustness
   to out-of-order (ooo) delivery
3) we suggest to add a whole section on "Operational
   Characteristics of the RoHC Channel", based on 3095's
   section 4.2 "Dynamicity" and complementing section
   "4.2. Operational Characteristics of RoHCv2 Profiles"
   in draft-pelletier-rohc-rohcv2-profiles-00.txt.
4) we suggest to add a section defining the Master Sequence
   Number (MSN), since all RoHC profiles use a SN as part
   of their profile-specific definition (in the most simple
   case to allow the use of feedback, and in the most frequent
   case to compress some fields that behave sequentially).
5) We suggest to include a section that define the concept of
   "static" and "dynamic" parts of a context.
6) We suggest to add to section 5.1.1. a definition of a new context.
7) We suggest the addition of an optional parameter to the
   ROHC channel, for the purpose of quantifying ooo depth.
8) We suggest to add to section 5.2 the two type identifiers
   that are unused by the RoHC framework.
9) Add a description of "Payload" field in the general packet
   format definition.
10) Split section 5.2.1 in smaller sub-sections
11) Replaced "MUST be discarded" by "MUST NOT be delieved to
    upper layers" just about everywhere appropriate.
12) Clarify the semantics of ACK, NACK and STATIC-NACK wrt static
    and dynamic parts of the decompressor context and assumptions
    of validity.
13) Delete first note in 5.2.3.1
14) Added a clear explanation of the purpose/usage of CRC-8, CRC-3
    and CRC-7 as guideline to profile definitions.
15) Include the UNCOMPRESSED profile definition in the framework
    document. This is motivated by the fact that this profile is a
    "channel" profile and because its definition does not need to
    be updated. In other words, this is not a compression profile,
    it is a channel path for all traffic that is not to be compressed.

Detailed text proposal for each point above:
---------------------------------------------

3)

Operational Characteristics of the RoHC Channel

Robust header compression can be used over many type of link
technologies.  The RoHC framework provides flexibility for profiles
to address a wide range of applications, and this section lists some
of the operational characteristics of the RoHC channel.

Multiplexing over a single logical channel

   The RoHC channel provides a mechanism to identify a context within
   the general RoHC header format.  The Context Identifier (CID) 
   makes it possible for a logical channel that supports RoHC to
   transport multiple header-compressed flows, while still making it
   possible for a channel to be dedicated to one single flow without
   any CID overhead.  More specifically, ROHC uses a distinct context
   identifier space per logical channel, and the context identifier
   can be omitted for one of the flows over the RoHC channel when
   configured to use a small CID space.

Establishment of Channel Parameters

   A link layer defining support for the RoHC channel must provide
   the means to establish header compression channel parameters (see
   section ý5.1).  This can be achieved either through a negotiation
   mechanism, static provisioning or some out-of-band signaling.

Packet type indication

   The RoHC channel defines a packet type identifier space, and puts 
   restrictions with respect to the use of a number of identifiers 
   that are common for all RoHC profiles. Identifiers that have no 
   restrictions, i.e. identifiers that are not defined by this 
   document, are available to each profile. This identifier is part 
   of each compressed header.  This makes it possible for the link 
   that supports the RoHC channel to allocate one single packet type 
   for RoHC.

Out-of-order delivery between compression endpoints

   Each profile define its own level of robustness, including against 
   reordering of packets between compression endpoints, if any.

   The definition of the RoHC channel includes state that is 
   established prior to the first header compressed packet being 
   sent.  It does not in itself make any assumption with respect to
   the order of the packets that are delivered by the link to the 
   decompressor. However, the channel state can include parameters
   that characterizes the maximum reordering depth that profiles
   supporting out-of-order delivery over the RoHC channel may use.

   For profiles specified in ý[3], the channel between compressor and 
   decompressor is required to maintain in-order delivery of the 
   packets, i.e. the definition of these profiles assume that the 
   decompressor always receives packets in the same order as the 
   compressor sent them.  The impacts of reordering on the 
   performance of these profiles is described in ý[7]. Reordering 
   before the compression point, however, is dealt with, i.e. these 
   profiles make no assumption that the compressor will only receive 
   packets in sequence.

   For the RoHv2 profiles specified in ý[8], their definition assume 
   that the decompressor can receive packets out-of-order, i.e. not 
   in the same order as the compressor sent them.  Reordering before 
   the compression point is also dealt with.

Duplication of packets

   The link supporting the RoHC channel is required to not duplicate
   packets.  (Duplication before the compression point, however, is
   dealt with, i.e., there is no assumption that the compressor will
   receive only one copy of each packet.)

Framing

   The link layer must provide framing that makes it possible to
   distinguish frame boundaries and individual frames.

Error detection/protection

   ROHC profiles are designed to cope with residual errors in the
   headers delivered to the decompressor.  CRCs are used to detect
   decompression failures and to prevent or reduce damage 
   propagation.  However, it is recommended that lower layers deploy
   error detection for ROHC headers and do not deliver ROHC headers
   with high residual error rates.

4)

Compression and Master Sequence Number (MSN)

Compression of header fields is based on the establishment of a 
function to a sequence number, called the Master Sequence Number 
(MSN).  This function describes the change pattern of the field with 
respect to an increase of the MSN.

Change patterns include e.g. fields that increase monotonically or by 
a small value, but also fields that seldom change as well as fields 
that remain unchanging for the entire lifetime of the flow, in which 
case the function to the MSN is equivalent to a constant value.

The compressor first establishes functions for each of the header 
fields, and it then reliably communicates the MSN.  When the change 
pattern of the field does not match the established function, i.e., 
the existing function gives a result that is different from the field 
in the header to be compressed, additional information is sent to 
update the parameters of that function.

The MSN is defined per profile. It can be either derived directly 
from one of the fields of the protocol being compressed (e.g. the RTP 
SN ý[8]), or it can be created and maintained by the compressor (e.g. 
the MSN for compression of UDP in profile 0x0102 ý[8] or the MSN in 
ROHC-TCP ý[9]).

5)

Static and Dynamic parts of a Context

A compression context can be conceptually divided in two different 
parts, the static context and the dynamic context, each based on the 
properties of the fields that are being compressed.

The static part includes the information necessary to compress and 
decompress the fields whose change behavior is classified as STATIC, 
STATIC-KNOWN or STATIC-DEF (as described in section ý4.1 above.

The dynamic part includes the state maintained for all the other 
fields, i.e. those that are classified as CHANGING.

6)

A context is considered to be a new context when the CID is 
associated with a profile for the first time since the creation of 
the ROHC channel, or when the CID gets associated from the reception 
of an IR (this does not apply to the IR-DYN) with a different profile 
than the profile in the context.

7)

MAX_R_DEPTH: Nonnegative integer. Maximum reordering depth expected 
   between the compressor and the decompressor, when the link ´
   supporting the RoHC channel cannot guarantee in-order delivery. If 
   MAX_R_DEPTH is negotiated to be 0, the channel is assumed not to 
   deliver packets to the decompressor in an order that differs for 
   the order the compressor sent them, per compressed flow (CID). 
   This parameter is optional.

8)
Other packet types can be defined and used by individual profiles:

1111101  : available (not reserved by ROHC framework)
11111001 : available (not reserved by ROHC framework)

9)

Payload corresponds to zero or more octets of payload from the 
uncompressed packet, starting with the first octet in the 
uncompressed packet after the last header compressible by the current 
profile.

12)

ACK         : Acknowledges successful decompression of a packet. 
              Indicates that the decompressor considers its context 
              to be valid up to this packet.

NACK        : Indicates that the decompressor considers that some or 
              all of the dynamic part of its context is invalid. 

STATIC-NACK : Indicates that the decompressor considers that its 
              entire static context is not valid, or that is  has not 
              been established.

14)

More specifically, the 8-bit CRC does not cover only and entirely the 
original uncompressed header; therefore it does not provide the means 
for the decompressor to verify a decompression attempt, or either the 
means to verify the correctness of the entire decompressor context. 
However, when successful, it does provide enough robustness for the 
decompressor to update its context with the information carried 
within the IR or the IR-DYN header.
--
The purpose of the 3-bit CRC is to provide the means for the 
decompressor to verify the outcome of a decompression attempt for 
small compressed headers, and to detect context damage based on 
aggregated probability over a number of decompression attempts. It is 
however too weak to provide enough success guarantees from the 
decompression of one single header. Therefore, compressed headers 
carrying a 3-bit CRC are normally not suitable to perform context 
repairs at the decompressor; hence profiles should refrain from 
allowing decompression of such header when some or the entire 
decompressor context is assumed invalid.
--
The purpose of the 7-bit CRC is to provide the means for the 
decompressor to verify the outcome of a decompression attempt for a 
larger compressed header, and to provide enough protection to 
validate a context repair at the decompressor. The 7-bit CRC is 
strong enough to assume a repair to be successful from the 
decompression of one single header; hence profiles may allow 
decompression of a header carrying a 7-bit CRC when some of the 
decompressor context is assumed invalid.

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