Network Working Group                                       L-E. Jonsson
INTERNET-DRAFT                                               K. Sandlund
Expires: August 2006
TO UPDATE: RFC 3095, 3241, 3843, 4019, 4362                 G. Pelletier
Expires: November 2006                                         P. Kremer
                                                                Ericsson
                                                        February 1,
                                                            May 22, 2006

                      The

                      RObust Header Compression (ROHC):
                 Corrections and Clarifications to RFC 3095 Implementer's Guide
                   <draft-ietf-rohc-rtp-impl-guide-18.txt>
                   <draft-ietf-rohc-rtp-impl-guide-19.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 Some parts of RFC 3095, and it also
   corrects some actual errors in the specification. The corrections specification
   are unclear or contain errors that may lead to misinterpretations
   that may impair interoperability between different implementations.
   This document provides corrections, additions and clarifications provided herein must be followed to get interoperable
   implementations, i.e.
   RFC 3095; this document thus updates RFC 3095. Further, minor
   interpretation details of In addition, other
   clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP
   profile) and RFC 4109 (ROHC UPD-Lite profiles) are also addressed. provided.

Table of Contents

   1. Introduction.....................................................3 Introduction and terminology.....................................3
   2. CRC calculation and coverage issues..............................3 coverage.....................................4
      2.1. CRC calculation.............................................3 calculation.............................................4
      2.2. Padding octet in CRC........................................4 and CRC calculations..........................4
      2.3. CRC coverage in CRC feedback options........................4
      2.4. CRC coverage of the ESP NULL header.........................4 header.........................5
   3. Enhanced Mode transition..................................................5
      3.1. Feedback during mode transition procedures..............................4
      3.1. Modified to U- and O-mode............5
         3.1.1. Mode transition logic for enhanced transitions..........5
      3.2. procedures allowing sparse feedback....5
         3.1.2. Transition from Reliable to Optimistic mode.................6
      3.3. mode............6
         3.1.3. Transition to Unidirectional mode...........................6 mode......................7
      3.2. Feedback during mode transition.............................7
      3.3. Packet decoding during mode transition......................8
   4. Timestamp encoding considerations................................7 encoding...............................................8
      4.1. Encoding used for compressed TS bits........................7 bits........................8
      4.2. (De)compression of TS without transmitted TS bits...........7 bits...........9
      4.3. Interpretation intervals for TS encoding....................8 encoding...................10
      4.4. TS_STRIDE for scaled timestamp encoding.....................8 encoding....................10
      4.5. TS wraparound with scaled timestamp encoding................9 encoding...............11
      4.6. Recalculating TS_OFFSET.....................................9 TS_OFFSET....................................12
      4.7. TS_STRIDE and the Tsc flag in Extension 3..................10 3..................12
      4.8. Using timer-based compression..............................10 compression..............................13
   5. List compression issues.........................................10 compression................................................13
      5.1. Generic extension header list..............................10
      5.2. CSRC list items in RTP dynamic chain.......................11 chain.......................13
      5.2. Multiple occurrences of the CC field.......................14
      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. compression..............................14
      5.4. Headers compressed with list compression...................12
      5.7. compression...................14
      5.5. ESP NULL header list compression...........................12
      5.8. compression...........................15
      5.6. Translation tables and indexes for IP extension headers....12
      5.9. headers....15
      5.7. Reference list.............................................12 list.............................................15
      5.8. Compression of AH and GRE sequence numbers.................16
   6. Updating properties.............................................13 properties.............................................17
      6.1. Implicit updates...........................................13 updates...........................................17
      6.2. Updating properties of UO-1*...............................13 UO-1*...............................17
      6.3. Context updating properties for IR packets.................18
      6.4. RTP padding field (R-P) in extension 3.....................18
      6.5. RTP eXtension bit (X) in dynamic part......................18
   7. Context management and CID/context re-use.......................14 re-use.......................19
      7.1. The Persistence of decompressor MUST keep MAX_CID contexts................14 contexts.......................19
      7.2. CID/context re-use.........................................14 re-use.........................................19
         7.2.1. Re-using a CID/context with the same profile..........14 profile..........20
         7.2.2. Re-using a CID/context with a different profile.......15
      7.3. Context updating properties for IR packets.................15 profile.......20
   8. Other protocol clarifications...................................15 clarifications...................................21
      8.1. Meaning of NBO.............................................15 NBO.............................................21
      8.2. IP-ID......................................................15 IP-ID......................................................21
      8.3. Extension-3 in UO-1-ID packets.............................16
      8.4. Extension-3 in UOR-2* packets..............................16 packets..............................21
      8.4. Multiple occurrences of the M bit..........................21
      8.5. Multiple SN options in one feedback packet.................16 packet.................22
      8.6. Multiple CRC options in one feedback packet................17 packet................22
      8.7. Packet decoding during mode transition.....................17
      8.8. How to respond Responding to lost feedback links?.....................17
      8.9. What does "presumed zero if absent" mean on page 88?.......18
      8.10. links..........................22
      8.8. UOR-2 in profile 2 0x0002 (UDP) and profile 3 (ESP)..............18
      8.11. 0x0003 (ESP).....23
      8.9. Sequence number LSB's in IP extension headers.............18
      8.12. headers..............23
      8.10. Expecting UOR-2 ACKs in O-mode............................18
      8.13. Compression of SN in AH and GRE extension headers.........19 O-mode............................23
   9. ROHC negotiation clarifications.................................19 negotiation................................................23
   10. PROFILES suboption in ROHC-over-PPP............................20 ROHC-over-PPP............................24
   11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......20 profiles.......24
   12. Security considerations........................................20 considerations........................................24
   13. IANA considerations............................................20 considerations............................................24
   14. Acknowledgment.................................................20 Acknowledgment.................................................24
   15. References.....................................................21 References.....................................................25
      15.1. Normative References......................................21 References......................................25
      15.2. Informative References....................................21 References....................................25
   16. Authors' Addresses.............................................21 Addresses.............................................26
   Appendix A - Sample CRC algorithm..................................22 algorithm..................................27

