tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4996


Pages: 94
Top     in Index     Prev     Next
 

RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)

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

Obsoleted by:    6846


Top       ToC       Page 1 
Network Working Group                                       G. Pelletier
Request for Comments: 4996                                   K. Sandlund
Category: Standards Track                                       Ericsson
                                                            L-E. Jonsson

                                                                 M. West
                                                      Siemens/Roke Manor
                                                               July 2007


   RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)

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.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies a ROHC (Robust Header Compression) profile
   for compression of TCP/IP packets.  The profile, called ROHC-TCP,
   provides efficient and robust compression of TCP headers, including
   frequently used TCP options such as SACK (Selective Acknowledgments)
   and Timestamps.

   ROHC-TCP works well when used over links with significant error rates
   and long round-trip times.  For many bandwidth-limited links where
   header compression is essential, such characteristics are common.

Top       Page 2 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Existing TCP/IP Header Compression Schemes . . . . . . . .  5
     3.2.  Classification of TCP/IP Header Fields . . . . . . . . . .  6
   4.  Overview of the TCP/IP Profile (Informative) . . . . . . . . .  8
     4.1.  General Concepts . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Compressor and Decompressor Interactions . . . . . . . . .  8
       4.2.1.  Compressor Operation . . . . . . . . . . . . . . . . .  8
       4.2.2.  Decompressor Feedback  . . . . . . . . . . . . . . . .  9
     4.3.  Packet Formats and Encoding Methods  . . . . . . . . . . .  9
       4.3.1.  Compressing TCP Options  . . . . . . . . . . . . . . . 10
       4.3.2.  Compressing Extension Headers  . . . . . . . . . . . . 10
     4.4.  Expected Compression Ratios with ROHC-TCP  . . . . . . . . 10
   5.  Compressor and Decompressor Logic (Normative)  . . . . . . . . 11
     5.1.  Context Initialization . . . . . . . . . . . . . . . . . . 11
     5.2.  Compressor Operation . . . . . . . . . . . . . . . . . . . 11
       5.2.1.  Compression Logic  . . . . . . . . . . . . . . . . . . 11
       5.2.2.  Feedback Logic . . . . . . . . . . . . . . . . . . . . 13
       5.2.3.  Context Replication  . . . . . . . . . . . . . . . . . 14
     5.3.  Decompressor Operation . . . . . . . . . . . . . . . . . . 14
       5.3.1.  Decompressor States and Logic  . . . . . . . . . . . . 14
       5.3.2.  Feedback Logic . . . . . . . . . . . . . . . . . . . . 18
       5.3.3.  Context Replication  . . . . . . . . . . . . . . . . . 18
   6.  Encodings in ROHC-TCP (Normative)  . . . . . . . . . . . . . . 18
     6.1.  Control Fields in ROHC-TCP . . . . . . . . . . . . . . . . 18
       6.1.1.  Master Sequence Number (MSN) . . . . . . . . . . . . . 19
       6.1.2.  IP-ID Behavior . . . . . . . . . . . . . . . . . . . . 19
       6.1.3.  Explicit Congestion Notification (ECN) . . . . . . . . 20
     6.2.  Compressed Header Chains . . . . . . . . . . . . . . . . . 21
     6.3.  Compressing TCP Options with List Compression  . . . . . . 23
       6.3.1.  List Compression . . . . . . . . . . . . . . . . . . . 23
       6.3.2.  Table-Based Item Compression . . . . . . . . . . . . . 24
       6.3.3.  Encoding of Compressed Lists . . . . . . . . . . . . . 25
       6.3.4.  Item Table Mappings  . . . . . . . . . . . . . . . . . 26
       6.3.5.  Compressed Lists in Dynamic Chain  . . . . . . . . . . 28
       6.3.6.  Irregular Chain Items for TCP Options  . . . . . . . . 28
       6.3.7.  Replication of TCP Options . . . . . . . . . . . . . . 28
     6.4.  Profile-Specific Encoding Methods  . . . . . . . . . . . . 29
       6.4.1.  inferred_ip_v4_header_checksum . . . . . . . . . . . . 29
       6.4.2.  inferred_mine_header_checksum  . . . . . . . . . . . . 30
       6.4.3.  inferred_ip_v4_length  . . . . . . . . . . . . . . . . 30
       6.4.4.  inferred_ip_v6_length  . . . . . . . . . . . . . . . . 31
       6.4.5.  inferred_offset  . . . . . . . . . . . . . . . . . . . 31
       6.4.6.  baseheader_extension_headers . . . . . . . . . . . . . 31
       6.4.7.  baseheader_outer_headers . . . . . . . . . . . . . . . 32

