SCHC design and implementation considerations

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 on 14 May 2023.¶

Copyright Notice

Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This is a reflexion on SCHC [RFC8724] and its use for LPWANs [RFC8376].¶

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.¶

2. Terminology

This draft re-uses the Terminology defined in [RFC8724].¶

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. 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 [RFC8724]).¶

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.¶

4. What is a packet field?

[RFC8724] 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.¶

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version| Traffic Class |           Flow Label                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Payload Length        |  Next Header  |   Hop Limit   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                         Source Address                        +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                      Destination Address                      +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Furthermore, parts of the RFC suggest that fields might be seen in a broader sense. Section 7.1 and [RFC8824] refer to the "CoAP URI Path" option as a field and this is further confirmed in [I-D.ietf-lpwan-schc-yang-data-model], 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 Figure 2.¶

    0   1   2   3   4   5   6   7
    +---------------+---------------+
    |               |               |
    |  Option Delta | Option Length |   1 byte
    |               |               |
    +---------------+---------------+
    |                               |
    |         Option Delta          |   0-2 bytes
    |          (extended)           |
    +-------------------------------+
    |                               |
    |         Option Length         |   0-2 bytes
    |          (extended)           |
    +-------------------------------+
    |                               |
    |                               |
    |                               |
    |         Option Value          |   0 or more bytes
    |                               |
    |                               |
    |                               |
    +-------------------------------+

5. Tokenization, Parsing, Decoding, Interpretation?

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.¶

6. Implication of interpreted fields in the SCHC data model

[I-D.ietf-lpwan-schc-yang-data-model] 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 [I-D.ietf-lpwan-schc-yang-data-model] 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.¶

7. Security considerations

N/A¶

8. IANA Considerations

N/A¶

Author's Address