Internet DRAFT - draft-lampin-lpwan-schc-considerations
draft-lampin-lpwan-schc-considerations
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8724>.
[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,
<https://www.rfc-editor.org/info/rfc8824>.
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, <https://www.ietf.org/archive/id/draft-
ietf-lpwan-schc-yang-data-model-21.txt>.
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,
<https://www.rfc-editor.org/info/rfc8376>.
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]