1. Introduction and terminology

   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 summarizes identified issues,
   and provide the clarifications issues and provides corrections
   needed to make
   creation of interoperable for implementations possible. It should thus be
   noted that it is essential that implementers of RFC 3095 follow the
   corrections and clarifications provided herein, to interoperate, i.e. this document
   constitute it
   constitutes an update to RFC 3095. This document also provides other
   clarifications related to common misinterpretations of the
   specification. When referring to RFC 3095, this document should
   therefore also be referenced.

   A few minor interpretation details of RFC 3241 [2] (ROHC over

   In addition, some clarifications and corrections are also provided
   for RFC 3241 [2] (ROHC over PPP), RFC 3843 [3] [4] (ROHC IP-only
   profile), and RFC 4019 [5] (ROHC UDP-Lite
   profiles) profiles), which are thus
   also addressed in updated by this document (chapter 10-11). document. Furthermore, RFC 4362 [7] (ROHC Link-
   Layer Assisted Profile) is implicitly updated by this document, since
   also RFC 4362 is based on RFC 3095.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   Note that all 2119 [6].

   When a section and chapter references of this document makes formal corrections, additions
   or invalidations to text in RFC 3095, this is clearly summarized. The
   text from RFC 3095 that is being addressed is given and labeled
   "INCOMPLETE", "INCORRECT" or "INCORRECT AND INVALIDATED", followed by
   the correct text labeled "CORRECTED", where applicable. When a formal
   addition is provided, it is given with the label "FORMAL ADDITION".

   In this document, a reference to a section or a chapter that is made
   without an explicit mention of a specific document refer refers to a
   section or a chapter in RFC 3095 [1], where not unless 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, CRCs, but it does
   not specify what algorithm is used. The 3, 7 and 8-bit CRCs are
   calculated using the same CRC algorithm can be used defined in these
   cases as well. [3].

   A PERL implementation of the algorithm (written by Carsten Bormann) can be found in Appendix A of
   this document.

2.2. Padding octet in and CRC

   According to calculations

   Section 5.9.1, in case of IR and IR-DYN packets 5.9.1 is incomplete, as it does not mention how to handle the
   padding octet in CRC
   "is calculated over the entire calculations for IR or IR-DYN packet, excluding Payload and including CID or Add-CID octet". IR-DYN packets. Padding
   isn't meant to be a meaningful part of a packet and MUST NOT be is not included
   in the CRC calculation. As a result, the CRC MUST NOT does not cover the Add-CID Add-
   CID octet for CID 0, either.

2.3. CRC coverage in CRC feedback options

   Section 5.7.6.3 states

   INCOMPLETE RFC 3095 TEXT (section 5.9.1):

      "The CRC option contains an 8-bit CRC computed in the IR and IR-DYN packet is calculated over the entire feedback payload, without
       IR or IR-DYN packet, excluding Payload and including CID or any
       Add-CID octet."

   CORRECTED TEXT:

      "The CRC in the IR and IR-DYN packet type is calculated over the entire
       IR or IR-DYN packet, excluding Payload, Padding and code
   octet, but including any CID fields, using
       or any Add-CID octet, except for the polynomial of section
   5.9.1". However, add-CID octet for CID 0."

2.3. CRC coverage in CRC feedback options

   Section 5.7.6.3 is incomplete, as it does not mention how the "size"
   field is handled,
   if present. handled when calculating the 8-bit CRC used in the CRC
   feedback option. Since the "size" field can be considered an
   extension of the "code" field, it must be treated as the "code" field, i.e.
   field.

   INCOMPLETE RFC 3095 TEXT (section 5.7.6.3):

      "The CRC option contains an 8-bit CRC computed over the
   "size" entire
       feedback payload, without the packet type and code octet, but
       including any CID fields, using the polynomial of section 5.9.1."

   CORRECTED TEXT:

      "The CRC option contains an 8-bit CRC computed over the entire
       feedback payload including any CID fields but excluding the
       packet type, the 'Size' field MUST NOT be covered by and the CRC. 'Code' octet, using the
       polynomial of section 5.9.1."

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 must be interpreted as including 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 MUST have has the same CRC coverage as the ESP header used in the ESP
   profile (section 5.7.7.7).

3. Enhanced Mode transition

3.1. Feedback during mode transition procedures to U- and O-mode

   Section 5.6.1 states that during mode transitions, while the D_TRANS
   parameter is I, the decompressor send feedback for each received
   packet. This restrictive behavior prevents a decompressor from using
   a sparse feedback algorithm during mode transitions.

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

   These modifications affect transitions enhanced procedures should be considered only as a possible
   improvement to Optimistic and
   Unidirectional modes of operation, i.e. the transitions described a decompressor implementation, since interoperability
   is not affected in
   sections 5.6.5 and 5.6.6, 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.

   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 any way. A decompressor implemented according to
   the optimized procedures would be able to will interoperate with an RFC3095
   compressor, as well as a decompressor implemented according to the
   procedures described in RFC3095 would do.

3.1. Modified does.

3.1.1. Mode transition logic for enhanced transitions procedures allowing sparse feedback

   The intent with purpose of these enhanced transition procedures is to allow the
   decompressor to stop sending sparsely send 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 This is realized achieved by allowing the decompressor transition
   parameter (D_TRANS) to be set to P (Pending) at that stage. However, stage, as mentioned above, there are robustness concerns related to this
   optimization, shown
   in the transition diagrams of sections 3.1.2 and to avoid 3.1.3 below.

   This enhanced transition, where feedback need not be sent for every
   decompressed packet, does however introduce some considerations in
   case feedback messages would be lost. Specifically, there is a risk
   for a deadlock situations with never completed
   transitions as situation when a result of transition from R-mode is performed
   in case no feedback losses, message successfully reaches the compressor and
   the transition is not complete. For transition between U-mode and O-
   mode, there is also a small risk for reduced compression efficiency.

   To avoid this, the decompressor MUST continue to send feedback at
   least periodically, also when in Pending transition state. That would be This is
   equivalent to enhancing the equivalence definition of enhancing the D_TRANS parameter definition in
   section 5.6.1, to include a the definition of a Pending state operation. state:

   - 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, with some
      periodicity, 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.

3.2.

   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, and make those transition diagrams more
   consistent with the diagram describing the transition to R-mode.

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

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

4. Timestamp encoding considerations

