tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5225

 Errata 
Proposed STD
Pages: 124
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ROHC

RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite

Part 1 of 4, p. 1 to 19
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                       G. Pelletier
Request for Comments: 5225                                   K. Sandlund
Category: Standards Track                                       Ericsson
                                                              April 2008


             RObust Header Compression Version 2 (ROHCv2):
              Profiles for RTP, UDP, IP, ESP and UDP-Lite

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document specifies ROHC (Robust Header Compression) profiles
   that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol,
   User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User
   Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP
   (Encapsulating Security Payload) headers.

   This specification defines a second version of the profiles found in
   RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but
   does not obsolete them.

   The ROHCv2 profiles introduce a number of simplifications to the
   rules and algorithms that govern the behavior of the compression
   endpoints.  It also defines robustness mechanisms that may be used by
   a compressor implementation to increase the probability of
   decompression success when packets can be lost and/or reordered on
   the ROHC channel.  Finally, the ROHCv2 profiles define their own
   specific set of header formats, using the ROHC formal notation.

Top       Page 2 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Background (Informative)  . . . . . . . . . . . . . . . . . .   7
     4.1.  Classification of Header Fields . . . . . . . . . . . . .   7
     4.2.  Improvements of ROHCv2 over RFC 3095 Profiles . . . . . .   8
     4.3.  Operational Characteristics of ROHCv2 Profiles  . . . . .  10
   5.  Overview of the ROHCv2 Profiles (Informative) . . . . . . . .  10
     5.1.  Compressor Concepts . . . . . . . . . . . . . . . . . . .  11
       5.1.1.  Optimistic Approach . . . . . . . . . . . . . . . . .  11
       5.1.2.  Tradeoff between Robustness to Losses and to
               Reordering  . . . . . . . . . . . . . . . . . . . . .  11
       5.1.3.  Interactions with the Decompressor Context  . . . . .  13
     5.2.  Decompressor Concepts . . . . . . . . . . . . . . . . . .  14
       5.2.1.  Decompressor State Machine  . . . . . . . . . . . . .  14
       5.2.2.  Decompressor Context Management . . . . . . . . . . .  17
       5.2.3.  Feedback Logic  . . . . . . . . . . . . . . . . . . .  19
   6.  ROHCv2 Profiles (Normative) . . . . . . . . . . . . . . . . .  19
     6.1.  Channel Parameters, Segmentation, and Reordering  . . . .  19
     6.2.  Profile Operation, Per-context  . . . . . . . . . . . . .  20
     6.3.  Control Fields  . . . . . . . . . . . . . . . . . . . . .  21
       6.3.1.  Master Sequence Number (MSN)  . . . . . . . . . . . .  21
       6.3.2.  Reordering Ratio  . . . . . . . . . . . . . . . . . .  21
       6.3.3.  IP-ID Behavior  . . . . . . . . . . . . . . . . . . .  22
       6.3.4.  UDP-Lite Coverage Behavior  . . . . . . . . . . . . .  22
       6.3.5.  Timestamp Stride  . . . . . . . . . . . . . . . . . .  22
       6.3.6.  Time Stride . . . . . . . . . . . . . . . . . . . . .  22
       6.3.7.  CRC-3 for Control Fields  . . . . . . . . . . . . . .  23
     6.4.  Reconstruction and Verification . . . . . . . . . . . . .  23
     6.5.  Compressed Header Chains  . . . . . . . . . . . . . . . .  24
     6.6.  Header Formats and Encoding Methods . . . . . . . . . . .  25
       6.6.1.  baseheader_extension_headers  . . . . . . . . . . . .  26
       6.6.2.  baseheader_outer_headers  . . . . . . . . . . . . . .  26
       6.6.3.  inferred_udp_length . . . . . . . . . . . . . . . . .  26
       6.6.4.  inferred_ip_v4_header_checksum  . . . . . . . . . . .  26
       6.6.5.  inferred_mine_header_checksum . . . . . . . . . . . .  27
       6.6.6.  inferred_ip_v4_length . . . . . . . . . . . . . . . .  28
       6.6.7.  inferred_ip_v6_length . . . . . . . . . . . . . . . .  28
       6.6.8.  Scaled RTP Timestamp Compression  . . . . . . . . . .  29
       6.6.9.  timer_based_lsb . . . . . . . . . . . . . . . . . . .  30
       6.6.10. inferred_scaled_field . . . . . . . . . . . . . . . .  31
       6.6.11. control_crc3_encoding . . . . . . . . . . . . . . . .  32
       6.6.12. inferred_sequential_ip_id . . . . . . . . . . . . . .  33
       6.6.13. list_csrc(cc_value) . . . . . . . . . . . . . . . . .  34
     6.7.  Encoding Methods with External Parameters as Arguments  .  38
     6.8.  Header Formats  . . . . . . . . . . . . . . . . . . . . .  40

