Network Working Group Richard Price, Siemens/Roke Manor
INTERNET-DRAFT Mark A West, Siemens/Roke Manor
Expires: November 2003
May 28, 2003
TCP/IP Compressed Packet Formats
<draft-price-rohc-tcp-packet-formats-00.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/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should
be directed to its mailing list, rohc@ietf.org.
Abstract
This document proposes a set of compressed packet formats for the
ROHC-TCP compression profile [ROHC-TCP]. The ROHC-TCP profile 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.
Price et al. [Page 1]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
Table of contents
1. Introduction..................................................2
2. Terminology...................................................3
3. Discussion and open issues....................................3
4. Packet formats described using ROHC-FN........................14
5. Security considerations.......................................19
6. Authors' addresses............................................19
7. References....................................................19
Appendix A: Packet formats described using box notation...........20
1. Introduction
The ROHC-TCP compression profile [ROHC-TCP] describes a header
compression scheme for TCP/IP that is robust against packet loss and
which offers enhanced capabilities, in particular for the compression
of header fields including TCP options. ROHC-TCP is offered as a
profile for the ROHC framework [RFC-3095], compliant with the
requirements on ROHC TCP/IP header compression [TCP-REQ].
An important missing piece of the current ROHC-TCP profile is a set
of compressed packet formats, which can be used to encode the
information contained in a TCP/IP header into a more compact form.
This document proposes a set of packet formats for ROHC-TCP, designed
to offer a suitable balance between compression efficiency,
robustness, future-proofing and implementation complexity.
Section 3 of the draft contains a discussion of the various design
decisions taken when generating the TCP/IP packet formats. The
topics which may benefit from further discussion are marked as "open
issues" - the authors would welcome additional feedback and
suggestions on any of these topics.
Section 4 gives the normative description of the proposed set of
TCP/IP packet formats, 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.
Appendix A provides an informative description of the fields present
in each compressed packet, using the traditional RFC "box notation".
The packet format diagrams can be derived automatically from the
ROHC-FN description via a suitable tool (note however that the
converse is not possible as the box notation defines the fields
present in each compressed header, but does not explain how to map
them to the corresponding uncompressed headers).
Price et al. [Page 2]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC-2119].
An explanation of the terminology used in this document can be found
in [ROHC-TCP].
3. Discussion and open issues
The following sections discuss the various design decisions taken
when generating the TCP/IP packet formats. The topics which may
benefit from further discussion are marked as "open issues" -
additional feedback and suggestions on any of these would be
gratefully received.
3.1. IPv4
This section covers the fields found in an IPv4 header.
Open issue: Currently we only handle a single IPv4 header - how many
nested IPv4 headers do we need to handle in the final profile? Also,
how many IPv4 headers do we need to actually compress (as opposed to
merely passing through transparently)?
3.1.1. IP Version
For IPv4, the IP Version is a 4-bit field that always takes the value
4. Hence it can be encoded using the "value(4,4)" encoding method,
requiring no bits in the compressed header.
Open issue: In RFC 3095, the IP Version field is transmitted in full
in the IR packet. However, since the field can only take two
possible values (4 or 6), why not compress it down to a single bit?
3.1.2. IP Header Length
As long as no options are present in the IP header, the header
length must always take the value 5. Consequently it can be encoded
as "value(4,5)", and no bits are required in the compressed header.
3.1.3. IP Type of Service
As per [TCP-BEH], the IP TOS field is divided into a 6-bit DSCP
(DiffServ Codepoint) field followed by a pair of ECN flags.
The DSCP field is currently encoded as "static" in the CO packets and
as "irregular(6)" in the IR(-DYN) packets (i.e. it is transmitted in
full).
Price et al. [Page 3]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
Open issue: How should the DSCP field be handled in the IR-REPLICATE
packets? It is likely that replicable flows will share the same
DSCP, but this is not 100% guaranteed. Therefore, would it be
sensible to offer two possible encodings for the DSCP field ("static"
and "irregular") in the IR-REPLICATE packet?
The behavior of the ECN flags is linked to the behavior of the ECN
flags in the TCP header. See Section 3.3.5 for a description of how
these flags are encoded.
3.1.4. IP Packet Length
The IP Packet Length is a 16-bit field whose value can be inferred
from the total size of the uncompressed packet. Therefore, we encode
the field using the "inferred_size" encoding method and send no bits
in the compressed header.
3.1.5. IP-ID
The IP-ID is currently compressed in two steps. Firstly, the Master
Sequence Number (MSN) is subtracted from the uncompressed IP-ID.
Secondly, the resulting offset bits are compressed using a choice of
encoding method: in the CO packets the offset can be encoded as
"static" or as "lsb(8,0)", but in the IR(-DYN) packets it is
transmitted in full.
For the purpose of calculating the discriminator bits, the "static"
encoding method is expected to be used in 90% of the CO packets, and
the "lsb(8,0)" encoding method is expected to be used in 10% of the
CO packets.
Open issue: Should we take into account the Network Byte Order (NBO)
when deriving the IP-ID offset from the MSN?
Open issue: Should we generate two different sets of packet formats,
one for a sequential IP-ID and one for a random IP-ID, as per RFC
3095?
Open issue: In the Linux TCP stack, the IP-ID seems to be set to 0 in
the SYN, SYN-ACK and FIN packets. Is it worth taking this behavior
into account?
Open issue: Can we replicate the IP-ID from a base context?
3.1.6. IP Reserved Flag
As per [RFC-3095], the IP Reserved Flag is assumed to always take the
value 0. Thus, it can be encoded as "value(1,0)", and no bits are
required in any of the compressed headers.
Price et al. [Page 4]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
Open issue: In [TCP-BEH], it is suggested that assuming the IP
Reserved Flag is always 0 may be too restrictive. For future
proofing, is it worth including a packet format where this flag can
take a non-zero value?
3.1.7. IP Don't Fragment Flag
As per [TCP-BEH], the IP Don't Fragment Flag is expected to generally
remain constant for the duration of a flow. In the CO packets, we
currently offer a choice of two encoding methods: "static" and
"irregular(1)". In the IR(-DYN) packets the flag is always sent in
full.
When calculating the discriminator bits, the "static" encoding is
expected to be used in 99% of the CO packets.
Open issue: Is there any need to have the CO packet that sends the
Don't Fragment Flag explicitly?
3.1.8. IP More Fragments Flag
As per [RFC-3095], the IP More Fragments Flag is assumed to always
take the value 0. Thus, it can be encoded as "value(1,0)", and no
bits are required in any of the compressed headers.
3.1.9. IP Fragment Offset
As per [RFC-3095], the IP Fragment Offset is assumed to always take
the value 0. Thus, it can be encoded as "value(13,0)", and no bits
are required in any of the compressed headers.
3.1.10. IP Time To Live
The IP Time To Live field is expected to generally remain constant
for the duration of a flow. In the CO packets, we currently offer a
choice of two encoding methods: "static" and "irregular(8)". In the
IR(-DYN) packets the flag is always sent in full.
When calculating the discriminator bits, the "static" encoding is
expected to be used in 99% of the CO packets.
Open issue: Should the IR-REPLICATE packet allow the TTL field to be
replicated?
Open issue: The TTL field will often take one of a small set of well-
known values (e.g. 32 and 64) corresponding to the default values of
common IP stacks. Is it worth providing special handling for these
values in the IR packet?
Price et al. [Page 5]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
3.1.11. IP Protocol
The value of the IP Protocol field can be derived from the type of
header that follows in the extension header chain. Consequently, it
does not need to be transmitted in the compressed packets.
Note: We propose a more complex encoding for the extension header
chain and the TCP options than used in [RFC-3095]. See Section 3.4
for further details.
3.1.12. IP Checksum
The IP Checksum can be reconstructed at the decompressor, and thus
does not need to be transmitted in the compressed packets.
3.1.13. IP Source and Destination Addresses
The IP Source and Destination Addresses are part of the definition of
a flow. Consequently they are transmitted in full in the IR packets,
but are assumed to be "static" in the IR-DYN and the CO packets.
3.2. IPv6
The only field in the IPv6 header that does not have an equivalent in
the IPv4 header is the Flow Label, which is expected to remain
constant for the duration of a flow. Consequently, the proposed set
of CO packets for IPv4 is also capable of encoding the information
contained in an IPv6 header.
Note however that a number of fields in the IPv4 header (IP-ID, DF
flag etc.) have no direct equivalents in the IPv6 header, and so a
number of the CO packets are redundant when compressing IPv6.
Open issue: Is it worth having a separate (simpler) set of packet
formats to handle IPv6?
3.3. TCP
This section discusses the fields contained in a basic TCP header.
The TCP options are covered separately in Section 3.4.
3.3.1. TCP Source and Destination Ports
The TCP Source and Destination Ports are part of the definition of a
flow. Consequently they are transmitted in full in the IR packets,
but are assumed to be "static" in the IR-DYN and the CO packets.
Price et al. [Page 6]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
3.3.2. TCP Sequence Number and Acknowledgement Number
The behavior of the TCP Sequence Number and Acknowledgement Number
are closely related, so from a compression point-of-view it is useful
to consider these fields together.
The proposed set of packet formats currently handles six distinct
behaviors patterns for the Sequence and Ack Numbers, listed below:
Behavior: Seq Number Encoding: Ack Number Encoding: Likelihood:
0 static static 48%
1 lsb(11,256) lsb(11,256) 20%
2 static lsb(14,4096) 15%
3 lsb(14,4096) static 15%
4 static lsb(18,65536) 1%
5 lsb(18,65536) static 1%
In the IR(-DYN) packets, both fields are currently transmitted in
full.
Open issue: The Sequence and Ack Numbers exhibit more structured
behavior than is currently taken into account in the packet formats.
For example, in a bulk data transfer the Sequence and Ack Numbers
will often increase by a fixed value for each successive packet
(barring retransmissions). Is it worth offering a more complex
encoding of the Sequence and Ack Numbers to take this behavior into
account?
3.3.3. TCP Data Offset
The TCP Data Offset is a 4-bit field that can be used to determine
the end of the TCP options and the beginning of the payload data.
Since we explicitly encode the list of options that are included in
the TCP header, the Data Offset field can be inferred from this
information and does not need to be transmitted in the compressed
header.
See Section 3.4 for a discussion on how to compress the TCP options.
3.3.4. TCP Reserved Bits
In current TCP stacks the TCP Reserved Bits are always set to 0.
However, in future TCP stacks a use for the Reserved Bits may be
found (and hence one or more of the bits may take a non-zero value).
For the proposed set of packet formats, we compromise by encoding the
Reserved Bits as "static" in the CO packets, but sending them in full
in the IR(-DYN) packets.
Price et al. [Page 7]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
Open issue: How much future proofing is needed for the TCP Reserved
Bits? Is it worth allowing them to be set to non-zero values?
Open issue: An example of a proposed use for the TCP Reserved Bits is
to provide a Nonce Sum (NS) of the ECT codepoints in the IP header.
If the NS bit is used then it is expected to change randomly in
successive packets, which can currently only be handled by sending
IR(-DYN) packets. Should we handle this behavior more efficiently by
providing extra CO packet formats?
3.3.5. TCP ECN Flags
The ECN flags from the IP and TCP headers have related behavior, so
for maximum efficiency it is proposed to compress them together.
The overall behavior of the ECN flags is expected to fall into one of
two categories, depending on whether the TCP/IP stack has adopted the
ECN mechanism or not. If ECN is not used then all of the flags will
be set to zero and do not need to be sent in the compressed packets.
When Explicit Congestion Notification is used then, for simplicity,
the proposed set of packet formats simply transmits the four ECN
flags in full.
When generating the discriminator bits, the ECN flags are expected to
be unused in 99% of the CO packets.
Open issue: The choice of whether or not to use ECN is likely to
remain constant for the duration of a flow, so better efficiency can
be obtained by offering two distinct sets of packet formats (one
designed to handle the case where ECN is used and the other for
handling the case where it is not). Is this efficiency gain worth
the extra complexity of having multiple sets of packet formats?
Open issue: Even when a stack employs ECN, the behavior displayed by
the four ECN flags is clearly non-random. Is there any value in
exploiting this additional redundancy to improve the overall
compression ratio?
3.3.6. TCP URG Flag
The TCP URG Flag is currently compressed together with the TCP Urgent
Pointer, as described in Section 3.3.12.
3.3.7. TCP ACK Flag
The TCP ACK Flag is known to be set to 1 in all packets except for
the initial SYN. Consequently, it is encoded as "value(1,1)" in the
CO packets, but is transmitted in full in the IR(-DYN) packets.
Price et al. [Page 8]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
3.3.8. TCP PSH Flag
The behavior of the TCP PSH Flag is heavily dependent on the
implementation of the TCP stack (for a given flow the PSH Flag may be
biased towards 0, biased towards 1, or may randomly change between
the two values). Consequently, it is proposed to carry the PSH Flag
explicitly in all compressed packets.
Open issue: Is there any value in attempting to compress the PSH
Flag?
3.3.9. TCP RST, SYN and FIN Flags
The RST, SYN and FIN flags have related behaviour, so it is proposed
to compress them together as a single field.
The CO packets can currently handle three behavior patterns for the
RST, SYN and FIN flags, which are illustrated below:
Behavior: RST Flag: SYN Flag: FIN Flag: Likelihood:
0 0 0 0 90%
1 1 0 0 5%
2 0 0 1 5%
In the IR(-DYN) packets the flags are sent in full (in particular,
this allows us to handle the initial SYN and SYN-ACK packets where
the SYN Flag is set to 1).
3.3.10. TCP Window
The TCP Window is expected to either remain constant between
successive packets, or to oscillate between 0 and the receiver's
window limit for the connection. Consequently, in the CO packets the
TCP Window can be encoded as "static" or as "lsb(15,4096)".
Note: We initially proposed to encode the TCP Window using 13 LSBs,
but increased this when we discovered that two spare bits were
available in the corresponding packet format. In future versions of
the packet formats, these extra bits may be put to a different use.
When calculating the discriminator bits, the TCP Window is expected
to remain constant for 70% of the packets in a flow.
In the IR(-DYN) packets the TCP Window is sent in full.
Open issue: We currently assume that the TCP Window remains constant
more often than not. Is this assumption reasonable?
Price et al. [Page 9]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
3.3.11. TCP Checksum
In order to avoid breaking end-to-end error protection, the TCP
Checksum is carried in full in all compressed packets.
3.3.12. TCP Urgent Pointer
The URG Flag and the Urgent Pointer have related behavior, so we
propose to compress them together.
If the URG Flag is set to 0 then the Urgent Pointer is ignored by the
receiving endpoint, and can be set to an arbitrary value. However,
in the current CO packets it is assumed that the Urgent Pointer is
encoded as "static" (i.e. it remains constant relative to the
previous header).
Open issue: It is assumed that if the URG Flag is zero then the
Urgent Pointer will remain constant between successive headers. Are
there any TCP stacks for which this assumption is false? For
example, could the Urgent Pointer be reset to 0 after the urgent
data?
In the IR(-DYN) packets, both the URG Flag and the Urgent Pointer are
carried in full.
Note that if the URG Flag is set to 1 then an IR(-DYN) packet must be
sent, as there are currently no CO packets that can carry an URG Flag
of 1.
Open issue: Will the URG Flag be set often enough to warrant its own
packet format (currently we assume that the answer is "no")?
3.4. TCP Options
From a compression perspective, perhaps the most difficult part of
the TCP/IP header is the list of TCP options. The list of options
often displays complex behavior, which is difficult to compress using
the techniques previously applied to RTP, UDP and IP headers.
One problem with the list of TCP options is that, unlike e.g. the IP
extension header chain, we typically get quite a large number of TCP
options in a given packet - and moreover, the precise set of options
will often be different for the initial SYN packet than for the main
body of the flow. Using the insert/remove scheme from [RFC-3095], a
minimum of 2-3 bytes must be sent to re-establish the options list
whenever it changes (even when context replication is used to
preserve the indices assigned to each list item).
Our alternative proposal for handling this is to determine the set of
possible TCP options in advance, and then to only transmit a set of
flags indicating which of the options are present in the uncompressed
Price et al. [Page 10]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
packet, and the order in which they occur. Together with any
compressed data needed by the individual options, this is enough
information for the complete list of options to be reconstructed at
the decompressor.
In the proposed IR packet it currently costs 1 byte to send the flags
indicating whether or not each option is present in the header, and 3
bytes to send the flags indicating the order in which the options
occur. However, it is expected that the order of the TCP options
will not change for a particular TCP stack, so this 3-byte field can
be replicated between different flows.
It is therefore expected that only the 1-byte presence flags will
need to be sent to initialize the TCP options in a new flow.
Open issue: It may be possible to further improve the compression
ratio of the TCP options by providing special handling for the SYN
packets (e.g. by storing the list of options separately for the SYN
packets than for the rest of the flow). Is it worth the extra effort
to save an additional byte in the first few packets of the flow?
Open issue: Is it worth including flags in the CO packets, to handle
options that appear and disappear within the same flow (e.g. SACK)?
The following sections discuss how each of the individual TCP options
is compressed.
3.4.1. End of Option List
The End of Option List option consists of a 1-byte "Kind" field that
takes the value 0. Consequently, it can be encoded as "value(8,0)",
and no bits need to be sent in the compressed header.
3.4.2. No Operation
The No Operation option consists of a 1-byte "Kind" field that takes
the value 1. Consequently, it can be encoded as "value(8,1)", and no
bits need to be sent in the compressed header.
3.4.3. SACK
The TCP SACK option consists of a 1-byte Kind field and a 1-byte
Length field, followed by one or more 8-byte SACK block structures
each acknowledging a block of data.
The current set of packet formats does not attempt particularly
aggressive compression of the SACK option. The Kind field is encoded
as "value(8,5)", and hence does not need to be sent in the compressed
header - however the SACK blocks themselves are always sent
uncompressed.
Price et al. [Page 11]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
Open issue: Will the SACK option occur often enough to warrant more
aggressive compression than just sending the SACK blocks
uncompressed?
3.4.4. Timestamp
The TCP Timestamp option consists of a 1-byte Kind field and a 1-byte
Length field, followed by a 4-byte Timestamp Value (TSval) field and
a 4-byte Timestamp Echo Reply (TSecr) field.
In the CO packets, the two timestamp fields are currently compressed
using self-describing variable-length values encoding (see Section
4.5.6 of [RFC-3095]). In the IR(-DYN) packets the fields are sent in
full.
Open issue: Is it possible to get more aggressive compression of the
timestamp fields, e.g. by using some form of scaled timestamp
encoding?
Open issue: Is it worth linking the compression of the Timestamp
option to the value carried in the ACK Flag? When the ACK Flag is
zero, the TSecr field is not valid and therefore must be set to 0
(potentially saving 4 bytes in the compressed header).
3.4.5. Maximum Segment Size
TBD - currently we encode this as a generic TCP option, but in future
it is proposed to handle the MSS via specialized packet formats.
3.4.6. Window Scale
TBD - currently we encode this as a generic TCP option, but in future
it is proposed to handle the WSopt via specialized packet formats.
3.4.7. SACK Permitted
TBD - currently we encode this as a generic TCP option, but in future
it is proposed to have special handling for the SACK Permitted option
(note that no additional packet formats will be required, as the
option can always be compressed down to 0 bits).
3.4.8. Generic TCP Options
Any TCP option that is not handled explicitly by the packet formats
can be encoded as a "genetic TCP option". In this case, the Kind and
Length fields are transmitted in full in the IR(-DYN) packets so that
the decompressor can store the Kind and Length of the new option. In
the CO packets the Kind and Length are assumed to be "static"
relative to the context.
Price et al. [Page 12]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
If present, any remaining fields in a generic TCP option are always
transmitted in full.
Open issue: Are there any TCP options currently encoded as generic
options, but which would benefit from specialized packet formats?
Open issue: Are there any generic TCP options that would benefit from
a more aggressive encoding of the option data? For example, are
there any cases where the option data remains static between
successive headers?
3.5. IP Extension Headers
TBD.
Open issue: Are there any IP extension headers that need to be
encoded differently for TCP/IP than for UDP/IP? Are there any
improvements that would be worth making relative to the encodings
used in [RFC-3095]?
3.6. Control fields
This section discusses the control fields that must be transmitted in
the compressed TCP/IP packet formats. Note that a control field
contains information that is not present in the original uncompressed
header, but which may be useful for the decompressor (examples
include a CRC to verify that the header has been successfully
decompressed).
3.6.1. Master Sequence Number
The Master Sequence Number (MSN) is a control field created by the
compressor. It currently 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.
Currently we send 2 LSBs of the MSN in each CO packet, and send the
16-bit MSN in full in the IR(-DYN) packets.
Open issue: Is it necessary/useful to send the MSN in every CO
packet?
Open issue: Can we encode the MSN more aggressively in the IR(-DYN)
packets by taking into account the fact that it will be biased
towards 0?
Price et al. [Page 13]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
3.6.2. Header CRC
From a robustness perspective, it is useful for the compressed
packets to contain a CRC calculated over the original uncompressed
header. The decompressor can use this CRC to verify that it has
successfully reconstructed the uncompressed header, guarding against
errors in either the compressed packet or the context that may cause
the decompression process to fail.
The current set of packet formats provides a 3-bit header CRC in
every packet (including both the CO packets and the IR(-DYN)
packets).
Open issue: Does a 3-bit CRC provide enough robustness for the
expected link error conditions?
Open issue: Would it be useful to provide additional CRC protection
in the packet formats that contain a large amount of context-updating
information?
3.6.3. Padding
Due to the restrictions imposed by the link layer, it is necessary
for all of the compressed packet formats to be aligned to a whole
number of bytes.
However, in some of the proposed packet formats, a number of spare
bits are left over after encoding all of the information needed by
the decompressor. These bits are currently marked as "padding" - set
to 0 by the compressor and ignored by the decompressor.
Open issue: What should we do with the spare bits in the compressed
header formats? Possible choices include - using the bits to carry
more LSBs of a field such as the MSN, using the bits to carry
additional CRC protection, or reserving the bits for use in future
versions of the profile.
4. Packet formats described using ROHC-FN
The following section describes the proposed set of TCP/IP packet
formats using the Formal Notation for Robust Header Compression
[ROHC-FN]. 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.
tcp_ip_formats ::= ordinary_huffman(tcp_ip_header)
tcp_ip_header ::= create_msn
ip_header
tcp_header
master_seq_number
Price et al. [Page 14]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
header_crc
ip_header ::= inferred_ip_checksum
inferred_size(16,-16)
ip_version
ip_header_length
ip_tos
ip_length
ip_id
ip_reserved
ip_dont_fragment
ip_more_fragments
ip_offset
ip_time_to_live
ip_protocol
ip_checksum
ip_source_address
ip_dest_address
tcp_header ::= tcp_checksum
tcp_source_port
tcp_dest_port
tcp_seq_number
tcp_ack_number
tcp_data_offset
tcp_reserved
tcp_ip_ecn_fields
tcp_urg
tcp_ack_flag
tcp_psh_flag
tcp_rsf_flags
tcp_window
tcp_urg_fields
tcp_options
ip_version ::= value(4,4)
ip_header_length ::= value(4,5)
ip_tos ::= static // irregular(6)
label(2,ecn)
ip_length ::= skip(16)
ip_id ::= inferred_offset(16,msn)
static 90% / lsb(8,0) 10% // irregular(16)
ip_reserved ::= value(1,0)
ip_dont_fragment ::= static 99% / irregular(1) 1%
Price et al. [Page 15]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
ip_more_fragments ::= value(1,0)
ip_offset ::= value(13,0)
ip_time_to_live ::= static 99% / irregular(8) 1%
ip_protocol ::= value(8,6)
ip_checksum ::= skip(16)
ip_source_address ::= static // irregular(32)
ip_dest_address ::= static // irregular(32)
tcp_source_port ::= static // irregular(16)
tcp_dest_port ::= static // irregular(16)
tcp_seq_number ::= (static change(behav,nil,0) 48%) /
(lsb(11,256) change(behav,nil,1)) 20% /
(static change(behav,nil,2)) 15% /
(lsb(14,4096) change(behav,nil,3)) 15% /
(static change(behav,nil,4)) 1% /
(lsb(18,65536) change(behav,nil,5)) 1% //
(irregular(32) change(behav,nil,6))
tcp_ack_number ::= (static change(behav,0,nil)) /
(lsb(11,256) change(behav,1,nil)) /
(lsb(14,4096) change(behav,2,nil)) /
(static change(behav,3,nil)) /
(lsb(18,65536) change(behav,4,nil)) /
(static change(behav,5,nil)) /
(irregular(32) change(behav,6,nil))
tcp_data_offset ::= label(4,data_offset)
tcp_reserved ::= static // irregular(4)
tcp_ip_ecn_fields ::= ecn_unused 99% / ecn_used 1%
ecn_unused ::= next_field(ecn)
value(2,0)
value(2,0)
ecn_used ::= next_field(ecn)
ip_ecn_bits
tcp_ecn_bits
ip_ecn_bits ::= irregular(2)
tcp_ecn_bits ::= irregular(2)
Price et al. [Page 16]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
tcp_urg ::= label(1,urg_flag)
tcp_ack_flag ::= value(1,1) // irregular(1)
tcp_psh_flag ::= irregular(1)
tcp_rsf_flags ::= value(3,0) 90% / value(3,4) 5% /
value(3,1) 5% // irregular(3)
tcp_window ::= static 70% / lsb(15,4096) 30% //
irregular(16)
skip(16)
tcp_checksum ::= map(temp,nil,val(remaining_data))
map(remaining_data,val(temp),val(temp) -
128)
irregular(16)
map(remaining_data,val(temp) -
144,val(temp))
map(temp,val(remaining_data),nil)
tcp_urg_fields ::= next_field(urg_flag)
urgf_zero // urgf_one
urgf_zero ::= value(1,0)
static
urgf_one ::= tcp_urg_flag
tcp_urg_pointer
tcp_urg_flag ::= irregular(1)
tcp_urg_pointer ::= irregular(16)
tcp_options ::= list(data_offset,1,32,-160,
[optional(tcp_sack),
optional(tcp_timestamp),
optional(tcp_end),
optional(tcp_no_operation),
optional(tcp_no_operation),
optional(tcp_generic),
optional(tcp_generic),
optional(tcp_generic)])
tcp_options_order
tcp_options_presence
tcp_options_order ::= next_field(order)
static // irregular(24)
tcp_options_presence ::= next_field(presence)
Price et al. [Page 17]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
static // irregular(8)
tcp_end ::= value(8,0)
tcp_no_operation ::= value(8,1)
tcp_sack ::= tcp_sack_kind
tcp_sack_len
tcp_sack_block
tcp_sack_kind ::= value(8,5)
tcp_sack_len ::= label(8,tcp_sack_length)
tcp_sack_block ::= uncompressible(tcp_sack_length,8,-16)
tcp_sack_length
tcp_sack_length ::= next_field(tcp_sack_length)
static // irregular(8)
tcp_timestamp ::= tcp_ts_kind
tcp_ts_length
tcp_ts_value
tcp_ts_echo_reply
tcp_ts_kind ::= value(8,8)
tcp_ts_length ::= value(8,10)
tcp_ts_value ::= self_describing_values(8,7) //
irregular(32)
tcp_ts_echo_reply ::= self_describing_values(8,7) //
irregular(32)
tcp_generic ::= tcp_generic_kind
tcp_generic_len
tcp_generic_option
tcp_generic_kind ::= static // irregular(8)
tcp_generic_len ::= label(8,tcp_generic_length)
tcp_generic_option ::= uncompressible(tcp_generic_length,8,-16)
tcp_generic_length
tcp_generic_length ::= next_field(tcp_generic_length)
static // irregular(8)
master_seq_number ::= next_field(msn)
lsb(2,0) // irregular(16)
Price et al. [Page 18]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
header_crc ::= map(current_field,nil,0)
irregular(3)
5. Security considerations
This draft describes a set of packet formats for ROHC-TCP [ROHC-TCP].
Consequently the security considerations for this draft match those
of ROHC-TCP.
6. Authors' addresses
Richard Price Tel: +44 1794 833681
Email: richard.price@roke.co.uk
Mark A West Tel: +44 1794 833311
Email: mark.a.west@roke.co.uk
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
7. References
7.1. Normative references
[ROHC-FN] "Formal Notation for Robust Header Compression
(ROHC-FN)", R. Price et al., <draft-ietf-rohc-formal-
notation-01.txt> (work in progress), March 2003
[RFC-2026] "The Internet Standards Process - Revision 3", S.
Bradner, Internet Engineering Task Force, October 1996
[RFC-2119] "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner, Internet Engineering Task Force,
March 1997
7.2. Informative references
[ROHC-TCP] "RObust Header Compression (ROHC): TCP/IP Profile (ROHC-
TCP)", G. Pelletier et al., <draft-ietf-rohc-tcp-04.txt>
(work in progress), May 2003
[TCP-BEH] "TCP/IP Field Behavior", M. West and S. McCann,
<draft-ietf-rohc-tcp-field-behavior-02.txt> (work in
progress), March 2003
[TCP-REQ] "Requirements on ROHC IP/TCP header compression", L-E.
Jonsson, <draft-ietf-rohc-tcp-requirements-05.txt> (work
in progress), October 2002.
Price et al. [Page 19]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
[RFC-3095] "RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", C. Bormann et
al., Internet Engineering Task Force, July 2001.
Appendix A: Packet formats described using box notation
This appendix provides an informative description of the fields in
each compressed packet, using the traditional RFC "box notation".
Note that the appendix does not provide the mapping between the
uncompressed and compressed versions of each field (this can be found
in Section 4).
Key:
"|" indicates the beginning/end of a field.
":" indicates that a field is split over multiple octets.
Abbreviations:
A = TCP_ACK_FLAG
MSN = MASTER_SEQ_NUMBER
I = IP_DONT_FRAGMENT
TEB = TCP_ECN_BITS
M = MASTER_SEQ_NUMBER
TRF = TCP_RSF_FLAGS
P = PADDING
U = TCP_URG_FLAG
T = TCP_PSH_FLAG
HC = HEADER_CRC
IEB = IP_ECN_BITS
Packet 0:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 0 | HC | MSN | T |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
Packet 1:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 1 0 | HC | MSN |
+---+---+---+---+---+---+---+---+
| TCP_WINDOW :
+---+---+---+---+---+---+---+---+
Price et al. [Page 20]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
+---+---+---+---+---+---+---+---+
: | T |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
Packet 2:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 1 1 | HC | MSN |
+---+---+---+---+---+---+---+---+
| T | TCP_ACK_NUMBER :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_SEQ_NUMBER | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | P |
+---+---+---+---+---+---+---+---+
Packet 3:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 0 0 | HC | M :
+---+---+---+---+---+---+---+---+
: | T | :
+---+---+---+---+---+---+---+---+
: TCP_SEQ_NUMBER |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
Packet 4:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 0 1 | HC | M :
+---+---+---+---+---+---+---+---+
: | T | :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER |
+---+---+---+---+---+---+---+---+
Price et al. [Page 21]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
Packet 5:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 1 0 0 | HC |
+---+---+---+---+---+---+---+---+
| MSN | :
+---+---+---+---+---+---+---+---+
: TCP_WINDOW :
+---+---+---+---+---+---+---+---+
: | T | TCP_ACK_NUMBER :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_SEQ_NUMBER |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
Packet 6:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 1 0 1 | HC |
+---+---+---+---+---+---+---+---+
| MSN | :
+---+---+---+---+---+---+---+---+
: TCP_WINDOW :
+---+---+---+---+---+---+---+---+
: | T | :
+---+---+---+---+---+---+---+---+
: TCP_SEQ_NUMBER |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
Price et al. [Page 22]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
Packet 7:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 1 1 0 | HC |
+---+---+---+---+---+---+---+---+
| MSN | :
+---+---+---+---+---+---+---+---+
: TCP_WINDOW :
+---+---+---+---+---+---+---+---+
: | T | :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
Packet 8:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 1 1 1 | HC |
+---+---+---+---+---+---+---+---+
| MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | IP_ID :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Packet 9:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 0 0 0 | HC :
+---+---+---+---+---+---+---+---+
: | MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Price et al. [Page 23]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
Packet 10:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 0 0 1 | HC :
+---+---+---+---+---+---+---+---+
: | MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Packet 11:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 0 1 0 | HC :
+---+---+---+---+---+---+---+---+
: | MSN | :
+---+---+---+---+---+---+---+---+
: TCP_WINDOW :
+---+---+---+---+---+---+---+---+
: | T | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | IP_ID :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Packet 12:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 0 1 1 | HC :
+---+---+---+---+---+---+---+---+
: | MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER | :
+---+---+---+---+---+---+---+---+
: TCP_SEQ_NUMBER :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | IP_ID :
+---+---+---+---+---+---+---+---+
Price et al. [Page 24]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Packet 13:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 1 0 0 0 | :
+---+---+---+---+---+---+---+---+
: HC | MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_SEQ_NUMBER :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | IP_ID :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Packet 14:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 1 0 0 1 | :
+---+---+---+---+---+---+---+---+
: HC | MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | IP_ID :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Packet 15:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 1 0 1 0 | :
+---+---+---+---+---+---+---+---+
: HC | MSN | :
+---+---+---+---+---+---+---+---+
Price et al. [Page 25]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
+---+---+---+---+---+---+---+---+
: TCP_WINDOW :
+---+---+---+---+---+---+---+---+
: | T | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Packet 16:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 1 0 1 1 | :
+---+---+---+---+---+---+---+---+
: HC | MSN | :
+---+---+---+---+---+---+---+---+
: TCP_WINDOW :
+---+---+---+---+---+---+---+---+
: | T | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Packet 17:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 1 1 0 0 | :
+---+---+---+---+---+---+---+---+
: HC | MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER |
+---+---+---+---+---+---+---+---+
| TCP_SEQ_NUMBER :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Price et al. [Page 26]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
Packet 18:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 1 1 0 1 | :
+---+---+---+---+---+---+---+---+
: HC | MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER |
+---+---+---+---+---+---+---+---+
| TCP_SEQ_NUMBER :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
Packet 19:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 1 1 1 0 | :
+---+---+---+---+---+---+---+---+
: HC | MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_SEQ_NUMBER :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | P |
+---+---+---+---+---+---+---+---+
Packet 20:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 1 1 1 1 0 |
+---+---+---+---+---+---+---+---+
| HC | MSN | T | :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER :
+---+---+---+---+---+---+---+---+
: ... |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
Price et al. [Page 27]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
Packet 21:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 1 1 1 1 1 |
+---+---+---+---+---+---+---+---+
| HC | MSN | :
+---+---+---+---+---+---+---+---+
: TCP_WINDOW :
+---+---+---+---+---+---+---+---+
: | T | :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER |
+---+---+---+---+---+---+---+---+
| TCP_SEQ_NUMBER :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM :
+---+---+---+---+---+---+---+---+
: | IP_ID :
+---+---+---+---+---+---+---+---+
: | PADDING |
+---+---+---+---+---+---+---+---+
IR-DYN Packet:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 | 0 |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: MASTER_SEQ_NUMBER |
+---+---+---+---+---+---+---+---+
| TCP_OPTIONS_PRESENCE |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_OPTIONS_ORDER :
+---+---+---+---+---+---+---+---+
: ... |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_URG_POINTER |
+---+---+---+---+---+---+---+---+
Price et al. [Page 28]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
+---+---+---+---+---+---+---+---+
| U | :
+---+---+---+---+---+---+---+---+
: TCP_WINDOW :
+---+---+---+---+---+---+---+---+
: | TRF | T | A | HC :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: IP_ID :
+---+---+---+---+---+---+---+---+
: | IP_TOS | I |
+---+---+---+---+---+---+---+---+
| TEB | IEB | TCP_RESERVED |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER :
+---+---+---+---+---+---+---+---+
: ... :
+---+---+---+---+---+---+---+---+
: ... |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_SEQ_NUMBER :
+---+---+---+---+---+---+---+---+
: ... :
+---+---+---+---+---+---+---+---+
: ... |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
| IP_TIME_TO_LIVE |
+---+---+---+---+---+---+---+---+
IR Packet:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | :
+---+---+---+---+---+---+---+---+
: HC | :
+---+---+---+---+---+---+---+---+
: MASTER_SEQ_NUMBER :
+---+---+---+---+---+---+---+---+
: | TCP_OPTIONS_PRESENCE :
+---+---+---+---+---+---+---+---+
Price et al. [Page 29]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_OPTIONS_ORDER :
+---+---+---+---+---+---+---+---+
: ... :
+---+---+---+---+---+---+---+---+
: | :
+---+---+---+---+---+---+---+---+
: TCP_URG_POINTER :
+---+---+---+---+---+---+---+---+
: | U | :
+---+---+---+---+---+---+---+---+
: TCP_WINDOW :
+---+---+---+---+---+---+---+---+
: | TRF | T | A |
+---+---+---+---+---+---+---+---+
| TEB | IEB | TCP_RESERVED |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_ACK_NUMBER :
+---+---+---+---+---+---+---+---+
: ... :
+---+---+---+---+---+---+---+---+
: ... |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_SEQ_NUMBER :
+---+---+---+---+---+---+---+---+
: ... :
+---+---+---+---+---+---+---+---+
: ... |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_DEST_PORT |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_SOURCE_PORT |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: TCP_CHECKSUM |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: IP_DEST_ADDRESS :
+---+---+---+---+---+---+---+---+
Price et al. [Page 30]
INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003
+---+---+---+---+---+---+---+---+
: ... :
+---+---+---+---+---+---+---+---+
: ... |
+---+---+---+---+---+---+---+---+
| :
+---+---+---+---+---+---+---+---+
: IP_SOURCE_ADDRESS :
+---+---+---+---+---+---+---+---+
: ... :
+---+---+---+---+---+---+---+---+
: ... |
+---+---+---+---+---+---+---+---+
| IP_TIME_TO_LIVE |
+---+---+---+---+---+---+---+---+
| I | :
+---+---+---+---+---+---+---+---+
: IP_ID :
+---+---+---+---+---+---+---+---+
: | IP_TOS | P |
+---+---+---+---+---+---+---+---+
Price et al. [Page 31]