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]