3.2. Feedback during mode transition

   Section 5.6.1 states that feedback is always used during mode
   transitions. However, the text then continues by making concrete
   applications of the rule in an inconsistent way, making it unclear
   when CRC's are used. Further, the text does not define how the
   compressor should act during mode transitions based on feedback not
   protected by CRCs, i.e. whether to carry out mode transition actions
   or not. The proper behavior from the compressor is to perform any
   action related to mode transitions only when the feedback is
   protected by the CRC option.

   INCOMPLETE RFC 3095 TEXT (section 5.6.1):

      "As a safeguard against residual errors, all feedback sent during
       a mode transition MUST be protected by a CRC, i.e., the CRC
       option MUST be used."

   CORRECTED TEXT:

      "As a safeguard against residual errors, all feedback sent by the
       decompressor during a mode transition MUST be protected by a CRC,
       i.e., the CRC option MUST be used. The compressor MUST ignore
       feedback information related to mode transition if the feedback
       is not protected by the CRC option."
   One more related issue that requires clarifications comes from the
   following text at the end of section 5.6.1:

      "While D_TRANS is I, the decompressor sends a NACK or ACK carrying
       a CRC option for each received packet."

   However, Section 5.5.2.2 already stated that for R-mode, feedback is
   never sent for packets that do not update the context, i.e. for
   packets that do not carry a CRC such as R-0 and R-1* packets.

   This means that when D_TRANS=I during mode transition, a decompressor
   operating in R-mode sends an acknowledgement for each packet it
   receives and MUST use the sequence number that corresponds to the
   packet that last updated the context, i.e. the decompressor MUST NOT
   use the sequence number of the R-0 or the R-1* packet."

3.3. 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 transition 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). The
   context must be established before the decompressor can know the
   profile used, which modes are defined by that profile, and the
   feedback packet formats available. Mode transition can therefore not
   be initiated by the decompressor before it has an established context
   for the CID.

   If the original transition procedures in sections 5.6.5 and 5.6.6 are
   followed (and not the enhanced procedures described in section 3.1 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 be mistakenly
   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.

4. Timestamp encoding

4.1. Encoding used for compressed 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

   When ROHC RTP operate using its most efficient packet types, 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). Fields that can be inferred from the
   SN are the IP Identification (IP-ID) and the RTP Timestamp (TS).

   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. in SO-state operation. This section
   specifies how the TS (scaled or unscaled) is decompressed 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 decompressed assuming a linear
   extrapolation from the SN, i.e. delta_TS = delta_SN * default-slope,
   where delta_SN and delta_TS are both signed integers. Section 5.7
   defines the potential values for default-slope.

   INCOMPLETE RFC 3095 TEXT (section 5.7):

      "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)."

   CORRECTED TEXT:

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

       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)."

   INCORRECT AND INVALIDATED RFC 3095 TEXT (section 5.5.1.2):

      "For example, in a typical case where the string pattern has the
       form of non-SN-field = SN * slope + offset, one ACK is enough if
       the slope has been previously established by the decompressor
       (i.e., only the new offset needs to be synchronized). Otherwise,
       two ACKs are required since the decompressor needs two headers to
       learn both the new slope and the new offset."

   Consequently, there is no other slope value than the default-slope,
   as defined in section 5.7.

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 (TIME_STRIDE set to a non-zero value),
   the interpretation interval is:
      p = 2^(k-1) - 1 (as per section 4.5.4)
   Otherwise, the interpretation interval is:
      p = 2^(k-2) - 1 (as per section 5.7)

   Since two different p-values are used, the compressor must take this
   into account throughout the process of enabling timer-based
   compression (see section 4.8 of this document). During transition
   from window-based compression to timer-based compression, it is thus
   necessary that the compressor keep k large enough to cover both
   interpretation intervals.

4.4. TS_STRIDE for scaled timestamp encoding

   RFC 3095 defines the timestamp stride (TS_STRIDE) 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 bits

   RTP Timestamp values (TS) are always encoded using W-LSB encoding,
   both when sent scaled and or constitutes the
   default-slope used when sent unscaled. For decompressing an unscaled TS values sent in
   Extension 3, W-LSB encoded values are sent using through a linear
   extrapolation from the self-describing
   variable-length format (section 4.5.6), and SN (see also section 4.2 of this applies to both
   scaled document).

   The relation between TS and unscaled values.

4.2. (De)compression TS_SCALED, given by the following
   equality in section 4.5.3, defines the mathematical meaning of
   TS_STRIDE:

      TS without transmitted = TS_SCALED * TS_STRIDE + TS_OFFSET

   TS_SCALED is incorrectly written as TS bits / TS_STRIDE in the compression
   step following the above core equality. This formula is incorrect
   both because it excludes TS_OFFSET and because it would prevent a
   TS_STRIDE value of 0, which is an alternative not excluded by the
   core equality above. 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
   would still lack a proper output for TS_STRIDE equal to 0. The
   formula of "2. Compression" is thus invalid.

   INCORRECT RFC 3095 explains that SO-state provides TEXT (section 4.5.3):

      "2. Compression: After initialization, the compressor no longer
          compresses the original TS values. Instead, it compresses the most efficient
          downscaled values: TS_SCALED = TS / TS_STRIDE. The
          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 method could be transmitted in RTP compressed headers. All other
   fields are then omitted either because they are unchanged W-LSB encoding or because
   they can be reconstructed through a function from the SN (i.e. by
   combining
          timer-based encoding described in the transmitted SN bits with state information from next section."

   CORRECTED TEXT:

      "2. Compression: After initialization, the
   context). Although compressor no longer
          compresses the original TS values. Instead, it is never spelled out explicitly what fields are
   inferred from compresses the SN in this way, one should
          downscaled values. The compression method could be able either
          W-LSB encoding or the timer-based encoding described in the
          next section."

