LPWAN Static Context Header Compression (SCHC) ArchitectureAcklio1137A avenue des Champs Blancs35510 Cesson-Sevigne CedexFrancea@ackl.ioCisco Systems45 Allee des Ormes - BP120006254 Mougins - Sophia AntipolisFrancepthubert@cisco.comAcklio1137A avenue des Champs Blancs35510 Cesson-Sevigne CedexFranceana@ackl.io
Internet
LPWAN Working GroupThis document defines the LPWAN SCHC architecture.The IETF LPWAN WG defined the necessary operations to enable IPv6 over
selected Low-Power Wide Area Networking (LPWAN) radio technologies.
presents an overview of those technologies.The Static Context Header Compression (SCHC) technology is the core
product of the IETF LPWAN working group. 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 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 lists the information that an LPWAN
technology-specific document must provide to profile SCHC for that technology.As an example, provides the SCHC profile for LoRaWAN networks.SCHC 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. also provides a Fragmentation/Reassembly (F/R) capability to cope
with the maximum 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 nature of a ruleID allows to determine if it is a compression or
fragmentation rule.Section 3 of depicts a typical network architecture for
an LPWAN network, simplified from that shown in and reproduced in
.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 (Apps) 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 provisionned in the network .Then again, 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 can provisionned in advance.
describes an alternate deployment where
the C/D and/or F/R operations are performed between peers of equal capabilities
over a PPP 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) , ensuring that the peers use the exact same set of rules.The rule database contains a set of rules that are specific per device.
There is thus a SCHC instance per pair of endpoints.
states that a SCHC instance obtains the rules to process
C/D and F/R before the session starts, and that rules cannot be modified during
the session. was defined to compress IPv6 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, extends the compression to CoAP and
OSCORE .As represented figure , the fragmentation and 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.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 woeking group to design an operational and interoperable
framework for allowing IP application over contrained networks.A SCHC instance, summarized in the , implies C/D and/or F/R present in both end and that both ends are provisionned with the same set of rules.To be able to provision end-points from different vendors, a common rule representation is needed that expresses the SCHC rules in an interoperable
fashion. To that effect, defines a rule representation using the
YANG formalism. defines an YANG data model to represent the rules. This enables the use of several protocols for rule management, such as NETCONF, RESTCONF, and CORECONF. 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 under RESTCONF and in CBOR under CORECONF.The Rule Manager (RM) is in charge of handling data derived from the YANG Data
Model and apply changes to the rules database .The RM is a application using the Internet to exchange information, therefore:for the network-level SCHC, the communication does not require routing. Each of the end-points having an RM and both RMs can be viewed on the same link, therefore wellknown Link Local addresses can be used to identify the device and the core RM. L2 security MAY be deemed as sufficient, if it provides the necessary level of protection.for application-level SCHC, routing is involved and global IP addresses SHOULD be used. End-to-end encryption is RECOMMENDED.Management messages can also be carried in the negotiation protocol as proposed in .
The RM traffic may be itself compressed by SCHC, especially if CORECONF is used, can be used.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 IANAThe authors would like to thank (in alphabetic order):SCHC: Generic Framework for Static Context Header Compression and FragmentationThis document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.Static Context Header Compression and Fragmentation (SCHC) over LoRaWANThe Static Context Header Compression and fragmentation (SCHC) specification (RFC 8724) describes generic header compression and fragmentation techniques for Low-Power Wide Area Network (LPWAN) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies.This document defines a profile of SCHC (RFC 8724) for use in LoRaWAN networks and provides elements such as efficient parameterization and modes of operation.Internet Protocol, Version 6 (IPv6) SpecificationThis document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.Low-Power Wide Area Network (LPWAN) OverviewLow-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.Data Model for Static Context Header Compression (SCHC)This document describes a YANG data model for the SCHC (Static Context Header Compression) compression and fragmentation rules.LPWAN Static Context Header Compression (SCHC) for CoAPThis draft defines how to compress the Constrained Application Protocol (CoAP) using the Static Context Header Compression (SCHC). SCHC is a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC for CoAP headers. The CoAP header structure differs from IPv6 and UDP since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP protocol messages format is asymmetric: the request messages have a header format different from the one in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.SCHC over PPPThis document extends RFC 5172 to signal the use of SCHC as the compression method between a pair of nodes over PPP. Combined with RFC 2516, this enables the use of SCHC over Ethernet and Wi-Fi.CoAP Management Interface (CORECONF)This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks.A Method for Transmitting PPP Over Ethernet (PPPoE)This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community.Uniform Resource Names (URNs)A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.Object Security for Constrained RESTful Environments (OSCORE)This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).The JavaScript Object Notation (JSON) Data Interchange FormatJavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.Concise Binary Object Representation (CBOR)The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.