Top      ToC       Page 3 
       6.8.1.  Initialization and Refresh Header Format (IR) . . . .  40
       6.8.2.  Compressed Header Formats (CO)  . . . . . . . . . . .  41
     6.9.  Feedback Formats and Options  . . . . . . . . . . . . . . 100
       6.9.1.  Feedback Formats  . . . . . . . . . . . . . . . . . . 100
       6.9.2.  Feedback Options  . . . . . . . . . . . . . . . . . . 102
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . 104
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 105
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . 106
     10.1. Normative References  . . . . . . . . . . . . . . . . . . 106
     10.2. Informative References  . . . . . . . . . . . . . . . . . 107
   Appendix A.    Detailed Classification of Header Fields . . . . . 108
     A.1.  IPv4 Header Fields  . . . . . . . . . . . . . . . . . . . 109
     A.2.  IPv6 Header Fields  . . . . . . . . . . . . . . . . . . . 112
     A.3.  UDP Header Fields   . . . . . . . . . . . . . . . . . . . 113
     A.4.  UDP-Lite Header Fields  . . . . . . . . . . . . . . . . . 114
     A.5.  RTP Header Fields . . . . . . . . . . . . . . . . . . . . 115
     A.6.  ESP Header Fields . . . . . . . . . . . . . . . . . . . . 117
     A.7.  IPv6 Extension Header Fields  . . . . . . . . . . . . . . 117
     A.8.  GRE Header Fields . . . . . . . . . . . . . . . . . . . . 118
     A.9.  MINE Header Fields  . . . . . . . . . . . . . . . . . . . 119
     A.10. AH Header Fields  . . . . . . . . . . . . . . . . . . . . 120
   Appendix B.    Compressor Implementation Guidelines . . . . . . . 121
     B.1.  Reference Management  . . . . . . . . . . . . . . . . . . 121
     B.2.  Window-based LSB Encoding (W-LSB)  . . .  . . . . . . . . 121
     B.3.  W-LSB Encoding and Timer-based Compression  . . . . . . . 122

Top      ToC       Page 4 
1.  Introduction

   The ROHC WG has developed a header compression framework on top of
   which various profiles can be defined for different protocol sets or
   compression requirements.  The ROHC framework was first documented in
   [RFC3095], together with profiles for compression of RTP/UDP/IP
   (Real-Time Transport Protocol, User Datagram Protocol, Internet
   Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload)
   headers.  Additional profiles for compression of IP headers [RFC3843]
   and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were
   later specified to complete the initial set of ROHC profiles.

   This document defines an updated version for each of the above
   mentioned profiles, and the definitions depend on the ROHC framework
   as found in [RFC4995].  The framework is required reading to
   understand the profile definitions, rules, and their role.

   Specifically, this document defines header compression schemes for:

   o RTP/UDP/IP      : profile 0x0101
   o UDP/IP          : profile 0x0102
   o ESP/IP          : profile 0x0103
   o IP              : profile 0x0104
   o RTP/UDP-Lite/IP : profile 0x0107
   o UDP-Lite/IP     : profile 0x0108

   Each of the profiles above can compress the following type of
   extension headers:

   o  AH [RFC4302]

   o  GRE [RFC2784][RFC2890]

   o  MINE [RFC2004]

   o  IPv6 Destination Options header[RFC2460]

   o  IPv6 Hop-by-hop Options header[RFC2460]

   o  IPv6 Routing header [RFC2460]

2.  Terminology

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

