LPWAN Static Context Header Compression (SCHC) for CoAP
draft-ietf-lpwan-coap-static-context-hc-01

Abstract

This draft discusses the way SCHC header compression can be applied to CoAP headers in an LPWAN flow regarding the generated traffic. CoAP protocol differs from IPv6 and UDP protocols because the CoAP Header has a flexible header due to variable options. Another important difference is the asymmetric format in the header information used in the request and the response packets. This draft shows that the Client and the Server do not uses the same fields and how the SCHC header compression can be used.

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 September 11, 2017.

Copyright Notice

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

[I-D.toutain-lpwan-ipv6-static-context-hc] defines a header compression mechanism for LPWAN network based on a static context. Where the context is said static since the element values composing the context are not learned during the packet exchanges but are previously defined. The context(s) is(are) known by both ends before transmission.

A context is composed of a set of rules (contexts) that are referenced by Rule IDs (identifiers). A rule describes the header fields with some associated Target Values (TV). A Matching Operator (MO) is associated to each header field description. The rule is selected if all the MOs fit the TVs. In that case, a Compression Decompression Function (CDF) associated to each field defines the link between the compressed and decompressed value for each of the header fields.

This draft discusses the way SCHC can be applied to CoAP headers, how to extend MOs to match a specific element when several fields of the same type are presented in the header. It also introduces the notion of bidirectional or unidirectional (upstream and downstream) fields.

2. CoAP Compressing

CoAP [RFC7252] is an implementation of the REST architecture for constrained devices. Gateway between CoAP and HTTP can be easily built since both protocols uses the same address space (URL), caching mechanisms and methods.

Nevertheless, if limited, the size of a CoAP header may be too large for LPWAN constraints and some compression may be needed to reduce the header size. CoAP compression is not straightforward. Some differences between IPv6/UDP and CoAP can be highlighted. CoAP differs from IPv6 and UDP protocols in the following
aspects:

• IPv6 and UDP are symmetrical protocols. The same fields are found in the request and in the response, only position in the header may change (e.g. source and destination fields). A CoAP request is different from an response. For example, the URI-path option is mandatory in the request and is not found in the response.
• CoAP also obeys to the client/server paradigm and the compression rate can be different if the request is issued from a LPWAN node or from an non LPWAN device. For instance a Thing (ES) aware of LPWAN constraints can generate a 1 byte token, but a regular CoAP cleint will certainly send a larger token to the Thing.
• In IPv6 and UDP header fields have a fixed size. In CoAP, Token size may vary from 0 to 8 bytes, length is given by a field in the header. More systematically, the CoAP options are described using the Type-Length-Value. When applying SCHC header compression, the token size is not known at the rule creation, the sender and the receiver must agree on its compressed size.
• The options type in CoAP is not defined with the same value. The Delta TLV coding makes that the type is not independent of previous option and may vary regarding the options contained in the header.

2.1. CoAP behavior

A LPWAN node can either be a client or a server and sometimes both. In the client mode, the LPWAN node sends request to a server and expects an answer or acknowledgements. Acknowledgements can be at 2 different levels:

• In the transport level, a CON message is acknowledged by an ACK message. A NON confirmable message is not acknowledged at all.
• In REST level, a REST request is acknowledged by an “error” code. The [RFC7967] defines an option to limit the number of acknowledgements.

Note that acknowledgement can be optimized and a REST level acknowledgement can be used as a transport level acknowledgement.

2.2. CoAP protocol analysis

CoAP header format defines the following fields:

