Tech-invite3GPPspecsSIPRFCs
90898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 6846

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

Pages: 96
Proposed Standard
Errata
Obsoletes:  4996
Part 1 of 5 – Pages 1 to 13
None   None   Next

Top   ToC   RFC6846 - Page 1
Internet Engineering Task Force (IETF)                      G. Pelletier
Request for Comments: 6846                   InterDigital Communications
Obsoletes: 4996                                              K. Sandlund
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                             L-E. Jonsson

                                                                 M. West
                                                      Siemens/Roke Manor
                                                            January 2013


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

Abstract

This document specifies a RObust Header Compression (ROHC) 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 selective acknowledgments (SACKs) 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. This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6846.
Top   ToC   RFC6846 - Page 2
Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
Top   ToC   RFC6846 - Page 3

Table of Contents

1. Introduction ....................................................5 2. Terminology .....................................................5 3. Background ......................................................7 3.1. Existing TCP/IP Header Compression Schemes .................7 3.2. Classification of TCP/IP Header Fields .....................8 4. Overview of the TCP/IP Profile (Informative) ...................10 4.1. General Concepts ..........................................10 4.2. Compressor and Decompressor Interactions ..................10 4.2.1. Compressor Operation ...............................10 4.2.2. Decompressor Feedback ..............................11 4.3. Packet Formats and Encoding Methods .......................11 4.3.1. Compressing TCP Options ............................11 4.3.2. Compressing Extension Headers ......................11 4.4. Expected Compression Ratios with ROHC-TCP .................12 5. Compressor and Decompressor Logic (Normative) ..................13 5.1. Context Initialization ....................................13 5.2. Compressor Operation ......................................13 5.2.1. Compression Logic ..................................13 5.2.1.1. Optimistic Approach .......................14 5.2.1.2. Periodic Context Refreshes ................14 5.2.2. Feedback Logic .....................................14 5.2.2.1. Optional Acknowledgments (ACKs) ...........14 5.2.2.2. Negative Acknowledgments (NACKs) ..........15 5.2.3. Context Replication ................................15 5.3. Decompressor Operation ....................................16 5.3.1. Decompressor States and Logic ......................16 5.3.1.1. Reconstruction and Verification ...........16 5.3.1.2. Detecting Context Damage ..................17 5.3.1.3. No Context (NC) State .....................18 5.3.1.4. Static Context (SC) State .................18 5.3.1.5. Full Context (FC) State ...................19 5.3.2. Feedback Logic .....................................19 5.3.3. Context Replication ................................20 6. Encodings in ROHC-TCP (Normative) ..............................20 6.1. Control Fields in ROHC-TCP ................................20 6.1.1. Master Sequence Number (MSN) .......................20 6.1.2. IP-ID Behavior .....................................21 6.1.3. Explicit Congestion Notification (ECN) .............22 6.2. Compressed Header Chains ..................................22 6.3. Compressing TCP Options with List Compression .............24 6.3.1. List Compression ...................................25 6.3.2. Table-Based Item Compression .......................26 6.3.3. Encoding of Compressed Lists .......................26 6.3.4. Item Table Mappings ................................28 6.3.5. Compressed Lists in Dynamic Chain ..................30 6.3.6. Irregular Chain Items for TCP Options ..............30
Top   ToC   RFC6846 - Page 4
           6.3.7. Replication of TCP Options .........................30
      6.4. Profile-Specific Encoding Methods .........................31
           6.4.1. inferred_ip_v4_header_checksum .....................31
           6.4.2. inferred_mine_header_checksum ......................31
           6.4.3. inferred_ip_v4_length ..............................32
           6.4.4. inferred_ip_v6_length ..............................32
           6.4.5. inferred_offset ....................................33
           6.4.6. baseheader_extension_headers .......................33
           6.4.7. baseheader_outer_headers ...........................34
           6.4.8. Scaled Encoding of Fields ..........................34
                  6.4.8.1. Scaled TCP Sequence Number Encoding .......35
                  6.4.8.2. Scaled Acknowledgment Number Encoding .....35
      6.5. Encoding Methods with External Parameters .................36
   7. Packet Types (Normative) .......................................38
      7.1. Initialization and Refresh (IR) Packets ...................38
      7.2. Context Replication (IR-CR) Packets .......................40
      7.3. Compressed (CO) Packets ...................................42
   8. Header Formats (Normative) .....................................43
      8.1. Design Rationale for Compressed Base Headers ..............44
      8.2. Formal Definition of Header Formats .......................47
      8.3. Feedback Formats and Options ..............................88
           8.3.1. Feedback Formats ...................................88
           8.3.2. Feedback Options ...................................89
                  8.3.2.1. The REJECT Option .........................89
                  8.3.2.2. The MSN-NOT-VALID Option ..................90
                  8.3.2.3. The MSN Option ............................90
                  8.3.2.4. The CONTEXT_MEMORY Feedback Option ........91
                  8.3.2.5. Unknown Option Types ......................91
   9. Changes from RFC 4996 ..........................................91
      9.1. Functional Changes ........................................91
      9.2. Non-functional Changes ....................................92
   10. Security Considerations .......................................92
   11. IANA Considerations ...........................................93
   12. Acknowledgments ...............................................93
   13. References ....................................................93
      13.1. Normative References .....................................93
      13.2. Informative References ...................................94
Top   ToC   RFC6846 - Page 5

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 selective acknowledgments (SACK) ([RFC2018], [RFC2883]) and Timestamps ([RFC1323]). TCP options that may be less frequently used do not necessarily need to be compressed by the protocol, and instead can be passed transparently without reducing the overall compression efficiency of other parts of the TCP header. The Robust Header Compression (ROHC) Working Group 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 [RFC5795], 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.

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 [RFC5795]. In addition, this document uses or defines the following terms:
Top   ToC   RFC6846 - Page 6
   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

      The Base header is 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.

   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.
Top   ToC   RFC6846 - Page 7

3. Background

This section provides some background information on TCP/IP header compression. The fundamentals of general header compression can be found in [RFC5795]. 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 [RFC5681] 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. 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.
Top   ToC   RFC6846 - Page 8
   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) - 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
Top   ToC   RFC6846 - Page 9
   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
   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.
Top   ToC   RFC6846 - Page 10
   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],
   Generic Routing Encapsulation (GRE) [RFC2784][RFC2890], and the
   Minimal Encapsulation (MINE) header [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 [RFC5795]. 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. 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.
Top   ToC   RFC6846 - Page 11

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 acknowledgments (ACKs) or negative acknowledgments (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.

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).
Top   ToC   RFC6846 - Page 12
   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. 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.
Top   ToC   RFC6846 - Page 13
   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.



(page 13 continued on part 2)

Next Section