[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/