[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 RFC 4815

Network Working Group                                       L-E. Jonsson
INTERNET-DRAFT                                               K. Sandlund
Expires: February 2006                                         P. Kremer
                                                                Ericsson
                                                          August 9, 2005



                      The RFC 3095 Implementer's Guide
                   <draft-ietf-rohc-rtp-impl-guide-14.txt>


Status of this memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   By submitting this Internet-Draft, each author accepts the provisions
   of Section 3 of BCP 78.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This document is a submission of the IETF ROHC WG. Comments should be
   directed to the ROHC WG mailing list, rohc@ietf.org.

Abstract

   RFC 3095 defines the RObust Header Compression (ROHC) framework and
   profiles for IP, UDP, RTP, and ESP. This document clarifies
   ambiguities and common misinterpretations of RFC 3095, and it also
   corrects some actual errors in the specification. The corrections and
   clarifications provided herein must be followed to get interoperable
   implementations, i.e. this document updates RFC 3095. Further, minor
   interpretation details of RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP
   profile) and RFC 4109 (ROHC UPD-Lite profiles) are also addressed.



Jonsson, et al.                                                 [Page 1]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


Table of Contents

   1. Introduction.....................................................3
   2. CRC calculation and coverage issues..............................3
      2.1. CRC calculation.............................................3
      2.2. Padding octet in CRC........................................4
      2.3. CRC coverage in CRC feedback options........................4
      2.4. CRC coverage of the ESP NULL header.........................4
   3. Enhanced mode transition procedures..............................4
      3.1. Modified transition logic for enhanced transitions..........5
      3.2. Transition from Reliable to Optimistic mode.................6
      3.3. Transition to Unidirectional mode...........................6
   4. Timestamp encoding considerations................................7
      4.1. Encoding used for compressed TS bits........................7
      4.2. (De)compression of TS without transmitted TS bits...........7
      4.3. Interpretation intervals for TS encoding....................8
      4.4. TS_STRIDE for scaled timestamp encoding.....................8
      4.5. TS wraparound with scaled timestamp encoding................9
      4.6. Recalculating TS_OFFSET.....................................9
      4.7. TS_STRIDE and the Tsc flag in Extension 3..................10
      4.8. Using timer-based compression..............................10
   5. List compression issues.........................................10
      5.1. Generic extension header list..............................10
      5.2. CSRC list items in RTP dynamic chain.......................10
      5.3. RTP dynamic chain..........................................11
      5.4. Compressed lists in UO-1-ID packets........................11
      5.5. Bit masks in list compression..............................11
      5.6. Headers compressed with list compression...................11
      5.7. ESP NULL header list compression...........................12
   6. Updating properties.............................................12
      6.1. Implicit updates...........................................12
      6.2. Updating properties of UO-1*...............................12
   7. Context management and CID/context re-use.......................13
      7.1. Compressor and decompressor MUST keep MAX_CID contexts.....13
      7.2. CID/context re-use.........................................13
         7.2.1. Re-using a CID/context with the same profile..........13
         7.2.2. Re-using a CID/context with a different profile.......14
      7.3. Context updating properties for IR packets.................14
   8. Other protocol clarifications...................................14
      8.1. Meaning of NBO.............................................14
      8.2. IP-ID......................................................14
      8.3. Extension-3 in UO-1-ID packets.............................15
      8.4. Extension-3 in UOR-2* packets..............................15
      8.5. Multiple SN options in one feedback packet.................15
      8.6. Multiple CRC options in one feedback packet................16
      8.7. Packet decoding during mode transition.....................16
      8.8. How to respond to lost feedback links?.....................16
      8.9. What does "presumed zero if absent" mean on page 88?.......17
      8.10. UOR-2 in profile 2 (UDP)..................................17
      8.11. Sequence number LSB's in IP extension headers.............17
      8.12. Expecting UOR-2 ACKs in O-mode............................17



Jonsson, et al.                                                 [Page 2]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


      8.13. Compression of SN in AH and GRE extension headers.........18
   9. ROHC negotiation clarifications.................................18
   10. PROFILES suboption in ROHC-over-PPP............................18
   11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......19
   12. Security considerations........................................19
   13. IANA considerations............................................19
   14. Acknowledgment.................................................19
   15. References.....................................................19
      15.1. Normative References......................................19
      15.2. Informative References....................................19
   16. Authors' Addresses.............................................20
   Appendix A - Sample CRC algorithm..................................21

1. Introduction

   RFC 3095 [1] defines the RObust Header Compression (ROHC) framework
   and profiles for IP, UDP, RTP, and ESP. During implementation and
   interoperability testing of RFC 3095 some ambiguities and common
   misinterpretations have been identified, as well as a few actual
   errors.

   This document has been created to summarize all identified issues,
   and provide the clarifications and corrections needed to make
   creation of interoperable implementations possible. It should thus be
   noted that it is essential that implementers of RFC 3095 follow the
   corrections and clarifications provided herein, i.e. this document
   constitute an update to RFC 3095. When referring to RFC 3095, this
   document should therefore also be referenced.

   A few minor interpretation details of RFC 3241 [2] (ROHC over PPP),
   RFC 3843 [3] (ROHC IP-only profile), and RFC 4019 [5] (ROHC UDP-Lite
   profiles) are also addressed in this document (chapter 10-11).

   Note that all section and chapter references in this document refer
   to [1], where not stated otherwise.

2. CRC calculation and coverage issues