Top      ToC       Page 3 
       6.4.8.  Scaled Encoding of Fields  . . . . . . . . . . . . . . 32
     6.5.  Encoding Methods With External Parameters  . . . . . . . . 34
   7.  Packet Types (Normative) . . . . . . . . . . . . . . . . . . . 36
     7.1.  Initialization and Refresh (IR) Packets  . . . . . . . . . 36
     7.2.  Context Replication (IR-CR) Packets  . . . . . . . . . . . 38
     7.3.  Compressed (CO) Packets  . . . . . . . . . . . . . . . . . 41
   8.  Header Formats (Normative) . . . . . . . . . . . . . . . . . . 42
     8.1.  Design Rationale for Compressed Base Headers . . . . . . . 42
     8.2.  Formal Definition of Header Formats  . . . . . . . . . . . 45
     8.3.  Feedback Formats and Options . . . . . . . . . . . . . . . 86
       8.3.1.  Feedback Formats . . . . . . . . . . . . . . . . . . . 86
       8.3.2.  Feedback Options . . . . . . . . . . . . . . . . . . . 87
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 89
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 89
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 90
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 90
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 90
     12.2. Informative References . . . . . . . . . . . . . . . . . . 91

1.  Introduction

   There are several reasons to perform header compression on low- or
   medium-speed links for TCP/IP traffic, and these have already been
   discussed in [RFC2507].  Additional considerations that make
   robustness an important objective for a TCP [RFC0793] compression
   scheme are introduced in [RFC4163].  Finally, existing TCP/IP header
   compression schemes ([RFC1144], [RFC2507]) are limited in their
   handling of the TCP options field and cannot compress the headers of
   handshaking packets (SYNs and FINs).

   It is thus desirable for a header compression scheme to be able to
   handle loss on the link between the compression and decompression
   points as well as loss before the compression point.  The header
   compression scheme also needs to consider how to efficiently compress
   short-lived TCP transfers and TCP options, such as SACK ([RFC2018],
   [RFC2883]) and Timestamps ([RFC1323]).

   The ROHC WG has developed a header compression framework on top of
   which various profiles can be defined for different protocol sets, or
   for different compression strategies.  This document defines a TCP/IP
   compression profile for the ROHC framework [RFC4995], compliant with
   the requirements listed in [RFC4163].

   Specifically, it describes a header compression scheme for TCP/IP
   header compression (ROHC-TCP) that is robust against packet loss and
   that offers enhanced capabilities, in particular for the compression
   of header fields including TCP options.  The profile identifier for
   TCP/IP compression is 0x0006.

Top      ToC       Page 4 
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 [RFC2119].

   This document reuses some of the terminology found in [RFC4995].  In
   addition, this document uses or defines the following terms:

   Base context

      The base context is a context that has been validated by both the
      compressor and the decompressor.  A base context can be used as
      the reference when building a new context using replication.

   Base Context Identifier (Base CID)

      The Base CID is the CID that identifies the base context, from
      which information needed for context replication can be extracted.

   Base header

      A compressed representation of the innermost IP and TCP headers of
      the uncompressed packet.

   Chaining of items

      A chain groups fields based on similar characteristics.  ROHC-TCP
      defines chain items for static, dynamic, replicable, or irregular
      fields.  Chaining is done by appending an item for each header
      e.g., to the chain in their 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 ROHC-TCP defines a compressed format.

   Context Replication (CR)

      Context replication is the mechanism that establishes and
      initializes a new context based on another existing valid context
      (a base context).  This mechanism is introduced to reduce the
      overhead of the context establishment procedure, and is especially
      useful for compression of multiple short-lived TCP connections
      that may be occurring simultaneously or near-simultaneously.

