Network Working Group                                        A. Minaburo
Internet-Draft                                                    Acklio
Intended status: Informational                                L. Toutain
Expires: December 8, 23, 2016     Institut MINES TELECOM ; TELECOM Bretagne
                                                           June 6, 21, 2016

    6LPWA Static Context Header Compression (SCHC) for IPV6 and UDP
             draft-toutain-6lpwa-ipv6-static-context-hc-00
             draft-toutain-6lpwa-ipv6-static-context-hc-01

Abstract

   This document describes a header compression scheme for IPv6, IPv6/
   UDP based on static contexts.  This technique is especially tailored
   for LPWA networks and could be extended to other protocol stacks.

   During the IETF history several compression mechanisms have been
   proposed.  First mechanisms, such as RoHC, are using a context to
   store header field values and send smaller incremental differences on
   the link.  Values in the context evolve dynamically with information
   contained in the compressed header.  The challenge is to maintain
   sender's and receiver's contexts synchronized even with packet
   losses.  Based on the fact that IPv6 contains only static fields,
   6LoWPAN developed an efficient context-free compression mechanisms,
   allowing better flexibility and performance.

   The Static Context Header Compression (SCHC) combines the advantages
   of RoHC formal notation, context which offers a great level of flexibility in the
   processing of fields, and 6LoWPAN behavior to elide fields that are
   known from the other side.  Static context means that values in the
   context field do not change during the transmission, avoiding complex
   resynchronization mechanisms, incompatible with LPWA characteristics.
   In most of the cases, IPv6/UDP/CoAP IPv6/UDP headers are reduced to a small context
   identifier.

   This document focuses on IPv6/UDP headers compression, but the
   mechanism can be applied to other protocols such as CoAP.  It will be
   described in a separate document.

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 December 8, 23, 2016.

Copyright Notice

   Copyright (c) 2016 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
   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.

1.  Introduction

   Headers compression is mandatory to bring the internet protocols to
   the node within a LPWA network. 6LoWPAN and its evolutions do not
   fulfil the drastic constraints imposed by the radio technology network [I-D.minaburo-lp-wan-gap-analysis].

   Nevertheless, LPWA networks offer good properties for an efficient
   header compression:

   o  Topology is star oriented. oriented, therefore all the packets follows the
      same path.  For the needs of this draft, the architecture can be
      summarized to End-Systems (ES) exchanging information with a
      single LPWA Compressor (LC).  In most of the cases, End Systems
      and LC form a star topology.  ESs and LC maintain a context for
      compression.

   o  Traffic flows are mostly deterministic, since End-Systems embed
      built-in applications.  Contrary to computers or smartphones, new
      applications cannot be easily installed.

   First mechanisms such as RoHC use a context to store header field
   values and send smaller incremental differences on the link.  The
   first version of RoHC targeted IP/UDP/RTP stack.  RoHCv2 extends the
   principle to any protocol and introduces a formal notation [RFC4997]
   describing the header and associating compression functions to each
   field.  To be efficient the sender and the receiver must check that
   the context remains synchronized (i.e. contains the same values).

   Context synchronization imposes to periodically send a full header or
   at least dynamic fields.  If fully compressed, the header can be
   compatible with LPWA constraints.  However, the first exchanges or a
   context resynchronisation resynchronisations impose to send uncompressed headers, which
   may be bigger than the original one.  This will force the use of
   inefficient fragmentation mechanisms.  For some LPWA technologies,
   duty cycle limits can also delay the resynchronization.  Figure 1
   illustrates this behavior.

                       sync
             ^         +-+         sync     sync             ^
             | IPv6    | |         +-+       +-+             | IPv6
             v         | |         | |       | |             v
      +------------+   | +-+-+     | |       | |    +------------+
      |       +--+ |   | | | |     | |       | |    | +--+       |
      |       | c| |   | | | +-+-+-+ +-+-+-+-+ |    | | c|       |
      |       | t| |   | | | | | | | | | | | | |    | | t|       |
      |       | x| |   +-+-+-+-+-+-+-+-+-+-+-+-+    | | x|       |
      |       | t| | <----------------------------> | | t|       |
      |       +--+ |                                | +--+       |
      +------------+                                +------------+

             Figure 1: RoHC Compressed Header size evolution.

   On the other hand, 6LoWPAN [RFC4944] is context-free based on the
   fact that IPv6, its extensions or UDP headers do not contain
   incremental fields.  The compression mechanism described in [RFC6282]
   is based on sending a 2-byte bitmap, which describe describes how the header
   should be decompressed, either using some standard values or sending
   information sent after this bitmap.  [RFC6282] also allows for UDP
   compression.

   In the best case, when Hop limit is a standard value, flow label,
   DiffServ fields are set to 0 and Link Local addresses are used over a
   single hop network, the 6LoWPAN compressed header is reduced to 4
   bytes.  This compression ratio is possible because the IID are
   derived from the MAC addresses and the link local prefix is known
   from both sides.  In that case, the IPv6 compression is 4 bytes and
   UDP compression is 2 bytes, which fills half of the payload of a
   SIGFOX frame, or more than 10% of a LoRaWAN payload (with spreading
   factor 12).

   The Static Context Header Compression (SCHC) combines the advantages
   of RoHC formal notation, context, which offers a great level of flexibility in the
   processing of fields, and 6LoWPAN behavior to elide fields that are
   known from the other side.  Static context means that values in the
   context field do not change during the transmission, avoiding complex
   resynchronization mechanisms, incompatible with LPWA characteristics.
   In most of the cases, IPv6/UDP/CoAP IPv6/UDP headers are reduced to a small context
   identifier.