• version (2 bits): this field can be elided during the SCHC compresssion
• type (2 bits). It defines the type of the transport messages, 4 values are defined, regarding the type of exchange. If only NON messages are sent or CON/ACK messages, this field can be reduced to 0 or 1 bit.
• token length (4 bits). The standard allows up to 8 bytes for a token. If a fixed token size is chosen, then this field can be elided. If some variation in length are needed then 1 or 2 bits could be enough for most of LPWAN applications.
• code (8 bits). This field codes the request and the response values. In CoAP these values are represented in a more compact way then the coding used in HTTP, but the coding is not optimal.
• message id (16 bits). This value of this header field is used to acknowledge CON frames. The size of this field is computed to allow the anticipation (how many frames can be sent without acknowledgement). When a value is used, the [RFC7252] defines the time before it can be reused without ambiguities. This size defined may be too large for a LPWAN node sending or receiving few messages a day.
• Token (0 to 8 bytes). Token header field is used to identify active flows. Regarding the usage for LPWAN (stability in time and limited number), a short token (1 Byte or less) can be enough.
• options are coded using delta-TLV. The delta-T depends on previous values, length is encoded inside the option. The [RFC7252] distinguishes repeatable options that can appear several times in the header. Among them we can distinguish:
  • list options which appear several time in the header but are exclusive such as the Accept option.
  • cumulative options which appear several times in the header but are part of a more generic value such as Uri-Path and Uri-Query. In that case, some elements may not change during the Thing lifetime and other may change at each request. For instance CoMi [I-D.ietf-core-comi] defines the following path /c/X6?k=”eth0”, where the first path element “c” does not change, the second element can vary over time with a different length (it represents the base64 enconding of a SID) and the query string can also vary over time.

  For a given flow some value options are stable through time. Observe, ETag, If-Match, If-None-Match and Size varies in each message.

The CoAP protocol must not be altered by the compression/decompression phase, but if no semantic is attributed to a value, it may be changed during this phase. For instance, the compression phase may reduce the size of a token but must maintain its unicity. The decompressor will not be able to restore the original value but the behavior will remain the same. If no special semantic is assigned to the token, this will be transparent. If a special semantic is assigned to the token, its compression may not be possible.

3. SCHC rules for CoAP header compression

This draft refines the rules definition by adding the direction of the message, from the Thing point of view (uplink, downlink or bidirectional). It does not introduce new Machting Operator or new Compression Decompression Function, but add some possibility to check one particular element when several of them are present at the same time.

A rule can contain CoAP and IPv6/UDP entries. In that case, IPv6/UDP entries are tagged bidirectional.

3.1. Directional Rules

By default, an entry in a rule is bidirectional which means that it can be applied either on the uplink or downlink headers. By specifying the direction, the LC will take into account the specific field only if the direction match.

If the Thing is a client, the URI-Path option is only present on request and not on the response. Therefore, the exact matching principle to select a rule cannot apply.

Some options are marked unidirectional, the value (uplink or downlink) depends of the scenario. A Uri-Path option will be marked uplink if the Thing acts as a client and downlink if the Thing acts as a server. If the Thing acts both as client and server, two different rules will be defined.

3.2. Matching Operator