2.1. CRC calculation

   ROHC uses CRC checksum in order to provide some protection against
   bit errors. CRC is used in the segmentation protocol and in the
   compressed packets, as well.

   Section 5.2.5.2 describes the segmentation protocol and refers to
   [3], which describes a well-defined CRC algorithm for 32 bit
   checksums.  Although, Section 5.9 only defines the polynomials for 3,
   7 and 8-bit long checksum, the same algorithm can be used in these
   cases as well.





Jonsson, et al.                                                 [Page 3]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   A PERL implementation of the algorithm (written by Carsten Bormann)
   can be found in Appendix A.
2.2. Padding octet in CRC

   According to Section 5.9.1, in case of IR and IR-DYN packets the CRC
   "is calculated over the entire IR or IR-DYN packet, excluding Payload
   and including CID or Add-CID octet".  Padding isn't meant to be
   meaningful part of a packet and not included in CRC calculation.  As
   a result, CRC doesn't cover the Add-CID octet for CID 0, either.

2.3. CRC coverage in CRC feedback options

   Section 5.7.6.3 states "The CRC option contains an 8-bit CRC computed
   over the entire feedback payload, without the packet type and code
   octet, but including any CID fields, using the polynomial of section
   5.9.1". However, it does not mention how the "size" field is handled,
   if present. Since the "size" field can be considered an extension of
   the "code" field, it must be treated as the "code" field, i.e. the
   "size" field is not covered by the CRC.

2.4. CRC coverage of the ESP NULL header

   Section 5.8.7 gives the CRC coverage of the ESP NULL header as
   "Entire ESP header". This should be interpreted as being only the
   initial part of the header (i.e. SPI and Sequence number), and not
   the trailer part at the end of the payload. Therefore, the ESP NULL
   header will have the same CRC coverage as the ESP header used in the
   ESP profile (section 5.7.7.7).

3. Enhanced mode transition procedures

   To reduce transmission overhead and computational complexity
   (including CRC calculation) associated with feedback packets sent for
   each decompressed packet during mode transition, a decompressor can
   be implemented with slightly modified mode transition procedures,
   compared to those defined in [1].

   These modifications affect transitions to Optimistic and
   Unidirectional modes of operation, i.e. the transitions described in
   sections 5.6.5 and 5.6.6 of [1], and make those transition diagrams
   more consistent with the diagram describing the transition to R-mode.
   However, the differences between the original diagrams of [1] were
   motivated by robustness concerns for mode transitions to Optimistic
   and Unidirectional modes. To avoid deadlock situations in mode
   transitions, these aspects must be addressed also when a decompressor
   implements the enhanced transition procedures, and that is done by
   following a slightly modified definition of the decompressor
   transition states. All aspects related to implementation of the
   enhanced transition procedures are described in subsequent chapters.





Jonsson, et al.                                                 [Page 4]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   Note that these modified operations should be seen only as an
   improved decompressor implementation, since interoperability is not
   at all affected. A decompressor implemented according to the
   optimized procedures would be able to interoperate with an RFC3095
   compressor, as well as a decompressor implemented according to the
   procedures described in RFC3095 would do.

