6LPWA Static Context Header Compression (SCHC) for IPV6 and UDP
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 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 headers are reduced to a small 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 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

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

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

Figure 1: RoHC Compressed Header size evolution.

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

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 describes how the header should be decompressed, either using some standard values or sending information 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 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 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 (for instance, as it learns the encryption key).

The context contains an ordered 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 rule identifier. If the layer 2 allows it, the rule id can be carried in the layer 2 header. Otherwise the rule id is located in the first byte of the L2 payload.

            
            
            +---------------------------------------------------------------------+
            |                      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 in LC

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

The compression/decompression process follows several steps:

compression rule selection: the goal is to identify which rule will be used to compress the headers. To each field is associated a 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 fields match, the packet is processed using this rule action functions and the rule list exploration is aborted. Otherwise the next rule is tested. If no rule is found, then the packet is dropped.
compression: the action function indicates is the field is send on the link or not. A field can also be partially sent regarding the matching operator. The resulting compressed header must be aligned on byte boundaries.
decompression rule selection, as for compression, a rule has to be selected to uncompress incoming packets. A matching operator is defined on the compress header and works as for compression.
decompression: the same action function indicates how the field value can be rebuilt, either from bits received on the link, a value stored in the rule or by using a specific algorithm.

3. Matching operators

Matching a field with a value and header compression are related operations; If a field matches a rule containing the value, it is not necessary to send it on the link. Since context are synchronized, reading the rule's value is enough to reconstruct the field's value at the other end.

On some other cases, the 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 rule id.

It may exist some intermediary cases, where part of the value may be used to select a field and a variable part has to be sent on the link. This is true for Least Significant Bits (LSB) where the most significant bit can be used to select a rule id and the least significant bits has to be sent on the link.

Several matching operators are defined:

= : a field value in a packet matches with a field value in a rule if they are equal.
no : no check is done between a field value in a packet matches with a field value in the rule
lbs(L) : a field value of length T in a packet matches with a field value in a rule if the most significant T-L bits are equal.

4. Action functions

/--------------------+-------------+--------------------------\
| Function           | Compression | Decompression            | 
|                    |             |                          | 
+--------------------+-------------+--------------------------+
|elided              |not sent     |use value stored in ctxt  |
|send-value          |send         |build field from value    |
|compute-IPv6-length |elided       |compute IPv6 length       |
|compute-UDP-length  |elided       |compute UDP length        |
|compute-UDP-checksum|elided       |compute UDP checksum      |
|ESiid-DID           |elided       |build IID from L2 ES addr |
|LCiid-DID           |elided       |build IID from L2 LA addr |
\--------------------+-------------+--------------------------/

Figure 3: Simplified Protocol Stack for LP-WAN

The action functions describe the action taken by the compression and inversely the action taken by the decompressor to restore the original value. Figure 3 lists all the functions defined to compress and decompress a field. The first column gives the function's name. The second and third columns outlines the 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 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     |elided               |The value is not sent, but each end     |
|IPv6 DiffServ    |                     |agrees on a value, which can be         | 
|IPv6 Flow Label  |                     |different from 0.                       |
|IPv6 Next Header |send-value           |Depending on the matching operator, the |
|                 |                     |entire field value is sent or an        |
|                 |                     |adjustment to the context value         |            
+-----------------+---------------------+----------------------------------------+ 
|IPv6 Length      |compute-IPv6-length  |Dedicated function to reconstruct value |
+-----------------+---------------------+----------------------------------------+
|IPv6 Hop Limit   |elided+no matching   |The receiver will put a value stored in |
|                 |                     |the context. It may be different from   |
|                 |                     |one originally sent, but in a star      |
|                 |                     |topology, there is not risk of loops    |
|                 |elided+matching      |Receiver and sender agree on the value. |
|                 |                     |If the value is not correct the packet  |
|                 |                     |the rule is not selected                |
|                 |send-value           |Explicitly sent                         |
+-----------------+---------------------+----------------------------------------+ 
|IPv6 ESPrefix    |elided               |The 64 bit prefix is stored on the ctxt |
|IPv6 LCPrefix    |send-value           |Explicitly send 64 bits on the link     |
+-----------------+---------------------+----------------------------------------+
|IPv6 ESiid       |elided               |IID is not sent, but stored in the ctxt |
|IPv6 LCiid       |ESiid-DID | LCiid-DID|IID is built from the ES Device ID      |
|                 |send-value           |IID is explicitly sent on the link. The |
|                 |                     |size depends of the L2 technology       |
+-----------------+---------------------+----------------------------------------+
|UDP ESport       |elided               |In the context                          |
|UDP LCport       |send-value           |Send the 2 bytes of the port number     |    
|                 |                     |or less if lsb matching is specified in |
|                 |                     |the matching operator.                  |   
+-----------------+---------------------+----------------------------------------+ 
|UDP length       |compute-UDP-length   |Dedicated function to reconstruct value |
+-----------------+---------------------+----------------------------------------+ 
|UDP Checksum     |compute-UDP-checksum |Dedicated function to reconstruct value |
+-----------------+---------------------+----------------------------------------+

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

Figure 4 gives an example of function assignment to IPv6/UDP fields.

4.1. Action functions

4.1.1. Elided

The compressor do not sent the field value on the link. The decompressor restore the field value with the one stored in the matched rule.

4.1.2. Send-value

The compressor send the field value on the link, if the matching operator is "=". Otherwise the matching operator indicates the information that will be sent on the link. For a LSB operator only the Least Significant Bits are sent.

4.1.3. ESiid-DID, LCiid-DID

These functions are used to process respectively the End System and the LC Device Identifier (DID). The IID value is computed from device ID present in the Layer 2 header. The computation depends of the technology and the device ID size.

5. Examples

This section gives some scenarios of the compression mechanism for IPv6/UDP. The goal is to illustrate the SCHC behaviour.

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. In this example, the first flow is for instance for the device management based on CoAP using Link Local addresses and UDP ports 123 and 124. The second flow will be a CoAP server for measurements done by the end-system (using ports 5683) and Global Addresses alpha::IID/64 to beta::1/64. The last flow is for legacy applications using different ports numbers, the destination is gamma::1/64.


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

Figure 5: Simplified Protocol Stack for LP-WAN

Figure 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 rule ID is represented by a shim id (respectively 0, 1 and 2).

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

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

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

Figure 6: Simplified Protocol Stack for LP-WAN

Figure 6 are present in the IPv6 and UDP headers. Two fields have been added at the begin, they are used to identify the rule id for decompression when the other end receives the compressed header. The shim id is read either from the L2 header or from the first bit in the payload depending on the technology. The ESDevice-ID value is found in the L2 header.

The second and third rules use global addresses. The way the ES learn the prefix is not in the scope of the document. One possible way is to use a management protocol to set up in both end rules the prefix used on the LPWA network.

The third rule compresses port 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", Internet-Draft draft-minaburo-lp-wan-gap-analysis-01, 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.
[RFC4997]	Finking, R. and G. Pelletier, "Formal Notation for RObust Header Compression (ROHC-FN)", RFC 4997, DOI 10.17487/RFC4997, July 2007.
[RFC6282]	Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011.

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