Network Working Group Ghyslain Pelletier, Editor, Ericsson
INTERNET-DRAFT Lars-Erik Jonsson, Ericsson
Expires: August 2005 Mark A West, Siemens/Roke Manor
Carsten Bormann, TZI/Uni Bremen
Kristofer Sandlund, Effnet
February 21, 2005
RObust Header Compression (ROHC):
A Profile for TCP/IP (ROHC-TCP)
<draft-ietf-rohc-tcp-09.txt>
Status of this memo
By submitting this Internet-Draft, I (we) certify that any applicable
patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I (we) accept the provisions of
Section #3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract
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 improved
compression efficiency and enhanced capabilities for compression of
various header fields including TCP options.
Pelletier, et al. [Page 1]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
Existing TCP/IP header compression schemes do not work 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. In addition, existing
schemes (RFC 1144 [14], RFC 2507 [21]) have not addressed how to
compress TCP options such as SACK (Selective Acknowledgements) (RFC
2018 [20], RFC 2883 [22]) and Timestamps (RFC 1323 [15]).
Table of Contents
1. Introduction.....................................................4
2. Terminology......................................................4
3. Background.......................................................5
3.1. Existing TCP/IP Header Compression Schemes..................6
3.2. Classification of TCP/IP Header Fields......................7
3.3. Characteristics of Short-lived TCP Transfers................8
4. Overview of the TCP/IP Profile...................................9
4.1. General Concepts............................................9
4.2. Context Replication.........................................9
4.3. State Machines and Profile Operation........................9
4.4. Packet Formats and Encoding Methods........................10
4.5. Irregular Chain............................................10
4.6. TCP Options................................................10
4.6.1. Compressing Extension Headers.........................10
5. Compressor and decompressor State Machines......................10
5.1. Compressor States and Logic................................11
5.1.1. Initialization and Refresh (IR) State.................11
5.1.2. Compression (CO) State................................11
5.1.3. Feedback Logic........................................12
5.1.4. State Transition Logic................................12
5.1.4.1. Optimistic Approach, Upward Transition...........12
5.1.4.2. Optional Acknowledgements (ACKs), Upward Transition
..........................................................12
5.1.4.3. Timeouts, Downward Transition....................13
5.1.4.4. Negative ACKs (NACKs), Downward Transition.......13
5.1.4.5. Need for Updates, Downward Transition............13
5.1.5. State Machine Supporting Context Replication..........13
5.2. Decompressor States and Logic..............................14
5.2.1. No Context (NC) State.................................15
5.2.2. Static Context (SC) State.............................15
5.2.3. Full Context (FC) State...............................15
5.2.4. Allowing Decompression................................16
5.2.5. Reconstruction and Verification.......................16
5.2.6. Actions upon CRC Failure..............................16
5.2.7. Feedback Logic........................................17
6. ROHC-TCP - TCP/IP Compression (Profile 0x0006)..................18
6.1. Profile-specific Encoding Methods..........................18
6.1.1. inferred_mine_header_checksum().......................18
6.1.2. inferred_ip_v4_header_checksum()......................19
6.1.3. inferred_ip_v4_length()...............................19
Pelletier, et. al [Page 2]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
6.1.4. inferred_ip_v6_length()...............................19
6.1.5. inferred_offset().....................................20
6.1.6. Scaled TCP Sequence Number Encoding...................20
6.1.7. Scaled Acknowledgement Number Encoding................21
6.2. Considerations for the Feedback Channel....................22
6.3. Control Fields in the ROHC-TCP Context.....................22
6.3.1. Master Sequence Number (MSN)..........................23
6.3.2. IP-ID Behavior........................................23
6.3.3. Explicit Congestion Notification (ECN) in ROHC-TCP....24
6.4. CRC Calculations...........................................24
6.5. Initialization.............................................24
7. Packet Types....................................................25
7.1. Compressed Header Chains...................................25
7.2. Compressing TCP Options with List Compression..............26
7.2.1. List Compression......................................26
7.2.2. Table-based Item Compression..........................27
7.2.3. Item Tables...........................................28
7.2.4. Constraints to List Compression.......................29
7.2.5. Item Table Mappings...................................29
7.2.6. Compressed Lists in Dynamic Chain.....................30
7.2.7. Irregular Chain Items for TCP Options.................30
7.2.8. Replication of TCP Options............................31
7.3. Initialization and Refresh Packets (IR)....................31
7.4. Context Replication Packets (IR-CR)........................33
7.5. Compressed Packets (CO)....................................34
8. Packet Formats..................................................35
8.1. Design rationale for compressed base headers...............35
8.2. Global Control Fields......................................38
8.3. General Structures.........................................38
8.4. Extension Headers..........................................42
8.4.1. IPv6 DEST opt header..................................42
8.4.2. IPv6 HOP opt header...................................43
8.4.3. IPv6 Routing Header...................................43
8.4.4. GRE Header............................................44
8.4.5. MINE header...........................................47
8.4.6. Authentication Header (AH) header.....................48
8.4.7. Encapsulation Security Payload (ESP) header...........49
8.5. IP Header..................................................51
8.5.1. Structures Common for IPv4 and IPv6...................51
8.5.2. IPv6 Header...........................................51
8.5.3. IPv4 Header...........................................54
8.6. TCP Header.................................................58
8.7. TCP Options................................................64
8.8. Structures used in Compressed Base Headers.................74
8.9. Feedback Formats and Options...............................89
8.9.1. Feedback Formats......................................89
8.9.2. Feedback Options......................................90
8.9.2.1. The CRC option...................................90
8.9.2.2. The REJECT option................................90
8.9.2.3. The MSN-NOT-VALID option.........................91
8.9.2.4. The MSN option...................................91
Pelletier, et. al [Page 3]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8.9.2.5. The LOSS option..................................91
8.9.2.6. Unknown option types.............................91
8.9.2.7. The CONTEXT_MEMORY Feedback Option...............92
9. Security Consideration..........................................92
10. IANA Considerations............................................93
11. Acknowledgments................................................93
12. Authors' Addresses.............................................93
13. References.....................................................94
13.1. Normative references......................................94
13.2. Informative References....................................95
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 [21]. Additional considerations that make
robustness an important objective for a TCP compression scheme are
introduced in [10]. Finally, existing TCP/IP header compression
schemes (RFC 1144 [14], RFC 2507 [21]) 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
[20], RFC 2883 [22]) and Timestamps (RFC 1323 [15]).
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 [2], compliant with the
requirements on ROHC TCP/IP header compression [10].
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 [1].
This document reuses some of the terminology found in RFC 3095 [2].
In addition, this document uses or defines the following terms:
Pelletier, et. al [Page 4]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
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
The Base Context Identifier is the CID used to identify the Base
Context, where information needed for context replication can
be extracted from.
Context replication
Context replication is the mechanism that establishes and
initializes a new context based on another existing valid context
(a base context). This mechanism is introduced to reduce the
overhead of the context establishment procedure, and is especially
useful for compression of multiple short-lived TCP connections that
may be occurring simultaneously or near-simultaneously.
ROHC Context Replication (ROHC-CR)
"ROHC-CR" in this document normatively refers to the context
replication mechanism for ROHC profiles defined in [3].
ROHC Formal Notation (ROHC-FN)
"ROHC-FN" in this document normatively refers to the formal
notation for ROHC profiles defined in [4], including the library of
encoding methods it specifies.
Short-lived TCP Transfer
Short-lived TCP transfers refer to TCP connections transmitting
only small amounts of data for each single connection. Short TCP
flows seldom need to operate beyond the slow-start phase of TCP to
complete their transfer, which also means that the transmission
ends before any significant increase of the TCP congestion window
may occur.
3. Background
This chapter provides some background information on TCP/IP header
compression. The fundamentals of general header compression may be
found in [2]. In the following 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.
Pelletier, et. al [Page 5]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
The behavior analysis of TCP/IP header fields among multiple short-
lived connections may be found in [11].
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 [14]) 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
[21]) improves somewhat on CTCP by augmenting the repair mechanism of
CTCP with a local repair mechanism called TWICE and with a link-level
nacking mechanism to request a header that updates the context.
The TWICE algorithm assumes that only the Sequence Number field of
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 link.
Pelletier, et. al [Page 6]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
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 [11]. The main conclusion is that most of the header fields can
easily be compressed away since they never or seldom change. The
following fields do however require more sophisticated mechanisms:
- IPv4 Identification (16 bits) - IP-ID
- TCP Sequence Number (32 bits) - SN
- TCP Acknowledgement Number (32 bits) - ACKN
- TCP Reserved (4 bits)
- TCP ECN flags (2 bits) - ECN
- TCP Window (16 bits) - WINDOW
- TCP Options
- Maximum Segment Size (4 octets) - MSS
- Window Scale (3 octets) - WSopt
- SACK Permitted (2 octets)
- TCP SACK - SACK
- TCP Timestamp (32 bits) - TS
The assignment of IP-ID values can be done in various ways, which are
Sequential, Sequential jump, Random or constant to a value of zero.
However, designers of IPv4 stacks for cellular terminals should use
an assignment policy close to Sequential. Some IPv4 stacks do use a
sequential assignment when generating IP-ID values but do not
transmit the contents 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 [2], the IP-ID is
generally inferred from the RTP Sequence Number. However, with
respect to TCP compression, the analysis in [11] reveals that there
is no obvious candidate to this purpose among the TCP fields.
The change pattern of several TCP fields (Sequence Number,
Acknowledgement Number, Window, etc.) is very hard to predict and
differs entirely from the behavior of RTP fields discussed in [2]. Of
particular importance to a TCP/IP header compression scheme is the
understanding of the sequence and acknowledgement number [11].
Specifically, the 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
Pelletier, et. al [Page 7]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
window. The TCP window also bound the jumps in acknowledgement
number.
Another important behavior of the TCP/IP header is the dependency
between the sequence number and the acknowledgment number. It is well
known that most TCP connections only 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 acknowledgement number remains constant for most
packets; on the backward path (from client to server), only the
sequence number is changing and the acknowledgement number remains
constant for most packets.
With respect to TCP options, it is noted that most options (such as
MSS, WSopt, SACK-permitted, etc.) may appear only on a SYN segment.
Every implementation should (and we expect most will) ignore unknown
options on SYN segments.
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 [2].
3.3. Characteristics of Short-lived TCP Transfers
Recent studies shows that the majority of TCP flows are short-lived
transfers with an average and a median size no larger than 10KB.
Short-lived TCP transfers will degrade the performance of header
compression schemes that establish a new context by initially sending
full headers.
It is hard to improve the performance for a single, unpredictable,
short-lived connection. However, there are common cases where there
will be multiple TCP connections between the same pair of hosts. A
mobile user browsing several web pages from the same web server (this
is more the case with HTTP/1.0 than HTTP/1.1) is one example.
In such case, multiple short-lived TCP/IP flows occur simultaneously
or near simultaneously within a relatively short time interval. It
may be expected that most (if not all) of the IP header of the these
connections will be almost identical to each other, with only small
relative jumps for the IP-ID field.
Furthermore, a subset of the TCP fields may also be very similar from
one connection to another. For example, one of the port numbers may
be reused (the service port) while the other (the ephemeral port) may
be changed only by a small amount relative to the just-closed
connection.
With regard to header compression, this means that parts of a
compression context used for a TCP connection may be reusable for
Pelletier, et. al [Page 8]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
another TCP connection. A mechanism supporting context replication,
where a new context is initialized from an existing one, provide
useful optimizations for a sequence of short-lived TCP connections.
Context replication is possible due to the fact that there is much
similarity in header field values and context values among multiple
simultaneous or near simultaneous connections. All header fields and
related context values have been classified in detail in [11]. The
main 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.
4. Overview of the TCP/IP Profile
4.1. General Concepts
Many of the concepts behind the ROHC-TCP profile are similar to those
described in RFC 3095 [2]. Like for other ROHC profiles, ROHC-TCP
makes use of the ROHC protocol as described in [2], in sections 5.1
to 5.2.6. This includes data structures, reserved packet types,
general packet formats, segmentation and initial decompressor
processing.
4.2. Context Replication
For ROHC-TCP, context replication may be particularly useful for
short-lived TCP flows [10]. ROHC-TCP therefore supports context
replication as defined in ROHC-CR [3]; the compressor MAY support
context replication, while a decompressor implementation is REQUIRED
to support decompression of the IR-CR packet type.
4.3. State Machines and Profile Operation
Header compression with ROHC can be characterized as an interaction
between two state machines, one compressor machine and one
decompressor machine, each instantiated once per context.
For ROHC-TCP compression, the compressor has two states and the
decompressor has three states. The two compressor states are the
Initialization and Refresh (IR) state, and the Compression (CO)
state. The three states of the decompressor are No Context (NC),
Static Context (SC) and Full Context (FC). The compressor may also
implement a third state, the Context Replication (CR) state, to
support context replication ROHC-CR [3]. Transitions need not be
synchronized between the two state machines.
Pelletier, et. al [Page 9]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
4.4. Packet Formats and Encoding Methods
The packet formats used for ROHC-TCP and found in this document 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 [4].
4.5. Irregular Chain
The ROHC-TCP profile defines an irregular chain for each header type,
in addition to the static and dynamic chains as used in RFC 3095 [2].
The irregular chain handles fields for which no predictable change
pattern could be identified, i.e. fields from the TCP, IP and
extension headers that have an irregular behavior and therefore have
to be included in each compressed packet. This chain is attached to
compressed packet in order to make it possible to carry arbitrary
combinations of headers.
4.6. TCP Options
The list compression scheme in ROHC-TCP is a downscaled version of
the list compression in [2], allowing option content to be
established so that TCP options can be added or removed from the
packet without having to send the entire option uncompressed.
4.6.1. Compressing Extension Headers
In RFC 3095 [2], list compression is used to compress extension
headers. ROHC-TCP compresses the same type of extension headers as in
[2]. However, these headers are treated exactly as other headers and
thus have a static chain, a dynamic chain, an irregular chain and a
replicate chain.
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.
5. Compressor and decompressor State Machines
The header compression state machines and their associated logic as
specified in this section are a simplified version of the ones found
in [2].
Pelletier, et. al [Page 10]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
5.1. Compressor States and Logic
The two compressor states are the Initialization and Refresh (IR)
state, and the Compression (CO) state. The compressor always starts
in the lower compression state (IR). The compressor will normally
operate in the higher compression state (CO), under the constraint
that the compressor is sufficiently confident that the decompressor
has the information necessary to reconstruct a header compressed
according to this state.
The figure below shows the state machine for the compressor. The
details of each state, state transitions, and compression logic are
given in sub-sections following the figure.
Optimistic approach / ACK ACK
+------>------>------>------+ +->-+
| | | |
| v | v
+----------+ +----------+
| IR State | | CO State |
+----------+ +----------+
^ |
| Timeout / NACK / STATIC-NACK |
+-------<-------<-------<--------+
The transition from IR state to CO state is based on the following
principles: the need for update and the optimistic approach principle
or, if a feedback channel is established, feedback received from the
decompressor.
5.1.1. Initialization and Refresh (IR) State
The purpose of the IR state is to initialize the static parts of the
context at the decompressor or to recover after failure. In this
state, the compressor sends complete header information. This
includes static and non-static fields in uncompressed form plus some
additional information.
The compressor stays in the IR state until it is fairly confident
that the decompressor has received the static information correctly.
5.1.2. Compression (CO) State
The purpose of the CO state is to efficiently communicate
irregularities in the packet stream when needed while maintaining the
most optimal compression ratio. When operating in this state, the
compressor normally sends most or all of the information in a
compressed form.
Pelletier, et. al [Page 11]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
5.1.3. Feedback Logic
The compressor state machine makes use of feedback from decompressor
to compressor for transitions in the backward direction, and
optionally to improve the forward transition.
The reception of either positive feedback (ACKs) or negative feedback
(NACKs) establishes the feedback channel from the decompressor. Once
there is an established feedback channel, the compressor makes use of
this feedback for optionally improving the transitions among
different states. This helps increasing the compression efficiency by
providing the information needed for the compressor to achieve the
necessary confidence level. When the feedback channel is established,
it becomes superfluous for the compressor to send periodic refreshes.
5.1.4. State Transition Logic
The compressor makes its decisions about when to transit between the
IR and the CO states on the basis of:
- variations in the packet headers
- positive feedback from decompressor (Acknowledgements -- ACKs)
- negative feedback from decompressor (Negative ACKS -- NACKs)
- confidence level regarding error-free decompression of a packet
5.1.4.1. Optimistic Approach, Upward Transition
Transition to the CO state is carried out according to the optimistic
approach principle. This means that the compressor transits to the CO
state when it is fairly confident that the decompressor has received
enough information to correctly decompress packets sent according to
the higher compression state.
In general, there are many approaches where the compressor can obtain
such information. A simple and general approach can be achieved by
sending uncompressed or partial full headers periodically.
5.1.4.2. Optional Acknowledgements (ACKs), Upward Transition
The compressor can also transit to the CO state based on feedback
received by the decompressor. If a feedback channel is available, the
decompressor MAY use positive feedback (ACKs) to acknowledge
successful decompression of packets. Upon reception of an ACK for a
context-updating packet, the compressor knows that the decompressor
has received the acknowledged packet and the transition to the CO
state can be carried out immediately.
Pelletier, et. al [Page 12]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
This functionality is optional, so a compressor MUST NOT expect to
get such ACKs initially or during normal operation, even if a
feedback channel is available or established.
5.1.4.3. Timeouts, Downward Transition
When the optimistic approach is used (i.e. until a feedback channel
is established), there will always be a possibility of failure since
the decompressor may not have received sufficient information for
correct decompression. Therefore, unless the decompressor has
established a feedback channel, the compressor MUST periodically
transit to the IR state.
5.1.4.4. Negative ACKs (NACKs), Downward Transition
Negative acknowledgments (NACKs) are also called context requests.
Upon reception of a NACK, the compressor transits back to the IR
state and sends updates (such as IR-DYN or IR) to the decompressor.
5.1.4.5. Need for Updates, Downward Transition
When the header to be compressed does not conform to the established
pattern or when the compressor is not confident whether the
decompressor has the synchronized context, the compressor will
transit to the IR state.
5.1.5. State Machine Supporting Context Replication
For a profile supporting context replication, the additional
compressor logic (including corresponding state transition and
feedback logic) defined by ROHC-CR [3] must be added to the
compressor state machine described above.
Pelletier, et. al [Page 13]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
The following figure shows the resulting state machine:
Optimistic approach / ACK
+--->------>------>------>------>------>------>---+
| |
| BCID Selection Optimistic approach / ACK | ACK
| +------>----->------+ +----->----->----->-----+ | +->-+
| | | | | | | |
| | v | v v | v
+---------+ +---------+ +---------+
| IR | | CR | | CO |
| State | | State | | State |
+---------+ +---------+ +---------+
^ ^ | |
| | NACK / STATIC-NACK | |
| +---<-----<-----<----+ |
| |
| Timeout / NACK / STATIC-NACK |
+-----<-------<-------<-------<-------<-------<----+
5.2. 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.
Success
+-->------>------>------>------>------>--+
| |
No Static | No Dynamic Success | Success
+-->--+ | +-->--+ +--->----->---+ +-->--+
| | | | | | | | |
| v | | v | v | v
+-----------------+ +---------------------+ +-------------------+
| No Context (NC) | | Static Context (SC) | | Full Context (FC) |
+-----------------+ +---------------------+ +-------------------+
^ | ^ |
| k_2 out of n_2 failures | | k_1 out of n_1 failures |
+-----<------<------<-----+ +-----<------<------<-----+
Pelletier, et. al [Page 14]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
5.2.1. No Context (NC) State
Initially, while working in the NC state, the decompressor has not
yet successfully decompressed a packet.
Upon receiving an IR or an IR-DYN packet, the decompressor will
verify the correctness of this packet by validating its header using
the CRC check. If the decompressed packet is successfully verified,
the decompressor will update the context and use this packet as the
reference packet. Once a packet has been decompressed correctly, the
decompressor can transit to the FC state, and only upon repeated
failures will it transit back to a lower state.
5.2.2. Static Context (SC) State
In the SC state, the decompressor assumes static context damage when
the CRC check of k_2 out of the last n_2 decompressed packets have
failed. The decompressor moves to the NC state and discards all
packets until a packet (e.g. IR or IR-DYN packet) that successfully
passes the verification check is received. The decompressor may send
feedback (see section 5.2.7) when assuming static context damage.
Note that appropriate values for k and n, are related to the residual
error rate of the link. When the residual error rate is close to
zero, k = n = 1 may be appropriate.
5.2.3. Full Context (FC) State
In the FC state, the decompressor assumes context damage when the CRC
check of k_1 out of the last n_1 decompressed packets have failed,
(where k and n are related to the residual error rate of the link as
in section 5.2.2). The decompressor moves to the SC state and
discards all packets until a packet carrying a 7- or 8-bit CRC that
successfully passes the verification check is received. The
decompressor may send feedback (see section 5.2.7) when assuming
context damage.
Upon receiving an IR or an IR-DYN packet, the decompressor MUST
verify the correctness of its header using CRC validation. If the
verification succeeds, the decompressor will update the context and
use this packet as the reference packet. Consequently, the
decompressor will convert the packet into the original packet and
pass it to the network layer of the system.
Upon receiving other types of packet, the decompressor will
decompress it. The decompressor MUST verify the correctness of the
decompressed packet by CRC check. If this verification succeeds, the
decompressor passes the decompressed packet to the system's network
Pelletier, et. al [Page 15]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
layer. The decompressor will then use this packet as the reference
value.
If the received packet is older than the current reference packet
(based on sequence numbers in the compressed packet or in the
uncompressed header), the decompressor MAY refrain from using this
packet as the new reference value, even if the correctness of its
header was successfully verified.
5.2.4. Allowing Decompression
In the No Context state, only packets carrying sufficient information
on the static fields (i.e. IR packets) can be decompressed.
In the Static Context state, only packets carrying a 7- or 8-bit CRC
may be decompressed (i.e. IR, IR-DYN and some CO packets).
In the Full Context state, decompression may be attempted regardless
of the type of packet received.
If decompression may not be performed, the packet is discarded.
As per ROHC-CR [3], IR-CR packets may be decompressed in any state.
5.2.5. Reconstruction and Verification
The CRC carried within compressed headers MUST be used to verify
decompression. When the decompression is verified and successful, the
decompressor updates the context with the information received in the
current header; otherwise if the reconstructed header fails the CRC
check, these updates MUST NOT be performed.
5.2.6. Actions upon CRC Failure
When a CRC check fails, the decompressor MUST discard the packet. The
actions to be taken when CRC verification fails following the
decompression of an IR-CR packet are specified in [3]. For other
packet types carrying a CRC, if feedback is used the logic specified
in section 5.2.7 must be followed when CRC verification fails.
Note: Decompressor implementations may attempt corrective or repair
measures prior to performing the above actions, and the result of any
attempt MUST be verified using the CRC check.
Pelletier, et. al [Page 16]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
5.2.7. 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) will establish this
channel. The decompressor will then use the feedback channel to send
error recovery requests and (optionally) acknowledgements of
significant context updates.
Once the decompressor establishes a feedback channel, the compressor
will operate using an optimistic logic. In particular, this means
that the compressor will rely on specific decompressor feedback
logic:
- the decompressor will send negative acknowledgements in case
when context damage is assumed or in other failure situations;
- the decompressor is not strictly expected to send feedback upon
successful decompression, other than for the purpose of
improving the forward state transition.
Once the feedback channel is established, the decompressor is
REQUIRED to continue sending feedback (subject to the feedback rate
limiting considerations later in this section) for the lifetime of
the packet stream as follow:
In NC state:
The decompressor SHOULD send a STATIC-NACK if a packet of a type
other than IR is received, or if an IR packet has failed the CRC
check.
In SC state:
The decompressor SHOULD send a STATIC-NACK when decompression of
an IR, an IR-DYN or a CO packet carrying a 7-bit CRC fails and
if static context damage is assumed (see also section 5.2.2).
If any other packet type is received, the decompressor SHOULD
treat it as a CRC mismatch when deciding if feedback is to be
sent.
In FC state:
The decompressor SHOULD send a NACK when decompression of any
packet type fails and if context damage is assumed (see also
section 5.2.3).
When decompression fails, the feedback rate SHOULD be limited. For
example, feedback could be sent only when decompression of several
consecutive packets have failed. In addition, the decompressor should
also limit the rate at which feedback is sent on successful
Pelletier, et. al [Page 17]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
decompression, if sent at all. The decompressor may limit the
feedback rate by sending feedback for one out of a number of packets
providing the same type of feedback.
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 7- or 8-bit CRC is correctly
decompressed, the compressor may optionally send an ACK.
Finally, when the decompressor ACKs an IR packet, it MUST use the CRC
option (see [2], section 5.7.6.3) when sending this feedback. This is
necessary to ensure that a context does not erroneously become a
candidate for later use as a base context for replication [3].
6. ROHC-TCP - TCP/IP Compression (Profile 0x0006)
This section describes a ROHC profile for TCP/IP compression. The
profile identifier for ROHC-TCP is 0x0006.
6.1. 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.1.1. inferred_mine_header_checksum()
This encoding method compresses the minimal encapsulation header
checksum. This checksum is defined in RFC 2004 [25] as follow:
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.
Pelletier, et. al [Page 18]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
6.1.2. inferred_ip_v4_header_checksum()
This encoding method compresses the header checksum field of the IPv4
header. This checksum is defined in RFC 791 [5] 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.
The "inferred_ip_v4_header_checksum()" 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 using the
above computation.
6.1.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 [5] 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.1.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 [9] as follow:
Payload Length: 16-bit unsigned integer
Pelletier, et. al [Page 19]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
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.1.5. inferred_offset()
This encoding method compresses
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.
6.1.6. Scaled TCP Sequence Number Encoding
On some TCP streams, such as data transfers, the payload size will be
constants over periods of time. For such streams, 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
Pelletier, et. al [Page 20]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
numbers, 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.
Packets incoming to the compressor for which the value of the residue
is different than the one that has previously been established MUST
be sent in a compressed packet that carry the sequence number
compressed using its unscaled representation, until a stable residue
value can once again be established at the decompressor.
Note that 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.
Note also that the scaling function applied to the TCP sequence
number does not use an explicit scaling factor, such as the TS_STRIDE
used in RFC 3095 [2]. 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.
6.1.7. Scaled Acknowledgement Number Encoding
Similar to the pattern exhibited by sequence numbers, the expected
increase in the TCP Acknowledgment number will often be a multiple of
the packet size. For the 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 Acknowledgement 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
Acknowledgement Number.
For the compressor to use the scaled acknowledgement number encoding,
it MUST first explicitly transmit the value of the scaling factor
(ack_stride) 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
acknowledgement number. This is done the same way as for the scaled
sequence number encoding (see section 6.1.6 above).
Pelletier, et. al [Page 21]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
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 compress
packets using the scaled representation of the Acknowledgement
Number. The compressor MUST NOT use the scaled acknowledgement number
encoding with the value of the scaling factor (ack_stride) set to
zero.
The compressor MAY use the scaled acknowledgement 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 acknowledgement numbers can be set to the
same value as the scaling factor of the sequence numbers used for
that flow.
6.2. Considerations for the Feedback Channel
The ROHC-TCP profile may 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 is
used at least once by the decompressor, this channel will be present
during the entire compression operation. Otherwise, if the connection
is broken and the channel disappears, header compression should be
restarted.
To parallel RFC 3095 [2], 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.
6.3. Control Fields in the ROHC-TCP Context
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.
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. These control fields are not a part of the
uncompressed header, but are explicitly transmitted inside ROHC-TCP
packets. Once established at the decompressor, the values of these
fields should be kept until updated by another packet.
Pelletier, et. al [Page 22]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
6.3.1. Master Sequence Number (MSN)
Feedback packets of types ACK and NACK carry information about
sequence number or acknowledgement number from decompressor to
compressor. Unfortunately, there is no guarantee that sequence number
and acknowledgement number fields will be used by every IP protocol
stack. In addition, the combined size of the sequence number field
and the acknowledgement number field is rather large, and they can
therefore not be carried efficiently within the feedback packet.
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 packets 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.
When the MSN is initialized, it is 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 monotonously.
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
context being associated with the new flow (CID); otherwise, the MSN
is initialized to a new value.
6.3.2. IP-ID Behavior
The IP-ID field of the Ipv4 header can have different change
patterns. RFC 3095 [2] describes three behaviors: sequential (NBO),
sequential byteswapped, and random (RND). In addition, this profile
uses a fourth behavior, the constant zero IP-ID behavior as defined
in RFC 3843 [12] (SID).
Pelletier, et. al [Page 23]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
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 the identified field behavior.
If more than one level of IP headers is present, ROHC-TCP can assign
a sequential behavior (NBO or byteswapped) only to the IP-ID of
innermost IP header. This is because only this IP-ID is likely to
have a close correlation with the MSN (see also section 6.3.1).
Therefore, a compressor MUST assign either the constant zero IP-ID or
the random behavior to tunneling headers.
The IP-ID behavior control fields are transmitted in certain packet
formats, as a two-bit field and for each IP header. When the
compressor sends compressed packets, this control field is used to
determine which set of packet formats will be used. Note these
control fields are also used to determine the contents of the
irregular chain item for each IP header.
6.3.3. Explicit Congestion Notification (ECN) in ROHC-TCP
When ECN is used once on a stream, it can be expected that ECN bits
will be 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 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 [23].
6.4. CRC Calculations
The 3-bit and 7-bit CRCs both cover the entire uncompressed header
chain. Note that there is no division between CRC-STATIC or CRC-
DYNAMIC fields in ROHC-TCP, as opposed to profiles defined in [2].
6.5. Initialization
The static context of ROHC TCP streams can be initialized in either
two ways:
Pelletier, et. al [Page 24]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
1) By using an IR packet as in section 7.3, 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.4,
where the profile number is six (6).
7. Packet Types
ROHC-TCP defines two different packet types: the Initialization and
Refresh (IR) packet type, and the Compressed packet type (CO). Each
type corresponds to one of the possible states of the compressor.
Each packet type also defines a number of packet formats: [TBD]
packet formats are defined for compressed headers (CO), and two for
initialization and refresh (IR).
Finally, the profile-specific part of the IR-CR packet [3] is also
defined in this section.
7.1. Compressed Header Chains
Some packet types use one or more chains containing sub-header
information. The function of a chain is to group items based on
similar characteristics, i.e. grouping fields that either are static,
dynamic or irregular in behavior. Chaining is done by appending each
item to the chain in their order of appearance in the original
header, starting from the fields in the outermost header.
Static chain:
The static chain is consists of one item for each header of the
chain of 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
named format_<protocol name>_static.
Dynamic chain:
The dynamic chain consists of one item for each header of the chain
of 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 7.2). In the formal description of the
packet formats, this dynamic chain item for each header type is
named format_<protocol name>_dynamic.
Pelletier, et. al [Page 25]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
Replicate chain:
The replicate chain consists of one item for each header in the
header chain 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 7.2). In the formal description of
the packet formats, this replicate chain item for each header type
is named format_<protocol name>_replicate. Header fields that are
not present in the replicate chain are replicated from the base
context.
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.5. This chain
also includes the irregular chain items for TCP options as defined
in section 7.2.7.
Note that 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. The name of the
chain item for the innermost header is postfixed
with_innermost_irregular, while the irregular chain item for outer
IP headers is postfixed by_outer_irregular. The format of the
irregular chain item for the outer IP headers also determined using
a flag for TTL/Hoplimit; this flag can be present in some
compressed base headers.
7.2. 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 format_[option_type]_list_item format and a
format_[option_type]_irregular format, where [option_type] is the
name of the actual field item in the option list.
7.2.1. List Compression
The TCP options in the uncompressed packet can be structured as an
ordered list, whose order and presence are most of the time constant
between packets. The generic structure of such a list is as follows:
Pelletier, et. al [Page 26]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
+--------+--------+--...--+--------+
list: | item 1 | item 2 | | item n |
+--------+--------+--...--+--------+
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 to the decompressor.
Then, once the context has been initialized:
2) When the structure AND the content of the list are not
changing, no information about the list is sent in compressed
headers.
3) When the structure of the list is constant, and when only the
content of one or more options that are defined within the
irregular format is changing, 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
7.2.7) in the generalcompressed packet format (section 7.5).
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.
7.2.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 L (Index, Item) pairs (not necessarily consecutively). The
value for L is maintained by the compressor. 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.
Pelletier, et. al [Page 27]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
Decompressor Logic
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.
7.2.3. Item Tables
Compressor Logic
The compressor uses the following structure to represent an entry
in the Item Table:
+-------+------+---------+--------------------------+
Index i | Known | Item | Counter | MSN_1, MSN_2, ..., MSN_L |
+-------+------+---------+--------------------------+
The flag "Known" indicates whether the mapping between Index i and
Item has been established, i.e., if Index i can be sent in
compressed lists without its corresponding Item.
The "Counter" field is useful to obtain confidence that the
context at the decompressor contains the (Index, Item) pair.
The list of sequence numbers, [MSN 1, ..., MSN L], is useful in
relating an acknowledgment received from the decompressor with the
(Index, Item) pair, meaning that it is now part of the
decompressor context.
The flag "Known" is initially set to a value of zero. It is also
set to zero whenever Index i is assigned to a new Item. "Known" is
set to a non-zero value when either of the following occur:
a) The corresponding (Index, Item) pair is acknowledged;
b) Counter >= L (confidence based of the optimistic approach).
When the compressor sets the flag "Known", the list of sequence
numbers can be discarded.
Decompressor Logic
The decompressor uses the following structure to represent an
entry in the Item Table:
+-------+------+
Index i | Known | item |
+-------+------+
Pelletier, et. al [Page 28]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
The flag "Known" is initially set to a value of zero. "Known" is
set to a non-zero value when the decompressor receives an (Index,
Item) pair and inserts the item "Item" into the table at position
"Index".
If an index without an accompanying item is received for which the
value of the "Known" flag is zero, the header MUST be discarded
and a NACK SHOULD be sent.
7.2.4. Constraints to List Compression
List compression, as defined in the ROHC-FN [4], allows 7-bit indexes
to be used in the Item table. For ROHC-TCP, the compressor MUST use
the low-order 4 bits of the item count (i.e. large_xi of [4], section
5.5.5) to describe an index. In other words, the compressor MUST NOT
map items with indexes larger than a value of 15. This is because no
more than 16 different options are expected to be used in a TCP flow.
7.2.5. Item Table Mappings
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. The decompressor MUST use
these mappings between item and indexes to decompress TCP options
compressed using list compression.
The compressor can thus omit from the compressed packet format an
option type that corresponds to a reserved item in the item table.
This is because the type of the option can be known based on the
index number.
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
Pelletier, et. al [Page 29]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
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.
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 do not have a reserved index in the item table.
7.2.6. Compressed Lists in Dynamic Chain
When a compressed list for TCP options is part of the dynamic chain
(i.e. IR or IR-DYN packets), the compressed list must have all its
list items present, i.e. all x-bits in the XI list must be set.
7.2.7. 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 expected to stay static 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 current TCP options in the uncompressed packet. If a
compressed type 0 list is present in the compressed packet, then the
Pelletier, et. al [Page 30]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
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
current list, MUST have their respective irregular items present in
the irregular chain.
7.2.8. 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 current list of options
for the new flow is also transmitted as a generic compressed list in
the IR-CR packet.
7.3. Initialization and Refresh Packets (IR)
ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets
as defined in [2] (section 5.2.3. and 5.2.4. respectively). The 8-bit
CRC is computed according to section 5.9.1 of [2].
o Packet type: IR
This packet type communicates the static part and the dynamic part
of the context.
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 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Static chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Dynamic chain / variable length
| |
Pelletier, et. al [Page 31]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
CRC: 8-bit CRC, computed according to section 5.9.1 of [2].
Static chain: See section 7.1.
Dynamic chain: See section 7.1.
Payload: The payload of the corresponding original packet, if
any. The presence of a payload is inferred from the packet
length.
o Packet type: IR-DYN
This packet type communicates the dynamic part of the context.
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 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Profile_Specific_Part / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
CRC: 8-bit CRC, computed according to section 5.9.1 of [2].
Dynamic chain: See section 7.1.
Payload: The payload of the corresponding original packet, if
any. The presence of a payload is inferred from the packet length.
Pelletier, et. al [Page 32]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
7.4. 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.
o 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 [3], section 3.4.2. With consideration
to the extensibility of the IR packet type defined in RFC 3095 [2],
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 | 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
| |
- - - - - - - - - - - - - - - -
Pelletier, et. al [Page 33]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
B: B = 1 indicates that the Base CID field is present.
CRC7: The CRC over the original, uncompressed, header. This 7-bit
CRC is computed according to section 3.4.1.1 of [3].
Replicate chain: See section 7.1.
Payload: The payload of the corresponding original packet, if
any. The presence of a payload is inferred from the packet length.
7.5. 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
: :
--- --- --- --- --- --- --- ---
The base header in the figure above is 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.8.
Irregular chain: See section 7.1.
TCP options irregular part: See section 7.2.7.
Pelletier, et. al [Page 34]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8. Packet Formats
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 [4]. 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 [4] for an explanation of the formal
notation itself, and the encoding methods used to compress each of
the fields in the TCP/IP header.
Note that the formal definition of the packet formats for ROHC-TCP
includes comments that follow a specific syntax. These comments,
called annotations, make use of square brackets as delimiters;
numbers in between the "[" and the "]" are used to provide additional
information about the expected number of bits for the field(s) that
appears as a right-hand operand. These are not normative in any way.
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 behaviour. 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 and ECN behaviour.
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:
o MSN
Since the MSN is a number generated by the compressor, it only
Pelletier, et. al [Page 35]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
needs to be large enough to ensure robust operation and to
accommodate a small amount of reordering. Therefore, each
compressed base header contains 4 bits of MSN. To handle
reordering, the LSB offset value is set to p=4.
o Sequence number
For ROHC-TCP compression to have the capability to handle bulk data
transfers efficiently, and for such connections, 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.
o Acknowledgement number
The design criterion for the acknowledgement number is similar to
that of the 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 acknowledgement number should be used in compressed base
headers. Since the acknowledgement number is expected to constantly
increase, and the only exception to this is packet reordering
(either on link or pre-link), the negative offset for LSB encoding
is set to be 25% of the total interval, i.e. p=2^(k-2)-1. The
offset value p has been set the same way as for the sequence number
(p=2^(k-1)-1).
o Window
The TCP window field is expected to increase in increments of
similar size as the sequence number, and therefore the design
criterion for the TCP window has been to send at least 14 bits when
used.
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.
Pelletier, et. al [Page 36]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
Each set of packet formats contains 10 different compressed base
headers. The reason for having this large number of packets is that
the TCP sequence number, TCP acknowledgement number, TCP window and
MSN are frequently changing in a non-linear pattern. All of the
compressed base headers transmit a LSB-encoded MSN, 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.
The following packet formats exist in both the sequential and random
packet format sets:
- Format 1: This packet format transmits changes to the TCP sequence
number and its principal use should be on the downstream of a data
transfer.
- Format 2: This packet format transmits the TCP sequence number in
scaled form, and will normally be used on the downstream of a data
transfer where the payload size is constant for multiple packets.
- Format 3: This packet format transmits changes in the TCP
acknowledgement number, and will be used in the acknowledgement
direction of data transfer.
- Format 4: This packet format is similar to format 3, but sends
scaled Acknowledgement number.
- Format 5: This packet format transmits both the TCP sequence number
and the acknowledgement number, and should be particularly useful
for streams that send data in both directions.
- Format 6: This packet format is similar to format 5, but sends the
sequence number in scaled form, when the payload size is static for
certain intervals in a data stream.
- Format 7: This packet format transmits changes to both the TCP
sequence number and the TCP window, and is expected to be useful
for any type of data transfer.
- Format 8: This packet format transmits changes to both the TCP
acknowledgement number and the TCP window, and is expected to be
useful for the acknowledgement streams of data connections.
- Format 9: This packet format is similar to format 7, but sends the
sequence number in scaled form to allow higher compression rates on
streams with a constant payload size,
- Format 10: This packet format is used to transmit changes to some
of the more seldom changing fields in the streams, such as ECN
behaviour, Reset/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
Pelletier, et. al [Page 37]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
this can be seen as a reduced form of the common packet format.
- Common packet format: The common packet format can be used for all
kinds of IP-ID behaviour, and should be used when some of the more
rarely changing fields in the IP or TCP header changes. Since this
packet format can be used to change what set of packet formats is
to be used for future 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 control which fields that are present in the
packet.
8.2. Global Control Fields
control_fields = ecn_used, %[ 1 ]
msn, %[ 16 ]
ip_inner_ecn, %[ 2 ]
seq_number_scaled, %[ 32 ]
seq_number_residue, %[ 32 ]
ack_stride, %[ 16 ]
ack_number_scaled, %[ 16 ]
ack_number_residue; %[ 16 ]
8.3. General Structures
static_or_irreg32(flag) ===
{
uc_format = field; %[ 32 ]
co_format_irreg_enc = field, %[ 32 ]
{
let (flag == 1);
field ::= irregular(32);
};
co_format_static_enc = field, %[ 0 ]
{
let (flag == 0);
field ::= static;
};
};
static_or_irreg16(flag) ===
{
uc_format = field; %[ 16 ]
co_format_irreg_enc = field, %[ 16 ]
{
let (flag == 1);
Pelletier, et. al [Page 38]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
field ::= irregular(16);
};
co_format_static_enc = field, %[ 0 ]
{
let (flag == 0);
field ::= static;
};
};
static_or_irreg8(flag) ===
{
uc_format = field; %[ 8 ]
co_format_irreg_enc = field, %[ 8 ]
{
let (flag == 1);
field ::= irregular(8);
};
co_format_static_enc = field, %[ 0 ]
{
let (flag == 0);
field ::= static;
};
};
variable_length_32_enc(flag) ===
{
uc_format = field; %[ 32 ]
co_format_not_present = field, %[ 0 ]
{
let(flag == 0);
field ::= static;
};
co_format_8_bit = field, %[ 8 ]
{
let(flag == 1);
field ::= lsb(8, 63);
};
co_format_16_bit = field, %[ 16 ]
{
let(flag == 2);
field ::= lsb(16, 16383);
};
co_format_32_bit = field, %[ 32 ]
{
let(flag == 3);
field ::= irregular(32);
};
};
Pelletier, et. al [Page 39]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
variable_length_16_enc(flag) ===
{
uc_format = field; %[ 16 ]
co_format_not_present = field, %[ 0 ]
{
let(flag == 0);
field ::= static;
};
co_format_8_bit = field, %[ 8 ]
{
let(flag == 1);
field ::= lsb(8, 63);
};
co_format_16_bit = field, %[ 16 ]
{
let(flag == 2);
field ::= irregular(16);
};
};
optional32 (flag) ===
{
uc_format = item; % 0 or 32 bits
co_format_present = item, %[ 32 ]
{
let (flag == 1);
item ::= irregular (32);
};
co_format_not_present = item, %[ 0 ]
{
let (flag == 0);
item ::= compressed_value (0, 0);
};
};
lsb_7_or_31 ===
{
uc_format = item; % 7 or 31 bits
co_format_lsb_7 = discriminator, %[ 1 ]
item, %[ 7 ]
{
discriminator ::= '0';
item ::= lsb (7, 8);
};
Pelletier, et. al [Page 40]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
co_format_lsb_31 = discriminator, %[ 1 ]
item, %[ 31 ]
{
discriminator ::= '1';
item ::= lsb (31, 256);
};
};
opt_lsb_7_or_31 (flag) ===
{
uc_format = item; % 32 bits
co_format_present = item, % 8 or 32 bits
{
let (flag == 1);
item ::= lsb_7_or_31;
};
co_format_not_present = item, %[ 0 ]
{
let (flag == 0);
item ::= compressed_value (0, 0);
};
};
crc3 (data_value, data_length) ===
{
uc_format = ;
co_format = crc_value, %[ 3 ]
{
crc_value ::= crc(3, 0x06, 0x07, data_value, data_length);
};
};
crc7 (data_value, data_length) ===
{
uc_format = ;
co_format = crc_value, %[ 7 ]
{
crc_value ::= crc(7, 0x79, 0x7f, data_value, data_length);
};
};
Pelletier, et. al [Page 41]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8.4. Extension Headers
8.4.1. IPv6 DEST opt header
ip_dest_opt ===
{
uc_format = next_header, %[ 8 ]
length, %[ 8 ]
value; % n bits
default_methods =
{
next_header ::= static;
length ::= static;
value ::= static;
};
co_format_dest_opt_static = next_header, %[ 8 ]
length, %[ 8 ]
{
next_header ::= irregular(8);
length ::= irregular(8);
};
co_format_dest_opt_dynamic = value, % n bits
{
value ::= irregular(length:uncomp_value * 64 + 48);
};
co_format_dest_opt_replicate_0 = discriminator, %[ 8 ]
{
discriminator ::= '00000000';
};
co_format_dest_opt_replicate_1 = discriminator, %[ 8 ]
length, %[ 8 ]
value, % n bits
{
discriminator ::= '10000000';
length ::= irregular(8);
value ::= irregular(length:uncomp_value * 64 + 48);
};
};
Pelletier, et. al [Page 42]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8.4.2. IPv6 HOP opt header
ip_hop_opt ===
{
uc_format = next_header, %[ 8 ]
length, %[ 8 ]
value; % n bits
default_methods =
{
next_header ::= static;
length ::= static;
value ::= static;
};
co_format_hop_opt_static = next_header, %[ 8 ]
length, %[ 8 ]
{
next_header ::= irregular(8);
length ::= irregular(8);
};
co_format_hop_opt_dynamic = value, % n bits
{
value ::= irregular(length:uncomp_value * 64 + 48);
};
co_format_hop_opt_replicate_0 = discriminator, %[ 8 ]
{
discriminator ::= '00000000';
};
co_format_hop_opt_replicate_1 = discriminator, %[ 8 ]
length, %[ 8 ]
value, % n bits
{
discriminator ::= '10000000';
length ::= irregular(8);
value ::= irregular(length:uncomp_value * 64 + 48);
};
};
8.4.3. IPv6 Routing Header
ip_rout_opt ===
{
uc_format = next_header, %[ 8 ]
length, %[ 8 ]
value; % n bits
Pelletier, et. al [Page 43]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
default_methods =
{
next_header ::= static;
length ::= static;
value ::= static;
};
co_format_rout_opt_static = next_header, %[ 8 ]
length, %[ 8 ]
value, % n bits
{
next_header ::= irregular(8);
length ::= irregular(8);
value ::= irregular(length:uncomp_value * 64 + 48);
};
co_format_rout_opt_dynamic =
{
};
co_format_rout_opt_replicate_0 = discriminator, %[ 8 ]
{
discriminator ::= '00000000';
};
co_format_rout_opt_replicate_1 = discriminator, %[ 8 ]
length, %[ 8 ]
value, % n bits
{
discriminator ::= '10000000';
length ::= irregular(8);
value ::= irregular(length:uncomp_value * 64 + 48);
};
};
8.4.4. GRE Header
optional_checksum (flag_value) ===
{
uc_format = value, % 0 or 16 bits
reserved1; % 0 or 16 bits
co_format_cs_present = value, %[ 16 ]
reserved1, %[ 0 ]
{
let (flag_value == 1);
value ::= irregular (16);
reserved1 ::= uncompressed_value (16, 0);
};
Pelletier, et. al [Page 44]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
co_format_not_present = value, %[ 0 ]
reserved1, %[ 0 ]
{
let (flag_value == 0);
value ::= compressed_value (0, 0);
reserved1 ::= compressed_value (0, 0);
};
};
gre_proto ===
{
uc_format = protocol; %[ 16 ]
default_methods =
{
};
co_format_ether_v4 = discriminator, %[ 1 ]
{
discriminator ::= compressed_value (1, 0);
protocol ::= uncompressed_value (16, 0x0800);
};
co_format_ether_v6 = discriminator, %[ 1 ]
{
discriminator ::= compressed_value (1, 1);
protocol ::= uncompressed_value (16, 0x86DD);
};
};
gre ===
{
uc_format = c_flag, %[ 1 ]
r_flag, %[ 1 ]
k_flag, %[ 1 ]
s_flag, %[ 1 ]
reserved0, %[ 9 ]
version, %[ 3 ]
protocol, %[ 16 ]
checksum_and_res, % 0 or 32 bits
key, % 0 or 32 bits
sequence_number; % 0 or 32 bits
default_methods =
{
c_flag ::= static;
r_flag ::= static;
k_flag ::= static;
s_flag ::= static;
reserved0 ::= uncompressed_value (9, 0);
version ::= static;
Pelletier, et. al [Page 45]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
protocol ::= static;
key ::= static;
checksum_and_res ::= optional_checksum (c_flag:uncomp_value);
};
co_format_gre_static = protocol, %[ 1 ]
c_flag, %[ 1 ]
r_flag, %[ 1 ]
k_flag, %[ 1 ]
s_flag, %[ 1 ]
version, %[ 3 ]
key, % 0 or 32 bits
{
protocol ::= gre_proto;
c_flag ::= irregular (1);
r_flag ::= irregular (1);
k_flag ::= irregular (1);
s_flag ::= irregular (1);
version ::= irregular (3);
key ::= optional32 (k_flag:uncomp_value);
sequence_number ::= static;
};
co_format_gre_dynamic = checksum_and_res, % 0 or 16 bits
sequence_number, % 0 or 32 bits
{
sequence_number ::= optional32 (s_flag:uncomp_value);
};
co_format_gre_replicate_0 = discriminator, %[ 8 ]
checksum_and_res, % 0 or 16 bits
sequence_number, % 0, 8 or 32 bits
{
discriminator ::= '00000000';
sequence_number ::= opt_lsb_7_or_31 (s_flag:uncomp_value);
};
co_format_gre_replicate_1 = discriminator, %[ 8 ]
c_flag, %[ 1 ]
r_flag, %[ 1 ]
k_flag, %[ 1 ]
s_flag, %[ 1 ]
reserved, %[ 1 ]
version, %[ 3 ]
checksum_and_res, % 0 or 16 bits
key, % 0 or 32 bits
sequence_number, % 0 or 32 bits
{
discriminator ::= '10000000';
c_flag ::= irregular (1);
Pelletier, et. al [Page 46]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
r_flag ::= irregular (1);
k_flag ::= irregular (1);
s_flag ::= irregular (1);
reserved ::= '0';
version ::= irregular (3);
key ::= optional32 (k_flag:uncomp_value);
sequence_number ::= optional32 (s_flag:uncomp_value);
};
co_format_gre_irregular = checksum_and_res, % 0 or 16 bits
sequence_number, % 0, 8 or 32 bits
{
sequence_number ::= opt_lsb_7_or_31 (s_flag:uncomp_value);
};
};
8.4.5. MINE header
mine ===
{
uc_format = next_header, %[ 8 ]
s_bit, %[ 1 ]
res_bits, %[ 7 ]
checksum, %[ 16 ]
orig_dest, %[ 32 ]
orig_src; % 0 or 32 bits
default_methods =
{
next_header ::= static;
s_bit ::= static;
res_bits ::= static;
checksum ::= inferred_mine_header_checksum;
orig_dest ::= static;
orig_src ::= static;
};
co_format_mine_static = next_header, %[ 8 ]
s_bit, %[ 1 ]
res_bits, %[ 7 ]
orig_dest, %[ 32 ]
orig_src, % 0 or 32 bits
{
next_header ::= irregular (8);
s_bit ::= irregular (1);
res_bits ::= irregular (7);
% include reserved - no benefit in removing them
orig_dest ::= irregular (32);
orig_src ::= optional32 (s_bit:uncomp_value);
};
Pelletier, et. al [Page 47]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
co_format_mine_dynamic =
{
};
co_format_mine_replicate_0 = discriminator, %[ 8 ]
checksum, %[ 0 ]
{
discriminator ::= '00000000';
};
co_format_mine_replicate_1 = discriminator, %[ 8 ]
s_bit, %[ 1 ]
res_bits, %[ 7 ]
orig_dest, %[ 32 ]
orig_src, % 0 or 32 bits
{
discriminator ::= '10000000';
s_bit ::= irregular (1);
res_bits ::= irregular (7);
orig_dest ::= irregular (32);
orig_src ::= optional32 (s_bit:uncomp_value);
};
};
8.4.6. Authentication Header (AH) header
ah ===
{
uc_format = next_header, %[ 8 ]
length, %[ 8 ]
res_bits, %[ 16 ]
spi, %[ 32 ]
sequence_number, %[ 32 ]
auth_data; % n bits
default_methods =
{
next_header ::= static;
length ::= static;
res_bits ::= static;
spi ::= static;
sequence_number ::= static;
auth_data ::= irregular (length:uncomp_value * 32 - 32);
};
co_format_ah_static = next_header, %[ 8 ]
length, %[ 8 ]
spi, %[ 32 ]
{
next_header ::= irregular(8);
Pelletier, et. al [Page 48]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
length ::= irregular (8);
spi ::= irregular (32);
};
co_format_ah_dynamic = res_bits, %[ 16 ]
sequence_number, %[ 32 ]
auth_data, % n bits
{
res_bits ::= irregular (16);
sequence_number ::= irregular (32);
};
co_format_ah_replicate_0 = discriminator, %[ 8 ]
sequence_number, % 8 or 32 bits
auth_data, % n bits
{
discriminator ::= '00000000';
sequence_number ::= lsb_7_or_31;
};
co_format_ah_replicate_1 = discriminator, %[ 8 ]
length, %[ 8 ]
res_bits, %[ 16 ]
spi, %[ 32 ]
sequence_number, %[ 32 ]
auth_data, % n bits
{
discriminator ::= '10000000';
length ::= irregular (8);
res_bits ::= irregular (16);
spi ::= irregular (32);
sequence_number ::= irregular (32);
};
co_format_ah_irregular = sequence_number, % 8 or 32 bits
auth_data, % n bits
{
sequence_number ::= lsb_7_or_31;
};
};
8.4.7. Encapsulation Security Payload (ESP) header
esp_null ===
{
uc_format = spi, %[ 32 ]
sequence_number, %[ 32 ]
next_header; %[ 8 ]
default_methods =
Pelletier, et. al [Page 49]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
{
spi ::= static;
% Next header will always be present in the trailer part,
% but sometimes it will ALSO be present in the header
% (static chain only).
nh_field ::= static; % Control field
next_header ::= static;
sequence_number ::= static;
};
co_format_esp_static = nh_field, %[ 8 ]
spi, %[ 32 ]
{
% identify next header assume next 96 bits skipped
% to get to end of packet (i.e. this is anchored
%from the end of the packet, not the start)
nh_field ::= compressed_value(8, next_header:uncomp_value);
next_header ::= irregular (8); % At packet end!
spi ::= irregular (32);
};
co_format_esp_dynamic = sequence_number, %[ 32 ]
{
sequence_number ::= irregular (32);
};
co_format_esp_replicate_0 = discriminator, %[ 8 ]
sequence_number, % 8 or 32 bits
{
discriminator ::= '00000000';
sequence_number ::= lsb_7_or_31;
};
co_format_esp_replicate_1 = discriminator, %[ 8 ]
spi, %[ 32 ]
sequence_number, %[ 32 ]
{
discriminator ::= '10000000';
spi ::= irregular (32);
sequence_number ::= irregular (32);
};
co_format_esp_irregular = sequence_number, % 8 or 32 bits
{
sequence_number ::= lsb_7_or_31;
};
};
Pelletier, et. al [Page 50]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8.5. IP Header
8.5.1. Structures Common for IPv4 and IPv6
irreg_tos_tc ===
{
uc_format = tos_tc; %[ 6 ]
co_format_tos_tc_present = tos_tc, %[ 6 ]
{
let(ecn_used:uncomp_value == 1);
tos_tc ::= irregular (6);
};
co_format_tos_tc_not_present = tos_tc, %[ 0 ]
{
let(ecn_used:uncomp_value == 0);
tos_tc ::= static;
};
};
ip_irreg_ecn ===
{
uc_format = ip_ecn_flags; %[ 2 ]
co_format_tc_present = ip_ecn_flags, %[ 2 ]
{
let(ecn_used:uncomp_value == 1);
ip_ecn_flags ::= irregular (2);
};
co_format_tc_not_present = ip_ecn_flags, %[ 0 ]
{
let(ecn_used:uncomp_value == 0);
ip_ecn_flags ::= static;
};
};
8.5.2. IPv6 Header
fl_enc ===
{
uc_format = flow_label;
co_format_fl_zero = discriminator, %[ 1 ]
flow_label, %[ 0 ]
reserved, %[ 4 ]
{
discriminator ::= '0';
flow_label ::= uncompressed_value (20, 0);
Pelletier, et. al [Page 51]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
reserved ::= '0000';
};
co_format_fl_non_zero = discriminator, %[ 1 ]
flow_label, %[ 20 ]
{
discriminator ::= '1';
flow_label ::= irregular (20);
};
};
% The argument flag should only be used if this
% flag was set when processing a compressed base
% header, if not, the flag should be zero.
ipv6 (ttl_irregular_chain_flag) ===
{
uc_format = version, %[ 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_methods =
{
version ::= uncompressed_value (4, 6);
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;
};
co_format_ipv6_static = version_flag, %[ 1 ]
reserved, %[ 2 ]
flow_label, % 5 or 21 bits
next_header, %[ 8 ]
src_addr, %[ 128 ]
dst_addr, %[ 128 ]
{
version_flag ::= '1';
reserved ::= '00';
flow_label ::= fl_enc;
next_header ::= irregular (8);
src_addr ::= irregular(128);
Pelletier, et. al [Page 52]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
dst_addr ::= irregular(128);
};
co_format_ipv6_dynamic = tos_tc, %[ 6 ]
ip_ecn_flags, %[ 2 ]
ttl_hopl, %[ 8 ]
{
tos_tc ::= irregular (6);
ip_ecn_flags ::= irregular (2);
ttl_hopl ::= irregular (8);
};
co_format_ipv6_replicate = tos_tc, %[ 6 ]
ip_ecn_flags, %[ 2 ]
{
tos_tc ::= irregular (6);
ip_ecn_flags ::= irregular (2);
};
co_format_ipv6_outer_irregular_without_ttl
= tos_tc, % 0 or 6 bits
ip_ecn_flags, % 0 or 2 bits
{
% for 'outer' headers only, irregular chain is required
tos_tc ::= irreg_tos_tc;
ip_ecn_flags ::= ip_irreg_ecn;
let(ttl_irregular_chain_flag == 0);
};
co_format_ipv6_outer_irregular_with_ttl
= tos_tc, % 0 or 6 bits
ip_ecn_flags, % 0 or 2 bits
ttl_hopl, %[ 8 ]
{
% for 'outer' headers only, irregular chain is required
tos_tc ::= irreg_tos_tc;
ip_ecn_flags ::= ip_irreg_ecn;
let(ttl_irregular_chain_flag == 1);
ttl_hopl ::= irregular(8);
};
% Note that the ECN bits are stored in the global control field
% so that they can be output in TCP irregular chain.
co_format_ipv6_innermost_irregular =
{
let(ip_inner_ecn:uncomp_value ==
ip_ecn_flags:uncomp_value);
};
};
Pelletier, et. al [Page 53]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8.5.3. IPv4 Header
ip_id_enc_dyn (behavior) ===
{
uc_format = ip_id; %[ 16 ]
co_format_ip_id_seq = ip_id, %[ 16 ]
{
let ((behavior == 0) || (behavior == 1) || (behavior == 2));
% In dynamic chain, but random, seq, and seq-swapped are 16 bits
ip_id ::= irregular(16);
};
co_format_ip_id_zero = ip_id, %[ 0 ]
{
let (behavior == 3);
% Zero IPID
ip_id ::= uncompressed_value (16, 0);
};
};
ip_id_enc_irreg (behavior) ===
{
uc_format = ip_id; %[ 16 ]
co_format_ip_id_seq = ip_id, %[ 0 ]
{
let (behavior == 0); % sequential
ip_id ::= static; % Nothing to send in irregular chain
};
co_format_ip_id_seq_swapped = ip_id, %[ 0 ]
{
let (behavior == 1); % sequential-swapped
ip_id ::= static; % Nothing to send in irregular chain
};
co_format_ip_id_rand = ip_id, %[ 16 ]
{
let (behavior == 2); % random
ip_id ::= irregular (16);
};
co_format_ip_id_zero = ip_id, %[ 0 ]
{
let (behavior == 3); % zero
ip_id ::= uncompressed_value (16, 0);
};
};
Pelletier, et. al [Page 54]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
ip_id_behavior_enc ===
{
uc_format = ip_id_behavior; %[ 2 ]
default_methods =
{
ip_id_behavior ::= irregular(2);
}
co_format_sequential = ip_id_behavior, %[ 2 ]
{
let (ip_id_behavior:uncomp_value = 0b00);
};
co_format_sequential_swapped = ip_id_behavior, %[ 2 ]
{
let (ip_id_behavior:uncomp_value = 0b01);
};
co_format_random = ip_id_behavior, %[ 2 ]
{
let (ip_id_behavior:uncomp_value = 0b10);
};
co_format_zero = ip_id_behavior, %[ 2 ]
{
let (ip_id_behavior:uncomp_value = 0b11);
};
};
% The argument flag should only be used if this flag was
% set when processing a compressed base header, if not,
% the flag should be zero.
ipv4 (ttl_irregular_chain_flag) ===
{
uc_format = version, %[ 4 ]
hdr_length, %[ 4 ]
tos_tc, %[ 6 ]
ip_ecn_flags, %[ 2 ]
length, %[ 16 ]
ip_id, %[ 16 ]
rf, %[ 1 ]
df, %[ 1 ]
mf, %[ 1 ]
frag_offset, %[ 13 ]
ttl_hopl, %[ 8 ]
protocol, %[ 8 ]
checksum, %[ 16 ]
src_addr, %[ 32 ]
dst_addr; %[ 32 ]
Pelletier, et. al [Page 55]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
control_fields = ip_id_behavior; %[ 2 ]
default_methods =
{
version ::= static;
hdr_length ::= uncompressed_value (4, 5);
protocol ::= static;
tos_tc ::= static;
ip_ecn_flags ::= static;
ttl_hopl ::= static;
df ::= static;
mf ::= uncompressed_value (1, 0);
rf ::= static;
frag_offset ::= uncompressed_value (13, 0);
ip_id ::= uncompressed_value (16, 0);
ip_id_behavior ::= static;
src_addr ::= static;
dst_addr ::= static;
checksum ::= inferred_ip_v4_header_checksum;
length ::= inferred_ip_v4_length;
};
co_format_ipv4_static = version_flag, %[ 1 ]
reserved, %[ 7 ]
protocol, %[ 8 ]
src_addr, %[ 32 ]
dst_addr, %[ 32 ]
{
version_flag ::= '0';
reserved ::= '0000000';
protocol ::= irregular (8);
src_addr ::= irregular(32);
dst_addr ::= irregular(32);
};
co_format_ipv4_dynamic = reserved, %[ 5 ]
df, %[ 1 ]
ip_id_behavior, %[ 2 ]
tos_tc, %[ 6 ]
ip_ecn_flags, %[ 2 ]
ttl_hopl, %[ 8 ]
ip_id, % 0/16 bits
{
reserved ::= '00000';
% The compressor chooses
% behavior of IP-ID
% 00 = sequential
% 01 = sequential byteswapped
% 10 = random
% 11 = zero
ip_id_behavior ::= ip_id_behavior_enc;
Pelletier, et. al [Page 56]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
df ::= irregular (1);
tos_tc ::= irregular (6);
ip_ecn_flags ::= irregular (2);
ttl_hopl ::= irregular (8);
ip_id ::= ip_id_enc_dyn (ip_id_behavior:uncomp_value);
};
co_format_ipv4_replicate_0 = discriminator, %[ 8 ]
ip_id, % 0 or 16 bits
tos_tc, %[ 6 ]
ip_ecn_flags, %[ 2 ]
{
discriminator ::= '00000000';
ip_id_behavior ::= static;
ip_id ::= ip_id_enc_irreg (ip_id_behavior:uncomp_value);
tos_tc ::= irregular (6);
ip_ecn_flags ::= irregular (2);
};
co_format_ipv4_replicate_1 = discriminator, %[ 5 ]
df, %[ 1 ]
ip_id_behavior, %[ 2 ]
tos_tc, %[ 6 ]
ip_ecn_flags, %[ 2 ]
ttl_hopl, %[ 8 ]
ip_id, % 0/16 bits
{
discriminator ::= '10000';
df ::= irregular (1);
tos_tc ::= irregular (6);
ip_ecn_flags ::= irregular (2);
ttl_hopl ::= irregular (8);
% The compressor chooses
% behavior of IP-ID
% 00 = sequential
% 01 = sequential byteswapped
% 10 = random
% 11 = zero
ip_id_behavior ::= ip_id_behavior_enc;
ip_id ::= ip_id_enc_dyn (ip_id_behavior:uncomp_value);
};
co_format_ipv4_outer_irregular_without_ttl =
ip_id, % 0 or 16 bits
tos_tc, % 0 or 6 bits
ip_ecn_flags, % 0 or 2 bits
{
ip_id_behavior ::= static;
ip_id ::= ip_id_enc_irreg (ip_id_behavior:uncomp_value);
tos_tc ::= irreg_tos_tc;
ip_ecn_flags ::= ip_irreg_ecn;
Pelletier, et. al [Page 57]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
let(ttl_irregular_chain_flag == 0);
};
co_format_ipv4_outer_irregular_with_ttl =
ip_id, % 0 or 16 bits
tos_tc, % 0 or 6 bits
ip_ecn_flags, % 0 or 2 bits
ttl_hopl, %[ 8 ]
{
ip_id_behavior ::= static;
ip_id ::= ip_id_enc_irreg (ip_id_behavior:uncomp_value);
tos_tc ::= irreg_tos_tc;
ip_ecn_flags ::= ip_irreg_ecn;
let(ttl_irregular_chain_flag == 1);
ttl_hopl ::= irregular(8);
};
% Note that the ECN bits are stored in the global control field
% so that they can be output in TCP irregular chain.
co_format_ipv4_innermost_irregular = ip_id, % 0 or 16 bits
{
ip_id_behavior ::= static;
ip_id ::= ip_id_enc_irreg (ip_id_behavior:uncomp_value);
let(ip_inner_ecn:uncomp_value ==
ip_ecn_flags:uncomp_value);
};
};
8.6. TCP Header
port_replicate(flags) ===
{
uc_format = port; %[ 16 ]
co_format_port_static_enc = port, %[ 0 ]
{
let(flags == 0b00);
port ::= static;
};
co_format_port_lsb8 = port, %[ 8 ]
{
let(flags == 0b01);
port ::= lsb (8, 64);
};
co_format_port_irr_enc = port, %[ 16 ]
{
let(flags == 0b10);
port ::= irregular (16);
Pelletier, et. al [Page 58]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
};
};
zero_or_irr16_enc(flag) ===
{
uc_format = field; %[ 16 ]
co_format_non_zero = field, %[ 16 ]
{
let(flag == 0);
field ::= irregular (16);
};
co_format_zero = field, %[ 0 ]
{
let(flag == 1);
field ::= uncompressed_value (16, 0);
};
};
ack_enc_dyn(flag) ===
{
uc_format = ack_number; %[ 32 ]
co_format_ack_non_zero = ack_number, %[ 32 ]
{
let(flag == 0);
ack_number ::= irregular (32);
};
co_format_ack_zero = ack_number, %[ 0 ]
{
let(flag == 1);
ack_number ::= uncompressed_value (32, 0);
};
};
tcp_ecn_flags_enc ===
{
uc_format = tcp_ecn_flags; %[ 2 ]
co_format_irreg = tcp_ecn_flags, %[ 2 ]
{
let(ecn_used:uncomp_value == 1);
tcp_ecn_flags ::= irregular(2);
};
co_format_unused =
{
let(ecn_used:uncomp_value == 0);
tcp_ecn_flags ::= static;
Pelletier, et. al [Page 59]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
};
};
tcp_res_flags_enc ===
{
uc_format = tcp_res_flags; %[ 4 ]
co_format_irreg = tcp_res_flags, %[ 4 ]
{
let(ecn_used:uncomp_value == 1);
tcp_res_flags ::= irregular(4);
};
co_format_unused =
{
let(ecn_used:uncomp_value == 0);
tcp_res_flags ::= uncompressed_value(4, 0);
};
};
tcp_irreg_ip_ecn ===
{
uc_format = ip_ecn_flags; %[ 2 ]
co_format_tc_present = ip_ecn_flags, %[ 2 ]
{
let(ecn_used:uncomp_value == 1);
ip_ecn_flags ::= compressed_value(2, ip_inner_ecn:uncomp_value);
};
co_format_tc_not_present = ip_ecn_flags, %[ 0 ]
{
let(ecn_used:uncomp_value == 0);
ip_inner_ecn ::= static; % Global control field
ip_ecn_flags ::= compressed_value(0,0); % Nothing transmit
};
};
rsf_index_enc ===
{
uc_format = rsf_flag; %[ 3 ]
co_format_none = rsf_idx, %[ 2 ]
{
rsf_idx ::= '00';
rsf_flag ::= uncompressed_value (3, 0x00);
};
co_format_rst_only = rsf_idx, %[ 2 ]
{
rsf_idx ::= '01';
Pelletier, et. al [Page 60]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
rsf_flag ::= uncompressed_value (3, 0x04);
};
co_format_syn_only = rsf_idx, %[ 2 ]
{
rsf_idx ::= '10';
rsf_flag ::= uncompressed_value (3, 0x02);
};
co_format_fin_only = rsf_idx, %[ 2 ]
{
rsf_idx ::= '11';
rsf_flag ::= uncompressed_value (3, 0x01);
};
};
optional_2bit_padding(used_flag) ===
{
uc_format = ;
co_format_used = padding, %[ 2 ]
{
let(used_flag == 1);
padding ::= compressed_value (2, 0x0);
};
co_format_unused = padding,
{
let(used_flag == 0);
padding ::= compressed_value (0, 0x0);
};
};
tcp ===
{
uc_format = 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 ]
psh_flag, %[ 1 ]
rsf_flags, %[ 3 ]
window, %[ 16 ]
checksum, %[ 16 ]
urg_ptr, %[ 16 ]
options; % n bits
Pelletier, et. al [Page 61]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
default_methods =
{
src_port ::= static;
dst_port ::= static;
seq_number ::= static;
ack_number ::= static;
rsf_flags ::= static;
psh_flag ::= irregular (1);
urg_flag ::= static;
ack_flag ::= uncompressed_value (1, 1);
urg_ptr ::= static;
window ::= static;
checksum ::= irregular (16);
tcp_ecn_flags ::= static;
tcp_res_flags ::= static;
};
co_format_tcp_static = src_port, %[ 16 ]
dst_port, %[ 16 ]
{
src_port ::= irregular(16);
dst_port ::= irregular(16);
};
co_format_tcp_dynamic = ecn_used, %[ 1 ]
ack_stride_zero, %[ 1 ]
ack_zero, %[ 1 ]
urp_zero, %[ 1 ]
tcp_res_flags, %[ 4 ]
tcp_ecn_flags, %[ 2 ]
urg_flag, %[ 1 ]
ack_flag, %[ 1 ]
psh_flag, %[ 1 ]
rsf_flags, %[ 3 ]
msn, %[ 16 ]
seq_number, %[ 32 ]
ack_number, % 0 or 32 bits
window, %[ 16 ]
checksum, %[ 16 ]
urg_ptr, % 0 or 16 bits
ack_stride, % 0 or 16 bits
options, % n bits
{
ecn_used ::= irregular (1);
ack_stride_zero ::= irregular (1);
ack_zero ::= irregular (1);
urp_zero ::= irregular (1);
ack_flag ::= irregular (1);
urg_flag ::= irregular (1);
psh_flag ::= irregular (1);
tcp_ecn_flags ::= irregular (2);
Pelletier, et. al [Page 62]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
rsf_flags ::= irregular (3);
tcp_res_flags ::= irregular (4);
msn ::= irregular (16);
seq_number ::= irregular (32);
window ::= irregular (16);
checksum ::= irregular (16);
urg_ptr ::= zero_or_irr16_enc(urp_zero:comp_value);
ack_number ::= ack_enc_dyn(ack_zero:comp_value);
ack_stride ::= zero_or_irr16_enc(ack_stride_zero:comp_value);
data_offset ::= uncompressed_value(4, data_offset_value);
options ::= list_tcp_options((data_offset_value - 5) * 32);
};
co_format_tcp_replicate = reserved, %[ 2 ]
window_presence, %[ 1 ]
list_present, %[ 1 ]
src_port_presence, %[ 2 ]
dst_port_presence, %[ 2 ]
ack_presence, %[ 1 ]
urp_presence, %[ 1 ]
urg_flag, %[ 1 ]
ack_flag, %[ 1 ]
psh_flag, %[ 1 ]
rsf_flags, %[ 2 ]
ecn_used, %[ 1 ]
msn, %[ 16 ]
seq_number, %[ 32 ]
src_port, % 0, 8 or 16 bits
dst_port, % 0, 8 or 16 bits
window, % 0 or 16 bits
urg_point, % 0 or 16 bits
ack_number, % 0 or 32 bits
ecn_padding, % 0 or 2 bits
tcp_res_flags, % 0 or 4 bits
tcp_ecn_flags, % 0 or 2 bits
options, % n bits
{
reserved ::= '000';
list_present ::= irregular (1);
msn ::= irregular (16);
urg_flag ::= irregular (1);
ack_flag ::= irregular (1);
psh_flag ::= irregular (1);
rsf_flags ::= rsf_index_enc;
ecn_used ::= irregular (1);
src_port_presence ::= compressed_value(2,
src_port_presence_value);
dst_port_presence ::= compressed_value(2,
dst_port_presence_value);
src_port ::= port_replicate(src_port_presence_value);
Pelletier, et. al [Page 63]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
dst_port ::= port_replicate( dst_port_presence_value);
seq_number ::= irregular(32);
ack_presence ::= compressed_value(1, ack_presence_value);
window_presence ::= compressed_value(1, window_presence_value);
urp_presence ::= compressed_value(1, urg_presence_value);
ack_number ::= static_or_irreg32(ack_presence_value);
window ::= static_or_irreg16(window_presence_value);
urg_point ::= static_or_irreg16(urp_presence_value);
ecn_padding ::= optional_2bit_padding(ecn_used:comp_value);
tcp_res_flags ::= tcp_res_flags_enc;
tcp_ecn_flags ::= tcp_ecn_flags_enc;
data_offset ::= uncompressed_value(4, data_offset_value);
options ::= tcp_list_presence_enc
((data_offset_value - 5) * 32,
list_present:comp_value,
ack_number:uncomp_value);
};
% ECN from innermost IP header is taken from global control field.
co_format_tcp_irregular = ip_ecn_flags, % 0 or 2 bits
tcp_res_flags, % 0 or 4 bits
tcp_ecn_flags, % 0 or 2 bits
checksum, %[ 16 ]
{
ip_ecn_flags ::= tcp_irreg_ip_ecn;
tcp_ecn_flags ::= tcp_ecn_flags_enc;
tcp_res_flags ::= tcp_res_flags_enc;
checksum ::= irregular (16);
};
};
8.7. TCP Options
tcp_opt_eol(nbits) === {
uc_format = type, %[ 8 ]
padding; % (nbits - 8) bits
default_methods =
{
type ::= uncompressed_value (8, 0);
pad_len ::= static;
padding ::= uncompressed_value (nbits - 8, 0);
};
co_format_eol_list_item = pad_len, % 8 bits
padding, %[ 0 ]
{
pad_len ::= compressed_value(8, nbits - 8);
};
Pelletier, et. al [Page 64]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
co_format_eol_irregular =
{
let(nbits - 8 == pad_len:uncomp_value);
};
};
tcp_opt_nop ===
{
uc_format = type; %[ 8 ]
default_methods =
{
type ::= uncompressed_value (8, 1);
};
co_format_nop_list_item =
{
};
co_format_nop_irregular =
{
};
};
tcp_opt_mss ===
{
uc_format = type, %[ 8 ]
length, %[ 8 ]
mss; %[ 16 ]
default_methods =
{
type ::= uncompressed_value (8, 2);
length ::= uncompressed_value (8, 4);
mss ::= static;
};
co_format_mss_list_item = mss, %[ 16 ]
{
mss ::= irregular (16);
};
co_format_mss_irregular =
{
};
};
tcp_opt_wscale ===
{
uc_format = type, %[ 8 ]
Pelletier, et. al [Page 65]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
length, %[ 8 ]
wscale; %[ 8 ]
default_methods =
{
type ::= uncompressed_value (8, 3);
length ::= uncompressed_value (8, 3);
wscale ::= static;
};
co_format_wscale_list_item = wscale, %[ 8 ]
{
wscale ::= irregular (8);
};
co_format_wscale_irregular =
{
};
};
ts_lsb ===
{
uc_format = tsval;
% Few bits (7 and 14) bits
% can only increase, while
% the larger formats allow
% decreasing timestamp to
% allow prelink reordering.
co_format_tsval_7 = discriminator, %[ 1 ]
tsval, %[ 7 ]
{
discriminator ::= '0';
tsval ::= lsb (7, -1);
};
co_format_tsval_14 = discriminator, %[ 2 ]
tsval, %[ 14 ]
{
discriminator ::= '10';
tsval ::= lsb (14, -1);
};
co_format_tsval_21 = discriminator, %[ 3 ]
tsval, %[ 21 ]
{
discriminator ::= '110';
tsval ::= lsb (21, 0x00040000);
};
Pelletier, et. al [Page 66]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
co_format_tsval_29 = discriminator, %[ 3 ]
tsval, %[ 29 ]
{
discriminator ::= '111';
tsval ::= lsb (29, 0x04000000);
};
};
tcp_opt_tsopt ===
{
uc_format = type, %[ 8 ]
length, %[ 8 ]
tsval, %[ 32 ]
tsecho; %[ 32 ]
default_methods =
{
type ::= uncompressed_value (8, 8);
length ::= uncompressed_value (8, 10);
};
co_format_tsopt_list_item = tsval, %[ 32 ]
tsecho, %[ 32 ]
{
tsval ::= irregular (32);
tsecho ::= irregular (32);
};
co_format_tsopt_irregular = tsval, % 16, 24 or 32 bits
tsecho, % 16, 24 or 32 bits
{
tsval ::= ts_lsb;
tsecho ::= ts_lsb;
};
};
sack_var_length_enc (base) ===
{
uc_format = sack_field; %[ 32 ]
default_methods =
{
let (sack_offset:uncomp_value == sack_field:uncomp_value - base);
let (sack_offset:uncomp_length == 32);
let (sack_field:uncomp_length == 32);
};
co_format_lsb_15 = discriminator, %[ 1 ]
sack_offset, %[ 15 ]
{
discriminator ::= '0';
Pelletier, et. al [Page 67]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
sack_offset ::= lsb (15, -1);
};
co_format_lsb_22 = discriminator, %[ 2 ]
sack_offset, %[ 22 ]
{
discriminator ::= '10';
sack_offset ::= lsb (22, -1);
};
co_format_lsb_30 = discriminator, %[ 2 ]
sack_offset, %[ 30 ]
{
discriminator ::= '11';
sack_offset ::= lsb (30, -1);
};
};
tcp_opt_sack_block (prev_block_end) ===
{
uc_format = block_start, %[ 32 ]
block_end; %[ 32 ]
co_format_0 = block_start, % 16, 24 or 32 bits
block_end, % 16, 24 or 32 bits
{
block_start ::= sack_var_length_enc (prev_block_end);
block_end ::= sack_var_length_enc (block_start);
};
};
tcp_opt_sack(ack_value) ===
{
% The ACK value from the TCP header is needed as input parameter.
uc_format = type, %[ 8 ]
length, %[ 8 ]
block_1, %[ 64 ]
block_2, % 0 or 64 bits
block_3, % 0 or 64 bits
block_4; % 0 or 64 bits
default_methods =
{
length ::= static;
type ::= uncompressed_value (8, 5);
block_2 ::= uncompressed_value (0, 0);
block_3 ::= uncompressed_value (0, 0);
block_4 ::= uncompressed_value (0, 0);
};
Pelletier, et. al [Page 68]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
co_format_sack1_list_item = discriminator,
block_1,
{
let(length:uncomp_value == 10);
discriminator ::= '00000001';
block_1 ::= tcp_opt_sack_block (ack_value);
};
co_format_sack2_list_item = discriminator,
block_1,
block_2,
{
let(length:uncomp_value == 18);
discriminator ::= '00000010';
block_1 ::= tcp_opt_sack_block (ack_value);
block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value);
};
co_format_sack3_list_item = discriminator,
block_1,
block_2,
block_3,
{
let(length:uncomp_value == 26);
discriminator ::= '00000011';
block_1 ::= tcp_opt_sack_block (ack_value);
block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value);
block_3 ::= tcp_opt_sack_block (block_2_end:uncomp_value);
};
co_format_sack4_list_item = discriminator,
block_1,
block_2,
block_3,
block_4,
{
let(length:uncomp_value == 34);
discriminator ::= '00000100';
block_1 ::= tcp_opt_sack_block (ack_value);
block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value);
block_3 ::= tcp_opt_sack_block (block_2_end:uncomp_value);
block_4 ::= tcp_opt_sack_block (block_3_end:uncomp_value);
};
co_format_sack_unchanged_irregular = discriminator,
block_1,
block_2,
block_3,
block_4,
{
discriminator ::= '00000000';
Pelletier, et. al [Page 69]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
block_1 ::= static;
block_2 ::= static;
block_3 ::= static;
block_4 ::= static;
};
co_format_sack1_irregular = discriminator,
block_1,
{
let(length:uncomp_value == 10);
discriminator ::= '00000001';
block_1 ::= tcp_opt_sack_block (ack_value);
};
co_format_sack2_irregular = discriminator,
block_1,
block_2,
{
let(length:uncomp_value == 18);
discriminator ::= '00000010';
block_1 ::= tcp_opt_sack_block (ack_value);
block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value);
};
co_format_sack3_irregular = discriminator,
block_1,
block_2,
block_3,
{
let(length:uncomp_value == 26);
discriminator ::= '00000011';
block_1 ::= tcp_opt_sack_block (ack_value);
block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value);
block_3 ::= tcp_opt_sack_block (block_2_end:uncomp_value);
};
co_format_sack4_irregular = discriminator,
block_1,
block_2,
block_3,
block_4,
{
let(length:uncomp_value == 34);
discriminator ::= '00000100';
block_1 ::= tcp_opt_sack_block (ack_value);
block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value);
block_3 ::= tcp_opt_sack_block (block_2_end:uncomp_value);
block_4 ::= tcp_opt_sack_block (block_3_end:uncomp_value);
};
};
Pelletier, et. al [Page 70]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
tcp_opt_sack_permitted ===
{
uc_format = type, %[ 8 ]
length; %[ 8 ]
default_methods =
{
type ::= uncompressed_value (8, 4);
length ::= uncompressed_value (8, 2);
};
co_format_sack_permitted_list_item =
{
};
co_format_sack_permitted_irregular =
{
};
};
tcp_opt_generic ===
{
uc_format = type, %[ 8 ]
length_msb, %[ 1 ]
length_lsb, %[ 7 ]
contents; % n bits
control_fields = option_static; %[ 1 ]
default_methods =
{
type ::= static;
% lengths are always < 128
% (i.e. the msb is always 0)
length_msb ::= uncompressed_value (1, 0);
length_lsb ::= static;
contents ::= static;
let (option_static:uncomp_length == 1);
};
co_format_generic_list_item = type, %[ 8 ]
option_static, %[ 1 ]
length_lsb, %[ 7 ]
contents, % n bits
{
type ::= irregular (8);
option_static ::= irregular (1);
length_lsb ::= irregular (7);
contents ::= irregular (length_len:uncomp_value * 8 - 16);
};
Pelletier, et. al [Page 71]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
% Used when context of option has option_static set to one
co_format_generic_irregular_static =
{
let(option_static:uncomp_value == 1);
};
% An item that can change, but currently is unchanged
co_format_generic_irregular_stable = discriminator, %[ 8 ]
{
let(option_static:uncomp_value == 0);
discriminator ::= '11111111';
};
% 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.
co_format_generic_irregular_full = discriminator, %[ 8 ]
contents, % n bits
{
let(option_static:uncomp_value == 0);
discriminator ::= '00000000';
contents ::= irregular (length_lsb:uncomp_value * 8 - 16);
};
};
list_tcp_options(nbits, ack_value) ===
{
uc_format = item,
tail;
default_methods = {
let(nbits >= item:uncomp_length);
tail ::= list_tcp_options(nbits - item:uncomp_length, ack_value);
};
co_format_list_end =
{
let(nbits == 0);
item ::= irregular(0);
tail ::= irregular(0);
};
co_format_eol = item,
tail
{
let(nbits == item:uncomp_length); % redundant
item ::= tcp_opt_eol(nbits);
tail ::= irregular(0);
};
Pelletier, et. al [Page 72]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
co_format_nop = item,
tail
{
item ::= tcp_opt_nop;
};
co_format_mss = item,
tail
{
item ::= tcp_opt_mss;
};
co_format_wscale = item,
tail
{
item ::= tcp_opt_wscale;
};
co_format_tsopt = item,
tail
{
item ::= tcp_opt_tsopt;
};
co_format_sack = item,
tail
{
item ::= tcp_opt_sack(ack_value);
};
co_format_permitted = item,
tail
{
item ::= tcp_opt_sack_permitted;
};
co_format_generic = item,
tail
{
item ::= tcp_opt_generic;
};
};
tcp_list_presence_enc(list_length, presence, ack_value) ===
{
uc_format = tcp_options;
co_format_list_not_present = tcp_options, %[ 0 ]
{
let (presence == 0);
tcp_options ::= static;
Pelletier, et. al [Page 73]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
};
co_format_list_present = tcp_options, % 8 + n*8 bits
{
let (presence == 1);
tcp_options ::= list_tcp_options(list_length, ack_value);
};
};
8.8. Structures used in Compressed Base Headers
tos_tc_enc(flag) ===
{
uc_format = tos_tc; %[ 6 ]
co_format_static = tos_tc, %[ 0 ]
{
let (flag == 0);
tos_tc ::= static;
};
co_format_irreg = tos_tc, %[ 6 ]
padding, %[ 2 ]
{
let (flag == 1);
tos_tc ::= irregular(6);
padding ::= compressed_value (2, 0);
};
};
ip_id_lsb (behavior, k, p) ===
{
uc_format = ip_id; %[ 16 ]
default_methods =
{
let (ip_id:uncomp_length == 16);
};
co_format_nbo = ip_id_offset, % k bits
{
let (behavior == 0);
let (ip_id_offset:uncomp_value ==
ip_id:uncomp_value - msn:uncomp_value);
let (ip_id_offset:uncomp_length == 16);
ip_id_offset ::= lsb (k, p);
};
Pelletier, et. al [Page 74]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
co_format_non_nbo = ip_id_offset, % k bits
{
let (behavior == 1);
let (ip_id_nbo:uncomp_value == (ip_id:uncomp_value / 256) +
(ip_id:uncomp_value & 255) * 256);
let (ip_id_nbo:uncomp_length == 16);
let (ip_id_offset:uncomp_value ==
ip_id_nbo:uncomp_value - msn:uncomp_value);
let (ip_id_offset:uncomp_length == 16);
ip_id_offset ::= lsb (k, p);
};
};
dont_fragment(version) ===
{
uc_format = df; %[ 1 ]
co_format_v4 = df, %[ 1 ]
{
let (version == 4);
df ::= irregular(1);
};
co_format_v6 = df,
{
let (version == 6);
df ::= compressed_value(1,0);
};
};
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 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 an
% "output argument" that should be passed
% to the processing of the irregular chain
% for outer IP headers.
co_baseheader(payload_size, ttl_irregular_chain_flag) ===
{
uc_format_v4 = version, %[ 4 ]
header_length, %[ 4 ]
tos_tc, %[ 6 ]
ip_ecn_flags, %[ 2 ]
length, %[ 16 ]
ip_id, %[ 16 ]
rf, %[ 1 ]
Pelletier, et. al [Page 75]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
df, %[ 1 ]
mf, %[ 1 ]
frag_offset, %[ 13 ]
ttl_hopl, %[ 8 ]
next_header, %[ 8 ]
checksum, %[ 16 ]
src_addr, %[ 32 ]
dest_addr, %[ 32 ]
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, % n bits
{
let (version:uncomp_value == 4);
};
uc_format_v6 = version, %[ 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 ]
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, % n bits
Pelletier, et. al [Page 76]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
{
let (version:uncomp_value == 6);
};
control_fields = ip_id_behavior; % 2 bits
default_methods =
{
version ::= static;
tos_tc ::= static;
ip_ecn_flags ::= static;
ttl_hopl ::= static;
next_header ::= static;
src_addr ::= static;
dest_addr ::= static;
flow_label ::= static;
payload_length ::= inferred_ip_v6_length;
header_length ::= uncompressed_value (4,5);
length ::= inferred_ip_v4_length;
ip_id ::= irregular(16);
ip_id_behavior ::= static;
rf ::= static;
df ::= static;
mf ::= static;
frag_offset ::= static;
checksum ::= inferred_ip_v4_header_checksum;
src_port ::= static;
dest_port ::= static;
seq_number ::= static;
ack_number ::= static;
data_offset ::= inferred_offset;
tcp_ecn_flags ::= static;
psh_flag ::= irregular (1);
urg_flag ::= uncompressed_value (1, 0);
ack_flag ::= uncompressed_value (1, 1);
window ::= static;
tcp_checksum ::= irregular(16);
urg_ptr ::= static;
rsf_flags ::= uncompressed_value (3, 0);
tcp_res_flags ::= static;
options_list ::= static;
let (version:uncomp_length == 4);
let (seq_number_scaled:uncomp_value ==
seq_number:uncomp_value / payload_size);
let (seq_number_residue:uncomp_value ==
mod(seq_number:uncomp_value, payload_size));
let (ack_number:uncomp_value ==
(ack_stride:uncomp_value *
ack_number_scaled:uncomp_value) +
ack_number_residue:uncomp_value);
Pelletier, et. al [Page 77]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
let (ack_number_residue:uncomp_value ==
mod(ack_number:uncomp_value, ack_stride:uncomp_value));
};
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Common compressed packet format
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
co_format_co_common = discriminator, %[ 7 ]
ttl_hopl_outer_flag, %[ 1 ]
ack_flag, %[ 1 ]
psh_flag, %[ 1 ]
rsf_flags, %[ 2 ]
msn, %[ 4 ]
seq_indicator, %[ 2 ]
ack_indicator, %[ 2 ]
ack_stride_indicator, %[ 1 ]
window_indicator, %[ 1 ]
ip_id_indicator, %[ 2 ]
urg_ptr_present, %[ 1 ]
ecn_used, %[ 1 ]
tos_tc_present, %[ 1 ]
ttl_hopl_present, %[ 1 ]
list_present, %[ 1 ]
ip_id_behavior, %[ 2 ]
urg_flag, %[ 1 ]
df, %[ 1 ]
header_crc, %[ 7 ]
seq_number, % 0, 8, 16, 32 bits
ack_number, % 0, 8, 16, 32 bits
ack_stride, % 0 or 16 bits
window, % 0 or 16 bits
ip_id, % 0, 8, 16 bits
urg_ptr, % 0 or 16 bits
tos_tc, % 0 or 8 bits
ttl_hopl, % 0 or 8 bits
options_list, % n bits
{
discriminator ::= '1111101';
ttl_hopl_outer_flag::= irregular(1);
% Need to bind argument so that it can be passed to the
% structure for IPv4/IPv6 irregular chain.
let(ttl_irregular_chain_flag ==
ttl_hopl_outer_flag:uncomp_value);
tos_tc_present ::= irregular(1);
ttl_hopl_present ::= irregular(1);
ack_flag ::= irregular(1);
psh_flag ::= irregular(1);
msn ::= lsb (4, 3);
df ::= dont_fragment(version:uncomp_value);
header_crc ::= crc7(this:uncomp_value, this:uncomp_length);
Pelletier, et. al [Page 78]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
urg_flag ::= irregular(1);
urg_ptr_present ::= irregular(1);
ecn_used ::= irregular(1);
list_present ::= irregular(1);
ip_id_behavior ::= ip_id_behavior_enc;
rsf_flags ::= rsf_index_enc;
window_indicator ::= irregular(1);
ip_id_indicator ::= irregular(2);
seq_indicator ::= irregular(2);
ack_indicator ::= irregular(2);
ack_stride_indicator ::= irregular(1);
seq_number ::= variable_length_32_enc(seq_indicator:comp_value);
ack_number ::= variable_length_32_enc(ack_indicator:comp_value);
ack_stride ::=
static_or_irreg16(ack_stride_indicator:comp_value);
window ::= static_or_irreg16(window_indicator:comp_value);
ip_id ::= variable_length_16_enc(ip_id_indicator:comp_value);
urg_ptr ::= static_or_irreg16(urg_ptr_present:comp_value);
ttl_hopl ::= static_or_irreg8(ttl_hopl_present:comp_value);
tos_tc ::= tos_tc_enc(tos_tc_present:comp_value);
options_list ::= tcp_list_presence_enc
((data_offset:uncomp_value - 5) * 32,
list_present:comp_value,
ack_number:uncomp_value);
};
% NON-SEQUENTIAL PACKET FORMATS
% +------+--------+-----+-----+-----+---------+---------+
% |Name |Disc |MSN |SN |ACK |Window |Comment |
% +------+--------+-----+-----+-----+---------+---------+
% |_1 |10111110|4 |16 |0 | | |
% +------+--------+-----+-----+-----+---------+---------+
% |_2 |1100 |4 |*4 |0 | | |
% +------+--------+-----+-----+-----+---------+---------+
% |_3 |0 |4 |0 |15 | | |
% +------+--------+-----+-----+-----+---------+---------+
% |_4 |1101 |4 |0 |4* | | |
% +------+--------+-----+-----+-----+---------+---------+
% |_5 |100 |4 |14 |15 | | |
% +------+--------+-----+-----+-----+---------+---------+
% |_6 |10110 |4 |*4 |15 | | |
% +------+--------+-----+-----+-----+---------+---------+
% |_7 |1010 |4 |14 |0 |14 | |
% +------+--------+-----+-----+-----+---------+---------+
% |_8 |10111111|4 |0 |16 |16 | |
% +------+--------+-----+-----+-----+---------+---------+
Pelletier, et. al [Page 79]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
% |_9 |101110 |4 |*4 |0 |14 | |
% +------+--------+-----+-----+-----+---------+---------+
% |_10 |1011110 |4 |14 |16 | |and more |
% +------+--------+-----+-----+-----+---------+---------+
% Send LSBs of sequence number
co_format_rnd_1 = discriminator, %[ 8 ]
seq_number, %[ 16 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '10111110';
msn ::= lsb(4, 4);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
seq_number ::= lsb(16, 32767);
};
% Send scaled sequence number LSBs
co_format_rnd_2 = discriminator, %[ 4 ]
seq_number_scaled, %[ 4 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '1100';
msn ::= lsb(4, 4);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
seq_number_scaled ::= lsb(4, 7);
seq_number_residue ::= static;
};
% Send acknowledgement number LSBs
co_format_rnd_3 = discriminator, %[ 1 ]
ack_number, %[ 15 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '0';
Pelletier, et. al [Page 80]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
msn ::= lsb(4, 4);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
ack_number ::= lsb(15, 8191);
};
% Send acknowledgement number scaled
co_format_rnd_4 = discriminator, %[ 4 ]
ack_number_scaled, %[ 4 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '1101';
msn ::= lsb(4, 4);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
ack_number_scaled ::= lsb(4, 3);
ack_number_residue ::= static;
};
% Send ACK and sequence number
co_format_rnd_5 = discriminator, %[ 3 ]
psh_flag, %[ 1 ]
msn, %[ 4 ]
header_crc, %[ 3 ]
seq_number, %[ 14 ]
ack_number, %[ 15 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '100';
msn ::= lsb(4, 4);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
ack_number ::= lsb(15, 8191);
seq_number ::= lsb(14, 8191);
};
% Send both ACK and scaled sequence number LSBs
co_format_rnd_6 = discriminator, %[ 5 ]
header_crc, %[ 3 ]
psh_flag, %[ 1 ]
ack_number, %[ 15 ]
msn, %[ 4 ]
seq_number_scaled, %[ 4 ],
Pelletier, et. al [Page 81]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '10110';
msn ::= lsb(4, 4);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
ack_number ::= lsb(15, 8191);
seq_number_scaled ::= lsb(4, 7);
seq_number_residue ::= static;
};
% Send sequence number and window
co_format_rnd_7 = discriminator, %[ 4 ]
seq_number, %[ 14 ]
window, %[ 14 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '1010';
msn ::= lsb(4, 4);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
seq_number ::= lsb(14, 8191);
window ::= lsb(14, 8191);
};
% Send ACK and window
co_format_rnd_8 = discriminator, %[ 8 ]
ack_number, %[ 16 ]
window, %[ 16 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '10111111';
msn ::= lsb(4, 4);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
ack_number ::= lsb(16, 16383);
window ::= irregular(16);
};
Pelletier, et. al [Page 82]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
% Send scaled sequence number and window.
co_format_rnd_9 = discriminator, %[ 6 ]
seq_number_scaled, %[ 4 ]
window, %[ 14 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '101110';
msn ::= lsb(4, 4);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
window ::= lsb(14, 8191);
seq_number_scaled ::= lsb(4, 3);
seq_number_residue ::= static;
};
% A packet halfway between co_common and compressed packets
% Can send LSBs of TTL, RSF flags,
% change ECN behavior and options list
co_format_rnd_10 = discriminator, %[ 7 ]
ecn_used, %[ 1 ]
list_present, %[ 1 ]
header_crc, %[ 7 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
ttl_hopl, %[ 3 ]
rsf_flags, %[ 2 ]
seq_number, %[ 14 ]
ack_number, %[ 16 ]
options_list, % 0 or X bits
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '1011110';
msn ::= lsb(4, 4);
header_crc ::= crc7 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
list_present ::= irregular(1);
options_list ::= tcp_list_presence_enc
((data_offset:uncomp_value - 5) * 32,
list_present:comp_value,
ack_number:uncomp_value);
rsf_flags ::= rsf_index_enc;
ecn_used ::= irregular(1);
ttl_hopl ::= lsb(3, 3);
seq_number ::= lsb(14, 8191);
Pelletier, et. al [Page 83]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
ack_number ::= lsb(16, 16383);
};
% SEQUENTIAL PACKET FORMATS
% +------+------+-----+-----+-----+-----+-----+---------+
% |Name |Disc |MSN |ID |SN |ACK |Win |Comment |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_1 |1010 |4 |4 |16 |0 | | |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_2 |11001 |4 |7 |*4 |0 | | |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_3 |1001 |4 |4 |0 |16 | | |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_4 |0 |4 |3 |0 |*4 | | |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_5 |1000 |4 |4 |16 |16 | | |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_6 |110110|4 |6 |*4 |16 | | |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_7 |11010 |4 |5 |14 |0 |16 | |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_8 |11000 |4 |5 |0 |16 |14 | |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_9 |110111|4 |6 |*4 |0 |16 | |
% +------+------+-----+-----+-----+-----+-----+---------+
% |_10 |1011 |4 |4 |14 |15 | |and more |
% +------+------+-----+-----+-----+-----+-----+---------+
% Send LSBs of sequence number
co_format_seq_1 = discriminator, %[ 4 ]
ip_id, %[ 4 ]
seq_number, %[ 16 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '1010';
msn ::= lsb(4, 4);
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 4, 3);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
seq_number ::= lsb(16, 32767);
};
% Send scaled sequence number LSBs
co_format_seq_2 = discriminator, %[ 5 ]
ip_id, %[ 7 ]
Pelletier, et. al [Page 84]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
seq_number_scaled, %[ 4 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '11001';
msn ::= lsb(4, 4);
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 7, 3);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
seq_number_scaled ::= lsb(4, 7);
seq_number_residue ::= static;
};
% Send acknowledgement number LSBs
co_format_seq_3 = discriminator, %[ 4 ]
ip_id, %[ 4 ]
ack_number, %[ 16 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '1001';
msn ::= lsb(4, 4);
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 4, 3);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
ack_number ::= lsb(16, 16383);
};
% Send scaled acknowledgement number scaled
co_format_seq_4 = discriminator, %[ 1 ]
ack_number_scaled, %[ 4 ]
ip_id, %[ 3 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '0';
msn ::= lsb(4, 4);
% Note that due to having very few ip_id bits,
% no reordering offset
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 3, 1);
Pelletier, et. al [Page 85]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
ack_number_scaled ::= lsb(4, 3);
ack_number_residue ::= static;
};
% Send ACK and sequence number
co_format_seq_5 = discriminator, %[ 4 ]
ip_id, %[ 4 ]
ack_number, %[ 16 ]
seq_number, %[ 16 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '1000';
msn ::= lsb(4, 4);
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 4, 3);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
ack_number ::= lsb(16, 16383);
seq_number ::= lsb(16, 32767);
};
% Send both ACK and scaled sequence number LSBs
co_format_seq_6 = discriminator, %[ 6 ]
seq_number_scaled, %[ 4 ]
ip_id, %[ 6 ]
ack_number, %[ 16 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '110110';
seq_number_scaled ::= lsb(4, 7);
seq_number_residue ::= static;
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 6, 3);
ack_number ::= lsb(16, 16383);
msn ::= lsb(4, 4);
psh_flag ::= irregular (1);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
};
Pelletier, et. al [Page 86]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
% Send sequence number and window
co_format_seq_7 = discriminator, %[ 5 ]
seq_number, %[ 14 ]
ip_id, %[ 5 ]
window, %[ 16 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '11010';
msn ::= lsb(4, 4);
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 5, 3);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
seq_number ::= lsb(14, 8191);
window ::= irregular(16);
};
% Send ACK and window
co_format_seq_8 = discriminator, %[ 5 ]
window, %[ 14 ]
ip_id, %[ 5 ]
ack_number, %[ 16 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '11000';
msn ::= lsb(4, 4);
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 5, 3);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
ack_number ::= lsb(16, 32767);
window ::= lsb(14, 8191);
};
% Send scaled sequence number and window.
co_format_seq_9 = discriminator, %[ 6 ]
ip_id, %[ 6 ]
seq_number_scaled, %[ 4 ]
window, %[ 16 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
header_crc, %[ 3 ]
{
Pelletier, et. al [Page 87]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '110111';
msn ::= lsb(4, 4);
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 6, 3);
header_crc ::= crc3 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
window ::= irregular(16);
seq_number_scaled ::= lsb(4, 7);
seq_number_residue ::= static;
};
% A packet halfway between co_common and compressed packets
% Can send LSBs of TTL, RSF flags,
% change ECN behavior and options list
co_format_seq_10 = discriminator, %[ 4 ]
ip_id, %[ 4 ]
list_present, %[ 1 ]
header_crc, %[ 7 ]
msn, %[ 4 ]
psh_flag, %[ 1 ]
ttl_hopl, %[ 3 ]
ecn_used, %[ 1 ]
ack_number, %[ 15 ]
rsf_flags, %[ 2 ]
seq_number, %[ 14 ]
options_list, % Nx8 bits
{
let ((ip_id_behavior:uncomp_value == 2) ||
(ip_id_behavior:uncomp_value == 3));
discriminator ::= '1011';
msn ::= lsb(4, 4);
ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 4, 3);
header_crc ::= crc7 (this:uncomp_value,
this:uncomp_length);
psh_flag ::= irregular (1);
list_present ::= irregular(1);
options_list ::= tcp_list_presence_enc
((data_offset:uncomp_value - 5) * 32,
list_present:comp_value);
rsf_flags ::= rsf_index_enc;
ecn_used ::= irregular(1);
ttl_hopl ::= lsb(3, 3);
seq_number ::= lsb(14, 8191);
ack_number ::= lsb(15, 8191);
};
};
Pelletier, et. al [Page 88]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8.9. Feedback Formats and Options
8.9.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 [2].
All feedback formats carry a field labeled SN. The SN field contains
LSBs of the Master Sequence Number (MSN) described in section 6.3.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.
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 parseability)
MSN: The lsb-encoded master sequence number.
Feedback options: A variable number of feedback options, see
section 8.9.2. Options may appear in any order.
Pelletier, et. al [Page 89]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8.9.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 Len octets
+---+---+---+---+---+---+---+---+
8.9.2.1. The CRC option
The CRC option contains an 8-bit CRC computed over the entire
feedback payload, without the packet type and code octet, but
including any CID fields, using the polynomial of section 5.9.1 of
[2]. 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 information MUST be ignored.
8.9.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 stops compressing the
packet stream, and should refrain from attempting to increase the
number of compressed packet streams for some time. Any FEEDBACK
packet carrying a REJECT option MUST also carry a CRC option.
Pelletier, et. al [Page 90]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8.9.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 |
+---+---+---+---+---+---+---+---+
8.9.2.4. The MSN option
The MSN option provides 8 additional bits of MSN.
+---+---+---+---+---+---+---+---+
| Opt Type = 4 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
8.9.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.9.2.6. 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 [Page 91]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
8.9.2.7. 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 stream, as the stream 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 stream in a way that requires less
decompressor memory resources, or stop compressing the packet stream.
9. Security Consideration
Because encryption eliminates the redundancy that header compression
schemes try to exploit, there is some inducement to forego encryption
of headers in order to enable operation over low-bandwidth links.
However, for those cases where encryption of data (and not headers)
is sufficient, TCP does specify an alternative encryption method in
which only the TCP payload is encrypted and the headers are left in
the clear. That would still allow header compression to be applied.
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.
Pelletier, et. al [Page 92]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
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. Acknowledgments
The authors would like to thank Qian Zhang, Hong Bin Liao and Richard
Price for their work with early versions of this specification.
Thanks also to Fredrik Lindstroem for reviewing the packet formats,
as well as to Robert Finking for valuable input.
12. Authors' Addresses
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Pelletier, et. al [Page 93]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
Mark A West
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
Phone: +44 1794 833311
Email: mark.a.west@roke.co.uk
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Kristofer Sandlund
Effnet AB
Stationsgatan 69
S-972 34 Lulea
Sweden
Phone: +46 920 609 17
Fax: +46 920 609 27
EMail: kristofer.sandlund@effnet.com
13. References
13.1. Normative references
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] 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.
[3] Pelletier, G., "Robust Header Compression (ROHC): Context
Replication for ROHC profiles", Internet Draft (work in
progress), <draft-ietf-rohc-context-replication-06.txt>, October
2004.
Pelletier, et. al [Page 94]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
[4] R. Finking, C. Bormann and G. Pelletier, "Formal Notation for
Robust Header Compression (ROHC-FN)", Internet Draft (work in
progress), <draft-ietf-rohc-formal-notation-04.txt>, February
2005.
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[7] S. Bradner, "The Internet Standards Process - Revision 3", RFC
2026, October 1996.
[8] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
13.2. Informative References
[10] Jonsson, L-E., "Requirements on ROHC IP/TCP header compression",
Internet Draft (work in progress), <draft-ietf-rohc-tcp-
requirements-08.txt>, September 2004.
[11] West, M. and S. McCann, "TCP/IP Field Behavior", Internet Draft
(work in progress), <draft-ietf-rohc-tcp-field-behavior-04.txt>,
October 2004.
[12] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A compression profile for IP", RFC 3843, June 2003.
[13] Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay
Paths", LBL, ISI, October 1988.
[14] Jacobson, V.,"Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144, February 1990.
[15] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[16] Braden, R. "T/TCP -- TCP Extensions for Transactions Functional
Specification", ISI, July 1994.
[17] Connolly, T., et al, "An Extension to TCP: Partial Order
Service", University of Delaware, November 1994.
Pelletier, et. al [Page 95]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
[18] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[19] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", NOAO, January 1997.
[20] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[21] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[22] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000.
[23] Ramakrishnan, K., Floyd and D. Black, "The Addition of Explicit
Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[24] Jacobson, V., "Fast Retransmit", Message to the end2end-interest
mailing list, April 1990.
[25] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
Pelletier, et. al [Page 96]
INTERNET-DRAFT ROHC Profile for TCP/IP February 21, 2005
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires August 21, 2005.
Pelletier, et. al [Page 97]
