idnits 2.17.1 draft-ietf-lpwan-schc-compound-ack-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 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.) ** There are 5 instances of too long lines in the document, the longest one being 39 characters in excess of 72. ** The abstract seems to contain references ([RFC8376], [RFC8724]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 129: '... Compound ACKs MAY be used in the do...' RFC 2119 keyword, line 133: '... bitmaps MUST be ordered from the lo...' RFC 2119 keyword, line 149: '...CHC Compound ACK MAY be used. The SCH...' RFC 2119 keyword, line 152: '...sent in the SCHC Compound ACK, MUST be...' RFC 2119 keyword, line 155: '... padding bits MUST be 0 to make subs...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2021) is 921 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 (-21) exists of draft-ietf-lpwan-schc-yang-data-model-04 ** Downref: Normative reference to an Informational RFC: RFC 8376 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group JC. Zuniga 3 Internet-Draft SIGFOX 4 Intended status: Standards Track C. Gomez 5 Expires: April 21, 2022 S. Aguilar 6 Universitat Politecnica de Catalunya 7 L. Toutain 8 IMT-Atlantique 9 S. Cespedes 10 D. Wistuba 11 NIC Labs, Universidad de Chile 12 October 18, 2021 14 SCHC Compound ACK 15 draft-ietf-lpwan-schc-compound-ack-01 17 Abstract 19 The present document describes an extension to the SCHC (Static 20 Header Compression and Fragmentation) protocol [RFC8724]. It defines 21 a SCHC Compound ACK message format, which is intended to reduce the 22 number of downlink transmissions (i.e., SCHC ACKs) by accumulating 23 bitmaps of several windows in a single SCHC message (i.e., the SCHC 24 Compound ACK). 26 The message format is generic, and can be used for instance by any 27 the four LWPAN technologies defined in [RFC8376], being Sigfox, 28 LoRaWAN, NB-IoT and IEEE 802.15.4w. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 21, 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. SCHC Compound ACK . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. SCHC Compound ACK Message Format . . . . . . . . . . . . 3 68 3.2. SCHC Compound ACK Examples . . . . . . . . . . . . . . . 4 69 3.3. SCHC Compound ACK YANG Data Model . . . . . . . . . . . . 5 70 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 The Generic Framework for Static Context Header Compression and 78 Fragmentation (SCHC) specification [RFC8724] describes two 79 mechanisms: i) an application header compression scheme, and ii) a 80 frame fragmentation and loss recovery functionality. Either can be 81 used on top of radio technologies such as the four LWPAN defined in 82 [RFC8376], being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. These 83 LPWANs have similar characteristics such as star-oriented topologies, 84 network architecture, connected devices with built-in applications, 85 etc. 87 SCHC offers a great level of flexibility to accommodate all these 88 LPWAN technologies. Even though there are a great number of 89 similarities between them, some differences exist with respect to the 90 transmission characteristics, payload sizes, etc. Hence, there are 91 optimal parameters and modes of operation that can be used when SCHC 92 is used on top of a specific LPWAN technology. 94 The present document describes an extension to the SCHC protocol. It 95 defines a SCHC Compound ACK format, which is intended to reduce the 96 number of downlink transmissions (i.e., SCHC ACKs) in the ACK-on- 97 Error mode of SCHC. The SCHC Compound ACK extends the SCHC ACK 98 message format so that it can contain several bitmaps, each bitmap 99 being identified by its corresponding window number. 101 The SCHC Compound ACK: 103 o provides feedback only for windows with fragment losses, 105 o has a variable size that depends on the number of windows with 106 fragment losses being reported in the single Compound SCHC ACK, 108 o includes the window number (i.e., W) of each bitmap, 110 o has the same SCHC ACK format defined in [RFC8724] when only one 111 window with losses is reported, 113 o might not cover all windows with fragment losses of a SCHC Packet, 115 o is distinguishable from the SCHC Receiver-Abort. 117 2. Terminology 119 It is assumed that the reader is familiar with the terms and 120 mechanisms defined in [RFC8376] and in [RFC8724]. 122 3. SCHC Compound ACK 124 The SCHC Compound ACK is a SCHC ACK message that can contain several 125 bitmaps, each bitmap being identified by its corresponding window 126 number. 128 When the ACK-on-Error mode is used for uplink fragmentation, SCHC 129 Compound ACKs MAY be used in the downlink responses. 131 The SCHC Compound ACK groups the window number (W) with its 132 corresponding bitmap. The included window numbers and corresponding 133 bitmaps MUST be ordered from the lowest-numbered to the highest- 134 numbered window. 136 3.1. SCHC Compound ACK Message Format 138 Figure 1 shows the regular SCHC ACK format when all fragments have 139 been correctly received (C=1), as defined in [RFC8724]. 141 |- SCHC ACK Header --| 142 + -------+---+------ + ------------ + 143 | RuleID | W | C=b'1 | b'0-pad(opt) | 144 + ------ + - + ----- + ------------ + 146 Figure 1: SCHC Success ACK message format, as defined in RFC8724 148 In case SCHC fragment losses are found in any of the windows of the 149 SCHC Packet (C=0), the SCHC Compound ACK MAY be used. The SCHC 150 Compound ACK message format is shown in Figure 2. 152 The window numbered 00, if present in the SCHC Compound ACK, MUST be 153 placed between the Rule ID and the C bit to avoid confusion with 154 padding bits. If padding is needed for the SCHC Compound ACK, 155 padding bits MUST be 0 to make subsequent window numbers and bitmaps 156 distinguishable. 158 |-SCHC ACK Header--| W = x |...| W = x + i | 159 +------------------+ ------ +...+ ------- + ------ +------------+ 160 |RuleID|W=b'x|C=b'0| Bitmap |...| W=b'x+i | Bitmap |b'0-pad(opt)| 161 +------+-----+-----+ ------ +...+ ------- + ------ +------------+ 163 Losses are found in windows W = x,...,x+i 165 Figure 2: SCHC Compound ACK message format 167 Each different SCHC LPWAN technology profile MUST specify how the 168 SCHC Compound ACK is different from the Receiver-Abort message. 170 The SCHC Compound ACK MAY use a Compressed Bitmap, and bitmap fields 171 MAY be of variable size. 173 3.2. SCHC Compound ACK Examples 175 Figure 3 shows an example transmission of a SCHC Packet in ACK-on- 176 Error mode using the SCHC Compound ACK. In the example, the SCHC 177 Packet is fragmented in 14 tiles, with N=3, WINDOW_SIZE=7, M=2 and 178 two lost SCHC fragments. Only 1 compound SCHC ACK is generated. 180 Sender Receiver 181 |-----W=0, FCN=6 ----->| 182 |-----W=0, FCN=5 ----->| 183 |-----W=0, FCN=4 ----->| 184 |-----W=0, FCN=3 ----->| 185 |-----W=0, FCN=2 --X-->| 186 |-----W=0, FCN=1 ----->| 187 |-----W=0, FCN=0 ----->| Bitmap: 1111011 188 (no ACK) 189 |-----W=1, FCN=6 ----->| 190 |-----W=1, FCN=5 ----->| 191 |-----W=1, FCN=4 ----->| 192 |-----W=1, FCN=3 ----->| 193 |-----W=1, FCN=2 ----->| 194 |-----W=1, FCN=1 --X-->| 195 |-- W=1, FCN=7 + RSC ->| Integrity check: failure 196 |<--- Compound ACK ----| C=0, W=0 - Bitmap:1111011, W=1 - Bitmap:1111101 197 |-----W=0, FCN=2 ----->| 198 |-----W=1, FCN=1 ----->| Integrity check: success 199 |<--- ACK, W=1, C=1 ---| C=0 200 (End) 202 Figure 3: SCHC Compound ACK message sequence example 204 |-- SCHC ACK Header ---|- W=00 --|----- W=01 -----| 205 + -------------------- + ------- + ---- + ------- + ------------- + 206 | RuleID | W=00 | C=0 | 1111011 | W=01 | 1111011 | b'0-pad (opt) | 207 + ------ + ------ + -- + ------- + ---- + ------- + ------------- + 209 On top are denoted the window numbers of the corresponding bitmap. 210 Losses are found in windows 00 and 01. 212 Figure 4: SCHC Compound ACK message format example 214 3.3. SCHC Compound ACK YANG Data Model 216 The present document also extends the YANG data model defined in 217 [I-D.ietf-lpwan-schc-yang-data-model] by including a new leaf in the 218 Ack-on-Error fragmentation mode to describe the option to use the 219 SCHC Compound ACK, as well as its bitmap format. Figure 5 shows this 220 definition: 222 // --- Bitmap format 224 identity bitmap-format-base-type { 225 description "Define how the bitmap is defined in ACK messages."; 226 } 228 identity RFC8724-bitmap { 229 base bitmap-format-base-type; 230 description "Bitmap as defined in RFC8724."; 231 } 233 identity compound-ack-bitmap { 234 base bitmap-format-base-type; 235 description "Compound Ack."; 236 } 238 typedef bitmap-format-type { 239 type identityref { 240 base RCS-algorithm-base-type; 241 } 242 description "type used in rules"; 243 } 245 // ------------- 247 choice mode { 248 case no-ack; 249 case ack-always; 250 case ack-on-error { 251 leaf tile-size { 252 type uint8; 253 description "size in bit of tiles, if not specified or set to 0: tile fills the fragment."; 254 } 255 leaf tile-in-All1 { 256 type schc:all1-data-type; 257 description "When true, sender and receiver except a tile in All-1 frag"; 258 } 259 leaf ack-behavior { 260 type schc:ack-behavior-type; 261 description "Sender behavior to acknowledge, after All-0, All-1 or when the 262 LPWAN allows it (Always)"; 263 } 264 leaf bitmap-format { 265 type schc:bitmap-format-type, 266 default schc:RFC8724-bitmap; 267 description "how the bitmaps are included in the Ack message."; 268 } 269 } 270 description "RFC 8724 defines 3 fragmentation modes"; 271 Figure 5: SCHC Compound ACK YANG Data Model 273 4. Security considerations 275 The current document specifies a message format extension for SCHC. 276 Hence, the same Security Considerations defined in [RFC8724] apply. 278 5. Acknowledgements 280 Carles Gomez has been funded in part by the Spanish Government 281 through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P 282 grant, and the PID2019-106808RA-I00 grant, and by Secretaria 283 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 284 la Generalitat de Catalunya 2017 through grant SGR 376. 286 Sergio Aguilar has been funded by the ERDF and the Spanish Government 287 through project TEC2016-79988-P and project PID2019-106808RA-I00, 288 AEI/FEDER, EU. 290 Sandra Cespedes has been funded in part by the ANID Chile Project 291 FONDECYT Regular 1201893 and Basal Project FB0008. 293 Diego Wistuba has been funded by the ANID Chile Project FONDECYT 294 Regular 1201893. 296 The authors would like to thank Rafael Vidal, Julien Boite, Renaud 297 Marty, and Antonis Platis for their useful comments and 298 implementation design considerations. 300 6. Normative References 302 [I-D.ietf-lpwan-schc-yang-data-model] 303 Minaburo, A. and L. Toutain, "Data Model for Static 304 Context Header Compression (SCHC)", draft-ietf-lpwan-schc- 305 yang-data-model-04 (work in progress), Feb 2021. 307 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 308 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 309 . 311 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 312 Zuniga, "SCHC: Generic Framework for Static Context Header 313 Compression and Fragmentation", RFC 8724, 314 DOI 10.17487/RFC8724, April 2020, 315 . 317 Authors' Addresses 319 Juan Carlos Zuniga 320 SIGFOX 321 Montreal QC 322 Canada 324 Email: JuanCarlos.Zuniga@sigfox.com 325 URI: http://www.sigfox.com/ 327 Carles Gomez 328 Universitat Politecnica de Catalunya 329 C/Esteve Terradas, 7 330 08860 Castelldefels 331 Spain 333 Email: carlesgo@entel.upc.edu 335 Sergio Aguilar 336 Universitat Politecnica de Catalunya 337 C/Esteve Terradas, 7 338 08860 Castelldefels 339 Spain 341 Email: sergio.aguilar.romero@upc.edu 343 Laurent Toutain 344 IMT-Atlantique 345 2 rue de la Chataigneraie 346 CS 17607 347 35576 Cesson-Sevigne Cedex 348 France 350 Email: Laurent.Toutain@imt-atlantique.fr 352 Sandra Cespedes 353 NIC Labs, Universidad de Chile 354 Av. Almte. Blanco Encalada 1975 355 Santiago 356 Chile 358 Email: scespedes@niclabs.cl 359 Diego Wistuba 360 NIC Labs, Universidad de Chile 361 Av. Almte. Blanco Encalada 1975 362 Santiago 363 Chile 365 Email: wistuba@niclabs.cl