Top      ToC       Page 5 
   This document is consistent with the terminology found in the ROHC
   framework [RFC4995] and in the formal notation for ROHC [RFC4997].
   In addition, this document uses or defines the following terms:

   Acknowledgment Number

      The Acknowledgment Number identifies what packet is being
      acknowledged in the RoHCv2 feedback element (See Section 6.9).
      The value of this field normally corresponds to the Master
      Sequence Number (MSN) of the header that was last successfully
      decompressed, for the compression context (CID) for which the
      feedback information applies.

   Chaining of Items

      A chain of items groups fields based on similar characteristics.
      ROHCv2 defines chain items for static, dynamic and irregular
      fields.  Chaining is achieved by appending an item to the chain
      for each header in its order of appearance in the uncompressed
      packet.  Chaining is useful to construct compressed headers from
      an arbitrary number of any of the protocol headers for which a
      ROHCv2 profile defines a compressed format.

   CRC-3 Control Fields Validation

      The CRC-3 control fields validation refers to the validation of
      the control fields.  This validation is performed by the
      decompressor when it receives a Compressed (CO) header that
      contains a 3-bit Cyclic Redundancy Check (CRC) calculated over
      control fields.  This 3-bit CRC covers controls fields carried in
      the CO header as well as specific control fields in the context.
      In the formal definition of the header formats, this 3-bit CRC is
      labeled "control_crc3" and uses the control_crc3_encoding (See
      also Section 6.6.11).

   Delta

      The delta refers to the difference in the absolute value of a
      field between two consecutive packets being processed by the same
      compression endpoint.

   Reordering Depth

      The number of packets by which a packet is received late within
      its sequence due to reordering between the compressor and the
      decompressor, i.e., reordering between packets associated with the
      same context (CID).  See the definition of sequentially late
      packet below.

Top      ToC       Page 6 
   ROHCv2 Header Types

      ROHCv2 profiles use two different header types: the Initialization
      and Refresh (IR) header type, and the Compressed (CO) header type.

   Sequentially Early Packet

      A packet that reaches the decompressor before one or several
      packets that were delayed over the channel, where all of the said
      packets belong to the same header-compressed flow and are
      associated to the same compression context (CID).  At the time of
      the arrival of a sequentially early packet, the packet(s) delayed
      on the link cannot be differentiated from lost packet(s).

   Sequentially Late Packet

      A packet is late within its sequence if it reaches the
      decompressor after one or several other packets belonging to the
      same CID have been received, although the sequentially late packet
      was sent from the compressor before the other packet(s).  How the
      decompressor detects a sequentially late packet is outside the
      scope of this specification, but it can for example use the MSN
      for this purpose.

   Timestamp Stride (ts_stride)

      The timestamp stride (ts_stride) is the expected increase in the
      timestamp value between two RTP packets with consecutive sequence
      numbers.  For example, for a media encoding with a sample rate of
      8 kHz producing one frame every 20 ms, the RTP timestamp will
      typically increase by n * 160 (= 8000 * 0.02), for some integer n.

   Time Stride (time_stride)

      The time stride (time_stride) is the time interval equivalent to
      one ts_stride, e.g., 20 ms in the example for the RTP timestamp
      increment above.

Top      ToC       Page 7 
3.  Acronyms

   This section lists most acronyms used for reference, in addition to
   those defined in [RFC4995].

   AH       Authentication Header.
   ESP      Encapsulating Security Payload.
   GRE      Generic Routing Encapsulation.
   FC       Full Context state (decompressor).
   IP       Internet Protocol.
   LSB      Least Significant Bits.
   MINE     Minimal Encapsulation in IP.
   MSB      Most Significant Bits.
   MSN      Master Sequence Number.
   NC       No Context state (decompressor).
   OA       Optimistic Approach.
   RC       Repair Context state (decompressor).
   ROHC     Header compression framework (RFC 4995).
   ROHCv2   Set of header compression profiles defined in this document.
   RTP      Real-time Transport Protocol.
   SSRC     Synchronization source. Field in RTP header.
   CSRC     Contributing source.  The RTP header contains an optional
            list of contributing sources.
   TC       Traffic Class.  Field in the IPv6 header.  See also TOS.
   TOS      Type Of Service.  Field in the IPv4 header.  See also TC.
   TS       RTP Timestamp.
   TTL      Time to Live.  Field in the IPv4 header.
   UDP      User Datagram Protocol.
   UDP-Lite User Datagram Protocol Lite.

4.  Background (Informative)

   This section provides background information on the compression
   profiles defined in this document.  The fundamentals of general
   header compression and of the ROHC framework may be found in sections
   3 and 4 of [RFC4995], respectively.  The fundamentals of the formal
   notation for ROHC are defined in [RFC4997].  [RFC4224] describes the
   impacts of out-of-order delivery on profiles based on [RFC3095].

