| Internet-Draft | SCHC Architecture | October 2023 |
| Pelov, et al. | Expires 5 April 2024 | [Page] |
This document defines the SCHC architecture.¶
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 5 April 2024.¶
Copyright (c) 2023 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.¶
The IETF LPWAN WG defined the necessary operations to enable IPv6 over selected Low-Power Wide Area Networking (LPWAN) radio technologies. [rfc8376] presents an overview of those technologies.¶
The Static Context Header Compression (SCHC) [rfc8724] technology is the core product of the IETF LPWAN working group and was the basis to form the SCHC Working Group. [rfc8724] defines a generic framework for header compression and fragmentation, based on a static context that is pre-installed on the SCHC endpoints.¶
This document details the constitutive elements of a SCHC-based solution, and how the solution can be deployed. It provides a general architecture for a SCHC deployment, positioning the required specifications, describing the possible deployment types, and indicating models whereby the rules can be distributed and installed to enable reliable and scalable operations.¶
Because LPWAN technologies [rfc8376] have strict yet distinct constraints, e.g., in terms of maximum frame size, throughput, and/or directionality, a SCHC instance must be profiled to adapt to the specific necessities of the technology to which it is applied.¶
Appendix D. "SCHC Parameters" of [rfc8724] lists the information that an LPWAN technology-specific document must provide to profile SCHC for that technology.¶
As an example, [rfc9011] provides the SCHC profile for LoRaWAN networks.¶
SCHC [rfc8724] specifies an extreme compression capability based on a state that must match on the compressor and decompressor side. This state comprises a set of Compression/Decompression (C/D) rules.¶
The SCHC Parser analyzes incoming packets and creates a list of fields that it matches against the compression rules. The rule that matches best is used to compress the packet, and the rule identifier (RuleID) is transmitted together with the compression residue to the decompressor. Based on the RuleID and the residue, the decompressor can rebuild the original packet and forward it in its uncompressed form over the Internet.¶
[rfc8724] also provides a Fragmentation/Reassembly (F/R) capability to cope with the maximum and/or variable frame size of a Link, which is extremely constrained in the case of an LPWAN network.¶
If a SCHC-compressed packet is too large to be sent in a single Link-Layer PDU, the SCHC fragmentation can be applied on the compressed packet. The process of SCHC fragmentation is similar to that of compression; the fragmentation rules that are programmed for this Device are checked to find the most appropriate one, regarding the SCHC packet size, the link error rate, and the reliability level required by the application.¶
The ruleID allows to determine if it is a compression or fragmentation rule.¶
[rfc8724] was defined to compress IPv6 [rfc8200] and UDP; but SCHC really is a generic compression and fragmentation technology. As such, SCHC is agnostic to which protocol it compresses and at which layer it is operated. The C/D peers may be hosted by different entities for different layers, and the F/R operation may also be performed between different parties, or different sub-layers in the same stack, and/or managed by different organizations.¶
If a protocol or a layer requires additional capabilities, it is always possible to document more specifically how to use SCHC in that context, or to specify additional behaviours. For instance, [rfc8824] extends the compression to CoAP [RFC7252] and OSCORE [RFC8613].¶
Section 3 of [rfc8724] depicts a typical network architecture for an LPWAN network, simplified from that shown in [rfc8376] and reproduced in Figure 1.¶
() () () | () () () () / \ +---------+ () () () () () () / \======| ^ | +-----------+ () () () | | <--|--> | |Application| () () () () / \==========| v |=============| Server | () () () / \ +---------+ +-----------+ Dev RGWs NGW App
Typically, an LPWAN network topology is star-oriented, which means that all packets between the same source-destination pair follow the same path from/to a central point. In that model, highly constrained Devices (Dev) exchange information with LPWAN Application Servers (App) through a central Network Gateway (NGW), which can be powered and is typically a lot less constrained than the Devices. Because Devices embed built-in applications, the traffic flows to be compressed are known in advance and the location of the C/D and F/R functions (e.g., at the Dev and NGW), and the associated rules, can be pre provisioned in the system before use.¶
The SCHC operation requires a shared sense of which SCHC Device is Uplink (Dev to App) and which is Downlink (App to Dev), see [rfc8376]. In a star deployment, the hub is always considered Uplink and the spokes are Downlink. The expectation is that the hub and spoke derive knowledge of their role from the network configuration and SCHC does not need to signal which is hub thus Uplink vs. which is spoke thus Downlink. In other words, the link direction is determined from extrinsic properties, and is not advertised in the protocol.¶
Nevertheless, SCHC is very generic and its applicability is not limited to star-oriented deployments and/or to use cases where applications are very static and the state provisioned in advance. In particular, a peer-to-peer (P2P) SCHC Instance (see Section 5.2) may be set up between peers of equivalent capabilities, and the link direction cannot be inferred, either from the network topology nor from the device capability.¶
In that case, by convention, the device that initiates the connection that sustains the SCHC Instance is considered as being Downlink, IOW it plays the role of the Dev in [rfc8724].¶
This convention can be reversed, e.g., by configuration, but for proper SCHC operation, it is required that the method used ensures that both ends are aware of their role, and then again this determination is based on extrinsic properties.¶
[rfc8724] defines a protocol operation between a pair of peers. A session called a SCHC Instance is established and SCHC maintains a state and timers associated to that Instance.¶
When the SCHC Device is a highly constrained unit, there is typically only one Instance for that Device, and all the traffic from and to the device is exchanged with the same Network Gateway. All the traffic can thus be implicitly associated with the single Instance that the device supports, and the Device does not need to manipulate the concept. For that reason, SCHC avoids to signal explicitly the Instance identification in its data packets.¶
The Network Gateway, on the other hand, maintains multiple Instances, one per SCHC Device. The Instance is derived from the lower layer, typically the source of an incoming SCHC packet. The Instance is used in particular to select from the rule database the set of rules that apply to the SCHC Device, and the current state of their exchange, e.g., timers and previous fragments.¶
This architecture generalizes the model to any kind of peers. In the case of more capable devices, a SCHC Device may maintain more than one Instance with the same peer, or a set of different peers. Since SCHC does not signal the Instance in its packets, the information must be derived from a lower layer point to point information. For instance, the SCHC session can be associated one-to-one with a tunnel, a TLS session, or a TCP or a PPP connection.¶
For instance, [I-D.thubert-schc-over-ppp] describes a type of deployment where the C/D and/or F/R operations are performed between peers of equal capabilities over a PPP [rfc2516] connection. SCHC over PPP illustrates that with SCHC, the protocols that are compressed can be discovered dynamically and the rules can be fetched on-demand by both parties from the same Uniform Resource Name (URN) [rfc8141], ensuring that the peers use the exact same set of rules.¶
+----------+ Wi-Fi / +----------+ ....
| IP | Ethernet | IP | .. )
| Host +-----/------+ Router +----------( Internet )
| SCHC C/D | Serial | SCHC C/D | ( )
+----------+ +----------+ ...
<-- SCHC -->
over PPP
In that case, the SCHC Instance is derived from the PPP connection. This means that there can be only one Instance per PPP connection, and that all the flow and only the flow of that Instance is exchanged within the PPP connection. As discussed in Section 5.1, the Uplink direction is from the node that initiated the PPP connection to the node that accepted it.¶
[rfc8724] states that a SCHC instance needs the rules to process C/D and F/R before the session starts, and that rules cannot be modified during the session.¶
As represented figure Figure 3, the compression of the IP and UDP headers may be operated by a network SCHC instance whereas the end-to-end compression of the application payload happens between the Device and the application. The compression of the application payload may be split in two instances to deal with the encrypted portion of the application PDU. Fragmentation applies before LPWAN transportation layer.¶
(Device) (NGW) (App)
+--------+ +--------+
A S | CoAP | | CoAP |
p C | inner | | inner |
p H +--------+ +--------+
. C | SCHC | | SCHC |
| inner | cryptographical boundary | inner |
-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
A S | CoAP | | CoAP |
p C | outer | | outer |
p H +--------+ +--------+
. C | SCHC | | SCHC |
| outer | layer / functional boundary | outer |
-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
N . UDP . . UDP .
e .......... .................. ..........
t . IPv6 . . IPv6 . . IPv6 .
w S .......... .................. ..........
o C .SCHC/L3 . . SCHC/L3. . . .
r H .......... .......... . . .
k C . LPWAN . . LPWAN . . . .
.......... .................. ..........
((((LPWAN)))) ------ Internet ------
This document defines a generic architecture for SCHC that can be used at any of these levels. The goal of the architectural document is to orchestrate the different protocols and data model defined by the LPWAN and SCHC working groups to design an operational and interoperable framework for allowing IP application over contrained networks.¶
SCHC can be used in multiple environments and multiple protocols. It was designed by default to work on native MAC frames with LPWAN technologies such as LoRaWAN[rfc9011], IEEE std 802.15.4 [I-D.ietf-6lo-schc-15dot4], and SigFox[rfc9442].¶
To operate SCHC over Ethernet, IPv6, and UDP, the definition of, respectively, an Ethertype, an IP Protocol Number, and a UDP Port Number are necessary, more in [I-D.ietf-intarea-schc-protocol-numbers]. In either case, there's a need for a SCHC header that is sufficient to identify the SCHC peers (endpoints) and their role (device vs. app), as well as the session between those peers that the packet pertains to.¶
In either of the above cases, the expectation is that the SCHC header is transferred in a compressed form. This implies that the rules to uncompress the header are well known and separate from the rules that are used to uncompress the SCHC payload. The expectation is that for each layer, the format of the SCHC header and the compression rules are well known, with enough information to identify the session at that layer, but there is no expectation that they are the same across layers.¶
Before the SCHC compression takes place, the SCHC header shows as header as represented figure Figure 4, that is virtually inserted before the real protocol header and data that are compressed in the session, e.g. a IPv6 in this figure.¶
+------------------+------------------+-------------+-----------
| IEEE 802 Header | SCHC Header | IPv6 Header | IPv6 NH
| Ethertype = SCHC | Ethertype = IPv6 | | / ULP
+------------------+------------------+-------------+-----------
<-
SCHC overhead
->
In the case of IPv6, the expectation is that the ULP checksum can be elided in the SCHC compression of the ULP, because the SCHC header has its own checksum that protects both the SCHC header and the whole ULP, header and payload.¶
Before any compression takes place, the SCHC header shows as an IPv6 extension header as represented figure Figure 5, that is virtually inserted before the headers and data that are compressed in the session, e.g. a ULP in this figure¶
+-------------+-------------+------------+-----------
| IPv6 Header | SCHC Header | ULP Header | ULP PDU
| NH=SCHC | NH = ULP | | (Payload)
+-------------+-------------+------------+-----------
<-
SCHC overhead
->
In the air, both the SCHC header (using well-known rules) and the ULP (using the rules indicated in the session) are compressed. The session endpoints are typically identified by the source and destination IP addresses. If the roles are well-known, then the endpoint information can be elided and deduced from the IP header. If there is only one session, it can be elided as well, otherwise a rule and residue are needed to extract the session ID. Finally, the SCHC extension header should contain a checksum that protects itself and all the ULP, so the ULP checksum can be elided in the compressed form of the ULP header.¶
When SCHC operates over the Internet, middleboxes may block packets with a next header that is SCHC. To avoid that issue, it would be desirable to prepaend a UDP header before the SCHC header as shown in figure Figure 6.¶
+-------------+-------------+-------------+------------+-----------
| IPv6 Header | UDP Header | SCHC Header | ULP Header | ULP PDU
| NH=UDP | Port = SCHC | NH = ULP | | (Payload)
+-------------+-------------+-------------+------------+-----------
<-
SCHC overhead
->
~
In that case, the destination port can indicate SCHC as in an header chain, and the source port can indicate the SCHC session in which case it can be elided in the compressed form of the SCHC header. The UDP checksum protects both the SCHC header and the whole ULP, so the SCHC and the ULP checksums can both be elided. In other words, in the SCHC over UDP case, the SCHC header can be fully elided, but the packet must carry the overhead of a full UDP header.¶
A SCHC instance, summarized in the Figure 7, implies C/D and/or F/R present in both end and that both ends are provisioned with the same set of rules.¶
(-------) (-------)
( Rules ) ( Rules )
(-------) (-------)
. read . read
. .
+-------+ +-------+
<===| R & D |<=== <===| C & F |<===
===>| C & F |===> ===>| R & D |===>
+-------+
A common rule representation that expresses the SCHC rules in an interoperable fashion is needed to be able to provision end-points from different vendors to that effect, [rfc9363] defines a rule representation using the YANG [rfc7950] formalism.¶
[rfc9363] defines an YANG data model to represent the rules. This enables the use of several protocols for rule management, such as NETCONF[RFC6241], RESTCONF[RFC8040], and CORECONF[I-D.ietf-core-comi]. NETCONF uses SSH, RESTCONF uses HTTPS, and CORECONF uses CoAP(s) as their respective transport layer protocols. The data is represented in XML under NETCONF, in JSON[RFC8259] under RESTCONF and in CBOR[RFC8949] under CORECONF.¶
create
(-------) read +=======+ *
( rules )<------->|Rule |<--|-------->
(-------) update |Manager| NETCONF, RESTCONF or CORECONF
. read delete +=======+ request
.
+-------+
<===| R & D |<===
===>| C & F |===>
+-------+
The Rule Manager (RM) is in charge of handling data derived from the YANG Data Model and apply changes to the rules database Figure 8.¶
The RM is an Application using the Internet to exchange information, therefore:¶
Management messages can also be carried in the negotiation protocol as proposed in [I-D.thubert-schc-over-ppp]. The RM traffic may be itself compressed by SCHC: if CORECONF protocol is used, [rfc8824] can be applied.¶
In the context of LPWANs, the expectation is that SCHC rules are associated with a physical device that is deployed in a network. This section describes the actions taken to enable an automatic commissioning of the device in the network.¶
The expectation for the development cycle is that message formats are documented as a data model that is used to generate rules. Several models are possible:¶
Depending on the deployment, the tools that generate the Rules should provide knobs to optimize the Rule set, e.g., more rules vs. larger residue.¶
In the device model and in the protocol model, at least one of the endpoints must obtain the rule set dynamically. The expectation is that the Rule Sets are published to a reachable repository and versionned (minor, major). Each rule set should have its own Uniform Resource Names (URN) [RFC8141] and a version.¶
The Rule Set should be authenticated to ensure that it is genuine, or obtained from a trusted app store. A corrupted Rule Set may be used for multiple forms of attacks, more in Section 9.¶
The device and the network should mutually authenticate themselves. The autonomic approach [RFC8993] provides a model to achieve this at scale with zero touch, in networks where enough bandwidth and compute are available. In highly constrained networks, one touch is usually necessary to program keys in the devices.¶
The initial handshake between the SCHC endpoints should comprise a capability exchange whereby URN and the version of the rule set are obtained or compared. SCHC may not be used if both ends can not agree on an URN and a major version. Manufacturer Usage Descriptions (MUD) [RFC8520] may be used for that purpose in the device model.¶
Upon the handshake, both ends can agree on a rule set, their role when the rules are asymmetrical, and fetch the rule set if necessary. Optionally, a node that fetched a rule set may inform the other end that it is reacy from transmission.¶
URN update without device update (bug fix) FUOTA => new URN => reprovisioning¶
Signal from device/vendor/network admin¶
SCHC is sensitive to the rules that could be abused to form arbitrary long messages or as a form of attack against the C/D and/or F/R functions, say to generate a buffer overflow and either modify the Device or crash it. It is thus critical to ensure that the rules are distributed in a fashion that is protected against tempering, e.g., encrypted and signed.¶
This document has no request to IANA¶
The authors would like to thank (in alphabetic order):¶