Internet DRAFT - draft-pelov-lpwan-architecture
draft-pelov-lpwan-architecture
LPWAN Working Group A. Pelov
Internet-Draft Acklio
Intended status: Informational P. Thubert
Expires: October 31, 2021 Cisco Systems
A. Minaburo
Acklio
April 29, 2021
LPWAN Static Context Header Compression (SCHC) Architecture
draft-pelov-lpwan-architecture-02
Abstract
This document defines the LPWAN SCHC architecture.
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 October 31, 2021.
Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Pelov, et al. Expires October 31, 2021 [Page 1]
Internet-Draft LPWAN Architecture April 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. LPWAN Technologies and Profiles . . . . . . . . . . . . . . . 2
3. The Static Context Header Compression . . . . . . . . . . . . 3
4. SCHC Endpoints . . . . . . . . . . . . . . . . . . . . . . . 3
5. SCHC Instances . . . . . . . . . . . . . . . . . . . . . . . 4
6. SCHC Data Model . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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. [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.
2. LPWAN Technologies and Profiles
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.
Pelov, et al. Expires October 31, 2021 [Page 2]
Internet-Draft LPWAN Architecture April 2021
3. The Static Context Header Compression
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 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.
4. SCHC Endpoints
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
Figure 1: Typical LPWAN Network Architecture
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
Pelov, et al. Expires October 31, 2021 [Page 3]
Internet-Draft LPWAN Architecture April 2021
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.
[I-D.thubert-intarea-schc-over-ppp] describes an alternate 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
Figure 2: PPP-based SCHC Deployment
5. SCHC Instances
The rule database contains a set of rules that are specific per
device. There is thus a SCHC instance per pair of endpoints.
[rfc8724] 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.
[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,
Pelov, et al. Expires October 31, 2021 [Page 4]
Internet-Draft LPWAN Architecture April 2021
[I-D.ietf-lpwan-coap-static-context-hc] extends the compression to
CoAP [RFC7252] and OSCORE [RFC8613].
As represented figure Figure 3, 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.
(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 . . SCHC . . . .
r H .......... .......... . . .
k C . LPWAN . . LPWAN . . . .
.......... .................. ..........
((((LPWAN)))) ------ Internet ------
Figure 3: Different SCHC instances in a global system
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.
6. SCHC Data Model
A SCHC instance, summarized in the Figure 4, implies C/D and/or F/R
present in both end and that both ends are provisionned with the same
set of rules.
Pelov, et al. Expires October 31, 2021 [Page 5]
Internet-Draft LPWAN Architecture April 2021
(-------) (-------)
( Rules ) ( Rules )
(-------) (-------)
. read . read
. .
+-------+ +-------+
<===| R & D |<=== <===| C & F |<===
===>| C & F |===> ===>| R & D |===>
+-------+ +-------+
+-------+
Figure 4: Summarized SCHC elements
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,
[I-D.ietf-lpwan-schc-yang-data-model] defines a rule representation
using the YANG [1] formalism.
[I-D.ietf-lpwan-schc-yang-data-model] 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 |===>
+-------+
Figure 5: Summerized SCHC elements
The Rule Manager (RM) is in charge of handling data derived from the
YANG Data Model and apply changes to the rules database Figure 5.
The RM is a application using the Internet to exchange information,
therefore:
o for the network-level SCHC, the communication does not require
routing. Each of the end-points having an RM and both RMs can be
Pelov, et al. Expires October 31, 2021 [Page 6]
Internet-Draft LPWAN Architecture April 2021
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.
o 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 [I-D.thubert-intarea-schc-over-ppp]. The RM traffic
may be itself compressed by SCHC, especially if CORECONF is used,
[I-D.ietf-lpwan-coap-static-context-hc] can be used.
7. Security Considerations
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.
8. IANA Consideration
This document has no request to IANA
9. Acknowledgements
The authors would like to thank (in alphabetic order):
10. References
10.1. Normative References
[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>.
[rfc9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context
Header Compression and Fragmentation (SCHC) over LoRaWAN",
RFC 9011, DOI 10.17487/RFC9011, April 2021,
<https://www.rfc-editor.org/info/rfc9011>.
Pelov, et al. Expires October 31, 2021 [Page 7]
Internet-Draft LPWAN Architecture April 2021
10.2. Informative References
[I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.
Petrov, "CoAP Management Interface (CORECONF)", draft-
ietf-core-comi-11 (work in progress), January 2021.
[I-D.ietf-lpwan-coap-static-context-hc]
Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static
Context Header Compression (SCHC) for CoAP", draft-ietf-
lpwan-coap-static-context-hc-19 (work in progress), March
2021.
[I-D.ietf-lpwan-schc-yang-data-model]
Minaburo, A. and L. Toutain, "Data Model for Static
Context Header Compression (SCHC)", draft-ietf-lpwan-schc-
yang-data-model-04 (work in progress), February 2021.
[I-D.thubert-intarea-schc-over-ppp]
Thubert, P., "SCHC over PPP", draft-thubert-intarea-schc-
over-ppp-03 (work in progress), April 2021.
[rfc2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
February 1999, <https://www.rfc-editor.org/info/rfc2516>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[rfc8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>.
Pelov, et al. Expires October 31, 2021 [Page 8]
Internet-Draft LPWAN Architecture April 2021
[rfc8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[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>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
10.3. URIs
[1] RFC7950
Authors' Addresses
Alexander Pelov
Acklio
1137A avenue des Champs Blancs
35510 Cesson-Sevigne Cedex
France
Email: a@ackl.io
Pascal Thubert
Cisco Systems
45 Allee des Ormes - BP1200
06254 Mougins - Sophia Antipolis
France
Email: pthubert@cisco.com
Pelov, et al. Expires October 31, 2021 [Page 9]
Internet-Draft LPWAN Architecture April 2021
Ana Minaburo
Acklio
1137A avenue des Champs Blancs
35510 Cesson-Sevigne Cedex
France
Email: ana@ackl.io
Pelov, et al. Expires October 31, 2021 [Page 10]