Top      ToC       Page 5 
   ROHC-TCP packet types

      ROHC-TCP uses three different packet types: the Initialization and
      Refresh (IR) packet type, the Context Replication (IR-CR) packet
      type, and the Compressed packet (CO) type.

   Short-lived TCP transfer

      Short-lived TCP transfers refer to TCP connections transmitting
      only small amounts of packets for each single connection.

3.  Background

   This section provides some background information on TCP/IP header
   compression.  The fundamentals of general header compression can be
   found in [RFC4995].  In the following subsections, two existing
   TCP/IP header compression schemes are first described along with a
   discussion of their limitations, followed by the classification of
   TCP/IP header fields.  Finally, some of the characteristics of
   short-lived TCP transfers are summarized.

   A behavior analysis of TCP/IP header fields is found in [RFC4413].

3.1.  Existing TCP/IP Header Compression Schemes

   Compressed TCP (CTCP) and IP Header Compression (IPHC) are two
   different schemes that may be used to compress TCP/IP headers.  Both
   schemes transmit only the differences from the previous header in
   order to reduce the size of the TCP/IP header.

   The CTCP [RFC1144] compressor detects transport-level retransmissions
   and sends a header that updates the context completely when they
   occur.  While CTCP works well over reliable links, it is vulnerable
   when used over less reliable links as even a single packet loss
   results in loss of synchronization between the compressor and the
   decompressor.  This in turn leads to the TCP receiver discarding all
   remaining packets in the current window because of a checksum error.
   This effectively prevents the TCP fast retransmit algorithm [RFC2581]
   from being triggered.  In such a case, the compressor must wait until
   TCP times out and retransmits a packet to resynchronize.

   To reduce the errors due to the inconsistent contexts between
   compressor and decompressor when compressing TCP, IPHC [RFC2507]
   improves somewhat on CTCP by augmenting the repair mechanism of CTCP
   with a local repair mechanism called TWICE and with a link-layer
   mechanism based on negative acknowledgments to request a header that
   updates the context.

Top      ToC       Page 6 
   The TWICE algorithm assumes that only the Sequence Number field of
   TCP segments is changing with the deltas between consecutive packets
   being constant in most cases.  This assumption is however not always
   true, especially when TCP Timestamps and SACK options are used.

   The full header request mechanism requires a feedback channel that
   may be unavailable in some circumstances.  This channel is used to
   explicitly request that the next packet be sent with an uncompressed
   header to allow resynchronization without waiting for a TCP timeout.
   In addition, this mechanism does not perform well on links with long
   round-trip times.

   Both CTCP and IPHC are also limited in their handling of the TCP
   options field.  For IPHC, any change in the options field (caused by
   Timestamps or SACK, for example) renders the entire field
   uncompressible, while for CTCP, such a change in the options field
   effectively disables TCP/IP header compression altogether.

   Finally, existing TCP/IP compression schemes do not compress the
   headers of handshaking packets (SYNs and FINs).  Compressing these
   packets may greatly improve the overall header compression ratio for
   the cases where many short-lived TCP connections share the same
   channel.

3.2.  Classification of TCP/IP Header Fields

   Header compression is possible due to the fact that there is much
   redundancy between header field values within packets, especially
   between consecutive packets.  To utilize these properties for TCP/IP
   header compression, it is important to understand the change patterns
   of the various header fields.

   All fields of the TCP/IP packet header have been classified in detail
   in [RFC4413].  The main conclusion is that most of the header fields
   can easily be compressed away since they seldom or never change.  The
   following fields do however require more sophisticated mechanisms:

     - IPv4 Identification       (16 bits) - IP-ID
     - TCP Sequence Number       (32 bits) - SN
     - TCP Acknowledgment Number (32 bits)
     - TCP Reserved              ( 4 bits)
     - TCP ECN flags             ( 2 bits) - ECN
     - TCP Window                (16 bits)

