lpwan Working Group Q. Lampin Internet-Draft Orange Intended status: Informational 10 November 2022 Expires: 14 May 2023 SCHC design and implementation considerations draft-lampin-lpwan-schc-considerations-00 Abstract Taking the opportunity of a fresh implementation of SCHC by a newcomer to SCHC to reflect on the design principles and the implications on the implication of SCHC. Topics addressed: * The parser, as described in SCHC specification. * A discussion on parsing and interpretation. * Practical implications of the specification of the parser of SCHC. * the challenge and opportunity of a generic parser implementation able to handle any protocol stack and rules design to enable it. 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. Lampin Expires 14 May 2023 [Page 1] Internet-Draft SCHC considerations November 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Parser description in RFC8724 . . . . . . . . . . . . . . . . 3 4. What is a packet field? . . . . . . . . . . . . . . . . . . . 3 5. Tokenization, Parsing, Decoding, Interpretation? . . . . . . 5 6. Implication of interpreted fields in the SCHC data model . . 6 6.1. Discussion #1: On supporting multiple interpretations of the same on-the-wire header fields . . . . . . . . . . . 6 6.2. Discussion #2: On supporting new protocols or protocol extensions . . . . . . . . . . . . . . . . . . . . . . . 6 6.3. Question: Would it be beneficial to include CoAP Options raw fields in the data model? . . . . . . . . . . . . . . 6 6.4. Arbitrary types and matching operators . . . . . . . . . 7 7. Security considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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]. Lampin Expires 14 May 2023 [Page 2] Internet-Draft SCHC considerations November 2022 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. Lampin Expires 14 May 2023 [Page 3] Internet-Draft SCHC considerations November 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IPv6 header format 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. Lampin Expires 14 May 2023 [Page 4] Internet-Draft SCHC considerations November 2022 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 | | | | | | +-------------------------------+ Figure 2: CoAP option header format 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. Lampin Expires 14 May 2023 [Page 5] Internet-Draft SCHC considerations November 2022 * *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*. 6.1. Discussion #1: On supporting multiple interpretations of the same on-the-wire header fields 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? 6.2. Discussion #2: On supporting new protocols or protocol extensions Supporting new protocols in SCHC, or extensions of them (e.g. new CoAP Options) requires updating the data model of [I-D.ietf-lpwan-schc-yang-data-model]. Assuming [I-D.ietf-lpwan-schc-yang-data-model] becomes an RFC, it would require updates every now and then. Limiting this need for updates is certainly beneficial. 6.3. Question: Would it be beneficial to include CoAP Options raw fields in the data model? 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. Lampin Expires 14 May 2023 [Page 6] Internet-Draft SCHC considerations November 2022 6.4. Arbitrary types and matching operators TBD. 7. Security considerations N/A 8. IANA Considerations N/A 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, June 2021, . 9.2. Informative References [I-D.ietf-lpwan-schc-yang-data-model] Minaburo, A. and L. Toutain, "Data Model for Static Context Header Compression (SCHC)", Work in Progress, Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-21, 9 October 2022, . Lampin Expires 14 May 2023 [Page 7] Internet-Draft SCHC considerations November 2022 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, . Author's Address Quentin Lampin Orange 22 chemin du Vieux Chene 38240 Meylan France Email: quentin.lampin@orange.com Lampin Expires 14 May 2023 [Page 8]