Robust Header Compression G. Pelletier
Internet-Draft L. Jonsson
Expires: December 21, 2006 K. Sandlund
Ericsson
M. West
Siemens/Roke Manor
June 19, 2006
RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
draft-ietf-rohc-tcp-12.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a ROHC (Robust Header Compression) profile
for compression of TCP/IP packets. The profile, called ROHC-TCP, is
a robust header compression scheme for TCP/IP that provides high
compression efficiency combined with high robustness. ROHC-TCP also
provides enhanced capabilities for compression of frequently used TCP
Pelletier, et al. Expires December 21, 2006 [Page 1]
Internet-Draft ROHC-TCP June 2006
options (such as SACK (Selective Acknowledgments) and Timestamps
compared to previous TCP/IP header compression schemes.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Existing TCP/IP Header Compression Schemes . . . . . . . . 6
3.2. Classification of TCP/IP Header Fields . . . . . . . . . . 7
4. Overview of the TCP/IP Profile (Informative) . . . . . . . . . 9
4.1. General Concepts . . . . . . . . . . . . . . . . . . . . . 9
4.2. Compressor and Decompressor Interactions . . . . . . . . . 9
4.2.1. Compressor Operation . . . . . . . . . . . . . . . . . 9
4.2.2. Decompressor Feedback . . . . . . . . . . . . . . . . 10
4.3. Packet Formats and Encoding Methods . . . . . . . . . . . 11
4.3.1. TCP Options . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. Compressing Extension Headers . . . . . . . . . . . . 11
4.4. Expected Compression Ratios with ROHC-TCP . . . . . . . . 11
5. Compressor and Decompressor Logic (Normative) . . . . . . . . 12
5.1. Context Initialization . . . . . . . . . . . . . . . . . . 12
5.2. Compressor Operation . . . . . . . . . . . . . . . . . . . 13
5.2.1. Compression Logic . . . . . . . . . . . . . . . . . . 13
5.2.2. Feedback Logic . . . . . . . . . . . . . . . . . . . . 14
5.2.3. Context Replication . . . . . . . . . . . . . . . . . 15
5.3. Decompressor Operation . . . . . . . . . . . . . . . . . . 15
5.3.1. Decompressor States and Logic . . . . . . . . . . . . 15
5.3.2. Reconstruction and Verification . . . . . . . . . . . 17
5.3.3. Feedback Logic . . . . . . . . . . . . . . . . . . . . 18
5.3.4. Context Replication . . . . . . . . . . . . . . . . . 19
6. Encodings in ROHC-TCP (Normative) . . . . . . . . . . . . . . 19
6.1. Control Fields in ROHC-TCP . . . . . . . . . . . . . . . . 19
6.1.1. Master Sequence Number (MSN) . . . . . . . . . . . . . 19
6.1.2. IP-ID Behavior . . . . . . . . . . . . . . . . . . . . 20
6.1.3. Explicit Congestion Notification (ECN) . . . . . . . . 20
6.2. Compressed Header Chains . . . . . . . . . . . . . . . . . 21
6.3. Compressing TCP Options with List Compression . . . . . . 22
6.3.1. List Compression . . . . . . . . . . . . . . . . . . . 22
6.3.2. Table-based Item Compression . . . . . . . . . . . . . 23
6.3.3. Encoding of Compressed Lists . . . . . . . . . . . . . 24
6.3.4. Item Table Mappings . . . . . . . . . . . . . . . . . 25
6.3.5. Compressed Lists in Dynamic Chain . . . . . . . . . . 27
6.3.6. Irregular Chain Items for TCP Options . . . . . . . . 27
Pelletier, et al. Expires December 21, 2006 [Page 2]
Internet-Draft ROHC-TCP June 2006
6.3.7. Replication of TCP Options . . . . . . . . . . . . . . 27
6.4. Profile-specific Encoding Methods . . . . . . . . . . . . 28
6.4.1. inferred_ip_v4_header_checksum . . . . . . . . . . . . 28
6.4.2. inferred_mine_header_checksum . . . . . . . . . . . . 28
6.4.3. inferred_ip_v4_length . . . . . . . . . . . . . . . . 29
6.4.4. inferred_ip_v6_length . . . . . . . . . . . . . . . . 29
6.4.5. inferred_offset . . . . . . . . . . . . . . . . . . . 30
6.4.6. baseheader_extension_headers . . . . . . . . . . . . . 30
6.4.7. baseheader_outer_headers . . . . . . . . . . . . . . . 31
6.4.8. Scaled TCP Sequence Number Encoding . . . . . . . . . 31
6.4.9. Scaled Acknowledgment Number Encoding . . . . . . . . 32
6.5. CRC Calculations . . . . . . . . . . . . . . . . . . . . . 33
7. Packet Types (Normative) . . . . . . . . . . . . . . . . . . . 33
7.1. Initialization and Refresh Packets (IR) . . . . . . . . . 33
7.2. Context Replication Packets (IR-CR) . . . . . . . . . . . 35
7.3. Compressed Packets (CO) . . . . . . . . . . . . . . . . . 37
8. Packet Formats (Normative) . . . . . . . . . . . . . . . . . . 38
8.1. Design rationale for compressed base headers . . . . . . . 38
8.2. Formal Definition in ROHC-FN . . . . . . . . . . . . . . . 41
8.3. Feedback Formats and Options . . . . . . . . . . . . . . . 83
8.3.1. Feedback Formats . . . . . . . . . . . . . . . . . . . 83
8.3.2. Feedback Options . . . . . . . . . . . . . . . . . . . 84
9. Security Consideration . . . . . . . . . . . . . . . . . . . . 87
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 87
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
12.1. Normative References . . . . . . . . . . . . . . . . . . . 88
12.2. Informative References . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90
Intellectual Property and Copyright Statements . . . . . . . . . . 91
Pelletier, et al. Expires December 21, 2006 [Page 3]
Internet-Draft ROHC-TCP June 2006
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 RFC 2507 [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 (RFC 1144 [RFC1144], RFC 2507 [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
point 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 (RFC 2018
[RFC2018], RFC 2883 [RFC2883]) and Timestamps (RFC 1323 [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 [RFC3095], compliant with
the requirements on ROHC TCP/IP header compression [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 RFC 2119 [RFC2119].
This document reuses some of the terminology found in RFC 3095
[RFC3095]. 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 CID
Pelletier, et al. Expires December 21, 2006 [Page 4]
Internet-Draft ROHC-TCP June 2006
The Base Context Identifier is the CID used to identify the Base
Context, where information needed for context replication can be
extracted from.
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 e.g. each
header 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.
CRC-8 validation
The CRC-8 validation refers to the validation of the integrity
against bit error(s) of the received IR, the IR-DYN or the IR-CR
header, using the 8-bit CRC that is included in the header.
CRC verification
The CRC verification refers to the verification of the result of a
decompression attempt, using the 3-bit CRC or 7-bit CRC included
in the header of a compressed packet format (CO).
ROHC Context Replication (ROHC-CR)
"ROHC-CR" in this document normatively refers to the context
replication mechanism for ROHC profiles defined in [RFC4164].
ROHC Formal Notation (ROHC-FN)
"ROHC-FN" in this document normatively refers to the formal
notation for ROHC profiles, as defined in [ROHC-FN], including the
library of encoding methods it specifies.
ROHC-TCP packet types
Pelletier, et al. Expires December 21, 2006 [Page 5]
Internet-Draft ROHC-TCP June 2006
ROHC-TCP uses two different packet types: the Initialization and
Refresh (IR) packet type, and the Compressed packet type (CO).
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 [RFC3095]. In the following sub-sections, 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.
The behavior analysis of TCP/IP header fields among multiple short-
lived connections may be 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 large overhead of the TCP/IP header.
The CTCP (RFC 1144 [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 (RFC 2001) from being triggered. In such case,
the compressor must wait until the TCP timeout to resynchronize.
To reduce the errors due to the inconsistent contexts between
compressor and decompressor when compressing TCP, IPHC (RFC 2507
[RFC2507]) improves somewhat on CTCP by augmenting the repair
mechanism of CTCP with a local repair mechanism called TWICE and with
a link layer nacking mechanism to request a header that updates the
context.
The TWICE algorithm assumes that only the Sequence number field of
Pelletier, et al. Expires December 21, 2006 [Page 6]
Internet-Draft ROHC-TCP June 2006
TCP segments are 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 time.
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
+ Maximum Segment Size (32 bits) - MSS
+ Window Scale (24 bits) - WSCALE
Pelletier, et al. Expires December 21, 2006 [Page 7]
Internet-Draft ROHC-TCP June 2006
+ SACK Permitted (16 bits)
+ TCP SACK (80, 144, 208 or 272 bits) - SACK
+ TCP Timestamp (80 bits) - TS
The assignment of IP-ID values can be done in various ways, most
usually one of sequential, sequential jump, random or constant to a
value of zero. 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. In RFC 3095 [RFC3095], the IP-ID is generally inferred from
the RTP Sequence number. However, with respect to TCP compression,
the analysis in [RFC4413] reveals that there is no obvious candidate
to this purpose among the TCP fields.
The change pattern of several TCP fields (Sequence number,
Acknowledgment number, Window, etc.) is very hard to predict and
differs entirely from the behavior of RTP fields discussed in
[RFC3095]. Of particular importance to a TCP/IP header compression
scheme is the understanding of the sequence and acknowledgment number
[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 FTP 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 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.
Pelletier, et al. Expires December 21, 2006 [Page 8]
Internet-Draft ROHC-TCP June 2006
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. All header fields and related context values
have been classified in detail in [RFC4413]; the conclusion is that
most part of the IP sub-context, some TCP fields, and some context
values can easily 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], AH [RFC4302], NULL-encrypted ESP header
[RFC4303], GRE [RFC2784][RFC2890] and the Minimal Encapsulation
header (MINE) [RFC2004] (i.e. the same headers as those compressed by
RFC 3095 [RFC3095]). Headers specific to Mobile IP (for IPv4 or
IPv6) do not receive any special treatment in this document, for
reasons similar as those described in [RFC3095].
4. Overview of the TCP/IP Profile (Informative)
4.1. General Concepts
Many of the concepts behind the ROHC-TCP profile are similar to those
described in RFC 3095 [RFC3095]. Like for other ROHC profiles, ROHC-
TCP makes use of the ROHC protocol as described in [RFC3095], in
sections 5.1 to 5.2.6. This includes data structures, reserved
packet types, general packet formats, segmentation and initial
decompressor processing.
In addition, ROHC-TCP supports context replication as defined in
ROHC-CR [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
Pelletier, et al. Expires December 21, 2006 [Page 9]
Internet-Draft ROHC-TCP June 2006
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 packets (CO) 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 feedback (ACKs) or negative feedback
(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 increasing the compression efficiency by
providing the information needed for the compressor to achieve the
necessary confidence level.
To parallel RFC 3095 [RFC3095], this is similar to allowing only one
mode transition per compressor: from the initial unidirectional mode
to the bi-directional mode of operation, with the transition being
triggered by the reception of the first packet containing feedback
from the decompressor. This effectively means that ROHC-TCP does not
explicitly define any operational modes.
The ROHC-TCP feedback mechanism is limited in its applicability by
the number of MSN (LSB coded) bits used in the FEEDBACK-2 format. It
is not suitable for a decompressor to use feedback altogether where
the MSN bits in the feedback could wraparound under one round-trip
time (RTT). Instead, unidirectional operation -- where the
compressor periodically sends larger context updating packets -- is
more appropriate.
Pelletier, et al. Expires December 21, 2006 [Page 10]
Internet-Draft ROHC-TCP June 2006
4.3. Packet Formats and Encoding Methods
The packet formats used for ROHC-TCP are defined using the formal
notation, ROHC-FN. The formal notation is used to provide an
unambiguous representation of the packet formats and a clear
definition of the encoding methods. The encoding methods used in the
packet formats for ROHC-TCP are defined in [ROHC-FN].
4.3.1. TCP Options
The TCP options in ROHC-TCP are compressed using a downscaled version
of the list compression in [RFC3095], allowing 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
In RFC 3095 [RFC3095], list compression is used to compress extension
headers. ROHC-TCP compresses the same type of extension headers as
in [RFC3095]. However, 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.
The consequence is 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 assumes 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 NOP options for padding and/or alignment.
Finally, in the examples for IPv4, a sequential IP-ID behavior is
assumed.
Pelletier, et al. Expires December 21, 2006 [Page 11]
Internet-Draft ROHC-TCP June 2006
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 a ROHC ACK has reached the
compressor before the second packet is being compressed, which can be
expected when using bidirectional ROHC-TCP operation; 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)
The header compression logic as described in this section is a
simplified version of the one found in [RFC3095].
5.1. Context Initialization
The static context of ROHC TCP flows can be initialized in either of
two ways:
Pelletier, et al. Expires December 21, 2006 [Page 12]
Internet-Draft ROHC-TCP June 2006
1. By using an IR packet as in Section 7.1, where the profile is six
(6) and the static chain ends with the static part of a TCP
header.
2. By replicating an existing context using the mechanism defined by
ROHC-CR. This is done with the IR-CR packet defined in
Section 7.2, where the profile number is six (6).
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;
o The compressor's level of confidence regarding decompressor state,
e.g. by using an optimistic approach through repetition of context
updates or from the reception of decompressor feedback (ACKs
and/or NACKs);
o Additional robustness required for the flow, e.g. periodic
repetition 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 more in 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
When ROHC-TCP is used over lossy links, all information needs to be
repeated by the compressor until it is fairly confident that the
decompressor has received the information contained in the packet.
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
Pelletier, et al. Expires December 21, 2006 [Page 13]
Internet-Draft ROHC-TCP June 2006
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 sending periodic
refreshes.
5.2.2. Feedback Logic
The compressor makes use of the feedback from the decompressor to
move to a lower compression state (NACKs), and optionally to move to
a higher compression state (ACKs).
5.2.2.1. Optional Acknowledgments (ACKs)
The compressor MAY optionally 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)
Negative acknowledgments (NACKs or STATIC-NACKs) are also called
error recovery requests and indicate that the all or parts of the
decompressor context has been invalidated.
On reception of a NACK feedback, the compressor SHOULD:
o assume that only the static part of the decompressor is valid, and
Pelletier, et al. Expires December 21, 2006 [Page 14]
Internet-Draft ROHC-TCP June 2006
o re-send all dynamic information (via an IR or IR-DYN packet) next
time it compresses a packet for the indicated flow
unless it has confidence that information sent after the packet that
is being acknowledged already provides a suitable response to the
error recovery request.
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)
next time it compresses a packet for the indicated flow.
unless it has confidence that information sent after the packet that
is being acknowledged already provides a suitable response to the
error recovery request.
5.2.3. Context Replication
A compressor MAY support context replication by implementing the
additional compression and feedback logic defined in ROHC-CR
[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
sub-sections following the figure.
Pelletier, et al. Expires December 21, 2006 [Page 15]
Internet-Draft ROHC-TCP June 2006
Success
+-->------>------>------>------>------>--+
| |
No Static | No Dynamic Success | Success
+-->--+ | +-->--+ +--->----->---+ +-->--+
| | | | | | | | |
| v | | v | v | v
+-----------------+ +---------------------+ +-------------------+
| No Context (NC) | | Static Context (SC) | | Full Context (FC) |
+-----------------+ +---------------------+ +-------------------+
^ | ^ |
| Static Context Damage | | Context Damage |
+-----<------<------<-----+ +-----<------<------<-----+
5.3.1.1. 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 be discarded.
Feedback logic:
In the NC state, the decompressor SHOULD send a STATIC-NACK if a
packet of a type other than one for which decompression is allowed
is received, or if an IR packet has failed the CRC-8 validation.
Once a packet has been validated and decompressed correctly, the
decompressor MUST transit to the FC state.
5.3.1.2. 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. How the decompressor detects
static context damage should be based on the residual error rate,
where a low error rate should make the decompressor assume damage
more often than on a link with a higher error rate.
Allowing decompression:
Pelletier, et al. Expires December 21, 2006 [Page 16]
Internet-Draft ROHC-TCP June 2006
In the SC state, only packets carrying sufficient information on
the dynamic fields covered by an 8-bit CRC can be decompressed
(e.g. IR and IR-DYN); otherwise the packet is of type CO and it
MUST be discarded.
Feedback logic:
In the SC state, the decompressor SHOULD send a STATIC-NACK when
an IR or an IR-DYN packet fails the CRC-8 validation. If a CO
packet type is received, the decompressor SHOULD treat it as a CRC
mismatch when deciding if a NACK is to be sent.
Once a packet has been validated and decompressed correctly, the
decompressor MUST transit to the FC state.
5.3.1.3. Full Context (FC) State
In the Full Context (FC) state, both the static and the dynamic parts
of the decompressor context are valid. The decompressor moves back
to the SC state if context damage is detected. How the decompressor
detects context damage should be based on the residual error rate,
where a low error rate should make the decompressor assume damage
more often than on a link with a higher error rate. The decompressor
may send feedback, as described below, when assuming context damage.
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 when
decompression of any packet type fails and if context damage is
assumed.
5.3.2. Reconstruction and Verification
When decompression of an IR or an IR-DYN packet is allowed, the
decompressor MUST validate the integrity of the received header using
CRC-8 validation: the decompressor computes the 8-bit CRC according
to the type of the received header, and then compares the result with
the 8-bit CRC carried in the header. If the two are identical, the
decompressor reconstructs the original header. Otherwise the packet
MUST be discarded without further processing.
Upon receiving an IR-CR packet, the decompressor MUST perform the
actions as specified in [RFC4164].
Pelletier, et al. Expires December 21, 2006 [Page 17]
Internet-Draft ROHC-TCP June 2006
When decompression of other packet types is allowed (CO packets), the
decompressor MUST check the outcome of the decompression attempt
using CRC verification: the decompressor computes the 3-bit CRC or
the 7-bit CRC over the reconstructed header, and then compares the
result with the corresponding CRC carried in the received header. If
the two are identical, the decompression attempt is successful. If
they are not identical, decompressor implementations 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 be discarded without further processing.
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
(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.
If a feedback channel is available, the decompressor MAY use positive
feedback (ACKs) to acknowledge successful decompression of packets.
5.3.3. 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. The decompressor MUST then use the feedback channel to
send error recovery requests and (optionally) acknowledgments of
significant context updates.
Once the feedback channel is established, the decompressor is
REQUIRED to continue sending error recovery requests (i.e. 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 optionally send ACKs upon successful
decompression of any packet type. In particular, when an IR, an IR-
DYN or any CO packet carrying a significant context update is
correctly decompressed, the decompressor MAY optionally send an ACK.
Pelletier, et al. Expires December 21, 2006 [Page 18]
Internet-Draft ROHC-TCP June 2006
5.3.4. Context Replication
ROHC-TCP supports context replication, therefore the decompressor
MUST implement the additional decompressor and feedback logic defined
in ROHC-CR [RFC4164].
6. Encodings in ROHC-TCP (Normative)
This section describes a ROHC profile for TCP/IP compression. The
profile identifier for ROHC-TCP is 0x0006.
6.1. Control Fields in ROHC-TCP
In ROHC-TCP, a number of control fields are used by the decompressor
in its interpretation of the packet formats for packets received from
the compressor.
A control field is a field that is transmitted from the compressor to
the decompressor, but is not part of the uncompressed header. Values
for control fields can be set up in the context of both the
compressor and the decompressor. Once established at the
decompressor, the values of these fields should be kept until updated
by another packet.
6.1.1. Master Sequence Number (MSN)
There is no field in the TCP header that can act as the master
sequence number for TCP compression, as explained in [RFC4413],
section 5.6.
To overcome this problem, ROHC-TCP introduces a control field called
the Master Sequence Number (MSN) field. The MSN field is created at
the compressor, rather than using one of the fields already present
in the uncompressed header. The compressor increments the value of
the MSN by one for each packet that it sends.
The MSN field has the following two functions:
1. Differentiating between packets when sending feedback data.
2. Inferring the value of incrementing fields such as the IP-ID.
The MSN field is present in every packet sent by the compressor. The
MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent
in full in IR/IR-DYN packets. The decompressor always sends the MSN
as part of the feedback information. The compressor can later use
the MSN to infer which packet the decompressor is acknowledging.
Pelletier, et al. Expires December 21, 2006 [Page 19]
Internet-Draft ROHC-TCP June 2006
When the MSN is initialized, it SHOULD be initialized to a random
value. The compressor should only initialize a new MSN for the
initial IR or IR-CR packet sent for a CID that corresponds to a
context that is not already associated with this profile. In other
words, if the compressor reuses the same CID to compress many TCP
flows one after the other, the MSN is not reinitialized but rather
continues to increment monotonically.
For context replication, the compressor does not use the MSN of the
base context when sending the IR-CR packet, unless the replication
process overwrites the base context (i.e. BCID == CID). Instead,
the compressor uses the value of the MSN if it already exists in the
ROHC-TCP context being associated with the new flow (CID); otherwise,
the MSN is initialized to a new value.
6.1.2. IP-ID Behavior
The IP-ID field of the IPv4 header can have different change
patterns. RFC 3095 [RFC3095] describes three behaviors: sequential
(NBO), sequential byte-swapped, and random (RND). In addition, this
profile uses a fourth behavior, the constant zero IP-ID behavior as
defined in RFC 3843 [RFC3843], Section 3.3.
The compressor monitors changes in the value of the IP-ID field for a
number of packets, to identify which one of the above listed behavior
is the closest match to the observed change pattern. The compressor
can then select packet formats based on the identified field
behavior.
If more than one level of IP headers is present, ROHC-TCP can assign
a sequential behavior (NBO or byte-swapped) only to the IP-ID of
innermost IP header. This is because only this IP-ID can possibly
have a sufficiently close correlation with the MSN (see also
Section 6.1.1) to compress it as a sequentially changing field.
Therefore, a compressor MUST assign either the constant zero IP-ID or
the random IP-ID behavior to tunneling headers.
The control field for the IP-ID behavior determines which set of
packet formats will be used. Note that these control fields are also
used to determine the contents of the irregular chain item for each
IP header.
6.1.3. Explicit Congestion Notification (ECN)
When ECN [RFC3168] is used once on a flow, it can be expected that
the ECN bits will change quite often. ROHC-TCP maintains a control
field in the context to indicate if ECN is used or not. This control
field is transmitted in the dynamic chain of the TCP header, and its
Pelletier, et al. Expires December 21, 2006 [Page 20]
Internet-Draft ROHC-TCP June 2006
value can be updated using specific compressed headers carrying a
7-bit CRC.
When this control field indicates that ECN is being used, items of IP
and TCP headers in the irregular chain will include bits used for
ECN. To preserve octet-alignment, all of the TCP reserved bits are
transmitted and, for outer IP headers, the entire TOS/TC field is
included in the irregular chain.
The design rationale behind this is the possible use of the "full-
functionality option" of section 9.1 of RFC 3168 [RFC3168].
6.2. Compressed Header Chains
Some packet types use one or more chains containing sub-header
information. The function of a chain is to group fields based on
similar characteristics, such as static, dynamic or irregular fields.
Chaining is done by appending an item for each header to the chain in
their order of appearance in the uncompressed packet, starting from
the fields in the outermost header. Chains are defined for all
headers compressed by ROHC-TCP (i.e. TCP [RFC0793], IPv4 [RFC0791],
IPv6 [RFC2460], AH [RFC4302], GRE [RFC2784][RFC2890], MINE [RFC2004],
NULL-encrupted ESP [RFC4303], IPv6 Destination Options
header[RFC2460], IPv6 Hop-by-hop Options header[RFC2460] and IPv6
Routing header [RFC2460].
Static chain:
The static chain consists of one item for each header of the chain
of protocol headers to be compressed, starting from the outermost
IP header and ending with a TCP header. In the formal description
of the packet formats, this static chain item for each header type
is labelled <protocol_name>_static. The static chain is only used
in IR packets.
Dynamic chain:
The dynamic chain consists of one item for each header of the
chain of protocol headers to be compressed, starting from the
outermost IP header and ending with a TCP header. It should be
noted that the dynamic chain item for the TCP header also contains
a compressed list of TCP options (see Section 6.3). In the formal
description of the packet formats, the dynamic chain item for each
header type is labelled <protocol_name>_dynamic. The dynamic
chain is used both in IR and IR-DYN packets.
Pelletier, et al. Expires December 21, 2006 [Page 21]
Internet-Draft ROHC-TCP June 2006
Replicate chain:
The replicate chain consists of one item for each header in the
chain of protocol headers to be compressed, starting from the
outermost IP header and ending with a TCP header. It should be
noted that the replicate chain item for the TCP header also
contains a compressed list of TCP options (see Section 6.3). In
the formal description of the packet formats, this replicate chain
item for each header type is labelled <protocol_name>_replicate.
Header fields that are not present in the replicate chain are
replicated from the base context. The replicate chain is only
used in the IR-CR packet.
Irregular chain:
The structure of the irregular chain is analogous to the structure
of the static chain. For each compressed packet, the irregular
chain is appended at the specified location in the general format
of the compressed packets as defined in Section 7.3. This chain
also includes the irregular chain items for TCP options as defined
in Section 6.3.6. The irregular chain is used for all CO packets.
The format of the irregular chain for the innermost IP header
differs from the format of outer IP headers, since this header is
a part of the compressed base header. Which of these irregular
chain items to use is decided by the argument "is_innermost" which
is passed to the corresponding encoding method (ipv4 or ipv6).
The format of the irregular chain item for the outer IP headers is
also determined using a flag for TTL/Hop Limit; this flag is
defined in the format of some of the compressed base headers.
6.3. Compressing TCP Options with List Compression
This section describes in details how list compression is applied to
the TCP options. In the definition of the packet formats for ROHC-
TCP, the most frequent type of TCP options are described. Each of
these options has an uncompressed format, a <option_type>_list_item
format and a <option_type>_irregular format, where <option_type> is
the name of the option type in the option list.
6.3.1. List Compression
The TCP options in the uncompressed packet can be represented as an
ordered list, whose order and presence are usually constant between
packets. The generic structure of such a list is as follows:
+--------+--------+--...--+--------+
list: | item 1 | item 2 | | item n |
Pelletier, et al. Expires December 21, 2006 [Page 22]
Internet-Draft ROHC-TCP June 2006
+--------+--------+--...--+--------+
The basic principles of list-based compression are the following:
1) When a context is being initialized, a complete representation
of the compressed list of options is transmitted. All options
that have any content are present in the compressed list of items
sent by the compressor.
Then, once the context has been initialized:
2) When the structure AND the content of the list are unchanged,
no information about the list is sent in compressed headers.
3) When the structure of the list is constant, and when only the
content defined within the irregular format for one or more
options is changed, no information about the list needs to be sent
in compressed headers; the irregular content is sent as part of
the irregular chain (as described in Section 6.3.6 in the general
compressed packet format (Section 7.3).
4) When the structure of the list changes, a compressed list is
sent in the compressed header, including a representation of its
structure and order.
6.3.2. Table-based Item Compression
The Table-based item compression compresses individual items sent in
compressed lists. The compressor assigns a unique identifier,
"Index", to each item "Item" of a list.
Compressor Logic
The compressor conceptually maintains an Item Table containing all
items, indexed using "Index". The (Index, Item) pair is sent
together in compressed lists until the compressor gains enough
confidence that the decompressor has observed the mapping between
items and their respective index. Confidence is obtained from the
reception of an acknowledgment from the decompressor, or by
sending (Index, Item) pairs using the optimistic approach. Once
confidence is obtained, the index alone is sent in compressed
lists to indicate the presence of the item corresponding to this
index.
The compressor may reassign an existing index to a new item, by
re-establishing the mapping using the procedure described above.
Decompressor Logic
Pelletier, et al. Expires December 21, 2006 [Page 23]
Internet-Draft ROHC-TCP June 2006
The decompressor conceptually maintains an Item Table that
contains all (Index, Item) pairs received. The Item Table is
updated whenever an (Index, Item) pair is received and
decompression is successfully verified using the CRC. The
decompressor retrieves the item from the table whenever an Index
without an accompanying Item is received.
If an index without an accompanying item is received and the
decompressor does not have any context for this index, the header
MUST be discarded and a NACK SHOULD be sent.
6.3.3. Encoding of Compressed Lists
Each item present in a compressed list is represented by:
o an index into the table of items, and
o a presence bit indicating if a compressed representation of the
item is present in the list.
o an item (if the presence bit is set)
If the presence bit is not set, the item must already be known by the
decompressor.
A compressed list of TCP options uses the following encoding:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Reserved |PS | m |
+---+---+---+---+---+---+---+---+
| XI_1, ..., XI_m | m octets, or m * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and m is odd
+---+---+---+---+---+---+---+---+
| |
/ item_1, ..., item_n / variable
| |
+---+---+---+---+---+---+---+---+
Reserved: Must be set to zero.
PS: Indicates size of XI fields:
PS = 0 indicates 4-bit XI fields;
PS = 1 indicates 8-bit XI fields.
m: Number of XI item(s) in the compressed list.
Pelletier, et al. Expires December 21, 2006 [Page 24]
Internet-Draft ROHC-TCP June 2006
XI_1, ..., XI_m: m XI items. Each XI represents one TCP option in
the uncompressed packet, in the same order as they appear in the
uncompressed packet.
The format of an XI item is as follows:
+---+---+---+---+
PS = 0: | X | Index |
+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
PS = 1: | X | Reserved | Index |
+---+---+---+---+---+---+---+---+
X: Indicates whether the item present in the list:
X = 1 indicates that the item corresponding to the Index is
sent in the item_1, ..., item_n list;
X = 0 indicates that the item corresponding to the Index is
not sent.
Reserved: Set to zero when sending, ignored when received.
Index: An index into the item table. See Section 6.3.4
When 4-bit XI items are used and, the XI items are placed in
octets in the following manner:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| XI_k | XI_k + 1 |
+---+---+---+---+---+---+---+---+
Padding: A 4-bit padding field is present when PS = 0 and the
number of XIs is odd. The Padding field is set to zero when
sending and ignored when receiving.
Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
XI 1, ..., XI m. Each entry in the item list is formatted as
expressed by <option_type>_list_item in Section 8.
6.3.4. Item Table Mappings
The item table for TCP options list compression is limited to 16
Pelletier, et al. Expires December 21, 2006 [Page 25]
Internet-Draft ROHC-TCP June 2006
different items, since it is unlikely that any packet flow will
contain a larger number of unique options.
The mapping between TCP option type and table indexes are listed in
the table below:
+-----------------+---------------+
| Option name | Table index |
+-----------------+---------------+
| NOP | 0 |
| EOL | 1 |
| MSS | 2 |
| WINDOW SCALE | 3 |
| TIMESTAMP | 4 |
| SACK-PERMITTED | 5 |
| SACK | 6 |
| Generic options | 7-15 |
+-----------------+---------------+
Some TCP options are used more frequently than others. To simplify
their compression, a part of the item table is reserved for these
option types, as shown on the table above. Both the compressor and
the decompressor MUST use these mappings between item and indexes to
(de)compress TCP options compressed using list compression.
It is expected that the option types for which an index is reserved
in the item table will only appear once in a list. However, if an
option type is detected twice in the same options list and if both
options have a different content, the compressor should compress the
second occurrence of the option type by mapping it to a generic
compressed option. Otherwise, if the options have the exact same
content, the compressor can still use the same table index for both.
The NOP option
The NOP option can appear more than once in the list. However,
since its value is always the same, no context information needs
to be transmitted. Multiple NOP options can thus be mapped to the
same index. Since the NOP option does not have any content when
compressed as a list_item, it will never be present in the item
list. For consistency, the compressor should still establish an
entry in the list by setting the presence bit, as done for the
other type of options.
List compression always preserves the original order of each item
in the decompressed list, no matter if the item is present or not
in the compressed list_item or if multiple items of the same type
can be mapped to the same index, as for the NOP option.
Pelletier, et al. Expires December 21, 2006 [Page 26]
Internet-Draft ROHC-TCP June 2006
The EOL option
The size of the compressed format for the EOL option can be larger
than one octet, and it is defined so that it includes the option
padding. This is because the EOL should terminate the parsing of
the options, but it can also be followed by padding octets that
all have the value zero.
The Generic option
The generic option can be used to compress any type of TCP option
that does not have a reserved index in the item table.
6.3.5. Compressed Lists in Dynamic Chain
A compressed list for TCP options that is part of the dynamic chain
(e.g. in IR or IR-DYN packets) must have all its list items present,
i.e. all X-bits in the XI list MUST be set.
6.3.6. Irregular Chain Items for TCP Options
The list_item represents the option inside the compressed item list,
and the irregular format is used for the option fields that are
expected to change with each packet. When an item of the specified
type is present in the current context, these irregular fields are
present in each compressed packet, as part of the irregular chain.
Since many of the TCP option types are not expected to change for the
duration of a flow, many of the irregular formats are empty.
The irregular chain for TCP options is structured analogously to the
structure of the TCP options in the uncompressed packet. If a
compressed list is present in the compressed packet, then the
irregular chain for TCP options MUST NOT contain irregular items for
the list items that are transmitted inside the compressed list (i.e.
items in the list that have the X-bit set in its XI). The items that
are not present in the compressed list, but are present in the
uncompressed list, MUST have their respective irregular items present
in the irregular chain.
6.3.7. Replication of TCP Options
The entire table of TCP options items is always replicated when using
the IR-CR packet. In the IR-CR packet, the list of options for the
new flow is also transmitted as a compressed list in the IR-CR
packet.
Pelletier, et al. Expires December 21, 2006 [Page 27]
Internet-Draft ROHC-TCP June 2006
6.4. Profile-specific Encoding Methods
This section defines encoding methods that are specific to this
profile. These methods are used in the formal definition of the
packet formats in Section 8.
6.4.1. inferred_ip_v4_header_checksum
This encoding method compresses the header checksum field of the IPv4
header. This checksum is defined in RFC 791 [RFC0791] as follows:
Header Checksum: 16 bits
A checksum on the header only. Since some header fields change
(e.g., time to live), this is recomputed and verified at each
point that the internet header is processed.
The checksum algorithm is:
The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header. For purposes
of computing the checksum, the value of the checksum field is
zero.
As described above, the header checksum protects individual hops from
processing a corrupted header. When almost all IP header information
is compressed away, and when decompression is verified by a CRC
computed over the original header for every compressed packet, there
is no point in having this additional checksum; instead it can be
recomputed at the decompressor side.
The "inferred_ip_v4_header_checksum" encoding method thus compresses
the IPv4 header checksum down to a size of zero bit, i.e. no bits are
transmitted in compressed headers for this field. Using this
encoding method, the decompressor infers the value of this field
using the computation above.
The compressor MAY use the header checksum to validate the
correctness of the header before compressing it, to avoid compressing
a corrupted header.
6.4.2. inferred_mine_header_checksum
This encoding method compresses the minimal encapsulation header
checksum. This checksum is defined in RFC 2004 [RFC2004] as follows:
Pelletier, et al. Expires December 21, 2006 [Page 28]
Internet-Draft ROHC-TCP June 2006
Header Checksum
The 16-bit one's complement of the one's complement sum of all
16-bit words in the minimal forwarding header. For purposes of
computing the checksum, the value of the checksum field is 0.
The IP header and IP payload (after the minimal forwarding
header) are not included in this checksum computation.
The "inferred_mine_header_checksum" encoding method compresses the
minimal encapsulation header checksum down to a size of zero bit,
i.e. no bits are transmitted in compressed headers for this field.
Using this encoding method, the decompressor infers the value of this
field using the above computation.
The motivations for inferring this checksum are similar to the ones
explained above in Section 6.4.1.
The compressor MAY use the minimal encapsulation header checksum to
validate the correctness of the header before compressing it, to
avoid compressing a corrupted header.
6.4.3. inferred_ip_v4_length
This encoding method compresses the total length field of the IPv4
header. The total length field of the IPv4 header is defined in RFC
791 [RFC0791] as follows:
Total Length: 16 bits
Total Length is the length of the datagram, measured in octets,
including internet header and data. This field allows the
length of a datagram to be up to 65,535 octets.
The "inferred_ip_v4_length" encoding method compresses the IPv4
header checksum down to a size of zero bit, i.e. no bits are
transmitted in compressed headers for this field. Using this
encoding method, the decompressor infers the value of this field by
counting in octets the length of the entire packet after
decompression.
6.4.4. inferred_ip_v6_length
This encoding method compresses the payload length field in the IPv6
header. This length field is defined in RFC 2460 [RFC2460] as
follows:
Pelletier, et al. Expires December 21, 2006 [Page 29]
Internet-Draft ROHC-TCP June 2006
Payload Length: 16-bit unsigned integer
Length of the IPv6 payload, i.e., the rest of the packet
following this IPv6 header, in octets. (Note that any
extension headers present are considered part of the payload,
i.e., included in the length count.)
The "inferred_ip_v6_length" encoding method compresses the payload
length field of the IPv6 header down to a size of zero bit, i.e. no
bits are transmitted in compressed headers for this field. Using
this encoding method, the decompressor infers the value of this field
by counting in octets the length of the entire packet after
decompression.
6.4.5. inferred_offset
This encoding method compresses the data offset field of the TCP
header.
The inferred_offset encoding method is used on the data offset field
of the TCP header. This field is defined in RFC 793 as:
Data Offset: 4 bits
The number of 32 bit words in the TCP Header. This indicates
where the data begins. The TCP header (even one including
options) is an integral number of 32 bits long.
The "inferred_offset" encoding method compresses the data offset
field of the TCP header down to a size of zero bit, i.e. no bits are
transmitted in compressed headers for this field. Using this
encoding method, the decompressor infers the value of this field by
first decompressing the TCP options list, and by then setting:
data offset = (options length / 4) + 5
Note: The equation above uses integer arithmetic.
6.4.6. baseheader_extension_headers
In CO packets (see Section 7.3), the innermost IP header and the TCP
header are combined to create a compressed base header. In some
cases the IP header will have a number of extension headers between
itself and the TCP header. In order to remain formally correct, the
base header must define some representation of these extension
headers, which is what this encoding method is used for. This
encoding method skips over all the extension headers and does not
encode any of the fields. Changed fields in these headers are
Pelletier, et al. Expires December 21, 2006 [Page 30]
Internet-Draft ROHC-TCP June 2006
encoded in the irregular chain.
6.4.7. baseheader_outer_headers
This encoding method, as well as the baseheader_extension_headers
encoding method described above, is needed for the specification to
remain formally correct. It is used in CO packets (see Section 7.3)
to describe tunneling IP headers and their respective extension
headers (i.e. all headers located before the innermost IP header).
This encoding method skips over all the fields in these headers and
does not perform any encoding. Changed fields in outer headers are
instead handled by the irregular chain.
6.4.8. Scaled TCP Sequence Number Encoding
For some TCP flows, such as data transfers, the payload size will be
constant over periods of time. For such flows, the TCP Sequence
number is bound to increase by multiples of the payload size between
packets. ROHC-TCP provides a method to use scaled compression of the
TCP sequence number to improve compression efficiency in such case.
When scaling the TCP Sequence number, the residue is the sequence
number offset from a multiple of the payload size. The precondition
for the compressor to start using this type of encoding is that the
compressor must be confident that the decompressor has received a
number of packets sufficient to establish the value of the residue of
the scaling function.
This confidence can be established by sending a number of packets
that are compressed using an unscaled representation of the sequence
number, when the payload size is constant. The compressor can then
start using the scaled sequence number encoding, where the sequence
number is first downscaled by the value of the payload size and then
LSB encoded.
When the compressor detects that the value of the residue has
changed, it MUST re-establish the residue value. This is done by
sending compressed packets that carry the sequence number compressed
using its unscaled representation until it is confident that the
decompressor has received the new value.
When the sequence number wraps around, the value of the residue of
the scaling function is likely to change, even when the payload size
remains constant. When this occurs, the compressor MUST reestablish
the new residue value using the unscaled representation of the
sequence number as described above.
The scaling function applied to the TCP sequence number does not use
Pelletier, et al. Expires December 21, 2006 [Page 31]
Internet-Draft ROHC-TCP June 2006
an explicit scaling factor, such as the TS_STRIDE used in RFC 3095
[RFC3095]. Instead, the payload size is used as the scaling factor;
as this value can be inferred from the length of the packet, there is
no need to transmit this field explicitly.
The expressions for compressing and decompressing the scaled sequence
number are specified in the definitions of the packet format
Section 8.2.
6.4.9. Scaled Acknowledgment Number Encoding
Similar to the pattern exhibited by the TCP Sequence number, the
expected increase in the TCP Acknowledgment number will often be a
multiple of the packet size. For the TCP Sequence number, the
compression scheme can use the payload size of the packets as a
scaling factor (see section 6.1.6 above).
For the TCP Acknowledgment number, the scaling factor depends on the
size of packets flowing in the opposite direction; this information
might not be available to the compressor/decompressor pair. For this
reason, ROHC-TCP uses an explicit scaling factor to compress the TCP
Acknowledgment number.
For the compressor to use the scaled acknowledgment number encoding,
it MUST first explicitly transmit the value of the scaling factor
(called ack_stride in the formal notation in section Section 8.2) to
the decompressor, using one of the packet types that can carry this
information. Once the value of the scaling factor is established,
before using this scaled encoding the compressor must have enough
confidence that the decompressor has successfully calculated the
residue of the scaling function for the acknowledgment number. This
is done the same way as for the scaled sequence number encoding (see
Section 6.4.8 above).
Once the compressor has gained enough confidence that both the value
of the scaling factor and the value of the residue have been
established in the decompressor, the compressor can start compressing
packets using the scaled representation of the acknowledgment number.
The compressor MUST NOT use the scaled acknowledgment number encoding
with the value of the scaling factor (ack_stride) set to zero.
The compressor MAY use the scaled acknowledgment number encoding;
what value it will use as the scaling factor is up to the compressor
implementation. In the case where there is a co-located decompressor
processing packets of the same TCP flow in the opposite direction,
the scaling factor for the acknowledgment numbers can be set to the
same value as the scaling factor of the TCP Sequence number used for
that flow.
Pelletier, et al. Expires December 21, 2006 [Page 32]
Internet-Draft ROHC-TCP June 2006
6.5. CRC Calculations
The 3-bit and 7-bit CRCs both cover the entire uncompressed header
chain. Note that there is no separation between CRC-STATIC or CRC-
DYNAMIC fields in ROHC-TCP, as opposed to profiles defined in
[RFC3095].
7. Packet Types (Normative)
ROHC-TCP uses two different packet types: the Initialization and
Refresh (IR) packet type, and the Compressed packet type (CO).
Each packet type defines a number of packet formats: three packet
formats are defined for the IR type, and two sets of eight base
header formats are defined for the CO type with one additional format
that is common to both sets.
7.1. Initialization and Refresh Packets (IR)
ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets
as defined in [RFC3095] (section 5.2.3. and 5.2.4. respectively).
Packet type: IR
This packet type communicates the static part and the dynamic part
of the context.
Pelletier, et al. Expires December 21, 2006 [Page 33]
Internet-Draft ROHC-TCP June 2006
For the ROHC-TCP IR packet, the value of the x bit MUST be set to
one. It has the following format:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 1 | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Static chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
CRC: 8-bit CRC, computed according to section 5.9.1 of [RFC3095].
Static chain: See Section 6.2.
Dynamic chain: See Section 6.2.
Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length.
Packet type: IR-DYN
This packet type communicates the dynamic part of the context.
Pelletier, et al. Expires December 21, 2006 [Page 34]
Internet-Draft ROHC-TCP June 2006
The ROHC-TCP IR-DYN packet has the following format:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
CRC: 8-bit CRC, computed according to section 5.9.1 of [RFC3095].
Dynamic chain: See Section 6.2.
Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length.
7.2. Context Replication Packets (IR-CR)
Context replication requires a dedicated IR packet format that
uniquely identifies the IR-CR packet for the ROHC-TCP profile. This
section defines the profile-specific part of the IR-CR packet
[RFC4164].
Packet type: IR-CR
This packet type communicates a reference to a base context along
with the static and dynamic parts of the replicated context that
differs from the base context.
The ROHC-TCP IR-CR packet follows the general format of the ROHC CR
packet, as defined in ROHC-CR [RFC4164], section 3.4.2. With
consideration to the extensibility of the IR packet type defined in
Pelletier, et al. Expires December 21, 2006 [Page 35]
Internet-Draft ROHC-TCP June 2006
RFC 3095 [RFC3095], the ROHC-TCP profile supports context replication
through the profile specific part of the IR packet. This is achieved
using the bit (x) left in the IR packet header for "Profile specific
information". For ROHC-TCP, this bit is defined as a flag indicating
whether this packet is an IR packet or an IR-CR packet. For the
ROHC-TCP IR-CR packet, the value of the x bit MUST be set to zero.
The ROHC-TCP IR-CR has the following format:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 0 | IR-CR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| B | CRC7 | 1 octet
+---+---+---+---+---+---+---+---+
: Reserved | Base CID : 1 octet, for small CID, if B=1
+---+---+---+---+---+---+---+---+
: :
/ Base CID / 1-2 octets, for large CIDs,
: : if B=1
+---+---+---+---+---+---+---+---+
| |
/ Replicate chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
B: B = 1 indicates that the Base CID field is present.
CRC: See [RFC4164].
Pelletier, et al. Expires December 21, 2006 [Page 36]
Internet-Draft ROHC-TCP June 2006
CRC7: The CRC over the original, uncompressed, header. This 7-bit
CRC is computed according section Section 6.5.
Reserved: MUST be set to zero when transmitting, decompressor MUST
verify that the value of this field is zero.
Base CID: CID of base context. Encoded according to [RFC4164],
Section 3.5.3.
Replicate chain: See Section 6.2.
Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length.
7.3. Compressed Packets (CO)
The ROHC-TCP CO packets communicate irregularities in the packet
header. All CO packets carry a CRC and can update the context.
The general format for a compressed TCP header is as follows:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID 1-15
+---+---+---+---+---+---+---+---+
| First octet of base header | (with type indication)
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ Remainder of base header / variable number of octets
+---+---+---+---+---+---+---+---+
: :
/ Irregular chain / variable
: :
--- --- --- --- --- --- --- ---
: :
/ TCP Options Irregular Part / variable
: :
--- --- --- --- --- --- --- ---
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
Base header: The compressed representation of the innermost IP header
and the TCP header in the uncompressed packet. The full set of base
headers are described in Section 8.
Pelletier, et al. Expires December 21, 2006 [Page 37]
Internet-Draft ROHC-TCP June 2006
Irregular chain: See Section 6.2.
TCP options irregular part: See Section 6.3.6.
Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length.
8. Packet Formats (Normative)
This section describes the set of compressed TCP/IP packet formats.
The normative description of the packet formats is given using a
formal notation, the ROHC-FN [ROHC-FN]. The formal description of
the packet formats specifies all of the information needed to
compress and decompress a header relative to the context.
In particular, the notation provides a list of all the fields present
in the uncompressed and compressed TCP/IP headers, and defines how to
map from each uncompressed packet to its compressed equivalent and
vice versa. See the ROHC-FN [ROHC-FN] for an explanation of the
formal notation itself, and for a description of the encoding methods
used to compress each of the fields in the TCP/IP header.
8.1. Design rationale for compressed base headers
The compressed packet formats are defined as two separate sets: one
set for the packets where the innermost IP header contains a
sequential IP-ID (either network byte order or byte swapped), and one
set for the packets without sequential IP-ID (either random, zero, or
no IP-ID).
These two sets of packet formats are referred to as the "sequential"
and the "random" set of packet format.
In addition, there is a common compressed packet that can be used
regardless of the type of IP-ID behavior. This common packet can
transmit rarely changing fields and also send the frequently changing
field coded in variable lengths. The common packet format can also
change the value of control fields such as IP-ID behavior and ECN
behavior.
All compressed base headers contain a 3-bit CRC, unless they update
control fields such as "ip_id_behavior" or "ecn_used" that affect the
interpretation of subsequent packets. Packets that can modify these
control fields will carry a 7-bit CRC instead.
The encoding methods used in the compressed base headers are based on
the following design criteria:
Pelletier, et al. Expires December 21, 2006 [Page 38]
Internet-Draft ROHC-TCP June 2006
o MSN
Since the MSN is a number generated by the compressor, it only
needs to be large enough to ensure robust operation and to
accommodate a small amount of reordering [RFC4163]. Therefore,
each compressed base header contains 4 bits of MSN and the LSB
offset value is set to p=4 to handle a reordering depth of up
to 4 packets. Additional guidance to improve performance when
a larger amount of reordering is possible can be found in
[RFC4224]
o TCP Sequence number
ROHC-TCP has the capability to handle bulk data transfers
efficiently, for which the sequence number is expected to
increase by about 1460 bytes (which can be represented by 11
bits). For the compressed base headers to handle
retransmissions (i.e. negative delta to the sequence number),
the LSB interpretation interval must handle negative offsets
about as large as positive offset, which means that one more
bit is needed.
Also, for ROHC-TCP to be robust to losses, two additional bits
are added to the LSB encoding of the sequence number. This
means that the base headers should contain at least 14 bits of
LSB-encoded sequence number when present. According to the
logic above, the LSB offset value p is set to be as large as
the positive offset, i.e. p = 2^(k-1)-1, where k is the number
of LSB-encoded bits that are transmitted in the base header.
o TCP Acknowledgment number
The design criterion for the acknowledgment number is similar
to that of the TCP Sequence number. However, often only every
other data packet is acknowledged, which means that the
expected delta value is twice as large as for sequence numbers.
Therefore, at least 15 bits of acknowledgment number should be
used in compressed base headers. Since the acknowledgment
number is expected to constantly increase, and the only
exception to this is packet reordering (either on the ROHC
channel [RFC3759] or prior to the compression point), the
negative offset for LSB encoding is set to be 1/4 of the total
interval, i.e. p = 2^(k-2)-1.
o TCP Window
The TCP Window field is expected to increase in increments of
similar size as the TCP Sequence number, and therefore the
design criterion for the TCP window has been to send at least
14 bits when used.
Pelletier, et al. Expires December 21, 2006 [Page 39]
Internet-Draft ROHC-TCP June 2006
o IP-ID
For the "sequential" set of packet formats, all the compressed
base headers contains LSB encoded IP-ID offset bits. The
requirement is that at least 3 bits of IP-ID should always be
present, but it is preferable to use 4 to 7 bits. When k=3,
p=1 and if k>3, then p=3 since the offset is expected to
increase most of the time.
Each set of packet formats contains eight different compressed base
headers. The reason for having this large number of packets is that
the TCP Sequence number, TCP Acknowledgment number, TCP Window and
MSN are frequently changing in a non-linear pattern.
The design of the packet formats is derived from the field behavior
analysis found in [RFC4413].
All of the compressed base headers transmit LSB-encoded MSN bits, the
push flag and a CRC, and in addition to this, all the base headers in
the sequential packet format set contains LSB encoded IP-ID bits.
The following packet formats exist in both the sequential and random
packet format sets:
o Format 1: This packet format transmits changes to the TCP Sequence
number and is expected to be used on the downstream of a data
transfer.
o Format 2: This packet format transmits the TCP Sequence number in
scaled form, and is expected to be used on the downstream of a
data transfer where the payload size is constant for multiple
packets.
o Format 3: This packet format transmits changes in the TCP
Acknowledgment number, and is expected to be used in the
acknowledgment direction of data transfer.
o Format 4: This packet format is similar to format 3, but sends a
scaled TCP Acknowledgment number.
o Format 5: This packet format transmits both the TCP sequence
number and the TCP Acknowledgment number, and is expected to be
used useful for flows that send data in both directions.
o Format 6: This packet format is similar to format 5, but sends the
TCP Sequence number in scaled form, when the payload size is
static for certain intervals in a data flow.
Pelletier, et al. Expires December 21, 2006 [Page 40]
Internet-Draft ROHC-TCP June 2006
o Format 7: This packet format transmits changes to both the TCP
Acknowledgment number and the TCP window, and is expected to be
used for the acknowledgment flows of data connections.
o Format 8: This packet format is used to transmit changes to some
of the more seldom changing fields in the TCP flow, such as ECN
behavior, RST/SYN/FIN flags, the TTL/Hop Limit and the TCP options
list. This format carries a 7-bit CRC, since it can change the
contents of the irregular chain in later packets. Note that this
can be seen as a reduced form of the common packet format.
o Common packet format: The common packet format can be used for all
kinds of IP-ID behavior, and should be used when some of the more
rarely changing fields in the IP or TCP header changes. Since
this packet format change control fields that decide how the
decompressor interprets packets, it carries a 7-bit CRC to reduce
the probability of context corruption. This packet can basically
change all the dynamic fields in the IP and TCP header, and it
uses a large set of flags to provide information about which
fields are present in the packet format.
8.2. Formal Definition in ROHC-FN
////////////////////////////////////////////
// Constants
////////////////////////////////////////////
IP_ID_BEHAVIOR_SEQUENTIAL = 0;
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1;
IP_ID_BEHAVIOR_RANDOM = 2;
IP_ID_BEHAVIOR_ZERO = 3;
////////////////////////////////////////////
// Global control fields
////////////////////////////////////////////
CONTROL {
ecn_used [ 1 ];
msn [ 16 ];
}
///////////////////////////////////////////////
// Encoding methods not specified in FN syntax:
///////////////////////////////////////////////
list_tcp_options "defined in Section 6.3.3";
inferred_ip_v4_header_checksum "defined in Section 6.4.1";
Pelletier, et al. Expires December 21, 2006 [Page 41]
Internet-Draft ROHC-TCP June 2006
inferred_mine_header_checksum "defined in Section 6.4.2";
inferred_ip_v4_length "defined in Section 6.4.3";
inferred_ip_v6_length "defined in Section 6.4.4";
inferred_offset "defined in Section 6.4.5";
baseheader_extension_headers "defined in Section 6.4.6";
baseheader_outer_headers "defined in Section 6.4.7";
////////////////////////////////////////////
// General encoding methods
////////////////////////////////////////////
static_or_irreg(flag, width)
{
UNCOMPRESSED {
field [ width ];
}
COMPRESSED irreg_enc {
field =:= irregular(width) [ width ];
ENFORCE(flag == 1);
}
COMPRESSED static_enc {
field =:= static [ 0 ];
ENFORCE(flag == 0);
}
}
variable_length_32_enc(flag)
{
UNCOMPRESSED {
field [ 32 ];
}
COMPRESSED not_present {
field =:= static [ 0 ];
ENFORCE(flag == 0);
}
COMPRESSED 8_bit {
field =:= lsb(8, 63) [ 8 ];
ENFORCE(flag == 1);
}
COMPRESSED 16_bit {
field =:= lsb(16, 16383) [ 16 ];
ENFORCE(flag == 2);
}
Pelletier, et al. Expires December 21, 2006 [Page 42]
Internet-Draft ROHC-TCP June 2006
COMPRESSED 32_bit {
field =:= irregular(32) [ 32 ];
ENFORCE(flag == 3);
}
}
optional32(flag)
{
UNCOMPRESSED {
item [ 0, 32 ];
}
COMPRESSED present {
item =:= irregular(32) [ 32 ];
ENFORCE(flag == 1);
}
COMPRESSED not_present {
item =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag == 0);
}
}
lsb_7_or_31
{
UNCOMPRESSED {
item [ 32 ];
}
COMPRESSED lsb_7 {
discriminator =:= '0' [ 1 ];
item =:= lsb(7, 8) [ 7 ];
}
COMPRESSED lsb_31 {
discriminator =:= '1' [ 1 ];
item =:= lsb(31, 256) [ 31 ];
}
}
opt_lsb_7_or_31(flag)
{
UNCOMPRESSED {
item [ 0, 32 ];
}
COMPRESSED present {
item =:= lsb_7_or_31 [ 8, 32 ];
Pelletier, et al. Expires December 21, 2006 [Page 43]
Internet-Draft ROHC-TCP June 2006
ENFORCE(flag == 1);
}
COMPRESSED not_present {
item =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag == 0);
}
}
crc3(data_value, data_length)
{
UNCOMPRESSED {
}
COMPRESSED {
crc_value =:=
crc(3, 0x06, 0x07, data_value, data_length) [ 3 ];
}
}
crc7(data_value, data_length)
{
UNCOMPRESSED {
}
COMPRESSED {
crc_value =:=
crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ];
}
}
// Encoding method for updating a scaled field and its associated
// control fields. Should be used both when the value is scaled
// or unscaled in a compressed format.
field_scaling(stride_value, scaled_value, unscaled_value)
{
UNCOMPRESSED {
residue_field [ 32 ];
}
COMPRESSED no_scaling {
ENFORCE(stride_value == 0);
ENFORCE(residue_field.UVALUE == unscaled_value);
ENFORCE(scaled_value == 0);
}
COMPRESSED scaling_used {
ENFORCE(stride_value != 0);
Pelletier, et al. Expires December 21, 2006 [Page 44]
Internet-Draft ROHC-TCP June 2006
ENFORCE(residue_field.UVALUE == (unscaled_value % stride_value));
ENFORCE(unscaled_value ==
scaled_value * stride_value + residue_field.UVALUE);
}
}
////////////////////////////////////////////
// IPv6 Destination options header
////////////////////////////////////////////
ip_dest_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ VARIABLE ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED dest_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED dest_opt_dynamic {
value =:= irregular(length.UVALUE * 64 + 48) [ VARIABLE ];
}
COMPRESSED dest_opt_replicate_0 {
discriminator =:= '00000000' [ 8 ];
}
COMPRESSED dest_opt_replicate_1 {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
value =:= irregular(length.UVALUE*64+48) [ VARIABLE ];
}
}
////////////////////////////////////////////
// IPv6 Hop-by-Hop options header
////////////////////////////////////////////
Pelletier, et al. Expires December 21, 2006 [Page 45]
Internet-Draft ROHC-TCP June 2006
ip_hop_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ VARIABLE ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED hop_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED hop_opt_dynamic {
value =:= irregular(length.UVALUE*64+48) [ VARIABLE ];
}
COMPRESSED hop_opt_replicate_0 {
discriminator =:= '00000000' [ 8 ];
}
COMPRESSED hop_opt_replicate_1 {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
value =:= irregular(length.UVALUE*64+48) [ VARIABLE ];
}
}
////////////////////////////////////////////
// IPv6 Routing header
////////////////////////////////////////////
ip_rout_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ VARIABLE ];
}
DEFAULT {
length =:= static;
Pelletier, et al. Expires December 21, 2006 [Page 46]
Internet-Draft ROHC-TCP June 2006
next_header =:= static;
value =:= static;
}
COMPRESSED rout_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
value =:= irregular(length.UVALUE*64+48) [ VARIABLE ];
}
COMPRESSED rout_opt_dynamic {
}
COMPRESSED rout_opt_replicate_0 {
discriminator =:= '00000000' [ 8 ];
}
COMPRESSED rout_opt_replicate_1 {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
value =:= irregular(length.UVALUE*64+48) [ VARIABLE ];
}
}
////////////////////////////////////////////
// GRE Header
////////////////////////////////////////////
optional_checksum(flag_value)
{
UNCOMPRESSED {
value [ 0, 16 ];
reserved1 [ 0, 16 ];
}
COMPRESSED cs_present {
value =:= irregular(16) [ 16 ];
reserved1 =:= uncompressed_value(16, 0) [ 0 ];
ENFORCE(flag_value == 1);
}
COMPRESSED not_present {
value =:= compressed_value(0, 0) [ 0 ];
reserved1 =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag_value == 0);
}
}
Pelletier, et al. Expires December 21, 2006 [Page 47]
Internet-Draft ROHC-TCP June 2006
gre_proto
{
UNCOMPRESSED {
protocol [ 16 ];
}
COMPRESSED ether_v4 {
discriminator =:= compressed_value(1, 0) [ 1 ];
protocol =:= uncompressed_value(16, 0x0800);
}
COMPRESSED ether_v6 {
discriminator =:= compressed_value(1, 1) [ 1 ];
protocol =:= uncompressed_value(16, 0x86DD);
}
}
gre
{
UNCOMPRESSED {
c_flag [ 1 ];
r_flag =:= uncompressed_value(1, 0) [ 1 ];
k_flag [ 1 ];
s_flag [ 1 ];
reserved0 =:= uncompressed_value(9, 0) [ 9 ];
version =:= uncompressed_value(3, 0) [ 3 ];
protocol [ 16 ];
checksum_and_res [ 0, 32 ];
key [ 0, 32 ];
sequence_number [ 0, 32 ];
}
DEFAULT {
c_flag =:= static;
k_flag =:= static;
s_flag =:= static;
protocol =:= static;
key =:= static;
sequence_number =:= static;
}
COMPRESSED gre_static {
protocol =:= gre_proto [ 1 ];
c_flag =:= irregular(1) [ 1 ];
k_flag =:= irregular(1) [ 1 ];
s_flag =:= irregular(1) [ 1 ];
padding =:= compressed_value(4, 0) [ 4 ];
key =:= optional32(k_flag.UVALUE) [ 0, 32 ];
Pelletier, et al. Expires December 21, 2006 [Page 48]
Internet-Draft ROHC-TCP June 2006
}
COMPRESSED gre_dynamic {
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_replicate_0 {
discriminator =:= '00000000' [ 8 ];
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:=
optional32(s_flag.UVALUE) [ 0, 8, 32 ];
}
COMPRESSED gre_replicate_1 {
discriminator =:= '10000' [ 5 ];
c_flag =:= irregular(1) [ 1 ];
k_flag =:= irregular(1) [ 1 ];
s_flag =:= irregular(1) [ 1 ];
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
key =:= optional32(k_flag.UVALUE) [ 0, 32 ];
sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_irregular {
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:=
opt_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ];
}
}
/////////////////////////////////////////////
// MINE header
/////////////////////////////////////////////
mine
{
UNCOMPRESSED {
next_header [ 8 ];
s_bit [ 1 ];
res_bits [ 7 ];
checksum [ 16 ];
orig_dest [ 32 ];
orig_src [ 0, 32 ];
Pelletier, et al. Expires December 21, 2006 [Page 49]
Internet-Draft ROHC-TCP June 2006
}
DEFAULT {
next_header =:= static;
s_bit =:= static;
res_bits =:= static;
checksum =:= inferred_mine_header_checksum;
orig_dest =:= static;
orig_src =:= static;
}
COMPRESSED mine_static {
next_header =:= irregular(8) [ 8 ];
s_bit =:= irregular(1) [ 1 ];
// Reserved are included - no benefit in removing them
res_bits =:= irregular(7) [ 7 ];
orig_dest =:= irregular(32) [ 32 ];
orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ];
}
COMPRESSED mine_dynamic {
}
COMPRESSED mine_replicate_0 {
discriminator =:= '00000000' [ 8 ];
}
COMPRESSED mine_replicate_1 {
discriminator =:= '10000000' [ 8 ];
s_bit =:= irregular(1) [ 1 ];
res_bits =:= irregular(7) [ 7 ];
orig_dest =:= irregular(32) [ 32 ];
orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ];
}
}
/////////////////////////////////////////////
// Authentication Header (AH)
/////////////////////////////////////////////
ah
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
res_bits [ 16 ];
spi [ 32 ];
sequence_number [ 32 ];
Pelletier, et al. Expires December 21, 2006 [Page 50]
Internet-Draft ROHC-TCP June 2006
auth_data [ VARIABLE ];
}
DEFAULT {
next_header =:= static;
length =:= static;
res_bits =:= static;
spi =:= static;
sequence_number =:= static;
}
COMPRESSED ah_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
spi =:= irregular(32) [ 32 ];
}
COMPRESSED ah_dynamic {
res_bits =:= irregular(16) [ 16 ];
sequence_number =:= irregular(32) [ 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ VARIABLE ];
}
COMPRESSED ah_replicate_0 {
discriminator =:= '00000000' [ 8 ];
sequence_number =:= irregular(32) [ 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ VARIABLE ];
}
COMPRESSED ah_replicate_1 {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
res_bits =:= irregular(16) [ 16 ];
spi =:= irregular(32) [ 32 ];
sequence_number =:= irregular(32) [ 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ VARIABLE ];
}
COMPRESSED ah_irregular {
sequence_number =:= lsb_7_or_31 [ 8, 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ VARIABLE ];
}
}
Pelletier, et al. Expires December 21, 2006 [Page 51]
Internet-Draft ROHC-TCP June 2006
/////////////////////////////////////////////
// ESP header (NULL encrypted)
/////////////////////////////////////////////
// Since the "next header" field is located in the packet trailer
// and ROHC-FN requires all UNCOMPRESSED fields to be contiguous,
// the values of the next header field is passed as a parameter.
// To avoid forcing the decompression to access the trailer part of
// the packet, the next header is istead handled with a control field
esp_null(next_header_value)
{
UNCOMPRESSED {
spi [ 32 ];
sequence_number [ 32 ];
}
CONTROL {
nh_field [ 8 ];
}
DEFAULT {
spi =:= static;
sequence_number =:= static;
nh_field =:= static;
}
COMPRESSED esp_static {
nh_field =:= compressed_value(8, next_header_value) [ 8 ];
spi =:= irregular(32) [ 32 ];
}
COMPRESSED esp_dynamic {
sequence_number =:= irregular(32) [ 32 ];
}
COMPRESSED esp_replicate_0 {
discriminator =:= '00000000' [ 8 ];
sequence_number =:= irregular(32) [ 32 ];
}
COMPRESSED esp_replicate_1 {
discriminator =:= '10000000' [ 8 ];
spi =:= irregular(32) [ 32 ];
sequence_number =:= irregular(32) [ 32 ];
}
COMPRESSED esp_irregular {
sequence_number =:= lsb_7_or_31 [ 8, 32 ];
Pelletier, et al. Expires December 21, 2006 [Page 52]
Internet-Draft ROHC-TCP June 2006
}
}
/////////////////////////////////////////////
// Encoding methods common for IPv4 and IPv6
/////////////////////////////////////////////
irreg_tos_tc
{
UNCOMPRESSED {
tos_tc [ 6 ];
}
COMPRESSED tos_tc_present {
tos_tc =:= irregular(6) [ 6 ];
ENFORCE(ecn_used.UVALUE == 1);
}
COMPRESSED tos_tc_not_present {
tos_tc =:= static [ 0 ];
ENFORCE(ecn_used.UVALUE == 0);
}
}
ip_irreg_ecn
{
UNCOMPRESSED {
ip_ecn_flags [ 2 ];
}
COMPRESSED tc_present {
ip_ecn_flags =:= irregular(2) [ 2 ];
ENFORCE(ecn_used.UVALUE == 1);
}
COMPRESSED tc_not_present {
ip_ecn_flags =:= static [ 0 ];
ENFORCE(ecn_used.UVALUE == 0);
}
}
/////////////////////////////////////////////
// IPv6 Header
/////////////////////////////////////////////
fl_enc
{
UNCOMPRESSED {
Pelletier, et al. Expires December 21, 2006 [Page 53]
Internet-Draft ROHC-TCP June 2006
flow_label [ 20 ];
}
COMPRESSED fl_zero {
discriminator =:= '0' [ 1 ];
flow_label =:= uncompressed_value(20, 0) [ 0 ];
reserved =:= '0000' [ 4 ];
}
COMPRESSED fl_non_zero {
discriminator =:= '1' [ 1 ];
flow_label =:= irregular(20) [ 20 ];
}
}
// The is_innermost flag should be true if this is the innermost
// IP header to be compressed.
// If extracting the irregular chain for an compressed packet,
// the TTL argument must have the same value as it had when
// processing co_baseheader. If extracting any other chain
// items, this argument is not used.
// ip_inner_ecn is bound in this encoding method and the value that
// it gets bound to should be passed to the tcp encoding method
// when processing the irregular chain for TCP.
ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn)
{
UNCOMPRESSED {
version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 6 ];
ip_ecn_flags [ 2 ];
flow_label [ 20 ];
payload_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dst_addr [ 128 ];
}
DEFAULT {
tos_tc =:= static;
ip_ecn_flags =:= static;
flow_label =:= static;
payload_length =:= inferred_ip_v6_length;
next_header =:= static;
ttl_hopl =:= static;
src_addr =:= static;
dst_addr =:= static;
}
Pelletier, et al. Expires December 21, 2006 [Page 54]
Internet-Draft ROHC-TCP June 2006
COMPRESSED ipv6_static {
version_flag =:= '1' [ 1 ];
reserved =:= '00' [ 2 ];
flow_label =:= fl_enc [ 5, 21 ];
next_header =:= irregular(8) [ 8 ];
src_addr =:= irregular(128) [ 128 ];
dst_addr =:= irregular(128) [ 128 ];
}
COMPRESSED ipv6_dynamic {
tos_tc =:= irregular(6) [ 6 ];
ip_ecn_flags =:= irregular(2) [ 2 ];
ttl_hopl =:= irregular(8) [ 8 ];
}
COMPRESSED ipv6_replicate {
tos_tc =:= irregular(6) [ 6 ];
ip_ecn_flags =:= irregular(2) [ 2 ];
reserved =:= '000' [ 3 ];
flow_label =:= fl_enc [ 5, 21 ];
}
COMPRESSED ipv6_outer_irregular_without_ttl {
tos_tc =:= irreg_tos_tc [ 0, 6 ];
ip_ecn_flags =:= ip_irreg_ecn [ 0, 2 ];
ENFORCE(ttl_irregular_chain_flag == 0);
ENFORCE(is_innermost == false);
}
COMPRESSED ipv6_outer_irregular_with_ttl {
tos_tc =:= irreg_tos_tc [ 0, 6 ];
ip_ecn_flags =:= ip_irreg_ecn [ 0, 2 ];
ttl_hopl =:= irregular(8) [ 8 ];
ENFORCE(ttl_irregular_chain_flag == 1);
ENFORCE(is_innermost == false);
}
COMPRESSED ipv6_innermost_irregular {
ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE);
ENFORCE(is_innermost == true);
}
}
/////////////////////////////////////////////
// IPv4 Header
/////////////////////////////////////////////
ip_id_enc_dyn(behavior)
Pelletier, et al. Expires December 21, 2006 [Page 55]
Internet-Draft ROHC-TCP June 2006
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED ip_id_seq {
ip_id =:= irregular(16) [ 16 ];
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED) ||
(behavior == IP_ID_BEHAVIOR_RANDOM));
}
COMPRESSED ip_id_zero {
ip_id =:= uncompressed_value(16, 0) [ 0 ];
ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
}
}
ip_id_enc_irreg(behavior)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED ip_id_seq {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
}
COMPRESSED ip_id_seq_swapped {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
}
COMPRESSED ip_id_rand {
ip_id =:= irregular(16) [ 16 ];
ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM);
}
COMPRESSED ip_id_zero {
ip_id =:= uncompressed_value(16, 0) [ 0 ];
ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
}
}
ip_id_behavior_choice
{
UNCOMPRESSED {
behavior [ 2 ];
}
Pelletier, et al. Expires December 21, 2006 [Page 56]
Internet-Draft ROHC-TCP June 2006
DEFAULT {
behavior =:= irregular(2);
}
COMPRESSED sequential {
behavior [ 2 ];
ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL);
}
COMPRESSED sequential_swapped {
behavior [ 2 ];
ENFORCE(behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
}
COMPRESSED random {
behavior [ 2 ];
ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
}
COMPRESSED zero {
behavior [ 2 ];
ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_ZERO);
}
}
// The is_innermost flag should be true if this is the innermost
// IP header to be compressed.
// If extracting the irregular chain for an compressed packet,
// the TTL argument must have the same value as it had when
// processing co_baseheader. If extracting any other chain
// items, this argument is not used.
// ip_inner_ecn is set in this encoding method and the value that
// it gets bound to should be passed to the tcp encoding method
ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn)
{
UNCOMPRESSED {
version =:= uncompressed_value(4, 4) [ 4 ];
hdr_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 6 ];
ip_ecn_flags [ 2 ];
length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
Pelletier, et al. Expires December 21, 2006 [Page 57]
Internet-Draft ROHC-TCP June 2006
protocol [ 8 ];
checksum [ 16 ];
src_addr [ 32 ];
dst_addr [ 32 ];
}
CONTROL {
ip_id_behavior [ 2 ];
}
DEFAULT {
tos_tc =:= static;
ip_ecn_flags =:= static;
length =:= inferred_ip_v4_length;
df =:= static;
ttl_hopl =:= static;
protocol =:= static;
checksum =:= inferred_ip_v4_header_checksum;
src_addr =:= static;
dst_addr =:= static;
ip_id_behavior =:= static;
}
COMPRESSED ipv4_static {
version_flag =:= '0' [ 1 ];
reserved =:= '0000000' [ 7 ];
protocol =:= irregular(8) [ 8 ];
src_addr =:= irregular(32) [ 32 ];
dst_addr =:= irregular(32) [ 32 ];
}
COMPRESSED ipv4_dynamic {
reserved =:= '00000' [ 5 ];
df =:= irregular(1) [ 1 ];
// compressor chooses behavior of IP-ID
ip_id_behavior =:= ip_id_behavior_choice [ 2 ];
tos_tc =:= irregular(6) [ 6 ];
ip_ecn_flags =:= irregular(2) [ 2 ];
ttl_hopl =:= irregular(8) [ 8 ];
ip_id =:=
ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ];
}
COMPRESSED ipv4_replicate {
reserved =:= '0000' [ 4 ];
ip_id_behavior =:= ip_id_behavior_choice [ 2 ];
ttl_flag =:= irregular(1) [ 1 ];
df =:= irregular(1) [ 1 ];
Pelletier, et al. Expires December 21, 2006 [Page 58]
Internet-Draft ROHC-TCP June 2006
tos_tc =:= irregular(6) [ 6 ];
ip_ecn_flags =:= irregular(2) [ 2 ];
ip_id =:=
ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ];
ttl_hopl =:=
static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ];
}
COMPRESSED ipv4_outer_irregular_without_ttl {
ip_id =:=
ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
tos_tc =:= irreg_tos_tc [ 0, 6 ];
ip_ecn_flags =:= ip_irreg_ecn [ 0, 2 ];
ENFORCE(ttl_irregular_chain_flag == 0);
ENFORCE(is_innermost == false);
}
COMPRESSED ipv4_outer_irregular_with_ttl {
ip_id =:=
ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
tos_tc =:= irreg_tos_tc [ 0, 6 ];
ip_ecn_flags =:= ip_irreg_ecn [ 0, 2 ];
ttl_hopl =:= irregular(8) [ 8 ];
ENFORCE(is_innermost == false);
ENFORCE(ttl_irregular_chain_flag == 1);
}
COMPRESSED ipv4_innermost_irregular {
ip_id =:=
ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE);
ENFORCE(is_innermost == true);
}
}
/////////////////////////////////////////////
// TCP Options
/////////////////////////////////////////////
//
// EOL marks the end of the option list and, based on
// the description in RFC 793 and the BSB TCP code,
// nothing after this should be processed...
// So, ignore everything after the EOL option
// (according to 793 it must be 0)
//
// The length of the padding needs to be transmitted with the
// compressed list since the length of the list can be unknown to
Pelletier, et al. Expires December 21, 2006 [Page 59]
Internet-Draft ROHC-TCP June 2006
// the decompressor.
//
tcp_opt_eol(nbits)
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 0) [ 8 ];
padding =:=
uncompressed_value(nbits-8, 0) [ VARIABLE ];
}
CONTROL {
pad_len [ 8 ];
}
DEFAULT {
pad_len =:= static;
}
COMPRESSED eol_list_item {
pad_len =:= compressed_value(8, nbits-8) [ 8 ];
}
COMPRESSED eol_irregular {
ENFORCE(nbits-8 == pad_len.UVALUE);
}
}
tcp_opt_nop
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 1) [ 8 ];
}
COMPRESSED nop_list_item {
}
COMPRESSED nop_irregular {
}
}
tcp_opt_mss
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 2) [ 8 ];
length =:= uncompressed_value(8, 4) [ 8 ];
mss [ 16 ];
}
Pelletier, et al. Expires December 21, 2006 [Page 60]
Internet-Draft ROHC-TCP June 2006
DEFAULT {
mss =:= static;
}
COMPRESSED mss_list_item {
mss =:= irregular(16) [ 16 ];
}
COMPRESSED mss_irregular {
}
}
tcp_opt_wscale
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 3) [ 8 ];
length =:= uncompressed_value(8, 3) [ 8 ];
wscale [ 8 ];
}
DEFAULT {
wscale =:= static;
}
COMPRESSED wscale_list_item {
wscale =:= irregular(8) [ 8 ];
}
COMPRESSED wscale_irregular {
}
}
ts_lsb
{
UNCOMPRESSED {
tsval [ 32 ];
}
// Few bits (7 and 14) bits can only increase, while the larger
// formats allow decreasing timestamp to handle reordering before
// the compression point.
COMPRESSED tsval_7 {
discriminator =:= '0' [ 1 ];
tsval =:= lsb(7, -1) [ 7 ];
}
COMPRESSED tsval_14 {
Pelletier, et al. Expires December 21, 2006 [Page 61]
Internet-Draft ROHC-TCP June 2006
discriminator =:= '10' [ 2 ];
tsval =:= lsb(14, -1) [ 14 ];
}
COMPRESSED tsval_21 {
discriminator =:= '110' [ 3 ];
tsval =:= lsb(21, 0x00040000) [ 21 ];
}
COMPRESSED tsval_29 {
discriminator =:= '111' [ 3 ];
tsval =:= lsb(29, 0x04000000) [ 29 ];
}
}
tcp_opt_tsopt
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 8) [ 8 ];
length =:= uncompressed_value(8, 10) [ 8 ];
tsval [ 32 ];
tsecho [ 32 ];
}
COMPRESSED tsopt_list_item {
tsval =:= irregular(32) [ 32 ];
tsecho =:= irregular(32) [ 32 ];
}
COMPRESSED tsopt_irregular {
tsval =:= ts_lsb [ 8, 16, 24, 32 ];
tsecho =:= ts_lsb [ 8, 16, 24, 32 ];
}
}
sack_var_length_enc(base)
{
UNCOMPRESSED {
sack_field [ 32 ];
}
CONTROL {
sack_offset [ 32 ];
ENFORCE(sack_offset.UVALUE == (sack_field.UVALUE - base));
}
COMPRESSED lsb_15 {
Pelletier, et al. Expires December 21, 2006 [Page 62]
Internet-Draft ROHC-TCP June 2006
discriminator =:= '0' [ 1 ];
sack_offset =:= lsb(15, -1) [ 15 ];
}
COMPRESSED lsb_22 {
discriminator =:= '10' [ 2 ];
sack_offset =:= lsb(22, -1) [ 22 ];
}
COMPRESSED lsb_30 {
discriminator =:= '11' [ 2 ];
sack_offset =:= lsb(30, -1) [ 30 ];
}
}
tcp_opt_sack_block(prev_block_end)
{
UNCOMPRESSED {
block_start [ 32 ];
block_end [ 32 ];
}
COMPRESSED {
block_start =:=
sack_var_length_enc(prev_block_end) [ 16, 24, 32 ];
block_end =:=
sack_var_length_enc(block_start) [ 16, 24, 32 ];
}
}
tcp_opt_sack(ack_value)
{
// The ACK value from the TCP header is needed as input parameter.
UNCOMPRESSED {
type =:= uncompressed_value(8, 5) [ 8 ];
length [ 8 ];
block_1 [ 64 ];
block_2 [ 0, 64 ];
block_3 [ 0, 64 ];
block_4 [ 0, 64 ];
}
DEFAULT {
length =:= static;
block_2 =:= uncompressed_value(0, 0);
block_3 =:= uncompressed_value(0, 0);
block_4 =:= uncompressed_value(0, 0);
Pelletier, et al. Expires December 21, 2006 [Page 63]
Internet-Draft ROHC-TCP June 2006
}
COMPRESSED sack1_list_item {
discriminator =:= '00000001';
block_1 =:= tcp_opt_sack_block(ack_value);
ENFORCE(length.UVALUE == 10);
}
COMPRESSED sack2_list_item {
discriminator =:= '00000010';
block_1 =:= tcp_opt_sack_block(ack_value);
block_2 =:= tcp_opt_sack_block(block_1_end.UVALUE);
ENFORCE(length.UVALUE == 18);
}
COMPRESSED sack3_list_item {
discriminator =:= '00000011';
block_1 =:= tcp_opt_sack_block(ack_value);
block_2 =:= tcp_opt_sack_block(block_1_end.UVALUE);
block_3 =:= tcp_opt_sack_block(block_2_end.UVALUE);
ENFORCE(length.UVALUE == 26);
}
COMPRESSED sack4_list_item {
discriminator =:= '00000100';
block_1 =:= tcp_opt_sack_block(ack_value);
block_2 =:= tcp_opt_sack_block(block_1_end.UVALUE);
block_3 =:= tcp_opt_sack_block(block_2_end.UVALUE);
block_4 =:= tcp_opt_sack_block(block_3_end.UVALUE);
ENFORCE(length.UVALUE == 34);
}
COMPRESSED sack_unchanged_irregular {
discriminator =:= '00000000';
block_1 =:= static;
block_2 =:= static;
block_3 =:= static;
block_4 =:= static;
}
COMPRESSED sack1_irregular {
discriminator =:= '00000001';
block_1 =:= tcp_opt_sack_block(ack_value);
ENFORCE(length.UVALUE == 10);
}
COMPRESSED sack2_irregular {
discriminator =:= '00000010';
Pelletier, et al. Expires December 21, 2006 [Page 64]
Internet-Draft ROHC-TCP June 2006
block_1 =:= tcp_opt_sack_block(ack_value);
block_2 =:= tcp_opt_sack_block(block_1_end.UVALUE);
ENFORCE(length.UVALUE == 18);
}
COMPRESSED sack3_irregular {
discriminator =:= '00000011';
block_1 =:= tcp_opt_sack_block(ack_value);
block_2 =:= tcp_opt_sack_block(block_1_end.UVALUE);
block_3 =:= tcp_opt_sack_block(block_2_end.UVALUE);
ENFORCE(length.UVALUE == 26);
}
COMPRESSED sack4_irregular {
discriminator =:= '00000100';
block_1 =:= tcp_opt_sack_block(ack_value);
block_2 =:= tcp_opt_sack_block(block_1_end.UVALUE);
block_3 =:= tcp_opt_sack_block(block_2_end.UVALUE);
block_4 =:= tcp_opt_sack_block(block_3_end.UVALUE);
ENFORCE(length.UVALUE == 34);
}
}
tcp_opt_sack_permitted
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 4) [ 8 ];
length =:= uncompressed_value(8, 2) [ 8 ];
}
COMPRESSED sack_permitted_list_item {
}
COMPRESSED sack_permitted_irregular {
}
}
tcp_opt_generic
{
UNCOMPRESSED {
type [ 8 ];
length_msb =:= uncompressed_value(1, 0) [ 1 ];
length_lsb [ 7 ];
contents [ VARIABLE ];
}
CONTROL {
option_static [ 1 ];
Pelletier, et al. Expires December 21, 2006 [Page 65]
Internet-Draft ROHC-TCP June 2006
}
DEFAULT {
type =:= static;
length_lsb =:= static;
contents =:= static;
}
COMPRESSED generic_list_item {
type =:= irregular(8) [ 8 ];
option_static =:= irregular(1) [ 1 ];
length_lsb =:= irregular(7) [ 7 ];
contents =:=
irregular(length_len.UVALUE*8-16) [ VARIABLE ];
}
// Used when context of option has option_static set to one
COMPRESSED generic_irregular_static {
ENFORCE(option_static.UVALUE == 1);
}
// An item that can change, but currently is unchanged
COMPRESSED generic_irregular_stable {
discriminator =:= '11111111' [ 8 ];
ENFORCE(option_static.UVALUE == 0);
}
// An item that can change, and has changed compared to context.
// Length is not allowed to change here, since a length change is
// most likely to cause new NOPs or an EOL length change.
COMPRESSED generic_irregular_full {
discriminator =:= '00000000' [ 8 ];
contents =:=
irregular(length_lsb.UVALUE*8-16) [ VARIABLE ];
ENFORCE(option_static.UVALUE == 0);
}
}
tcp_list_presence_enc(presence)
{
UNCOMPRESSED {
tcp_options;
}
COMPRESSED list_not_present {
tcp_options =:= static [ 0 ];
ENFORCE(presence == 0);
}
Pelletier, et al. Expires December 21, 2006 [Page 66]
Internet-Draft ROHC-TCP June 2006
COMPRESSED list_present {
tcp_options =:= list_tcp_options [ VARIABLE ];
ENFORCE(presence == 1);
}
}
/////////////////////////////////////////////
// TCP Header
/////////////////////////////////////////////
port_replicate(flags)
{
UNCOMPRESSED {
port [ 16 ];
}
COMPRESSED port_static_enc {
port =:= static [ 0 ];
ENFORCE(flags == 0b00);
}
COMPRESSED port_lsb8 {
port =:= lsb(8, 64) [ 8 ];
ENFORCE(flags == 0b01);
}
COMPRESSED port_irr_enc {
port =:= irregular(16) [ 16 ];
ENFORCE(flags == 0b10);
}
}
zero_or_irr16_enc(flag)
{
UNCOMPRESSED {
field [ 16 ];
}
COMPRESSED non_zero {
field =:= irregular(16) [ 16 ];
ENFORCE(flag == 0);
}
COMPRESSED zero {
field =:= uncompressed_value(16, 0) [ 0 ];
ENFORCE(flag == 1);
}
}
Pelletier, et al. Expires December 21, 2006 [Page 67]
Internet-Draft ROHC-TCP June 2006
ack_enc_dyn(flag)
{
UNCOMPRESSED {
ack_number [ 32 ];
}
COMPRESSED ack_non_zero {
ack_number =:= irregular(32) [ 32 ];
ENFORCE(flag == 0);
}
COMPRESSED ack_zero {
ack_number =:= uncompressed_value(32, 0) [ 0 ];
ENFORCE(flag == 1);
}
}
ecn_choice
{
UNCOMPRESSED {
ecn_field [ 1 ];
}
COMPRESSED zero {
ecn_field [ 1 ];
ENFORCE(ecn_field.UVALUE == 0);
}
COMPRESSED nonzero {
ecn_field [ 1 ];
ENFORCE(ecn_field.UVALUE == 1);
}
}
tcp_ecn_flags_enc
{
UNCOMPRESSED {
tcp_ecn_flags [ 2 ];
}
COMPRESSED irreg {
tcp_ecn_flags =:= irregular(2) [ 2 ];
ENFORCE(ecn_used.UVALUE == 1);
}
COMPRESSED unused {
tcp_ecn_flags =:= static [ 0 ];
ENFORCE(ecn_used.UVALUE == 0);
Pelletier, et al. Expires December 21, 2006 [Page 68]
Internet-Draft ROHC-TCP June 2006
}
}
tcp_res_flags_enc
{
UNCOMPRESSED {
tcp_res_flags [ 4 ];
}
COMPRESSED irreg {
tcp_res_flags =:= irregular(4) [ 4 ];
ENFORCE(ecn_used.UVALUE == 1);
}
COMPRESSED unused {
tcp_res_flags =:= uncompressed_value(4, 0) [ 0 ];
ENFORCE(ecn_used.UVALUE == 0);
}
}
tcp_irreg_ip_ecn(ip_inner_ecn)
{
UNCOMPRESSED {
ip_ecn_flags [ 2 ];
}
COMPRESSED ecn_present {
ip_ecn_flags =:=
compressed_value(2, ip_inner_ecn) [ 2 ];
ENFORCE(ecn_used.UVALUE == 1);
}
COMPRESSED ecn_not_present {
ip_ecn_flags =:= static [ 0 ];
ENFORCE(ecn_used.UVALUE == 0);
}
}
rsf_index_enc
{
UNCOMPRESSED {
rsf_flag [ 3 ];
}
COMPRESSED none {
rsf_idx =:= '00' [ 2 ];
rsf_flag =:= uncompressed_value(3, 0x00);
}
Pelletier, et al. Expires December 21, 2006 [Page 69]
Internet-Draft ROHC-TCP June 2006
COMPRESSED rst_only {
rsf_idx =:= '01' [ 2 ];
rsf_flag =:= uncompressed_value(3, 0x04);
}
COMPRESSED syn_only {
rsf_idx =:= '10' [ 2 ];
rsf_flag =:= uncompressed_value(3, 0x02);
}
COMPRESSED fin_only {
rsf_idx =:= '11' [ 2 ];
rsf_flag =:= uncompressed_value(3, 0x01);
}
}
optional_2bit_padding(used_flag)
{
UNCOMPRESSED {
}
COMPRESSED used {
padding =:= compressed_value(2, 0x0) [ 2 ];
ENFORCE(used_flag == 1);
}
COMPRESSED unused {
padding =:= compressed_value(0, 0x0);
ENFORCE(used_flag == 0);
}
}
// ack_stride_value is the user-selected stride for scaling the
// TCP ack_number
// ip_inner_ecn is the value bound when processing the innermost
// IP header (ipv4 or ipv6 encoding method)
tcp(payload_size, ack_stride_value, ip_inner_ecn)
{
UNCOMPRESSED {
src_port [ 16 ];
dst_port [ 16 ];
seq_number [ 32 ];
ack_number [ 32 ];
data_offset [ 4 ];
tcp_res_flags [ 4 ];
tcp_ecn_flags [ 2 ];
urg_flag [ 1 ];
ack_flag [ 1 ];
Pelletier, et al. Expires December 21, 2006 [Page 70]
Internet-Draft ROHC-TCP June 2006
psh_flag [ 1 ];
rsf_flags [ 3 ];
window [ 16 ];
checksum [ 16 ];
urg_ptr [ 16 ];
options [ n ];
}
CONTROL {
seq_number_scaled [ 32 ];
seq_number_residue =:=
field_scaling(payload_size, seq_number_scaled.UVALUE,
seq_number.UVALUE) [ 32 ];
ack_stride [ 16 ];
ack_number_scaled [ 32 ];
ack_number_residue =:=
field_scaling(ack_stride.UVALUE, ack_number_scaled.UVALUE,
ack_number.UVALUE) [ 32 ];
ENFORCE(ack_stride.UVALUE == ack_stride_value);
}
DEFAULT {
src_port =:= static;
dst_port =:= static;
seq_number =:= static;
ack_number =:= static;
data_offset =:= inferred_offset;
tcp_res_flags =:= static;
tcp_ecn_flags =:= static;
urg_flag =:= static;
ack_flag =:= uncompressed_value(1, 1);
rsf_flags =:= static;
window =:= static;
urg_ptr =:= static;
}
COMPRESSED tcp_static {
src_port =:= irregular(16) [ 16 ];
dst_port =:= irregular(16) [ 16 ];
}
COMPRESSED tcp_dynamic {
ecn_used =:= ecn_choice [ 1 ];
ack_stride_flag =:= irregular(1) [ 1 ];
ack_zero =:= irregular(1) [ 1 ];
urp_zero =:= irregular(1) [ 1 ];
tcp_res_flags =:= irregular(4) [ 4 ];
tcp_ecn_flags =:= irregular(2) [ 2 ];
Pelletier, et al. Expires December 21, 2006 [Page 71]
Internet-Draft ROHC-TCP June 2006
urg_flag =:= irregular(1) [ 1 ];
ack_flag =:= irregular(1) [ 1 ];
psh_flag =:= irregular(1) [ 1 ];
rsf_flags =:= irregular(3) [ 3 ];
msn =:= irregular(16) [ 16 ];
seq_number =:= irregular(32) [ 32 ];
ack_number =:=
ack_enc_dyn(ack_zero.CVALUE) [ 0, 32 ];
window =:= irregular(16) [ 16 ];
checksum =:= irregular(16) [ 16 ];
urg_ptr =:=
zero_or_irr16_enc(urp_zero.CVALUE) [ 0, 16 ];
ack_stride =:=
static_or_irr16(ack_stride_flag.CVALUE) [ 0, 16 ];
options =:= list_tcp_options [ VARIABLE ];
}
COMPRESSED tcp_replicate {
reserved =:= '0' [ 1 ];
window_presence =:= irregular(1) [ 1 ];
list_present =:= irregular(1) [ 1 ];
src_port_presence =:= irregular(2) [ 2 ];
dst_port_presence =:= irregular(2) [ 2 ];
ack_stride_flag =:= irregular(1) [ 1 ];
ack_presence =:= irregular(1) [ 1 ];
urp_presence =:= irregular(1) [ 1 ];
urg_flag =:= irregular(1) [ 1 ];
ack_flag =:= irregular(1) [ 1 ];
psh_flag =:= irregular(1) [ 1 ];
rsf_flags =:= rsf_index_enc [ 2 ];
ecn_used =:= ecn_choice [ 1 ];
msn =:= irregular(16) [ 16 ];
seq_number =:= irregular(32) [ 32 ];
src_port =:=
port_replicate(src_port_presence) [ 0, 8, 16 ];
dst_port =:=
port_replicate(dst_port_presence) [ 0, 8, 16 ];
window =:=
static_or_irreg(window_presence, 16) [ 0, 16 ];
urg_point =:=
static_or_irreg(urp_presence, 16) [ 0, 16 ];
ack_number =:=
static_or_irreg(ack_presence, 32) [ 0, 32 ];
ecn_padding =:=
optional_2bit_padding(ecn_used.CVALUE) [ 0, 2 ];
tcp_res_flags =:= tcp_res_flags_enc [ 0, 4 ];
tcp_ecn_flags =:= tcp_ecn_flags_enc [ 0, 2 ];
checksum =:= irregular(16) [ 16 ];
Pelletier, et al. Expires December 21, 2006 [Page 72]
Internet-Draft ROHC-TCP June 2006
ack_stride =:=
static_or_irr16(ack_stride_flag.CVALUE) [ 0, 16 ];
options =:=
tcp_list_presence_enc((data_offset.UVALUE-5)*32,
list_present.CVALUE,
ack_number.UVALUE) [ VARIABLE ];
}
// ECN from innermost IP header is taken from global control field
COMPRESSED tcp_irregular {
ip_ecn_flags =:= tcp_irreg_ip_ecn(ip_inner_ecn) [ 0, 2 ];
tcp_res_flags =:= tcp_res_flags_enc [ 0, 4 ];
tcp_ecn_flags =:= tcp_ecn_flags_enc [ 0, 2 ];
checksum =:= irregular(16) [ 16 ];
}
}
///////////////////////////////////////////////////
// Encoding methods used in compressed base headers
///////////////////////////////////////////////////
tos_tc_enc(flag)
{
UNCOMPRESSED {
tos_tc [ 6 ];
}
COMPRESSED static_enc {
tos_tc =:= static [ 0 ];
ENFORCE(flag == 0);
}
COMPRESSED irreg {
tos_tc =:= irregular(6) [ 6 ];
padding =:= compressed_value(2, 0) [ 2 ];
ENFORCE(flag == 1);
}
}
ip_id_lsb(behavior, k, p)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
CONTROL {
ip_id_offset [ 16 ];
ip_id_nbo [ 16 ];
Pelletier, et al. Expires December 21, 2006 [Page 73]
Internet-Draft ROHC-TCP June 2006
}
COMPRESSED nbo {
ip_id_offset =:= lsb(k, p) [ VARIABLE ];
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
}
COMPRESSED non_nbo {
ip_id_offset =:= lsb(k, p) [ VARIABLE ];
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
ENFORCE(ip_id_nbo.UVALUE ==
(ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256);
ENFORCE(ip_id_nbo.ULENGTH == 16);
ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE);
}
}
optional_ip_id_lsb(behavior, indicator)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED short {
ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ];
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 0);
}
COMPRESSED long {
ip_id =:= irregular(16) [ 16 ];
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 1);
}
COMPRESSED not_present {
ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
(behavior == IP_ID_BEHAVIOR_ZERO));
}
}
dont_fragment(version)
{
UNCOMPRESSED {
df [ 1 ];
Pelletier, et al. Expires December 21, 2006 [Page 74]
Internet-Draft ROHC-TCP June 2006
}
COMPRESSED v4 {
df =:= irregular(1) [ 1 ];
ENFORCE(version == 4);
}
COMPRESSED v6 {
df =:= compressed_value(1, 0) [ 1 ];
ENFORCE(version == 6);
}
}
//////////////////////////////////
// Actual start of compressed packet formats
// Important note:
// The base header is the compressed representation
// of the innermost IP header AND the TCP header.
//////////////////////////////////
// ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit
// of an outer header has changed. The same value must be passed as
// an argument to the ipv4/ipv6 encoding methods when extracting
// the irregular chain items.
co_baseheader(payload_size, ack_stride_value,
ttl_irregular_chain_flag)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 6 ];
ip_ecn_flags [ 2 ];
length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dest_port [ 16 ];
seq_number [ 32 ];
Pelletier, et al. Expires December 21, 2006 [Page 75]
Internet-Draft ROHC-TCP June 2006
ack_number [ 32 ];
data_offset [ 4 ];
tcp_res_flags [ 4 ];
tcp_ecn_flags [ 2 ];
urg_flag [ 1 ];
ack_flag [ 1 ];
psh_flag [ 1 ];
rsf_flags [ 3 ];
window [ 16 ];
tcp_checksum [ 16 ];
urg_ptr [ 16 ];
options_list [ VARIABLE ];
}
UNCOMPRESSED v6 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 6 ];
ip_ecn_flags [ 2 ];
flow_label [ 20 ];
payload_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dest_port [ 16 ];
seq_number [ 32 ];
ack_number [ 32 ];
data_offset [ 4 ];
tcp_res_flags [ 4 ];
tcp_ecn_flags [ 2 ];
urg_flag [ 1 ];
ack_flag [ 1 ];
psh_flag [ 1 ];
rsf_flags [ 3 ];
window [ 16 ];
tcp_checksum [ 16 ];
urg_ptr [ 16 ];
options_list [ VARIABLE ];
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
}
CONTROL {
ip_id_behavior [ 2 ];
seq_number_scaled [ 32 ];
seq_number_residue =:=
Pelletier, et al. Expires December 21, 2006 [Page 76]
Internet-Draft ROHC-TCP June 2006
field_scaling(payload_size, seq_number_scaled.UVALUE,
seq_number.UVALUE) [ 32 ];
ack_stride [ 16 ];
ack_number_scaled [ 32 ];
ack_number_residue =:=
field_scaling(ack_stride.UVALUE, ack_number_scaled.UVALUE,
ack_number.UVALUE) [ 32 ];
ENFORCE(ack_stride_value == ack_stride.UVALUE);
}
DEFAULT {
tcp_ecn_flags =:= static;
data_offset =:= inferred_offset;
tcp_res_flags =:= static;
rsf_flags =:= uncompressed_value(3, 0);
dest_port =:= static;
tos_tc =:= static;
src_port =:= static;
urg_flag =:= uncompressed_value(1, 0);
window =:= static;
dest_addr =:= static;
version =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
ack_number =:= static;
urg_ptr =:= static;
seq_number =:= static;
ack_flag =:= uncompressed_value(1, 1);
options_list =:= static;
payload_length =:= inferred_ip_v6_length;
checksum =:= inferred_ip_v4_header_checksum;
length =:= inferred_ip_v4_length;
flow_label =:= static;
next_header =:= static;
ip_ecn_flags =:= static;
// The tcp_checksum has no default,
// it is considered a part of tcp_irregular
ip_id_behavior =:= static;
ecn_used =:= static;
// Default is to have no TTL in irregular chain
// Can only be nonzero if co_common is used
ENFORCE(ttl_irregular_chain_flag == 0);
}
////////////////////////////////////////////
// Common compressed packet format
Pelletier, et al. Expires December 21, 2006 [Page 77]
Internet-Draft ROHC-TCP June 2006
////////////////////////////////////////////
COMPRESSED co_common {
discriminator =:= '1111101' [ 7 ];
ttl_hopl_outer_flag =:=
compressed_value(1, ttl_irregular_chain_flag) [ 1 ];
ack_flag =:= irregular(1) [ 1 ];
psh_flag =:= irregular(1) [ 1 ];
rsf_flags =:= rsf_index_enc [ 2 ];
msn =:= lsb(4, 4) [ 4 ];
seq_indicator =:= irregular(2) [ 2 ];
ack_indicator =:= irregular(2) [ 2 ];
ack_stride_indicator =:= irregular(1) [ 1 ];
window_indicator =:= irregular(1) [ 1 ];
ip_id_indicator =:= irregular(1) [ 1 ];
urg_ptr_present =:= irregular(1) [ 1 ];
reserved =:= compressed_value(1, 0) [ 1 ];
ecn_used =:= ecn_choice [ 1 ];
tos_tc_present =:= irregular(1) [ 1 ];
ttl_hopl_present =:= irregular(1) [ 1 ];
list_present =:= irregular(1) [ 1 ];
ip_id_behavior =:= ip_id_behavior_choice [ 2 ];
urg_flag =:= irregular(1) [ 1 ];
df =:= dont_fragment(version.UVALUE) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
seq_number =:=
variable_length_32_enc(seq_indicator.CVALUE) [ 0, 8, 16, 32 ];
ack_number =:=
variable_length_32_enc(ack_indicator.CVALUE) [ 0, 8, 16, 32 ];
ack_stride =:=
static_or_irreg(ack_stride_indicator.CVALUE, 16) [ 0, 16 ];
window =:=
static_or_irreg(window_indicator.CVALUE, 16) [ 0, 16 ];
ip_id =:=
optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
urg_ptr =:=
static_or_irreg(urg_ptr_present.CVALUE, 16) [ 0, 16 ];
tos_tc =:=
tos_tc_enc(tos_tc_present.CVALUE) [ 0, 8 ];
ttl_hopl =:=
static_or_irreg(ttl_hopl_present.CVALUE, 8) [ 0, 8 ];
options_list =:=
tcp_list_presence_enc((data_offset.UVALUE - 5) * 32,
list_present.CVALUE,
ack_number.UVALUE) [ VARIABLE ];
}
Pelletier, et al. Expires December 21, 2006 [Page 78]
Internet-Draft ROHC-TCP June 2006
// Send LSBs of sequence number
COMPRESSED rnd_1 {
discriminator =:= '101110' [ 6 ];
seq_number =:= lsb(18, 65535) [ 18 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send scaled sequence number LSBs
COMPRESSED rnd_2 {
discriminator =:= '1100' [ 4 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send acknowledgment number LSBs
COMPRESSED rnd_3 {
discriminator =:= '0' [ 1 ];
ack_number =:= lsb(15, 8191) [ 15 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send acknowledgment number scaled
COMPRESSED rnd_4 {
discriminator =:= '1101' [ 4 ];
ack_number_scaled =:= lsb(4, 3) [ 4 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send ACK and sequence number
COMPRESSED rnd_5 {
discriminator =:= '100' [ 3 ];
psh_flag =:= irregular(1) [ 1 ];
Pelletier, et al. Expires December 21, 2006 [Page 79]
Internet-Draft ROHC-TCP June 2006
msn =:= lsb(4, 4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
seq_number =:= lsb(14, 8191) [ 14 ];
ack_number =:= lsb(15, 8191) [ 15 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send both ACK and scaled sequence number LSBs
COMPRESSED rnd_6 {
discriminator =:= '1010' [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
psh_flag =:= irregular(1) [ 1 ];
ack_number =:= lsb(16, 16383) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send ACK and window
COMPRESSED rnd_7 {
discriminator =:= '101111' [ 6 ];
ack_number =:= lsb(18, 65535) [ 18 ];
window =:= irregular(16) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// An extended packet type for seldom-changing fields
// Can send LSBs of TTL, RSF flags, change ECN behavior and
// options list
COMPRESSED rnd_8 {
discriminator =:= '10110' [ 5 ];
rsf_flags =:= rsf_index_enc [ 2 ];
list_present =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
ttl_hopl =:= lsb(3, 3) [ 3 ];
ecn_used =:= ecn_choice [ 1 ];
seq_number =:= lsb(16, 65535) [ 16 ];
ack_number =:= lsb(16, 16383) [ 16 ];
options_list =:=
tcp_list_presence_enc((data_offset.UVALUE-5)*32,
Pelletier, et al. Expires December 21, 2006 [Page 80]
Internet-Draft ROHC-TCP June 2006
list_present.CVALUE,
ack_number.UVALUE) [ VARIABLE ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send LSBs of sequence number
COMPRESSED seq_1 {
discriminator =:= '1010' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ];
seq_number =:= lsb(16, 32767) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send scaled sequence number LSBs
COMPRESSED seq_2 {
discriminator =:= '11010' [ 5 ];
ip_id =:=
ip_id_lsb(ip_id_behavior.UVALUE, 7, 3) [ 7 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send acknowledgment number LSBs
COMPRESSED seq_3 {
discriminator =:= '1001' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ];
ack_number =:= lsb(16, 16383) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send scaled acknowledgment number scaled
COMPRESSED seq_4 {
Pelletier, et al. Expires December 21, 2006 [Page 81]
Internet-Draft ROHC-TCP June 2006
discriminator =:= '0' [ 1 ];
ack_number_scaled =:= lsb(4, 3) [ 4 ];
// Due to having very few ip_id bits, no negative offset
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 3, 1) [ 3 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send ACK and sequence number
COMPRESSED seq_5 {
discriminator =:= '1000' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ];
ack_number =:= lsb(16, 16383) [ 16 ];
seq_number =:= lsb(16, 32767) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send both ACK and scaled sequence number LSBs
COMPRESSED seq_6 {
discriminator =:= '11011' [ 5 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 7, 3) [ 7 ];
ack_number =:= lsb(16, 16383) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send ACK and window
COMPRESSED seq_7 {
discriminator =:= '1100' [ 4 ];
window =:= lsb(15, 16383) [ 15 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5, 3) [ 5 ];
ack_number =:= lsb(16, 32767) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
Pelletier, et al. Expires December 21, 2006 [Page 82]
Internet-Draft ROHC-TCP June 2006
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// An extended packet type for seldom-changing fields
// Can send LSBs of TTL, RSF flags, change ECN behavior and
// options list
COMPRESSED seq_8 {
discriminator =:= '1011' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ];
list_present =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
ttl_hopl =:= lsb(3, 3) [ 3 ];
ecn_used =:= ecn_choice [ 1 ];
ack_number =:= lsb(15, 8191) [ 15 ];
rsf_flags =:= rsf_index_enc [ 2 ];
seq_number =:= lsb(14, 8191) [ 14 ];
options_list =:=
tcp_list_presence_enc((data_offset.UVALUE-5)*32,
list_present.CVALUE,
ack_number.UVALUE) [ VARIABLE ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
}
8.3. Feedback Formats and Options
8.3.1. Feedback Formats
This section describes the feedback format for ROHC-TCP. ROHC-TCP
uses the ROHC feedback format described in section 5.2.2 of
[RFC3095].
All feedback formats carry a field labelled SN. The SN field
contains LSBs of the Master Sequence Number (MSN) described in
Section 6.1.1. The sequence number to use is the MSN corresponding
to the header that caused the feedback information to be sent. If
that MSN cannot be determined, for example when decompression fails,
the MSN to use is that corresponding to the latest successfully
decompressed header.
Pelletier, et al. Expires December 21, 2006 [Page 83]
Internet-Draft ROHC-TCP June 2006
FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
MSN: The lsb-encoded master sequence number.
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK,
FEEDBACK-2 must be used.
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| MSN |
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
Acktype:
0 = ACK
1 = NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used for parsability)
MSN: The lsb-encoded master sequence number.
Feedback options: A variable number of feedback options, see
Section 8.3.2. Options may appear in any order.
8.3.2. Feedback Options
A ROHC-TCP Feedback option has variable length and the following
general format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type | Opt Len |
+---+---+---+---+---+---+---+---+
/ option data / Opt Length (octets)
+---+---+---+---+---+---+---+---+
Each ROHC-TCP feedback option can appear at most once within a
FEEDBACK-2.
Pelletier, et al. Expires December 21, 2006 [Page 84]
Internet-Draft ROHC-TCP June 2006
8.3.2.1. The CRC option
The CRC option contains an 8-bit CRC computed over the entire
feedback payload including any CID fields but excluding the packet
type, the 'Size' field and the 'Code' octet, using the polynomial of
section 5.9.1 of [RFC3095]. If the CID is given with an Add-CID
octet, the Add-CID octet immediately precedes the FEEDBACK-1 or
FEEDBACK-2 format. For purposes of computing the CRC, the CRC fields
of all CRC options are zero.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 1 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
When receiving feedback information with a CRC option, the compressor
MUST verify the information by computing the CRC and comparing the
result with the CRC carried in the CRC option. If the two are not
identical, the feedback packet MUST be discarded.
8.3.2.2. The REJECT option
The REJECT option informs the compressor that the decompressor does
not have sufficient resources to handle the flow.
+---+---+---+---+---+---+---+---+
| Opt Type = 2 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a REJECT option, the compressor MUST stop compressing
the packet flow, and SHOULD refrain from attempting to increase the
number of compressed packet flows for some time. Any FEEDBACK packet
carrying a REJECT option MUST also carry a CRC option.
8.3.2.3. The MSN-NOT-VALID option
The MSN-NOT-VALID option indicates that the MSN of the feedback is
not valid. A compressor MUST NOT use the MSN of the feedback to find
the corresponding sent header when this option is present.
+---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
Pelletier, et al. Expires December 21, 2006 [Page 85]
Internet-Draft ROHC-TCP June 2006
8.3.2.4. The MSN option
The MSN option provides 2 additional bits of MSN.
+---+---+---+---+---+---+---+---+
| Opt Type = 4 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| MSN | Reserved |
+---+---+---+---+---+---+---+---+
8.3.2.5. The LOSS option
The LOSS option allows the decompressor to report the largest
observed number of packets lost in sequence.
+---+---+---+---+---+---+---+---+
| Opt Type = 7 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| longest loss event (packets) |
+---+---+---+---+---+---+---+---+
The decompressor MAY choose to ignore the oldest loss events. Thus,
the value reported may decrease. Since setting the reference window
too small can reduce robustness, a FEEDBACK packet carrying a LOSS
option SHOULD also carry a CRC option. The compressor MAY choose to
ignore decreasing loss values.
8.3.2.6. The CONTEXT_MEMORY Feedback Option
The CONTEXT_MEMORY option informs the compressor that the
decompressor does not have sufficient memory resources to handle the
context of the packet flow, as the flow is currently compressed.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
actions to compress the packet flow in a way that requires less
decompressor memory resources, or stop compressing the packet flow.
8.3.2.7. Unknown option types
If an option type unknown to the compressor is encountered, it must
continue parsing the rest of the FEEDBACK packet, which is possible
since the length of the option is explicit, but MUST otherwise ignore
the unknown option.
Pelletier, et al. Expires December 21, 2006 [Page 86]
Internet-Draft ROHC-TCP June 2006
9. Security Consideration
A malfunctioning or malicious header compressor could cause the
header decompressor to reconstitute packets that do not match the
original packets but still have valid IP, and TCP headers and
possibly also valid TCP checksums. Such corruption may be detected
with end-to-end authentication and integrity mechanisms that will not
be affected by the compression. Moreover, this header compression
scheme uses an internal checksum for verification of reconstructed
headers. This reduces the probability of producing decompressed
headers not matching the original ones without this being noticed.
Denial-of-service attacks are possible if an intruder can introduce
(for example) bogus IR, CO or FEEDBACK packets onto the link and
thereby cause compression efficiency to be reduced. However, an
intruder having the ability to inject arbitrary packets at the link
layer in this manner raises additional security issues that dwarf
those related to the use of header compression.
10. IANA Considerations
The ROHC profile identifier 0x00XX <# Editor's Note: To be replaced
before publication #> has been reserved by the IANA for the profile
defined in this document.
<# Editor's Note: To be removed before publication #>
A ROHC profile identifier must be reserved by the IANA for the
profile defined in this document. Profiles 0x0000-0x0005 have
previously been reserved, which means this profile could be 0x0006.
As for previous ROHC profiles, profile numbers 0xnnXX must also be
reserved for future updates of this profile. A suggested
registration in the "RObust Header Compression (ROHC) Profile
Identifiers" name space would then be:
Profile Usage Document
identifier
0x0006 ROHC TCP [RFCXXXX (this)]
0xnn06 Reserved
11. Acknowledgements
The authors would like to thank Qian Zhang, Hong Bin Liao, Richard
Price and Fredrik Lindstroem for their work with early versions of
this specification. Thanks also to Robert Finking and Carsten Borman
Pelletier, et al. Expires December 21, 2006 [Page 87]
Internet-Draft ROHC-TCP June 2006
for valuable input. Finally, thanks to Joe Touch for his thorough
review and comments.
12. References
12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context
Replication for ROHC Profiles", RFC 4164, August 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[ROHC-FN] Finking, R. and G. Pelletier, "Formal Notation for Robust
Header Compression (ROHC-FN)",
Pelletier, et al. Expires December 21, 2006 [Page 88]
Internet-Draft ROHC-TCP June 2006
draft-ietf-rohc-formal-notation-10.txt (work in progress),
May 2006.
12.2. Informative References
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed
serial links", RFC 1144, February 1990.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC):
Terminology and Channel Mapping Examples", RFC 3759,
April 2004.
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843,
June 2004.
[RFC4163] Jonsson, L-E., "RObust Header Compression (ROHC):
Requirements on TCP/IP Header Compression", RFC 4163,
August 2005.
[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
Header Compression (ROHC): ROHC over Channels That Can
Reorder Packets", RFC 4224, January 2006.
[RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413,
March 2006.
Pelletier, et al. Expires December 21, 2006 [Page 89]
Internet-Draft ROHC-TCP June 2006
Authors' Addresses
Ghyslain Pelletier
Ericsson
Box 920
Lulea SE-971 28
Sweden
Phone: +46 (0) 8 404 29 43
Email: ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson
Ericsson
Box 920
Lulea SE-971 28
Sweden
Phone: +46 (0) 8 404 29 61
Email: lars-erik.jonsson@ericsson.com
Kristofer Sandlund
Ericsson
Box 920
Lulea SE-971 28
Sweden
Phone: +46 (0) 8 404 41 58
Email: kristofer.sandlund@ericsson.com
Mark A West
Siemens/Roke Manor
Roke Manor Research Ltd.
Romsey, Hampshire SO51 0ZN
UK
Phone: +44 1794 833311
Email: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Pelletier, et al. Expires December 21, 2006 [Page 90]
Internet-Draft ROHC-TCP June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Pelletier, et al. Expires December 21, 2006 [Page 91]
