[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                           A. Ayadi
Internet-Draft                                                    D. Ros
Intended status: Experimental                                 L. Toutain
Expires: April 28, 2011                                 Telecom Bretagne
                                                        October 25, 2010


                   TCP header compression for 6LoWPAN
                     draft-aayadi-6lowpan-tcphc-01

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 bytes of the mandatory TCP header
   can be compressed into as little as 6 bytes.

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 April 28, 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 April 28, 2011                 [Page 1]


Internet-Draft     TCP header compression for 6LoWPAN       October 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Related Work . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Connection Initiation  . . . . . . . . . . . . . . . . . .  8
     2.2.  The LoWPAN_TCPHC context . . . . . . . . . . . . . . . . . 10
       2.2.1.  LoWPAN_TCPHC context structure . . . . . . . . . . . . 10
       2.2.2.  Context management . . . . . . . . . . . . . . . . . . 12
     2.3.  Loss detection and retransmissions . . . . . . . . . . . . 12
   3.  Transmission Control Protocol  . . . . . . . . . . . . . . . . 13
     3.1.  TCP headers fields . . . . . . . . . . . . . . . . . . . . 14
     3.2.  TCP Header Options . . . . . . . . . . . . . . . . . . . . 15
   4.  TCP header fields compression  . . . . . . . . . . . . . . . . 15
     4.1.  TCP ports  . . . . . . . . . . . . . . . . . . . . . . . . 16
     4.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     4.3.  Sequence and Acknowledgment numbers  . . . . . . . . . . . 16
     4.4.  Window . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     4.5.  Urgent Pointer . . . . . . . . . . . . . . . . . . . . . . 17
   5.  LOWPAN_TCPHC Packet Format . . . . . . . . . . . . . . . . . . 17
     5.1.  TCP segments types . . . . . . . . . . . . . . . . . . . . 17
     5.2.  LOWPAN_TCPHC Format  . . . . . . . . . . . . . . . . . . . 18
     5.3.  Examples of compressed TCP headers . . . . . . . . . . . . 19
       5.3.1.  Compressed header  . . . . . . . . . . . . . . . . . . 19
   6.  TCP Option Compression . . . . . . . . . . . . . . . . . . . . 19
     6.1.  Selective Acknowledgment option  . . . . . . . . . . . . . 20
     6.2.  Timestamp option . . . . . . . . . . . . . . . . . . . . . 20
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23















Ayadi, et al.            Expires April 28, 2011                 [Page 2]


Internet-Draft     TCP header compression for 6LoWPAN       October 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 bytes.  In [I-D.ietf-6lowpan-hc], a header-compression
   method for the transport layer (LOWPAN_NHC) has also been introduced,
   however, only a 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 byte (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 typically [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.

   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 should be able to
   decompress compressed segments correctly even when segments arrive



Ayadi, et al.            Expires April 28, 2011                 [Page 3]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   with a moderate reordering).

   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
   and decompression is performed in the edge router between the 6LoWPAN
   and the external IP network.  The compression scheme can also be used
   between two 6LoWPAN nodes for machine-to-machine communications.
   This document defines also an encoding format for LOWPAN_TCPHC header
   compression.  Such mechanism and packet format aims at making TCP a
   more 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 header overheads to about
   seven to ten bytes instead of 60 bytes.

   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 subsequent 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 describe 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 current and the previous
   value of dynamic fields (e.g., sequence number, acknowledgment
   number).  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 ubiquitous nowadays
   [Medina05].




Ayadi, et al.            Expires April 28, 2011                 [Page 4]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   IPHC [RFC2507] enhances Jacobson's TCP header compression by
   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 acknowledgments.  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 signaling overhead.  LoWPAN_TCPHC enhances
   IPHC by defining an adapted header compression of TCP for LLNs by
   sending lest significant bytes instead of sending a delta value.
   Moreover, LoWPAN_TCPHC completes IPHC by defining header compression
   schemes for the mostly used TCP options.

   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 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



Ayadi, et al.            Expires April 28, 2011                 [Page 5]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


      compressing the header.
   o  Decompression: The act of reconstructing a compressed header.
   o  Static fields: These fields are expected to be constant throughout
      the lifetime of the TCP connection.  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 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.
   o  Compressed header: A header in which all the static fields are
      elided, and all the dynamic fields are sent compressed.
   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.
   o  LoWPAN host: A node that only sources or sinks IPv6 datagrams.
      Referred to as a host in this document.
   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.


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



Ayadi, et al.            Expires April 28, 2011                 [Page 6]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   intent of reducing both bandwidth usage and energy consumption due to
   packet transmissions.

   Indeed, the LOWPAN_TCPHC allows establishing TCP connections between
   an external IP host and a LoWPAN host, and also between two LoWPAN
   hosts.  This former 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 with which two edge router
   create a bridge between the LoWPAN network and the external IP
   network.  The path between a LoWPAN node to the external network may
   change following the movement of the node or the update of routing
   tables.

                           |                  *  *
                           |                 *  *  *
                           |    +--------+  *  *  *  *
                           |____|  Edge  | *  *  *  *  *
                           |    | Router | *  *  *  *  *
                           |    +--------+  *  *  *  *
                           |                 *  *  *
    External IP Network -- |                  *  *  *
                           |                 *  *  *
                           |    +--------+  *  *  *  *
                           |____|  Edge  | *  *  *  *  *
                           |    | Router | *  *  *  *  *
                           |    +--------+  *  *  *  *
                           |                 *  *  *
                           |                  *  *
    *: LoWPAN Node

                        Figure 1: A 6LoWPAN network

   The compression and decompression mechanisms are implemented on the
   edge routers and on the LoWPAN hosts.  The ERs create and maintain
   the contexts of all TCP connections.  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 or full headers.

   The LOWPAN_TCPHC algorithm does not compress TCP control messages at
   the connection establishment phase.  These segments are used to
   exchange the context identifier (CID) and allow the ER to create a
   context using the TCP header fields.  The LOWPAN_TCPHC algorithm
   supports usefull TCP option for LLNs.  Supported TCP options that are
   negotiated in the two first messages are sent in a full header
   format.  Whereas, the remaining supported options are sent compressed
   with in the TCP segments.  The LOWPAN_TCPHC algorithm defines a



Ayadi, et al.            Expires April 28, 2011                 [Page 7]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   compression mechanism for TCP SACK and Timestamp options.

   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 packet is
   dropped due to loss, then the mechanism refreshes the context by
   retransmitting lost segments using the mostly compressed header
   format.

   The compression protocol uses two different header formats.  For the
   TCP opening phase and for error management, the TCP segments must 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 LoWPAN host if the TCP connection is between
   a LoWPAN host and an external IP host.  Otherwise (i.e., a TCP
   connection between two LoWPAN hosts), the CID value and its size are
   set by the LoWPAN host that has opened the connection.  For the TCP
   connection between a LoWPAN host and an external IP host, the couple
   (CID, Ipv6 address) must be unique.

   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 is lost, corruption or
   reordering is detected by the TCP receiver.  This segment is called
   mostly compressed header and contains dynamic fields with all bytes
   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 April 28, 2011                 [Page 8]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


    External IP host          Edge Router                LoWPAN host
    |                              |                               |
    | --- SYN -->                  |         --- SYN with CID=0--> |
    | The LOWPAN host creates a context for the new TCP connection |
    |                                                              |
    |                              |       <-- SYN/ACK with CID--- |
    | The ER creates a context using the received (CID, LoWPAN IPv6)  |
    |                              |                               |
    | <-- SYN/ACK ---              |                               |
    | --- ACK -->                  |          ---  ACK with CID -->|
    |                              |                               |

         Figure 2: TCP 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 the smallest available CID value.  The ER creates a new
   context with the received information from the SYN/ACK segment.

    External IP host          Edge Router                LoWPAN host
    |                              |                               |
    |                              |           <-- SYN with CID--- |
    |  The LOWPAN host creates a context and sends the SYN message |
    |                                                              |
    | <-- SYN ---                  |                               |
    | The ER creates a context for the new TCP connection          |
    |                                                              |
    | --- SYN/ACK -->              |      --- SYN/ACK with CID --> |
    | <-- ACK ---                  |          <-- ACK with CID --- |

            Figure 3: TCP Connection initiated by a LoWPAN host

   Figure 3 gives an example of a TCP connection initiated by a LoWPAN
   host.  The first SYN segment is sent with the full header with a CID
   value equal to smallest available value of CIDs.  Contrary to the
   first case, the ER creates a context upon the reception of the SYN
   message from the LoWPAN host.








Ayadi, et al.            Expires April 28, 2011                 [Page 9]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


      LoWPAN host                                      LoWPAN host
      |                                                           |
      |                <-- SYN with CID---                        |
      | The initiator LOWPAN Host creates a context for the new   |
      | TCP connection and then sends SYN segment                 |
      |                                                           |
      |                   --- SYN/ACK with CID--->                |
      | The receiver creates a context using the initiator IID    |
      |                                                           |
      |                <--  ACK with CID ---                      |

          Figure 4: TCP/IPv6 Connection between two LoWPAN hosts

   Figure 4 presents a TCP connection initiated by a LoWPAN node to
   another LoWPAN node.  The LoWPAN host sends in the TCP SYN segment
   with a CID equals to the smallest available CID value.

   The CID value is chosen by the first LoWPAN host that is involved in
   establishing the TCP connection.  This way, it is easy to ensure the
   unicity of the CID.  At the same time, this simplifies the context
   management at the ERs.  Moreover, if all CID values are used, the
   initiator should increase the CID field length from 8 bits to 16
   bits.

2.2.  The LoWPAN_TCPHC context

2.2.1.  LoWPAN_TCPHC context structure

   The context includes some TCP header fields that are needed by the
   compressor and the decompressor algorithm.  Figure 5 lists the
   contents of a LOWPAN_TCPHC context.




















Ayadi, et al.            Expires April 28, 2011                [Page 10]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


      +---------+------------------------------------+----------+
     | Field   | Description                        | Length   |
     +---------+------------------------------------+----------+
     | CID     | Context Identifier                 | 16 bits  |
     +---------+------------------------------------+----------+
     | Address | LoWPAN IPv6 address                | 128 bits |
     ---------+------------------------------------+----------+
     | SrcPort | TCP Source Port Number             | 16 bits  |
     +---------+------------------------------------+----------+
     | DstPort | TCP Destination Port Number        | 16 bits  |
     +---------+------------------------------------+----------+
     | seq_rcv | Sequence number in incoming segments | 32 bits  |
     +---------+------------------------------------+----------+
     | ack_rcv | Acknowledgment number in reception | 32 bits  |
     ---------+------------------------------------+----------+
     | wnd_rcv | Window size in reception           | 16 bits  |
     ---------+------------------------------------+----------+
     | seq_snd | Sequence number in reception       | 32 bits  |
     +---------+------------------------------------+----------+
     | ack_snd | Acknowledgment number in reception | 32 bits  |
     ---------+------------------------------------+----------+
     | wnd_snd | Window size in reception           | 16 bits  |
     ---------+------------------------------------+----------+
     | State   | Context state                      | 4 bits   |
     +---------+------------------------------------+----------+

               Figure 5: Structure of a LOWPAN_TCPHC context

   The address field saves the Ipv6 address of the 6LoWPAN node.  If the
   TCP connection is established between two 6LoWPAN nodes, the Ipv6
   address of the initiator is saved in the context.

   State field indicates in which state a TCP connection is.  This field
   is especially needed by the ERs.  The possible states of a context
   are: closed, using, closing, fin_1, fin_2, fin_3, and shutting.

   The CID and Ipv6 address are utilized to identify the connection for
   compressed headers.  The SrcPort and DstPort, toghether with the Ipv6
   adsress, are used to identify the connection for full headers.

   The seq_rcv, ack_rcv, and wnd_rcv are used to store the dynamic
   fields of the last incoming segment (except retransmitted segment).
   While the seq_snd, ack_snd, and wnd_snd are the dynamic fields of the
   last outgoing segment (except retransmitted segment).







Ayadi, et al.            Expires April 28, 2011                [Page 11]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


2.2.2.  Context management

   This section describes the context management in 6LoWPAN when
   LOWPAN_TCPHC is used.  The edge router to which a LoWPAN node host is
   attached may change over time, due to route instability or to host
   mobility However, this change should not break 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.  Context exchange and
   management between ERs is out of the 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 are exchanged after a certain period of time).

   The ER may remove the context of a TCP connection that is not yet
   closed.  In this case, after receiving a new data segment, the ER
   SHOULD reply by sending a RST segment to the sender.

2.3.  Loss detection and retransmissions

   In this section, we present how the LOWPAN_TCPHC mechanism should
   react 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 on
   both sides after a packet loss.  We assume that the 6LoWPAN has a low
   bit rate, and also that nodes are memory-constrained and thus the TCP
   window size is probably limited to a few segments.  In this case, the
   loss of synchronization will likely not lead to a burst of losses.
   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 April 28, 2011                [Page 12]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   External IP Host           Edge Router                  LoWPAN Host
   |                              |                                   |
   | --- Regular DATA(124) -->    |--- Compressed header DATA(124) -->|
   | <-- Regular ACK(188)  ---    | <-- Compressed header ACK(188) ---|
   | --- Regular DATA(188) -->    | --- Compressed header DATA(188) -X|
   | Data packet (188) is lost in the LoWPAN                          |
   |                              |                                   |
   | The External node handles the segment loss after an RTO          |
   | and retransmits the lost segment                                 |
   |                              |                                   |
   | --- Regular DATA(188) -->    |       --- Most Comp. DATA(188) -->|
   | The ER compresses the retranmitted segment with a mostly         |
   | compressed header                                                |
   |                              |                                   |
   | <-- Regular ACK(252)  ---    | <-- Compressed header ACK(252) ---|
   | The receiver decompresses the request data segment,              |
   | and finally sends an ACK to request the next segment             |
   |                              |                                   |

                    Figure 6: Loss detection in 6LoWPAN

   Figure 6 shows a scenario where a TCP segment is lost in the 6LoWPAN.
   After an RTO the enternal IP host retransmits the lost segment.  Upon
   the reception of the retransmitted segment, the ER produces a mostly
   compressed header allowing the LoWPAN node to decompress the segment.


3.  Transmission Control Protocol

   This section presents more details on TCP 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 bytes
   in each direction between two end-points by packing some number of
   bytes into segments for transmission through IP-based network.

   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 byte (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.




Ayadi, et al.            Expires April 28, 2011                [Page 13]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


3.1.  TCP headers fields

   In this section, we present a short description of TCP header fields
   and how they are handled by the compression mechanism.  [RFC4413]
   provides a 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 in compressed headers.
   o  Destination port (16 bits): This field identifies the receiving
      port.  This field will be replaced by the CID in compressed
      headers.
   o  Sequence Number (32 bits): The sequence number of the first data
      byte in this segment (except when SYN flag is set).  If SYN is
      present the sequence number is the initial sequence number (ISN)
      and the first data byte is ISN+1.  Only the bytes that change
      (respect to the previous segment) will be sent.  If this field
      does not change, nothing should be sent.
   o  Acknowledgment number (32 bits): If the ACK flag 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 bytes of this field according
      to the last sent segment will be sent.  If this field does not
      change, nothing should be sent.
   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 contains a valid value.
      ACK (1 bit):  Acknowledgment field contains a valid value.
      PSH (1 bit):  Push.
      RST (1 bit):  Reset the connection.
      SYN (1 bit):  Synchronize sequence numbers.
      FIN (1 bit):  No more data from sender.
      CWR (1 bit):  Congestion window reduced.
      ECE (1 bit):  Echo the 'congestion experienced' signal in the IP
         header.
   o  Window (16 bits): The number of data bytes, beginning with the one
      indicated in the acknowledgment field, the sender of this segment
      is willing to accept.  This field is compressed and only the bytes
      that have changed are sent.
   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 byte following the urgent data.  This field is only
      interpreted in segments with the URG flag set to 1.  This field is
      rarely used in TCP communications.  For this reason, the URG flag



Ayadi, et al.            Expires April 28, 2011                [Page 14]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


      and Urgent Pointer are sent if and only if they are set.  In this
      case, the segment is sent with a full header.

3.2.  TCP Header Options

   Options may occupy space at the end of the TCP header and are a
   multiple of 8 bits in length.  Options are considered for the
   checksum calculation.  The most used TCP options are indicated below:
   o  End of Option List (8 bits): indicates the end of the option list.
   o  No-Operation (8 bits): may be used between options.
   o  Maximum Segment Size (32 bits): the maximum segment size at the
      TCP which sends this segment.
   o  Window Scale Option (24 bits): indicates that the sending TCP end-
      host is prepared to perform both send and receive window scaling.
   o  SACK-Permitted (16 bits): ask for using SACK option.
   o  SACK (80-320 bits): selective acknowledgment.
   o  Timestamp (80 bits): 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.


4.  TCP header fields compression

   In this section, we define the LOWPAN_TCPHC specifications for TCP
   header compression for LLNs.  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 described in [RFC2507], the context consists of the header fields
   whose values are constant or regularly increasing.  The dynamic
   fields should be elided because they are the same 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.  The LoWPAN_TCPHC mechanism is based on
   sending only those fields or parts of fields that do change with
   respect to the previously sent packet.  That is why, the TCP receiver
   should save the last received segment fields to decompress the next
   one.  For example, the two first bytes of the sequence number field
   can be elided if they are equal to the value of the previous segment.

   If a TCP segment is lost and must be retransmitted, the retransmitted
   segment should be sent with a mostly compressed header.  Then, the
   TCPHC receiver updates the context.

   The TCP compression format is shown in Figure 10.  The three first
   bits are used to dispatch between different types of segments.



Ayadi, et al.            Expires April 28, 2011                [Page 15]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   LOWPAN_TCPHC uses two bytes which contain the uncompressed flags of
   TCP.

   Source and destination port numbers are omitted and replaced by a
   context identifier.  The latter should be sent in connection
   initiation messages and replaces the 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, based
   on the previously received segment, the receiver 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 bytes (2 bytes LOWPAN_TCPHC,
   1 byte CID, 1 byte acknowledgment number, 2 bytes 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
   the first involved LoWPAN node.

4.2.  Flags

   Some of the TCP flags are omitted because TCP control messages that
   set such flags (SYN, PUSH) are sent uncompressed.  The uncompressed
   flags are : PUSH, FIN, Congestion Window Reduced (CWR) and ECN-Echo
   indication (ECE).  These flags are present in the two bytes of the
   LOWPAN_TCPHC header.

4.3.  Sequence and Acknowledgment numbers

   The sequence number specifies the first data byte in the segment
   (except the first segment).  The length of the sequence number field
   is four bytes.

   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 less significant bytes (LSB) are expected to change mush
   frequently than the most significant bytes (MSB).  Thus, it is often
   enough to send the N less-significant bytes if the 4-N bytes most
   significant bytes do not change.  The decompressor module can deduce



Ayadi, et al.            Expires April 28, 2011                [Page 16]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   the elided bytes from the previously received segments.

   For example: The MSS value is 512 bytes and the current sequence
   number is 0x00f24512.  Then, the sequence number of the next segment
   should be less or equal to 0x00f24712.  The compressed segment can
   sent with only two bytes instead of sending all 4 bytes.  The TCP
   sender can send two bytes 0x4712 and the TCP receives should add the
   remaining static bytes 0x00f2.  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 bytes.

   The sequence number can be elided if a receiver is just acknowledging
   data segments and does not send data to the source (i.e., the
   receiver sends a pure TCP ACK).  The same algorithm is used for the
   compression of the acknowledgment number and only bytes which are
   changed should be carried in-line.  If the TCP sink does not generate
   data, the four bytes of the sequence number are omitted in all
   acknowledgment segments and only compressed acknowledgment fields
   should be sent.

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 full header format only if the
   urgent flag is set.  Otherwise, this field is elided.


5.  LOWPAN_TCPHC Packet Format

5.1.  TCP segments types

   Three 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.  Figure 7 shows the packet format of a regular TCP
      segment.

                  +------------+----------+-------+
                  |IPHC (NHC=0)|TCP header|Payload|
                  +------------+----------+-------+

                     Figure 7: Regular header TCP segment



Ayadi, et al.            Expires April 28, 2011                [Page 17]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   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 8 shows the packet
      format of a full header TCP segment.

           +------------+--------+---+----------+-------+
           |IPHC (NHC=1)|00000001|CID|TCP header|Payload|
           +------------+--------+---+----------+-------+

                      Figure 8: Full header TCP segment

   Compressed header TCP segment:  Figure 9 shows the header stack of a
      compressed TCP segment.

      +------------+------------+---+-----------------------+-------+
      |IPHC (NHC=1)|LOWPAN_TCPHC|CID|uncompressed TCP fields|Payload|
      +------------+------------+---+-----------------------+-------+

                   Figure 9: Compressed header TCP segment

5.2.  LOWPAN_TCPHC Format

     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 1 | 1 | 0 |Id |  Seq  |  Ack  |   W   |CWR|ECE| F | P | T | S |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                      Figure 10: TCP Header Encoding

   Id:  Context Identifier Size
      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 less-significant bits of Sequence Number are carried
         in-line.  The remaining 24 bits are elided.
      10:  First 16 less-significant 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 less-significant bits of Acknowledgment Number are
         carried in-line.  The remaining 24 bits are elided.
      10:  First 16 less-significant bits of Acknowledgment Number are
         carried in-line.  Last 16 bits of Acknowledgment Number are
         elided.





Ayadi, et al.            Expires April 28, 2011                [Page 18]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


      11:  All 32 bits of Acknowledgment Number are carried in-line.
   W: Window:
      00:  The Window field is elided.
      01:  The less-significant byte of Window field is carried in-line.
         The most-significant byte is elided.
      10:  The most-significant byte of Window field is carried in-line.
         The less-significant byte is elided.
      11:  Full 16 bits for Window field are carried in-line.
   F: FIN flag.
   P: PUSH flag.
   CWR:  Congestion Window Reduced flag.
   ECE:  ECN-Echo flag.
   T: Set if the TCP header contains Timestamp option.
   S: Set 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 MAC layer 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.  Compressed header

   Figure 11 represents a header of a TCP data segment whose window
   field has not changed from with respect its antecedent, the two bytes
   of the lowest bytes of the sequence number that have been changed.
   The size of this header is seven bytes.

      3  1  2  2  2 1 1 1 1 1 1 1 8       16         16
   +---+-+--+--+--+-+-+-+-+-+-+-+---+----------+----------+
   |010|0|01|00|00|0|0|0|0|0|0|0|CID|Seq.Number| Checksum |
   +---+-+--+--+--+-+-+-+-+-+-+-+---+----------+----------+

             Figure 11: Compressed header TCP Header Encoding


6.  TCP Option Compression

   This section defines a compression method for the TCP options most
   likely to be used in 6LoWPAN.  The "end of option" byte and the "no
   operatioon" byte are elided.  Taking into account the caracterisctics
   of the LLNs, the "window scale" option are not supported because it
   is especially needed in broadband network and the window size in LLNs
   are limited to few segments.  The "maximum segment size" option is



Ayadi, et al.            Expires April 28, 2011                [Page 19]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   negociated in the first control segments, thus they are not
   compressed.  SACK option are not negociated and are allowed by
   default.  However, 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 12 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 bytes and the size
   of Timestamp option is variable from 2 to 8 bytes.

   +--------------+-----+----------+-------+-----------+---------+
   | LOWPAN_TCPHC | CID | Com. TCP | SACK  | Timestamp | Payload |
   |   Encoding   |     |  fields  | option|  option   |         |
   +--------------+-----+----------+-------+-----------+---------+

                Figure 12: TCP Header Option Configuration

6.1.  Selective Acknowledgment option

   The TCP Selective Acknowledgment option (SACK) [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 byte 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 (16 bits) |
             +---------------------+----------------------+

                     Figure 13: Compressed SACK option

6.2.  Timestamp option

   This option carries eight-byte 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 reduced: 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.



Ayadi, et al.            Expires April 28, 2011                [Page 20]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


   LOWPAN_TCPHC sends only bytes that have changed since the last
   segment to reduce the size of the Timestamp field.  LOWPAN_TCPHC
   defines a bitmap field which specifies the bytes that are elided and
   the bytes that are carried in-line.  Figure 14 shows the structure of
   the compressed TCP timestamp option fields.

       +------------------+------------------+------------------+
       | Timestamp bitmap | Compressed TSval | Compressed TSecr |
       +------------------+------------------+------------------+

                  Figure 14: Compressed Timestamp option


7.  Acknowledgments

   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.


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.

   [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.

   [I-D.ietf-6lowpan-hc]
              Hui, J. and P. Thubert, "Compression Format for IPv6



Ayadi, et al.            Expires April 28, 2011                [Page 21]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


              Datagrams in 6LoWPAN Networks", October 2009.

   [IEEE 802.15.4]
              IEEE Computer Society, "IEEE Std. 802.15.4-2006", IEEE
              Standard for Information technology-Telecommunications and
              information exchange between systems-Local and
              metropolitan area networks- Specific requirements Part
              15.4: Wireless Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications for Low-Rate Wireless Personal
              Area Networks (WPANs), October 2006.

   [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
              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,



Ayadi, et al.            Expires April 28, 2011                [Page 22]


Internet-Draft     TCP header compression for 6LoWPAN       October 2010


              "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.


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 April 28, 2011                [Page 23]


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