4.1.  Classification of Header Fields

   Section 3.1 of [RFC4995] explains that header compression is possible
   due to the fact that there is much redundancy between field values
   within the headers of a packet, especially between the headers of
   consecutive packets.

   Appendix A lists and classifies in detail all the header fields
   relevant to this document.  The appendix concludes with

Top      ToC       Page 8 
   recommendations on how the various fields should be handled by header
   compression algorithms.

   The main conclusion is that most of the header fields can easily be
   compressed away since they never or seldom change.  A small number of
   fields however need more sophisticated mechanisms.

   These fields are:

   - IPv4 Identification        (16 bits) - IP-ID
   - ESP Sequence Number        (32 bits) - ESP SN
   - UDP Checksum               (16 bits) - Checksum
   - UDP-Lite Checksum          (16 bits) - Checksum
   - UDP-Lite Checksum Coverage (16 bits) - CCov
   - RTP Marker                 ( 1 bit ) - M-bit
   - RTP Sequence Number        (16 bits) - RTP SN
   - RTP Timestamp              (32 bits) - TS

   In particular, for RTP, the analysis in Appendix A reveals that the
   values of the RTP Timestamp (TS) field usually have a strong
   correlation to the RTP Sequence Number (SN), which increments by one
   for each packet emitted by an RTP source.  The RTP M-bit is expected
   to have the same value most of the time, but it needs to be
   communicated explicitly on occasion.

   For UDP, the Checksum field cannot be inferred or recalculated at the
   receiving end without violating its end-to-end properties, and is
   thus sent as-is when enabled (mandatory with IPv6).  The same applies
   to the UDP-Lite Checksum (mandatory with both IPv4 and IPv6), while
   the UDP-Lite Checksum Coverage may in some cases be compressible.

   For IPv4, a similar correlation as that of the RTP TS to the RTP SN
   is often observed between the Identifier field (IP-ID) and the master
   sequence number (MSN) used for compression (e.g., the RTP SN when
   compressing RTP headers).

4.2.  Improvements of ROHCv2 over RFC 3095 Profiles

   The ROHCv2 profiles can achieve compression efficiency and robustness
   that are both at least equivalent to RFC 3095 profiles [RFC3095],
   when used under the same operating conditions.  In particular, the
   size and bit layout of the smallest compressed header (i.e., PT-0
   format U/O-0 in RFC 3095, and pt_0_crc3 in ROHCv2) are identical.

   There are a number of differences and improvements between profiles
   defined in this document and their earlier version defined in RFC
   3095.  This section provides an overview of some of the most
   significant improvements:

Top      ToC       Page 9 
   Tolerance to reordering

      Profiles defined in RFC 3095 require that the channel between
      compressor and decompressor provide in-order delivery between
      compression endpoints.  ROHCv2 profiles, however, can handle
      robustly and efficiently a limited amount of reordering after the
      compression point as part of the compression algorithm itself.  In
      addition, this improved support for reordering makes it possible
      for ROHCv2 profiles to handle prelink reordering more efficiently.

   Operational logic

      Profiles in RFC 3095 define multiple operational modes, each with
      different updating logic and compressed header formats.  ROHCv2
      profiles operate in unidirectional operation until feedback is
      first received for a context (CID), at which point bidirectional
      operation is used; the formats are independent of what operational
      logic is used.

   IP extension header

      Profiles in RFC 3095 compress IP Extension headers using list
      compression.  ROHCv2 profiles instead treat extension headers in
      the same manner as other protocol headers, i.e., using the
      chaining mechanism; it thus assumes that extension headers are not
      added or removed during the lifetime of a context (CID), otherwise
      compression has to be restarted for this flow.

   IP encapsulation

      Profiles in RFC 3095 can compress at most two levels of IP
      headers.  ROHCv2 profiles can compress an arbitrary number of IP
      headers.

   List compression

      ROHCv2 profiles do not support reference-based list compression.

   Robustness and repairs

      ROHCv2 profiles do not define a format for the IR-DYN packet;
      instead, each profile defines a compressed header that can be used
      to perform a more robust context repair using a 7-bit CRC
      verification.  This also implies that only the IR header can
      change the association between a CID and the profile it uses.

Top      ToC       Page 10 
   Feedback

      ROHCv2 profiles mandate a CRC in the format of the FEEDBACK-2,
      while this is optional in RFC 3095.  A different set of feedback
      options is also used in ROHCv2 compared to RFC 3095.

