Network Working Group A. Minaburo
Internet-Draft Acklio
Intended status: Informational L. Toutain
Expires: July 16, 2017 Institut Mines Telecom Atlantique
January 12, 2017

CoAP Traffic
draft-toutain-lpwan-coap-traffic-00

Abstract

This document describes different CoAP scenarios for the SCHC compression. It goes from the simplest exchange without acknowledgments to a basic study of the CoMI traffic.

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 July 16, 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

This document describes different CoAP scenarios for the SCHC compression. It goes from the simplest exchange without acknowledgments to a basic study of the CoMI traffic. These scenarios currently do not cover cases where encryption is used (COSE, OSCOAP,...).

2. scenario 1 - Unidirectional traffic

2.1. CoAP POST without Acknowledgement from thing


 thing                          LPWAN SCHC                   CoAP Server
|                                |                                |
|                                |   NON POST MID=0x00AB          |
|                                |   Token = 0x11                 |
|                                |   Path = /elm1/elm2            |
|                                |   Content-format = val         |
|                                |   NoResponse = 0|2|8|16        |
|     rule-id value              |   Value                        |
|------------------------------->|                                |
|                                | ------------------------------>|
      
  
    

Figure 1: POST with no ACK

The thing sends a CoAP POST/PUT request without acknowledgment using CoAP NON message and no response option [RFC7967]. This is a common traffic in a LPWAN network to minimize the downlink.

*** NOTE: The Mid may not be sent, since no acknowledgement is expected. Nevertheless several copies of the same message will not be detected by the receiver which will view them as several requests. This can be solved at L2 if the technology sends the frame with unique value.

2.2. Scenario 2 - CoAP POST without Acknowledgement to thing


thing                          LPWAN SCHC                  CoAP Server   
|                                |                                |
|                                |   NON POST MID=0xCDAB          |
|                                |   Token = 0x11223344           |
|                                |   Path = /elm1/elm2            |
|                                |   Content-format = val         |
|                                |   NoResponse = 0|2|8|16        |
|                                |   Value                        |
|    rule-id Value               |<-------------------------------|
|<-------------------------------|                                |
|                                |                                |
      
  
    

Figure 2: POST with no ACK

Same as Section 2.1 but request comes from network to thing. Selected values for Mid, token need to be control to allow a better compression rate. A CoAP proxy is need to normalize these values.

  • do not send version, type, token length, code because they are defined in the rule.
  • reduce value size and compress Message ID and Token.
  • do not sent options because they are defined in the rule
  • send value

3. bi-directional traffic

3.1. Scenario 3 - CoAP ack


thing                          LPWAN SCHC                   CoAP Server
|                                |                                |
|                                |   CON POST MID=0x00AB          |
|                                |   Token = 0x11                 |
|                                |   Path = /elm1/elm2            |
|                                |   Content-format = val         |
|            TDB                 |   NoResponse = 0|2|8|16        |
|------------------------------->|   Value                        |
|                                |------------------------------->|
|                                |                                |
|                                |   ACK 0.00 MID=0x00AB          |
|            TBD                 |<-------------------------------|
|<-------------------------------|
      
  
    

Figure 3: POST with no ACK

Same as Section 2.1 but the network acknowledge the CoAP message.

  • Thing
    • do not send version, token length.
    • compress type, Message ID, Token and code.
    • do not sent options.
    • send value

  • Network
    • compress type and code.

3.2. Scenario 4 - REST ack


thing                          LPWAN SCHC                   CoAP Server
|                                |                                |
|                                |   NON POST MID=0x00AB          |
|                                |   Token = 0x11                 |
|                                |   Path = /elm1/elm2            |
|------------------------------->|   Value                        |
|            TBD                 |------------------------------->|
|                                |                                |
|                                |   NON X.YY MID=0x1234          |
|                                |   Token = 0x11                 |
|            TBD                 |<-------------------------------|
|<-------------------------------|                                |
      
  
    

Figure 4: POST with no ACK

Same as Section 2.1 but the thing wait for an acknowledgement at REST level. Response code can be 2.04, 2.01, 2.02, 4.0Y, 5.0Y.

  • Thing
    • do not send version, token length.
    • compress type, Message ID and Token.
    • compress code.
    • do not sent options
    • send value

  • Network
    • do not send version, token length.
    • compress type, Message ID and token.
    • reduce MID size in response and compress it.

