idnits 2.17.1 draft-pelov-lpwan-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 287: '... MAY be deemed as sufficient, if ...' RFC 2119 keyword, line 291: '... addresses SHOULD be used. End-t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 268 has weird spacing: '... . read delet...' -- The document date (April 28, 2021) is 1094 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-lpwan-schc-yang-data-model-04 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group A. Pelov 3 Internet-Draft Acklio 4 Intended status: Informational P. Thubert 5 Expires: October 30, 2021 Cisco Systems 6 A. Minaburo 7 Acklio 8 April 28, 2021 10 LPWAN Static Context Header Compression (SCHC) Architecture 11 draft-pelov-lpwan-architecture-01 13 Abstract 15 This document defines the LPWAN SCHC architecture. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 30, 2021. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. SCHC Operation . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Global architecture . . . . . . . . . . . . . . . . . . . . . 5 55 5. Data management . . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 59 7.2. Informative References . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 62 1. Introduction 64 The IETF LPWAN WG defined the necessary operations to enable IPv6 65 over selected Low-Power Wide Area Networking (LPWAN) radio 66 technologies. [rfc8376] presents an overview of those technologies. 68 The core product of the working group is the Static Context Header 69 Compression (SCHC) [rfc8724] technology. 71 SCHC provides an extreme compression capability based on a state that 72 must match on the compressor and decompressor side. This state if 73 formed of an ordered set of Compression/Decompression (C/D) rules. 74 The first rule that matches is used to compress, and is indicated 75 with the compression residue. Based on the rule identifier (RuleID) 76 the decompressor can rebuild the original bitstream based on the 77 residue. 79 [rfc8724] also provides a Fragmentation/Reassembly (F/R) capability 80 to cope with a constrained Maximum Transmit Unit (MTU) below the IPv6 81 minimum link MTU of 1280 bytes (see section 5 of [rfc8200]), which is 82 typically the case on an LPWAN network. 84 [rfc8724] was defined to compress IPv6 and UDP; but SCHC really is a 85 generic compression and fragmentation technology. As such, SCHC is 86 agnostic to which protocol it compresses and at which layer it is 87 operated. The C/D peers may be hosted by different entities for 88 different layers, and the F/R operation may also be performed between 89 different parties, or different sub-layers in the same stack. 91 If a protocol or a layer requires additional capabilities, it is 92 always possible to document more specifically how to use SCHC in that 93 context, or to specify additional behaviours. For instance, 94 [I-D.ietf-lpwan-coap-static-context-hc] extends the compression to 95 CoAP [rfc7252] and OSCORE [rfc8613]. 97 SCHC is also designed to be profiled to adapt to the specific 98 necessities of the various LPWAN technologies to which it is applied. 99 Appendix D. "SCHC Parameters" of [rfc8724] lists the information 100 that an LPWAN technology-specific document must provide to profile 101 SCHC for that technology. As an example, [rfc9011] provides the 102 profile for LoRaWAN networks. 104 In order to deploy SCHC, it is mandatory that the C/D and F/R peers 105 are provisionned with the exact same set of rules. To be able to 106 provision end-points from different vendors, a common data model is 107 needed that expresses the SCHC rules in an interoperable fashion. To 108 that effect, [I-D.ietf-lpwan-schc-yang-data-model] defines a rule 109 representation using the YANG [rfc7950] formalism. 111 Finally, section 3 of [rfc8724] depicts a typical network 112 architecture for an LPWAN network, simplified from that shown in 113 [rfc8376]and reproduced in Figure 1. 115 () () () | 116 () () () () / \ +---------+ 117 () () () () () () / \======| ^ | +-----------+ 118 () () () | | <--|--> | |Application| 119 () () () () / \==========| v |=============| Server | 120 () () () / \ +---------+ +-----------+ 121 Dev RGWs NGW App 123 Figure 1: Typical LPWAN Network Architecture 125 Typically, an LPWAN network topology is star-oriented, which means 126 that all packets between the same source-destination pair follow the 127 same path from/to a central point. In that model, highly constrained 128 Devices (Dev) exchange information with LPWAN Application Servers 129 (Apps) through a central Network Gateway (NGW), which can be powered 130 and is typically a lot less constrained than the Devices. Because 131 devices embed built-in applications, the traffic flows to be 132 compressed are known in advance and the location of the C/D and F/R 133 functions (e.g., at the Dev and NGW), and the associated rules, can 134 be pre provisionned in the network . 136 Then again, SCHC is very generic and its applicability is not limited 137 to star-oriented deployments and/or to use cases where applications 138 are very static and the state can provisionned in advance. 139 [I-D.thubert-intarea-schc-over-ppp] describes an alternate deployment 140 where the C/D and/or F/R operations are performed between peers of 141 equal capabilities over a PPP [rfc2516] connection. SCHC over PPP 142 illustrates that with SCHC, the protocols that are compressed can be 143 discovered dynamically and the rules can be fetched on-demand by both 144 parties from the same Uniform Resource Name (URN) [rfc8141], ensuring 145 that the peers use the exact same set of rules. 147 +----------+ Wi-Fi / +----------+ .... 148 | IP | Ethernet | IP | .. ) 149 | Host +-----/------+ Router +----------( Internet ) 150 | SCHC C/D | Serial | SCHC C/D | ( ) 151 +----------+ +----------+ ... 152 <-- SCHC --> 153 over PPP 155 Figure 2: PPP-based SCHC Deployment 157 This document provides a general architecture for a SCHC deployment, 158 positioning the required specifications, describing the possible 159 deployment types, and indicating models whereby the rules can be 160 distributed and installed to enable reliable and scalable operations. 162 2. SCHC Operation 164 As [I-D.ietf-lpwan-coap-static-context-hc] states, the SCHC 165 compression and fragmentation mechanism can be implemented at 166 different levels and/or managed by different organizations. For 167 instance, as represented figure Figure 3, IP compression and 168 fragmentation may be managed by the network SCHC instance and end-to- 169 end compression between the device and the application. The former 170 can itself be split in two instances since encryption hides the field 171 structure. 173 (device) (NGW) (App) 175 +--------+ +--------+ 176 A S | CoAP | | CoAP | 177 p C | inner | | inner | 178 p H +--------+ +--------+ 179 . V | SCHC | | SCHC | 180 | inner | cryptographical boundary | inner | 181 -._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._ 182 A S | CoAP | | CoAP | 183 p C | outer | | outer | 184 p H +--------+ +--------+ 185 . C | SCHC | | SCHC | 186 | outer | functional boundary | outer | 187 -._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._ 188 N . udp . . udp . 189 e .......... .................. .......... 190 t . ipv6 . . ipv6 . . ipv6 . 191 w C .......... .................. .......... 192 o S . schc . . schc . . . . 193 r H .......... .......... . . . 194 k C . lpwan . . lpwan . . . . 195 .......... .................. .......... 196 ((((LPWAN)))) ------ Internet ------ 198 Figure 3: Different SCHC instances in a global system 200 This document defines a generic architecture for SCHC that can be 201 used at any of these levels. The goal of the architectural document 202 is to orchestrate the different protocols and data model defined by 203 the LPWAN woeking group to design an operational and interoperable 204 framework for allowing IP application over contrained networks. 206 3. Definitions 208 4. Global architecture 210 As described in [rfc8724] a SCHC service is composed of a Parser, 211 analyzing packets and creating a list of fields what will be used to 212 match against the compression rules. If a packet matches rules, 213 compression can be applied following rules instructions. 215 If SCHC compressed packet is too large to be send in a single L2 216 frame, fragmentation will apply. The process is similar, device 217 rules are checked to find the most appropriate fragmentation rule, 218 regarding the SCHC packet size, the link error rate, the reliability 219 required by the application, ... 221 On the other direction, when a packet SCHC arrives, the ruleID is 222 used to find the rule. Its nature allows to select if it is a 223 compression or fragmentation rule. 225 The rule database contains a set of rules specific to a single 226 device. The [rfc8724] indicates that the SCHC instance reads the 227 rules to process C/D and F/R, rules are not modified during these 228 actions. 230 A SCHC instance, summarized in the Figure 4, implies C/D and F/R 231 present in both end. The device connected to a constrained network 232 is in one end and the other end is either located in the core network 233 or at the application. 235 In any cases, the rules must be the same in both ends to perform C/D 236 and F/R. 238 (device) (core|app) 240 (---) (---) 241 ( r ) ( r ) 242 (---) (---) 243 . read . read 244 . . 245 +-----+ +-----+ 246 <===| R&D |<=..............................<=| C&F |<=== 247 ===>| C&F |=>..............................=>| R&D |===> 248 +-----+ +-----+ 250 Figure 4: Summarized SCHC elements 252 To enable rule synchronization between both ends, a common rule 253 representation must be defined. 255 5. Data management 257 [I-D.ietf-lpwan-schc-yang-data-model] defines an YANG data model to 258 represent the rules. This enables the use of several protocols for 259 rule management, such as NETCONF, RESTCONF and CORECONF. NETCONF 260 uses SSH, RESTCONF uses HTTPS, and CORECONF uses CoAP(s) as their 261 respective transport layer protocols. The data is represented in XML 262 under NETCONF, in JSON under RESTCONF and in CBOR under CORECONF. 264 create 265 (-------) read +=======+ * 266 ( rules )<------->|Rule |<--|--------> 267 (-------) update |Manager| NETCONF, RESTCONF or CORECONF 268 . read delete +=======+ request 269 . 270 +-------+ 271 <===| R & D |<=== 272 ===>| C & F |===> 273 +-------+ 275 Figure 5: Summerized SCHC elements 277 Rule Manager (RM) is in charge of handling data derived from the YANG 278 Data Model and apply changes to the rules database Figure 5. 280 The RM is a application using the Internet to exchange information, 281 therefore: 283 o for the network-level SCHC, the communication does not require 284 routing. Each of the end-points having an RM and both RMs can be 285 viewed on the same link, therefore wellknown Link Local addresses 286 can be used to identify the device and the core RM. L2 security 287 MAY be deemed as sufficient, if it provides the necessary level of 288 protection. 290 o for application-level SCHC, routing is involved and global IP 291 addresses SHOULD be used. End-to-end encryption is recommended. 293 Management messages can also be carried in the negotiation protocol 294 as proposed in [I-D.thubert-intarea-schc-over-ppp] 296 The RM traffic may be itself compressed by SCHC, especially if 297 CORECONF is used, [I-D.ietf-lpwan-coap-static-context-hc] can be 298 used. 300 6. Acknowledgements 302 The authors would like to thank (in alphabetic order): 304 7. References 306 7.1. Normative References 308 [rfc8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 309 Zuniga, "SCHC: Generic Framework for Static Context Header 310 Compression and Fragmentation", RFC 8724, 311 DOI 10.17487/RFC8724, April 2020, 312 . 314 7.2. Informative References 316 [I-D.ietf-lpwan-coap-static-context-hc] 317 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 318 Context Header Compression (SCHC) for CoAP", draft-ietf- 319 lpwan-coap-static-context-hc-19 (work in progress), March 320 2021. 322 [I-D.ietf-lpwan-schc-yang-data-model] 323 Minaburo, A. and L. Toutain, "Data Model for Static 324 Context Header Compression (SCHC)", draft-ietf-lpwan-schc- 325 yang-data-model-04 (work in progress), February 2021. 327 [I-D.thubert-intarea-schc-over-ppp] 328 Thubert, P., "SCHC over PPP", draft-thubert-intarea-schc- 329 over-ppp-03 (work in progress), April 2021. 331 [rfc2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 332 and R. Wheeler, "A Method for Transmitting PPP Over 333 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 334 February 1999, . 336 [rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 337 Application Protocol (CoAP)", RFC 7252, 338 DOI 10.17487/RFC7252, June 2014, 339 . 341 [rfc7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 342 RFC 7950, DOI 10.17487/RFC7950, August 2016, 343 . 345 [rfc8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 346 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 347 . 349 [rfc8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 350 (IPv6) Specification", STD 86, RFC 8200, 351 DOI 10.17487/RFC8200, July 2017, 352 . 354 [rfc8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 355 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 356 . 358 [rfc8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 359 "Object Security for Constrained RESTful Environments 360 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 361 . 363 [rfc9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context 364 Header Compression and Fragmentation (SCHC) over LoRaWAN", 365 RFC 9011, DOI 10.17487/RFC9011, April 2021, 366 . 368 Authors' Addresses 370 Alexander Pelov 371 Acklio 372 1137A avenue des Champs Blancs 373 35510 Cesson-Sevigne Cedex 374 France 376 Email: a@ackl.io 378 Pascal Thubert 379 Cisco Systems 380 45 Allee des Ormes - BP1200 381 06254 Mougins - Sophia Antipolis 382 France 384 Email: pthubert@cisco.com 386 Ana Minaburo 387 Acklio 388 1137A avenue des Champs Blancs 389 35510 Cesson-Sevigne Cedex 390 France 392 Email: ana@ackl.io