Network Working Group A. Ayadi
Internet-Draft D. Ros
Intended status: Informational L. Toutain
Expires: January 7, 2011 Telecom Bretagne
July 6, 2010
TCP header compression for 6LoWPAN
draft-aayadi-6lowpan-tcphc-00
Abstract
This document describes LOWPAN_TCPHC, a scheme for compressing the
header of Transmission Control Protocol (TCP) segments, in order to
reduce the overhead on low-power and lossy networks. It also
specifies the LOWPAN_TCPHC header fields for the transmission of TCP
segments over IPv6 for Low-power Wireless Personal Area Networks
(6LoWPAN). In many cases, the 20 octets of the mandatory TCP header
can be compressed into as little as 6 octets.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Ayadi, et al. Expires January 7, 2011 [Page 1]
Internet-Draft TCP header compression for 6LoWPAN July 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Ayadi, et al. Expires January 7, 2011 [Page 2]
Internet-Draft TCP header compression for 6LoWPAN July 2010
1. Introduction
The 6LoWPAN Working Group [RFC4919] has proposed LOWPAN_IPHC
[I-D.ietf-6lowpan-hc], a new version of the LOWPAN_HC1 header
compression mechanism [RFC4944] which reduces the IPv6 header to
about 3-5 octets. In [I-D.ietf-6lowpan-hc], a header-compression
method for the transport layer (LOWPAN_NHC) has also been introduced,
however, only an UDP [RFC0768] datagram compression mechanism is
specified.
UDP header compression is useful for 6LoWPAN because many Low-power
and Lossy Network (LLN) applications are fault-tolerant and do not
require 100% reliability. However, other applications and services
such as SSH and HTTP require a reliable service from the transport
layer that cannot be offered by UDP. Moreover, some usage scenarios
of LLNs, such as health, military and security applications, impose
strong reliability constraints. Also, in some usage cases (e.g.,
sending a software update to a wireless node, or sending a query
requesting a specific information from the wireless node) there is a
need for a reliable data transport.
In this document, we focus on the Transmission Control Protocol (TCP)
[RFC0793], which carries most of the traffic in IP networks. TCP is
a connection-oriented, end-to-end reliable transport protocol. To
ensure end-to-end reliability, TCP must recover from packet
corruption, loss or out-of-order delivery. This is achieved by
assigning a sequence number to each transmitted octet (done by the
TCP source), by requiring a positive acknowledgment (ACK) from the
TCP destination, and by retransmitting lost or corrupted packets.
In the context of 6LoWPAN networks, the size of TCP headers may
induce a large overhead, especially for link-layer technologies that
use small frames. For instance, a pure TCP acknowledgment (i.e., a
TCP ACK carrying no data) without any TCP options represents 25% of
the payload of an IEEE 802.15.4 MAC frame. In addition, TCP pure
ACKs represent roughly 33% of the total number of segments exchanged
in a TCP session (this figure may go up to roughly 50% if the Delayed
ACK mechanism [RFC1122] is not used). This suggests that the use of
header-compression mechanisms for TCP may result in important
performance gains, in terms of used bandwidth and/or energy spent for
frame transmission.
The goal of this document is thus to define a TCP header compression
scheme for 6LoWPAN, called LOWPAN_TCPHC, which allows to
significantly reduce the TCP overhead. The TCP header compression is
performed in the edge router between the 6LoWPAN and the external IP
network, but it can also be used between two 6LoWPAN nodes for
machine-to-machine communications. This document defines also an
Ayadi, et al. Expires January 7, 2011 [Page 3]
Internet-Draft TCP header compression for 6LoWPAN July 2010
encoding format for LOWPAN_TCPHC header compression. Such mechanism
and packet format aims at making TCP a viable proposition for 6LoWPAN
networks. Moreover, the LOWPAN_TCPHC mechanism can be used with
LOWPAN_IPHC [I-D.ietf-6lowpan-hc] and thus reduce all overheads to
about seven to ten octets instead of 60 octets.
A TCP header compression algorithm for 6LoWPAN should respect some
requirements: (a) Efficiency (the scheme must provide low overhead in
all cases), (b) Transparency (the resulting header after a
compression and decompression should be identical to the original
header), (c) Reordering tolerance (the scheme must be able to
decompress compressed segments correctly even when segments arrive
with a moderate reordering).
The proposed scheme does not compress TCP control messages at the
connection establishment phase. Those TCP segments are used to
exchange a context identifier. Such context identifier replaces the
port numbers in the following TCP segments, as a means of identifying
a given TCP session. Some TCP options, such as Timestamp [RFC2018]
and SACK [RFC1323] [RFC2883], are supported (i.e., compressed) by the
mechanism, while other options, unlikely to be required / used in
6LoWPANs, are omitted.
1.1. Related Work
This section presents prior work on TCP/IP header compression. In
particular, we will briefly decribe three existing TCP header
compression algorithms. A more detailed discussion of these
algorithms can be found in [RFC4996].
One of the first TCP/IP header compression methods was Compressed TCP
(CTCP), proposed by Jacobson [RFC1144]. Jacobson's header
compression algorithm distinguishes between dynamic fields and static
fields. The static fields (e.g., source address, source port, ...)
are sent in two situations: when initiating a connection, and when
refreshing the context after a loss of synchronization. CTCP
proposes to send the difference between the actual value of a dynamic
field (e.g., sequence number, acknowledgment number, ...) and its
previous value. When the synchronization is lost between the
compressor and the decompressor, the TCP sender sends a segment with
a regular header to refresh the context. Experimental studies
[Perkins et al.] [Srivastava et al.] [Wang04] have shown that the
performance of Jacobson's algorithm may degrade significantly in
noisy / lossy network environments. An important disadvantage of
CTCP is that it does not support TCP options, some of which are
ubiquituous nowadays [Medina05].
IPHC [RFC2507] enhances Jacobson's TCP header compression by
Ayadi, et al. Expires January 7, 2011 [Page 4]
Internet-Draft TCP header compression for 6LoWPAN July 2010
introducing a mechanism, called TWICE, to repair incorrectly-
decompressed headers. TWICE is most efficient when applied to data-
carrying TCP segments. [RFC2507] also describes a mechanism for
explicitly requesting the transmission of less-compressed or
uncompressed headers; such mechanism is especially suited for pure
TCP acknowledgements. Note however that IPHC does not actually
provide a compression method for TCP options; changing option fields
are carried in compressed headers, but without any compression.
Also, the header request mechanism may be unsuited for lossy 6LoWPAN
networks, which low bit rates and strong energy constraints are at
odds with any additional signalling overhead. Note that neither CTCP
nor IPHC support the compression of SYN (i.e., connection-opening)
and FIN (i.e., connection-closing) segments.
ROHC-TCP [RFC4996] improves on [RFC2507] by providing a new method
for compressing all TCP header fields, including the TCP options.
ROHC-TCP proposes also to start compressing packets starting from the
SYN segments, using parameters from previous or simultaneous
connections. This may offer noticeable improvements in performance
when most TCP flows are short-lived, i.e., composed of a small number
of data segments. Nevertheless, the ROHC-TCP algorithm is fairly
complex and its memory requirements may not be met by small,
constrained devices.
The algorithm described in this document, LOWPAN_TCPHC, supports
features like the compression of TCP options and FIN segments, and at
the same time it is relatively simple and easy to implement in
memory- and CPU-constrained devices.
1.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 section defines general terms related to TCP/IPv6 header
compression [RFC2507] [RFC4995] and to the 6LoWPAN architecture
[RFC4919] used in this specification.
o Subheader: An IPv6 header, a UDP header, or a TCP header.
o Header: A chain of subheaders.
o Compression: The act of reducing the size of a header by either
removing header fields or reducing the size of header fields.
This is done in a way such that a decompressor can reconstruct the
header if its context state is identical to the context state used
when compressing the header.
Ayadi, et al. Expires January 7, 2011 [Page 5]
Internet-Draft TCP header compression for 6LoWPAN July 2010
o Decompression: The act of reconstructing a compressed header.
o Static fields: These fields are expected to be constant throughout
the lifetime of the packet stream. Static information must be
communicated once in some way.
o Dynamic fields: These fields are expected to vary between
different TCP segments, either randomly within a limited range or
in some other manner.
o Context identifier (CID): A small unique number identifying the
context that should be used to decompress a compressed header.
Carried in full headers, mostly compressed headers and compressed
headers.
o Context: The state used by the compressor to compress a header,
and by the decompressor to decompress a header. The context is
given by the uncompressed version of the last header sent
(compressor) or received (decompressor) over the link, except for
fields in the header that are included "as-is" in compressed
headers, or that can be inferred from e.g. the size of the link-
layer frame.
o Full header: An uncompressed header that updates or refreshes the
context for a packet stream. It carries a CID that will be used
to identify the context.
o Regular header: A normal, uncompressed header. It does not carry
any CID or generation association.
o Compressed header: A header in which all the static fields are
elided, and all the dynamic fields are sent compressed.
o Mostly compressed header: A header in which all the static fields
are elided, and all the dynamic fields are sent without
compression
o Incorrect decompression: When a decompressed header does not match
the corresponding original, uncompressed header. Usually due to
mismatching contexts between the compressor and decompressor,
caused by e.g. bit errors during the transmission of the
compressed header, or by packet loss.
o IEEE 802.15.4: A low-power, low-bandwidth link layer protocol,
over which ZigBee was originally intended to run.
o LoWPAN host: A node that only sources or sinks IPv6 datagrams.
Referred to as a Host in this document.
Ayadi, et al. Expires January 7, 2011 [Page 6]
Internet-Draft TCP header compression for 6LoWPAN July 2010
o LoWPAN router: A node that forwards datagrams between arbitrary
source-destination pairs using a single 6LoWPAN interface,
performing IP routing on that interface.
o LoWPAN edge router (ER): An IPv6 router that interconnects the
6LoWPAN to another IP network. Referred to as an Edge Router in
this document.
o LoWPAN node: A node that composes a 6LoWPAN, referring to both
hosts and routers. Simply called a Node in this document.
Ayadi, et al. Expires January 7, 2011 [Page 7]
Internet-Draft TCP header compression for 6LoWPAN July 2010
2. Protocol Overview
This section gives an overview of the TCP header compression
mechanism for 6LoWPAN (LOWPAN_TCPHC). The main purpose of
LOWPAN_TCPHC is to reduce the protocol header overhead, with the
intent of reducing both bandwidth usage and energy consumption due to
packet transmissions. Moreover, the LOWPAN_TCPHC allows establishing
TCP connections between an external IP host and a LoWPAN host, and
also between two LoWPAN hosts. This first type of connection is
performed by an Edge Router (ER) which links the 6LoWPAN to an
external IPv6-based network. Figure 1 shows a typical 6LoWPAN
topology.
| * *
| * * *
| +--------+ * * * * *
|____| Edge | * * * * *
| | Router | * * * *
| +--------+ * * * *
| * * *
External IP Network -- | * * *
| * * *
| +--------+ * * * *
|____| Edge | * * * * *
| | Router | * * * * *
| +--------+ * * * * *
| * * *
| * * *
*: LoWPAN Node
Figure 1: A 6LoWPAN network
The compression and decompression mechanisms are implemented on the
edge router and on the LoWPAN nodes. The ER maintains the contexts
for incoming and outgoing connections between the 6LoWPAN and the
external network. Figure 2 and Figure 3 show sequence diagrams of a
connection establishment between a LoWPAN host and an external IP
host. The external IP host sends and receives regular TCP segments,
whereas the LoWPAN host sends and receives segments with compressed
headers, mostly compressed headers or full headers.
The LOWPAN_TCPHC algorithm does not compress TCP control messages at
the connection establishment phase. The TCP control segments are
used to exchange the context identifier (CID). Supported TCP options
that are negotiated in the two first messages are sent in a full-
header format. The LOWPAN_TCPHC algorithm defines a compression
mechanism for TCP SACK and Timestamp options.
Ayadi, et al. Expires January 7, 2011 [Page 8]
Internet-Draft TCP header compression for 6LoWPAN July 2010
The TCP connection may also be established between two LoWPAN hosts
for Machine-to-Machine communications. In this case, the context
should be shared between the two LoWPAN hosts. If a lost or
corrupted packet is detected, then the mechanism refreshes the
context by retransmitting lost segments using a mostly compressed
header.
The compression protocol uses three different header formats. For
the TCP opening phase and for error management, TCP segments SHOULD
be sent with a full header. These segments contain the Context
Identifier (CID) which will be used to identify the connection during
the transfer phase. The CID replaces the two port numbers, hence
avoiding to send the port numbers in every packet. The CID value and
its size are set by the ER if the TCP connection is between a LoWPAN
host and an external IP host, otherwise they are set by a LoWPAN
host. The CID pairs SHOULD be unique for a destination inside the
6LoWPAN network.
The CID SHOULD be set by the ER to ensure uniqueness. This field is
added by the edge router in the ACK segment when an external IP host
initiates the TCP connection. The CID MUST be sent in the ACK
segment to make sure that the LoWPAN node is aware of the CID of the
new connection. For in-6LoWPAN TCP communications, the CID that is
finally used should be the one set in the third ACK segment of the
three-way handshake.
The second kind of header is the compressed header in which all
static fields are elided, and all dynamic fields are compressed.
Depending on how they change with respect to the last sent segment,
dynamic fields may be compressed fully (i.e., elided) or partially
(i.e., only a portion of a field is sent, containing the bytes that
have changed).
The last kind of packet is sent when a packet loss, corruption or
reordering is detected by the TCP receiver. This segment is called
mostly compressed header and contains dynamic fields with all octets
uncompressed, while its static fields are elided. This kind of
segment should be sent after a loss of synchronization between the
compressor and the decompressor.
2.1. Connection Initiation
This section gives an overview of TCP connection initiation with
LOWPAN_TCPHC.
Ayadi, et al. Expires January 7, 2011 [Page 9]
Internet-Draft TCP header compression for 6LoWPAN July 2010
External IP Host Edge Router LoWPAN Host
| | |
| --- SYN --> | --- SYN with CID=0--> |
| <-- SYN/ACK --- | <-- SYN/ACK with CID=max --- |
| --- ACK --> | --- ACK with CID -->|
| | |
Figure 2: TCP/IPv6 Connection initiated by an external IP-host
Figure 2 shows an example of a connection initiation scenario started
by an external IP host. In this scenario, an external host sends a
SYN segment trying to establish a connection with a LoWPAN host. The
SYN message can include options, some of which may be eliminated by
the Edge Router (i.e., those options not supported by the
LOWPAN_TCPHC mechanism). The ER sends the SYN segment in a full
header message with a CID equal to zero. Upon the reception of the
SYN segment, the LoWPAN node sends a SYN/ACK segment including a new
CID, set to to the highest used CID value (denoted in Figure 2 as
"max"). After the reception of the third segment of the three-way
handshake, the ER assigns a CID number to the LoWPAN host and itself
for identifying the new connection. The CID number should be the
smallest value greater than max, and sends it to the LoWPAN node in
the ACK segment.
External IP Host Edge Router LoWPAN Host
| | |
| <-- SYN --- | <-- SYN with CID=max--- |
| --- SYN/ACK --> | --- SYN/ACK with CID --> |
| <-- ACK --- | <-- ACK with CID --- |
Figure 3: TCP/IPv6 Connection initiated by a LoWPAN host
Figure 3 gives an example of a TCP connection initiated by a LoWPAN
node. The first SYN segment is sent with the full header with a CID
value equal to zero. The LoWPAN host replays by sending a TCP SYN+
ACK in full header with a CID equals to the maximum of its current
used CIDs. The ER assigns the CID number which is the smallest value
greater than max, and sends it to the LoWPAN node in the ACK segment.
LoWPAN Host LoWPAN Host
| |
| <-- SYN with CID=Max1--- |
| --- SYN/ACK with CID=max(Max1,Max2)+1 --> |
| <-- ACK with CID --- |
Figure 4: TCP/IPv6 Connection between two LoWPAN hosts
Figure 4 presents a TCP connection initiated by a LoWPAN node to
Ayadi, et al. Expires January 7, 2011 [Page 10]
Internet-Draft TCP header compression for 6LoWPAN July 2010
another LoWPAN node. The LoWPAN host sends in the TCP SYN segment a
CID equals to the maximum of its current used CIDs. Upon the
reception of a TCP SYN segment, the second LoWPAN assigns a CID for
this connection equal to the maxmimum of the two maximum value plus
one. If all CID values are used, the compressor or the decompressor
should increase the CID field length from 8 bits or 16 bits. In this
case, the choice of the CID depends only on the two LOWPAN nodes.
2.2. The Context Management
This section describes the context management in 6LoWPAN when the
LOWPAN_TCPHC is used. In a wireless network, the 6LoWPAN node may
move and thus changes the edge router to which it is attached.
However, this change should not affect the TCP communication. To
ensure the TCP communication despite the change of ER, the ERs should
share the contexts of current connections. So, even if a 6LoWPAN
node changes its attached ER, the new ER should continue to compress
the segments using the same context. The contexts exchange and
management between ERs is out of scope of this document.
The edge router should free a context when a TCP connection is
finished (e.g., reception of FIN control messages). The Edge Router
can also free a connection after a silent period (i.e., when no
messages is exchanged after a certain period of time). After a
context get free, its CID can be used by the ER and may be assigned
to a new TCP connection.
2.3. Loss Detection and Retransmissions
In this section, we present how should react the LOWPAN_TCPHC
mechanism when a segment is lost or is assumed to be lost. The loss
is handled when the TCP ACK segment is not received within the RTO.
The ER handles a retransmission by scanning the sequence numbers.
The ER should send a mostly compressed header segment when it
receives an already sent segment. This mechanism allows updating the
context of both sides after a packet loss. We assume that the
6LoWPAN has a low bit rate, and short memory and thus the TCP window
size is probably limited to few segments. In this case, the lost of
synchronization is not fatal. For this reason, this document does
not present a refresh algorithm to update the context between the
compressor and the decompressor.
Ayadi, et al. Expires January 7, 2011 [Page 11]
Internet-Draft TCP header compression for 6LoWPAN July 2010
External IP Host Edge Router LoWPAN Host
| | |
| --- Regular DATA(n) --> | --- Compressed header DATA(n) -->|
| <-- Regular Ack(n+1) --- | <-- Compressed header ACK(n+1) ---|
| --- Regular DATA(n+1) --> |--- Compressed header DATA(n+1) -X |
| | |
| A data packet get lost in the wireless area |
| | |
| --- Regular DATA(n+2) --> | --- Compressed DATA(n+2) --> |
| | |
| The TCP receiver and the Edge router handle the packet loss |
| The TCP receiver should keep the packet if it has enough memory |
| | |
| <-- Regular Ack(n+1) --- | <-- Compressed header ACK(n+1) ---|
| | |
| The TCP sender retransmits the lost segment |
| | |
| --- Regular DATA(n+1) --> |--- Compressed header DATA(n+1) -->|
| | |
| The receive decompress the request data segment, |
| and the previously received segment if they was already |
| saved and finally send an ACK to request the next segment |
| | |
| <-- Regular Ack(n+3) --- | <-- Compressed header ACK(n+3) ---|
| | |
Figure 5: Loss detection in 6LoWPAN
Figure 5 shows a scenario where a TCP segment is lost in the wireless
area. Then, a new TCP segment arrives because the current value of
the TCP windows is more that one. The reception of the new segment,
the LOWPAN node may not be able to decompress the segment. If the
LOWPAN node has enough memory, it may save the message and then
reduce a new retransmission.
Ayadi, et al. Expires January 7, 2011 [Page 12]
Internet-Draft TCP header compression for 6LoWPAN July 2010
3. Transmission Control Protocol
This section presents with more details on Transmission Control
Protocol and its header fields. As it has been defined in [RFC0793],
The TCP is a connection-oriented, end-to-end reliable transport
protocol mostly used in IP-based networks. The TCP is able to
transfer a continuous stream of octets in each direction between two
end-points by packing some number of octets into segments for
transmission through IP-based network. In general, the TCPs decide
when to block and forward data at their own convenience.
To ensure the end-to-end reliability, the TCP must recover data that
is damaged, lost or delivered out-of-order. This is achieved by
assigning a sequence number to each transmitted octet (done by the
TCP source), and by requiring a positive acknowledgment (ACK) from
the TCP destination. If the ACK is not received within the timeout
interval, the data segment is assumed to be lost. Then, the source
TCP should retransmit it. At the receiver, the sequence numbers are
used to correctly order segments that may be received out of order
and eliminate duplicates. Damaged segments are handled by adding a
checksum to each segment transmitted, checking it at the receiver and
rejecting damaged segments.
3.1. TCP headers fields
In this section, we present a short description of TCP header fields.
[RFC4413] provides detailed description of TCP header and TCP header
options.
o Source port (16 bits): This field identifies the sending port.
This field will be replaced by the CID.
o Destination port (16 bits): This field identifies the receiving
port. This field will be replaced by the CID.
o Sequence Number (32 bits): The sequence number of the first data
octet in this segment (except when SYN is present). If SYN is
present the sequence number is the initial sequence number (ISN)
and the first data octet is ISN+1. Only changed octets of this
field will be sent. If this field does not change, no bit should
be sent.
o Acknowledgment number (32 bits): If the ACK control bit is set
this field contains the value of the next sequence number the
sender of the segment is expecting to receive. Once a connection
is established this is always sent. Only changed octets of this
field according to the last sent segment will be sent. If this
field does not change, no bit should be sent.
Ayadi, et al. Expires January 7, 2011 [Page 13]
Internet-Draft TCP header compression for 6LoWPAN July 2010
o Reserved (4 bits): Reserved for future use. Must be zero. This
field should not be sent in compressed segments.
o flags (8 bits):
URG (1 bit): Urgent Pointer field significant.
ACK (1 bit): Acknowledgment field significant.
PSH (1 bit): Push Function.
RST (1 bit): Reset the connection.
SYN (1 bit): Synchronize sequence numbers.
FIN (1 bit): No more data from sender.
CWR (1 bit): Signal congestion windows reduced.
ECE (1 bit): Echo the 'congestion experienced' signaled in IP
header.
o Window (16 bits): The number of data octets beginning with the one
indicated in the acknowledgment field with the sender of this
segment is willing to accept. This field is compressed and only
the octet that has changed are sent. In LOWPAN_TCPHC, two bits
are used to indicates the octets that are uncompressed.
o Checksum (16 bits) The 16-bit checksum field is used for error-
checking of the header and data. This field is not compressed by
LOWPAN_TCPHC.
o Urgent Pointer (16 bits): This field communicates the current
value of the urgent pointer as a positive offset from the sequence
number in this segment. The urgent pointer points to the sequence
number of the octet following the urgent data. This field is only
be interpreted in segments with the URG flag set to 1. This field
is rarely used in TCP communications. For this reason, the URG
flag and Urgent Pointer are sent if and only if they are set. In
this case, the segment is sent with fullheader.
3.2. TCP Header Options
Options may occupy space at the end of the TCP header and are a
multiple of the 8 bits in length. All options are calculated in the
checksum. Most used TCP options are indicated below:
Ayadi, et al. Expires January 7, 2011 [Page 14]
Internet-Draft TCP header compression for 6LoWPAN July 2010
o End of Option List (8bits): indicates the end of the option list
o No-Operation (8bits)): may be used between options
o Maximum Segment Size (32bits): the maximum receive segment size at
the TCP which sends this segment
o Window Scale Option (24bits): indicate that the sending TCP end-
host is prepared to perform both send and receive windows scaling
o Sack-Permitted (16bits): ask for using sack option
o Sack (80-320 bits): acknowledge already received segment
o Timestamp (80bits): used to compute RTT
The TCP header padding is used to ensure that the TCP header ends and
data begins on the 32 bit boundary. The padding is composed of
zeros.
Ayadi, et al. Expires January 7, 2011 [Page 15]
Internet-Draft TCP header compression for 6LoWPAN July 2010
4. TCP header fields compression
In this section, we define the LOWPAN_TCPHC specifications for TCP
header compression for IEEE 802.15.4 networks. LOWPAN_TCPHC
initiates the compression algorithm by exchanging a context
identifier at the beginning of the connection. The compressor and
decompressor store most fields of the first full headers as a
context.
As it is described in [RFC2507], the context consists of the header
fields whose values are constant and regularly increasing. The
dynamic fields should be elided because they are the same or few
change with respect to the previous header. In fact, It is more
efficient to send fewer bits, which are the difference from previous
value comparing to the sending of the absolute value.
This mechanism is based on sending not all TCP fields, but only
fields or parts of fields that do change from the last one sent.
That is why, the TCP receiver should save the last received segments
to decompress the next one. Therefore, the two first octets of the
sequence number field can be elided if they are equal to the value of
the previous segment.
If a TCP segment gets lost and must be retransmitted by the TCP
engine, the retransmitted segment should be sent with a full header.
Then, the TCP receiver updates again the context.
The TCP compression format is shown in Figure 10. The three first
bits are used to dispatch between different types of segments.
LOWPAN_TCPHC uses two octets which contain the uncompressed flags of
TCP.
Source and destination port numbers are omitted and replaced by a
context identifier. This latter should be sent in connection
initiation messages and be replaced source and destination port
numbers.
The checksum is not compressed and is used by the receiver to check
if the decompressed TCP segment is received correctly. To reduce the
TCP header length, only these fields which have been changed between
two successive segments need to be sent to the receiver. Thus, the
receiver based on previously received segment reconstructs the
original TCP header.
The urgent pointer field is transmitted only when the urgent bit is
set. When a receiver sends a duplicated acknowledgment, LOWPAN_TCPHC
can compress the TCP header down to six octets (2 octets
LOWPAN_TCPHC, 1 octet CID, 1 octet sequence number of 1 octet
Ayadi, et al. Expires January 7, 2011 [Page 16]
Internet-Draft TCP header compression for 6LoWPAN July 2010
acknowledgment number, 2 octets Checksum).
4.1. TCP ports
These fields are part of the definition of a stream and they must be
constant for all packets in the stream. TCP port numbers can be
elided in TCP compressed segments and replaced by a context
identifier (CID). The context identifier should be generated by the
destination host or by the border router and it should be sent with
the last uncompressed TCP segment.
4.2. Flags
Some of the TCP flags are omitted because TCP control messages are
sent uncompressed. The uncompressed flags are : Push, Fin,
Congestion Window Reduced (CWR) and ECN-Echo indicates (ECE). These
flags are present in the two octets of LOWPAN_TCPHC.
4.3. Sequence and Acknowledgment numbers
The sequence number specifies the first data octet in the segment
(except the first segment). The length of the sequence number field
is four octets.
Jacobson in [RFC1144] assumes that packets are arriving in order. He
proposes sending the difference between fields of segments rather
than sending the fields themselves. In LoWPAN_TCPHC, the numbers
sent for TCP sequence number and acknowledgment are the difference
between the current value and the value in the previous packet. The
lost of a packet and/or the reception of an out-of-order packets lead
to a loss of synchronization between the compressor and the
decompressor. In this case, the TCP engine after waiting a RTO,
restarts the retransmission by sending a mostly compressed header
segment. The Van Jacobson's scheme is very loss- and disorder-
sensitive [Wang04].
In a TCP connection, the sequence number is incremented for each
packet by a value between 0 and the MSS (Maximum Segment Size).
Thus, the first two octets would change more frequently than the last
ones. The two first octets can be sent if the other octets do not
change. The decompressor module can deduce the elided octets from
the previously received segments.
For example: The MSS value is 512 octets and the current sequence
number is 00f24512. Then, the sequence number of the next segment
should be less or equal to 00f24712. The compressed segment can sent
with only two octets instead of sending all 4 octets. The TCP sender
can send two octets "4712" and the TCP receives should add the
Ayadi, et al. Expires January 7, 2011 [Page 17]
Internet-Draft TCP header compression for 6LoWPAN July 2010
remaining static octets "00f2". Using this method, we reduce to
about 50% the length of sequence number or acknowledgment number
fields if the MSS value does not exceed 65535 octets.
The sequence number can be elided if a receiver is just acknowledging
data segments and does not send data to the source. The same
algorithm is used for the compression of acknowledgment number and
only octets which are changed should be carried in-line. If the TCP
sink does not generate data, the four octets of sequence number are
omitted in all acknowledgment segments and only compressed
acknowledgment fields should be sent. One of the suitable solutions
for out-of-orders packets can be "Twice" algorithm [RFC2507]. A new
sophisticated algorithm can be proposed to improve "Twice" algorithm.
4.4. Window
The window field can be omitted if it does not change in time.
Moreover, only the window field bits that have been changed should be
sent. The decompression deduces the value of this field from the
last received full segment.
4.5. Urgent Pointer
The urgent pointer field is sent in fullheader format only if the
urgent flag is set. Otherwise, this field is elided.
Ayadi, et al. Expires January 7, 2011 [Page 18]
Internet-Draft TCP header compression for 6LoWPAN July 2010
5. LOWPAN_TCPHC Format
5.1. TCP segments types
This section presents the components of different types of TCP
segments. In fact, four types of packets are used in a TCP session
with header compression:
Regular header TCP segment: A normal, uncompressed header, Does not
carry any CID or generation association. Figure 6 shows the
header stack of a regular TCP segment.
+-------------+------------+---------+
| IPv6 header | TCP header | Payload |
+-------------+------------+---------+
Figure 6: Regular header TCP segment
Full header TCP segment: An uncompressed header that updates or
refreshes the context for a packet stream. It carries a CID that
will be used to identify the context. Figure 7 shows the header
stack of a full header TCP segment.
+-------------+--------------+-----+------------+---------+
| IPv6 header | LOWPAN_TCPHC | CID | TCP header | Payload |
+-------------+--------------+-----+------------+---------+
Figure 7: Full header TCP segment
Mostly compressed header TCP segment: A TCP segment sent to refresh
only dynamic field. Especially requested after a packet loss or
after the reception of an out-of-order segment. Figure 8 shows
the header stack of a mostly compressed TCP segment.
+-------------+--------------+-----+----------------+---------+
| IPv6 header | LOWPAN_TCPHC | CID | Dyn. TCP field | Payload |
+-------------+--------------+-----+----------------+---------+
Figure 8: Mostly compressed header TCP segment
Compressed header TCP segment: Figure 9 shows the header stack of a
compressed TCP segment.
+-------------+--------------+-----+-------------------+---------+
| IPv6 header | LOWPAN_TCPHC | CID | Uncomp. TCP field | Payload |
+-------------+--------------+-----+-------------------+---------+
Figure 9: Compressed header TCP segment
Ayadi, et al. Expires January 7, 2011 [Page 19]
Internet-Draft TCP header compression for 6LoWPAN July 2010
5.2. LOWPAN_TCPHC Format
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DISPATCH |Id | Seq | Ack | W |CWR|ECE| F | P | T | S |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 10: TCP Header Encoding
DISPATCH: Three bits, which allow specifying up to seven kinds
header on TCP header compression
000: Reserved
001: Full header TCP segment.
010: Mostly compressed TCP header segment.
011: Compressed TCP header segment.
1xx: Reserved
Id: Context Identifier
0: CID is coded in 8 bits.
1: CID is coded in 16 bits.
Seq: Sequence Number:
00: All 32 bits of Sequence Number are elided.
01: First 8 bits of Sequence Number are carried in-line. The
remaining 24 bits are elided.
10: First 16 bits of Sequence Number are carried in-line. Last
16 bits of Sequence Number are elided.
11: All 32 bits of Sequence Number are carried in-line.
Ack: Acknowledgment Number:
00: All 32 bits of Acknowledgment Number are elided.
01: First 8 bits of Acknowledgment Number are carried in-line.
The remaining 24 bits are elided.
Ayadi, et al. Expires January 7, 2011 [Page 20]
Internet-Draft TCP header compression for 6LoWPAN July 2010
10: First 16 bits of Acknowledgment Number are carried in-line.
Last 16 bits of Acknowledgment Number are elided.
11: All 32 bits of Acknowledgment Number are carried in-line.
W: Window:
00: The Window field is elided.
01: The first octet of Window field is carried in-line. The
second octet is elided.
10: The second octet of Window field is carried in-line. The
first octet is elided.
11: Full 16 bits for Window field are carried in-line.
F: Fin flag
P: Push Function
CWR: Congestion Window Reduced
ECE: ECN-Echo
T: Indicated if the TCP header contains Timestamp option
S: Indicated if the TCP header contains SACK option
Fields carried in-line (in part or in whole) appear in the same order
as they do in the TCP header format [RFC0793]. The TCP Length field
must always be elided and it is inferred from lower layers using the
6LoWPAN fragmentation header or the IEEE 802.15.4 header.
5.3. Examples of compressed TCP headers
In this section, we present some examples of a compressed TCP header
using LOWPAN_TCPHC.
5.3.1. Mostly compressed header
Figure 11 represents a header of a mostly compressed segment. The
sequence number, acknowledgment number and window size fields are
carried in-line. The size of this header is 15 octets.
Ayadi, et al. Expires January 7, 2011 [Page 21]
Internet-Draft TCP header compression for 6LoWPAN July 2010
3 1 2 2 2 1 1 2 1 1 8 32 32 16 16
+---+-+--+--+--+-+-+-+-+-+-+---+---------+---------+-------+--------+
|010|0|11|11|11|0|0|0|1|0|0|CID|Seq.Numb.|Ack.Numb.|Windows|Checksum|
+---+-+--+--+--+-+-+-+-+-+-+---+---------+---------+-------+--------+
Figure 11: Mostly compressed header TCP Header Encoding
5.3.2. Compressed header
Figure 12 represents a header of a TCP data segment whose window
field has not been changed from compared to its antecedent, the two
bytes of the lowest octets of the sequence number that have been
changed. The size of this header is seven octets
3 1 2 2 2 1 1 1 1 1 1 1 8 16 16
+---+-+--+--+--+-+-+-+-+-+-+-+---+----------+----------+
|011|0|01|00|00|0|0|0|0|0|0|0|CID|Seq.Number| Checksum |
+---+-+--+--+--+-+-+-+-+-+-+-+---+----------+----------+
Figure 12: Compressed header TCP Header Encoding
Ayadi, et al. Expires January 7, 2011 [Page 22]
Internet-Draft TCP header compression for 6LoWPAN July 2010
6. TCP Option Compression
This section defines a compression method for the TCP options most
likely to be used in 6LoWPAN. The ER can decide to allow or to deny
an option sent in the SYN segment. LOWPAN_TCPHC compresses the
mostly used TCP options : SACK and Timestamp. We assume that the
SACK and Timestamp are not negotiated and used by default.
LOWPAN_TCPHC specifies two bits for SACK and Timestamp TCP options.
Figure 13 shows the structure of a TCP segment including options
compressed using LOWPAN_TCPHC. MSS and SACK-Permitted options are
sent in a SYN and they are compressed. The Window Scale Option (WSO)
is useless in 6LoWPAN because it is more performance to use small
windows than large windows. The size of the SACK option is 4 octets
and the size of Timestamp option is variable from 4 to 8 octets.
+--------------+---------+-----------+--------
| LOWPAN_TCPHC | SACK | Timestamp | Payload
| Encoding | option | option |
+--------------+---------+-----------+--------
Figure 13: TCP Header Option Configuration
6.1. SACK
The SACK option [RFC2018] [RFC2883] should be negotiated in set-up
phase, then the option may be used when dropped segments are detected
by the receiver. This option is to be used to convey extended
acknowledgment information over an established connection. The left
edge of the block can be replaced by the offset between the first
octet of the segment and the right edge by the length of the block.
The Left edge and the right edge will be coded in 16 bits.
+---------------------+---------------------+
| Left Edge (16 bits) | Right Edge (16bits) |
+---------------------+---------------------+
Figure 14: Compressed SACK option
6.2. Timestamp
This option carries eight-octet timestamp fields. If timestamp
options [RFC1323] are exchanged in the connection set-up phase, they
are expected to appear on all subsequent segments. This overhead
added by this option can be reduce : a TCP that does not sent data is
not interested to compute the RTTM. And thus, it can replay by
sending only Timestamp Echo Reply field (TSecr). However, the
Timestamp Value field (TSval) is more important for TCP that send
data. Then, if the T flag and ACK flag are set, it mean that the
Ayadi, et al. Expires January 7, 2011 [Page 23]
Internet-Draft TCP header compression for 6LoWPAN July 2010
next 4 octets contain the TSecr. Otherwise, (i.e., if the ACK flag
is not set) the 4 octets contain the TSval. This optimization is
only valid when a single TCP sends data. Otherwise, the two four-
octets should be sent.
Ayadi, et al. Expires January 7, 2011 [Page 24]
Internet-Draft TCP header compression for 6LoWPAN July 2010
7. Acknowledgements
This work has been funded by the Pole de Recherche Avancee en
Communications (PraCOM). The authors would like to thank Patrick
Maille and Tiancong Zheng for their useful comments on an early
version of this document.
Ayadi, et al. Expires January 7, 2011 [Page 25]
Internet-Draft TCP header compression for 6LoWPAN July 2010
8. References
[Perkins et al.]
Perkins, S. and M. Multa, "Dependency removal for
transport protocol header compression over noisy
channels", International Conference on
Communications 1997, June 1997.
[Srivastava et al.]
Srivastava, A., Friday, R., Ritter, M., and W. San
Filippo, "A study of TCP performance over wireless data
networks", Vehicular Technology Conference, IEEE VTS 53rd,
May 2001.
[Wang04] Wang, R., "An experimental study of TCP/IP's Van Jacobson
header compression behavior in lossy space environment",
Vehicular Technology Conference, IEEE VTC 60th,
September 2004.
[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in 6LoWPAN Networks", October 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed
serial links", RFC 1144, February 1990.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Ayadi, et al. Expires January 7, 2011 [Page 26]
Internet-Draft TCP header compression for 6LoWPAN July 2010
Extension to the Selective Acknowledgment (SACK) Option
for TCP", RFC 2883, July 2000.
[RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413,
March 2006.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West,
"RObust Header Compression (ROHC): A Profile for TCP/IP
(ROHC-TCP)", RFC 4996, July 2007.
[Medina05]
Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet", ACM
SIGCOMM Computer Communications Review 35(2):37-51,
April 2005.
Ayadi, et al. Expires January 7, 2011 [Page 27]
Internet-Draft TCP header compression for 6LoWPAN July 2010
Authors' Addresses
Ahmed Ayadi
Telecom Bretagne
Rue de la Chataigneraie, CS 17607
35576 Cesson Sevigne cedex
France
Phone: +33 2 99 12 70 52
Email: ahmed.ayadi@telecom-bretagne.eu
David Ros
Telecom Bretagne
Rue de la Chataigneraie, CS 17607
35576 Cesson Sevigne cedex
France
Phone: +33 2 99 12 70 46
Email: david.ros@telecom-bretagne.eu
Laurent Toutain
Telecom Bretagne
Rue de la Chataigneraie, CS 17607
35576 Cesson Sevigne cedex
France
Phone: +33 2 99 12 70 26
Email: laurent.toutain@telecom-bretagne.eu
Ayadi, et al. Expires January 7, 2011 [Page 28]