idnits 2.17.1 draft-ietf-lpwan-schc-compound-ack-02.txt: -(6): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. 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 4 instances of too long lines in the document, the longest one being 27 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 136: '...ound ACK message MUST be ordered from ...' RFC 2119 keyword, line 152: '...CHC Compound ACK MAY be used. The SCH...' RFC 2119 keyword, line 155: '...sent in the SCHC Compound ACK, MUST be...' RFC 2119 keyword, line 168: '...CHC Compound ACK MUST NOT use the Comp...' RFC 2119 keyword, line 170: '...mediate bitmaps fields MUST be of size...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 December 2021) is 868 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 (~~), 3 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: 13 June 2022 S. Aguilar 6 Universitat Politècnica de Catalunya 7 L. Toutain 8 IMT-Atlantique 9 S. Céspedes 10 D. Wistuba 11 NIC Labs, Universidad de Chile 12 10 December 2021 14 SCHC Compound ACK 15 draft-ietf-lpwan-schc-compound-ack-02 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 of 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 13 June 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 (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. SCHC Compound ACK . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. SCHC Compound ACK Message Format . . . . . . . . . . . . 3 67 3.2. SCHC Compound ACK Behaviour . . . . . . . . . . . . . . . 4 68 3.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 5 69 3.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 5 70 3.3. SCHC Compound ACK Examples . . . . . . . . . . . . . . . 5 71 3.4. SCHC Compound ACK YANG Data Model . . . . . . . . . . . . 6 72 3.4.1. SCHC YANG Data Model Extension . . . . . . . . . . . 6 73 3.4.2. SCHC YANG Tree Extension . . . . . . . . . . . . . . 9 74 4. SCHC Compound ACK Parameters . . . . . . . . . . . . . . . . 9 75 5. Security considerations . . . . . . . . . . . . . . . . . . . 9 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 7. Normative References . . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The Generic Framework for Static Context Header Compression and 83 Fragmentation (SCHC) specification [RFC8724] describes two 84 mechanisms: i) a protocol header compression scheme, and ii) a frame 85 fragmentation and loss recovery functionality. Either can be used on 86 top of radio technologies such as the four LWPAN defined in 87 [RFC8376], being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. These 88 LPWANs have similar characteristics such as star-oriented topologies, 89 network architecture, connected devices with built-in applications, 90 etc. 92 SCHC offers a great level of flexibility to accommodate all these 93 LPWAN technologies. Even though there are a great number of 94 similarities between them, some differences exist with respect to the 95 transmission characteristics, payload sizes, etc. Hence, there are 96 optimal parameters and modes of operation that can be used when SCHC 97 is used on top of a specific LPWAN technology. 99 The present document describes an extension to the SCHC protocol. It 100 defines a SCHC Compound ACK format, which is intended to reduce the 101 number of downlink transmissions (i.e., SCHC ACKs) in the ACK-on- 102 Error mode of SCHC. The SCHC Compound ACK extends the SCHC ACK 103 message format so that it can contain several bitmaps, each bitmap 104 being identified by its corresponding window number. 106 The SCHC Compound ACK: 108 * provides feedback only for windows with fragment losses, 110 * has a variable size that depends on the number of windows with 111 fragment losses being reported in the single Compound SCHC ACK, 113 * includes the window number (i.e., W) of each bitmap, 115 * has the same SCHC ACK format defined in [RFC8724] when only one 116 window with losses is reported, 118 * might not cover all windows with fragment losses of a SCHC Packet, 120 * and is distinguishable from the SCHC Receiver-Abort. 122 2. Terminology 124 It is assumed that the reader is familiar with the terms and 125 mechanisms defined in [RFC8376] and in [RFC8724]. 127 3. SCHC Compound ACK 129 The SCHC Compound ACK is a SCHC ACK message that can contain several 130 bitmaps, each bitmap being identified by its corresponding window 131 number. 133 The SCHC Compound ACK groups the window number (W) with its 134 corresponding bitmap. Windows do not need to be contiguous. 135 However, the window numbers and corresponding bitmaps included in the 136 SCHC Compound ACK message MUST be ordered from the lowest-numbered to 137 the highest-numbered window. 139 3.1. SCHC Compound ACK Message Format 141 Figure 1 shows the regular SCHC ACK format when all fragments have 142 been correctly received (C=1), as defined in [RFC8724]. 144 |- SCHC ACK Header --| 145 + -------+---+------ + ------------ + 146 | RuleID | W | C=b'1 | b'0-pad(opt) | 147 + ------ + - + ----- + ------------ + 149 Figure 1: SCHC Success ACK message format, as defined in RFC8724 151 In case SCHC fragment losses are found in any of the windows of the 152 SCHC Packet, the SCHC Compound ACK MAY be used. The SCHC Compound 153 ACK message format is shown in Figure 2. 155 The window numbered 00, if present in the SCHC Compound ACK, MUST be 156 placed between the Rule ID and the C bit to avoid confusion with 157 padding bits. 159 |--SCHC ACK Header--| W = w1 |...| W = wi | 160 +-------------------+ ------ +...+ ------- + ------ +------------+ 161 |RuleID|W=b'w1|C=b'0| Bitmap |...| W=b'wi | Bitmap |b'0-pad(opt)| 162 +------+------+-----+ ------ +...+ ------- + ------ +------------+ 164 Losses are found in windows W = w1,...,wi; where w1| 230 |-----W=0, FCN=5 ----->| 231 |-----W=0, FCN=4 ----->| 232 |-----W=0, FCN=3 ----->| 233 |-----W=0, FCN=2 --X-->| 234 |-----W=0, FCN=1 ----->| 235 |-----W=0, FCN=0 ----->| Bitmap: 1111011 236 (no ACK) 237 |-----W=1, FCN=6 ----->| 238 |-----W=1, FCN=5 ----->| 239 |-----W=1, FCN=4 ----->| 240 |-----W=1, FCN=3 ----->| 241 |-----W=1, FCN=2 ----->| 242 |-----W=1, FCN=1 --X-->| 243 |-- W=1, FCN=7 + RSC ->| Integrity check: failure 244 |<--- Compound ACK ----| [C=0, W=0 - Bitmap:1111011, 245 |-----W=0, FCN=2 ----->| W=1 - Bitmap:1111101] 246 |-----W=1, FCN=1 ----->| Integrity check: success 247 |<--- ACK, W=1, C=1 ---| C=1 248 (End) 250 Figure 3: SCHC Compound ACK message sequence example 252 |-- SCHC ACK Header ---|- W=00 --|----- W=01 -----| 253 + -------------------- + ------- + ---- + ------- + ------------- + 254 | RuleID | W=00 | C=0 | 1111011 | W=01 | 1111011 | b'0-pad (opt) | 255 + ------ + ------ + -- + ------- + ---- + ------- + ------------- + 257 Figure 4: SCHC Compound ACK message format example: Losses are 258 found in windows 00 and 01 260 3.4. SCHC Compound ACK YANG Data Model 262 The present document also extends the SCHC YANG data model defined in 263 [I-D.ietf-lpwan-schc-yang-data-model] by including a new leaf in the 264 Ack-on-Error fragmentation mode to describe both the option to use 265 the SCHC Compound ACK, as well as its bitmap format. 267 3.4.1. SCHC YANG Data Model Extension 268 file "ietf-compound-ack@2021-12-10.yang" 269 module ietf-schc-compound-ack { 270 yang-version 1.1; 271 namespace "urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack"; 272 prefix schc-compound-ack; 274 import ietf-schc { 275 prefix schc; 276 } 278 organization 279 "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; 280 contact 281 "WG Web: 282 WG List: 283 Editor: Laurent Toutain 284 285 Editor: Juan Carlos Zuniga 286 "; 287 description 288 " 289 Copyright (c) 2021 IETF Trust and the persons identified as 290 authors of the code. All rights reserved. 291 Redistribution and use in source and binary forms, with or 292 without modification, is permitted pursuant to, and subject to 293 the license terms contained in, the Simplified BSD License set 294 forth in Section 4.c of the IETF Trust's Legal Provisions 295 Relating to IETF Documents 296 (https://trustee.ietf.org/license-info). 297 This version of this YANG module is part of RFC XXXX 298 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 299 for full legal notices. 300 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 301 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 302 'MAY', and 'OPTIONAL' in this document are to be interpreted as 303 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 304 they appear in all capitals, as shown here. 306 *************************************************************** 308 This module extends the ietf-schc module to include the 309 Compound ACK behavior for ACK-on-Error as defined in RFC YYYY. 310 It introduces a new leaf for ACK-on-Error defining the format 311 of the SCHC Compound ACK, adding the possibility to send 312 several bitmaps in a single SCHC ACK message."; 314 revision 2021-12-08 { 315 description 316 "Initial version for RFC YYYY "; 317 reference 318 "RFC YYYY: SCHC Compound ACK"; 319 } 321 identity bitmap-format-base-type { 322 description 323 "Define how the bitmap is formed in ACK messages."; 324 } 326 identity bitmap-RFC8724 { 327 base bitmap-format-base-type; 328 description 329 "Bitmap by default as defined in RFC8724."; 330 } 332 identity bitmap-compound-ack { 333 base bitmap-format-base-type; 334 description 335 "Compound ACK."; 336 } 338 typedef bitmap-format-type { 339 type identityref { 340 base bitmap-format-base-type; 341 } 342 description 343 "type used in rules"; 344 } 346 augment "/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-error" { 347 leaf bitmap-format { 348 when "derived-from(../schc:fragmentation-mode, 'schc:fragmentation-mode-ack-on-error')"; 349 type schc-compound-ack:bitmap-format-type; 350 default "schc-compound-ack:bitmap-RFC8724"; 351 description 352 "How the bitmaps are included in the Ack message."; 353 } 354 description 355 "added to SCHC rules"; 356 } 358 } 359 361 Figure 5: SCHC YANG Data Model - Compound ACK extension 363 3.4.2. SCHC YANG Tree Extension 365 augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-error: 366 +--rw bitmap-format? schc-compound-ack:bitmap-format-type 368 Figure 6: SCHC YANG Tree - Compound ACK extension 370 4. SCHC Compound ACK Parameters 372 This section lists the parameters related to the SCHC Compound ACK 373 usage that need to be defined in the Profile, in addition to the ones 374 listed in Annex D of [RFC8724]. 376 * Usage or not of the SCHC Compound ACK message. 378 * Usage or not of the compressed bitmap format in the last window of 379 the SCHC Compound ACK message. 381 * Differentiation between SCHC Receiver-Abort and SCHC Compound ACK 382 message, e.g., Receiver-Abort message padded with 1s with an extra 383 byte appended at the end, while the SCHC Compound ACK is 0-padded. 385 5. Security considerations 387 The current document specifies a message format extension for SCHC. 388 Hence, the same Security Considerations defined in [RFC8724] apply. 390 6. Acknowledgements 392 Carles Gomez has been funded in part by the Spanish Government 393 through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P 394 grant, and the PID2019-106808RA-I00 grant, and by Secretaria 395 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 396 la Generalitat de Catalunya 2017 through grant SGR 376. 398 Sergio Aguilar has been funded by the ERDF and the Spanish Government 399 through project TEC2016-79988-P and project PID2019-106808RA-I00, 400 AEI/FEDER, EU. 402 Sandra Cespedes has been funded in part by the ANID Chile Project 403 FONDECYT Regular 1201893 and Basal Project FB0008. 405 Diego Wistuba has been funded by the ANID Chile Project FONDECYT 406 Regular 1201893. 408 The authors would like to thank Rafael Vidal, Julien Boite, Renaud 409 Marty, Antonis Platis, Dominique Barthel and Pascal Thubert for their 410 very useful comments, reviews and implementation design 411 considerations. 413 7. Normative References 415 [I-D.ietf-lpwan-schc-yang-data-model] 416 Minaburo, A. and L. Toutain, "Data Model for Static 417 Context Header Compression (SCHC)", Work in Progress, 418 Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-04, 419 February 2021, . 422 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 423 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 424 . 426 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 427 Zuniga, "SCHC: Generic Framework for Static Context Header 428 Compression and Fragmentation", RFC 8724, 429 DOI 10.17487/RFC8724, April 2020, 430 . 432 Authors' Addresses 434 Juan Carlos Zúñiga 435 SIGFOX 436 Montreal QC 437 Canada 439 Email: JuanCarlos.Zuniga@sigfox.com 440 URI: http://www.sigfox.com/ 442 Carles Gomez 443 Universitat Politècnica de Catalunya 444 C/Esteve Terradas, 7 445 08860 Castelldefels 446 Spain 448 Email: carlesgo@entel.upc.edu 449 Sergio Aguilar 450 Universitat Politècnica de Catalunya 451 C/Esteve Terradas, 7 452 08860 Castelldefels 453 Spain 455 Email: sergio.aguilar.romero@upc.edu 457 Laurent Toutain 458 IMT-Atlantique 459 2 rue de la Chataigneraie 460 CS 17607 461 35576 Cesson-Sevigne Cedex 462 France 464 Email: Laurent.Toutain@imt-atlantique.fr 466 Sandra Céspedes 467 NIC Labs, Universidad de Chile 468 Av. Almte. Blanco Encalada 1975 469 Santiago 470 Chile 472 Email: scespedes@niclabs.cl 474 Diego Wistuba 475 NIC Labs, Universidad de Chile 476 Av. Almte. Blanco Encalada 1975 477 Santiago 478 Chile 480 Email: wistuba@niclabs.cl