Top      ToC       Page 7 
     - TCP Options
       o  Maximum Segment Size   (32 bits) - MSS
       o  Window Scale           (24 bits) - WSCALE
       o  SACK Permitted         (16 bits)
       o  TCP SACK               (80, 144, 208, or 272 bits) - SACK
       o  TCP Timestamp          (80 bits) - TS

   The assignment of IP-ID values can be done in various ways, usually
   one of sequential, sequential jump, or random, as described in
   Section 4.1.3 of [RFC4413].  Some IPv4 stacks do use a sequential
   assignment when generating IP-ID values but do not transmit the
   contents of this field in network byte order; instead, it is sent
   with the two octets reversed.  In this case, the compressor can
   compress the IP-ID field after swapping the bytes.  Consequently, the
   decompressor also swaps the bytes of the IP-ID after decompression to
   regenerate the original IP-ID.  With respect to TCP compression, the
   analysis in [RFC4413] reveals that there is no obvious candidate
   among the TCP fields suitable to infer the IP-ID.

   The change pattern of several TCP fields (Sequence Number,
   Acknowledgment Number, Window, etc.) is very hard to predict.  Of
   particular importance to a TCP/IP header compression scheme is the
   understanding of the sequence and acknowledgment numbers [RFC4413].

   Specifically, the TCP Sequence Number can be anywhere within a range
   defined by the TCP Window at any point on the path (i.e., wherever a
   compressor might be deployed).  Missing packets or retransmissions
   can cause the TCP Sequence Number to fluctuate within the limits of
   this window.  The TCP Window also bounds the jumps in acknowledgment
   number.

   Another important behavior of the TCP/IP header is the dependency
   between the sequence number and the acknowledgment number.  TCP
   connections can be either near-symmetrical or show a strong
   asymmetrical bias with respect to the data traffic.  In the latter
   case, the TCP connections mainly have one-way traffic (Web browsing
   and file downloading, for example).  This means that on the forward
   path (from server to client), only the sequence number is changing
   while the acknowledgment number remains constant for most packets; on
   the backward path (from client to server), only the acknowledgment
   number is changing and the sequence number remains constant for most
   packets.  A compression scheme for TCP should thus have packet
   formats suitable for either cases, i.e., packet formats that can
   carry either only sequence number bits, only acknowledgment number
   bits, or both.

   In addition, TCP flows can be short-lived transfers.  Short-lived TCP
   transfers will degrade the performance of header compression schemes

Top      ToC       Page 8 
   that establish a new context by initially sending full headers.
   Multiple simultaneous or near simultaneous TCP connections may
   exhibit much similarity in header field values and context values
   among each other, which would make it possible to reuse information
   between flows when initializing a new context.  A mechanism to this
   end, context replication [RFC4164], makes the context establishment
   step faster and more efficient, by replicating part of an existing
   context to a new flow.  The conclusion from [RFC4413] is that part of
   the IP sub-context, some TCP fields, and some context values can be
   replicated since they seldom change or change with only a small jump.

   ROHC-TCP also compresses the following headers: IPv6 Destination
   Options header [RFC2460], IPv6 Routing header [RFC2460], IPv6 Hop-by-
   Hop Options header [RFC2460], Authentication Header (AH) [RFC4302],
   NULL-encrypted Encapsulating Security Payload (ESP) header [RFC4303],
   Generic Routing Encapsulation (GRE) [RFC2784][RFC2890] and the
   Minimal Encapsulation header (MINE) [RFC2004].

   Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any
   special treatment in this document, for reasons similar to those
   described in [RFC3095].

4.  Overview of the TCP/IP Profile (Informative)

4.1.  General Concepts

   ROHC-TCP uses the ROHC protocol as described in [RFC4995].  ROHC-TCP
   supports context replication as defined in [RFC4164].  Context
   replication can be particularly useful for short-lived TCP flows
   [RFC4413].

4.2.  Compressor and Decompressor Interactions

