LPWAN Static Context Header Compression (SCHC) for CoAPAcklio2bis rue de la Chataigneraie35510 Cesson-Sevigne CedexFranceana@ackl.ioInstitut MINES TELECOM ; IMT Atlantique2 rue de la ChataigneraieCS 1760735576 Cesson-Sevigne CedexFranceLaurent.Toutain@imt-atlantique.frlpwan Working GroupThis 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. 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.CoAP 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.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 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.CoAP header format defines the following fields:version (2 bits): this field can be elided during the SCHC compresssiontype (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 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 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 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.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.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.The Matching Operator behavior has not changed, but the value must take a position value,
if the entry is repeated :For instance, the rule matches with /foo/bar, but not /bar/foo.The position is added after the natural argument of the MO, for example MSB (4,3)
indicates a most significant bit matching of 4 bits in a field located in position 3.When the length is not clearly indicated in the rule, the value length must be sent with the
field data, which means for CoAP to send directly the CoAP option where the delta-T is
set to 0.For the CoMi path /c/X6?k=”eth0” the rule can be set to: shows the parsing and the compression of the URI. where c is not sent.
The second element is sent with the length (i.e. 0x02 X 6) followed by the query option
(i.e. 0x08 k=”eth0”).[[NOTE we don’t process URI with a multiple number of path element ??]].This section lists the different CoAP header fields and how they can
be compressed.This field is bidirectional.This field contains always the same value, therefore the TV may be 1, the MO
is set to “equal” and the CDF is set to “not-sent”This field is bidirectional or undirectional.Several strategies can be applied to this field regarding the values used:if only one type is sent, for example NON message, its transmission can be avoided.
TV is set to the value, MO is set to “equal” and CDF is set to “not-sent”.if two values are sent, for example CON and ACK and RST is not used, this field can
be reduced to one bit. TV is set to a matching value {CON: 0, ACK: 1}, MO is set
to match-mapping and CDF is set to mapping-sent.It is also possible avoid transmission of this field by marking it unidirectional.
In one direction, the TV is set to CON, MO is set to “equal” and CDF is set to “not-sent”.
On the other direction, the TV is set to ACK, the MO is set to “equal” and the CDF is
set to “not-sent”.Otherwise TV is not set, MO is set to “ignore” and CDF is set to “value-sent”.This field is bi-directional.Several strategies can be applied to this field regarding the values:no token or a wellknown length, the transmission can be avoided. TV is set to the
length, the MO is set to “equal” and CDF is set to “not-sent”The length is variable from one message to another. TV is not set, MO is set to
“ignore” and CDF is set to “value-sent”. The size of the sent value must be known by
ends. The size may be 4 bits. The receiver must take into account this value to
retrieve the token. A CoAP proxy may be used before the compression to reduce the
field size.This field is unidirectional. The client and the server do not use the
same values.The CoAP code field defines a tricky way to ensure compatibility with
HTTP values. Nevertheless only 21 values are defined by
compared to the 255 possible values. So, it could efficiently be
coded on 5 bits. The number of code may vary over time, some new codes
may be introduced or some applications use a limited number of values. gives a possible mapping, it can be changed
to add new codes or reduced if some values are never used by both ends.The field can be treated differently in upstream than in downstream.
If the Thing is a client an entry can be set on the uplink message with a
code matching for 0.0X values and another for downlink values for Y.ZZ
codes. It is the opposite if the thing is a server.This field is bidirectional.Message ID is used for two purposes:To acknowledge a CON message with an ACK.To avoid duplicate messages.In LPWAN, since a message can be received by several radio gateway, some
LPWAN technologies include a sequence number in L2 to avoid duplicate frames. Therefore
if the message does not need to be acknowledged (NON or RST message), the Message
ID field can be avoided. In that case TV is not set, MO is set to ignore and CDF
is set to “not-sent”. The decompressor can generate a number.[[Note; check id this field is not used by OSCOAP .]]To optimize information sent on the LPWAN, shorter values may be used during the
exchange, but Message ID values generated a common CoAP implementation will not take
into account this limitation. Before the compression, a proxy may be needed to
reduce the size. In that case, the TV is set to 0x0000, MO is set to “MSB(l)”
and CDF is set to “LSB(16-l)”, where “l” is the size of the compressed header.Otherwise if no compression is needed the TV is not set,
MO is set to ignore and CDF is set to “not-sent”.This field is bi-directional.Token is used to identify transactions and varies from one
transaction to another. Therefore, it is usually necessary to send
the value of the token field on the LPWAN network. The optimization will occur
by using small
values.Common CoAP implementations may generate large tokens, even if shorter tokens could
be used regarding the LPWAN characteristics. A proxy may be needed to reduce
the size of the token before compression.Otherwise the TV is not set, the MO is set to ignore and CDF is set to “value-sent”.The decompression may know the length of the token field from the token length field.This field is unidirectional and must not be set to bidirectional in a rule entry.
It is used only by the server to inform the client about of the payload type and is never found in client
requests.If the value is known by both sides, the TV contains that value and MO is set to
“equal” and the CDF is set to “not-sent”.Otherwise the TV is not set, MO is set to “ignore” and CDF is set to “value-sent”A mapping list can also be used to reduce the size.This field is unidirectional and must not be set to bidirectional in a rule entry.
It is used only by the client to inform of the possible payload type and is never
found in server response.The number of accept options is not limited and can vary regarding the usage. To
be selected a rule must contain the exact number about accept options with their positions.if the accept value must be sent, the TV contains that value, MO is set to “ignore x”
where “x” is the accept option’s position and CDF is set to value-sent. Since the value length
is not known, it must be sent as a CoAP TLV with delta-T set to 0.Otherwise the TV is not set, MO is set to “equal x” where x is the accept option’s position
and CDF is set to “not-sent”[[note: it could be more liberal and do not provide the same order after decompression]]This field is unidirectional and must not be set to bidirectional in a rule entry.
It is 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 TV is set with this duration, the MO is set
to “equal” and the CDF is set to “not-sent”.Otherwise the TV is not set, the MO is set to “ignore” and the CDF is set to “value-sent”.
Since the value length is not known, it must be sent as a CoAP TLV with delta-T set to 0.[[note: we can reduce (or create a new option) the unit to minute,
second is small for LPWAN ]]This fields are unidirectional and must not be set to bidirectional in a rule entry.
They are used only by the client to access to a specific server and are never found
in server response.For each option, if the value is known by both ends, the TV is set with this value,
the MO is set
to “equal” and the CDF is set to “not-sent”.Otherwise the TV is not set, the MO is set to “ignore” and the CDF is set to “value-sent”.
Since the value length is not known, it must be sent as a CoAP TLV with delta-T set to 0.This fields are unidirectional and must not be set to bidirectional in a rule entry.
They are used only by the client to access to a specific resource and are never found
in server response.Path and Query option may have different formats. gives some examples.If the URI path as well as the query is composed of 2 or more elements, then
the position must be set in the MO parameters.If a Path or Query element is stable over the time, then TV is set with its value, MO is
set to “equal x” where x is the position in the Path or the Query and CDF is set to “not-sent”.Otherwise if the value varies over time, TV is not set, MO is set to “ignore x”
where x is the position in the Path or in the Query and CDF is set to “value-sent”. Since
the value length is not known, it must be sent as a CoAP TLV with deltaT set to 0.A Mapping list can be used to reduce size of variable Paths or Queries. In that case, to
optimize the compression, several elements can be regrouped into a single entry.
Numbering of elements do not change, MO comparison is set with the first element
of the matching.For instance, the following Path /foo/bar/variable/stable can leads to the rule defined
.These fields are unidirectional and must not be set to bidirectional in a rule entry.
They are used only by the client to access to a specific resource and are never found
in server response.If the field value must be sent, TV is not set, MO is set to “ignore” and CDF is set
to “value-sent. A mapping can also be used.Otherwise the TV is set to the value, MO is set to “equal” and CDF is set to “not-sent”These fields are unidirectional.These fields values cannot be stored in a rule entry. They must always be sent with the
request.[[Can include OSCOAP Object security in that category ]]Block option should be avoided in LPWAN. The minimum size of 16 bytes can be incompatible
with some LPWAN technologies.[[Note: do we recommand LPWAN fragmentation since the smallest value of 16 is too big?]] defines the Observe option. The TV is not set, MO is set to “ignore” and the
CDF is set to “value-sent”. SCHC does not limit the maximum size for this option (3 bytes).
To reduce the transmission size either the Thing implementation should limit the value
increase or a proxy can be used limit the increase.Since RST message may be sent to inform a server that the client do not require Observe
response, a rule must allow the transmission of this message. defines an No-Response option limiting the responses made by a server to
a request. If the value is not by both ends, then TV is set to this value, MO is
set to “equal” and CDF is set to “not-sent”.Otherwise, if the value is changing over time, TV is not set, MO is set to “ignore” and
CDF to “value-sent”. A matching list can also be used to reduce the size.In this first scenario, the LPWAN compressor receives from outside client
a POST message, which is immediately acknowledged by the Thing. For this simple
scenario, the rules are described .The version and Token Length fields are elided. Code has shrunk to 5 bits
using the matching list (as the one given : 0.01
is value 0x01 and 2.05 is value 0x0c)
Message-ID has shrunk to 9 bits to preserve alignment on byte boundary. The
most significant bit must be set to 0 through a CoAP proxy. Uri-Path contains
a single element indicated in the matching operator. shows the time diagram of the exchange. A LPWAN Application Server sends
a CON message. Compression reduces the header sending only the Type, a mapped
code and the least 9 significant bits of Message ID. The receiver decompresses
the header. .The CON message is a request, therefore the LC process to a dynamic
mapping. When the ES receives the ACK message, this will not
initiate locally a message ID mapping since it is a response.
The LC receives the ACK and uncompressed it to restore the original
value. Dynamic Mapping context lifetime follows the same rules as
message ID duration.The message can be further optimized by setting some fields unidirectional, as
described in . Note that Type is no more sent in the
compressed format, Compressed Code size in not changed in that example (8 values
are needed to code all the requests and 21 to code all the responses in the matching list
)In that example, the Thing is using CoMi and sends queries for 2 SID.Transmission of IPv6 Packets over IEEE 802.15.4 NetworksThis document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressedThis document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK]Formal Notation for RObust Header Compression (ROHC-FN)This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work. [STANDARDS-TRACK]RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-LiteThis document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers.This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation. [STANDARDS-TRACK]Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based NetworksThis document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.Constrained Application Protocol (CoAP) Option for No Server ResponseThere can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.The PPP Internet Protocol Control Protocol (IPCP)The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. [STANDARDS-TRACK]Observing Resources in the Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.LPWAN Static Context Header Compression (SCHC) for IPv6 and UDPThis document describes a header compression scheme for IPv6, IPv6/ UDP based on static contexts. This technique is especially tailored for LPWA networks and could be extended to other protocol stacks. During the IETF history several compression mechanisms have been proposed. First mechanisms, such as RoHC, are using a context to store header field values and send smaller incremental differences on the link. Values in the context evolve dynamically with information contained in the compressed header. The challenge is to maintain sender's and receiver's contexts synchronized even with packet losses. Based on the fact that IPv6 contains only static fields, 6LoWPAN developed an efficient context-free compression mechanisms, allowing better flexibility and performance. The Static Context Header Compression (SCHC) combines the advantages of RoHC context which offers a great level of flexibility in the processing of fields, and 6LoWPAN behavior to elide fields that are known from the other side. Static context means that values in the context field do not change during the transmission, avoiding complex resynchronization mechanisms, incompatible with LPWA characteristics. In most of the cases, IPv6/UDP headers are reduced to a small identifier. This document focuses on IPv6/UDP headers compression, but the mechanism can be applied to other protocols such as CoAP. It will be described in a separate document.CoAP Management InterfaceThis document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CoMI). The Constrained Application Protocol (CoAP) is used to access data resources specified in YANG, or SMIv2 converted to YANG. CoMI uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CoMI extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks.