idnits 2.17.00 (12 Aug 2021) /tmp/idnits39791/draft-ietf-lpwan-schc-compound-ack-04.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 7 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 137: '...ound ACK message MUST be ordered from ...' RFC 2119 keyword, line 139: '...the SCHC Compound ACK message, it MUST...' RFC 2119 keyword, line 140: '...er and its W number MUST be placed in-...' RFC 2119 keyword, line 157: '...CHC Compound ACK MAY be used. The SCH...' RFC 2119 keyword, line 169: '...CHC Compound ACK MUST NOT use the Comp...' (12 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 March 2022) is 54 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 (-08) 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 Cisco 4 Updates: RFC8724 (if approved) C. Gomez 5 Intended status: Standards Track S. Aguilar 6 Expires: 22 September 2022 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 21 March 2022 14 SCHC Compound ACK 15 draft-ietf-lpwan-schc-compound-ack-04 17 Abstract 19 The present document describes an extension to the SCHC (Static 20 Context Header Compression and fragmentation) protocol [RFC8724]. It 21 defines a SCHC Compound ACK message format and procedure, which are 22 intended to reduce the number of response transmissions (i.e., SCHC 23 ACKs) in the ACK-on-Error mode, by accumulating bitmaps of several 24 windows in a single SCHC message (i.e., the SCHC Compound ACK). 26 Both message format and procedure are generic, so they can be used, 27 for instance, by any of the four LWPAN technologies defined in 28 [RFC8376], being Sigfox, 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 22 September 2022. 47 Copyright Notice 49 Copyright (c) 2022 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 . . . . . . . . . . . . 4 67 3.2. SCHC Compound ACK Behaviour . . . . . . . . . . . . . . . 5 68 3.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 5 69 3.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 6 70 3.3. SCHC Compound ACK Examples . . . . . . . . . . . . . . . 6 71 3.4. SCHC Compound ACK YANG Data Model . . . . . . . . . . . . 7 72 3.4.1. SCHC YANG Data Model Extension . . . . . . . . . . . 7 73 3.4.2. SCHC YANG Tree Extension . . . . . . . . . . . . . . 10 74 4. SCHC Compound ACK Parameters . . . . . . . . . . . . . . . . 10 75 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 7. Normative References . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 for 100 frame fragmentation and loss recovery. It defines a SCHC Compound 101 ACK format and procedure, which is intended to reduce the number of 102 response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of 103 SCHC. The SCHC Compound ACK extends the SCHC ACK message format so 104 that it can contain several bitmaps, each bitmap being identified by 105 its corresponding window number. 107 The SCHC Compound ACK: 109 * provides feedback only for windows with fragment losses, 111 * has a variable size that depends on the number of windows with 112 fragment losses being reported in the single Compound SCHC ACK, 114 * includes the window number (i.e., W) of each bitmap, 116 * has the same SCHC ACK format defined in [RFC8724] when only one 117 window with losses is reported, 119 * might not cover all windows with fragment losses of a SCHC Packet, 121 * and is distinguishable from the SCHC Receiver-Abort. 123 2. Terminology 125 It is assumed that the reader is familiar with the terms and 126 mechanisms defined in [RFC8376] and in [RFC8724]. 128 3. SCHC Compound ACK 130 The SCHC Compound ACK is a SCHC ACK message that can contain several 131 bitmaps, each bitmap being identified by its corresponding window 132 number. 134 The SCHC Compound ACK groups the window number (W) with its 135 corresponding bitmap. Windows do not need to be contiguous. 136 However, the window numbers and corresponding bitmaps included in the 137 SCHC Compound ACK message MUST be ordered from the lowest-numbered to 138 the highest-numbered window. Hence, if the the bitmap of window 139 number zero is present in the SCHC Compound ACK message, it MUST 140 always be the first one in order and its W number MUST be placed in- 141 between the Rule ID and the C bit. This also avoids confusing any 142 '0s' padding bits following the first bitmap with W number zero. 144 3.1. SCHC Compound ACK Message Format 146 Figure 1 shows the regular SCHC ACK format when all fragments have 147 been correctly received (C=1), as defined in [RFC8724]. 149 |- SCHC ACK Header --| 150 + -------+---+------ + ------------ + 151 | RuleID | W | C=b'1 | b'0-pad(opt) | 152 + ------ + - + ----- + ------------ + 154 Figure 1: SCHC Success ACK message format, as defined in RFC8724 156 In case SCHC Fragment losses are found in any of the windows of the 157 SCHC Packet, the SCHC Compound ACK MAY be used. The SCHC Compound 158 ACK message format is shown in Figure 2. 160 |--SCHC ACK Header--| W = w1 |...| W = wi | 161 +-------------------+ ------ +...+ ------- + ------ +------------+ 162 |RuleID|W=b'w1|C=b'0| Bitmap |...| W=b'wi | Bitmap |b'0-pad(opt)| 163 +------+------+-----+ ------ +...+ ------- + ------ +------------+ 165 Losses are found in windows W = w1,...,wi; where w1| 267 |-----W=0, FCN=5 ----->| 268 |-----W=0, FCN=4 ----->| 269 |-----W=0, FCN=3 ----->| 270 |-----W=0, FCN=2 --X-->| 271 |-----W=0, FCN=1 ----->| 272 |-----W=0, FCN=0 ----->| Bitmap: 1111011 273 (no ACK) 274 |-----W=1, FCN=6 ----->| 275 |-----W=1, FCN=5 ----->| 276 |-----W=1, FCN=4 ----->| 277 |-----W=1, FCN=3 ----->| 278 |-----W=1, FCN=2 ----->| 279 |-----W=1, FCN=1 --X-->| 280 |-- W=1, FCN=7 + RCS ->| Integrity check: failure 281 |<--- Compound ACK ----| [C=0, W=0 - Bitmap:1111011, 282 |-----W=0, FCN=2 ----->| W=1 - Bitmap:1111101] 283 |-----W=1, FCN=1 ----->| Integrity check: success 284 |<--- ACK, W=1, C=1 ---| C=1 285 (End) 287 Figure 3: SCHC Compound ACK message sequence example 289 |-- SCHC ACK Header ---|- W=00 --|----- W=01 -----| 290 + -------------------- + ------- + ---- + ------- + ------------- + 291 | RuleID | W=00 | C=0 | 1111011 | W=01 | 1111101 | b'0-pad (opt) | 292 + ------ + ------ + -- + ------- + ---- + ------- + ------------- + 294 Figure 4: SCHC Compound ACK message format example: Losses are 295 found in windows 00 and 01 297 3.4. SCHC Compound ACK YANG Data Model 299 The present document also extends the SCHC YANG data model defined in 300 [I-D.ietf-lpwan-schc-yang-data-model] by including a new leaf in the 301 Ack-on-Error fragmentation mode to describe both the option to use 302 the SCHC Compound ACK, as well as its bitmap format. 304 3.4.1. SCHC YANG Data Model Extension 305 file "ietf-compound-ack@2021-12-10.yang" 306 module ietf-schc-compound-ack { 307 yang-version 1.1; 308 namespace "urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack"; 309 prefix schc-compound-ack; 311 import ietf-schc { 312 prefix schc; 313 } 315 organization 316 "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; 317 contact 318 "WG Web: 319 WG List: 320 Editor: Laurent Toutain 321 322 Editor: Juan Carlos Zuniga 323 "; 324 description 325 " 326 Copyright (c) 2021 IETF Trust and the persons identified as 327 authors of the code. All rights reserved. 328 Redistribution and use in source and binary forms, with or 329 without modification, is permitted pursuant to, and subject to 330 the license terms contained in, the Simplified BSD License set 331 forth in Section 4.c of the IETF Trust's Legal Provisions 332 Relating to IETF Documents 333 (https://trustee.ietf.org/license-info). 334 This version of this YANG module is part of RFC XXXX 335 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 336 for full legal notices. 337 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 338 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 339 'MAY', and 'OPTIONAL' in this document are to be interpreted as 340 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 341 they appear in all capitals, as shown here. 343 *************************************************************** 345 This module extends the ietf-schc module to include the 346 Compound ACK behavior for ACK-on-Error as defined in RFC YYYY. 347 It introduces a new leaf for ACK-on-Error defining the format 348 of the SCHC Compound ACK, adding the possibility to send 349 several bitmaps in a single SCHC ACK message."; 351 revision 2022-02-08 { 352 description 353 "Initial version for RFC YYYY "; 354 reference 355 "RFC YYYY: SCHC Compound ACK"; 356 } 358 identity bitmap-format-base-type { 359 description 360 "Define how the bitmap is formed in ACK messages."; 361 } 363 identity bitmap-RFC8724 { 364 base bitmap-format-base-type; 365 description 366 "Bitmap by default as defined in RFC8724."; 367 } 369 identity bitmap-compound-ack { 370 base bitmap-format-base-type; 371 description 372 "Compound ACK."; 373 } 375 typedef bitmap-format-type { 376 type identityref { 377 base bitmap-format-base-type; 378 } 379 description 380 "type used in rules"; 381 } 383 augment "/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-error" { 384 leaf bitmap-format { 385 when "derived-from(../schc:fragmentation-mode, 'schc:fragmentation-mode-ack-on-error')"; 386 type schc-compound-ack:bitmap-format-type; 387 default "schc-compound-ack:bitmap-RFC8724"; 388 description 389 "How the bitmaps are included in the SCHC ACK message."; 390 } 392 leaf last-bitmap-compression { 393 when "derived-from(../schc:fragmentation-mode, 'schc:fragmentation-mode-ack-on-error')"; 394 type boolean; 395 default true; 396 description 397 "when true ultimate bitmap in the SCHC ACK message can be compressed"; 398 } 400 description 401 "added to SCHC rules"; 402 } 404 } 405 407 Figure 5: SCHC YANG Data Model - Compound ACK extension 409 3.4.2. SCHC YANG Tree Extension 411 augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-error: 412 +--rw bitmap-format? schc-compound-ack:bitmap-format-type 414 Figure 6: SCHC YANG Tree - Compound ACK extension 416 4. SCHC Compound ACK Parameters 418 This section lists the parameters related to the SCHC Compound ACK 419 usage that need to be defined in the Profile, in addition to the ones 420 listed in Annex D of [RFC8724]. 422 * Usage or not of the SCHC Compound ACK message. 424 * Usage or not of the compressed bitmap format in the last window of 425 the SCHC Compound ACK message. 427 * Differentiation between SCHC Receiver-Abort and SCHC Compound ACK 428 message, e.g., Receiver-Abort message padded with 1s with an extra 429 byte appended at the end, while the SCHC Compound ACK is 0-padded. 431 5. Security considerations 433 The current document specifies a message format extension for SCHC. 434 Hence, the same Security Considerations defined in [RFC8724] apply. 436 6. Acknowledgements 438 Carles Gomez has been funded in part by the Spanish Government 439 through the TEC2016-79988-P grant, and the PID2019-106808RA-I00 grant 440 (funded by MCIN / AEI / 10.13039/501100011033), and by Secretaria 441 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 442 la Generalitat de Catalunya 2017 through grant SGR 376. 444 Sergio Aguilar has been funded by the ERDF and the Spanish Government 445 through project TEC2016-79988-P and project PID2019-106808RA-I00, 446 AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033). 448 Sandra Cespedes has been funded in part by the ANID Chile Project 449 FONDECYT Regular 1201893 and Basal Project FB0008. 451 Diego Wistuba has been funded by the ANID Chile Project FONDECYT 452 Regular 1201893. 454 The authors would like to thank Rafael Vidal, Julien Boite, Renaud 455 Marty, Antonis Platis, Dominique Barthel and Pascal Thubert for their 456 very useful comments, reviews and implementation design 457 considerations. 459 7. Normative References 461 [I-D.ietf-lpwan-schc-yang-data-model] 462 Minaburo, A. and L. Toutain, "Data Model for Static 463 Context Header Compression (SCHC)", Work in Progress, 464 Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-04, 465 February 2021, . 468 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 469 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 470 . 472 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 473 Zuniga, "SCHC: Generic Framework for Static Context Header 474 Compression and Fragmentation", RFC 8724, 475 DOI 10.17487/RFC8724, April 2020, 476 . 478 Authors' Addresses 480 Juan Carlos Zúñiga 481 Cisco 482 Montreal QC 483 Canada 484 Email: juzuniga@cisco.com 486 Carles Gomez 487 Universitat Politècnica de Catalunya 488 C/Esteve Terradas, 7 489 08860 Castelldefels 490 Spain 491 Email: carlesgo@entel.upc.edu 492 Sergio Aguilar 493 Universitat Politècnica de Catalunya 494 C/Esteve Terradas, 7 495 08860 Castelldefels 496 Spain 497 Email: sergio.aguilar.romero@upc.edu 499 Laurent Toutain 500 IMT-Atlantique 501 2 rue de la Chataigneraie 502 CS 17607 503 35576 Cesson-Sevigne Cedex 504 France 505 Email: Laurent.Toutain@imt-atlantique.fr 507 Sandra Céspedes 508 NIC Labs, Universidad de Chile 509 Av. Almte. Blanco Encalada 1975 510 Santiago 511 Chile 512 Email: scespedes@niclabs.cl 514 Diego Wistuba 515 NIC Labs, Universidad de Chile 516 Av. Almte. Blanco Encalada 1975 517 Santiago 518 Chile 519 Email: wistuba@niclabs.cl