4.2.1.  Compressor Operation

   Header compression with ROHC can be conceptually characterized as the
   interaction of a compressor with a decompressor state machine.  The
   compressor's task is to minimally send the information needed to
   successfully decompress a packet, based on a certain confidence
   regarding the state of the decompressor context.

   For ROHC-TCP compression, 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.  Alternatively, the compressor may also support
   Context Replication (CR) and use IR-CR packets [RFC4164], which
   attempts to reuse context information related to another flow.

Top      ToC       Page 9 
   The compressor can then adjust the compression level based on its
   confidence that the decompressor has the necessary information to
   successfully process the Compressed (CO) packets that it selects.  In
   other words, the task of the compressor is to ensure that the
   decompressor operates in the state that allows decompression of the
   most efficient CO packet(s), and to allow the decompressor to move to
   that state as soon as possible otherwise.

4.2.2.  Decompressor Feedback

   The ROHC-TCP profile can be used in environments with or without
   feedback capabilities from decompressor to compressor.  ROHC-TCP
   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
   ROHC-TCP context, this channel will be used during the entire
   compression operation for that context.  If the feedback channel
   disappears, compression should be restarted.

   The reception of either positive acknowledgment (ACKs) or negative
   acknowledgment (NACKs) establishes the feedback channel from the
   decompressor for the context for which the feedback was received.
   Once there is an established feedback channel for a specific context,
   the compressor should make use of this feedback to estimate the
   current state of the decompressor.  This helps in increasing the
   compression efficiency by providing the information needed for the
   compressor to achieve the necessary confidence level.

   The ROHC-TCP feedback mechanism is limited in its applicability by
   the number of (least significant bit (LSB) encoded) master sequence
   number (MSN) (see Section 6.1.1) bits used in the FEEDBACK-2 format
   (see Section 8.3).  It is not suitable for a decompressor to use
   feedback altogether where the MSN bits in the feedback could wrap
   around within one round-trip time.  Instead, unidirectional operation
   -- where the compressor periodically sends larger context-updating
   packets -- is more appropriate.

4.3.  Packet Formats and Encoding Methods

   The packet formats and encoding methods used for ROHC-TCP are defined
   using the formal notation [RFC4997].  The formal notation is used to
   provide an unambiguous representation of the packet formats and a
   clear definition of the encoding methods.

Top      ToC       Page 10 
4.3.1.  Compressing TCP Options

   The TCP options in ROHC-TCP are compressed using a list compression
   encoding that allows option content to be established so that TCP
   options can be added to the context without having to send all TCP
   options uncompressed.

4.3.2.  Compressing Extension Headers

   ROHC-TCP compresses the extension headers as listed in Section 3.2.
   These headers are treated exactly as other headers and thus have a
   static chain, a dynamic chain, an irregular chain, and a chain for
   context replication (Section 6.2).

   This means that headers appearing in or disappearing from the flow
   being compressed will lead to changes to the static chain.  However,
   the change pattern of extension headers is not deemed to impair
   compression efficiency with respect to this design strategy.

4.4.  Expected Compression Ratios with ROHC-TCP

   The following table illustrates typical compression ratios that can
   be expected when using ROHC-TCP and IPHC [RFC2507].

   The figures in the table assume that the compression context has
   already been properly initialized.  For the TS option, the Timestamp
   is assumed to change with small values.  All TCP options include a
   suitable number of No Operation (NOP) options [RFC0793] for padding
   and/or alignment.  Finally, in the examples for IPv4, a sequential
   IP-ID behavior is assumed.

                             Total Header Size (octets)
                              ROHC-TCP          IPHC
                     Unc.   DATA    ACK      DATA    ACK
   IPv4+TCP+TS       52       8      8        18     18
   IPv4+TCP+TS       52       7      6        16     16   (1)
   IPv6+TCP+TS       72       8      7        18     18
   IPv6+TCP+no opt   60       6      5         6      6
   IPv6+TCP+SACK     80       -     15         -     80   (2)
   IPv6+TCP+SACK     80       -      9         -     26   (3)

   (1) The payload size of the data stream is constant.
   (2) The SACK option appears in the header, but was not present
       in the previous packet.  Two SACK blocks are assumed.
   (3) The SACK option appears in the header, and was also present
       in the previous packet (with different SACK blocks).
       Two SACK blocks are assumed.