4.3.  Operational Characteristics of ROHCv2 Profiles

   Robust header compression can be used over different link
   technologies.  Section 4.4 of [RFC4995] lists the operational
   characteristics of the ROHC channel.  The ROHCv2 profiles address a
   wide range of applications, and this section summarizes some of the
   operational characteristics that are specific to these profiles.

   Packet length

      ROHCv2 profiles assume that the lower layer indicates the length
      of a compressed packet.  ROHCv2 compressed headers do not contain
      length information for the payload.

   Out-of-order delivery between compression endpoints

      The definition of the ROHCv2 profiles places no strict requirement
      on the delivery sequence between the compression endpoints, i.e.,
      packets may be received in a different order than the compressor
      has sent them and still have a fair probability of being
      successfully decompressed.

      However, frequent out-of-order delivery and/or significant
      reordering depth will negatively impact the compression
      efficiency.  More specifically, if the compressor can operate
      using a proper estimate of the reordering characteristics of the
      path between the compression endpoints, larger headers can be sent
      more often to increase the robustness against decompression
      failures due to out-of-order delivery.  Otherwise, the compression
      efficiency will be impaired from an increase in the frequency of
      decompression failures and recovery attempts.

5.  Overview of the ROHCv2 Profiles (Informative)

   This section provides an overview of concepts that are important and
   useful to the ROHCv2 profiles.  These concepts may be used as
   guidelines for implementations but they are not part of the normative
   definition of the profiles, as these concepts relate to the
   compression efficiency of the protocol without impacting the
   interoperability characteristics of an implementation.

Top      ToC       Page 11 
5.1.  Compressor Concepts

   Header compression can be conceptually characterized as the
   interaction of a compressor with a decompressor state machine, one
   per context.  The responsibility of the compressor is to convey the
   information needed to successfully decompress a packet, based on a
   certain confidence regarding the state of the decompressor context.

   This confidence is obtained from the frequency and the type of
   information the compressor sends when updating the decompressor
   context from the optimistic approach (Section 5.1.1), and optionally
   from feedback messages (See Section 6.9), received from the
   decompressor.

5.1.1.  Optimistic Approach

   A compressor always uses the optimistic approach when it performs
   context updates.  The compressor normally repeats the same type of
   update until it is fairly confident that the decompressor has
   successfully received the information.  If the decompressor
   successfully receives any of the headers containing this update, the
   state will be available for the decompressor to process smaller
   compressed headers.

   If field X in the uncompressed header changes value, the compressor
   uses a header type that contains an encoding of field X until it has
   gained confidence that the decompressor has received at least one
   packet containing the new value for X.  The compressor normally
   selects a compressed format with the smallest header that can convey
   the changes needed to achieve confidence.

   The number of repetitions that is needed to obtain this confidence is
   normally related to the packet loss and out-of-order delivery
   characteristics of the link where header compression is used; it is
   thus not defined in this document.  It is outside the scope of this
   specification and is left to implementors to decide.

5.1.2.  Tradeoff between Robustness to Losses and to Reordering

   The ability of a header compression algorithm to handle sequentially
   late packets is mainly limited by two factors: the interpretation
   interval offset of the sliding window used for lsb encoded fields
   [RFC4997], and the optimistic approach (See Section 5.1.1) for seldom
   changing fields.

Top      ToC       Page 12 
   lsb encoded fields:

      The interpretation interval offset specifies an upper limit for
      the maximum reordering depth, by which is it possible for the
      decompressor to recover the original value of a dynamically
      changing (i.e., sequentially incrementing) field that is encoded
      using a window-based lsb encoding.  Its value is typically bound
      to the number of lsb compressed bits in the compressed header
      format, and thus grows with the number of bits transmitted.
      However, the offset and the lsb encoding only provide robustness
      for the field that it compresses, and (implicitly) for other
      sequentially changing fields that are derived from that field.

      This is shown in the figure below:

         <--- interpretation interval (size is 2^k) ---->
         |------------------+---------------------------|
      v_ref-p             v_ref              v_ref + (2^k-1) - p
       Lower                                          Upper
       Bound                                          Bound
         <--- reordering --> <--------- losses --------->

         where p is the maximum negative delta, corresponding to the
         maximum reordering depth for which the lsb encoding can recover
         the original value of the field;

         where (2^k-1) - p is the maximum positive delta, corresponding
         to the maximum number of consecutive losses for which the lsb
         encoding can recover the original value of the field;

         where v_ref is the reference value, as defined in the lsb
         encoding method in [RFC4997].

      There is thus a tradeoff between the robustness against reordering
      and the robustness against packet losses, with respect to the
      number of MSN bits needed and the distribution of the
      interpretation interval between negative and positive deltas in
      the MSN.

   Seldom changing fields

      The optimistic approach (Section 5.1.1) provides the upper limit
      for the maximum reordering depth for seldom changing fields.

   There is thus a tradeoff between compression efficiency and
   robustness.  When only information on the MSN needs to be conveyed to
   the decompressor, the tradeoff relates to the number of compressed