4.5. TS wraparound with scaled timestamp encoding

   Section 4.5.3 states in point 4 and 5 that the compressor is not
   required to figure out initialize TS_OFFSET at wraparound, but that this principle applies it is
   required to increase the IP Identification (IP-ID) field
   and number of bits sent for the RTP Timestamp (TS) field.

   IP-ID compression scaled TS value
   when there is a TS wraparound. The decompressor is also required to
   detect and decompression, both cope with TS wraparound, including updating TS_OFFSET.

   This method is not interoperable and without
   transmitted IP-ID bits not robust. The gain is also
   insignificant, as TS wraparound happens very seldom. Therefore, the
   compressor reinitializes TS_OFFSET upon TS wraparound, by sending
   unscaled TS.

   INCORRECT RFC 3095 TEXT (section 4.5.3):

      "4. Offset at wraparound: Wraparound of the unscaled 32-bit TS
          will invalidate the current value of TS_OFFSET used in the compressed header, are well defined in
   section 4.5.5 (see section 8.2
          equation above. For example, let us assume TS_STRIDE = 160 =
          0xA0 and the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50
          = 80.  Then if the next RTP TS = 0x00000130 (i.e., the
          increment is 160 * 2 = 320), the new TS_OFFSET should be
          0x00000130 modulo 0xA0 = 0x90 = 144.  The compressor is not
          required to re-initialize TS_OFFSET at wraparound. Instead,
          the decompressor MUST detect wraparound of this document). However, for the unscaled TS it
          (which is only defined how trivial) and update TS_OFFSET to decompress based on actual TS bits in

          TS_OFFSET = (Wrapped around unscaled TS) modulo TS_STRIDE
   CORRECTED TEXT:

      "4. Offset at wraparound: If the
   compressed header, either scaled or unscaled, but value of TS_STRIDE is not how equal
          to infer a power of two, wraparound of the unscaled 32-bit TS from the SN, i.e. will
          change the SO-state operation. Although value of TS_OFFSET. When this happens, the general
   idea is simple,
          compressor SHOULD reinitialize TS_OFFSET by sending unscaled
          TS, as in 1 above."

   INCORRECT AND INVALIDATED RFC 3095 TEXT (section 4.5.3):

      The entire point 5, i.e. the actual operation must be clearly defined entire text starting from "5.
      Interpretation interval at wraparound ...", down to
   ensure interoperability. There are also inconsistent and including
      the block of text pieces that starts with "Let a be the number of LSBs"
      and that ends with "...interpretation interval is b." is incorrect
      and is thus invalid.

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 confuse still stay unchanged.
   To ensure correct decompression of subsequent packets, the
   decompressor MUST therefore always recalculate TS_OFFSET (RTP TS
   modulo TS_STRIDE) when a packet with an implementer unscaled TS value is
   received.

4.7. TS_STRIDE and result the Tsc flag in non-interoperable
   implementations. This section therefore provides Extension 3

   The Tsc flag in Extension 3 indicates whether TS is scaled or not.
   The value of the necessary
   clarifications Tsc flag thus applies to SN-to-TS decompression, i.e. decompression of all TS
   (scaled or unscaled) when bits, also if there
   are no TS bits are transmitted in the
   compressed header. extension itself. When no TS bits are transmitted is scaled, it is
   always scaled using context(TS_STRIDE). The legend for Extension 3 in
   section 5.7.5 incorrectly states that value(TS_STRIDE) is used for
   scaled TS, which is incorrect.

   If TS_STRIDE is present in Extension 3, as indicated by the Tss flag
   being set, the TS field in the compressed header, header SHOULD contain
   unscaled TS bits, i.e. the encoded Tsc flag SHOULD NOT be set when Tss is set
   since an unscaled TS value (scaled or unscaled) is needed together with TS_STRIDE to be decompressed assuming recalculate
   the TS_OFFSET. If TS_STRIDE is included in a linear
   extrapolation from compressed header with
   scaled TS, the SN, i.e. delta_TS decompressor must ignore and discard field(TS_STRIDE).

   INCORRECT RFC 3095 TEXT (section 4.5.3):

      "Tsc: Tsc = delta_SN * default-slope.

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

     If value(Tsc) 0 indicates that TS is not scaled;
            Tsc = 1, Scaled RTP Timestamp encoding 1 indicates that TS is used before
     compression (see scaled according to section 4.5.3), and default-slope(TS) =
             4.5.3, using value(TS_STRIDE).
             Context(Tsc) is always 1.  If value(Tsc) = 0, the Timestamp value scaling is compressed as-is, and
     default-slope(TS) not desired, the
             compressor will establish TS_STRIDE = value(TS_STRIDE).

   What must be noted here 1."
   CORRECTED TEXT:

      "Tsc: Tsc = 0 indicates that TS is not scaled;
            Tsc = 1 indicates that no slope value TS is used other than the
   default-slope value, as defined in scaled according to section 5.7. There
            4.5.3, using context(TS_STRIDE).

            Context(Tsc) is confusing
   text in section 5.5.1.2 that might mistakenly be interpreted as if always 1.  If scaling is not desired, the slope can have different values
            compressor will establish TS_STRIDE = 1.

            If field(Tsc) = 1, and be "learned", which is
   incorrect. The default-slope from 5.7 if TSS = 1 (meaning that TS_STRIDE is always
            present in the extension), field(TS_STRIDE) MUST be ignored
            and discarded."

   When the compressor re-establishes a new value used when
   decompressing TS based on SN.

4.3. Interpretation intervals for TS_STRIDE using
   Extension-3, it should send unscaled TS encoding

   Section 4.5.4 defines the interpretation interval, p, for bits together with TS_STRIDE.

4.8. Using timer-based compression

   Timer-based compression of the RTP timestamp.  However, Section 5.7 defines a
   different interpretation interval, which is defined timestamp, 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 described in section
   4.5.4, p = 2^(k-1) - 1, MUST may be used for TS.  Otherwise, to reduce the interval number of section 5.7, p = 2^(k-2) - 1, MUST transmitted timestamp bits
   (bytes) needed when the timestamp can not be used, i.e. inferred from the SN.
   Timer-based compression is only used for decompression of compressed
   headers that contains a TS with
   regular W-LSB encoding.

   Since two different p-values field, otherwise when no timestamp bits
   are used, present the compressor must take this
   into account during timestamp is linearly inferred from the process SN (see
   section 4.2 of enabling this document).

   Whether to use timer-based compression. 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. Before timer-based
   compression can be used, the decompressor will
   have has to inform the
   compressor (on a per-channel basis) about its clock resolution. Further, resolution by
   sending a CLOCK feedback option for any CID on the channel. The
   compressor has to send can then initiate timer-based compression by sending (on a per-
   context
   per-context basis) a non-zero TIME_STRIDE to the decompressor.

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

5. List 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

5.1. CSRC list items 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, dynamic chain

   Section 5.7.7.6 defines the mathematical meaning of
   TS_STRIDE:

      TS = TS_SCALED * TS_STRIDE + TS_OFFSET
   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, static 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 dynamic parts of the scaled timestamp encoding section, 4.5.3, it is said RTP
   header. This section indicates a 'Generic CSRC list' field in point
   4 and 5 that the compressor
   dynamic chain, which has a variable length (see section 5.8.6). This
   field is not required to initialize TS_OFFSET always at wraparound, but that it least one octet in size, even if the list is required empty
   (as opposed to increase the number of bits
   sent for CSRC list in 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 uncompressed RTP header, which is therefore RECOMMENDED
   not present when the RTP CC field is set to follow point 4-5 0).