Top      ToC       Page 11 
   The table below illustrates the typical initial compression ratios
   for ROHC-TCP and IPHC.  The data stream in the example is assumed to
   be IPv4+TCP, with a sequential behavior for the IP-ID.  The following
   options are assumed present in the SYN packet: TS, MSS, and WSCALE,
   with an appropriate number of NOP options.

                     Total Header Size (octets)
                      Unc.   ROHC-TCP   IPHC
   1st packet (SYN)   60      49        60
   2nd packet         52      12        52

   The figures in the table assume that the compressor has received an
   acknowledgment from the decompressor before compressing the second
   packet, which can be expected when feedback is used in ROHC-TCP.
   This is because in the most common case, the TCP ACKs are expected to
   take the same return path, and because TCP does not send more packets
   until the TCP SYN packet has been acknowledged.

5.  Compressor and Decompressor Logic (Normative)

5.1.  Context Initialization

   The static context of ROHC-TCP flows can be initialized in either of
   two ways:

   1.  By using an IR packet as in Section 7.1, where the profile number
       is 0x06 and the static chain ends with the static part of a TCP
       header.

   2.  By replicating an existing context using the mechanism defined by
       [RFC4164].  This is done with the IR-CR packet defined in
       Section 7.2, where the profile number is 0x06.

5.2.  Compressor Operation

5.2.1.  Compression Logic

   The task of the compressor is to determine what data must be sent
   when compressing a TCP/IP packet, so that the decompressor can
   successfully reconstruct the original packet based on its current
   state.  The selection of the type of compressed header to send thus
   depends on a number of factors, including:

   o  The change behavior of header fields in the flow, e.g., conveying
      the necessary information within the restrictions of the set of
      available packet formats.

Top      ToC       Page 12 
   o  The compressor's level of confidence regarding decompressor state,
      e.g., by selecting header formats updating the same type of
      information for a number of consecutive packets or from the
      reception of decompressor feedback (ACKs and/or NACKs).

   o  Additional robustness required for the flow, e.g., periodic
      refreshes of static and dynamic information using IR and IR-DYN
      packets when decompressor feedback is not expected.

   The impact of these factors on the compressor's packet type selection
   is described in more detail in the following subsections.

   In this section, a "higher compression state" means that less data
   will be sent in compressed packets, i.e., smaller compressed headers
   are used, while a lower compression state means that a larger amount
   of data will be sent using larger compressed headers.

5.2.1.1.  Optimistic Approach

   The optimistic approach is the principle by which a compressor sends
   the same type of information for a number of packets (consecutively
   or not) until it is fairly confident that the decompressor has
   received the information.  The optimistic approach is useful to
   ensure robustness when ROHC-TCP is used to compress packet over lossy
   links.

   Therefore, if field X in the uncompressed packet changes value, the
   compressor MUST use a packet type that contains an encoding for field
   X until it has gained confidence that the decompressor has received
   at least one packet containing the new value for X. The compressor
   SHOULD choose a compressed format with the smallest header that can
   convey the changes needed to fulfill the optimistic approach
   condition used.

5.2.1.2.  Periodic Context Refreshes

   When the optimistic approach is used, there will always be a
   possibility of decompression failures since the decompressor may not
   have received sufficient information for correct decompression.

   Therefore, until the decompressor has established a feedback channel,
   the compressor SHOULD periodically move to a lower compression state
   and send IR and/or IR-DYN packets.  These refreshes can be based on
   timeouts, on the number of compressed packets sent for the flow, or
   any other strategy specific to the implementation.  Once the feedback
   channel is established, the decompressor MAY stop performing periodic
   refreshes.

Top      ToC       Page 13 
5.2.2.  Feedback Logic

   The semantics of feedback messages, acknowledgments (ACKs) and
   negative acknowledgments (NACKs or STATIC-NACKs), are defined in
   Section 5.2.4.1 of [RFC4995].

5.2.2.1.  Optional Acknowledgments (ACKs)

   The compressor MAY use acknowledgment feedback (ACKs) to move to a
   higher compression state.

   Upon reception of an ACK for a context-updating packet, the
   compressor obtains confidence that the decompressor has received the
   acknowledged packet and that it has observed changes in the packet
   flow up to the acknowledged packet.

   This functionality is optional, so a compressor MUST NOT expect to
   get such ACKs, even if a feedback channel is available and has been
   established for that flow.

5.2.2.2.  Negative Acknowledgments (NACKs)

   The compressor uses feedback from the decompressor to move to a lower
   compression state (NACKs).

   On reception of a NACK feedback, the compressor SHOULD:

   o  assume that only the static part of the decompressor is valid, and

   o  re-send all dynamic information (via an IR or IR-DYN packet) the
      next time it compresses a packet for the indicated flow

   unless it has confidence that information sent after the packet being
   acknowledged already provides a suitable response to the NACK
   feedback.  In addition, the compressor MAY use a CO packet carrying a
   7-bit Cyclic Redundancy Check (CRC) if it can determine with enough
   confidence what information provides a suitable response to the NACK
   feedback.

   On reception of a STATIC-NACK feedback, the compressor SHOULD:

   o  assume that the decompressor has no valid context, and

   o  re-send all static and all dynamic information (via an IR packet)
      the next time it compresses a packet for the indicated flow

Top      ToC       Page 14 
   unless it has confidence that information sent after the packet that
   is being acknowledged already provides a suitable response to the
   STATIC-NACK feedback.

5.2.3.  Context Replication

   A compressor MAY support context replication by implementing the
   additional compression and feedback logic defined in [RFC4164].

5.3.  Decompressor Operation

5.3.1.  Decompressor States and Logic

   The three states of the decompressor are No Context (NC), Static
   Context (SC), and Full Context (FC).  The decompressor starts in its
   lowest compression state, the NC state.  Successful decompression
   will always move the decompressor to the FC state.  The decompressor
   state machine normally never leaves the FC state once it has entered
   this state; only repeated decompression failures will force the
   decompressor to transit downwards to a lower state.

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

                                 Success
                +-->------>------>------>------>------>--+
                |                                        |
    No Static   |            No Dynamic        Success   |    Success
     +-->--+    |             +-->--+      +--->----->---+    +-->--+
     |     |    |             |     |      |             |    |     |
     |     v    |             |     v      |             v    |     v
   +-----------------+   +---------------------+   +-------------------+
   | No Context (NC) |   | Static Context (SC) |   | Full Context (FC) |
   +-----------------+   +---------------------+   +-------------------+
      ^                         |        ^                         |
      |  Static Context         |        | Context Damage Assumed  |
      |  Damage Assumed         |        |                         |
      +-----<------<------<-----+        +-----<------<------<-----+

5.3.1.1.  Reconstruction and Verification

   When decompressing an IR or an IR-DYN packet, the decompressor MUST
   validate the integrity of the received header using CRC-8 validation
   [RFC4995].  If validation fails, the packet MUST NOT be delivered to
   upper layers.

Top      ToC       Page 15 
   Upon receiving an IR-CR packet, the decompressor MUST perform the
   actions as specified in [RFC4164].

   When decompressing other packet types (e.g., CO packets), the
   decompressor MUST validate the outcome of the decompression attempt
   using CRC verification [RFC4995].  If verification fails, a
   decompressor implementation MAY attempt corrective or repair measures
   on the packet, and the result of any attempt MUST be validated using
   the CRC verification; otherwise, the packet MUST NOT be delivered to
   upper layers.

   When the CRC-8 validation or the CRC verification of the received
   header is successful, the decompressor SHOULD update its context with
   the information received in the current header; the decompressor then
   passes the reconstructed packet to the system's network layer.
   Otherwise, the decompressor context MUST NOT be updated.

   If the received packet is older than the current reference packet,
   e.g., based on the master sequence number (MSN) in the compressed
   packet, the decompressor MAY refrain from updating the context using
   the information received in the current packet, even if the
   correctness of its header was successfully verified.