Top      ToC       Page 13 
   MSN bits in the compressed header format.  Otherwise, the tradeoff
   relates to the implementation of the optimistic approach.

   In particular, compressor implementations should adjust their
   optimistic approach strategy to match both packet loss and reordering
   characteristics of the link over which header compression is applied.
   For example, the number of repetitions for each update of a non-lsb
   encoded field can be increased.  The compressor can ensure that each
   update is repeated until it is reasonably confident that at least one
   packet containing the change has reached the decompressor before the
   first packet sent after this sequence.

5.1.3.  Interactions with the Decompressor Context

   The compressor normally starts compression with the initial
   assumption that the decompressor has no useful information to process
   the new flow, and sends Initialization and Refresh (IR) packets.

   Initially, when sending the first IR packet for a compressed flow,
   the compressor does not expect to receive feedback for that flow,
   until such feedback is first received.  At this point, the compressor
   may then assume that the decompressor will continue to send feedback
   in order to repair its context when necessary.  The former is
   referred to as unidirectional operation, while the latter is called
   bidirectional operation.

   The compressor can then adjust the compression level (i.e., what
   header format it selects) based on its confidence that the
   decompressor has the necessary information to successfully process
   the compressed headers that it selects.

   In other words, the responsibilities of the compressor are to ensure
   that the decompressor operates with state information that is
   sufficient to successfully decompress the type of compressed
   header(s) it receives, and to allow the decompressor to successfully
   recover that state information as soon as possible otherwise.  The
   compressor therefore selects the type of compressed header based on
   the following factors:

   o  the outcome of the encoding method applied to each field;

   o  the optimistic approach, with respect to the characteristics of
      the channel;

   o  the type of operation (unidirectional or bidirectional), and if in
      bidirectional operation, feedback received from the decompressor
      (ACKs, NACKs, STATIC-NACK, and options).

Top      ToC       Page 14 
   Encoding methods normally use previous value(s) from a history of
   packets whose headers it has previously compressed.  The optimistic
   approach is meant to ensure that at least one compressed header
   containing the information to update the state for a field is
   received.  Finally, feedback indicates what actions the decompressor
   has taken with respect to its assumptions regarding the validity of
   its context (Section 5.2.2); it indicates what type of compressed
   header the decompressor can or cannot decompress.

   The decompressor has the means to detect decompression failures for
   any compressed (CO) header format, using the CRC verification.
   Depending on the frequency and/or on the type of the failure, it
   might send a negative acknowledgement (NACK) or an explicit request
   for a complete context update (STATIC-NACK).  However, the
   decompressor does not have the means to identify the cause of the
   failure, and in particular the decompression of what field(s) is
   responsible for the failure.  The compressor is thus always
   responsible for determining the most suitable response to a negative
   acknowledgement, using the confidence it has in the state of the
   decompressor context, when selecting the type of compressed header it
   will use when compressing a header.

5.2.  Decompressor Concepts

   The decompressor normally uses the last received and successfully
   validated (IR packets) or verified (CO packets) header as the
   reference for future decompression.

   The decompressor is responsible for verifying the outcome of every
   decompression attempt, to update its context when successful, and
   finally to request context repairs by making coherent usage of
   feedback once it has started using feedback.

   Specifically, the outcome of every decompression attempt is verified
   using the CRC present in the compressed header; the decompressor
   updates the context information when this outcome is successfully
   verified; finally, if the decompressor uses feedback once for a
   compressed flow, then it will continue to do so for as long as the
   corresponding context is associated with the same profile.