The Matching Operator behavior has not changed, but the value must take a position value, if the entry is repeated :

      FID          TV      MO             CDF
      
      URI-Path     foo     equal 1      not-sent
      URI-Path     bar     equal 2      not-sent

      FID          TV      MO             CDF
      
      URI-Path     c       equal 1      not-sent
      URI-Path             ignore 2     value-sent
      URI-Query    k=      MSB (16, 1)  value-sent 
      

               +------+------------------------------+-----------+
               | Code | Description                  | Mapping   |
               +------+------------------------------+-----------+
               | 0.00 |                              |  0x00     |
               | 0.01 | GET                          |  0x01     |
               | 0.02 | POST                         |  0x02     |
               | 0.03 | PUT                          |  0x03     |
               | 0.04 | DELETE                       |  0x04     |
               | 0.05 | FETCH                        |  0x05     |
               | 0.06 | PATCH                        |  0x06     |
               | 0.07 | iPATCH                       |  0x07     |
               | 2.01 | Created                      |  0x08     |
               | 2.02 | Deleted                      |  0x09     |
               | 2.03 | Valid                        |  0x0A     |
               | 2.04 | Changed                      |  0x0B     |
               | 2.05 | Content                      |  0x0C     |
               | 4.00 | Bad Request                  |  0x0D     |
               | 4.01 | Unauthorized                 |  0x0E     |
               | 4.02 | Bad Option                   |  0x0F     |
               | 4.03 | Forbidden                    |  0x10     |
               | 4.04 | Not Found                    |  0x11     |
               | 4.05 | Method Not Allowed           |  0x12     |
               | 4.06 | Not Acceptable               |  0x13     |
               | 4.12 | Precondition Failed          |  0x14     |
               | 4.13 | Request Entity Too Large     |  0x15     |
               | 4.15 | Unsupported Content-Format   |  0x16     |
               | 5.00 | Internal Server Error        |  0x17     |
               | 5.01 | Not Implemented              |  0x18     |
               | 5.02 | Bad Gateway                  |  0x19     |
               | 5.03 | Service Unavailable          |  0x1A     |
               | 5.04 | Gateway Timeout              |  0x1B     |
               | 5.05 | Proxying Not Supported       |  0x1C     |
               +------+------------------------------+-----------+

      FID        TV              MO                   CDF
      
      URI-Path   {"/foo/bar":1,  match-mapping 1      mapping-sent
                  "/bar/foo":2}  
      URI-Path                   ignore 3             value-sent
      URI-Path     stable        equal 4              not-sent

 rule id 1
+-------------+------+---------+-------------+-----+----------------+
| Field       |TV    |MO       |CDF          |dir  | Sent           |
+=============+======+=========+=============+=====+================+
|CoAP version | 01   |equal    |not-sent     |bi   |                |
|CoAP Type    |      |ignore   |value-sent   |bi   |TT              |
|CoAP TKL     | 0    |equal    |not-sent     |bi   |                |
|CoAP Code    | ML1  |match-map|matching-sent|bi   |  CC CCC        |
|CoAP MID     | 0000 |MSB(7 )  |LSB(9)       |bi   |         M-ID   |
|CoAP Uri-Path| path |equal 1  |not-sent     |down |                |
+-------------+------+---------+-------------+-----+----------------+

                   End System               LPWA LC
                        |                     |
                        |        rule id=1    |<----------------------
                        |<--------------------| +-+-+--+----+--------+
  <-------------------- |  TTCC CCCM MMMM MMMM| |1|0| 4|0.01| 0x0034 |
 +-+-+--+----+--------+ |  0000 0010 0011 0100| |  0xb4   p    a   t |
 |1|0| 1|0.01| 0x0034 | |                     | |  h   |
 |  0xb4   p    a   t | |                     | +------+
 |  h   |               |                     |     
 +------+               |                     |   
                        |                     |    
                        |                     |    
----------------------->|       rule id=1     |
+-+-+--+----+--------+  |-------------------->|
|1|2| 0|2.05| 0x0034 |  |  TTCC CCCM MMMM MMMM|------------------------>
+-+-+--+----+--------+  |  1001 1000 0011 0100| +-+-+--+----+--------+
                        |                     | |1|2| 0|2.05| 0x0034 |
                        v                     v +-+-+--+----+--------+

 rule id 1
+-------------+------+---------+-------------+---+----------------+
| Field       |TV    |MO       |CDF          |dir| Sent           |
+=============+======+=========+=============+===+================+
|CoAP version | 01   |equal    |not-sent     |bi |                |
|CoAP Type    | CON  |equal    |not-sent     |dw |                |
|CoAP Type    | ACK  |equal    |not-sent     |up |                |
|CoAP TKL     | 0    |equal    |not-sent     |bi |                |
|CoAP Code    | ML2  |match-map|matching-sent|dw |CCCC C          |
|CoAP Code    | ML3  |match-map|matching-sent|up |CCCC C          |
|CoAP MID     | 0000 |MSB(5)   |LSB(11)      |bi |       M-ID     |
|CoAP Uri-Path| path |equal 1  |not-sent     |dw |                |
+-------------+------+---------+-------------+---+----------------+