2.  Static Context Header Compression

   Static Context Header Compression (SCHC) avoids context
   synchronization, which is the most bandwidth-consuming operation in
   RoHC.  Based on the fact that the nature of data flows is highly
   predictable in LPWA networks, a static context may be stored on the
   End-System (ES).  The other end, the LPWA Compressor (LC) can learn
   the context through a provisionning protocol during the
   identification phase. phase (for instance, as it learns the encryption key).

   The context contains an ordered lists list of rules.  Each rule is a vector
   of entries.  Each entry is composed of a field descriptor, a
   prescribed matching value, a matching rule for the compression side,
   a matching rule for the decompression side and a compression/
   decompression action.  Contexts in the compressor and decompressor
   are the same.  A rule is identified by a value, also called context rule identifier.  If the
   layer 2 allows it, the context rule id can be carried in the layer 2 header.
   Otherwise the context rule id is located in the first byte of the L2 payload.

   Being at the boundary between Layer 2 and Layer 3, the context rule id is will
   also be called a SHIM. shim id.  Different ES will use the same SHIM shim id to
   identify their own context.  An LC needs may also use the ES MAC address device id to
   identify the appropriate context in its memory. rule.

            +---------------------------------------------------------------------+
            |                      Rule N                                         |
       +---------------------------------------------------------------------+    |
       |                    Rule i                                           |    |
+---------------------------------------------------------------------+      |    |
|                    Rule 1                                           |      |    |
|   +---------+-------+------------+--------------+-----------------+ |      |    |
|   | Field 1 | Value |match. comp.| match decomp | Action function | |      |    |
|   +---------+-------+------------+--------------+-----------------+ |      |    |
|   | Field 2 | Value |match. comp.| match decomp | Action function | |      |    |
|   +---------+-------+------------+--------------+-----------------+ |      |    |
|   | ...     | ...   |...         | ...          | ...             | |      |    |
|   +---------+-------+------------+--------------+-----------------+ |      |----+
|   | Field N | Value |match. comp.| match decomp | Action function | |      |
|   +---------+-------+------------+--------------+-----------------+ |------+
|                                                                     |
+---------------------------------------------------------------------+

                          Figure 2: Context rules in LC

   The compression/decompression process follows several steps:

   o  compression rule selection: the goal is to identify which rule
      will be used for several purposes:

   o  Flow compression: context rules contain to compress the headers.  To each field is associated
      a high-level description
      of matching rule for compression.  Each header field's value is
      compared to the corresponding value stored in the rule for that
      field using the matching operator.  If all the headers' fields match, the
      packet is processed using this rule action functions and associate a function to each of them. the rule
      list exploration is aborted.  Otherwise the next rule is tested.
      If no rule is found, then the packet is dropped.

   o  Flow decompression:  compression: the action function associated to each field indicates is the field is send on
      the link or not.  A field can also be partially sent regarding the decompression behavior.

   o  Uncompressed flow selection:
      matching operator.  The information stored in the context resulting compressed header must be
      aligned on byte boundaries.

   o  decompression rule is also used selection, as for compression, a rule has to match incoming packets be
      selected to check if uncompress incoming packets.  A matching operator is
      defined on the
      compression rule compress header and works as for compression.

   o  decompression: the same action function indicates how the field
      value can be applied.  There is rebuilt, either from bits received on the link, a strong relation
      between filtering and decompression.  For instance,
      value stored in the rule or by using a flow may be
      defined as specific algorithm.

