Network Working Group Ghyslain Pelletier, Editor, Ericsson AB
INTERNET-DRAFT Lars-Erik Jonsson, Ericsson AB
Expires: October 2004 Mark A West, Siemens/Roke Manor
Richard Price, Siemens/Roke Manor
April 2, 2004
RObust Header Compression (ROHC):
A Profile for TCP/IP (ROHC-TCP)
<draft-ietf-rohc-tcp-06.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
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.
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, RFC-2507] have not addressed how to compress TCP
options such as SACK (Selective Acknowledgements) [RFC-2018, RFC-
2883] and Timestamps [RFC-1323].
Pelletier, et al. [Page 1]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
Table of contents
1. Introduction....................................................4
2. Terminology.....................................................4
3. Background......................................................5
3.1. Existing TCP/IP header compression schemes................5
3.2. Classification of TCP/IP header fields....................6
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.......................9
5. Compression and decompression state machines....................9
5.1. Compressor states and logic...............................9
5.1.1. Initialization and Refresh (IR) state..................10
5.1.2. Compression (CO) state.................................10
5.1.3. Feedback logic.........................................10
5.1.4. State transition logic.................................11
5.1.4.1. Optimistic approach, upward transition...............11
5.1.4.2. Optional acknowledgements (ACKs), upward transition..11
5.1.4.3. Timeouts, downward transition........................11
5.1.4.4. Negative ACKs (NACKs), downward transition...........12
5.1.4.5. Need for updates, downward transition................12
5.1.5. State machine supporting context replication...........12
5.2. Decompressor states and logic............................12
5.2.1. No Context (NC) state..................................13
5.2.2. Static Context (SC) state..............................13
5.2.3. Full Context (FC) state................................13
5.2.4. Allowing decompression.................................14
5.2.5. Reconstruction and verification........................15
5.2.6. Actions upon CRC failure...............................15
5.2.7. Feedback logic.........................................15
6. ROHC-TCP - TCP/IP compression (Profile 0x0006).................16
6.1. Feedback channel considerations..........................16
6.2. Master Sequence Number (MSN).............................17
6.3. Initialization...........................................17
6.4. Packet types.............................................18
6.4.1. Initialization and Refresh packets (IR)................18
6.4.2. Context replication packets (IR-CR)....................19
6.4.3. Compressed packets (CO)................................21
Pelletier, et al. [Page 2]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
6.5. Packet formats...........................................21
6.5.1. Uncompressed TCP/IP packet.............................22
6.5.2. Default encoding methods...............................23
6.5.3. Compressed TCP Options using list encoding.............26
6.5.4. Packet type IR and IR-DYN..............................30
6.5.5. Compressed TCP/IP packets..............................32
6.5.5.1. Packet type IR-CR....................................32
6.5.5.2. Packet type CO.......................................38
6.6. Feedback formats and options.............................57
6.6.1. Feedback formats.......................................57
6.6.2. Feedback options.......................................58
6.6.3. The CONTEXT_MEMORY Feedback Option.....................58
7. Security considerations........................................58
8. IANA considerations............................................59
9. Acknowledgements...............................................59
10. References....................................................59
10.1. Normative references.....................................59
10.2. Informative references...................................60
11. Authors' addresses............................................61
Full Copyright Statement...........................................63
Pelletier, et al. [Page 3]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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]. [TCP-REQ] introduces additional
considerations making robustness an important objective for a TCP
compression scheme. Finally, existing TCP/IP header compression
schemes [RFC-1144, RFC-2507] 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,
RFC-2883] and Timestamps [RFC-1323].
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 [RFC-3095], compliant with
the requirements on ROHC TCP/IP header compression [TCP-REQ].
Specifically, it describes a header compression scheme for TCP/IP
header compression (ROHC-TCP) that is robust against packet loss and
that offers enhanced capabilities, in particular for the compression
of header fields including TCP options. The profile identifier for
TCP/IP compression is 0x0006.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
This document reuses some of the terminology found in [RFC-3095]. In
addition, this document defines the following terms:
Base context
The base context is a context that has been validated by both the
compressor and the decompressor. A base context can be used as the
reference when building a new context using replication.
Base CID
The Base Context Identifier is the CID used to identify the Base
Context, where information needed for context replication can
be extracted from.
Pelletier, et al. [Page 4]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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.
Short-lived TCP Transfer
Short-lived TCP transfers refer to the 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 [RFC-3095]. 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.
The behavior analysis of TCP/IP header fields among multiple short-
lived connections may be found in [TCP-BEH].
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] 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.
Pelletier, et al. [Page 5]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
To reduce the errors due to the inconsistent contexts between
compressor and decompressor when compressing TCP, IPHC [RFC-2507]
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.
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 [TCP-BEH]. 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
Pelletier, et al. [Page 6]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
- 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], the IP-ID is generally
inferred from the RTP Sequence Number. However, with respect to TCP
compression, the analysis in [TCP-BEH] 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.) are very hard to predict and
differs entirely from the behavior of RTP fields discussed in [RFC-
3095]. Of particular importance to a TCP/IP header compression scheme
is the understanding of the sequence and acknowledgement number [TCP-
BEH]. Specifically, at any point on the path (i.e. wherever a
compressor might be deployed), the sequence number can be anywhere
within a range defined by the TCP window. Missing packets or
retransmissions can cause the TCP sequence number to fluctuate within
the limits of this window. The jumps in acknowledgement number are
also bounded by this TCP window.
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 similar reasons as those
described in [RFC-3095].
Pelletier, et al. [Page 7]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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
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 [TCP-BEH].
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.
Pelletier, et al. [Page 8]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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]. Like for other ROHC profiles, ROHC-TCP makes
use of the ROHC protocol as described in [RFC-3095, sections 5.1 to
5.2.6]. This include 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 [TCP-REQ]. ROHC-TCP therefore supports context
replication as defined in [ROHC-CR]; 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]. Transitions need not be
synchronized between the two state machines.
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 [ROHC-FN].
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 [RFC-3095].
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 start in
the lower compression state (IR). The compressor will normally
Pelletier, et al. [Page 9]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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.
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.
Pelletier, et al. [Page 10]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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
Decisions about transitions between the IR and the CO states are
taken by the compressor 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.
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 a feedback channel has been
Pelletier, et al. [Page 11]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
established by the decompressor, 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) found in [ROHC-CR] must be added to the compressor
state machine described above. 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.
Pelletier, et al. [Page 12]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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 |
+-----<------<------<-----+ +-----<------<------<-----+
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
Pelletier, et al. [Page 13]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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 SHOULD
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
layer. The decompressor will then use this packet as the reference
value, if it is not older than the current reference packet (based on
sequence numbers in the compressed packet or in the uncompressed
header).
5.2.4. Allowing decompression
<# Editor's Note: CO packets containing a large amount of context #>
<# updating information will use a 7-(or 8)bit CRC #>
<# their packet format, in the next version of this #>
<# draft #>
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], IR-CR packets may be decompressed in any state.
Pelletier, et al. [Page 14]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
5.2.5. Reconstruction and verification
<# Editor's Note: The definition of the CRC polynomials will be #>
<# included in the library of encoding methods in #>
<# ROHC-FN. #>
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 a CRC verification fails following the
decompression of an IR-CR packet are specified in [ROHC-CR]. For
other packet types carrying a CRC, if feedback is used the logic
specified in section 5.2.7 must be followed when a 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.
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 feedback channel will then be used by the decompressor
to send error recovery requests and (optionally) acknowledgements of
significant context updates.
Once a feedback channel is established by the decompressor, the
compressor will operate using an optimistic logic. In particular,
this means that the compressor will rely on a 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 for the lifetime of the packet
stream as follow:
Pelletier, et al. [Page 15]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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
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.
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. Feedback channel considerations
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.
Pelletier, et al. [Page 16]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
To parallel [RFC-3095], 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.2. 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. It 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 MSN can later be used by the
compressor to infer which packet is being acknowledged by the
decompressor.
6.3. Initialization
The static context of ROHC TCP streams can be initialized in either
two ways:
1) By using an IR packet as in section 5.4.1, where the profile is
six (6) and the static chain ends with the static part of a TCP
packet. At the compressor, the MSN is initialized to a random value
[RFC-1948] when the initial IR packet is sent.
2) By replicating an existing context using the mechanism defined in
[ROHC-CR]. This is done with an IR-CR packet as in section 5.4.3,
where the profile number is six (6) and the static replication chain
ends with the static part of a TCP packet. At the compressor, the MSN
is then reinitialized to a random value [RFC-1948] when the initial
IR-CR packet is sent.
Pelletier, et al. [Page 17]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
6.4. Packet types
ROHC-TCP defines two different packet types: the Initialization and
Refresh (IR) packet type, and the Compressed packet type (CO). Each
type correspond to one of the possible states of the compressor.
Each packet type also define a number of packet formats: 30 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 [ROHC-CR] is
also defined in this section.
6.4.1. Initialization and Refresh packets (IR)
The ROHC-TCP IR packet follows the general format of the ROHC IR
packet, as defined in [RFC-3095, section 5.2.3].
Packet type: IR
This packet type communicates the static part and the dynamic part
of the context.
The ROHC-TCP IR 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 1 0 0 | IR 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 [RFC-3095, section 5.9.1.].
Pelletier, et al. [Page 18]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
profile_specific_part: The format of this field is defined using
the formal notation in section 6.5.4.
Payload: The payload of the corresponding original packet, if
any. The presence of a payload is inferred from the packet
length.
Packet type: IR-DYN
This packet type communicates the dynamic part of the context.
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 [RFC-3095, section 5.9.1.].
profile_specific_part: The format of this field is defined using
the formal notation in section 6.5.4.
Payload: The payload of the corresponding original packet, if
any. The presence of a payload is inferred from the packet
length.
6.4.2. Context Replication packets (IR-CR)
ROHC-TCP supports the context replication mechanism defined in [ROHC-
CR]. Context replication requires a dedicated IR packet format that
uniquely identifies the IR-CR packet for this profile.
Pelletier, et al. [Page 19]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
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, section 3.4.2.]. With consideration
to the extensibility of the IR packet type defined in [RFC-3095], 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 one.
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 1 | 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
+---+---+---+---+---+---+---+---+
| | present if B = 1,
/ Base CID / 1 octet if for small CIDs, or
| | 1-2 octets if for large CIDs
+---+---+---+---+---+---+---+---+
| |
| profile_specific_part / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ 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 [ROHC-CR, section 3.4.1.1].
Pelletier, et al. [Page 20]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
profile_specific_part: Static and dynamic subheader information
used for replication. What information is present is inferred
from a list of discriminators within the IR-CR packet format.
The format of this field is defined using the formal notation
in section 6.5.5.1.
Payload: The payload of the corresponding original packet, if
any. The presence of a payload is inferred from the packet
length.
6.4.3. Compressed packets (CO)
The ROHC-TCP CO packets communicates irregularities in the packet
header. All CO packets carry a CRC and can update the context.
6.5. Packet formats
<# #>
<# Editor's Note: The packet formats are unchanged from the #>
<# previous version of this draft. #>
<# The packet formats will be updated in the next #>
<# version to support IPv6, to fix some problems #>
<# with the current formats, to octet-align the #>
<# fields in the compressed formats and generally #>
<# improve the formatting. #>
<# Some explanatory text improving clarity should #>
<# also be added throughout this section. #>
<# #>
This section describes the set of compressed TCP/IP packet formats.
The normative description of the packet formats is given using the
Formal Notation for Robust Header Compression [ROHC-FN]. The ROHC-FN
description of the packet formats specifies all of the information
needed to compress and decompress a header relative to the context.
In particular, it 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 [ROHC-FN] for an explanation of the Formal Notation
itself, and the encoding methods used to compress each of the fields
in the TCP/IP header.
The following constants are defined to improve readability of the
packet formats in this section:
sequential_ip_id ::= constant(0),
random_ip_id ::= constant(1),
zero_ip_id ::= constant(0),
nonzero_ip_id ::= constant(1),
tcp_ecn_used ::= constant(0),
tcp_ecn_unused ::= constant(1),
Pelletier, et al. [Page 21]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
6.5.1. Uncompressed TCP/IP packet
The uncompressed format of the TCP/IP header specified using the
formal notation is as follow:
tcp_ip ::= multiple_packet_formats,
uncompressed_format ::= ip_version, % 4 bits
ip_header_length, % 4 bits
ip_tos, % 6 bits
ip_ecn, % 2 bits
ip_length, % 16 bits
ip_id, % 16 bits
ip_reserved, % 1 bit
ip_dont_frag, % 1 bit
ip_more_fragments, % 1 bit
ip_offset, % 13 bits
ip_ttl, % 8 bits
ip_protocol, % 8 bits
ip_checksum, % 16 bits
ip_src_addr, % 32 bits
ip_dest_addr, % 32 bits
tcp_src_port, % 16 bits
tcp_dest_port, % 16 bits
tcp_seq_number, % 32 bits
tcp_ack_number, % 32 bits
tcp_data_offset, % 4 bits
tcp_reserved, % 4 bits
tcp_flags_ecn, % 2 bits
tcp_flags_urg, % 1 bit
tcp_flags_ack, % 1 bit
tcp_flags_psh, % 1 bit
tcp_flags_rsf, % 3 bits
tcp_window, % 16 bits
tcp_checksum, % 16 bits
tcp_urg_point, % 16 bits
tcp_options, % data_offset * 32
% - 160 bits
<# Editor's Note: Explanatory text regarding tcp options should #>
<# be added #>
Pelletier, et al. [Page 22]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
6.5.2. Default encoding methods
The following notation defines a set of default encoding methods for
fields in the TCP/IP header. If a particular CO packet format does
not specify how to encode a field, then it is assumed to use the
default encoding method.
default_methods ::= ... ,
{ ip_version ::= value(4, 4),
ip_header_length ::= value(4, 5),
ip_tos ::= static,
ip_ecn ::= derived_value,
{ field_length ::= constant(2),
field_value ::=
expression((uncomp(tcp_ip.tcp_ecn_and_reserved) // 16) mod 4)
},
ip_length ::= inferred_size(16, 0),
ip_id ::= multiple_packet_formats,
{ uncompressed_format ::= ip_id, % 16 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 0 bit
ip_id, % 16 bits
{ discriminator ::= '',
discriminator.format ::= same_as(nonzero_ip_id),
ip_id ::= irregular(16)
},
co_format_1 ::= discriminator, % 0 bit
ip_id, % 0 bit
{ discriminator ::= '',
discriminator.format ::= same_as(zero_ip_id),
ip_id ::= value(16, 0)
}
},
ip_reserved ::= static,
ip_dont_frag ::= static,
ip_more_fragments ::= value(1, 0),
ip_offset ::= value(13, 0),
ip_ttl ::= static,
ip_protocol ::= value(8, 6),
ip_checksum ::= inferred_ip_checksum,
ip_src_addr ::= static,
ip_dest_addr ::= static,
Pelletier, et al. [Page 23]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_src_port ::= static,
tcp_dest_port ::= static,
tcp_seq_number ::= derived_value,
{ field_length ::= constant(32),
field_value ::=
expression(uncomp(tcp_seq_number_scaled) *
uncomp(tcp_payload_size) +
uncomp(tcp_seq_number_residue))
},
tcp_ack_number ::= static,
tcp_data_offset ::= derived_value,
{ field_length ::= constant(4),
field_value ::=
expression((uncomp(tcp_ip.tcp_options.list_length) + 160) // 32)
},
tcp_reserved ::= derived_value,
{ field_length ::= constant(4),
field_value ::=
expression(uncomp(tcp_ip.tcp_ecn_and_reserved) mod 16)
},
tcp_flags_ecn ::= derived_value,
{ field_length ::= constant(2),
field_value ::=
expression(uncomp(tcp_ip.tcp_ecn_and_reserved) // 64)
},
tcp_flags_urg ::= value(1, 0),
tcp_window ::= static,
tcp_urg_point ::= static,
tcp_ecn_and_reserved ::= control_field,
{ base_field ::= group,
{ field_list ::= tcp_ip.tcp_flags_ecn,
tcp_ip.ip_ecn,
tcp_ip.tcp_reserved
},
compressed_method ::= multiple_packet_formats,
{ uncompressed_format ::= tcp_ecn_and_reserved, % 8 bits
co_num_formats ::= constant(2),
Pelletier, et al. [Page 24]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
co_format_0 ::= discriminator, % 0 bit
tcp_ecn_and_reserved, % 0 bit
{ discriminator ::= '',
discriminator.format ::= same_as(tcp_ecn_unused),
tcp_ecn_and_reserved ::= value(8, 0)
},
co_format_1 ::= discriminator, % 0 bit
tcp_ecn_and_reserved, % 8 bits
{ discriminator ::= '',
discriminator.format ::= same_as(tcp_ecn_used),
tcp_ecn_and_reserved ::= irregular(8)
}
}
},
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= static
},
tcp_seq_number_residue ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) mod
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= static
},
order_flag ::= control_field,
{ base_field ::=
same_as(tcp_ip.tcp_options.order_flag),
compressed_method ::= value(1, 0)
},
presence_flag ::= control_field,
{ base_field ::=
same_as(tcp_ip.tcp_options.presence_flag),
compressed_method ::= value(1, 0)
},
Pelletier, et al. [Page 25]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
6.5.3. Compressed TCP Options using list encoding
The following notation defines how to compress the TCP options:
tcp_options ::= list_of_known_length,
{
list_length ::=
expression(uncomp(tcp_ip.tcp_data_offset)
* 32 - 160),
list_items ::= mss,
wsopt,
sack_permitted,
timestamp,
nop,
eol,
sack,
generic,
order_flag ::= from_list(tcp_ip.order_flag),
presence_flag ::= from_list(tcp_ip.presence_flag),
mss ::= single_packet_format,
{
uncompressed_data ::= kind, % 8 bits
length, % 8 bits
mss, % 16 bits
compressed_data ::= mss, % 16 bits
kind ::= value(8, 2),
length ::= value(8, 4),
mss ::= irregular(16)
},
wsopt ::= single_packet_format,
{
uncompressed_data ::= kind, % 8 bits
length, % 8 bits
scale, % 8 bits
compressed_data ::= wscale, % 8 bits
kind ::= value(8, 3),
length ::= value(8, 3),
wscale ::= irregular(8)
},
eol ::= value(8, 0),
nop ::= value(8, 1),
Pelletier, et al. [Page 26]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
sack ::= single_packet_format,
{
uncompressed_data ::= kind, % 8 bits
length, % 8 bits
sack_blocks, % list_length bits
compressed_data ::= sack_blocks,
kind ::= value(8, 5),
length ::= static,
sack_blocks ::= list_of_known_length,
{
list_length ::= expression(uncomp(length) * 8 - 16),
list_items ::= sack_block,
sack_block,
sack_block,
sack_block,
sack_block ::= multiple_packet_formats,
{
uncompressed_data ::= block_start, % 32 bits
block_end, % 32 bits
co_format_count ::= constant(3),
co_format_0 ::= discriminator, % 2 bits
block_start, % 32 bits
block_end.offset, % 14 bits
{
discriminator ::= '00',
block_start ::= irregular(32),
block_end ::= inferred_offset(32),
{
base_field ::= same_as(block_start),
offset ::= irregular(14)
}
},
co_format_1 ::= discriminator, % 2 bits
block_start, % 32 bits
block_end.offset, % 22 bits
{
discriminator ::= '01',
block_start ::= irregular(32),
block_end ::= inferred_offset(32),
{
base_field ::= same_as(block_start),
offset ::= irregular(22)
}
Pelletier, et al. [Page 27]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
},
co_format_2 ::= discriminator, % 2 bits
block_start, % 32 bits
block_end.offset, % 30 bits
{
discriminator ::= '10',
block_start ::= irregular(32),
block_end ::= inferred_offset(32),
{
base_field ::= same_as(block_start),
offset ::= irregular(30)
}
}
}
}
},
timestamp ::= multiple_packet_formats,
{
co_num_formats ::= constant(5),
uncompressed_format ::= kind, % 8 bits
length, % 8 bits
value, % 32 bits
echo_reply, % 32 bits
co_format_0 ::= discriminator, % 4 bits
value, % 14 bits
echo_reply, % 14 bits
{ discriminator ::= '0000',
kind ::= value(8, 8),
length ::= value(8, 10),
value ::= lsb(14, 0),
echo_reply ::= lsb(14, 0)
},
co_format_1 ::= discriminator, % 4 bits
value, % 14 bits
echo_reply, % 22 bits
{ discriminator ::= '0001',
kind ::= value(8, 8),
length ::= value(8, 10),
value ::= lsb(14, 0),
echo_reply ::= lsb(22, 0)
},
co_format_2 ::= discriminator, % 4 bits
Pelletier, et al. [Page 28]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
value, % 22 bits
echo_reply, % 14 bits
{ discriminator ::= '0010',
kind ::= value(8, 8),
length ::= value(8, 10),
value ::= lsb(22, 0),
echo_reply ::= lsb(14, 0)
},
co_format_3 ::= discriminator, % 4 bits
value, % 22 bits
echo_reply, % 22 bits
{ discriminator ::= '0011',
kind ::= value(8, 8),
length ::= value(8, 10),
value ::= lsb(22, 0),
echo_reply ::= lsb(22, 0) },
co_format_4 ::= discriminator, % 8 bits
value, % 32 bits
echo_reply, % 32 bits
{ discriminator ::= '10000000',
kind ::= value(8, 8),
length ::= value(8, 10),
value ::= irregular(32),
echo_reply ::= irregular(32)
}
},
generic ::= single_packet_format,
{ uncompressed_data ::= kind, % 8 bits
length, % 8 bits
data_item, % data_size bits
compressed_data ::= data_item,
kind ::= static,
length ::= static,
data_item ::=
uncompressible(tcp_ip.tcp_options.generic.length, 8, 1, -16)
}
}
}
}.
Pelletier, et al. [Page 29]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
6.5.4. Packet type IR and IR-DYN
<# Editor's Note: Is the coverage part of the definition of the #>
<# CRC encoding method in the formal notation? #>
<# Editor's Note: This section attempts to make a binding #>
<# between the packet format using the formal #>
<# notation and the notation in rfc-3095. #>
ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets
as defined in [RFC-3095, section 5.2.3. and 5.2.4. respectively]. The
8-bit CRC is computed according to [RFC-3095, section 5.9.1.].
For the ROHC-TCP IR packet, the value of the x bit must be set to
zero. The profile-specific information of the IR packet consists of
the static chain, the dynamic chain and TCP options, as follow:
profile_specific_part ::= ir_static_part,
ir_dynamic_part,
tcp_ip.options.
For the ROHC-TCP IR-DYN packet, the profile-specific information of
the IR-DYN packet consists of the dynamic chain and TCP options only,
as follow:
profile_specific_part ::= ir_dynamic_part,
tcp_ip.options .
The static and dynamic parts have the following format:
ir_static_part ::= ip_src_addr, % 32 bits
ip_dest_addr, % 32 bits
tcp_src_port, % 16 bits
tcp_dest_port, % 16 bits
{ ip_src_addr ::= irregular(32),
ip_dest_addr ::= irregular(32),
tcp_src_port ::= irregular(16),
tcp_dest_port ::= irregular(16) },
ir_dynamic_part ::= discriminator, % 2 bits
format, % 1 bit
ip_id.discriminator, % 1 bit
tcp_ecn_and_reserved.discriminator,
% 1 bit
order_flag, % 1 bit
presence_flag, % 1 bit
ip_reserved, % 1 bit
msn, % 16 bits
ip_tos, % 6 bits
ip_dont_frag, % 1 bit
Pelletier, et al. [Page 30]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_flags_ack, % 1 bit
ip_ttl, % 8 bits
tcp_seq_number, % 32 bits
tcp_ack_number % 32 bits
tcp_window, % 16 bits
tcp_checksum, % 16 bits
tcp_urg_point, % 16 bits
tcp_data_offset, % 4 bits
tcp_flags_psh, % 1 bit
tcp_flags_rsf, % 3 bits
ip_id, % 0 or 16 bits
tcp_ecn_and_reserved,% 0 or 8 bits
tcp_options,% variable no. of bits
{ discriminator ::= '00',
{ num_formats ::= constant(2) },
discriminator.format ::= irregular(1),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= irregular(16) },
ip_tos ::= irregular(6),
ip_id ::= multiple_packet_formats,
{ uncompressed_format ::= ip_id, % 16 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bit
ip_id, % 16 bits
{ discriminator ::= '0',
discriminator.format ::= value(1, 0), % non-zero IP ID
ip_id ::= irregular(16) },
co_format_1 ::= discriminator, % 1 bit
ip_id, % 0 bit
{ discriminator ::= '1',
discriminator.format ::= value(1, 1), % zero IP ID
ip_id ::= value(16, 0) }
}
ip_reserved ::= irregular(1),
ip_dont_frag ::= irregular(1),
ip_ttl ::= irregular(8),
tcp_seq_number ::= irregular(32),
tcp_ack_number ::= irregular(32),
tcp_data_offset ::= irregular(4),
tcp_flags_ack ::= irregular(1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= irregular(3),
tcp_window ::= irregular(16),
tcp_checksum ::= irregular(16),
tcp_urg_point ::= irregular(16),
tcp_ecn_and_reserved ::= control_field,
{ base_field ::= group,
{ field_list ::= tcp_ip.tcp_flags_ecn,
tcp_ip.ip_ecn,
Pelletier, et al. [Page 31]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_ip.tcp_reserved },
compressed_method ::= multiple_packet_formats,
{ uncompressed_format ::= tcp_ecn_and_reserved, % 8 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bit
tcp_ecn_and_reserved, % 0 bit
{ discriminator ::= '0',
discriminator.format ::= value(1, 0), % ECN/reserved
% unused
tcp_ecn_and_reserved ::= value(8, 0) },
co_format_1 ::= discriminator, % 1 bit
tcp_ecn_and_reserved,% 8 bits
{ discriminator ::= '1',
discriminator.format ::= value(1, 1), % ECN/reserved
% used
tcp_ecn_and_reserved ::= irregular(8)
}
}
},
order_flag ::= control_field,
{ base_field ::=
same_as(tcp_ip.default_methods.tcp_options.order_flag),
compressed_method ::= irregular(1)
},
presence_flag ::= control_field,
{ base_field ::=
same_as(tcp_ip.default_methods.tcp_options.presence_flag),
compressed_method ::= irregular(1)
}
},
6.5.5. Compressed TCP/IP packets
6.5.5.1. Packet type IR-CR
The profile-specific information of the IR-CR packet consists of a
replicated part common to all IR-CR formats along with fields
specific to the particular format, as follow:
profile_specific_part ::= replicate_formats,
tcp_ip.options.
Pelletier, et al. [Page 32]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
The following notation describes the IR-REPLICATE packet. Options are
as per IR/IR-DYNAMIC packets.
replicate_format_0 ::= discriminator, % 4 bits
format, % 1 bit
ip_id.discriminator, % 1 bit
ip_src_addr.discriminator, % 1 bit
ip_dst_addr.discriminator, % 1 bit
ip_tos.discriminator, % 1 bit
ip_ttl.discriminator, % 1 bit
tcp_src_port.discriminator, % 2 bits
tcp_dst_port.discriminator, % 2 bits
tcp_ack_number.discriminator, % 1 bit
tcp_ecn_and_reserved.discriminator,% 1 bit
order_flag, % 1 bit
presence_flag, % 1 bit
ip_dont_frag, % 1 bit
tcp_flags_urg, % 1 bit
tcp_flags_ack, % 1 bit
tcp_flags_psh, % 1 bit
tcp_flags_rsf, % 2 bits
header_crc, % 8 bits
msn, % 16 bits
tcp_seq_number, % 32 bits
ip_src_addr, % 0 or 32 bits
ip_dst_addr, % 0 or 32 bits
ip_id, % 0 or 16 bits
tcp_src_port, % 0, 8 or 16 bits
tcp_dst_port, % 0, 8 or 16 bits
tcp_ack_number, % 0 or 32 bits
tcp_ecn_and_reserved, % 0 or 8 bits
tcp_options, % variable no. of bits
{ discriminator ::= '0000',
discriminator.format ::= irregular(1),
ip_dont_frag ::= irregular(1),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= irregular(16) },
ip_id ::= multiple_packet_formats,
{ uncompressed_format ::= ip_id, % 16 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bit
ip_id, % 16 bits
{ discriminator ::= '0',
discriminator.format ::= value(1, 0),
% non-zero IP ID theoretically replicable, but only saves 1 bit
Pelletier, et al. [Page 33]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
ip_id ::= irregular(16)
},
co_format_1 ::= discriminator, % 1 bit
ip_id, % 0 bit
{ discriminator ::= '1',
discriminator.format ::= value(1, 1),
% zero IP ID theoretically replicable, but only saves 1 bit
ip_id ::= value(16, 0)
}
},
header_crc ::= crc(8),
ip_src_addr ::= multiple_packet_formats,
{ uncompressed_format ::= ip_src_addr, % 32 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bit
ip_src_addr, % 0 bit
{ discriminator ::= '0',
ip_src_addr ::= static
},
co_format_1 ::= discriminator, % 1 bit
ip_src_addr, % 32 bits
{ discriminator ::= '1',
ip_src_addr ::= irregular(32)
}
},
ip_dst_addr ::= multiple_packet_formats,
{ uncompressed_format ::= ip_dst_addr, % 32 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bit
ip_dst_addr, % 0 bit
{ discriminator ::= '0',
ip_dst_addr ::= static
},
co_format_1 ::= discriminator, % 1 bit
ip_dst_addr, % 32 bits
{ discriminator ::= '1',
ip_dst_addr ::= irregular(32)
}
},
ip_tos ::= multiple_packet_formats,
{ uncompressed_format ::= ip_tos, % 8 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bit
ip_tos, % 0 bit
{ discriminator ::= '0',
Pelletier, et al. [Page 34]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
ip_tos ::= static
},
co_format_1 ::= discriminator, % 1 bit
ip_tos, % 8 bits
{ discriminator ::= '1',
ip_tos ::= irregular(8)
}
},
ip_ttl ::= multiple_packet_formats,
{ uncompressed_format ::= ip_ttl, % 8 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bit
ip_ttl, % 0 bit
{ discriminator ::= '0',
ip_ttl ::= static
},
co_format_1 ::= discriminator, % 1 bit
ip_ttl, % 8 bits
{ discriminator ::= '1',
ip_ttl ::= irregular(8)
}
},
tcp_flags_urg ::= irregular(1)
tcp_flags_ack ::= irregular(1)
tcp_flags_psh ::= irregular(1)
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_ecn_and_reserved ::= control_field,
{ base_field ::= group,
{ field_list ::= tcp_ip.tcp_flags_ecn,
tcp_ip.ip_ecn,
tcp_ip.tcp_reserved
},
compressed_method ::= multiple_packet_formats,
{ uncompressed_format ::= tcp_ecn_and_reserved,% 8 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bits
tcp_ecn_and_reserved,% 0 bit
{ discriminator ::= '0',
discriminator.format ::= value (1, 0),
tcp_ecn_and_reserved ::= value(8, 0)
Pelletier, et al. [Page 35]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
},
co_format_1 ::= discriminator, % 1 bit
tcp_ecn_and_reserved,% 8 bits
{ discriminator ::= '1',
discriminator.format ::= value (1, 1),
tcp_ecn_and_reserved ::= irregular(8)
}
}
},
tcp_src_port ::= multiple_packet_formats,
{ uncompressed_format ::= tcp_src_port, % 32 bits
co_num_formats ::= constant(3),
co_format_0 ::= discriminator, % 2 bits
tcp_src_port, % 0 bit
{ discriminator ::= '00',
tcp_src_port ::= static
},
co_format_1 ::= discriminator, % 2 bits
tcp_src_port, % 8 bits
{ discriminator ::= '01',
tcp_src_port ::= lsb(8,64)
},
co_format_1 ::= discriminator, % 2 bits
tcp_src_port, % 16 bits
{ discriminator ::= '10',
tcp_src_port ::= irregular(16)
},
},
tcp_dst_port ::= multiple_packet_formats,
{ uncompressed_format ::= tcp_dst_port, % 32 bits
co_num_formats ::= constant(3),
co_format_0 ::= discriminator, % 2 bits
tcp_dst_port, % 0 bit
{ discriminator ::= '00',
tcp_dst_port ::= static
},
co_format_1 ::= discriminator, % 2 bits
tcp_dst_port, % 8 bits
{ discriminator ::= '01',
tcp_dst_port ::= lsb(8,64)
},
co_format_1 ::= discriminator, % 2 bits
tcp_dst_port, % 16 bits
{ discriminator ::= '10',
tcp_dst_port ::= irregular(16)
},
},
Pelletier, et al. [Page 36]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_seq_number ::= irregular(32),
tcp_ack_number ::= multiple_packet_formats,
{ uncompressed_format ::= tcp_ack_number % 32 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bit
tcp_ack_number, % 0 bit
{ discriminator ::= '0',
tcp_ack_number ::= value(32,0)
},
co_format_1 ::= discriminator, % 1 bit
tcp_ack_number, % 32 bits
{ discriminator ::= '1',
tcp_ack_number ::= irregular(32)
}
},
tcp_window ::= multiple_packet_formats,
{ uncompressed_format ::= tcp_window, % 16 bits
co_num_formats ::= constant(2),
co_format_0 ::= discriminator, % 1 bit
tcp_window, % 0 bit
{ discriminator ::= '0',
tcp_window ::= static
},
co_format_1 ::= discriminator, % 1 bit
tcp_window, % 16 bits
{ discriminator ::= '1',
tcp_window ::= irregular(16)
}
},
tcp_urg_point ::= value(16, 0)
order_flag ::= control_field,
{ base_field ::=
same_as(tcp_ip.default_methods.tcp_options.order_flag),
compressed_method ::= irregular(1)
},
presence_flag ::= control_field,
{ base_field ::=
same_as(tcp_ip.default_methods.tcp_options.presence_flag),
compressed_method ::= irregular(1)
}
}
Pelletier, et al. [Page 37]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
6.5.5.2. Packet type CO
The ROHC-TCP compressed header has the following format:
% The following notation describes all of the 31 compressed (CO)
packet formats
% for the basic TCP/IP header (excluding TCP options, which are
handled separately).
% Open issue: Is this a sensible number of packet formats?
co_num_formats ::= constant(31),
co_format_0 ::= discriminator, % 3 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
header_crc, % 3 bits
tcp_checksum, % 16 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '100',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16)
},
co_format_1 ::= discriminator, % 8 bits
tcp_checksum, % 16 bits
msn, % 1 bit
tcp_seq_number_scaled, % 7 bits
tcp_seq_number_residue, % 0 bit
tcp_flags_psh, % 1 bit
ip_id, % 2 bits
tcp_ack_number, % 2 bits
header_crc, % 3 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '11001100',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
Pelletier, et al. [Page 38]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
ip_id ::= inferred_offset(16),
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= lsb(2, 1)
},
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(7, 63)
}
},
co_format_2 ::= discriminator, % 2 bits
tcp_ack_number, % 14 bits
tcp_checksum, % 16 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
header_crc, % 3 bits
tcp_seq_number_scaled, % 3 bits
tcp_seq_number_residue, % 0 bit
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '01',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1) },
header_crc ::= crc(3),
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(3, 3) } },
co_format_3 ::= discriminator, % 6 bits
msn, % 2 bits
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
tcp_ack_number, % 2 bits
header_crc, % 3 bits
ip_id, % 3 bits
Pelletier, et al. [Page 39]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_flags_rsf, % 3 bits
tcp_seq_number_scaled, % 4 bits
tcp_seq_number_residue, % 0 bit
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '110000',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(3),
ip_id ::= inferred_offset(16),
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= lsb(3, 3)
},
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(4, 3)
}
},
co_format_4 ::= discriminator, % 3 bits
msn, % 1 bit
tcp_seq_number, % 12 bits
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
header_crc, % 3 bits
tcp_ack_number, % 12 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '101',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
tcp_seq_number ::= lsb(12, 1023),
tcp_ack_number ::= lsb(12, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16)
Pelletier, et al. [Page 40]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
},
co_format_5 ::= discriminator, % 8 bits
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
msn, % 2 bits
tcp_seq_number, % 13 bits
tcp_ack_number, % 2 bits
header_crc, % 3 bits
ip_id, % 3 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '11001111',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(3),
ip_id ::= inferred_offset(16),
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= lsb(3, 3)
},
tcp_seq_number ::= lsb(13, 1023),
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 1),
tcp_checksum ::= irregular(16)
},
co_format_6 ::= discriminator, % 8 bits
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
msn, % 2 bits
tcp_seq_number, % 13 bits
tcp_ack_number, % 2 bits
header_crc, % 3 bits
ip_id, % 3 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '11001001',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(3),
ip_id ::= inferred_offset(16),
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= lsb(3, 3) },
Pelletier, et al. [Page 41]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_seq_number ::= lsb(13, 1023),
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16)
},
co_format_7 ::= discriminator, % 4 bits
tcp_seq_number_scaled, % 4 bits
tcp_seq_number_residue, % 0 bit
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
header_crc, % 7 bits
msn, % 2 bits
tcp_ack_number, % 14 bits
ip_id, % 3 bits
tcp_window, % 13 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '1101',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(7),
ip_id ::= inferred_offset(16),
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= lsb(3, 3)
},
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_window ::= lsb(13, 2047),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(4, 3)
}
},
co_format_8 ::= discriminator, % 2 bits
msn, % 1 bit
tcp_window, % 13 bits
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
header_crc, % 7 bits
Pelletier, et al. [Page 42]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_seq_number, % 12 bits
tcp_ack_number, % 12 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '00',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(7),
tcp_seq_number ::= lsb(12, 1023),
tcp_ack_number ::= lsb(12, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_window ::= lsb(13, 2047),
tcp_checksum ::= irregular(16)
},
co_format_9 ::= discriminator, % 9 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
tcp_seq_number, % 2 bits
header_crc, % 3 bits
tcp_ack_number, % 32 bits
tcp_checksum, % 16 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '110010001',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
tcp_seq_number ::= lsb(2, 0),
tcp_ack_number ::= irregular(32),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16)
},
co_format_10 ::= discriminator, % 8 bits
ip_id, % 16 bits
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
msn, % 2 bits
tcp_seq_number, % 13 bits
tcp_ack_number, % 2 bits
Pelletier, et al. [Page 43]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
header_crc, % 3 bits
tcp_flags_rsf, % 3 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '11001110',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(3),
ip_id ::= inferred_offset(16),
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= irregular(16)
},
tcp_seq_number ::= lsb(13, 1023),
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_checksum ::= irregular(16) },
co_format_11 ::= discriminator, % 7 bits
tcp_flags_psh, % 1 bit
tcp_window, % 16 bits
tcp_checksum, % 16 bits
msn, % 2 bits
tcp_ack_number, % 14 bits
ip_id, % 3 bits
tcp_flags_rsf, % 3 bits
tcp_seq_number_scaled, % 3 bits
tcp_seq_number_residue, % 0 bit
header_crc, % 7 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '1100101',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(7),
ip_id ::= inferred_offset(16),
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= lsb(3, 3)
},
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_window ::= irregular(16),
Pelletier, et al. [Page 44]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(3, 3)
}
},
co_format_12 ::= discriminator, % 6 bits
tcp_ack_number, % 2 bits
ip_id, % 16 bits
ip_ttl, % 8 bits
tcp_checksum, % 16 bits
msn, % 1 bit
header_crc, % 7 bits
tcp_flags_psh, % 1 bit
tcp_flags_rsf, % 3 bits
tcp_seq_number, % 12 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '110001',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(7),
ip_id ::= inferred_offset(16),
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= irregular(16)
},
ip_ttl ::= irregular(8),
tcp_seq_number ::= lsb(12, 1023),
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_checksum ::= irregular(16)
},
co_format_13 ::= discriminator, % 9 bits
header_crc, % 7 bits
ip_id, % 16 bits
ip_ttl, % 8 bits
tcp_window, % 16 bits
tcp_checksum, % 16 bits
ip_dont_frag, % 1 bit
tcp_flags_psh, % 1 bit
ip_tos, % 6 bits
msn, % 2 bits
Pelletier, et al. [Page 45]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_ack_number, % 14 bits
tcp_flags_rsf, % 3 bits
tcp_seq_number, % 13 bits
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '110010000',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(7),
ip_tos ::= irregular(6),
ip_id ::= inferred_offset(16),
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= irregular(16)
},
ip_dont_frag ::= irregular(1),
ip_ttl ::= irregular(8),
tcp_seq_number ::= lsb(13, 1023),
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_window ::= irregular(16),
tcp_checksum ::= irregular(16)
},
co_format_14 ::= discriminator, % 8 bits
ip_id, % 16 bits
ip_ttl, % 8 bits
tcp_ack_number, % 32 bits
tcp_window, % 16 bits
tcp_checksum, % 16 bits
msn, % 1 bit
header_crc, % 7 bits
tcp_flags_ack, % 1 bit
tcp_flags_psh, % 1 bit
tcp_flags_rsf, % 3 bits
tcp_seq_number_scaled, % 3 bits
tcp_seq_number_residue, % 0 bit
tcp_ecn_and_reserved, % 0 or 8 bits
{ discriminator ::= '11001101',
discriminator.format ::= same_as(sequential_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(7),
ip_id ::= inferred_offset(16),
Pelletier, et al. [Page 46]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
{ base_field ::= expression(uncomp(tcp_ip.msn)),
compressed_method ::= irregular(16)
},
ip_ttl ::= irregular(8),
tcp_ack_number ::= irregular(32),
tcp_flags_ack ::= irregular(1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_window ::= irregular(16),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(3, 3)
}
},
co_format_15 ::= discriminator, % 3 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
header_crc, % 3 bits
tcp_checksum, % 16 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '100',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16)
},
co_format_16 ::= discriminator, % 3 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
header_crc, % 3 bits
tcp_checksum, % 16 bits
tcp_ack_number, % 2 bits
tcp_flags_rsf, % 3 bits
tcp_seq_number_scaled, % 3 bits
tcp_seq_number_residue, % 0 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
Pelletier, et al. [Page 47]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
{ discriminator ::= '101',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(3, 3)
}
},
co_format_17 ::= discriminator, % 6 bits
msn, % 2 bits
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
tcp_ack_number, % 2 bits
header_crc, % 3 bits
tcp_seq_number_scaled, % 10 bits
tcp_seq_number_residue, % 0 bit
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '110101',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(3),
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(10, 255)
}
},
Pelletier, et al. [Page 48]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
co_format_18 ::= discriminator, % 2 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
tcp_seq_number, % 12 bits
tcp_checksum, % 16 bits
tcp_ack_number, % 2 bits
header_crc, % 3 bits
tcp_flags_rsf, % 3 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '01',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
tcp_seq_number ::= lsb(12, 1023),
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_checksum ::= irregular(16)
},
co_format_19 ::= discriminator, % 6 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
tcp_checksum, % 16 bits
header_crc, % 3 bits
tcp_seq_number, % 13 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '110100',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
tcp_seq_number ::= lsb(13, 1023),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16)
},
co_format_20 ::= discriminator, % 7 bits
msn, % 1 bit
Pelletier, et al. [Page 49]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
header_crc, % 3 bits
tcp_ack_number, % 12 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '1100010',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
tcp_ack_number ::= lsb(12, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16)
},
co_format_21 ::= discriminator, % 6 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
tcp_checksum, % 16 bits
header_crc, % 3 bits
tcp_seq_number_scaled, % 7 bits
tcp_seq_number_residue, % 0 bit
tcp_ack_number, % 14 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '110111',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(3),
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(7, 63)
}
},
Pelletier, et al. [Page 50]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
co_format_22 ::= discriminator, % 7 bits
tcp_flags_psh, % 1 bit
tcp_checksum, % 16 bits
msn, % 2 bits
tcp_ack_number, % 14 bits
header_crc, % 3 bits
tcp_seq_number, % 13 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '1101101',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(3),
tcp_seq_number ::= lsb(13, 1023),
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16)
},
co_format_23 ::= discriminator, % 7 bits
tcp_flags_psh, % 1 bit
ip_ttl, % 8 bits
tcp_checksum, % 16 bits
msn, % 2 bits
tcp_ack_number, % 2 bits
header_crc, % 7 bits
tcp_seq_number, % 13 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '1100000',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(7),
ip_ttl ::= irregular(8),
tcp_seq_number ::= lsb(13, 1023),
tcp_ack_number ::= lsb(2, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16)
Pelletier, et al. [Page 51]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
},
co_format_24 ::= discriminator, % 5 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
header_crc, % 7 bits
tcp_seq_number_scaled, % 7 bits
tcp_seq_number_residue, % 0 bits
tcp_window, % 13 bits
tcp_ack_number, % 14 bits
tcp_checksum, % 16 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '11001',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(7),
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_window ::= lsb(13, 2047),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(7, 63)
}
},
co_format_25 ::= discriminator, % 9 bits
msn, % 1 bit
tcp_flags_psh, % 1 bit
tcp_seq_number, % 2 bits
header_crc, % 3 bits
tcp_ack_number, % 32 bits
tcp_checksum, % 16 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '110110001',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
Pelletier, et al. [Page 52]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
header_crc ::= crc(3),
tcp_seq_number ::= lsb(2, 0),
tcp_ack_number ::= irregular(32),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_checksum ::= irregular(16) },
co_format_26 ::= discriminator, % 2 bits
msn, % 1 bit
tcp_window, % 13 bits
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
header_crc, % 7 bits
tcp_seq_number, % 12 bits
tcp_ack_number, % 12 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '00',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(7),
tcp_seq_number ::= lsb(12, 1023),
tcp_ack_number ::= lsb(12, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_window ::= lsb(13, 2047),
tcp_checksum ::= irregular(16) },
co_format_27 ::= discriminator, % 7 bits
msn, % 1 bit
tcp_window, % 16 bits
tcp_checksum, % 16 bits
tcp_flags_psh, % 1 bit
header_crc, % 7 bits
tcp_flags_rsf, % 3 bits
tcp_seq_number_scaled, % 7 bits
tcp_seq_number_residue, % 0 bit
tcp_ack_number, % 14 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '1100011',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
Pelletier, et al. [Page 53]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(7),
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_window ::= irregular(16),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(7, 63)
}
},
co_format_28 ::= discriminator, % 7 bits
tcp_flags_psh, % 1 bit
ip_ttl, % 8 bits
tcp_checksum, % 16 bits
msn, % 2 bits
tcp_ack_number, % 14 bits
tcp_seq_number_scaled, % 4 bits
tcp_seq_number_residue, % 0 bit
header_crc, % 7 bits
tcp_window, % 13 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '1100001',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(7),
ip_ttl ::= irregular(8),
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= value(3, 0),
tcp_window ::= lsb(13, 2047),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(4, 3)
}
},
Pelletier, et al. [Page 54]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
co_format_29 ::= discriminator, % 9 bits
header_crc, % 7 bits
ip_ttl, % 8 bits
tcp_window, % 16 bits
tcp_checksum, % 16 bits
ip_dont_frag, % 1 bit
tcp_flags_psh, % 1 bit
ip_tos, % 6 bits
msn, % 2 bits
tcp_ack_number, % 14 bits
tcp_flags_rsf, % 3 bits
tcp_seq_number, % 13 bits
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '110110000',
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(2, -1)
},
header_crc ::= crc(7),
ip_tos ::= irregular(6),
ip_dont_frag ::= irregular(1),
ip_ttl ::= irregular(8),
tcp_seq_number ::= lsb(13, 1023),
tcp_ack_number ::= lsb(14, 0),
tcp_flags_ack ::= value(1, 1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_window ::= irregular(16),
tcp_checksum ::= irregular(16)
},
co_format_30 ::= discriminator, % 8 bits
ip_ttl, % 8 bits
tcp_ack_number, % 32 bits
tcp_window, % 16 bits
tcp_checksum, % 16 bits
msn, % 1 bit
header_crc, % 7 bits
tcp_flags_ack, % 1 bit
tcp_flags_psh, % 1 bit
tcp_flags_rsf, % 3 bits
tcp_seq_number_scaled, % 3 bits
tcp_seq_number_residue, % 0 bit
tcp_ecn_and_reserved, % 0 or 8 bits
ip_id, % 0 or 16 bits
{ discriminator ::= '11011001',
Pelletier, et al. [Page 55]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
discriminator.format ::= same_as(random_ip_id),
msn ::= control_field,
{ base_field ::= counter(16),
compressed_method ::= lsb(1, -1)
},
header_crc ::= crc(7),
ip_ttl ::= irregular(8),
tcp_ack_number ::= irregular(32),
tcp_flags_ack ::= irregular(1),
tcp_flags_psh ::= irregular(1),
tcp_flags_rsf ::= index(3, [0, 1, 2, 4]),
tcp_window ::= irregular(16),
tcp_checksum ::= irregular(16),
tcp_seq_number_scaled ::= control_field,
{ base_field ::=
expression(uncomp(tcp_ip.tcp_seq_number) //
uncomp(tcp_ip.tcp_payload_size)),
compressed_method ::= lsb(3, 3)
}
},
co_common ::= tcp_payload_size, % 0 bit
tcp_options, % variable no. of bits
{ tcp_payload_size ::= expression(uncomp(tcp_ip.ip_length) -
((uncomp(tcp_ip.ip_header_length) +
uncomp(tcp_ip.tcp_data_offset)) * 4))
},
Pelletier, et al. [Page 56]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
6.6. Feedback formats and options
6.6.1. Feedback formats
This section describes the feedback format for ROHC-TCP. ROHC-TCP
uses the ROHC feedback format described in [ROHC, section 5.2.2].
All feedback formats carry a field labeled SN. The SN field contains
LSBs of the Master Sequence Number (MSN) described in section 4.1.3.
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 5.5.4.2. Options may appear in any order.
Pelletier, et al. [Page 57]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
6.6.2. Feedback options
ROHC-TCP uses the same feedback options as the options defined in
[RFC-3095, section 5.7.6], with the following exceptions:
1) The MSN replaces RTP SN in the feedback information.
2) The CLOCK option [RFC-3095, section 5.7.6.6] is not used.
3) The JITTER option [RFC-3095, section 5.7.6.7] is not used.
6.6.3. 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 = X | 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.
7. Security considerations
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 which 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
Pelletier, et al. [Page 58]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
layer in this manner raises additional security issues that dwarf
those related to the use of header compression.
8. IANA Considerations
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
9. Acknowledgements
The authors would like to thank Qian Zhang and Hong Bin Liao for
their work with early versions of this specification. Thanks also to
Kristofer Sandlund and Fredrik Lindstroem for reviewing the packet
formats, and to Carsten Bormann and Robert Finking for valuable
input.
10. References
10.1. Normative References
[RFC-3095] 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.
[ROHC-CR] Pelletier, G., "Robust Header Compression (ROHC): Context
replication for ROHC profiles", Internet Draft (work in
progress), <draft-ietf-rohc-context-replication-
02.txt>, April 2004.
Pelletier, et al. [Page 59]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
[ROHC-FN] R. Price et al., "Formal Notation for Robust Header
Compression (ROHC-FN)", Internet Draft (work in
progress),<draft-ietf-rohc-formal-notation-02.txt>,
October 2003.
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC-2026] S. Bradner, "The Internet Standards Process -
Revision 3", RFC-2026, October 1996.
[RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
10.2. Informative References
[TCP-REQ] Jonsson, L-E., "Requirements on ROHC IP/TCP header
compression", Internet Draft (work in progress),<draft-
ietf-rohc-tcp-requirements-05.txt>, October 2002.
[TCP-BEH] West, M. and S. McCann, "TCP/IP Field Behavior", Internet
Draft (work in progress), <draft-ietf-rohc-tcp-field-
behavior-02.txt>, March 2003.
[IP-ONLY] Jonsson, L. and G. Pelletier, "RObust Header Compression
(ROHC): A compression profile for IP", Internet draft
(work in progress), <draft-ietf-rohc-ip-only-05.txt>,
October 2003.
[RFC-1072] Jacobson, V., and R. Braden, "TCP Extensions for Long-
Delay Paths", LBL, ISI, October 1988.
[RFC-1144] Jacobson, V.,"Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC-1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC-1644] Braden, R. "T/TCP -- TCP Extensions for Transactions
Functional Specification", ISI, July 1994.
[RFC-1693] Connolly, T., et al, "An Extension to TCP : Partial Order
Service", University of Delaware, November 1994.
Pelletier, et al. [Page 60]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
[RFC-1889] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RFC-1948] Bellovin, S., "Defending Against Sequence Number
Attacks", RFC 1948, May 1996.
[RFC-2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", NOAO, January
1997.
[RFC-2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October
1996.
[RFC-2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC-2883] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000.
[E2E] Jacobson, V., "Fast Retransmit", Message to the end2end-
interest mailing list, April 1990.
[Mobi96] Degermark, M., Engan, M., Nordgren, B. and S. Pink, "Low-
loss TCP/IP header compression for wireless networks", In
the Proceedings of MobiCom, 1996.
11. Authors' addresses
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 920 20 24 32
Fax: +46 920 20 20 99
Email: ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Email: lars-erik.jonsson@ericsson.com
Pelletier, et al. [Page 61]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
Mark A West
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
Phone: +44 1794 833311
Email: mark.a.west@roke.co.uk
Richard Price
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
Phone: +44 1794 833681
Email: Richard.price@roke.co.uk
Pelletier, et al. [Page 62]
INTERNET-DRAFT ROHC Profile for TCP/IP April 2, 2004
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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 October 2, 2004.
Pelletier, et al. [Page 63]
