draft-ietf-lpwan-coap-static-context-hc-12.txt   draft-ietf-lpwan-coap-static-context-hc-13.txt 
lpwan Working Group A. Minaburo lpwan Working Group A. Minaburo
Internet-Draft Acklio Internet-Draft Acklio
Intended status: Standards Track L. Toutain Intended status: Standards Track L. Toutain
Expires: June 12, 2020 Institut MINES TELECOM; IMT Atlantique Expires: September 6, 2020 Institut MINES TELECOM; IMT Atlantique
R. Andreasen R. Andreasen
Universidad de Buenos Aires Universidad de Buenos Aires
December 10, 2019 March 05, 2020
LPWAN Static Context Header Compression (SCHC) for CoAP LPWAN Static Context Header Compression (SCHC) for CoAP
draft-ietf-lpwan-coap-static-context-hc-12 draft-ietf-lpwan-coap-static-context-hc-13
Abstract Abstract
This draft defines the way SCHC header compression can be applied to This draft defines the way SCHC (Static Context Header Compression)
CoAP headers. The CoAP header structure differs from IPv6 and UDP header compression can be applied to the CoAP protocol. SCHC is a
protocols since CoAP uses a flexible header with a variable number of header compression mechanism adapted for constrained devices. SCHC
options, themselves of variable length. The CoAP protocol messages uses a static description of the header to reduce the redundancy and
format is asymmetric: the request messages have a header format the size of the information in the header. While
different from the one in the response messages. This document [I-D.ietf-lpwan-ipv6-static-context-hc] describes the SCHC
explains how to use the SCHC compression mechanism for CoAP. compression and fragmentation framework, and its application for
IPv6/UDP headers, this document applies the use of SCHC for CoAP
headers. The CoAP header structure differs from IPv6 and UDP since
CoAP uses a flexible header with a variable number of options,
themselves of variable length. The CoAP protocol messages format is
asymmetric: the request messages have a header format different from
the one in the response messages. This specification gives guidance
on how to apply SCHC to flexible headers and how to leverage the
asymmetry for more efficient compression Rules.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 12, 2020. This Internet-Draft will expire on September 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. SCHC Compression Process . . . . . . . . . . . . . . . . . . 3 2. Applying SCHC to CoAP . . . . . . . . . . . . . . . . . . . . 4
3. CoAP Compression with SCHC . . . . . . . . . . . . . . . . . 4 3. CoAP Compression with SCHC . . . . . . . . . . . . . . . . . 5
3.1. Differences between CoAP and UDP/IP . . . . . . . . . . . 5
4. Compression of CoAP header fields . . . . . . . . . . . . . . 6 4. Compression of CoAP header fields . . . . . . . . . . . . . . 6
4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 6 4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 7
4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 6 4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 7
4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 6 4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 7
4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 7 4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 7
4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 7 4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 7
5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 7 5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. CoAP Content and Accept options. . . . . . . . . . . . . 7 5.1. CoAP Content and Accept options. . . . . . . . . . . . . 8
5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields . . . . 8 5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields . . . . 8
5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 8 5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 8
5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 9 5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 9
5.3.2. Variable number of path or query elements . . . . . . 9 5.3.2. Variable number of path or query elements . . . . . . 10
5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme
fields . . . . . . . . . . . . . . . . . . . . . . . . . 9 fields . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path
and Location-Query fields . . . . . . . . . . . . . . . . 10 and Location-Query fields . . . . . . . . . . . . . . . . 10
6. Other RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. SCHC compression of CoAP extension RFCs . . . . . . . . . . . 10
6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Examples of CoAP header compression . . . . . . . . . . . . . 12 7. Examples of CoAP header compression . . . . . . . . . . . . . 12
7.1. Mandatory header with CON message . . . . . . . . . . . . 12 7.1. Mandatory header with CON message . . . . . . . . . . . . 12
7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 13 7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 13
7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 16 7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Security considerations . . . . . . . . . . . . . . . . . . . 26 9. Security considerations . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. Normative References . . . . . . . . . . . . . . . . . . . . 26 11. Normative References . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
CoAP [rfc7252] is an implementation of the REST architecture for CoAP [rfc7252] is a transfer protocol that implements a subset of
constrained devices. Although CoAP was designed for constrained HTTP (Hypertext Transfer Protocol) and is optimized for REST-based
devices, the size of a CoAP header still is too large for the (Representational state transfer) services. Although CoAP was
constraints of Low Power Wide Area Networks (LPWAN) and some designed for constrained devices, the size of a CoAP header still is
compression is needed to reduce the header size. too large for the constraints of LPWAN (Low Power Wide Area Networks)
and some compression is needed to reduce the header size.
[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression The [I-D.ietf-lpwan-ipv6-static-context-hc] defines SCHC, a header
mechanism for LPWAN network based on a static context. The context compression mechanism for LPWAN network based on a static context.
is said static since the field description composing the Rules are The section 5 of the [I-D.ietf-lpwan-ipv6-static-context-hc] explains
not learned during the packet exchanges but are previously defined. the architecture where compression and decompression are done. The
The context(s) is(are) known by both ends before transmission. context is known by both ends before transmission. The way the
context is configured or exchanged is out of the scope for this
document.
A context is composed of a set of rules that are referenced by Rule SCHC compresses and decompresses headers based on shared contexts
IDs (identifiers). A rule contains an ordered list of the fields between devices. Each context consists of multiple Rules. Each rule
descriptions containing a field ID (FID), its length (FL) and its can match header fields and specific values or ranges of values. If
position (FP), a direction indicator (DI) (upstream, downstream and a rule matches, the matched header fields are substituted by the rule
bidirectional) and some associated Target Values (TV). Target Value ID and optionally some residual bits. Thus, different Rules may
indicates the value that can be expected. TV can also be a list of correspond to different types of packets that a device expects to
values. A Matching Operator (MO) is associated to each header field send or receive.
A Rule describes the complete header of the packet with an ordered
list of fields descriptions, see section 7 of the
[I-D.ietf-lpwan-ipv6-static-context-hc], thereby each description
contains the field ID (FID), its length (FL) and its position (FP), a
direction indicator (DI) (upstream, downstream and bidirectional) and
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 for all description. The rule is selected if all the MOs fit the TVs for all
fields of the incoming packet. In that case, a Compression/ fields of the incoming packet.
Decompression Action (CDA) associated to each field defines how the In that case, a Compression/Decompression Action (CDA) associated to
compressed and the decompressed values are computed out of each each field defines how the compressed and the decompressed values are
other, for each of the header fields. Compression mainly results in computed out of each other, for each of the header fields.
one of 4 actions: send the field value, send nothing, send some least Compression mainly results in one of 4 actions: * send the field
significant bits of the field or send an index. After applying the value, * send nothing, * send some least significant bits of the
compression there may be some bits to be sent, these values are field or * send an index. After applying the compression there may
called Compression Residues and are transmitted after the Rule ID in be some bits to be sent, these values are called Compression
the compressed messages. Residues.
The compression rules define a generic way to compress and decompress SCHC is a general concept mechanism that can be applied to different
the fields. If the device is modified, for example, to introduce new protocols, the exact Rules to be used depend on the protocol and the
functionalities or new CoAP options, the rules must be updated to application, and CoAP differs from UDP and IPv6, see Section 3.
reflect the evolution.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [rfc2119][rfc8174] when, and only when, they appear in all 14 [rfc2119][rfc8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. SCHC Compression Process 2. Applying SCHC to CoAP
The SCHC Compression rules can be applied to CoAP flows. SCHC The SCHC Compression rules can be applied to CoAP flows. SCHC
Compression of the CoAP header MAY be done in conjunction with the Compression of the CoAP header MAY be done in conjunction with the
lower layers (IPv6/UDP) or independently. The SCHC adaptation layers lower layers (IPv6/UDP) or independently. The SCHC adaptation layers
as described in [I-D.ietf-lpwan-ipv6-static-context-hc] may be used as described in section 5 of [I-D.ietf-lpwan-ipv6-static-context-hc]
as shown in Figure 1. may be used as shown in Figure 1.
^ +------------+ ^ +------------+ ^ +------------+ ^ +------------+ ^ +------------+ ^ +------------+
| | CoAP | | | CoAP | inner | | CoAP | | | CoAP | | | CoAP | inner | | CoAP |
| +------------+ v +------------+ x | OSCORE | | +------------+ v +------------+ x | OSCORE |
| | UDP | | DTLS | outer | +------------+ | | UDP | | DTLS | outer | +------------+
| +------------+ +------------+ | | UDP | | +------------+ +------------+ | | UDP |
| | IPv6 | | UDP | | +------------+ | | IPv6 | | UDP | | +------------+
v +------------+ +------------+ | | IPv6 | v +------------+ +------------+ | | IPv6 |
| IPv6 | v +------------+ | IPv6 | v +------------+
+------------+ +------------+
Figure 1: rule scope for CoAP Figure 1: rule scope for CoAP
Figure 1 shows some examples for CoAP architecture and the SCHC Figure 1 shows some examples for CoAP architecture and the SCHC
rule's scope. rule's scope.
In the first example, a rule compresses the complete header stack In the first example, a rule compresses the complete header stack
from IPv6 to CoAP. In this case, SCHC C/D (Static Context Header from IPv6 to CoAP. In this case, SCHC C/D (Static Context Header
Compression Compressor/Decompressor) is performed at the device and Compression Compressor/Decompressor) is performed at the Sender and
at the LPWAN boundary. at the Receiver.
In the second example, an end-to-end encryption mechanisms is used In the second example, an end-to-end encryption mechanisms is used
between the device and the application. The SCHC compression is between the Sender and the Receiver. The SCHC compression is applied
applied in the CoAP layer compressing the CoAP header independently in the CoAP layer compressing the CoAP header independently of the
of the other layers. The rule ID and the compression residue are other layers. The rule ID and the compression residue are encrypted
encrypted using a mechanism such as DTLS. Only the other end can using a mechanism such as DTLS. Only the other end can decipher the
decipher the information. Layers below may also be compressed using information. Layers below may also be compressed using other SCHC
other SCHC rules (this is out of the scope of this document) as rules (this is out of the scope of this document) as defined in the
defined in the SCHC [I-D.ietf-lpwan-ipv6-static-context-hc] document. SCHC [I-D.ietf-lpwan-ipv6-static-context-hc] document.
In the third example, OSCORE [rfc8613] is used. In this case, two In the third example, OSCORE [rfc8613] is used. In this case, two
rulesets are used to compress the CoAP message. A first ruleset rulesets are used to compress the CoAP message. A first ruleset
focused on the inner header and is applied end to end by both ends. focused on the inner header and is applied end to end by both ends.
A second ruleset compresses the outer header and the layers below and A second ruleset compresses the outer header and the layers below and
is done between the device and the LPWAN boundary. is done between the Sender and the Receiver.
3. CoAP Compression with SCHC 3. CoAP Compression with SCHC
SCHC with CoAP will be used exactly the same way as it is applied in
any protocol as IP or UDP with the difference that the fields
description needs to be defined based on both headers and target
values of the request and the responses. SCHC Rules description use
the direction information to optmize the compression by reducing the
number of Rules needed to compress traffic. CoAP compression follows
the [I-D.ietf-lpwan-ipv6-static-context-hc] scheme and as for other
protocols, if no valid Rule was found, then the packet MUST be sent
uncompressed using the RuleID dedicated to this purpose and the
Compression Residue is the complete header of the packet. See
section 6 of [I-D.ietf-lpwan-ipv6-static-context-hc].
3.1. Differences between CoAP and UDP/IP
CoAP differs from IPv6 and UDP protocols on the following aspects: CoAP differs from IPv6 and UDP protocols on the following aspects:
o IPv6 and UDP are symmetrical protocols. The same fields are found o IPv6 and UDP are not request and response protocols as CoAP, and
in the request and in the response, with the value of some fields so the same header fields are used in all packets for all
being swapped on the return path (e.g. source and destination directions, with the value of some fields being swapped on the
fields). A CoAP request is intrinsically different from a return path (e.g. source and destination addresses fields). The
response. For example, the URI-path option is mandatory in the CoAP headers instead are asymmetric, the headers are different for
request and is not found in the response, a request may contain an a request or a response. For example, the URI-path option is
Accept option and the response a Content option. mandatory in the request and is not found in the response, a
request may contain an Accept option and the response may contain
a Content option.
[I-D.ietf-lpwan-ipv6-static-context-hc] defines the use of a The [I-D.ietf-lpwan-ipv6-static-context-hc] defines the use of a
message direction (DI) in the Field Description, which allows a Direction Indicator (DI) in the Field Description, which allows a
single Rule to process message headers differently depending of single Rule to process message headers differently depending on
the direction. the direction.
o Even when a field is "symmetric" (i.e. found in both directions) o Even when a field is "symmetric" (i.e. found in both directions)
the values carried in each direction are different. Combined with the values carried in each direction are different. To performs
a matching list in the TV, this allows reducing the range of the compression a matching list in the TV might be use because
expected values in a particular direction and therefore reduce the this allows reducing the range of expected values in a particular
size of the compression residue. For instance, if a client sends direction and therefore reduces the size of the
only CON request, the type can be elided by compression and the compression residue. For instance, if a client sends only CON
answer may use one single bit to carry either the ACK or RST type. requests, the type can be elided by compression and the answer may
The same behavior can be applied to the CoAP Code field 0.0X code use one single bit to carry either the ACK or RST type. In CoAP
Format is found in the request and Y.ZZ code format in the answer. some fields have the same behavior, for example the field Code can
The direction allows splitting in two parts the possible values have 0.0X code format value in the request and Y.ZZ code format in
for each direction in the same Rule. the response. Through the direction indicator, a field
description in the Rules splits the possible field value in two
parts. Resulting in a smaller compression residue.
o In IPv6 and UDP, header fields have a fixed size and it is not o In IPv6 and UDP, header fields have a fixed size, defined in the
sent. In CoAP, some fields in the header have a varying size, for Rule, which is not sent. In CoAP, some fields in the header have
example the Token size may vary from 0 to 8 bytes, the length is a variable length, for example the Token size may vary from 0 to 8
given by a field in the header. More systematically, the CoAP bytes, the length is given by a field in the header. The CoAP
options are described using the Type-Length-Value. options are described using the Type-Length-Value encoding format.
[I-D.ietf-lpwan-ipv6-static-context-hc] offers the possibility to Section 7.5.2 from [I-D.ietf-lpwan-ipv6-static-context-hc] offers
define a function for the Field Length in the Field Description. the possibility to define a function for the Field Length in the
Field Description to have knwoledge of the length before
compression. When doing SCHC compression of a variable length
field two cases may be raised after applying the CDA: * The result
of the compression is of fixed length and the compressed value is
sent in the residue. * Or the result of the compression is of
variable-length and in this case, the size is sent with the
compressed value in the residue.
o In CoAP headers, a field can appear several times. This is o In CoAP headers, a field can appear several times. This is
typical for elements of a URI (path or queries). The SCHC typical for elements of a URI (path or queries). The SCHC
specification [I-D.ietf-lpwan-ipv6-static-context-hc] allows a specification [I-D.ietf-lpwan-ipv6-static-context-hc] allows a
Field ID to appears several times in the rule, and uses the Field Field ID to appears several times in the rule, and uses the Field
Position (FP) to identify the correct instance, and thereby Position (FP) to identify the correct instance, and thereby
removing the ambiguity of the matching operation. removing the ambiguity of the matching operation.
o Field sizes defined in the CoAP protocol can be too large o Field sizes defined in the CoAP protocol can be too large
regarding LPWAN traffic constraints. This is particularly true regarding LPWAN traffic constraints. This is particularly true
for the Message ID field and the Token field. The MSB MO can be for the Message ID field and the Token field. SCHC uses different
applied to reduce the information carried on LPWANs. Matching operators (MO) to performs the compression, see section
7.4 of [I-D.ietf-lpwan-ipv6-static-context-hc]. In this case the
o CoAP also obeys the client/server paradigm and the compression Most Significant Bits (MSB) MO can be applied to reduce the
ratio can be different if the request is issued from an LPWAN information carried on LP
device or from a non LPWAN device. For instance, a Device (Dev)
aware of LPWAN constraints can generate a 1-byte token, but a
regular CoAP client will certainly send a larger token to the Dev.
The SCHC compression-decompression process never modifies the
Values it only reduces their sizes. Nevertheless, a proxy placed
before the compressor may change some field values to allow SCHC
achieving a better compression ratio, while maintaining the
necessary context for interoperability with existing CoAP
implementations.
o If no valid Rule was found, then the packet MUST be sent
uncompressed using the RuleID dedicated to this purpose and the
Compression Residue is the complete header of the packet. See
section 6 of [I-D.ietf-lpwan-ipv6-static-context-hc].
4. Compression of CoAP header fields 4. Compression of CoAP header fields
This section discusses the compression of the different CoAP header This section discusses the compression of the different CoAP header
fields. fields. The CoAP compression with SCHC follows the Section 7.1 of
[I-D.ietf-lpwan-ipv6-static-context-hc].
4.1. CoAP version field 4.1. CoAP version field
CoAP version is bidirectional and MUST be elided during the SCHC CoAP version is bidirectional and MUST be elided during the SCHC
compression, since it always contains the same value. In the future, compression, since it always contains the same value. In the future,
if new versions of CoAP are defined, new rules will be needed to if new versions of CoAP are defined, new rules will be needed to
avoid ambiguities between versions. avoid ambiguities between versions.
4.2. CoAP type field 4.2. CoAP type field
CoAP Protocol [rfc7252] defines 4 types of messages: CON, NON, ACK The CoAP Protocol [rfc7252] has four type of messages: two request
and RST. ACK and RST are a response to the CON and NON. If the (CON, NON); one response (ACK) and one empty message (RST).
device plays a specific client or server role, a rule can take
advantage of these properties with the mapping list: [CON, NON] for
one direction and [ACK, RST] for the other direction and so, the
compression residue is reduced to 1 bit.
The field SHOULD be elided if for instance a client is sending only The field SHOULD be elided if for instance a client is sending only
NON or only CON messages. NON or only CON messages. For the RST message a dedicated Rule may
be needed. For other usages a mapping list can be used.
In any case, a rule MUST be defined to carry RST to a client.
4.3. CoAP code field 4.3. CoAP code field
The compression of the CoAP code field follows the same principle as The code field indicates the Request Method used in CoAP, a registry
that of the CoAP type field. If the device plays a specific role, is given in section 12.1 of [rfc7252]. The compression of the CoAP
the set of code values can be split in two parts, the request codes code field follows the same principle as that of the CoAP type field.
with the 0 class and the response values. If the device plays a specific role, the set of code values can be
split in two parts, the request codes with the 0 class and the
response values.
If the device only implements a CoAP client, the request code can be If the device only implements a CoAP client, the request code can be
reduced to the set of requests the client is able to process. reduced to the set of requests the client is able to process.
All the response codes MUST be compressed with a SCHC rule. A mapping list can be used for known values, for other values the
field cannot be compressed an the value needs to be sent in the
residue.
4.4. CoAP Message ID field 4.4. CoAP Message ID field
The Message ID field is bidirectional and is used to manage The Message ID field can be compressed with the MSB(x) MO and the
acknowledgments. The server memorizes the value for an Least Significant Bits (LSB) CDA, see section 7.4 of
EXCHANGE_LIFETIME period (by default 247 seconds) for CON messages [I-D.ietf-lpwan-ipv6-static-context-hc].
and a NON_LIFETIME period (by default 145 seconds) for NON messages.
During that period, a server receiving the same Message ID value will
process the message as a retransmission. After this period, it will
be processed as a new message.
In case where the Device is a client, the size of the Message ID
field may be too large regarding the number of messages sent. The
client SHOULD use only small Message ID values, for instance 4 bit
long. Therefore, an MSB can be used to limit the size of the
compression residue.
In case where the Device is a server, the client may be located
outside of the LPWAN area and it views the Device as a regular device
connected to the Internet. The client will generate Message ID using
the 16 bits space offered by this field. A CoAP proxy can be set
before the SCHC C/D to reduce the value of the Message ID, to allow
its compression with the MSB matching operator and LSB CDA.
4.5. CoAP Token fields 4.5. CoAP Token fields
Token is defined through two CoAP fields, Token Length in the Token is defined through two CoAP fields, Token Length in the
mandatory header and Token Value directly following the mandatory mandatory header and Token Value directly following the mandatory
CoAP header. CoAP header.
Token Length is processed as any protocol field. If the value Token Length is processed as any protocol field. If the value does
remains the same during all the transaction, the size can be stored not change, the size can be stored in the TV and elided during the
in the context and elided during the transmission. Otherwise, it transmission. Otherwise, it will have to be sent in the compression
will have to be sent as a compression residue. residue.
Token Value size cannot be defined directly in the rule in the Field Token Value MUST not be sent as a variable length residue to avoid
Length (FL). Instead, a specific function designated as "TKL" MUST ambiguity with Token Length. Therefore, Token Length value MUST be
be used and length does not have to be sent with the residue. During used to define the size of the residue. A specific function
the decompression, this function returns the value contained in the designated as "TKL" MUST be used in the Rule. During the
Token Length field. decompression, this function returns the value contained in the Token
Length field.
5. CoAP options 5. CoAP options
5.1. CoAP Content and Accept options. 5.1. CoAP Content and Accept options.
These fields are both unidirectional and MUST NOT be set to These fields are both unidirectional and MUST NOT be set to
bidirectional in a rule entry. bidirectional in a rule entry.
If a single value is expected by the client, it can be stored in the If a single value is expected by the client, it can be stored in the
TV and elided during the transmission. Otherwise, if several TV and elided during the transmission. Otherwise, if several
possible values are expected by the client, a matching-list SHOULD be possible values are expected by the client, a matching-list SHOULD be
used to limit the size of the residue. Otherwise, the value has to used to limit the size of the residue. Otherwise, the value has to
be sent as a residue (fixed or variable length). be sent as a residue (fixed or variable length).
5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields 5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields
These fields are unidirectional and MUST NOT be set to bidirectional These fields are unidirectional and MUST NOT be set to bidirectional
in a rule entry. They are used only by the server to inform of the in a rule DI entry. see section 7.1 of
caching duration and is never found in client requests. [I-D.ietf-lpwan-ipv6-static-context-hc]. They are used only by the
server to inform of the caching duration and is never found in client
requests.
If the duration is known by both ends, the value can be elided on the If the duration is known by both ends, the value can be elided on the
LPWAN. LPWAN.
A matching list can be used if some well-known values are defined. A matching list can be used if some well-known values are defined.
Otherwise these options SHOULD be sent as a residue (fixed or Otherwise these options can be sent as a residue (fixed or variable
variable length). length).
5.3. CoAP option Uri-Path and Uri-Query fields 5.3. CoAP option Uri-Path and Uri-Query fields
These fields are unidirectional and MUST NOT be set to bidirectional These fields are unidirectional and MUST NOT be set to bidirectional
in a rule entry. They are used only by the client to access a in a rule entry. They are used only by the client to access a
specific resource and are never found in server responses. specific resource and are never found in server responses.
Uri-Path and Uri-Query elements are a repeatable options, the Field Uri-Path and Uri-Query elements are a repeatable options, the Field
Position (FP) gives the position in the path. Position (FP) gives the position in the path.
skipping to change at page 9, line 12 skipping to change at page 9, line 25
Figure 2: complex path example Figure 2: complex path example
In Figure 2 a single bit residue can be used to code one of the 2 In Figure 2 a single bit residue can be used to code one of the 2
paths. If regrouping were not allowed, a 2 bits residue would be paths. If regrouping were not allowed, a 2 bits residue would be
needed. needed.
5.3.1. Variable length Uri-Path and Uri-Query 5.3.1. Variable length Uri-Path and Uri-Query
When the length is not known at the rule creation, the Field Length When the length is not known at the rule creation, the Field Length
SHOULD be set to variable, and the unit is set to bytes. MUST be set to variable, and the unit is set to bytes.
The MSB MO can be applied to a Uri-Path or Uri-Query element. Since The MSB MO can be applied to a Uri-Path or Uri-Query element. Since
MSB value is given in bit, the size MUST always be a multiple of 8 MSB value is given in bit, the size MUST always be a multiple of 8
bits. bits.
The length sent at the beginning of a variable length residue The length sent at the beginning of a variable length residue
indicates the size of the LSB in bytes. indicates the size of the LSB in bytes.
For instance for a CORECONF path /c/X6?k="eth0" the rule can be set For instance for a CORECONF path /c/X6?k="eth0" the rule can be set
to: to:
skipping to change at page 9, line 46 skipping to change at page 10, line 16
not sent. The second element is sent with the length (i.e. 0x2 X 6) not sent. The second element is sent with the length (i.e. 0x2 X 6)
followed by the query option (i.e. 0x05 "eth0"). followed by the query option (i.e. 0x05 "eth0").
5.3.2. Variable number of path or query elements 5.3.2. Variable number of path or query elements
The number of Uri-path or Uri-Query elements in a rule is fixed at The number of Uri-path or Uri-Query elements in a rule is fixed at
the rule creation time. If the number varies, several rules SHOULD the rule creation time. If the number varies, several rules SHOULD
be created to cover all the possibilities. Another possibility is to be created to cover all the possibilities. Another possibility is to
define the length of Uri-Path to variable and send a compression define the length of Uri-Path to variable and send a compression
residue with a length of 0 to indicate that this Uri-Path is empty. residue with a length of 0 to indicate that this Uri-Path is empty.
This adds 4 bits to the compression residue. This adds the 4 bits of the variable residue size. See section 7.5.2
[I-D.ietf-lpwan-ipv6-static-context-hc]
5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields
These fields are unidirectional and MUST NOT be set to bidirectional These fields are unidirectional and MUST NOT be set to bidirectional
in a rule entry. They are used only by the client to access a in a rule DI entry, see section 7.1 of the
specific resource and are never found in server response. [I-D.ietf-lpwan-ipv6-static-context-hc]. They are used only by the
client to access a specific resource and are never found in server
response.
If the field value has to be sent, TV is not set, MO is set to If the field value has to be sent, TV is not set, MO is set to
"ignore" and CDA is set to "value-sent". A mapping MAY also be used. "ignore" and CDA is set to "value-sent". A mapping MAY also be used.
Otherwise, the TV is set to the value, MO is set to "equal" and CDA Otherwise, the TV is set to the value, MO is set to "equal" and CDA
is set to "not-sent". is set to "not-sent".
5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path and 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path and
Location-Query fields Location-Query fields
These fields are unidirectional. These fields are unidirectional.
These fields values cannot be stored in a rule entry. They MUST These fields values cannot be stored in a rule entry. They MUST
always be sent with the compression residues. always be sent with the compression residues.
6. Other RFCs 6. SCHC compression of CoAP extension RFCs
6.1. Block 6.1. Block
Block [rfc7959] allows a fragmentation at the CoAP level. SCHC also Block [rfc7959] allows a fragmentation at the CoAP level. SCHC also
includes a fragmentation protocol. They are compatible. If a block includes a fragmentation protocol. They are compatible. If a block
option is used, its content MUST be sent as a compression residue. option is used, its content MUST be sent as a compression residue.
6.2. Observe 6.2. Observe
The [rfc7641] defines the Observe option. The TV is not set, MO is The [rfc7641] defines the Observe option. The TV is not set, MO is
skipping to change at page 11, line 44 skipping to change at page 12, line 21
kid context field in the option. Bit k, when set, indicates the kid context field in the option. Bit k, when set, indicates the
presence of a kid field. The 3 least significant bits n indicate the presence of a kid field. The 3 least significant bits n indicate the
length of the piv (Partial Initialization Vector) field in bytes. length of the piv (Partial Initialization Vector) field in bytes.
When n = 0, no piv is present. When n = 0, no piv is present.
The flag byte is followed by the piv field, kid context field and kid The flag byte is followed by the piv field, kid context field and kid
field in this order and if present; the length of the kid context field in this order and if present; the length of the kid context
field is encoded in the first byte denoting by s the length of the field is encoded in the first byte denoting by s the length of the
kid context in bytes. kid context in bytes.
This draft recommends to implement a parser that is able to identify This specification recommends to identify the OSCORE Option and the
the OSCORE Option and the fields it contains. fields it contains.
Conceptually, it discerns up to 4 distinct pieces of information Conceptually, it discerns up to 4 distinct pieces of information
within the OSCORE option: the flag bits, the piv, the kid context, within the OSCORE option: the flag bits, the piv, the kid context,
and the kid. It is thus recommended that the parser split the OSCORE and the kid. It is thus recommended that the parser split the OSCORE
option into the 4 subsequent fields: option into the 4 subsequent fields:
o CoAP OSCORE_flags, o CoAP OSCORE_flags,
o CoAP OSCORE_piv, o CoAP OSCORE_piv,
skipping to change at page 18, line 5 skipping to change at page 19, line 5
0x82 = token 0x82 = token
0xFF Payload marker 0xFF Payload marker
Payload: Payload:
0x32332043 0x32332043
Original msg length: 10 Original msg length: 10
Figure 10: CoAP CONTENT Response Figure 10: CoAP CONTENT Response
The SCHC Rules for the Inner Compression include all fields that are TheSCHC Rules for the Inner Compression include all fields that are
already present in a regular CoAP message, what is important is their alreadypresent in a regular CoAP message. The methods described in
order and the definition of only those CoAP fields are into section Section 4 applies to these fields. As an example, see
Plaintext, Figure 11. Figure 11.
Rule ID 0 Rule ID 0
+---------------+--+--+-----------+-----------+-----------++------+ +---------------+--+--+-----------+-----------+-----------++------+
| Field |FP|DI| Target | MO | CDA || Sent | | Field |FP|DI| Target | MO | CDA || Sent |
| | | | Value | | ||[bits]| | | | | Value | | ||[bits]|
+---------------+--+--+-----------+-----------+-----------++------+ +---------------+--+--+-----------+-----------+-----------++------+
|CoAP Code | |up| 1 | equal |not-sent || | |CoAP Code | |up| 1 | equal |not-sent || |
|CoAP Code | |dw|[69,132] | match-map |match-sent || c | |CoAP Code | |dw|[69,132] | match-map |match-sent || c |
|CoAP Uri-Path | |up|temperature| equal |not-sent || | |CoAP Uri-Path | |up|temperature| equal |not-sent || |
|COAP Option-End| |dw| 0xFF | equal |not-sent || | |COAP Option-End| |dw| 0xFF | equal |not-sent || |
skipping to change at page 19, line 46 skipping to change at page 20, line 46
_________________________________________________ _________________________________________________
| | | |
| encrypted_plaintext = 0xa2 (1 byte) | | encrypted_plaintext = 0xa2 (1 byte) |
| tag = 0xc54fe1b434297b62 (8 bytes) | | tag = 0xc54fe1b434297b62 (8 bytes) |
| | | |
| ciphertext = 0xa2c54fe1b434297b62 (9 bytes) | | ciphertext = 0xa2c54fe1b434297b62 (9 bytes) |
|_________________________________________________| |_________________________________________________|
Figure 12: Plaintext compression and encryption for GET Request Figure 12: Plaintext compression and encryption for GET Request
In Figure 13 we repeat the process for the example CONTENT Response. In Figure 13 the process is repeated for the example CONTENT
In this case the misalignment produced by the compression residue (1 Response. The residue is 1 bit long. Note that since SCHC adds
bit) makes it so that 7 bits of padding have to be applied after the padding after the payload, this misalignment causes the hexadecimal
payload, resulting in a compressed Plaintext that is the same size as code from the payload to differ from the original, even though it has
before compression. This misalignment also causes the hexcode from not been compressed.
the payload to differ from the original, even though it has not been
compressed. On top of this, the overhead from the tag bytes is On top of this, the overhead from the tag bytes is incurred as
incurred as before. before.
________________________________________________________ ________________________________________________________
| | | |
| OSCORE Plaintext | | OSCORE Plaintext |
| | | |
| 0x45ff32332043 (6 bytes) | | 0x45ff32332043 (6 bytes) |
| | | |
| 0x45 Successful Response Code 69 "2.05 Content" | | 0x45 Successful Response Code 69 "2.05 Content" |
| | | |
| ff Payload marker | | ff Payload marker |
skipping to change at page 21, line 13 skipping to change at page 22, line 13
Figure 13: Plaintext compression and encryption for CONTENT Response Figure 13: Plaintext compression and encryption for CONTENT Response
The Outer SCHC Rules (Figure 16) MUST process the OSCORE Options The Outer SCHC Rules (Figure 16) MUST process the OSCORE Options
fields. In Figure 14 and Figure 15 we show a dump of the OSCORE fields. In Figure 14 and Figure 15 we show a dump of the OSCORE
Messages generated from our example messages once they have been Messages generated from our example messages once they have been
provided with the Inner Compressed Ciphertext in the payload. These provided with the Inner Compressed Ciphertext in the payload. These
are the messages that have to be compressed by the Outer SCHC are the messages that have to be compressed by the Outer SCHC
Compression. Compression.
Protected message: Protected message:
================== ==================
0x4102000182d7080904636c69656e74ffa2c54fe1b434297b62 0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62
(25 bytes) (25 bytes)
Header: Header:
0x4102 0x4102
01 Ver 01 Ver
00 CON 00 CON
0001 tkl 0001 tkl
00000010 Request Code 2 "POST" 00000010 Request Code 2 "POST"
0x0001 = mid 0x0001 = mid
skipping to change at page 22, line 48 skipping to change at page 23, line 48
Note that fixing a flag bit will limit the choice of CoAP Options Note that fixing a flag bit will limit the choice of CoAP Options
that can be used in the exchange, since their values are dependent on that can be used in the exchange, since their values are dependent on
certain options. certain options.
The piv field lends itself to having a number of bits masked off with The piv field lends itself to having a number of bits masked off with
MO MSB and CDA LSB. This could be useful in applications where the MO MSB and CDA LSB. This could be useful in applications where the
message frequency is low such as that found in LPWAN technologies. message frequency is low such as that found in LPWAN technologies.
Note that compressing the sequence numbers effectively reduces the Note that compressing the sequence numbers effectively reduces the
maximum amount of sequence numbers that can be used in an exchange. maximum amount of sequence numbers that can be used in an exchange.
Once this amount is exceeded, the SCHC Context would need to be re- Once this amount is exceeded, the OSCORE keys need to be re-
established. established.
The size s included in the kid context field MAY be masked off with The size s included in the kid context field MAY be masked off with
CDA MSB. The rest of the field could have additional bits masked CDA MSB. The rest of the field could have additional bits masked
off, or have the whole field be fixed with MO equal and CDA not-sent. off, or have the whole field be fixed with MO equal and CDA not-sent.
The same holds for the kid field. The same holds for the kid field.
Figure 16 shows a possible set of Outer Rules to compress the Outer Figure 16 shows a possible set of Outer Rules to compress the Outer
Header. Header.
skipping to change at page 26, line 30 skipping to change at page 27, line 30
As can be seen, the difference between applying SCHC + OSCORE as As can be seen, the difference between applying SCHC + OSCORE as
compared to regular SCHC + COAP is about 10 bytes of cost. compared to regular SCHC + COAP is about 10 bytes of cost.
8. IANA Considerations 8. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
9. Security considerations 9. Security considerations
This document does not have any more Security consideration than the This document does not have any more Security consideration than the
ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc] ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc].
Variable length residues may be used to compress URI elements. They
cannot produce a packet expansion either on the LPWAN network or in
the Internet network after decompression. The length send is not
used to indicate the information that should be reconstructed at the
other end, but on the contrary the information sent as a Residue.
Therefore, if a length is set to a high value, but the number of bits
on the SCHC packet is smaller, the packet must be dropped by the
decompressor.
OSCORE compression is also based on the same compression method
described in [I-D.ietf-lpwan-ipv6-static-context-hc]. The size of
the Initialisation Vector residue size must be considered carefully.
A too large value has a impact on the compression efficiency and a
too small value will force the device to renew its key more often.
This operation may be long and energy consuming.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Dominique Barthel, Carsten Bormann, The authors would like to thank Dominique Barthel, Carsten Bormann,
Thomas Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov, Thomas Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov,
Goran Selander. Goran Selander.
11. Normative References 11. Normative References
[I-D.ietf-lpwan-ipv6-static-context-hc] [I-D.ietf-lpwan-ipv6-static-context-hc]
 End of changes. 51 change blocks. 
191 lines changed or deleted 226 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/