3.  Matching operators

   Matching a set of values that correspond to field with a set of fields.
      This flow is identified by value and header compression are related
   operations; If a SHIM.  A destination sharing field matches a rule containing the same value, it is not
   necessary to send it on the link.  Since context are synchronized,
   reading the rule's value is able enough to reconstruct the original header upon reception
      of a given SHIM.

   o  Compressed flow selection: when receiving a compressed packet,
      information in field's value
   at the context (typically other end.

   On some other cases, the SHIM) will value need to be sent on the link to inform
   the other end.  The field value may vary from one packet to another,
   therefore the field cannot be used to select the decompression rule in combination with id.

   It may exist some intermediary cases, where part of the ES MAC
      address.

   o  Packet filtering: LPWA can value may be easily subject
   used to DoS attacks.  If select a
      packet field and a variable part has to be sent on the
   link.  This is not explicitly assigned true for Least Significant Bits (LSB) where the most
   significant bit can be used to select a specific context, then
      incoming packets will rule id and the least
   significant bits has to be discarded.

3.  Filtering functions

   The compression/decompression mechanisms proposed sent on the link.

   Several matching operators are defined:

   o  = : a field value in this Figure 2 a packet matches with a field value in a rule
      if they are equal.

   o  no : no check is done between a field value in a packet matches
      with a combinaison field value in the rule

   o  lbs(L) : a field value of 6LoWPAN principles, which are efficient length T in sending
   only information what cannot be reconstructed at a packet matches with a
      field value in a rule if the most significant T-L bits are equal.

4.  Action functions

   The action functions describe the action taken by the other end, and
   RoHCv2 which assigns compression and decompression functions
   inversely the action taken by the decompressor to each
   field.  The use of a context avoids sending well-known information.

/--------------------+-----+-----+-------------+--------------------------\ restore the
   original value.

   /--------------------+-------------+--------------------------\
   | Function           |Selec|Selec|           | Compression | Decompression            |
   |                    |comp |dec.                    |             |                          |
+--------------------+-----+-----+-------------+--------------------------+
|ignore              |no   |no
   +--------------------+-------------+--------------------------+
   |elided       |add              |not sent     |use value stored in ctxt  |
   |send-value          |no   |no          |send value         |build field from value    |
|send-value-lbs      |yes  |no   |send lsb     |concatenation ctxt val+lsb|
|send-value-filter   |no   |yes  |send value   |elided                    |
|not-sent            |yes  |no   |elided       |add value stored in ctxt  |
|just-check          |yes  |yes  |nothing      |nothing                   |
   |compute-IPv6-length |no   |no |elided       |compute IPv6 length       |
   |compute-UDP-length  |no   |no  |elided       |compute UDP length        |
|compute-UDP-checksum|no   |no   |elided
   |compute-UDP-checksum|elided       |compute UDP checksum      |
|ESiid-MAC           |no   |no
   |ESiid-DID           |elided       |build IID from L2 ES addr |
|LAiid-MAC           |no   |no
   |LCiid-DID           |elided       |build IID from L2 LA addr |
\--------------------+-----+-----+-------------+--------------------------/
   \--------------------+-------------+--------------------------/

              Figure 2: 3: Simplified Protocol Stack for LP-WAN

   Figure 2 3 lists all the functions defined to compress and decompress a
   field.  The first column gives the function's name.  The second column describes the rule selection property of the
   function.  Selection determines if the compression rule can be
   applied to a packet.  A comparison is made between the value stored
   in the context and the field's value.  Generally it is an equality
   between the field value and a associated context value, but functions
   may define more complex matching rules.  To succeed and apply the
   compression/decompression rule, the comparisons of all header fields
   marked as "yes" in this column must be true.

   The
   third column indicates which function can be used to select the
   appropriate rules for decompression.  Typically it will be the SHIM
   and the MAC address.

   Fourth column outlines the compression process.

   Last column columns outlines the decompression compression/decompression process.

   As with 6LoWPAN, the compression process may produce some data, where
   fields that were not compressed (or were partially compressed) will
   be sent in the order order of the original packet.  Information added by
   the compression phase must be aligned on byte boundaries, but each
   individual compression function may generate any size.

/--------------------+---------------------+----------------------------------------\