5.2.1.  Decompressor State Machine

   The decompressor operation may be represented as a state machine
   defining three states: No Context (NC), Repair Context (RC), and Full
   Context (FC).

   The decompressor starts without a valid context, the NC state.  Upon
   receiving an IR packet, the decompressor validates the integrity of

Top      ToC       Page 15 
   its header using the CRC-8 validation.  If the IR header is
   successfully validated, the decompressor updates the context and uses
   this header as the reference header, and moves to the FC state.  Once
   the decompressor state machine has entered the FC state, it does not
   normally leave; only repeated decompression failures will force the
   decompressor to transit downwards to a lower state.  When context
   damage is detected, the decompressor moves to the repair context (RC)
   state, where it stays until it successfully verifies a decompression
   attempt for a compressed header with a 7-bit CRC or until it
   successfully validates an IR header.  When static context damage is
   detected, the decompressor moves back to the NC state.

   Below is the state machine for the decompressor.  Details of the
   transitions between states and decompression logic are given in the
   sub-sections following the figure.

  CRC-8(IR) Validation
   +----->----->----->----->----->----->----->----->----->----->----+
   |                                                  CRC-8(IR)     |
   |  !CRC-8(IR) or      CRC-7(CO) or                 or CRC-7(CO)  |
   |  PT not allowed     CRC-8(IR)                    or CRC-3(CO)  |
   |  +--->---+         +--->----->----->----->---+  +--->---->---+ |
   |  |       |         |                         |  |            | |
   |  |       v         |                         v  |            v v
  +-----------------+  +----------------------+  +--------------------+
  | No Context (NC) |  | Repair Context (RC)  |  | Full Context (FC)  |
  +-----------------+  +----------------------+  +--------------------+
    ^ ^ Static Context  | ^ !CRC-7(CO) or  | ^ Context Damage  | |
    | | Damage Detected | | PT not allowed | | Detected        | |
    | +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+ |
    |                                                            |
    |            Static Context Damage Detected                  |
    +--<-----<-----<-----<-----<-----<-----<-----<-----<---------+

  where:

    CRC-8(IR)        : Successful CRC-8 validation for the IR header.
    !CRC-8(IR)       : Unsuccessful CRC-8 validation for the IR header.
    CRC-7(CO) and/or
    CRC-3(CO)        : Successful CRC verification for the decompression
                       of a CO header, based on the number of CRC bits
                       carried in the CO header.
    !CRC-7(CO)       : Failure to CRC verify the decompression of a CO
                       header carrying a 7-bit CRC.
    PT not allowed   : The decompressor has received a packet type (PT)
                       for which the decompressor's current context does
                       not provide enough valid state information to
                       decompress the packet.

Top      ToC       Page 16 
      Static Context Damage Detected: See definition in Section 5.2.2.

      Context Damage Detected: See definition in Section 5.2.2.

5.2.1.1.  No Context (NC) State

   Initially, while working in the No Context (NC) state, the
   decompressor has not yet successfully validated an IR header.

   Attempting decompression:

      In the NC state, only packets carrying sufficient information on
      the static fields (i.e., IR packets) can be decompressed.

   Upward transition:

      The decompressor can move to the Full Context (FC) state when the
      CRC validation of an 8-bit CRC in an IR header is successful.

   Feedback logic:

      In the NC state, the decompressor should send a STATIC-NACK if a
      packet of a type other than IR is received, or if an IR header has
      failed the CRC-8 validation, subject to the feedback rate
      limitation as described in Section 5.2.3.

5.2.1.2.  Repair Context (RC) State

   In the Repair Context (RC) state, the decompressor has successfully
   decompressed packets for this context, but does not have confidence
   that the entire context is valid.

   Attempting decompression:

      In the RC state, only headers covered by an 8-bit CRC (i.e., IR)
      or CO headers carrying a 7-bit CRC can be decompressed.

   Upward transition:

      The decompressor can move to the Full Context (FC) state when the
      CRC verification succeeds for a CO header carrying a 7-bit CRC or
      when validation of an 8-bit CRC in an IR header succeeds.

   Downward transition:

      The decompressor moves back to the NC state if it assumes static
      context damage.

Top      ToC       Page 17 
   Feedback logic:

      In the RC state, the decompressor should send a STATIC-NACK when
      CRC-8 validation of an IR header fails, or when a CO header
      carrying a 7-bit CRC fails and static context damage is assumed,
      subject to the feedback rate limitation as described in
      Section 5.2.3.  If any other packet type is received, the
      decompressor should treat it as a CRC verification failure to
      determine if NACK is to be sent.