5.2. Multiple occurrences of section 4.5.3, the CC field

   The static and instead the compressor SHOULD reinitialize TS_OFFSET upon TS
   wraparound, by sending unscaled TS. This is equivalent dynamic parts of replacing
   point 4-5 with:

     4.  Offset at wraparound: If the value RTP header are defined in
   Section 5.7.7.6. In the dynamic part, a CC field indicates the number
   of TS_STRIDE CSRC items present in the 'Generic CSRC list'. Another CC field
   also appears within the 'Generic CSRC list' (section 5.8.6.1),
   because Encoding Type 0 is not equal
         to a power always used in the dynamic chain. Both CC
   fields have the same meaning: the value of two, wraparound the CC field determines
   the number of XI items in the unscaled 32-bit TS will
         change CSRC list for Encoding Type 0, and it
   is not used otherwise. Therefore, the following applies:

   FORMAL ADDITION TO RFC 3095:

      "The first octet in the value dynamic part of TS_OFFSET. When this happens, the
         compressor SHOULD reinitialize TS_OFFSET by sending unscaled
         TS, RTP header contains a
       CC field, as defined in section 5.7.7.6. A second occurrence
       appears 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 'Generic CSRC list', which is also in the compressor will
   follow dynamic
       part of the above recommendation, there RTP header, where Encoding Type 0 is a risk used according
       to the format defined in 5.8.6.1.

       The compressor MUST set both occurrences of the CC field to the
       same value.

       The decompressor
   context becoming invalid. Considering MUST use the size if value of the TS number
   space, CC field from the
       Encoding Type 0 within the Generic CRSC list, and it MUST thus
       ignore the number first occurrence of packets between each TS wraparound, the
   potential cost CC field."

5.3. Bit masks in list compression

   The insertion and/or removal schemes, described in sections 5.8.6.2 -
   5.8.6.4, use bit masks to indicates insertion or removal positions
   within the reference list. The size of this is considered negligible.

4.6. Recalculating TS_OFFSET

   TS the bit mask can be sent unscaled 7-bit or
   15-bit.

   The compressor MAY use a 7-bit mask, even if the TS value change does not match reference list has
   more than 7 items, provided that changes to the
   established TS_STRIDE, but list are only applied
   to items within the TS_STRIDE might still stay unchanged.
   To ensure correct decompression first 7 items of subsequent packets, the reference list, leaving
   items with an index not covered by the 7-bit mask unchanged.

   The decompressor MUST therefore always recalculate NOT modify items with an index not covered by
   the RTP TS modulo,
   TS_OFFSET, 7-bit mask, when a packet 7-bit mask is received for a reference list
   that contains more than 7 items.

5.4. Headers compressed with an unscaled TS value list compression

   In section 5.8, it is received.

4.7. TS_STRIDE stated that headers which can be part of
   extension header chains "include" AH, null ESP, minimal encapsulation
   (MINE), GRE, and the Tsc flag in Extension 3

   The Tsc flag in Extension 3 indicates whether TS IPv6 extensions. This list of headers which can be
   compressed is scaled or not. correct, but the word "include" should not be there,
   since only the header types listed can actually be handled. It
   must should
   further be noted that for the Tsc value apply to all TS bits, also if Minimal Encapsulation (MINE) header,
   there
   are is no TS bits explicit discussion of how to compress it, as the header
   is either sent uncompressed or fully compressed away.

5.5. ESP NULL header list compression

   Due to the offset of the fields in the extension itself.

   When trailer part of the ESP
   header, 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 NOT compress packets until decompressor confidence containing more than
   one NULL ESP header, unless the second-outermost header is obtained.

   When Tsc=1, TS MUST be scaled using context(TS_STRIDE) treated as
   a regular ESP header and not
   value(TS_STRIDE), which is incorrectly stated in the legend packets are compressed using profile
   0x0003.

5.6. Translation tables and indexes for
   Extension 3 in section 5.7.5. Instead, if IP extension headers

   Section 5.8.4 describes how list indexes are associated to list items
   and how table lists are built for IP extension headers. The text
   incorrectly states that one index per type is used, since the decompressor receives
   an Extension 3 same
   type can appear several times with TS_STRIDE included while Tsc=1, the decompressor
   would simply ignore/discard value(TS_STRIDE). Since different content in one single
   chain.

   In IP extension header list compression, an unscaled TS index is
   needed together associated with TS_STRIDE to recalculate TS_OFFSET, it is thus
   meaningless to include TS_STRIDE in Extension 3 if Tsc is set to 1.

4.8. Using timer-based compression

   Timer-based compression
   each individual extension header of an extension header chain. When
   there are multiple non-identical occurrences of the RTP timestamp, as described in section
   4.5.4, may same extension
   type (Protocol Number) within a header chain, each MUST be used to reduce given its
   own index.

   In the number case where there are multiple identical occurrences of transmitted timestamp bits
   (bytes) needed when the timestamp
   same extension type, the compressor can not be inferred from associate them to the SN. It
   should thus be noted that timer-based compression has no influence on
   decompression same
   index. When the value of packets where no timestamp bits are sent, an item whose index occurs more than once in that
   case
   the timestamp list is just linearly inferred from updated, the SN (see section
   4.2 compressor MUST send the value for each
   occurrence of this document).

   Whether that index in the list.

   When content of extension headers changes, an implementation can
   choose to either use timer-based compression a different index, or not is controlled by update the
   TIME_STRIDE control field, which existing one.
   Some extensions 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 away also when some fields change,
   as those changes can be conveyed to a value > 0, but the decompressor implicitly (e.g.
   sequence numbers in extension headers that can be done first after inferred from the decompressor has declared its clock
   resolution, which is done by sending a CLOCK feedback option for any
   CID on
   RTP SN) or explicitly (e.g. as part of the channel.

5. List compression issues

5.1. Generic 'IP extension header header(s)'
   field in extension 3).

   When there is more than one IP header, there is more than one list

   Section 5.7.7.4 defines the static of
   extension headers, and dynamic parts a translation table is maintained for each
   list independently of one another.

5.7. Reference list

   A list compressed using encoding type 1 (insertion), type 2 (removal)
   or type 3 (removal/insertion) uses a coding scheme that is based on
   the IPv4
   header.  This section indicates use of a 'Generic extension header list'
   field reference list in the dynamic chain, which has context (identified as ref_id).

   While it could seem a variable length.  The
   detailed description of this field can be found in Section 5.8.6.1.

   The generic extension header fair choice to send a type 1 list starts with an octet that when ref_id
   is always
   present, so its length an empty list, there is one octet, at least.  If the 'GP' bit no gain in
   the first octet doing so with respect to using
   a type 0 list. Sending a type 2 list when ref_id is set an empty list
   would lead to 1 then the length of the a failure, while sending a type 3 list has very little
   meaning. All these alternatives could be seen as possible, based on
   how list compression is two
   octets, specified in RFC 3095.

   If these alternatives were allowed, a decompressor would become
   required to maintain a sliding window of ref_id lists in R-mode, even if
   for the list is empty.