3.3. Scenario 5 - GET


thing                          LPWAN SCHC                     CoAP Server
|                                |                                |
|                                |   NON GET MID=0x00AB           |
|                                |   Token = 0x11                 |
|          TBD                   |   Accept = val                 |
|------------------------------->|   Path = /elm1/elm2            |
|                                |------------------------------->|
|                                |                                |
|                                |   NON 2.05 MID=0x1234          |
|                                |   Token = 0x11                 |
|                                |   Content-format = val         |
|                                |   Value                        |
|          TDB                   |<-------------------------------|
|<-------------------------------|                                |
      
  
    

Figure 5: POST with no ACK

Same as Section 3.2 but GET request and value in response..

  • Thing
    • do not send version, type, token length.
    • compress Message ID and Token.
    • compress code.
    • do not sent options

  • Network
    • reduce MID size in response and compress it.
    • compress code.
    • send token.
    • send value

4. CoMI

[I-D.vanderstok-core-comi] defines the different exchanges using CoMI. The path /c gives access to the CoMI module.

4.1. GET

With the GET method, /c is followed by the SID integer value coded in base64. A query parameter allows to specify a particular instance by sending the YANG keys. If no value is given then the full structure is returned. For instance (taken from the draft):

  • GET /c/a3
  • GET /c/Bf4?k="eth0"
  • GET /c

Objective:

  • allow to compress partially the path and send only the SID value on the radio link.

4.2. FETCH

FETCH /c/ Content-Format (application/YANG-fetch+cbor)
       <CBOR array of instance identifiers>

Figure 6: FETCH Structure

The FETCH method uses a CBOR structure sent in the payload instead of the URI.

FETCH /c Content-Format (application/YANG-fetch+cbor)
   [ 1719,              # ID 1719
     [-186, "eth0"]   # ID 1533 with name = "eth0"
   ]

Figure 7: FETCH with CBOR parameters

The CBOR structure is an array containing either CBOR Integer for SID or array with a SID and a list of filtering parameters.

For the compression point of view, Fetch is a new code value 0.05. But to send dynamically SIDs and keys, the CBOR structure must be understood by SCHC.

4.3. PUT/POST

PUT allows to remplace or create a data resource instance, POST always add a data resource instance. Draft imposes to use a confirmable CoAP message (which may not needed since there is REST confirmation). POST URI contains only the SID value and PUT can add a query parameter with keys.

4.4. iPATCH

   iPATCH /c Content-Format(application/YANG-patch+cbor)
   [
     [1533, "eth0"] ,                # interface (ID = 1533)
       {
         +4 : "eth0",                # name (ID 1537)
         +1 : "Ethernet adaptor",    # description (ID 1534)
         +5 : 1179,                  # type (ID 1538),
                                     # identity ethernetCsmacd
         +2 : true                   # enabled (ID 1535)
       }
     +203 , 60          # timezone-utc-offset (delta = 1736 - 1533)
   ]

   2.04 Changed

Figure 8: iPATCH with CBOR parameters

As for FETCH, the URI is static and the parameters are sent in a CBOR array containing the SID and then values.

4.5. DELETE

If GET and PUT/POST can be replaced by FETCH and iPATCH to have a more compact representation of SID and keys, DELETE imposes to put these values in the URI.

4.6. Examples

            
module: ietf-lpwan-compression
    +--rw compression-context
       +--rw context-rules* [rule-id]
          +--rw rule-id        uint8
          +--rw rule-fields* [position]
             +--rw name?                                       string
             +--rw position                                    uint8
             +--rw target-value?                               lpwan-types
             +--rw matching-operator?                          matching-operator-type
             +--rw matching-operator-value?                    lpwan-types
             +--rw compression-decompression-function?         compression-decompression-function-type
             +--rw compression-decompression-function-value?   lpwan-types


Figure 9: Generic module tree

            

SID        Assigned to
---------  --------------------------------------------------
1000       Module ietf-lpwan-compression
1001       identity /compression-decompression-function
1002       identity /compression-decompression-function/cdf-compute-ipv6-length
1003       identity /compression-decompression-function/cdf-compute-udp-checksum
1004       identity /compression-decompression-function/cdf-compute-udp-length
1005       identity /compression-decompression-function/cdf-esiid-did
1006       identity /compression-decompression-function/cdf-laiid-did
1007       identity /compression-decompression-function/cdf-lsb
1008       identity /compression-decompression-function/cdf-not-sent
1009       identity /compression-decompression-function/cdf-value-sent
1010       identity /matching-operator
1011       identity /matching-operator/mo-equal
1012       identity /matching-operator/mo-ignore
1013       identity /matching-operator/mo-msb
1014       node /compression-context
1015       node /compression-context/context-rules
1016       node /compression-context/context-rules/rule-fields
1017       node /compression-context/context-rules/rule-fields/compression-decompression-function
1018       node /compression-context/context-rules/rule-fields/compression-decompression-function-value
1019       node /compression-context/context-rules/rule-fields/matching-operator
1020       node /compression-context/context-rules/rule-fields/matching-operator-value
1021       node /compression-context/context-rules/rule-fields/name
1022       node /compression-context/context-rules/rule-fields/position
1023       node /compression-context/context-rules/rule-fields/target-value
1024       node /compression-context/context-rules/rule-id

File ietf-lpwan-compression@2016-11-01.sid created
Number of SIDs available : 200
Number of SIDs assigned : 25

Figure 10: Example of SID allocation

          
iPATCH /c Content-Format(application/YANG-patch+cbor)
[
  [field-SID, rule-id, field-pos], value
]  

Figure 11: YANG definition of the IPv6 UDP compression

Figure 9 gives the YANG module tree for SCHC. Two keys are defined: one for the rule-id and the other for the position (field-id). Figure 10 gives some SID value that may be applied to this YANG module. Note that Matching Operators and Compression/Decompression Functions are identified by a SID value. Figure 11 gives an example of a simple request where:

  • a thing selects a dynamic port number for a flow and informs the other end of this value.
  • a thing informs the other end of the destination IPv6 address.
  • Network informs the thing of the IPv6 prefix

  • field-SID contains the SID value identifying the Target Value (1023 in Figure 10),
  • rule-id is the rule to be modified
  • field-pos is the value indicating that it is respectively a ESport, or a prefix

 
  +----------------+------------------------+----------------+-----------------+
  | Field          |   Function             | Target Value   | Sent compressed |
  +----------------+------------------------+----------------+-----------------+
  |CoAP version    | not-sent               | 1              |                 |
  |CoAP Type       | not-sent               | CON*           | t               |
  |CoAP TKL        | compute-token-length   |                |                 |
  |CoAP Code       | map-code               | mapping table  |  CC             |
  |CoAP MID        | remapping              | 7 bits         |    MM           |
  |CoAP Token      | remapping              | 8 bits         |       TTT       |
  |CoAP Path       | not-sent               | /c             |                 |
  |CoAP content-F  | not-sent               | YANG-patch+cbor|                 |
  +----------------+------------------------+----------------+-----------------+
  * draft mandate a Confirmable message

Figure 12: CoAP Context to compress header with token

To set a port number for Rule 10 a CoMI iPTACH is sent. The rule 1 is used for that CoMI request and contains the Path, the content-format values and also the field-SID for Target Value (1023).

The objective will be to sent on the radio link a message containing:

  • rule-id for CoMI message : 0x01
  • CoAP header : 0xXX (1 byte)
  • CBOR Rule-id : 0x0A (10 in the example) (1 byte)
  • CBOR position to identify ESport : 0xPPPPPPPP (4 bytes)
  • CBOR port number value : 0xPPPP (2 bytes)

Therefore 9 bytes are sent on the LPWAN radio link.

5. Normative References

[I-D.vanderstok-core-comi] Stok, P., Bierman, A., Veillette, M. and A. Pelov, "CoAP Management Interface", Internet-Draft draft-vanderstok-core-comi-10, October 2016.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A. and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016.

Authors' Addresses

Ana Minaburo Acklio 2bis rue de la Chataigneraie 35510 Cesson-Sevigne Cedex, France EMail: ana@ackl.io
Laurent Toutain Institut Mines Telecom Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex, France EMail: Laurent.Toutain@imt-atlantique.fr

Table of Contents