/-----------------+---------------------+----------------------------------------\
| Field           |Function             | Behavior                               |
+--------------------+---------------------+----------------------------------------+
+-----------------+---------------------+----------------------------------------+
|IPv6 version        |ignore               |No IPv4: not sent, not used for select  |
|                    |send-value-filter*   |With IPv4: sent value, used for select  |
+--------------------+---------------------+----------------------------------------+
|IPv6 DiffServ       |not-sent*     |elided               |The value is not sent, but each end     |
|IPv6 Flow Label DiffServ    |                     |agree                     |agrees on a value, which can be someting |         |
|IPv6 Flow Label  |                     |different from 0.                       |
|
|IPv6 Next Header |send-value           |If DiffServ           |Depending on the matching operator, the |
|                 |                     |entire field varies it value is sent or an        |
|
+--------------------+---------------------+----------------------------------------+                 |                     |adjustment to the context value         |
+-----------------+---------------------+----------------------------------------+
|IPv6 Length      |compute-IPv6-length  |Dedicated function to reconstruct value |
+--------------------+---------------------+----------------------------------------+
[IPv6 Next Header    |not-sent*            |Value is known in the ctxt.             |
|                    |send value           |Same behavior as 6LoWPAN                |
+--------------------+---------------------+----------------------------------------+
+-----------------+---------------------+----------------------------------------+
|IPv6 Hop Limit      |ignore   |elided+no matching   |The receiver will put a value stored in |
|                 |                     |the context. It may be different from   |
|                 |                     |one originally sent, but in s a star      |
|                 |                     |topology, there is not risk of loops    |
|                    |not-sent*                 |elided+matching      |Receiver and sender agree on the value. |
|                 |                     |If the value is not correct the packet  |
|                 |                     |is discarded                     |the rule is not selected                |
|                 |send-value           |Explicitly sent                         |
+--------------------+---------------------+----------------------------------------+
+-----------------+---------------------+----------------------------------------+
|IPv6 ESPrefix       |not-sent*    |elided               |The 64 bit prefix is stored on the ctxt |
|IPv6 LCPrefix    |send-value           |Explicitly send 64 bits on the link     |
+--------------------+---------------------+----------------------------------------+
+-----------------+---------------------+----------------------------------------+
|IPv6 ESiid          |not-sent       |elided               |IID is not sent, but stored in the ctxt |
|IPv6 LCiid          |ESiid-MAC       |ESiid-DID | LCiid-MAC|IID LCiid-DID|IID is built from the ES MAC address Device ID      |
|                    |send-value*                 |send-value           |IID is explicitly sent on the link. The |
|                 |                     |size depends of the L2 technology       |
+--------------------+---------------------+----------------------------------------+
+-----------------+---------------------+----------------------------------------+
|UDP ESport          |not-sent       |elided               |In the context                          |
|UDP LCport          |send-value*       |send-value           |Send the 2 bytes of the port number     |
|                    |send-value-lsb*      |Send least significant bits of the port                 |                     |or less if lsb matching is specified in |
|                     |number.                 |
+--------------------+---------------------+----------------------------------------+                     |the matching operator.                  |
+-----------------+---------------------+----------------------------------------+
|UDP length       |compute-UDP-length   |Dedicated function to reconstruct value |
+-----------------+---------------------+----------------------------------------+
|UDP Checksum     |compute-UDP-checksum |Dedicated function to reconstruct value |
+--------------------+---------------------+----------------------------------------+
  * field used for rule selection.
+-----------------+---------------------+----------------------------------------+

       Figure 3: 4: SCHC functions' example assignment for IPv6 and UDP

   Figure 3 4 gives an example of function assignment to IPv6/UDP fields,
   a star after the function name indicates when a field participates in
   the context id selection.

3.1.  Compression fields.

4.1.  Action functions

3.1.1.  Ignore

   Ignore function defines a field that does not participate to the rule
   selection process.
4.1.1.  Elided

   The field value will compressor do not be sent on the wire and
   can be reconstructed on the other side.

   The ignore function can be assigned to the IPv6 version field (if
   IPv4 is not used in the system).  IPv6 Hop Limit may also be a
   candidate in some cases.  Hop Limit value will not affect the flow
   selection process.  The receiver may assign a static value.  If there
   is a risk of loop creation (i.e. non-star topology), the send-value
   function must be used instead.

3.1.2.  Send-value

   This function is used to transmit the full field value that is not
   stored in the context.  In the decompression phase, the receiver uses
   the transmitted value for reconstructing the field.  This field
   cannot participate to the selection process since it can vary other
   the time.

   The send-value function may be used to send interface IID in a meshed
   topology.

3.1.3.  Send-value-lsb

   This function allows to send only the less significant bits of a
   value.  The context contains the size of the less significant bits
   and a reference value.

   Send-value-lbs is involved in the rule selection.  The most
   significant bit of field's value must matches the most significant
   bits of the context reference value.

   The sender send on the radio link only the less significant bits.
   The receiver reconstruct the initial value by concatenating the most
   significant bits of reference value contained in the context and the
   less significant bits received.

   This function can be used to define a port range and allow several IP
   flows to share the same context.

3.1.4.  Send-value-filter

   In the compression phase, a field assigned with this value is sent on the radio link.  It does not influence the rule selection.

   Value sent on the link influences the rule selection for
   decompression.

   Typically, this function is used to transmit the SHIM field and
   proceed to rule identification when the header is decompressed.  The
   SHIM is elided from the uncompressed header.

3.1.5.  Not-sent

   In
   decompressor restore the compression phase, a field assigned with this value is not
   sent on the radio link.  This influence the rule selection.

   In the decompression phase, the uncompressed value is with the one stored in the context.  Since
   matched rule.

4.1.2.  Send-value

   The compressor send the field value is not send on the radio link, it
   cannot influence the flow selection.

   IPv6 protocol identifier, UDP ports number fields can be assigned to
   this function.  This avoid to send then on if the link.

3.1.6.  just-check

   The field value matching
   operator is checked for "=".  Otherwise the rule selection, but nothing is
   sent on matching operator indicates the radio link.

   This can
   information that will be used to include L2 parameters such as addresses in the
   rule selection.

3.1.7.  compute-IPv6-lenght, compute-UDP-length, compute-UDP-checksum

   Fields assigned with this functions are not sent on the radio link,
   they do not participate to the rule selection process.  They are
   computed during the decompression phase.

   This functions are specific to link.  For a field in LSB operator only
   the header.

3.1.8.  ESiid-MAC, LCiid-MAC Least Significant Bits are sent.

4.1.3.  ESiid-DID, LCiid-DID

   These functions are used to process respectively the End System and
   the LPWA AP Interface Identifier. LC Device Identifier (DID).  The IID value is computed from
   addresses
   device ID present in the MAC Layer 2 header.  The computation depends of
   the technology and the MAC address device ID size.  The values of the field do not
   participate to the flow selection since they are sent on the radio
   link at layer 2.

   These functions can be used in case of the star topology.

4.

5.  Examples

   This section gives some scenarios of the compression mechanism.  Note
   that mechanism for reasons of simplicity in this example CoAP is not
   compressed, it will be described later with the same principles.
   IPv6/UDP.  The goal is to illustrate the SCHC behaviour.

4.1.

5.1.  IPv6/UDP compression in a star topology

   The most common case will be a LPWA end-system embeds some
   applications running over CoAP.  Typically one will be  In this example, the first flow is
   for instance for the device management based on CoAP using the COMI/CoOL protocol (using Link Local
   addresses and UDP ports 123 and
   124). 124.  The second one flow will be a CoAP
   server for measurements done by the end-system (using ports 5683).  A third UDP traffic 5683) and
   Global Addresses alpha::IID/64 to beta::1/64.  The last flow is for
   legacy applications using different ports numbers. numbers, the destination is
   gamma::1/64.

   Figure 4 5 presents the protocol stack for this end-system.  IPv6 and
   UDP are represented with dotted lines since these protocols are
   compressed on the radio link.  The context rule ID is represented by a SHIM shim
   id (respectively 0, 1 and 2).

   |
   |/c  |/a   |

    Managment    Data
   +----------+---------+---------+
   |   CoAP   |  CoAP   | legacy  |
   +----||----+---||----+---||----+
   .   UDP    .  UDP    |   UDP   |
   ................................
   .   IPv6   .  IPv6   .  IPv6   .
   +--SHIM0------SHIM1-----SHIM2---------------------------+
   +--SHIM0------SHIM1-----SHIM2--+
   |      6LPWA L2 technologies   |
   +-------------------------------------------------------+
   +------------------------------+
         End System or LPWA GW

              Figure 4: 5: Simplified Protocol Stack for LP-WAN

   Note that in some LPWA technologies, only End Systems have a MAC
   address. device
   ID . Therefore it is necessary to define statically an IID for the
   Link Local address for the LPWA Compressor.

  +----------------+------------------------+----------------+-----------------+

   +----------------+---------+--------+--------+-------------++------+
   | Field          |   Function             | Ctxt Value   | Sent compressed Match  |
  +----------------+------------------------+----------------+-----------------+ Match  | LPWA Function    || Sent |
   +----------------+---------+-----------------+-------------++------+
   |LPWA SHIM       |0        | send-value-filter No     | 0 =      | send-value  || 0    |
  +================+========================+================+=================+
   |ESDevice-ID     |dev-id   | No     | =      | elided      ||      |
   +================+=========+========+========+=============++======+
   |IPv6 version    |6        | ignore =      | No     | elided      ||      |
   |IPv6 DiffServ   |0        | not-sent =      | 0 No     | elided      ||      |
   |IPv6 Flow Label |0        | not-sent =      | 0 No     | elided      ||      |
   |IPv6 Length     |XXXXXXXXX| No     | No     | compute-IPv6-length    |----------------| comp-IPv6-l ||      |
   |IPv6 Next Header| not-sent Header|17       | 17 =      | No     | elided      ||      |
   |IPv6 Hop Limit  |255      | ignore No     | 1 No     | elided      ||      |
   |IPv6 ESprefix   |FE80::/64| =      | not-sent               | FE80::/64 No     | elided      ||      |
   |IPv6 ESiid      | ESiid-MAC         | No     | No     | ESiid-DID   ||      |
   |IPv6 LCprefix   |FE80::/64| =      | not-sent               | FE80::/64 No     | elided      ||      |
   |IPv6 LCiid      |::1      | LCiid-value =      | ::1 No     | elided      ||      |
  +================+========================+================+=================+
   +================+=========+========+========+=============++======+
   |UDP ESport      |123      | not-sent =      | 123 No     | elided      ||      |
   |UDP LCport      |124      | not-sent =      | 124 No     | elided      ||      |
   |UDP Length      |XXXXXXXXX| No     | No     | compute-UDP-length     |----------------| comp-UDP-l  ||      |
   |UDP checksum    |XXXXXXXXX| No     | compute-UDP-checksum   |----------------| No     |
  +================+========================+================+=================+

  +----------------+------------------------+----------------+-----------------+ comp-UDP-c  ||      | Field
   +================+=========+========+========+=============++======+

   +----------------+---------+--------+--------+-------------++------+
   |   Function Field          | Ctxt Value   | Sent compressed Match  |
  +----------------+------------------------+----------------+-----------------+ Match  | LPWA Function    || Sent |
   +----------------+---------+-----------------+-------------++------+
   |LPWA SHIM       |1        | send-value-filter No     | 1 =      | send-value  || 1    |
  +================+========================+================+=================+
   |ESDevice-ID     |dev-id   | No     | =      | elided      ||      |
   +================+=========+========+========+=============++======+
   |IPv6 version    |6        | ignore =      | No     | elided      ||      |
   |IPv6 DiffServ   |0        | not-sent =      | 0 No     | elided      ||      |
   |IPv6 Flow Label |0        | not-sent =      | 0 No     | elided      ||      |
   |IPv6 Length     |XXXXXXXXX| No     | compute-IPv6-length    |----------------| No     | comp-IPv6-l ||      |
   |IPv6 Next Header| not-sent Header|17       | =      | 17 No     | elided      ||      |
   |IPv6 Hop Limit  |255      | ignore No     | 1 No     | elided      ||      |
   |IPv6 ESprefix   |alpha/64 | not-sent =      | FE80::/64 No     | elided      ||      |
   |IPv6 ESiid      | ESiid-MAC         | No     | No     | ESiid-DID   ||      |
   |IPv6 LCprefix   |beta/64  | not-sent =      | FE80::/64 No     | elided      ||      |
   |IPv6 LCiid      |::1000   | LCiid-value =      | ::1 No     | elided      ||      |
  +================+========================+================+=================+
   +================+=========+========+========+=============++======+
   |UDP ESport      |5683     | not-sent =      | 5683 No     | elided      ||      |
   |UDP LCport      |5683     | not-sent =      | 5683 No     | elided      ||      |
   |UDP Length      |XXXXXXXXX| No     | No     | compute-UDP-length     |----------------| comp-UDP-l  ||      |
   |UDP checksum    |XXXXXXXXX| No     | compute-UDP-checksum   |----------------| No     |
  +================+========================+================+=================+

  +----------------+------------------------+----------------+-----------------+ comp-UDP-c  ||      | Field
   +================+=========+========+========+=============++======+

    +----------------+---------+--------+--------+-------------++------+
   |   Function Field          | Ctxt Value   | Sent compressed Match  |
  +----------------+------------------------+----------------+-----------------+ Match  | LPWA Function    || Sent |
   +----------------+---------+-----------------+-------------++------+
   |LPWA SHIM       |2        | send-value-filter No     | 2 =      | send-value  || 2    |
  +================+========================+================+=================+
   |ESDevice-ID     |dev-id   | No     | =      | elided      ||      |
   +================+=========+========+========+=============++======+
   |IPv6 version    |6        | ignore =      | No     | elided      ||      |
   |IPv6 DiffServ   |0        | not-sent =      | 0 No     | elided      ||      |
   |IPv6 Flow Label |0        | not-sent =      | 0 No     | elided      ||      |
   |IPv6 Length     |XXXXXXXXX| No     | No     | compute-IPv6-length    |----------------| comp-IPv6-l ||      |
   |IPv6 Next Header| not-sent Header|17       | 17 =      | No     | elided      ||      |
   |IPv6 Hop Limit  |255      | ignore No     | 1 No     | elided      ||      |
   |IPv6 ESprefix   |alpha/64 | not-sent =      | FE80::/64 No     | elided      ||      |
   |IPv6 ESiid      | ESiid-MAC         | No     | No     | ESiid-DID   ||      |
   |IPv6 LCprefix   |gamma/64 | not-sent =      | FE80::/64 No     | elided      ||      |
   |IPv6 LCiid      |::1000   | LCiid-value =      | ::1 No     | elided      ||      |
  +================+========================+================+=================+
   +================+=========+========+========+=============++======+
   |UDP ESport      |8720     | send-value lsb(4) | No     | port number elided      || lsb  |
   |UDP LCport      |8720     | send-value lsb(4) | No     | port number elided      || lsb  |
   |UDP Length      |XXXXXXXXX| No     | compute-UDP-length     |----------------| No     | comp-UDP-l  ||      |
   |UDP checksum    |XXXXXXXXX| No     | No     | compute-UDP-checksum   |----------------| comp-UDP-c  ||      |
  +================+========================+================+=================+
   +================+=========+========+========+=============++======+

              Figure 5: 6: Simplified Protocol Stack for LP-WAN

   All the fields described in the three rules Figure 6 shows an alternative way to compress more efficiently port
   numbers.  The send-value-lsb allows to send are present in one byte
   the two ports
   number differences.  Since the compressed information must be aligned
   on byte boundary, it has IPv6 and UDP headers.  Two fields have been chosen in added at the example a size of 4 bits begin,
   they are used to identify the rule id for each lsb.

  +----------------+------------------------+----------------+-----------------+
  | Field          |   Function             | Ctxt Value     | Sent decompression when the
   other end receives the compressed |
  +----------------+------------------------+----------------+-----------------+
  | LPWA SHIM      | send-value-filter      | 2              | 2               |
  +================+========================+================+=================+
  |IPv6 version    | ignore                 |                |                 |
  |IPv6 DiffServ   | not-sent               | 0              |                 |
  |IPv6 Flow Label | not-sent               | 0              |                 |
  |IPv6 Length     | compute-IPv6-length    |----------------|                 |
  |IPv6 Next Header| not-sent               | 17             |                 |
  |IPv6 Hop Limit  | ignore                 | 1              |                 |
  |IPv6 ESprefix   | not-sent               | FE80::/64      |                 |
  |IPv6 ESiid      | ESiid-MAC              |                |                 |
  |IPv6 LCprefix   | not-sent               | FE80::/64      |                 |
  |IPv6 LCiid      | LCiid-value            | ::1            |                 |
  +================+========================+================+=================+
  |UDP ESport      | send-value-lsb         | 4+ES ref val   | lsb             |
  |UDP LCport      | send-value-lsb         | 4+LC ref val   | lsb             |
  |UDP Length      | compute-UDP-length     |----------------|                 |
  |UDP checksum    | compute-UDP-checksum   |----------------|                 |
  +================+========================+================+=================+

            Figure 6: Alternative compressions of port numbers