5.2. CSRC list case where no items are sent in RTP dynamic chain

   Section 5.7.7.6 defines the static compressed list, and dynamic parts of the RTP
   header.  This section indicates a 'Generic CSRC list' field in the
   dynamic chain, which has this
   is not a variable length.  This field uses the same desirable requirement. Using list encoding rules as the 'Generic extension header list' in the IPv4
   header, so type 1, type 2,
   and type 3 is therefore only allowed for non-empty reference lists.

   FORMAL ADDITION TO RFC 3095:

      "Regardless of the same rules apply operating mode, for list encoding of type 1,
       type 2, and type 3 lists, ref_id MUST refer to its length.

5.3. RTP dynamic chain a non-empty list."

5.8. Compression of AH and GRE sequence numbers

   Section 5.7.7.6 defines 5.8.4.2 and section 5.8.4.4 describes how to compress the static
   Authentication Header (AH) and dynamic parts of the RTP Generic Routing Encapsulation
   (GRE) header.  In the dynamic part, Both these sections present a 'CC' field indicates possibility to omit the
   AH/GRE sequence 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, header, under certain
   circumstances. However, the values of specific conditions for omitting the fields are equal.

   Proposed behavior if
   AH/GRE sequence number, as well as the values concrete compression and
   decompression procedures to apply, are different:
      Both fields not clearly defined to
   guarantee robustness and facilitate interoperable implementation.

   Proper rules are within the RTP dynamic part but only the second
      'CC' field resides inside the 'Generic CSRC list' together with provided for the XI items.  Since ESP case, i.e.:

      "Sequence Number: Not sent when the 'CC' value determines offset from the sequence
       number of XI
      items in the CSRC list and isn't used otherwise, compressed header is constant, when the first CC
      field SHOULD be ignored, and compressor
       has confidence that the second field (inside decompressor has established the CSRC
      list) MUST be used when decompressing packets.  For outgoing
      packets both fields SHOULD correct
       offset. When the offset is not constant, the sequence number may
       be set compressed by sending LSBs"

   The same logic applies to the same value.

5.4. Compressed lists AH/GRE sequence numbers.

   INCORRECT RFC 3095 TEXT (section 5.8.4.2):

      "If the sequence number 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) AH linearly increases as the RTP
       Sequence Number increases, and every list may have a unique
   identifier (gen_id).  The identifier is present in U/O-mode when the compressor decides is confident 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 has obtained the other hand, pattern, the
   decompressor updates its translation table whenever an (Index, item)
   pair is received (section 5.8.1). sequence number in
       AH need not be sent. The decompressor must be able applies linear
       extrapolation to
   handle such a packet, thus it MUST follow section 5.8.1 and update
   its translation table whenever an (Index, item) pair is received.
   The compressor MUST also increment Counter by 1 (section 5.8.1.2).

5.5. Bit masks reconstruct the sequence number in list compression

   A 7-bit or 15-bit mask may the AH."

   CORRECTED TEXT:

      "The AH sequence number can be used in omitted from 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 MAY be used as long as changes
   are only applied in header
       when the first part offset from the sequence number (SN) of the reference list, and items
   with an index not covered by the 7-bit mask MUST stay unchanged.

5.6. Headers compressed with list compression

   In section 5.8, it
       header is stated constant, when the compressor has confidence that headers which can be part of
   extension
       the decompressor has established the correct offset."
   INCORRECT RFC 3095 TEXT (section 5.8.4.4):

      "If the sequence number in the GRE header chains INCLUDE AH, null ESP, minimal encapsulation
   (MINE), GRE, linearly increases as
       the RTP Sequence Number increases and IPv6 extensions. This list of headers which can be
   compressed the compressor is correct, but confident
       that the word INCLUDE should decompressor has received the pattern, the sequence
       number in GRE need not be there,
   since only sent. The decompressor applies linear
       extrapolation to reconstruct the header types listed sequence number in the GRE
       header."

   CORRECTED TEXT:

      "The GRE sequence number 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 omitted from the header
   is either sent uncompressed or fully compressed away.

5.7. ESP NULL header list compression

   Due to
       when the offset from the sequence number (SN) of the fields compressed
       header is constant, when the compressor has confidence that the
       decompressor has established the correct offset."

6. Updating properties

6.1. Implicit updates

   A context updating packet that contains compressed sequence number
   information may also carry information about other fields; in such
   case, these fields are updated according to the trailer part content of the ESP
   header, a compressor MUST NOT compress packets containing more than
   one NULL ESP header.

5.8. Translation tables and indexes for IP extension headers

   Section 5.8.4 aims at describing how list indexes are associated
   packet. The updating packet also implicitly updates inferred fields
   (e.g. RTP timestamp) according to
   list items the current mode and how table lists are built for IP extension headers.
   However, the text is not very clear,
   appropriate mapping function of the updated and it is actually wrong to just
   say that an index per type is used, since the same type can appear
   several times with different content in one single chain.

   In IP extension inferred fields.

   An updating packet thus updates the reference values of all header list compression, an index is associated
   fields, either explicitly or implicitly, with
   each individual extension header of an extension header chain. When
   there are multiple occurrences of exception for the same extension type (Protocol
   Number) within
   UO-1-ID packet (see section 6.2 of this document). In UO-mode, all
   packets are updating packets, while in R-mode all packets with a header chain, each MUST be given its own index
   (assuming they CRC
   are not identical). When content of extension headers
   changes, an implementation can choose to either initiate updating packets.

   For example, a new index,
   or update UO-0 packet contains the existing one. Note that some extensions can be compressed away RTP sequence
   number (SN). Such a packet also when some fields change, as there are other
   means to explicitly or implicitly convey the changes.

   When there is more than one IP header, there is more than one list updates RTP timestamp,
   IPv4 ID, and sequence numbers of IP extension headers, and a translation table is maintained for each
   list independently headers.

6.2. Updating properties of one another.

