idnits 2.17.1 draft-pelov-lpwan-architecture-00.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 201: '... MAY be deemed as sufficient, if ...' RFC 2119 keyword, line 205: '... 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 182 has weird spacing: '... . read delet...' -- The document date (January 19, 2021) is 1190 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-lpwan-coap-static-context-hc-16 == Outdated reference: A later version (-21) exists of draft-ietf-lpwan-schc-yang-data-model-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.thubert-lpwan-schc-over-ppp' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: Standards Track P. Thubert 5 Expires: July 23, 2021 Cisco Systems 6 A. Minaburo 7 Acklio 8 January 19, 2021 10 Static Context Header Compression (SCHC) Architecture 11 draft-pelov-lpwan-architecture-00 13 Abstract 15 This document defines the 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 July 23, 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Global architecture . . . . . . . . . . . . . . . . . . . . . 3 54 4. Data management . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 59 1. Introduction 61 The base operation and the definition of the SCHC compression & 62 Fragmentation are now described in several documents published by the 63 LPWAN working group. 65 Among them: 67 o The [rfc8724] defines the generic compression and fragmentation 68 mechanisms for SCHC and applies it to IPv6 and UDP. 70 o The [I-D.ietf-lpwan-coap-static-context-hc] extend the compression 71 to CoAP and OSCORE. 73 o The [I-D.ietf-lpwan-schc-yang-data-model] defines a rule 74 representation using the YANG formalism. 76 As [I-D.ietf-lpwan-coap-static-context-hc] states, the SCHC 77 compression and fragmentation mechanism can be implemented at 78 different levels and/or managed by different organizations. For 79 instance, as represented figure Figure 1, IP compression and 80 fragmentation may be managed by the network SCHC instance and end-to- 81 end compression between the device and the application. The former 82 can itself be split in two instances since encryption hides the field 83 structure. 85 (device) (NGW) (App) 87 +--------+ +--------+ 88 A S | CoAP | | CoAP | 89 p C | inner | | inner | 90 p H +--------+ +--------+ 91 . V | SCHC | | SCHC | 92 | inner | cryptographical boundary | inner | 93 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 94 A S | CoAP | | CoAP | 95 p C | outer | | outer | 96 p H +--------+ +--------+ 97 . C | SCHC | | SCHC | 98 | outer | functional boundary | outer | 99 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 100 N . udp . . udp . 101 e .......... .................. .......... 102 t . ipv6 . . ipv6 . . ipv6 . 103 w C .......... .................. .......... 104 o S . schc . . schc . . . . 105 r H .......... .......... . . . 106 k C . lpwan . . lpwan . . . . 107 .......... .................. .......... 108 ((((LPWAN)))) ------ Internet ------ 110 Figure 3: OSCORE compression/decompression. 112 Figure 1: Different SCHC instances in a global system 114 This document defines a generic architecture for SCHC that can be 115 used at any of these levels. The goal of the architectural document 116 is to orchestrate the different protocols and data model defined by 117 the LPWAN woeking group to design an operational and interoperable 118 framework for allowing IP application over contrained networks. 120 2. Definitions 122 3. Global architecture 124 As described in [rfc8724] a SCHC service is composed of a Parser, 125 analyzing packets and creating a list of fields what will be used to 126 match against the compression rules. If a packet matches rules, 127 compression can be applied following rules instructions. 129 If SCHC compressed packet is too large to be send in a single L2 130 frame, fragmentation will apply. The process is similar, device 131 rules are checked to find the most appropriate fragmentation rule, 132 regarding the SCHC packet size, the link error rate, the reliability 133 required by the application, ... 135 On the other direction, when a packet SCHC arrives, the ruleID is 136 used to find the rule. Its nature allows to select if it is a 137 compression or fragmentation rule. 139 The rule database contains a set of rules specific to a single 140 device. The [rfc8724] indicates that the SCHC instance reads the 141 rules to process C/D and F/R, rules are not modified during these 142 actions. 144 A SCHC instance, summarized in the Figure 2, implies C/D and F/R 145 present in both end. The device connected to a constrained network 146 is in one end and the other end is either located in the core network 147 or at the application. 149 In any cases, the rules must be the same in both ends to perform C/D 150 and F/R. 152 (device) (core|app) 154 (---) (---) 155 ( r ) ( r ) 156 (---) (---) 157 . read . read 158 . . 159 +-----+ +-----+ 160 <===| R&D |<=..............................<=| C&F |<=== 161 ===>| C&F |=>..............................=>| R&D |===> 162 +-----+ +-----+ 164 Figure 2: Summarized SCHC elements 166 To enable rule synchronization between both ends, a common rule 167 representation must be defined. 169 4. Data management 171 [I-D.ietf-lpwan-schc-yang-data-model] defines an YANG data model to 172 represent the rules. This enables the use of several protocols for 173 rule management, such as NETCONF, RESTCONF and CORECONF. NETCONF 174 uses SSH, RESTCONF uses HTTPS, and CORECONF uses CoAP(s) as their 175 respective transport layer protocols. The data is represented in XML 176 under NETCONF, in JSON under RESTCONF and in CBOR under CORECONF. 178 create 179 (-------) read +=======+ * 180 ( rules )<------->|Rule |<--|--------> 181 (-------) update |Manager| NETCONF, RESTCONF or CORECONF 182 . read delete +=======+ request 183 . 184 +-------+ 185 <===| R & D |<=== 186 ===>| C & F |===> 187 +-------+ 189 Figure 3: Summerized SCHC elements 191 Rule Manager (RM) is in charge of handling data derived from the YANG 192 Data Model and apply changes to the rules database Figure 3. 194 The RM is a application using the Internet to exchange information, 195 therefore: 197 o for the network-level SCHC, the communication does not require 198 routing. Each of the end-points having an RM and both RMs can be 199 viewed on the same link, therefore wellknown Link Local addresses 200 can be used to identify the device and the core RM. L2 security 201 MAY be deemed as sufficient, if it provides the necessary level of 202 protection. 204 o for application-level SCHC, routing is involved and global IP 205 addresses SHOULD be used. End-to-end encryption is recommended. 207 Management messages can also be carried in the negotiation protocol 208 as proposed in [I-D.thubert-lpwan-schc-over-ppp] 210 The RM traffic may be itself compressed by SCHC, especially if 211 CORECONF is used, [I-D.ietf-lpwan-coap-static-context-hc] can be 212 used. 214 5. Acknowledgements 216 The authors would like to thank (in alphabetic order): 218 6. Normative References 220 [I-D.ietf-lpwan-coap-static-context-hc] 221 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 222 Context Header Compression (SCHC) for CoAP", draft-ietf- 223 lpwan-coap-static-context-hc-16 (work in progress), 224 October 2020. 226 [I-D.ietf-lpwan-schc-yang-data-model] 227 Minaburo, A. and L. Toutain, "Data Model for Static 228 Context Header Compression (SCHC)", draft-ietf-lpwan-schc- 229 yang-data-model-03 (work in progress), July 2020. 231 [I-D.thubert-lpwan-schc-over-ppp] 232 Thubert, P., "SCHC over PPP", draft-thubert-lpwan-schc- 233 over-ppp-01 (work in progress), June 2020. 235 [rfc8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 236 Zuniga, "SCHC: Generic Framework for Static Context Header 237 Compression and Fragmentation", RFC 8724, 238 DOI 10.17487/RFC8724, April 2020, 239 . 241 Authors' Addresses 243 Alexander Pelov 244 Acklio 245 1137A avenue des Champs Blancs 246 35510 Cesson-Sevigne Cedex 247 France 249 Email: a@ackl.io 251 Pascal Thubert 252 Cisco Systems 253 45 Allee des Ormes - BP1200 254 06254 Mougins - Sophia Antipolis 255 France 257 Email: pthubert@cisco.com 259 Ana Minaburo 260 Acklio 261 1137A avenue des Champs Blancs 262 35510 Cesson-Sevigne Cedex 263 France 265 Email: ana@ackl.io