4.2.  Global addresses header.  The scenario depicted Figure 7, management remains with Link Local
   addresses, but shim id is read either
   from the CoAP message are sent to an external server
   2001:db8:1::1 and L2 header or from the legacy to another server 2001:db8:2::1/64. first bit in the payload depending on
   the technology.  The
   EC must be configured with ESDevice-ID value is found in the L2 header.

   The second and third rules use global addresses.  The way the ES
   learn the prefix used by is not in the LC scope of the document.  One possible
   way is to forward
   traffic.  This prefix could be changed using use a management procedure
   if needed.

  +----------------+------------------------+----------------+-----------------+
  | Field          |   Function             | Ctxt Value     | Sent compressed |
  +----------------+------------------------+----------------+-----------------+
  | LPWA SHIM      | send-value-filter      | 0              | 0               |
  +================+========================+================+=================+
  |IPv6 version    | ignore                 |                |                 |
  |IPv6 DiffServ   | not-sent               | 0              |                 |
  |IPv6 Flow Label | not-sent               | 0              |                 |
  |IPv6 Length     | compute-IPv6-length    |----------------|                 |
  |IPv6 Next Header| not-sent               | 17             |                 |
  |IPv6 Hop Limit  | ignore                 | 1              |                 |
  |IPv6 ESprefix   | not-sent               | FE80::/64      |                 |
  |IPv6 ESiid      | ESiid-MAC              |                |                 |
  |IPv6 LCprefix   | not-sent               | FE80::/64      |                 |
  |IPv6 LCiid      | LCiid-value            | ::1            |                 |
  +================+========================+================+=================+
  |UDP ESport      | not-sent               | 123            |                 |
  |UDP LCport      | not-sent               | 124            |                 |
  |UDP Length      | compute-UDP-length     |----------------|                 |
  |UDP checksum    | compute-UDP-checksum   |----------------|                 |
  +================+========================+================+=================+

  +----------------+------------------------+----------------+-----------------+
  | Field          |   Function             | Ctxt Value     | Sent compressed |
  +----------------+------------------------+----------------+-----------------+
  | LPWA SHIM      | send-value-filter      | 1              | 1               |
  +================+========================+================+=================+
  |IPv6 version    | ignore                 |                |                 |
  |IPv6 DiffServ   | not-sent               | 0              |                 |
  |IPv6 Flow Label | not-sent               | 0              |                 |
  |IPv6 Length     | compute-IPv6-length    |----------------|                 |
  |IPv6 Next Header| not-sent               | 17             |                 |
  |IPv6 Hop Limit  | ignore                 | 1              |                 |
  |IPv6 ESprefix   | not-sent               |2001:db8:3::/64 |                 |
  |IPv6 ESiid      | ESiid-MAC              |                |                 |
  |IPv6 LCprefix   | not-sent               |2001:bd8:1::/64 |                 |
  |IPv6 LCiid      | LCiid-value            | ::1            |                 |
  +================+========================+================+=================+
  |UDP ESport      | not-sent               | 5683           |                 |
  |UDP LCport      | not-sent               | 5683           |                 |
  |UDP Length      | compute-UDP-length     |----------------|                 |
  |UDP checksum    | compute-UDP-checksum   |----------------|                 |
  +================+========================+================+=================+

  +----------------+------------------------+----------------+-----------------+
  | Field          |   Function             | Ctxt Value     | Sent compressed |
  +----------------+------------------------+----------------+-----------------+
  | protocol to set up in both end rules the
   prefix used on the LPWA SHIM      | send-value-filter      | 2              | 2               |
  +================+========================+================+=================+
  |IPv6 version    | ignore                 |                |                 |
  |IPv6 DiffServ   | not-sent               | 0              |                 |
  |IPv6 Flow Label | not-sent               | 0              |                 |
  |IPv6 Length     | compute-IPv6-length    |----------------|                 |
  |IPv6 Next Header| not-sent               | 17             |                 |
  |IPv6 Hop Limit  | ignore                 | 1              |                 |
  |IPv6 ESprefix   | not-sent               |2001:db8:3::/64 |                 |
  |IPv6 ESiid      | ESiid-MAC              |                |                 |
  |IPv6 LCprefix   | not-sent               |2001:db8:2::/64 |                 |
  |IPv6 LCiid      | LCiid-value            | ::1            |                 |
  +================+========================+================+=================+
  |UDP ESport      | send-value             |                | port number     |
  |UDP LCport      | send-value             |                | network.

   The third rule compresses port number     |
  |UDP Length      | compute-UDP-length     |----------------|                 |
  |UDP checksum    | compute-UDP-checksum   |----------------|                 |
  +================+========================+================+=================+

                Figure 7: Compression with global addresses

5.  CoAP compression

   TBD numbers on 4 bits.  This value is
   selected to maintain alignment on byte boundaries for the compressed
   header.

6.  Acknowledgements

   Thanks to Dominique Barthel, Alexander Pelov, Juan Carlos Zuniga for
   useful design consideration.

7.  Normative References

   [I-D.minaburo-lp-wan-gap-analysis]
              Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP
              Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in
              progress), February 2016.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <http://www.rfc-editor.org/info/rfc4944>.

   [RFC4997]  Finking, R. and G. Pelletier, "Formal Notation for RObust
              Header Compression (ROHC-FN)", RFC 4997,
              DOI 10.17487/RFC4997, July 2007,
              <http://www.rfc-editor.org/info/rfc4997>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <http://www.rfc-editor.org/info/rfc6282>.

Authors' Addresses

   Ana Minaburo
   Acklio
   2bis rue de la Chataigneraie
   35510 Cesson-Sevigne Cedex
   France

   Email: ana@ackl.io
   Laurent Toutain
   Institut MINES TELECOM ; TELECOM Bretagne
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   France

   Email: Laurent.Toutain@telecom-bretagne.eu