5.2.1.3.  Full Context (FC) State

   In the Full Context (FC) state, the decompressor assumes that its
   entire context is valid.

   Attempting decompression:

      In the FC state, decompression can be attempted regardless of the
      type of packet received.

   Downward transition:

      The decompressor moves back to the RC state if it assumes context
      damage.  If the decompressor assumes static context damage, it
      moves directly to the NC state.

   Feedback logic:

      In the FC state, the decompressor should send a NACK when CRC-8
      validation or CRC verification of any header type fails and if
      context damage is assumed, or it should send a STATIC-NACK if
      static context damage is assumed; this is subject to the feedback
      rate limitation described in Section 5.2.3.

5.2.2.  Decompressor Context Management

   All header formats carry a CRC and are context updating.  A packet
   for which the CRC succeeds updates the reference values of all header
   fields, either explicitly (from the information about a field carried
   within the compressed header) or implicitly (fields inferred from
   other fields).

   The decompressor may assume that some or the entire context is
   invalid, when it fails to validate or to verify one or more headers
   using the CRC.  Because the decompressor cannot know the exact

Top      ToC       Page 18 
   reason(s) for a CRC failure or what field caused it, the validity of
   the context hence does not refer to what specific part(s) of the
   context is deemed valid or not.

   Validity of the context rather relates to the detection of a problem
   with the context.  The decompressor first assumes that the type of
   information that most likely caused the failure(s) is the state that
   normally changes for each packet, i.e., context damage of the dynamic
   part of the context.  Upon repeated decompression failures and
   unsuccessful repairs, the decompressor then assumes that the entire
   context, including the static part, needs to be repaired, i.e.,
   static context damage.  Failure to validate the 3-bit CRC that
   protects control fields should be treated as a decompression failure
   when the decompressor asserts the validity of its context.

   Context Damage Detection

      The assumption of context damage means that the decompressor will
      not attempt decompression of a CO header that carries only a 3-bit
      CRC, and will only attempt decompression of IR headers or CO
      headers protected by a CRC-7.

   Static Context Damage Detection

      The assumption of static context damage means that the
      decompressor refrains from attempting decompression of any type of
      header other than the IR header.

   How these assumptions are made, i.e., how context damage is detected,
   is open to implementations.  It can be based on the residual error
   rate, where a low error rate makes the decompressor assume damage
   more often than on a high rate link.

   The decompressor implements these assumptions by selecting the type
   of compressed header for which it will attempt decompression.  In
   other words, validity of the context refers to the ability of a
   decompressor to attempt (or not) decompression of specific packet
   types.

   When ROHCv2 profiles are used over a channel that cannot guarantee
   in-order delivery, the decompressor may refrain from updating its
   context with the content of a sequentially late packet that is
   successfully decompressed.  This is to avoid updating the context
   with information that is older than what the decompressor already has
   in its context.

Top      ToC       Page 19 
5.2.3.  Feedback Logic

   ROHCv2 profiles may be used in environments with or without feedback
   capabilities from decompressor to compressor.  ROHCv2 however assumes
   that if a ROHC feedback channel is available and if this channel is
   used at least once by the decompressor for a specific context, this
   channel will be used during the entire compression operation for that
   context (i.e., bidirectional operation).

   The ROHC framework defines 3 types of feedback messages: ACKs, NACKs,
   and STATIC-NACKs.  The semantics of each message is defined in
   Section 5.2.4.1. of [RFC4995].  What feedback to send is coupled with
   the context management of the decompressor, i.e., with the
   implementation of the context damage detection algorithms as
   described in Section 5.2.2.

   The decompressor should send a NACK when it assumes context damage,
   and it should send a STATIC-NACK when it assumes static context
   damage.  The decompressor is not strictly expected to send ACK
   feedback upon successful decompression, other than for the purpose of
   improving compression efficiency.

   When ROHCv2 profiles are used over a channel that cannot guarantee
   in-order delivery, the decompressor may refrain from sending ACK
   feedback for a sequentially late packet that is successfully
   decompressed.

   The decompressor should limit the rate at which it sends feedback,
   for both ACKs and STATIC-NACK/NACKs, and should avoid sending
   unnecessary duplicates of the same type of feedback message that may
   be associated with the same event.



(page 19 continued on part 2)

Next RFC Part