SCHC design and implementation considerations

Introduction This is a reflexion on SCHC and its use for LPWANs . This document captures the author's reflections during its implementation of the SCHC protocol (C/D) in microSCHC. This is a work-in-progress and might contain mistakes or misinterpretations.

Terminology This draft re-uses the Terminology defined in . The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Parser description in RFC8724 SCHC C/D assumes that both ends of a SCHC communication implement a parser alongside the implementation of the rule matching, compression and decompression procedures. This parser, whose specification is out of scope of the RFC, "is able to identify all the fields encountered in the headers to be compressed, and to label them with a Field ID. Rules only describe the compression/decompression behavior for each header field, after it has been identified." (Section 7.1 of ). Sections 7.1 and 10 and Appendix A provide further insights as to what the parser is expected to output for a field:

Field ID (FID) [string | integer | ...] unique identifier for a given ruleset.
Field Length (FL) [integer | type].
Field Position (FP) [integer].
Field Value (FV) [type]

where type can be anything: integers, bytes, arrays, etc.

What is a packet field? does not provide a formal definition of a packet field but the examples provided in Appendix A, figures 26 to 28, suggest the use of the colloquial definition, i.e. a sequence of continuous bits of the frame provided by the underlying layer. For example, the following IPv6 packet would be parsed as 8 fields : IPv6 Version, Traffic Class, etc.

Furthermore, parts of the RFC suggest that fields might be seen in a broader sense. Section 7.1 and refer to the "CoAP URI Path" option as a field and this is further confirmed in , where subfields are introduced. The case of "CoAP URI Path" is an interesting one, as it is not a on-the-wire field but an abstract construct based on the decoding and interpretation of on-the-wire fields, namely "CoAP Option Delta", "CoAP Option Length", "CoAP Option Delta Extended" (if any), "CoAP Option Length Extended" (if any) and "CoAP Option Value", illustrated below .

As illustrated in the previous section, some level of interpretation is expected from the parser which raises the question of its roles and expected capabilities. Depending on the protocol to parse, the parser might be required to execute:

tokenization: the tokenization consists in extracting sequential bits from the on-the-wire packet buffer and expose those as tokens or raw fields.
parsing: parsing adds labels and meta-data to raw fields, in SCHC such labels and meta-data include the Field ID, Field Length, Position Indicator, etc.
decoding: decoding consists in processing a number of raw fields to extract information needed for processing the packet further, e.g., determine the length of a variable length field.
interpretation: interpretation consists in providing an alternative representation of the information carried by one or several raw fields, a good example of this is the representation of CoAP options as fields.

provides YANG data models to describe the IPv6, UDP and CoAP headers and those models determine the itemization or, practically speaking, the list of fields, their IDs, the type and encoding of the internal representation used by C/D and so forth. In particular, the CoAP model provided in lists CoAP Options as fields but not the raw fields constituting the CoAP Option header on-the-wire. A SCHC parser implementation must therefore include some level of interpretation.

Depending on the characteristics of the packets to be compressed between two SCHC endpoints, one set of fields representations might provide better compression performance than another. This yields the question of the support of multiple interpretations of the same on-the-wire frame and how to enable it. In particular, does it require to list fields representations in the SCHC data model?

Supporting new protocols in SCHC, or extensions of them (e.g. new CoAP Options) requires updating the data model of . Assuming becomes an RFC, it would require updates every now and then. Limiting this need for updates is certainly beneficial.

More specifically, should the data model include: CoAP Option Delta, CoAP Option Length, CoAP Option Delta Extended, CoAP Option Length Extended, CoAP Option Value, CoAP Payload Marker? A study on the complexity (memory, code, ...) vs compression efficiency of rules on interpreted fields compared to equivalent rules on raw fields would be interesting.

TBD.

N/A