| 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
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.
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 (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.
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,...).
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.
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.
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 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 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..
[I-D.vanderstok-core-comi] defines the different exchanges using CoMI. The path /c gives access to the CoMI module.
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):
Objective:
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.
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.
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.
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.
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:
+----------------+------------------------+----------------+-----------------+ | 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:
Therefore 9 bytes are sent on the LPWAN radio link.
| [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. |