3.1. Modified transition logic for enhanced transitions

   The intent with these enhanced transition procedures is to allow the
   decompressor to stop sending feedback packets for all packets
   decompressed during the second half of the transition procedure, i.e.
   after an appropriate IR/IR-DYN/UOR-2 packet has been received from
   the compressor. In the transition diagrams, sections 3.2 and 3.3
   below, this is realized by allowing the decompressor transition
   parameter (D_TRANS) to be set to P (Pending) at that stage. However,
   as mentioned above, there are robustness concerns related to this
   optimization, and to avoid deadlock situations with never completed
   transitions as a result of feedback losses, the decompressor must
   continue to send feedback at least periodically, also when in Pending
   transition state. That would be the equivalence of enhancing the
   D_TRANS parameter definition in section 5.6.1 of [1], to include a
   definition of Pending state operation.

   - D_TRANS:
      Possible values for the D_TRANS parameter are (I)NITIATED,
      (P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode
      transition can be initiated only when D_TRANS is D. While D_TRANS
      is I, the decompressor sends a NACK or ACK carrying a CRC option
      for each packet received. When D_TRANS is set to P, the
      decompressor do not have to send a NACK or ACK for each packet
      received, but it MUST continue to send feedback on a regular
      basis, and all feedback packets sent MUST include the CRC option.
      This ensures that all mode transitions will be completed also in
      case of feedback losses.



















Jonsson, et al.                                                 [Page 5]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


3.2. Transition from Reliable to Optimistic mode

   The enhanced procedure for transition from Reliable to Optimistic
   mode is shown below:

            Compressor                     Decompressor
           ----------------------------------------------
                 |                               |
                 |        ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
                 |       +-<-<-<-<-<-<-<-+       |
     C_TRANS = P |-<-<-<-+                       |
     C_MODE = O  |                               |
                 |->->->-+ IR/IR-DYN/UOR-2(SN,O) |
                 |       +->->->->->->->-+       |
                 |->-..                  +->->->-| D_TRANS = P
                 |->-..                          | D_MODE = O
                 |           ACK(SN,O)   +-<-<-<-|
                 |       +-<-<-<-<-<-<-<-+       |
     C_TRANS = D |-<-<-<-+                       |
                 |                               |
                 |->->->-+  UO-0, UO-1*          |
                 |       +->->->->->->->-+       |
                 |                       +->->->-| D_TRANS = D
                 |                               |

3.3. Transition to Unidirectional mode

   The enhanced procedure for transition to Unidirectional mode is shown
   on the following figure:

                Compressor                     Decompressor
               ----------------------------------------------
                 |                               |
                 |        ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
                 |       +-<-<-<-<-<-<-<-+       |
     C_TRANS = P |-<-<-<-+                       |
     C_MODE = U  |                               |
                 |->->->-+ IR/IR-DYN/UOR-2(SN,U) |
                 |       +->->->->->->->-+       |
                 |->-..                  +->->->-| D_TRANS = P
                 |->-..                          |
                 |           ACK(SN,U)   +-<-<-<-|
                 |       +-<-<-<-<-<-<-<-+       |
     C_TRANS = D |-<-<-<-+                       |
                 |                               |
                 |->->->-+  UO-0, UO-1*          |
                 |       +->->->->->->->-+       |
                 |                       +->->->-| D_TRANS = D
                 |                               | D_MODE= U





Jonsson, et al.                                                 [Page 6]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


4. Timestamp encoding considerations

4.1. Encoding used for compressed TS bits

   RTP Timestamp values (TS) are always encoded using W-LSB encoding,
   both when sent scaled and when sent unscaled. For TS values sent in
   Extension 3, W-LSB encoded values are sent using the self-describing
   variable-length format (section 4.5.6), and this applies to both
   scaled and unscaled values.

4.2. (De)compression of TS without transmitted TS bits

   RFC 3095 explains that SO-state provides the most efficient
   compression within ROHC RTP. In this state, apart from packet type
   identification and the error detection CRC, only RTP sequence number
   (SN) bits have to be transmitted in RTP compressed headers. All other
   fields are then omitted either because they are unchanged or because
   they can be reconstructed through a function from the SN (i.e. by
   combining the transmitted SN bits with state information from the
   context). Although it is never spelled out explicitly what fields are
   inferred from the SN in this way, one should be able to figure out
   that this principle applies to the IP Identification (IP-ID) field
   and the RTP Timestamp (TS) field.

   IP-ID compression and decompression, both with and without
   transmitted IP-ID bits in the compressed header, are well defined in
   section 4.5.5 (see section 8.2 of this document). However, for TS it
   is only defined how to decompress based on actual TS bits in the
   compressed header, either scaled or unscaled, but not how to infer
   the TS from the SN, i.e. the SO-state operation. Although the general
   idea is simple, the actual operation must be clearly defined to
   ensure interoperability. There are also inconsistent text pieces that
   might confuse an implementer and result in non-interoperable
   implementations. This section therefore provides the necessary
   clarifications to SN-to-TS decompression, i.e. decompression of TS
   (scaled or unscaled) when no TS bits are transmitted in the
   compressed header.

   When no TS bits are transmitted in the compressed header, the encoded
   TS value (scaled or unscaled) is to be decompressed assuming a linear
   extrapolation from the SN, i.e. delta_TS = delta_SN * default-slope.

   Section 5.7 defines the potential values for default-slope as:

     If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
     compression (see section 4.5.3), and default-slope(TS) = 1.

     If value(Tsc) = 0, the Timestamp value is compressed as-is, and
     default-slope(TS) = value(TS_STRIDE).





Jonsson, et al.                                                 [Page 7]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   What must be noted here is that no slope value is used other than the
   default-slope value, as defined in section 5.7. There is confusing
   text in section 5.5.1.2 that might mistakenly be interpreted as if
   the slope can have different values and be "learned", which is
   incorrect. The default-slope from 5.7 is always the value used when
   decompressing TS based on SN.

4.3. Interpretation intervals for TS encoding

   Section 4.5.4 defines the interpretation interval, p, for timer-based
   compression of the RTP timestamp.  However, Section 5.7 defines a
   different interpretation interval, which is defined as the
   interpretation interval to use for all TS values.  It is thus unclear
   which p-value to use, at least for timer-based compression.

   The way this should be interpreted is that the p-value differs
   depending on whether timer-based compression is enabled or not.  For
   timer-based compression, the interpretation interval of section
   4.5.4, p = 2^(k-1) - 1, is used for TS.  Otherwise, the interval of
   section 5.7, p = 2^(k-2) - 1, is used for TS with regular W-LSB
   encoding.

   Since two different p-values are used, the compressor must take this
   into account during the process of enabling timer-based compression.
   Before timer-based compression can be used, the decompressor will
   have to inform the compressor (on a per-channel basis) about its
   clock resolution. Further, the compressor has to send (on a per-
   context basis) a non-zero TIME_STRIDE to the decompressor.

   When the compressor is confident that the decompressor has received
   the TIME_STRIDE value, it can switch to timer-based compression.
   During this transition from window-based compression to timer-based
   compression, it is necessary that the compressor keep k large enough
   to cover both interpretation intervals.

4.4. TS_STRIDE for scaled timestamp encoding

   The timestamp stride (TS_STRIDE) is defined as the expected increase
   in the timestamp value between two RTP packets with consecutive
   sequence numbers. TS_STRIDE is set by the compressor and explicitly
   communicated to the decompressor, and it is used either as the
   scaling factor for scaled TS encoding, or constitutes the default-
   slope used when decompressing an unscaled TS through a linear
   extrapolation from the SN (see also section 4.2 above).

   The relation between TS and TS_SCALED, given by the following
   equality in section 4.5.3, defines the mathematical meaning of
   TS_STRIDE:

      TS = TS_SCALED * TS_STRIDE + TS_OFFSET




Jonsson, et al.                                                 [Page 8]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   In the compression step explained following this core equality of
   section 4.5.3, TS_SCALED is incorrectly written as TS / TS_STRIDE.
   This formula is incorrect both because it excludes TS_OFFSET, and
   because it would prevent a TS_STRIDE value of 0. If "/" were a
   generally unambiguously defined operation meaning "the integral part
   of the result from dividing X by Y", the absence of TS_OFFSET could
   be explained, but the formula still lacks a proper output for
   TS_STRIDE equal to 0. As the core equality above does not prevent
   setting TS_STRIDE to 0, and there is no reason not to allow a
   compressor to do that, the formula of "2. Compression" should not be
   read as having any formal meaning.

4.5. TS wraparound with scaled timestamp encoding

   In the scaled timestamp encoding section, 4.5.3, it is said in point
   4 and 5 that the compressor is not required to initialize TS_OFFSET
   at wraparound, but that it is required to increase the number of bits
   sent for the scaled TS value when there is a TS wraparound. The
   decompressor is also required to detect and cope with TS wraparound,
   including updating TS_OFFSET. This has been found to be non-trivial
   to do, as well as hard to make interoperable and robust. The gain is
   also insignificant, as TS wraparound happens very seldom.

   It is therefore recommended not to follow point 4-5 of section 4.5.3,
   and instead the compressor is recommended to reinitialize TS_OFFSET
   upon TS wraparound, by sending unscaled TS. This is equivalent of
   replacing point 4-5 with:

     4.  Offset at wraparound: If the value of TS_STRIDE is not equal
         to a power of two, wraparound of the unscaled 32-bit TS will
         change the value of TS_OFFSET. When this happens, the
         compressor must reinitialize TS_OFFSET by sending unscaled TS,
         as in 1 above.

   It should be noted that by following this recommendation for the
   compressor to reinitialize TS_OFFSET at wraparound, there will be no
   problems interacting with a decompressor that still tries to follow
   4.5.3 points 4-5. For a decompressor that assumes the compressor will
   follow the above recommendation, there is a risk of the decompressor
   context becoming invalid. Considering the size if the TS number
   space, and thus the number of packets between each TS wraparound, the
   potential cost of this is considered negligible.

4.6. Recalculating TS_OFFSET

   TS can be sent unscaled if the TS value change does not match the
   established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
   To ensure correct decompression of subsequent packets, the
   decompressor should therefore always recalculate the RTP TS modulo,
   TS_OFFSET, when a packet with an unscaled TS value is received.




Jonsson, et al.                                                 [Page 9]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


4.7. TS_STRIDE and the Tsc flag in Extension 3

   The Tsc flag in Extension 3 indicates whether TS is scaled or not. It
   must be noted that the Tsc value apply to all TS bits, also if there
   are no TS bits in the extension itself.

   Note also that if Tsc=1, TS is scaled using context(TS_STRIDE), not
   value(TS_STRIDE) as is said in the legend for Extension 3 in section
   5.7.5.

   When a compressor uses Extension 3 to re-establish a new value for
   TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some
   packets until decompressor confidence is obtained. When the TS_STRIDE
   field is present in Extension 3, the Tsc flag must thus be set to 0.

4.8. Using timer-based compression

   Timer-based compression of the RTP timestamp, as described in section
   4.5.4, may be used to reduce the number of transmitted timestamp bits
   (bytes) needed when the timestamp can not be inferred from the SN. It
   should thus be noted that timer-based compression has no influence on
   decompression of packets where no timestamp bits are sent, in that
   case the timestamp is just linearly inferred from the SN (see section
   4.2 of this document).

   Whether to use timer-based compression or not is controlled by the
   TIME_STRIDE control field, which can be set either by an IR, an IR-
   DYN, or by a compressed packet with extension 3. The compressor turns
   on timer-based compression by setting TIME_STRIDE to a value > 0, but
   that can be done first after the decompressor has declared its clock
   resolution, which is done by sending a CLOCK feedback option for any
   CID on the channel.

5. List compression issues

5.1. Generic extension header list

   Section 5.7.7.4 defines the static and dynamic parts of the IPv4
   header.  This section indicates a 'Generic extension header list'
   field in the dynamic chain, which has a variable length.  The
   detailed description of this field can be found in Section 5.8.6.1.

   The generic extension header list starts with an octet that is always
   present, so its length is one octet, at least.  If the 'GP' bit in
   the first octet is set to 1 then the length of the list is two
   octets, even if the list is empty.

5.2. CSRC list items in RTP dynamic chain

   Section 5.7.7.6 defines the static and dynamic parts of the RTP
   header.  This section indicates a 'Generic CSRC list' field in the



Jonsson, et al.                                                [Page 10]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   dynamic chain, which has a variable length.  This field uses the same
   encoding rules as the 'Generic extension header list' in the IPv4
   header, so the same rules apply to its length.

5.3. RTP dynamic chain

   Section 5.7.7.6 defines the static and dynamic parts of the RTP
   header.  In the dynamic part, a 'CC' field indicates the number of
   CSRC items present in the 'Generic CSRC list'. A 'CC' field can also
   be found within the 'Generic CSRC list' (when present), and these
   fields would then have the same meaning. In order to decode a
   compressed packet correctly it's necessary to know the 'CC' value
   because it has serious impact on the packet's length.  In normal
   case, the values of the fields are equal.

   Proposed behavior if the values are different:
      Both fields are within the RTP dynamic part but only the second
      'CC' field resides inside the 'Generic CSRC list' together with
      the XI items.  Since the 'CC' value determines the number of XI
      items in the CSRC list and isn't used otherwise, the first CC
      field should be ignored and only the second field (inside the CSRC
      list) should be used for incoming packets.  For outgoing packets
      both fields should be set to the same value.

5.4. Compressed lists in UO-1-ID packets

   This section describes the situation when a UO-1-ID packet carries a
   compressed list.  Compressed lists are encoded using Encoding Type 0
   (section 5.7.5 and 5.8.6.1) and every list may have a unique
   identifier (gen_id).  The identifier is present in U/O-mode when the
   compressor decides that it may use this list as a future reference.

   On one hand, the decompressor shouldn't save the list because UO-1-ID
   packets doesn't update the context.  On the other hand, the
   decompressor updates its translation table whenever an (Index, item)
   pair is received (section 5.8.1).  The decompressor must be able to
   handle such a packet, thus it has to behave as described in the
   latter case.  According to section 5.8.1.2, the compressor must
   increment Counter by 1.

5.5. Bit masks in list compression

   A 7-bit or 15-bit mask may be used in the insertion and/or removal
   schemes for compressed lists. It should be noted that even if a list
   has more than 7 items, a 7-bit mask could be used as long as changes
   are only applied in the first part of the reference list, and items
   with an index not covered by the 7-bit mask are thus kept unchanged.

5.6. Headers compressed with list compression





Jonsson, et al.                                                [Page 11]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   In section 5.8, it is stated that headers which can be part of
   extension header chains INCLUDE AH, null ESP, minimal encapsulation
   (MINE), GRE, and IPv6 extensions. This list of headers which can be
   compressed is correct, but the word INCLUDE should not be there,
   since only the header types listed can actually be handled. It should
   further be noted that for the Minimal Encapsulation (MINE) header,
   there is no explicit discussion of how to compress it, as the header
   is either sent uncompressed or fully compressed away.

5.7. ESP NULL header list compression

   Due to the offset of the fields in the trailer part of the ESP
   header, a compressor must only compress packets containing at most
   one NULL ESP header.

6. Updating properties

6.1. Implicit updates

   If an updating packet (e.g. R-0-CRC or UO-0) contains information
   about a specific field X (compressed RTP sequence number, typically),
   then X is updated according to the content of that packet.  But this
   packet implicitly updates all other inferred fields (i.e. RTP
   timestamp) according to the current mode and the appropriate mapping
   function of the updated and the inferred fields.

   An updating packet thus updates the reference values of all header
   fields, either explicitly or implicitly, with an exception for the
   UO-1-ID packet, which only updates TS, SN, IP-ID, and sequence
   numbers of IP extension headers (see 5.7.3). In UO-mode, all packets
   are updating packets, while in R-mode all packets with a CRC are
   updating packets.

   For example, a UO-0 packet contains the compressed RTP sequence
   number (SN). Such a packet also implicitly updates RTP timestamp,
   IPv4 ID, and sequence numbers of IP extension headers.

6.2. Updating properties of UO-1*

   In section 5.7.3, the updating properties of UO-1* are stated:

     "Values provided in extensions, except those in other SN, TS,
      or IP-ID fields, do not update the context."

   However, also sequence number fields of extension headers must be
   updated, which means the updating properties should be rephrased as:

     "The only values provided in extensions that update the context are
      the additional bits for the SN, TS, or IP-ID fields. Other values
      provided in extensions do not update the context. Note that
      sequence number fields of extension headers are also updated."



Jonsson, et al.                                                [Page 12]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


7. Context management and CID/context re-use

7.1. Compressor and decompressor MUST keep MAX_CID contexts

   As part of the negotiated channel parameters, compressor and
   decompressor have through the MAX_CID parameter agreed on the highest
   context identification (CID) number to be used. By agreeing on
   MAX_CID, both compressor and decompressor also agrees to provide
   memory resources to host at least MAX_CID+1 contexts, and an
   established context with CID within this negotiated space MUST be
   kept by both compressor and decompressor until either the CID gets
   re-used, or the channel is taken down or re-negotiated.

7.2. CID/context re-use

   As part of the channel negotiation, the maximal number of active
   contexts supported is negotiated between the compressor and the
   decompressor through the MAX_CID parameter. The value of MAX_CID can
   of course vary enormously between different link scenarios, as well
   as the load in terms of actual packet streams to compress. Depending
   on link technology, the ROHC channel lifetime will also vary from
   almost permanent to rather short-lived. However, in general it is not
   expected that resources will be allocated for more contexts than what
   can reasonably be expected to be active concurrently over the link.
   As a consequence hereof, context identifiers (CIDs) and context
   memory are resources that will have to be re-used by the compressor
   as part of what can be considered normal operation.

   How context resources are re-used is in RFC 3095 [1] and subsequent
   ROHC standards basically left unspecified and up to implementation.
   However, re-using a CID and its allocated memory is not always as
   simple as initiating a contexts with a previously unused CID. Because
   some profiles can be operating in various modes where packet formats
   vary depending on current mode, care has to be taken to ensure that
   the old context data will be completely and safely overwritten,
   eliminating the risk of undesired side effects from interactions
   between old and new context data.

   On a high level, CID/context re-use can be of two kinds, either re-
   use for a new context based on the same profile as the old context,
   or for a new context based on a different profile. These cases, are
   discussed separately in the following two subsections.

7.2.1. Re-using a CID/context with the same profile

   For multi-mode profiles, such as those defined in RFC 3095 [1], when
   a CID/context is re-used for a new context based on the same profile
   as the old context, the current mode of operation MUST be inherited
   from the old to the new context. The reason for this is that there is
   no reliable way for the compressor to inform the decompressor that a
   CID/context re-use is happening. The decompressor can thus not be



Jonsson, et al.                                                [Page 13]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   expected to flush the context memory for the CID, and there is no way
   to trigger a safe mode switching, which requires a decompressor-
   initiated handshake procedure, as defined in section 5.6 of [1].

   It should be noted that the rule of mode inheritance applies also
   when the CONTEXT_REINITIALIZATION signal is used to reinitiate an
   entire context.

7.2.2. Re-using a CID/context with a different profile

   When a CID is re-used for a new context based on a different profile
   than the old context, operation with that context MUST start in the
   initial mode of the profile (if it is a multi-mode profile). This
   applies both to IR-initiated new contexts and profile downgrades with
   IR-DYN (e.g. the IP/UDP/RTP->IP/UDP downgrade in [1] section 5.11.1).

   A CID for an R-mode operating context SHOULD NOT be re-used for a new
   context based on a different profile than the old context, because of
   the R-0/R-1 misinterpretation risk (these packets have no CRC). If a
   compressor still wants or has to do this, the compressor must be very
   careful to minimize the misinterpretation risk, e.g. by not using
   packets of types beginning with 00 or 10 before the compressor is
   highly confident that the new context has successfully been initiated
   at the decompressor.

7.3. Context updating properties for IR packets

   It should be noted that an IR does not flush the whole context, but
   updates all fields carried in the IR header. Similarly, an IR without
   a dynamic chain simply updates the static part of the context, while
   the rest of the context is left unchanged.

8. Other protocol clarifications

8.1. Meaning of NBO

   In general, an unset flag indicates the normal operation and a set
   flag indicates unusual behavior.  However, in IPv4 dynamic part
   (Section 5.7.7.4), if the 'NBO' bit is set, it means that network
   byte order is used.

8.2. IP-ID

   According to Section 5.7 IP-ID means the compressed value of the IPv4
   header's 'Identification' field. Compressed packets contain this
   compressed value (IP-ID), while IR packets with dynamic chain and IR-
   DYN packets transmit the original, uncompressed Identification field
   value. The IP-ID field always represents the Identification value of
   the innermost IPv4 header whose corresponding RND flag is not 1.





Jonsson, et al.                                                [Page 14]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent
   as 16-bit original Identification value(s) at the end of the
   compressed base header, according to the IP-ID description (see the
   beginning of section 5.7). When there is no compressed IP-ID, i.e.
   for IPv6 or when all IP Identification information is sent as-is (as
   indicated by RND/RND2 being set to 1), the decompressor ignores IP-ID
   bits sent within compressed base headers.

   It should be noted that when RND*=0, IP-ID is always compressed, i.e.
   expressed as an SN offset and byte-swapped if NBO=0. This is the case
   even when 16 bits of IP-ID is sent in extension 3.

   When RND=0 but no IP-ID bits are sent in the compressed header, the
   SN offset for IP-ID stays unchanged, meaning that Offset_m equals
   Offset_ref, as described in Section 4.5.5. This is further expressed
   in a slightly different way (with the same meaning) in Section 5.7,
   where it is said that "default-slope(IP-ID offset) = 0", meaning that
   if no bits are sent for IP-ID, its SN offset slope defaults to 0.

8.3. Extension-3 in UO-1-ID packets

   Extension-3 is applied to give values and indicate changes to fields
   other than SN, TS and IP-ID in IP header(s) and RTP header.  In case
   of UO-1-ID packets, it should be noted that values provided in
   extensions do not update the context, with an exception for SN, TS
   and IP-ID fields, which always update the context (Section 5.7.3.).
   It should also be noted that a UO-1-ID packet with Extension 3 must
   never be sent with RND flags that changes the packet interpretation,
   i.e. that would violate the base condition for UO-1-ID (at least one
   RND value must be 0).

   Besides, usage of Extension-3 in UO-1-ID can be useful to compress a
   transient change in a packet stream.  For example, if a field's value
   changes in the current packet but in the next packet it returns to
   its regular behavior.  E.g. changes in TTL.

8.4. Extension-3 in UOR-2* packets

   If Extension-3 is used in a UOR-2* packet then the information of the
   extension updates the context (Section 5.7.4).  Some flags of the IP
   header in the extension (e.g. NBO or RND) changes the interpretation
   of fields in UOR-2* packets. In these cases, when a flag changes in
   Extension-3, a decompressor should re-parse the UOR-2* packet.

8.5. Multiple SN options in one feedback packet

   The length of the sequence number field in the original ESP header is
   32 bits.  A decompressor can't send back all the 32 bits in a
   feedback packet unless it uses multiple SN options in one feedback
   packet.  Section 5.7.6.1 declares that a FEEDABCK-2 packet can




Jonsson, et al.                                                [Page 15]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   contain variable number of feedback options and the options can
   appear in any order.

   A compressor should be able to process multiple SN options in one
   feedback packet.

8.6. Multiple CRC options in one feedback packet

   Although it is never required to have more than one single CRC option
   in a feedback packet, having multiple CRC options is still allowed.
   If multiple CRC options are included, all such CRC options will be
   identical, as they will be calculated over the same header.

8.7. Packet decoding during mode transition

   Each ROHC profile defines its own set of packet formats, and also its
   own feedback packets. The use of various operational modes is also
   defined by each specific profile. A decompressor can therefore not
   initiate a mode transfer request before at least one packet of a new
   context has been correctly decompressed, establishing the context
   based on one specific profile (as specified in IR packets). First
   then the context has been established, the decompressor knows the
   profile used, which modes are defined by that profile, and the
   feedback packet formats available.

   If the transition procedures in sections 5.6.5 and 5.6.6 of [1] are
   followed (and not the enhanced procedures described in section 3 of
   this document), it is important to note that type 0 or type 1 packets
   may be received by the decompressor during the first half of the
   transition procedure, and these packets must not mistakenly be
   interpreted as the packets sent by the compressor to indicate
   completed transition. The decompressor side must therefore keep track
   of the transition status, e.g. with an additional parameter. If the
   enhanced transition procedures described in section 3 of this
   document are used, the D_TRANS parameter can serve this purpose since
   its definition and usage is slightly modified.

8.8. How to respond to lost feedback links?

   One potential issue that might have to be considered, depending on
   link technology, is whether feedback links might get lost, and in
   such cases how this is handled. When the compressor is notified that
   the feedback channel is down, the compressor must be able to handle
   it by restarting compression with creating a new context. Creating a
   new context also implies to use a new CID value.

   Generally, feedback links are not expected to disappear when once
   present, but it should be noted that this might be the case for
   certain link technologies.





Jonsson, et al.                                                [Page 16]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


8.9. What does "presumed zero if absent" mean on page 88?

   On page 88, RFC 3095 says that R-P contains the absolute value of RTP
   Padding bit and it's presumed zero if absent.  It could be absent
   from RTP header flags and fields, from the extension type 3 or from
   the ROHC packet. It's been agreed that the RTP padding bit is
   presumed zero if absent from the RTP header flags.

8.10. UOR-2 in profile 2 (UDP)

   One single new format is defined for UOR-2 in profile 2, which
   replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile
   1. The same UOR-2 format is thus used independent of if there are IP
   headers with a corresponding RND=1 or not.

8.11. Sequence number LSB's in IP extension headers

   In section 5.8.5, formats are defined for compression of IP extension
   header fields. These include compressed sequence number fields, and
   it is said that these fields contain "LSB of sequence number". This
   means these sequence numbers are not "LSB-encoded" as e.g. the RTP
   sequence number with an interpretation interval, but are actually
   just the LSB's of the uncompressed fields.

8.12. Expecting UOR-2 ACKs in O-mode

   It should be noted that the use of UOR-2 ACKs in O-mode, as discussed
   in section 5.4.1.1.2, is indeed optional, and a decompressor can send
   ACKs for other purposes than actually acking the UOR-2, without then
   having to continue sending them for all UOR-2. Similarly, compressor
   implementations can totally ignore UOR-2 ACKs for the purpose of
   adapting the optimistic approach strategies. Current implementation
   experience also suggests using that approach, and the recommendation
   is thus to not make use of the optional ACK mechanism in O-mode,
   neither in compressor nor in decompressor implementations.

   For implementers who still want to make use of the optional O-mode
   acks, the following clarifications should be taken into account.
   Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in O-mode,
   and explains a conceptual algorithm for a compressor to determine
   whether such ACKs can be expected from the decompressor, simply using
   a condition based on unspecified parameters k_3 and n_3. However,
   what is not clearly pointed out is the importance of being very
   careful when implementing this confidence algorithm, as using an
   incorrect expectation on UOR-2 ACKs as a basis for compressor
   behavior will significantly degrade the compression performance. If a
   compressor implementation wants to adapt its optimistic approach
   behavior on potential UOR-2 ACK usage, the confidence algorithm for
   determining UOR-2 ACK usage must be carefully designed, with k_3 and
   n_3 having values much larger than 1, as UOR-2 ACKs can be sent from
   a decompressor for other purposes than to actually acknowledge the



Jonsson, et al.                                                [Page 17]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   UOR-2 packet, e.g. to send feedback data such as clock resolution, or
   to initiate a mode transfer. Before adapting a compressor to the
   potential use of UOR-2 ACKs, the implementer must ensure all aspects
   are considered by the confidence algorithm.

8.13. Compression of SN in AH and GRE extension headers

   The AH and GRE sequence numbers are compressed exactly as the ESP
   sequence number. Specifically, the principle for when to include or
   exclude the AH and GRE sequence numbers is the same as for ESP, i.e.
   the following rule applies to all these sequence numbers:

     Sequence Number: Not sent when the offset from the sequence number
                      of the compressed header is constant. When the
                      offset is not constant, the sequence number is
                      compressed by sending LSBs. See 5.8.4.

9. ROHC negotiation clarifications

   According to section 4.1, the link layer must provide means to
   negotiate e.g. the channel parameters listed in section 5.1.1.  One
   of these parameters is the PROFILES parameter, which is said to be a
   set of non-negative integers where each integer indicates a profile
   supported by the decompressor.  This can be interpreted as if it is
   sufficient to have a mechanism to announce profile support from
   decompressor to compressor.  However, things are a little bit more
   complicated than that.

   Each profile is identified by a 16-bit value, where the 8 LSB bits
   indicate the actual profile, and the 8 MSB bits indicate the variant
   of that profile (see chapter 8).  In the ROHC headers sent over the
   link, the profile used is identified only with the 8 LSB bits, which
   means that the compressor and decompressor must have agreed on which
   variant to use for each profile.  This can be done in various ways,
   but the negotiation protocol must provide means to do it.

   In conclusion, the negotiation protocol must be able to communicate
   to the compressor the set of profiles supported by the decompressor,
   and when multiple variants of the same profile are available, also
   provide means for the decompressor to know which variant will be used
   by the compressor.  This basically means that the PROFILES set after
   negotiation must not include more than one variant of the same
   profile.

10. PROFILES suboption in ROHC-over-PPP

   The logical union of suboptions for IPCP and IPV6CP negotiations, as
   specified by ROHC over PPP [2], can not be used for the PROFILES
   suboption, as the whole union would then have to be considered within
   each of the two IPCP negotiations, to avoid getting an ambiguous
   profile set. An implementation of RFC 3241 must therefore make sure



Jonsson, et al.                                                [Page 18]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   the same profile set is negotiated for both IPv4 and IPv6 (IPCP and
   IPV6CP).

11. Constant IP-ID encoding in IP-only and UPD-Lite profiles

   In the ROHC IP-only profile, section 3.3 of RFC 3843 [3], a mechanism
   for encoding of a constant Identification value in IPv4 (constant IP-
   ID) is defined. This mechanism is also used by the ROHC UDP-Lite
   profiles, RFC 4019 [5].

   It should be noted that the "Constant IP-ID" mechanism applies to
   both the inner and the outer IP header, when present , meaning that
   there will be both a SID and a SID2 context value.

12. Security considerations

   This document provides a number of clarifications to [1], but it does
   not make any changes or additions to the protocol.  As a consequence,
   the security considerations of [1] apply without additions.

13. IANA considerations

   This document does not require any IANA actions.

14. Acknowledgment

   The authors would like to thank Vicknesan Ayadurai, Carsten Bormann,
   Mikael Degermark, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees,
   Mark West, Tommy Lundemo, Alan Kennington and Remi Pelland for their
   contributions and comments.

15. References

15.1. Normative References

   [1]  C. Bormann, et al., "RObust Header Compression (ROHC) Framework
        and four profiles: RTP, UDP, ESP, and uncompressed",
        RFC 3095, July 2001.

   [2]  C. Bormann, "Robust Header Compression (ROHC) over PPP",
        RFC 3241, April 2002.

   [3]  L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC):
        A Compression Profile for IP", RFC 3843, June 2004.

   [4]  W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994.