5.9. Reference list

   A list compressed using encoding type 1 (insertion), type 2 (removal)
   or type 3 (removal/insertion) uses UO-1*

   Section 5.7.3 states that the values provided in extensions carried
   by a coding scheme UO-1-ID packet do not update the context, except for SN, TS, or
   IP-ID fields. However, section 5.8.1 correctly states that is based on the use of a reference list
   translation table in the context (identified as ref_id).

   It is noted that while it could seem a fair choice to send a type 1
   list when ref_id is updated whenever an empty list, there (Index, item)
   pair is no gain received, something that is contradicted by the statement in doing so
   5.7.3 because the UO-1-ID packet can carry extension 3 with
   respect (Index,
   item) pair items within the 'Compressed CSRC list' field. In addition
   to using a type 0 list. Sending a type 2 list when ref_id is
   an empty list would lead this contradiction, the text does not mention what to do with the
   other sequence numbers inferred from the SN, which are also to a failure, while sending a type 3 list
   has very little meaning. All these alternatives could be seen
   implicitly updated. The updating properties of UO-1* as
   possible, based on how list compression is specified in stated by
   section 5.7.3 are thus incomplete.

   INCOMPLETE RFC 3095.

   If these alternatives were allowed, a decompressor would become
   required to maintain a sliding window of ref_id lists 3095 TEXT (section 5.7.3):

      "Values provided in R-mode, even
   for the case where no items are sent as compressed list. To avoid
   this, extensions, except those in other SN, TS,
       or IP-ID fields, do not update the sending of type 1, 2, context."

   CORRECTED TEXT:

      "UO-1-ID packets only updates TS, SN, IP-ID, and 3 compressed list using sequence
       numbers of IP extension headers. Other values
       provided in extensions do not update the context.

       The decompressor MUST update its translation table whenever an empty
   reference list
       (Index, item) pair is disallowed. Therefore empty lists are not needed received, as per Section 5.8.1, and this
       rule applies also to
   be stored in UO-1-ID packets."

6.3. Context updating properties for IR packets

   IR packets do not clear the sliding window whole context, but update all fields
   carried in the decompressor.

   More specifically, when IR header. Similarly, an IR without a dynamic chain
   simply updates the compressor uses list encoding static part of type 1,
   type 2, and type 3, the ref_id used MUST refer to a non-empty
   reference list, regardless context, while the rest of the operating mode.

6. Updating properties

6.1. Implicit updates

   A
   context updating packet is left unchanged.

   A consequence of this is that contains compressed sequence number
   information may also carry information about other fields; in such
   case, these fields that are not updated according to by the content of IR
   packet, e.g. the
   packet. The updating packet also implicitly updates inferred fields
   (e.g. translation tables for list compression, MUST NOT be
   invalidated by the decompressor when it assumes context damage.

6.4. RTP timestamp) according to padding field (R-P) in extension 3

   Section 5.7.5 defines the current mode properties of RTP header flags and fields
   in extension 3. These get updated when the
   appropriate mapping function rtp flag of the updated and the inferred fields.

   An updating packet thus extension
   3 is set, i.e. when rtp = 1, otherwise they are not updated. However,
   it is unclear how extension 3 updates the reference values of all header
   fields, either explicitly or implicitly, with an exception for R-P bit in the
   UO-1-ID packet, which only updates TS, SN, IP-ID, and sequence
   numbers context.

   INCOMPLETE RFC 3095 TEXT (section 5.7.5):

      "R-P: RTP Padding bit, absolute value (presumed zero if absent)."

   CORRECTED TEXT:

      "R-P: RTP Padding bit. If R-PT = 1, R-P is the absolute value 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 padding bit and this value updates context(R-P). If
            R-PT = 0, context(R-P) is updated to zero."

6.5. RTP timestamp,
   IPv4 ID, and sequence numbers of IP extension headers.

6.2. Updating properties of UO-1*

   In section 5.7.3, eXtension bit (X) in dynamic part

   Section 5.7.7.6 defines 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 RTP header flags and
   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 RTP part of the additional bits for dynamic chain of IR and IR-DYN packets.
   However, it is unclear how the SN, TS, or IP-ID fields. Other values
      provided X bit is updated in extensions do not update the context. Note that
      sequence number fields of extension headers are also updated."

   See also section 5.4

   INCOMPLETE RFC 3095 TEXT (section 5.7.7.6):

      "X: Copy of X bit from RTP header (presumed 0 if RX = 0)"

   CORRECTED TEXT:

      "X: X bit from RTP header. If RX = 1, X is the X bit from the RTP
          header and this document. value updates context(X). If RX = 0,
          context(X) is updated to zero."

7. Context management and CID/context re-use

7.1. The Persistence of 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, the decompressor also agrees to provide memory resources to
   host at least MAX_CID+1 contexts, and an established context with a
   CID within this negotiated space MUST be kept by the 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
   differ significantly from one link scenarios, application to another, as well as
   the load in terms of actual the number of packet streams to compress. Depending
   on link technology, the The
   lifetime of a ROHC channel lifetime will can also vary 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. This
   document does not intends to change that, i.e. ROHC resource
   management is still considered an implementation detail. However, re-using re-
   using a CID and its allocated memory is not always as simple as
   initiating a contexts context 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. This document therefore points out
   some important core aspects to consider when implementing resource
   management in ROHC compressors and decompressors.

   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 mode
   transitions are performed using a decompressor-initiated handshake
   procedure, as defined in section 5.6. 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 SHOULD be inherited from the old to the new
   context. Specifically, the compressor SHOULD continue to operate
   using the mode of operation of the old context also with 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 expected to flush clear the
   context memory for the CID, CID (see section 6.3 of this document), and
   there is no way to trigger a safe mode switching, which switching (which requires a decompressor-
   initiated handshake procedure, as defined in section 5.6.

   It should be noted that the
   decompressor-initiated handshake procedure).

   The rule of mode inheritance applies also when the
   CONTEXT_REINITIALIZATION signal (section 6.3.1) 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, both the compressor and the decompressor MUST
   start 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 profile
   0x0001 -> profile 0x0002 downgrade in [1]section [1], section 5.11.1).

   Type 0 and type 1 packets have different formats in U/O- and R-mode,
   and these R-mode packets have no CRC. When initiating a new context
   on a re-used R-mode CID, there is a risk that the decompressor will
   misinterpret compressed packets, if the initiating IR packets are
   lost.

   A CID for an R-mode operating a context currently operating in R-mode SHOULD NOT therefore
   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 context. A compressor must be very
   careful to doing otherwise should minimize the
   risk for misinterpretation risk, e.g. of R-0/R-1 by e.g. 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.

   A consequence of this or 10 before it is highly confident that fields that cannot be updated by the IR
   packet, e.g. the Translation Tables for list compression, MUST NOT be
   invalidated by the decompressor when it assumes
   new context damage. has successfully been initiated at the decompressor.

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

   If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent
   as 16-bit original uncompressed 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,

   When RND=RND2=0, IP-ID is always compressed, i.e. expressed as an SN offset
   and byte-swapped if NBO=0. This is the case
   even also 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
   NOT 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). See also section 5.4 of this document.

   Besides, usage of Extension-3 in UO-1-ID can be useful to compress a
   transient change IP-
   ID is sent in a packet stream.  For example, if a field's value
   changes extension 3.

   When RND=0 but no IP-ID bits are sent in the current packet but 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 next packet same meaning) in Section 5.7,
   where it returns to is said that "default-slope(IP-ID offset) = 0", meaning that
   if no bits are sent for IP-ID, its regular behavior, e.g. changes in TTL.