ML1 = {CON : 0, ACK:1} ML2 = {POST:0, 2.04:1, 0.00:3}

  CON 
  MID=0x0012     |                         |
  POST           |                         |   
  Accept X       |                         | 
  /c/k=AS        |------------------------>|
                 |                         |
                 |                         |
                 |<------------------------|  ACK MID=0x0012
                 |                         |  0.00
                 |                         |
                 |                         |
                 |<------------------------|   CON
                 |                         |   MID=0X0034
                 |                         |   Content-Format X
ACK MID=0x0034   |------------------------>|
0.00           

 rule id 3
+-------------+------+---------+-------------+---+----------------+
| Field       |TV    |MO       |CDF          |dir| Sent           |
+=============+======+=========+=============+===+================+
|CoAP version | 01   |equal    |not-sent     |bi |                |
|CoAP Type    | CON  |equal    |not-sent     |up |                |
|CoAP Type    | ACK  |equal    |not-sent     |dw |                |
|CoAP TKL     | 1    |equal    |not-sent     |bi |                |
|CoAP Code    | POST |equal    |not-sent     |up |                |
|CoAP Code    | 0.00 |equal    |not-sent     |dw |                |
|CoAP MID     | 0000 |MSB(8)   |LSB(8)       |bi |MMMMMMMM        |
|CoAP Token   |      |ignore   |send-value   |up |TTTTTTTT        |
|CoAP Uri-Path| /c   |equal 1  |not-sent     |dw |                |
|CoAP Uri-query ML4  |equal 1  |not-sent     |dw |P               |
|CoAP Content | X    |equal    |not-sent     |up |                |
+-------------+------+---------+-------------+---+----------------+

 rule id 4
+-------------+------+---------+-------------+---+----------------+
| Field       |TV    |MO       |CDF          |dir| Sent           |
+=============+======+=========+=============+===+================+
|CoAP version | 01   |equal    |not-sent     |bi |                |
|CoAP Type    | CON  |equal    |not-sent     |dw |                |
|CoAP Type    | ACK  |equal    |not-sent     |up |                |
|CoAP TKL     | 1    |equal    |not-sent     |bi |                |
|CoAP Code    | 2.05 |equal    |not-sent     |dw |                |
|CoAP Code    | 0.00 |equal    |not-sent     |up |                |
|CoAP MID     | 0000 |MSB(8)   |LSB(8)       |bi |MMMMMMMM        |
|CoAP Token   |      |ignore   |send-value   |dw |TTTTTTTT        |
|COAP Accept  | X    |equal    |not-sent     |dw |                |
+-------------+------+---------+-------------+---+----------------+


alternative rule:

 rule id 4
+-------------+------+---------+-------------+---+----------------+
| Field       |TV    |MO       |CDF          |dir| Sent           |
+=============+======+=========+=============+===+================+
|CoAP version | 01   |equal    |not-sent     |bi |                |
|CoAP Type    | ML1  |equal    |match-sent(1)|bi |t               |
|CoAP TKL     | 1    |equal    |not-sent     |bi |                |
|CoAP Code    | ML2  |equal    |match-sent(1)|up | cc             |
|CoAP Code    | ML3  |equal    |match-sent(2)|dw | cc             |
|CoAP MID     | 0000 |MSB(8)   |LSB(8)       |bi |MMMMMMMM        |
|CoAP Token   |      |ignore   |send-value   |dw |TTTTTTTT        |
|CoAP Uri-Path| /c   |equal 1  |not-sent     |dw |                |
|CoAP Uri-query ML4  |equal 1  |not-sent     |dw |P               |
|CoAP Content | X    |equal    |not-sent     |up |                |
|COAP Accept  | x    |equal    |not-sent     |dw |                |
+-------------+------+---------+-------------+---+----------------+

ML1 {CON:0, ACK:1} ML2 {POST:0, 0.00: 1} ML3 {2.05:0, 0.00:1}
ML4 {NULL:0, k=AS:1, K=AZE:2}