lpwan Working Group A. Minaburo Internet-Draft Acklio Intended status: Informational L. Toutain Expires:September 5, 2018January 3, 2019 Institut MINES TELECOM; IMT AtlantiqueMarch 04,R. Andreasen Universidad de Buenos Aires July 02, 2018 LPWAN Static Context Header Compression (SCHC) for CoAPdraft-ietf-lpwan-coap-static-context-hc-03draft-ietf-lpwan-coap-static-context-hc-04 Abstract This draft defines the way SCHC header compression can be applied to CoAP headers. CoAP header structure differs from IPv6 and UDP protocols since the CoAPHeader isuse a flexible header with a variable number of options themself of a variable length. Another important difference is the asymmetry in the headerinformationformat usedforin request and response messages.This draft takes into accountMost of thefact that a thing can playcompression mechanisms have been introduced in [I-D.ietf-lpwan-ipv6-static-context-hc], this document explains how to use therole of a CoAP client, a CoAP client or both roles.SCHC compression for CoAP. 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 https://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 onSeptember 5, 2018.January 3, 2019. Copyright Notice Copyright (c) 2018 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 (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .23 2.CoAP Compressing . . . .SCHC Compression Process . . . . . . . . . . . . . . . . . . 3 3.Compression ofCoAPheader fieldsCompression with SCHC . . . . . . . . . . . . . . . . . 43.1.4. Compression of CoAPversion field (2 bits) .header fields . . . . . . . . . . . . . .4 3.2.6 4.1. CoAPtypeversion field . . . . . . . . . . . . . . . . . . .. . 5 3.3.6 4.2. CoAPtoken lengthtype field . . . . . . . . . . . . . . . . .5 3.4.. . . . 6 4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 63.5.4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . .8 3.6.6 4.5. CoAP Tokenfieldfields . . . . . . . . . . . . . . . . . . . .9 4.7 5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . .9 4.1. CoAP option Content-format field. . . . . . . . . . . . . 9 4.2.7 5.1. CoAPoptionContent and Acceptfieldoptions. . . . . . . . . . . . .. . . . 10 4.3.7 5.2. CoAP option Max-Age field, CoAP option Uri-Host and Uri- Port fields . . . . . . . . . . . . . . . . . . . . . . .11 5.7 5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 8 5.3.1. Variable length Uri-Path and Uri-Query . .11 5.1.. . . . . 8 5.3.2. Variable number of path or query elements . . . . . . 9 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields . . . . . .12 5.2.. . . . . . . . . . . . . . . . . . . 9 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path and Location-Query fields . . . . . . . . . . . . . . . .139 6. Other RFCs . . . . . . . . . . . . . . . . . . . . . . . . .139 6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . .139 6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . .1310 6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . .13 7. Protocol analysis10 6.4. Time Scale . . . . . . . . . . . . . . . . . . . . . .13 8.. 10 6.5. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Examples of CoAP header compression . . . . . . . . . . . . .14 8.1.12 7.1. Mandatory header with CON message . . . . . . . . . . . .14 8.2.12 7.2. Complete exchange . . . . . . . . . . . . . . . . . . . .16 9. Normative References13 7.3. OSCORE Compression . . . . . . . . . . . . . . . . . . . 14 7.4. Example OSCORE Compression . . . . . . . . . . . . . . . 17Authors' Addresses8. Normative References . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . .18 1. Introduction CoAP. . . . . . . . . . . . . . . . . . . . 22 1. Introduction CoAP [rfc7252] is an implementation of the REST architecture for constrained devices.A 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.[I-D.toutain-lpwan-ipv6-static-context-hc][I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression mechanism for LPWAN network based on a static context. The context is said static since the field description composing the Rules and 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 that are referenced by Rule IDs (identifiers). A rule contains an ordered list of the fields descriptions containing a field ID(FID)(FID), its length (FL) and its positionwhen repeated,(FP), a direction indicator (DI) (upstream, downstream and bidirectional) and some associated Target Values(TV) which are expected in(TV). Target Value indicates themessage header.value that can be expected. TV can also be a list of values. A Matching Operator (MO) is associated to each header field description. The rule is selected if all the MOs fit theTVs.TVs for all fields. In that case, a Compression/Decompression Action (CDA) associated to each field defines the link between the compressed and decompressed value for each of the header fields.This document describes howCompression results mainly in 4 actions: send the field value, send nothing, send less significant bits of a field, send an index. Values sent are called Compression Residues and follows the rule ID. 2. SCHC Compression Process The SCHC Compression rules can be applied to CoAP flows. SCHC Compression of the CoAP header may be done in conjunction with the above layers (IPv6/UDP) orindependantly. 2.independently. The SCHC adaptation layers as described in [I-D.ietf-lpwan-ipv6-static-context-hc] may be used as as shown in the Figure 1. ^ +------------+ ^ +------------+ ^ +------------+ | | CoAPCompressing| | | CoAPdiffers from IPv6 and| inner | | CoAP | | +------------+ v +------------+ x | OSCORE | | | UDPprotocols on the following aspects: o| | DTLS | outer | +------------+ | +------------+ +------------+ | | UDP | | | IPv6and| | UDPare symmetrical protocols. The same fields are found in the request| | +------------+ v +------------+ +------------+ | | IPv6 | | IPv6 | v +------------+ +------------+ Figure 1: rule scope for CoAP Figure 1 shows some examples for CoAP architecture andin the response, only the location intheheader may vary (e.g. source and destination fields).SCHC rule's scope. ACoAP request is differentrule can covers all headers froma response. For example, the URI-path optionIPv6 to CoAP, SCHC C/D ismandatorydone in therequestdevice andis not found inat theresponse, a request may containLPWAN boundary. If anAccept optionend-to- end encryption mechanisms is used between the device and theresponse a Content-format option. Even when a field is "symmetric" (i.e. found in both directions)application. CoAP must be compressed independently of thevalues carried are different. For instanceother layers. The rule ID and theType field will containcompression residue are encrypted using aCON value inmechanism such as DTLS. Only therequest and a ACK or RST value inother end can decipher theresponse. Exploitinginformation. Layers below may also be compressed using other SCHC rules (this is out of theasymmetry in compression will allowscope of this document). OSCORE [I-D.ietf-core-object-security] can also define 2 rules tosend no bit incompress thecompressed requestCoAP message. A first rule focuses on the inner header and is end to end, asingle bit insecond rule may compress theanswer. Same behavior can be applied toouter header and the layer above. SCHC C/D for inner header is done by both ends, SCHC C/D for outer header and other headers is done between the device and the LPWAN boundary. 3. CoAPCode field (O.OX codeCompression with SCHC CoAP differs from IPv6 and UDP protocols on the following aspects: o IPv6 and UDP arepresentsymmetrical protocols. The same fields are found in the request andY.ZZin theanswer). o CoAP also obeys to the client/server paradigm andresponse, only thecompression rate can be different iflocation in the header may vary (e.g. source and destination fields). A CoAP request isissued from an LPWAN node ordifferent froman non LPWAN device. For instance a Thing (ES) aware of LPWAN constraints can generate a 1 byte token, but a regular CoAP client will certainly sendalarger token toresponse. For example, theThing. SCHC compression willURI-path option is mandatory in the request and is notmodifyfound in thevalues to offer a better compression rate. Neverthelessresponse, aproxy placed before the compressorrequest maychange somecontain an Accept option and the response a Content option. [I-D.ietf-lpwan-ipv6-static-context-hc] defines the use of a message direction (DI) when processing the rule which allows the description of message header format 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 a matching list in the TV, this will allow toofferreduce the range of expected values in a particular direction and therefore reduce the size of abettercompressionrateresidue. For instance, if a client sends only CON request, the type can be elided by compression andmaintainthenecessary context for interoperability with existinganswer may use one bit to carry either the ACK or RST type. Same behavior can be applied to the CoAPimplementations.Code field (0.0X code are present in the request and Y.ZZ in the answer). The direction allows to split in two parts the possible values for each direction. o 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. By sending compressed field information following the rule order, SCHC[I-D.ietf-lpwan-ipv6-static-context-hc] offersa serialization/deserialization mechanism. Since a field exists to indicatethetoken length there is no ambiguity. For options, the rule indicates also the expected options found the int CoAP header. Therefore only the length is neededpossibility torecognize an option. The length will be sent using the same CoAP encoding (size less than 12 are directly sent, higher values use the escape mechanisms defined by [rfc7252]). Delta Type is omitted, the value will be recovered by the decompressor. This reduces the option length of 4, 12 or 20 bits regarding the original size ofdefine a function for thedelta type encodingField Length in theoption.Field Description. o In CoAPheadersheaders, a field can be duplicated several times, for instances, elements of an URI (path orqueries) or accepted formats.queries). The position defined in a rule, associated to a Field ID, can be used to identify the proper element.3. Compression of CoAP header fields This section discusses of the compression of the different[I-D.ietf-lpwan-ipv6-static-context-hc] allows a Field id to appears several times in the rule, the Field Position (FP) removes ambiguities for the matching operation. o Field size defined in the CoAPheader fields. These are just examples.protocol can be to large regarding LPWAN traffic constraints. This is particularly true for the message ID field or Token field. The use of MSB MO can be used to reduce the information carried on LPWANs. o CoAP also obeys to the client/server paradigm and the compressionshould take into accountrate can be different if thenaturerequest is issued from an LPWAN node or from an 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 thetraffic andThing. SCHC compression will notonlymodify thefield values. Next chapter will definevalues to offer a better compression rate. Nevertheless a proxy placed before the compressor may change some field values to offer a better compressionrulesrate and maintain the necessary context forsome common exchanges. 3.1.interoperability with existing CoAP implementations. 4. Compression of CoAP header fields This section discusses of the compression of the different CoAP header fields. 4.1. CoAP version field(2 bits)This field is bidirectional andcanmust be elided during the SCHC compression, since it always contains the same value.It appears only in first position. FID FL FP DI Value MO CDA Sent ver 2 1 bi 1 equal not-sent 3.2.In the future, if new version of CoAPtype field This field can be managed bidirectionally or unidirectionally.Several strategies canare defined, new rules ID will beapplied to thisdefined avoiding ambiguities between versions. 4.2. CoAP type fieldregarding[rfc7252] defines 4 types of messages: CON, NON, ACK and RST. The latter two ones are a response of thevalues used: otwo first ones. If theES isdevice plays aclient orspecific role, aServer and non confirmable message are used,rule can exploit these property with thetransmission ofmapping list: [CON, NON] for one direction and [ACK, RST] for theType field can be avoided: * Posother direction. Compression residue isalways 1, * DI can eitherreduced to 1 bit. The field must be"uplink"elided ifthe ES isfor instance aCoAPclientor "downlink" if the ESisa CoAP server,sending only NON or"bidirectional" * TV is set to the value, * MO is setCON messages. In any case, a rule must be defined to"equal" * CDA is setcarry RST to"not-sent". FID FL FP DI Target Value MO CDA Senta client. 4.3. CoAP code field The compression of the CoAP code field follows the same principle as for the CoAP type2 1 bi NON equal not-sent ofield. If theES is either a client ordevice plays aServer and confirmable message are used,specific role, theDIset of code values can beused to elide the type onsplit in two parts, the request codes with the 0 class andcompress it to 1 bit ontheresponse. The example above showsresponse values. If therule for a ES acting asdevice implement only a CoAP client,directions need tothe request code can bereversed for a ES acting as a server. FID FL FP DI TV MO CDA Sent type 2 1 up CON equal not-sent type 2 1 dw [ACK,RST] match-mapping mapping-sent [1] o Otherwise ifreduced to the set of request theES is acting simultaneously as aclientand a server andis able to process. All therule handle these two traffics, Type field mustresponse codes should besent uncompressed. FID FL FP DI TV MO CDA Sent type 2 1 bi ignore send-value [2] 3.3.compressed with a SCHC rule. 4.4. CoAPtoken lengthMessage ID field This field isbi-directional. Several strategies can be appliedbidirectional and is used tothis field regardingmanage acknowledgments. Server memorizes thevalues: o no token orvalue for awellknown length, the transmission can be avoided. A special care must be taken, ifEXCHANGE_LIFETIME period (by default 247 seconds) for CON messagesare acknowledged with an empty ACK message. Inand a NON_LIFETIME period (by default 145 seconds) for NON messages. During thatcaseperiod, a server receiving thetoken is not always present. FID FL FP DI TV MO CDA Sent TKL 4 1 bisame Message ID valueignore send-value [4] o Ifwill process thelength is changing from onemessageto an other,has a retransmission. After this period, it will be processed as a new messages. In case theToken LengthDevice is a client, the size of the message ID fieldmust be sent. Ifmay theToken lengthtoo large regarding the number of messages sent. Client may use only small message ID values, for instance 4 bit long. Therefore a MSB can belimited, then only the least significant bits haveused to limit the size of the compression residue. In case the Device is a server, client may besent. The example below allows values between 0located outside of the LPWAN area and3. FID FL FP DI TV MO CDA Sent TKL 4 1 bi 0x0 MSB(2) LSB(2) [2] o otherwiseview thefield value hasdevice as a regular device connected tobe sent. FID FL FP DI TV MO CDA Sent TKL 4 1 bi ignore value-sent [4] 3.4.the internet. The client will generate Message ID using the 16 bits space offered by this field. A CoAPcode field This field is bidirectional, but compressionproxy can beenhanced using DI. The CoAP Code field defines a tricky wayset before the SCHC C/D to reduce the value of the Message ID, toensure compatibilityallow its compression withHTTP values. Nevertheless only 21 values arethe MSB matching operator and LSB CDA. 4.5. CoAP Token fields Token is definedby [rfc7252] compared tothrough two CoAP fields, Token Length in the255 possible values. +------+------------------------------+-----------+ | Code | Description | Mapping | +------+------------------------------+-----------+ | 0.00 | | 0x00 | | 0.01 | GET | 0x01 | | 0.02 | POST | 0x02 | | 0.03 | PUT | 0x03 | | 0.04 | DELETE | 0x04 | | 0.05 | FETCH | 0x05 | | 0.06 | PATCH | 0x06 | | 0.07 | iPATCH | 0x07 | | 2.01 | Created | 0x08 | | 2.02 | Deleted | 0x09 | | 2.03 | Valid | 0x0A | | 2.04 | Changed | 0x0B | | 2.05 | Content | 0x0C | | 4.00 | Bad Request | 0x0D | | 4.01 | Unauthorized | 0x0E | | 4.02 | Bad Option | 0x0F | | 4.03 | Forbidden | 0x10 | | 4.04 | Not Found | 0x11 | | 4.05 | Method Not Allowed | 0x12 | | 4.06 | Not Acceptable | 0x13 | | 4.12 | Precondition Failed | 0x14 | | 4.13 | Request Entity Too Large | 0x15 | | 4.15 | Unsupported Content-Format | 0x16 | | 5.00 | Internal Server Error | 0x17 | | 5.01 | Not Implemented | 0x18 | | 5.02 | Bad Gateway | 0x19 | | 5.03 | Service Unavailable | 0x1A | | 5.04 | Gateway Timeout | 0x1B | | 5.05 | Proxying Not Supported | 0x1C | +------+------------------------------+-----------+ Figure 1: Example of CoAP code mapping Figure 1 gives a possible mapping, it can be changed to add new codes or reduced if some values are never used by both ends. It could efficiently be coded on 5 bits. Even if the number of code can be increase with other RFC, implementations may use a limited number of values, which can help to reduce the number of bits sent on the LPWAN. The number of code may vary over time, some new codes may be introduced or some applications use a limited number of values. The client and the server do not use the same values. This asymmetry can be exploited to reduce the size sent on the LPWAN. 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. If the ES always sends or receives requests with the same method, the Code field can be elided. The entry below shows a rule for a client sending only GET request. FID FL FP DI TV MO CDA Sent code 8 1 up GET equal not-sent If the client may send different methods, a matching-list can be applied. For table Figure 1, 3 bits are necessary, but it could be less if fewer methods are used. Example below gives an example where the ES is a server and receives only GETmandatory header andPOST requests. FID FL FP DI TargetToken ValueMO CDA Sent code 8 1 dw [0.01, 0.02] match-mapping mapping-sent [1] The same approach can be applied to responses. 3.5.directly following the mandatory CoAPMessage ID field This field is bidirectional. Message IDheader. Token Length isused for two purposes: o To acknowledge a CON message with an ACK. o To avoid duplicate messages. In LPWAN, since a message can be received by several radio gateway, some LPWAN technologies includeprocessed as asequence number in L2 to avoid duplicate frames. Therefore if the message does not need to be acknowledged (NON or RST message),tradition protocol field. If theMessage ID field can be avoided. FID FL FP DI TV MO CDA Sent Mid 8 1 bi ignore not-sent The decompressor must generate a value. [[Note; check id this field is not used by OSCOAP .]] To optimize information sent onvalue remains theLPWAN, shorter values may be usedsame during all theexchange, but Message ID values generated a common CoAP implementation will not take into account this limitation. Beforetransaction, thecompression, a proxy maysize can beneeded to reduce the size. FID FL FP DI TV MO CDA Sent Mid 8 1 bi 0x0000 MSB(12) LSB(4) [4] Otherwise if no compression is possible,stored in thefield has to be sent FID FL FP DI TV MO CDA Sent Mid 8 1 bi ignore value-sent [8] 3.6. CoAP Token field This field is bi-directional. Token is used to identify transactionscontext andvaries 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 neededelided during the transmission. Otherwise it will have toreducethe send as a compression residue. Token Value sizeofshould not be defined directly in thetoken before compression. The size ofrule in thecompress token sent is known byField Length (FL). Instead acombinationspecific function designed as "TKL" must be used. This function informs the SCHC C/D that the length of this field has to be read from the Token Lengthfield and the rule entry. For instance, with the entry below: FID FL FP DI TV MO CDA Sent tkl 4 1 bi 2 equal not-sent token 8 1 bi 0x00 MSB(12) LSB(4) [4] The uncompressed token is 2 bytes long, but the compressed size will be 4 bits. 4.field. 5. CoAP options4.1.5.1. CoAPoption Content-format field. ThisContent and Accept options. These fieldisare both 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 single value is expected by the client, it can be stored in the TVcontains that value and MO is set to "equal"and elided during theCDF is set to "not-sent". The examples below describe the rules for an ES acting as a server. FID FL FP DI TV MO CDA Sent content 16 1 up value equal not-sent Iftransmission. Otherwise, if several possiblevaluevalues are expected by the client, a matching-listcanshould beused. FID FL FP DI TV MO CDA Sent content 16 1 up [50, 41] match-mapping mapping-sent [1] Otherwiseused to limit thevalue can be sent.The value-sent CDF insize of thecompressor doresidue. If notsend the option type and the decompressor reconstruct it regardingtheposition inpossible, therule. FID FL FP DI TV MO CDA Sent content 16 1 up ignore value-sent [0-16] 4.2.value as to be sent as a residue (fixed or variable length). 5.2. CoAP optionAccept fieldMax-Age field, CoAP option Uri-Host and Uri-Port fields This field is unidirectional and must not be set to bidirectional in a rule entry. It is used only by theclientserver to inform of thepossible payload typecaching duration and is never found inserver response. The number of accept optionsclient requests. If the duration isnot limited andknown by both ends, value canvary regardingbe elided on theusage. ToLPWAN. A matching list can beselectedused if some well-known values are defined. Otherwise these options should be sent as aruleresidue (fixed or variable length). 5.3. CoAP option Uri-Path and Uri-Query fields This fields are unidirectional and mustcontain the exact number about accept options with their positions. Since the ordernot be set to bidirectional inwhicha rule entry. They are used only by theAccept valueclient to access to a specific resource and aresent,never found in server responses. Uri-Path and Uri-Query elements are a repeatable options, the Field Position (FP) gives the positionorderin the path. A Mapping list can bemodified. The rule below FID FL FP DI TV MO CDA Sent accept 16 1 up 41 egal not-sent accept 16 2 up 50 egal not-sent willused to reduce size of variable Paths or Queries. In that case, to optimize the compression, several elements can beselected only if two accept options are inregrouped into a single entry. Numbering of elements do not change, MO comparison is set with theCoAP header if this order. The rule below:first element of the matching. FID FL FP DI TV MO CDASent accept 16 0URI-Path 1 up41 egal["/a/b", equal not-sentaccept 16 0"/c/d"] URI-Path 3 up50 egal not-sent will accept a-only CoAP messages withignore value-sent Figure 2: complex path example In Figure 2accept options, buta single bit residue can be used to code one of theorder will2 paths. If regrouping was notinfluence the rule selection. The decompression will reconstructallowed, a 2 bits residue whould have been needed. 5.3.1. Variable length Uri-Path and Uri-Query When theheader regardinglength is known at the ruleorder. Otherwise a matching-list cancreation, the Field Length must beappliedset to variable, and thedifferent values, in that case the orderunit isimportantset torecover the appropriatebytes. The MSB MO can be apply to a Uri-Path or Uri-Query element. Since MSB valueandis given in bit, thepositionsize must always beclearly indicate. FID FL FP DI TV MOa multiple of 8 bits and the LSB CDASent accept 16 1 up [50,41] match-mapping mapping-sent [1] accept 16 2 up [50,61] match-mapping mapping-sent [1] accept 16 3 up [61,71] match-mapping mapping-sent [1] Finally,must not carry any value. The length sent at theoptionbeginning of a variable length residue indicates the size of the LSB in bytes. For instance for a CoMi path /c/X6?k="eth0" the rule can beexplicitly sent.set to: FID FL FP DI TV MO CDASent acceptURI-Path 1 up "c" equal not-sent URI-Path 2 up ignore value-sent4.3. CoAP option Max-Age field, CoAP option Uri-HostURI-Query 1 up "k=" MSB (16) LSB Figure 3: CoMi URI compression Figure 3 shows the parsing andUri-Port fields This fieldthe compression of the URI. where c isunidirectional and mustnotbe set to bidirectional in a rule entry. Itsent. The second element isused onlysent with the length (i.e. 0x2 X 6) followed by theserver to informquery option (i.e. 0x05 "eth0"). 5.3.2. Variable number ofthe caching duration and is never foundpath or query elements The number of Uri-path or Uri-Query element inclient requests.a rule is fixed at the rule creation time. If theduration is known by both ends, value cannumber varies, several rules should beelided oncreated to cover all theLPWAN. A matching list can be used if some wellknown values are defined. Otherwisepossibilities. Another possibilities is to define theoptionlength of Uri-Path to variable andvalue can be sent on the LPWAN. [[note: we can reduce (or createsend anew option) the unitcompression residue with a length of 0 tominute, secondindicate that this Uri-Path issmall for LPWAN ]] 5.empty. This add 4 bits to the compression residue. 5.4. CoAP optionUri-PathSize1, Size2, Proxy-URI andUri-QueryProxy-Scheme fieldsThisThese 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.The Matching Operator behavior has not changed, butIf the field value musttake a position value, if the entry is repeated : FID FL FP DIbe sent, TV is not set, MOCDA Sent URI-Path 1 up foo equal not-sent URI-Path 2 up bar equal not-sent Figure 2: Position entry. For instance,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" 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path and Location-Query fields These fields are unidirectional. These fields values cannot be stored in a ruleFigure 2 matchesentry. They must always be sent with/foo/bar, butthe compression residues. 6. Other RFCs 6.1. Block Block [rfc7959] allows a fragmentation at the CoAP level. SCHC includes also a fragmentation protocol. They are compatible. If a block option is used, its content must be sent as a compression residue. 6.2. Observe [rfc7641] defines the Observe option. The TV is not/bar/ foo. Whenset, MO is set to "ignore" and thelengthCDF is set to "value-sent". SCHC does notclearly indicated inlimit therule,maximum size for this option (3 bytes). To reduce the transmission size either the device implementation should limit the valuelength mustincrease or a proxy can modify the incrementation. Since RST message may be sentwith the field data, which means for CoAPtosend directlyinform a server that theCoAPclient do not require Observe response, a rule must allow the transmission of this message. 6.3. No-Response [rfc7967] defines an No-Response optionwith length and value. For instance forlimiting the responses made by aCoMi path /c/X6?k="eth0"server to a request. If therule can be set to: FID FL FP DIvalue is not known by both ends, then TV is set to this value, MOCDA Sent URI-Path 1 up c equal not-sent URI-Path 2 up ignore value-sent URI-Query 1 up k= MSB (16) LSB Figure 3: CoMi URI compression Figure 3 shows the parsingis set to "equal" and CDF is set to "not-sent". Otherwise, if thecompression of the URI. where cvalue is changing over time, TV is notsent. The second elementset, MO issent with the length (i.e. 0x2 X 6) followed by the query option (i.e. 0x05 "eth0").set to "ignore" and CDA to "value-sent". AMappingmatching list can also be used to reducesize of variable Paths or Queries. In that case,the size. 6.4. Time Scale Time scale [I-D.toutain-core-time-scale] option allows a client tooptimizeinform thecompression, several elements canserver that it is in a slow network and that message ID should beregrouped intokept for asingle entry. Numbering of elements doduration given by the option. If the value is notchange,known by both ends, then TV is set to this value, MOcomparisonis setwith the first element ofto "equal" and CDA is set to "not-sent". Otherwise, if thematching. FID FL FP DIvalue is changing over time, TV is not set, MO is set to "ignore" and CDASent URI-Pathto "value-sent". A matching list can also be used to reduce the size. 6.5. OSCORE OSCORE [I-D.ietf-core-object-security] defines end-to-end protection for CoAP messages. This section describes how SCHC rules can be applied to compress OSCORE-protected messages. 0 1up {0:"/c/c", equal not-sent 1:"/c/d" URI-Path2 3up ignore value-sent URI-Query4 5 6 7 <--------- n bytes -------------> +-+-+-+-+-+-+-+-+--------------------------------- |0 0 0|h|k| n | Partial IV (if any) ... +-+-+-+-+-+-+-+-+--------------------------------- | | | <--------- CoAP OSCORE_piv ------------------> | <- 1up k= MSB (16) LSBbyte -> <------ s bytes -----> +------------+----------------------+-----------------------+ | s (if any) | kid context (if any) | kid (if any) ... | +------------+----------------------+-----------------------+ | | | | <------ CoAP OSCORE_kidctxt ----->|<-- CoAP OSCORE_kid -->| Figure 4:complex path example For instance, the following Path /foo/bar/variable/stable can leads toOSCORE Option The encoding of theruleOSCORE Option Value defined in Section 6.1 of [I-D.ietf-core-object-security] is repeated in Figure 4.5.1. CoAP option Proxy-URI and Proxy-Scheme fields These fieldsThe first byte is used for flags that specify the contents of the OSCORE option. The 3 most significant bits areunidirectionalreserved andmust not bealways set tobidirectional0. Bit h, when set, indicates the presence of the kid context field ina rule entry. They are used only bytheclientoption. Bit k, when set, indicates the presence of a kid field. The 3 least significant bits n indicate toaccesslength of the piv field in bytes, n = 0 taken toa specific resourcemean that no piv is present. After the flag byte follow the piv field, kid context field andare never foundkid field inserver response. Iforder and if present; the length of the kid context fieldvalue must be sent, TV is not set, MOissetencoded in the first byte denoting by s the length of the kid context in bytes. This draft recommends to"ignore" and CDFimplement a parser that issetable to"value-sent. A mapping can also be used. Otherwiseidentify theTV is setOSCORE Option and the fields it contains - this makes it possible to do a preliminary processing of thevalue, MO is setmessage in preparation for regular SCHC compression. Conceptually, the OSCORE option can transmit up to"equal"3 distinct pieces of information at a time: the piv, the kid context, andCDF is set to "not-sent" 5.2.the kid. This draft proposes that the SCHC Parser split the contents of this option into 3 SCHC fields: o CoAP OSCORE_piv, o CoAPoption ETag, If-Match, If-None-Match, Location-Path and Location-Query fieldsOSCORE_ctxt, o CoAP OSCORE_kid. These fields areunidirectional. These fields values cannot be stored in a rule entry. They must always be sent withsuperposed on therequest. [[Can include OSCOAP Object security in that category ]] 6. Other RFCs 6.1. Block Block option should be avoidedOSCORE Option format inLPWAN. The minimumFigure 4, and include the corresponding flag and size bits for each part of16 bytesthe option. Both the flag and size bits can beincompatibleomitted by use of the MSB matching operator on each field. 7. Examples of CoAP header compression 7.1. Mandatory header withsome LPWAN technologies. [[Note: do we recommandCON message In this first scenario, the LPWANfragmentation sincecompressor receives from outside client a POST message, which is immediately acknowledged by the Device. For this simple scenario, the rules are described Figure 5. Rule ID 1 +-------------+--+--+--+------+---------+-------------++------------+ | Field |FL|FP|DI|Target| Match | CDA || Sent | | | | | |Value | Opera. | || [bits] | +-------------+--+--+--+------+---------+-------------++------------+ |CoAP version | | |bi| 01 |equal |not-sent || | |CoAP version | | |bi| 01 |equal |not-sent || | |CoAP Type | | |dw| CON |equal |not-sent || | |CoAP Type | | |up|[ACK, | | || | | | | | | RST] |match-map|matching-sent|| T | |CoAP TKL | | |bi| 0 |equal |not-sent || | |CoAP Code | | |bi| ML1 |match-map|matching-sent|| CC CCC | |CoAP MID | | |bi| 0000 |MSB(7 ) |LSB(9) || M-ID| |CoAP Uri-Path| | |dw| path |equal 1 |not-sent || | +-------------+--+--+--+------+---------+-------------++------------+ Figure 5: CoAP Context to compress header without token The version and Token Length fields are elided. Code has shrunk to 5 bits using a matching list. Uri-Path contains a single element indicated in thesmallest valuematching operator. Figure 6 shows the time diagram of16 is too big?]] 6.2. Observe [rfc7641] definestheObserve option. The TV is not set, MO is setexchange. A client in the Application Server sends a CON request. It can go through a proxy which reduces the message ID to"ignore" anda smallest value, with at least theCDF is set9 most significant bits equal to"value-sent".0. SCHCdoes not limit the maximum size for this option (3 bytes). To reduceCompression reduces thetransmission size eitherheader sending only theThing implementation should limitType, a mapped code and thevalue increase orleast 9 significant bits of Message ID. Device LPWAN SCHC C/D | | | rule id=1 |<-------------------- |<-------------------| +-+-+--+----+------+ <------------------- | CCCCCMMMMMMMMM | |1|0| 4|0.01|0x0034| +-+-+--+----+-------+ | 00001000110100 | | 0xb4 p aproxy can be used limitt| |1|0| 1|0.01|0x0034 | | | | h | | 0xb4 p a t | | | +------+ | h | | | +------+ | | | | | | ---------------------->| rule id=1 | +-+-+--+----+--------+ |------------------->| |1|2| 0|2.05| 0x0034 | | TCCCCCMMMMMMMMM |---------------------> +-+-+--+----+--------+ | 001100000110100 | +-+-+--+----+------+ | | |1|2| 0|2.05|0x0034| v v +-+-+--+----+------+ Figure 6: Compression with global addresses 7.2. Complete exchange In that example, theincrease. Since RST message may be sentThing is using CoMi and sends queries for 2 SID. CON MID=0x0012 | | POST | | Accept X | | /c/k=AS |------------------------>| | | | | |<------------------------| ACK MID=0x0012 | | 0.00 | | | | |<------------------------| CON | | MID=0X0034 | | Content-Format X ACK MID=0x0034 |------------------------>| 0.00 7.3. OSCORE Compression OSCORE aims toinform a server that the client do not require Observe response, a rule must allowsolve thetransmissionproblem ofthis message. 6.3. No-Response [rfc7967] defines an No-Response option limiting the responses made by a serverend-to-end encryption for CoAP messages, which are otherwise required toa request. Ifterminate their TLS or DTLS protection at thevalue isproxy, as discussed in Section 11.2 of [rfc7252]. CoAP proxies are men-in-the-middle, but notby both ends, then TV is setall of the information they have access tothis value, MOisset to "equal" and CDFnecessary for their operation. The goal, therefore, issetto"not- sent". Otherwise, ifhide as much of thevaluemessage as possible while still enabling proxy operation. Conceptually this ischanging over time, TVachieved by splitting the CoAP message into an Inner Plaintext and Outer OSCORE Message. The Inner Plaintext contains sensible information which is notset, MOnecessary for proxy operation. This, in turn, isset to "ignore" and CDF to "value-sent". A matching list can also be used to reducethesize. 7. Protocol analysis 8. Examplespart ofCoAP header compression 8.1. Mandatory header with CONthe messageIn this first scenario,which can be encrypted and need not be decrypted until it reaches its end destination. The Outer Message acts as a shell matching theLPWAN compressor receives from outside clientformat of aPOSTregular CoAP message,whichand includes all Options and information needed for proxy operation and caching. This decomposition isimmediately acknowledgedillustrated in Figure 7. CoAP options are sorted into one of 3 classes, each granted a specific type of protection by theThing. For this simple scenario,protocol: o Class E: Enrypted options moved to therules are described Figure 5. Rule ID 1 +-------------+--+--+--+------+---------+-------------++------------+Inner Plaintext, o Class I: Intergrity-protected options included in the AAD for the encryption of the Plaintext but otherwise left untouched in the Outer Message, o Class U: Unprotected options left untouched in the Outer Message. Additionally, the OSCORE Option is added as an Outer option, signaling that the message is OSCORE protected. This option carries the information necessary to retrieve the Security Context with which the message was encrypted so that it may be correctly decrypted at the other end-point. Orignal CoAP Message +-+-+---+-------+---------------+ |v|t|tkl| code |Field |FL|FP|DI|Target| MatchMsg Id. |CDA || Sent+-+-+---+-------+---------------+....+ | Token | +-------------------------------.....+ | Options (IEU) | . . . . +------+-------------------+ ||Value0xFF |Opera.+------+------------------------+ ||| [bits]|+-------------+--+--+--+------+---------+-------------++------------+ |CoAP version| Payload ||bi| 01 |equal |not-sent ||||CoAP version| +-------------------------------+ / \ / \ / \ / \ Outer Header v v Plaintext +-+-+---+--------+---------------+ +-------+ |v|t|tkl|new code| Msg Id. ||bi| 01 |equal |not-sent ||||CoAP Typecode | +-+-+---+--------+---------------+....+ +-------+-----......+ ||bi| |ignore |value-sent ||TTToken ||CoAP TKL| Options (E) ||bi| 0 |equal |not-sent ||+--------------------------------.....+ +-------+------.....+ ||CoAP CodeOptions (IU) | ||bi| ML1 |match-map|matching-sent|| CC CCCOxFF ||CoAP MID. . +-------+-----------+ . OSCORE Option . | ||bi| 0000 |MSB(7 ) |LSB(9) || M-ID| |CoAP Uri-Path|+------+-------------------+ ||dw| path |equal 1 |not-sent ||Payload |+-------------+--+--+--+------+---------+-------------++------------+ Figure 5: CoAP Context to compress header without token The version and Token Length fields are elided. Code has shrunk to 5 bits using the matching list (as the one given| 0xFF | | | +------+ +-------------------+ Figure1: 0.01 is value 0x017: OSCORE inner and2.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 throughouter header form a CoAPproxy. Uri-Path contains a single element indicated in the matching operator.message Figure67 shows thetime diagram ofmessage format for theexchange. A LPWAN Application Server sends a CON message. Compression reducesOSCORE Message and Plaintext. In theheader sending onlyOuter Header, theType, a mappedoriginal message code is hidden and replaced by a default value (POST or FETCH) depending on whether theleast 9 significant bits of Message ID. The receiver decompresses the header. .original message was a Request or a Response. TheCONoriginal message code isa request, thereforeput into theLC process to a dynamic mapping. Whenfirst byte of theES receivesPlaintext. Following theACK message, this will not initiate locally amessageID mapping since it is a response. The LC receivescode come theACKclass E options anduncompressed it to restoreif present the original message Payload preceded by its payload marker. The Plaintext is now encrypted by an AEAD algorithm which integrity protects Security Context parameters and eventually any class I options from the Outer Header. Currently no CoAP options are marked class I. The resulting Ciphertext becomes theoriginal value. Dynamic Mapping context lifetime followsnew Payload of thesame rulesOSCORE message, asmessage ID duration. End System LPWA LC | | | rule id=1 |<-------------------- |<-------------------| +-+-+--+----+------+ <------------------- | TTCC CCCM MMMM MMMM| |1|0| 4|0.01|0x0034| +-+-+--+----+-------+ | 0000 0010 0011 0100| | 0xb4 p a t| |1|0| 1|0.01|0x0034 | | | | h | | 0xb4 p a t | | | +------+ | hillustrated in Figure 8. Outer Header +-+-+---+--------+---------------+ |v|t|tkl|new code| Msg Id. | +-+-+---+--------+---------------+....+ | Token |+------++--------------------------------.....+ | Options (IU) | . . . OSCORE Option . +------+-------------------+ | 0xFF | +------+-------------------------+ | |---------------------->| rule id=1|+-+-+--+----+--------+ |------------------->| |1|2| 0|2.05| 0x0034Encrypted Inner Header and | |TTCC CCCM MMMM MMMM|---------------------> +-+-+--+----+--------+Payload |1001 1000 0011 0100| +-+-+--+----+------+| ||1|2| 0|2.05|0x0034| v v +-+-+--+----+------++--------------------------------+ Figure6: Compression with global addresses8: OSCORE message The SCHC Compression scheme consists of compressing both the Plaintext before encryption and the resulting OSCORE messagecan be further optimized by setting some fields unidirectional, as described inafter encryption, see Figure7. 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 code9. This way compression reaches all fields of therequests and 21 tooriginal CoAP message. Outer Message OSCORE Plaintext +-+-+---+--------+---------------+ +-------+ |v|t|tkl|new code| Msg Id. | | codeall the responses in the matching list Figure 1) Rule ID 2 +-------------+--+--+--+------+---------+------------++------------+|Field |FL|FP|DI|Target| MO+-+-+---+--------+---------------+....+ +-------+-----......+ |CDA || SentToken | | Options (E) | +--------------------------------.....+ +-------+------.....+ | Options (IU) ||Value| OxFF ||| [bits]. . +-------+-----------+ . OSCORE Option . |+-------------+--+--+--+------+---------+------------++------------+ |CoAP version| +------+-------------------+ ||bi|01 |equal |not-sent ||Payload ||CoAP Type| 0xFF ||dw|CON |equal |not-sent ||||CoAP Type| +------+------------+ +-------------------+ ||up| ACK |equal |not-sent ||Ciphertext |<---------\ ||CoAP TKL| ||bi|0 |equal |not-sent ||||CoAP Codev +-------------------+ | +-----------------+ ||dw|ML2 |match-map|mapping-sent||CCCC C||CoAP Code| Inner SCHC ||up|ML3 |match-map|mapping-sent||CCCC Cv ||CoAP MID| Compression ||bi|0000 |MSB(5) |LSB(11) || M-ID+-----------------+ ||CoAP Uri-Path|+-----------------+ ||dw|path |equal 1 |not-sent ||Outer SCHC |+-------------+--+--+--+------+---------+------------++------------+ ML1 = {CON : 0, ACK:1} ML2 = {POST:0, 2.04:1, 0.00:3} Figure 7: CoAP Context to compress header without token 8.2. Complete exchange In that example, the Thing is using CoMi and sends queries for 2 SID. CON MID=0x0012| |POST| Compression |Accept X| v +-----------------+ |/c/k=AS |------------------------>|+-------+ | | |Rule ID| v | +-------+--+ +--------+ +------------+ ||<------------------------| ACK MID=0x0012Residue | |Rule ID'| | Encryption | <--- +----------+--------+ +--------+--+ +------------+ | | | Residue' |0.00| Payload | +-----------+-------+ | ||<------------------------| CON| Ciphertext |MID=0X0034+-------------------+ | |Content-Format X+-------------------+ Figure 9: OSCORE Compression Diagram 7.4. Example OSCORE Compression In what follows we present an example GET Request and consequent CONTENT Response and show a possible set of rules for the Inner and Outer SCHC Compression. We then show a dump of the results and contrast SCHC + OSCORE performance with SCHC + COAP performance. This gives an approximation to the cost of security with SCHC-OSCORE. Our first example CoAP message is the GET Request in Figure 10 Original message: ================= 0x4101000182bb74656d7065726174757265 Header: 0x4101 01 Ver 00 CON 0001 tkl 00000001 Request Code 1 "GET" 0x0001 = mid 0x82 = token Options: 0xbb74656d7065726174757265 Option 11: URI_PATH Value = temperature Original msg length: 17 bytes. Figure 10: CoAP GET Request Its corresponding response is the CONTENT Response in Figure 11. Original message: ================= 0x6145000182ff32332043 Header: 0x6145 01 Ver 10 ACKMID=0x0034 |------------------------>| 0.000001 tkl 01000101 Successful Response Code 69 "2.05 Content" 0x0001 = mid 0x82 = token 0xFF Payload marker Payload: 0x32332043 Original msg length: 10 Figure 11: CoAP CONTENT Response The SCHC Rules for the Inner Compression include all fields that are already present in a regular CoAP message, what matters is the order of appearance and inclusion of only those CoAP fields that go into the Plaintext, Figure 12. Rule ID3 +--------------+--+--+--+------+--------+-----------++------------+0 +----------------+--+--+-----------+-----------+-----------++--------+ | Field|FL|FP|DI|Target||FP|DI| Target | MO | CDA || Sent | | | | ||ValueValue | | || [bits] |+--------------+--+--+--+------+--------+-----------++------------+ |CoAP version | | |bi| 01 |equal |not-sent || |+----------------+--+--+-----------+-----------+-----------++--------+ |CoAPType |Code | |up|CON |equal |not-sent || | |CoAP Type | | |dw| ACK |equal |not-sent || | |CoAP TKL | | |bi|1|equal |not-sent || | |CoAP Code|| |up| POST |equalequal |not-sent || | |CoAP Code | |dw|[69,132] ||dw| 0.00 |equal |not-sentmatch-map |match-sent ||| |CoAP MID | | |bi| 0000 |MSB(8) |LSB ||MMMMMMMM | |CoAP Token | | |up| |ignore |send-value ||TTTTTTTTc | |CoAP Uri-Path || |dw| /c |equal 1|up|temperature| equal |not-sent || ||CoAP Uri-query||COAP Option-End | |dw|ML4 |equal 1 |not-sent ||P0xFF ||CoAP Content | | |up| X |equalequal |not-sent || |+--------------+--+--+--+------+--------+-----------++------------++----------------+--+--+-----------+-----------+-----------++--------+ Figure 12: Inner SCHC Rules The Outer SCHC Rules (Figure 13) must process the OSCORE Options fields. Here we mask off the repeated bits (most importantly the flag and size bits) with the MSB Mathing Operator. Rule ID4 +--------------+--+--+--+------+--------+-----------++------------+0 +---------------+--+--+--------------+---------+-----------++------------+ | Field|FL|FP|DI|Target||FP|DI| Target | MO | CDA || Sent | | | | ||ValueValue | | || [bits] |+--------------+--+--+--+------+--------+-----------++------------++---------------+--+--+--------------+---------+-----------++------------+ |CoAP version |||bi| 01 |equal |not-sent || | |CoAP Type || |dw| CON|up| 0 |equal |not-sent || | |CoAP Type || |up| ACK|dw| 2 |equal |not-sent || | |CoAP TKL |||bi| 1 |equal |not-sent || | |CoAP Code || |dw| 2.05|up| 2 |equal |not-sent || | |CoAP Code| | |up| 0.00| |dw| 68 |equal |not-sent || | |CoAP MID |||bi| 0000|MSB(8)|MSB(12) |LSB||MMMMMMMM||MMMM | |CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT ||dw| |ignore |send-value||TTTTTTTT|CoAP OSCORE_piv| |up| 0x0900 |MSB(12) |LSB ||PPPP | |COAPAcceptOSCORE_kid| |up|b'\x06client' |MSB(52) |LSB ||KKKK | |CoAP OSCORE_piv| |dw| b'' |equal |not-sent || | |COAP Option-End| |dw|X0xFF |equal |not-sent || |+--------------+--+--+--+------+---------+----------++------------+ alternative rule:+---------------+--+--+--------------+---------+-----------++------------+ Figure 13: Outer SCHC Rules Next we show a dump of the compressed message: Compressed message: ================== 0x00291287f0a5c4833760d170 0x00 = Rule ID4 +--------------+--+--+--+------+---------+-----------++------------+piv = 0x04 Compression residue: 0b0001 010 0100 0100 (15 bits -> 2 bytes with padding) mid tkn piv kid Payload 0xa1fc297120cdd8345c Compressed message length: 12 bytes Figure 14: SCHC-OSCORE Compressed GET Request Compressed message: ================== 0x0015f4de9cb814c96aed9b1d981a3a58 0x00 = Rule ID Compression residue: 0b0001 010 (7 bits -> 1 byte with padding) mid tkn Payload 0xfa6f4e5c0a64b576cd8ecc0d1d2c Compressed msg length: 16 bytes Figure 15: SCHC-OSCORE Compressed CONTENT Response For contrast, we compare these results with what would be obtained by SCHC compressing the original CoAP messages without protecting them with OSCORE. To do this, we compress the CoAP mesages according to the SCHC rules in Figure 16. Rule ID 1 +---------------+--+--+-----------+---------+-----------++------------+ | Field|FL|FP|DI|Target||FP|DI| Target | MO | CDA || Sent | | | | ||ValueValue | | || [bits] |+--------------+--+--+--+------+---------+-----------++------------++---------------+--+--+-----------+---------+-----------++------------+ |CoAP version |||bi| 01 |equal |not-sent || | |CoAP Type | |up| 0 |equal |not-sent || ||bi| ML1 |match-map|match-sent ||t|CoAP Type | |dw| 2 |equal |not-sent || | |CoAP TKL |||bi| 1 |equal |not-sent || | |CoAP Code |||up|ML2 |match-map|match-sent2 |equal |not-sent ||cc| |CoAP Code |||dw|ML3 |match-map|match-sent[69,132] |equal |not-sent ||cc| |CoAP MID |||bi| 0000|MSB(8)|MSB(12) |LSB||MMMMMMMM||MMMM | |CoAP Token || |dw| |ignore |send-value ||TTTTTTTT|bi| 0x80 |MSB(5) |LSB ||TTT | |CoAP Uri-Path || |dw| /c |equal 1 |not-sent || | |CoAP Uri-query| | |dw| ML4 |equal 1 |not-sent ||P | |CoAP Content | | |up| X |equal|up|temperature|equal |not-sent || | |COAPAccept | |Option-End| |dw|x0xFF |equal |not-sent || |+--------------+--+--+--+------+---------+-----------++------------+ ML1 {CON:0, ACK:1} ML2 {POST:0, 0.00: 1} ML3 {2.05:0, 0.00:1} ML4 {NULL:0, k=AS:1, K=AZE:2} 9.+---------------+--+--+-----------+---------+-----------++------------+ Figure 16: SCHC-CoAP Rules (No OSCORE) This yields the results in Figure 17 for the Request, and Figure 18 for the Response. Compressed message: ================== 0x0114 0x01 = Rule ID Compression residue: 0b00010100 (1 byte) Compressed msg length: 2 Figure 17: CoAP GET Compressed without OSCORE Compressed message: ================== 0x010a32332043 0x01 = Rule ID Compression residue: 0b00001010 (1 byte) Payload 0x32332043 Compressed msg length: 6 Figure 18: CoAP CONTENT Compressed without OSCORE As can be seen, the difference between applying SCHC + OSCORE as compared to regular SCHC + COAP is about 10 bytes of cost. 8. Normative References[I-D.toutain-lpwan-ipv6-static-context-hc] Minaburo, A.[I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", draft-ietf-core-object-security-13 (work in progress), June 2018. [I-D.ietf-lpwan-ipv6-static-context-hc] Minaburo, A., Toutain, L., Gomez, C., and D. Barthel, "LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP",draft-toutain-lpwan- ipv6-static-context-hc-00draft-ietf-lpwan-ipv6- static-context-hc-16 (work in progress),September 2016.June 2018. [I-D.toutain-core-time-scale] Minaburo, A. and L. Toutain, "CoAP Time Scale Option", draft-toutain-core-time-scale-00 (work in progress), October 2017. [rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. [rfc7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>. [rfc7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>. [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, <https://www.rfc-editor.org/info/rfc7967>. Authors' Addresses Ana Minaburo Acklio2bis rue de la Chataigneraie1137A avenue des Champs Blancs 35510 Cesson-Sevigne Cedex France Email: ana@ackl.io Laurent Toutain Institut MINES TELECOM; IMT Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@imt-atlantique.fr Ricardo Andreasen Universidad de Buenos Aires Av. Paseo Colon 850 C1063ACV Ciudad Autonoma de Buenos Aires Argentina Email: randreasen@fi.uba.ar