5.3.1.2.  Detecting Context Damage

   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 that are inferred
   from other fields).

   The decompressor may assume that some or the entire context is
   invalid, following one or more failures to validate or verify a
   header using the CRC.  Because the decompressor cannot know the exact
   reason(s) for a CRC failure or what field caused it, the validity of
   the context hence does not refer to what exact context entry 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 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.

Top      ToC       Page 16 
   Context Damage Detection

      The assumption of context damage means that the decompressor will
      not attempt decompression of a CO header that carries a 3-bit CRC,
      and only attempt decompression of IR, IR-DYN, or IR-CR 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 may attempt decompression.  In
   other words, validity of the context refers to the ability of a
   decompressor to attempt or not attempt decompression of specific
   packet types.

5.3.1.3.  No Context (NC) State

   Initially, while working in the No Context (NC) state, the
   decompressor has not yet successfully decompressed a packet.

   Allowing decompression:

      In the NC state, only packets carrying sufficient information on
      the static fields (IR and IR-CR packets) can be decompressed;
      otherwise, the packet MUST NOT be decompressed and MUST NOT be
      delivered to upper layers.

   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 decompression of
      an IR packet has failed, subject to the feedback rate limitation
      as described in Section 5.3.2

   Once a packet has been validated and decompressed correctly, the
   decompressor MUST transit to the FC state.

Top      ToC       Page 17 
5.3.1.4.  Static Context (SC) State

   When the decompressor is in the Static Context (SC) state, only the
   static part of the decompressor context is valid.

   From the SC state, the decompressor moves back to the NC state if
   static context damage is detected.

   Allowing decompression:

      In the SC state, packets carrying sufficient information on the
      dynamic fields covered by an 8-bit CRC (e.g., IR and IR-DYN) or CO
      packets covered by a 7-bit CRC can be decompressed; otherwise, the
      packet MUST NOT be decompressed and MUST NOT be delivered to upper
      layers.

   Feedback logic:

      In the SC state, the decompressor should send a STATIC-NACK if CRC
      validation of an IR/IR-DYN/IR-CR fails and static context damage
      is assumed.  If any other packet type is received, the
      decompressor should send a NACK.  Both of the above cases are
      subject to the feedback rate limitation as described in
      Section 5.3.2.

   Once a packet has been validated and decompressed correctly, the
   decompressor MUST transit to the FC state.

5.3.1.5.  Full Context (FC) State

   In the Full Context (FC) state, both the static and the dynamic parts
   of the decompressor context are valid.  From the FC state, the
   decompressor moves back to the SC state if context damage is
   detected.

   Allowing decompression:

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

   Feedback logic:

      In the FC state, the decompressor should send a NACK if the
      decompression of any packet type fails and context damage is
      assumed, subject to the feedback rate limitation as described in
      Section 5.3.2.

Top      ToC       Page 18 
5.3.2.  Feedback Logic

   The decompressor MAY send positive feedback (ACKs) to initially
   establish the feedback channel for a particular flow.  Either
   positive feedback (ACKs) or negative feedback (NACKs) establishes
   this channel.

   Once the feedback channel is established, the decompressor is
   REQUIRED to continue sending NACKs or STATIC-NACKs for as long as the
   context is associated with the same profile, in this case with
   profile 0x0006, as per the logic defined for each state in
   Section 5.3.1.

   The decompressor MAY send ACKs upon successful decompression of any
   packet type.  In particular, when a packet carrying a significant
   context update is correctly decompressed, the decompressor MAY send
   an ACK.

   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 to the same event.

5.3.3.  Context Replication

   ROHC-TCP supports context replication; therefore, the decompressor
   MUST implement the additional decompressor and feedback logic defined
   in [RFC4164].



(page 18 continued on part 2)

Next RFC Part