8.4. SN offset slope defaults to 0.

8.3. 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 may
   change the interpretation of fields in UOR-2* packets. In these such cases,
   when a flag changes in Extension-3, a decompressor SHOULD MUST re-parse the
   UOR-2* packet.

8.4. Multiple occurrences of the M bit

   The RTP header part of Extension 3, as defined by section 5.7.5,
   includes a one-bit field for the RTP Marker bit. This field is also
   present in all compressed base header formats except for UO-1-ID,
   meaning there may be multiple occurrences of the field within one
   single compressed header. In such cases, the two M fields must have
   the same value.

   FORMAL ADDITION TO RFC 3095:

      "When there are two occurrences of the M field in a compressed
       header (both in the compressed base header and in the RTP part of
       Extension 3), the compressor MUST set both these occurrences of
       the M field to the same value.

       At the decompressor, if the two M field values of such a packet
       are not identical, the packet MUST be discarded."

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 The format of the SN feedback option (5.7.6.6) allows for 8
   additional SN bits to the 12 SN bits of the FEEDBACK-2 format
   (5.7.6.1). One single SN feedback option is thus not enough for the
   decompressor can't to send back all the 32 bits of the ESP sequence number
   in a feedback packet packet, unless it uses multiple SN options in one
   feedback packet.  Section 5.7.6.1 declares that a FEEDABCK-2 packet
   can contain variable number of feedback options and the options can
   appear in any order.

   A compressor MUST be able to process

   When processing multiple SN options in one feedback packet, and the SN
   would be given by concatenating the fields.

8.6. Multiple CRC options in one feedback packet

   Although it is never required not useful 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 MUST 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 original transition procedures in sections 5.6.5 and 5.6.6 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 be mistakenly
   interpreted as the packets sent by header, 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, SHOULD otherwise discard the D_TRANS parameter can serve this purpose since
   its definition and usage is slightly modified.

8.8. How to respond feedback packet.

8.7. Responding to lost feedback links?

   Althought links

   Although this is neither desirable or expected, it may happen that a
   link used to carry feedback between two associated instances become becomes
   unavailable. If the compressor can be notified of such event, the
   most suitable response in such case is for such event, the
   compressor to SHOULD restart compression for each flow going over the ROHC channel, except for
   flows that are is operating
   in U/O-mode or flows using a CID associated
   with the uncompressed profile (profile 0x0000). R-mode. When restarting compression, the compressor SHOULD use a
   different CID for each flow being restarted; this is useful to avoid
   that packet types for which both U/O-mode and R-mode share the same
   type identifier gets misinterpreted when restarting the flow in U-mode. U-
   mode (see also section 7.2 of this document).

   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.

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.

8.8. UOR-2 in profile 2 0x0002 (UDP) and profile 3 0x0003 (ESP)

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

8.11. This also applies to the IP profile [4] and the IP/UDP-
   Lite profile [5].

8.9. 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 These sequence numbers
   are not "LSB-encoded" as e.g. the RTP sequence number with an interpretation interval, number, but are actually
   just the
   LSB's of the uncompressed fields.

8.12.

8.10. Expecting UOR-2 ACKs in O-mode

   It should be noted that the use

   Usage of UOR-2 ACKs in O-mode, as discussed in section 5.4.1.1.2, is indeed optional, and a
   optional. A decompressor can also send ACKs for other purposes other than actually acking
   to acknowledge the UOR-2, without then having to continue sending them ACKs for
   all UOR-2. Similarly, a compressor
   implementations implementation 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

   It is thus RECOMMENDED 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

   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 compression
   performance. This is because UOR-2 ACKs can be sent from a
   decompressor for other purposes than to actually acknowledge the 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
   transition. If an implementation does use of UOR-2 ACKs, the implementer must ensure all aspects
   are considered by the confidence algorithm.

8.13. Compression of SN optional acknowledgment
   algorithm described 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 Section 5.4.1.1.2, it must make sure to include or
   exclude set
   the AH k_3 and GRE sequence numbers is the same as for ESP, i.e.
   the following rule from section 5.8.4.3 applies n_3 parameters to all these sequence
   numbers:

    "Sequence Number: Not sent when the offset from the sequence number
                      of the compressed header is constant. When much larger values than one to ensure
   that the
                      offset compressor performance is not constant, degraded due to the sequence number is
                      compressed by sending LSBs. See 5.8.4." problem
   described above.

9. ROHC negotiation clarifications

   According to section 4.1,

   Section 4.1 states that 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 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

   The negotiation protocol must thus 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 a 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 ensure the
   same profile set is negotiated for both IPv4 and IPv6 (IPCP/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], [4], 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

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

12. Security considerations

   This document provides a number of corrections and clarifications to
   [1], but it does not make any changes or additions with regards to the security
   aspects of 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, Zhigang Liu, Abigail Surtees, Mark West, Tommy
   Lundemo, Alan Kennington and Remi Pelland for their contributions and
   comments. Thanks also to the committed document reviewers, Carl
   Knutsson and Biplab Sarkar, who reviewed the document during working
   group last-call.

15. References

15.1. Normative References

   [1]  C. Bormann, et al., "RObust Header Compression (ROHC) (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]  W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994.

   [4]  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.

   [6]  S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

15.2. Informative References

   [7]  L-E. Jonsson, G. Pelletier & K. Sandlund, "RObust Header
        Compression (ROHC): A Link-Layer Assisted Profile for
        IP/UDP/RTP", RFC 4362, June 2004.

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

   Ghyslain Pelletier
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden
   Phone: +46 8 404 29 43
   EMail: ghyslain.pelletier@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

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 four types of CRC in use in RFC 3095,
   # the specification for robust header compression standard. compression. 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;
   }

   #---------------------------------
   #
   # 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);

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 (2006). 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 August 1, November 22, 2006.