15.2. Informative References

   [5]  G. Pelletier, "RObust Header Compression (ROHC): Profiles for
        User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.



Jonsson, et al.                                                [Page 19]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


16. Authors' Addresses

   Lars-Erik Jonsson
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden
   Phone: +46 8 404 29 61
   EMail: lars-erik.jonsson@ericsson.com

   Kristofer Sandlund
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden
   Phone: +46 8 404 41 58
   EMail: kristofer.sandlund@ericsson.com

   Peter Kremer
   Conformance and Software Test Laboratory
   Ericsson Hungary
   H-1300 Bp. 3., P.O. Box 107, HUNGARY
   Phone: +36 1 437 7033
   EMail: peter.kremer@ericsson.com
































Jonsson, et al.                                                [Page 20]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


Appendix A - Sample CRC algorithm


   #!/usr/bin/perl -w
   use strict;
   #=================================
   #
   # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
   #
   # This little demo shows the three types of CRC in use in RFC 3095,
   # the robust header compression standard.  Type your data in
   # hexadecimal form and then press Control+D.
   #
   #---------------------------------
   #
   # utility
   #
   sub dump_bytes($) {
       my $x = shift;
       my $i;
       for ($i = 0; $i < length($x); ) {
     printf("%02x ", ord(substr($x, $i, 1)));
     printf("\n") if (++$i % 16 == 0);
       }
       printf("\n") if ($i % 16 != 0);
   }

   #---------------------------------
   #
   # The CRC calculation algorithm.
   #
   sub do_crc($$$) {
       my $nbits = shift;
       my $poly = shift;
       my $string = shift;

       my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
       for (my $i = 0; $i < length($string); ++$i) {
     my $byte = ord(substr($string, $i, 1));
     for( my $b = 0; $b < 8; $b++ ) {
         if (($crc & 1) ^ ($byte & 1)) {
          $crc >>= 1;
          $crc ^= $poly;
         } else {
          $crc >>= 1;
         }
         $byte >>= 1;
     }
       }
       printf "%2d bits, ", $nbits;
       printf "CRC: %02x\n", $crc;



Jonsson, et al.                                                [Page 21]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


   }

   #---------------------------------
   #
   # Test harness
   #
   $/ = undef;
   $_ = <>;         # read until EOF
   my $string = ""; # extract all that looks hex:
   s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
   dump_bytes($string);

   #---------------------------------
   #
   # 32-bit segmentation CRC
   # Note that the text implies this is complemented like for PPP
   # (this differs from 8, 7, and 3-bit CRC)
   #
   #      C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
   #             x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
   #
   do_crc(32, 0xedb88320, $string);

   #---------------------------------
   #
   # 8-bit IR/IR-DYN CRC
   #
   #      C(x) = x^0 + x^1 + x^2 + x^8
   #
   do_crc(8, 0xe0, $string);

   #---------------------------------
   #
   # 7-bit FO/SO CRC
   #
   #      C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
   #
   do_crc(7, 0x79, $string);

   #---------------------------------
   #
   # 3-bit FO/SO CRC
   #
   #      C(x) = x^0 + x^1 + x^3
   #
   do_crc(3, 0x6, $string);








Jonsson, et al.                                                [Page 22]

INTERNET-DRAFT      The RFC 3095 Implementer's Guide     August 9, 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org.


Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





This Internet-Draft expires February 9, 2006.







Jonsson, et al.                                                [Page 23]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/