lpwan Working Group JC. Zuniga Internet-Draft Cisco Updates: 8724, 9363 (if approved) C. Gomez Intended status: Standards Track S. Aguilar Expires: 7 October 2023 Universitat Politecnica de Catalunya L. Toutain IMT-Atlantique S. Cespedes Concordia University D. Wistuba NIC Labs, Universidad de Chile 5 April 2023 SCHC Compound ACK draft-ietf-lpwan-schc-compound-ack-17 Abstract The present document updates the SCHC (Static Context Header Compression and fragmentation) protocol RFC8724 and the corresponding Yang Module RFC9363. It defines a SCHC Compound ACK message format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode, by accumulating bitmaps of several windows in a single SCHC message (i.e., the SCHC Compound ACK). Both message format and procedure are generic, so they can be used, for instance, by any of the four Low Power Wide Area Networks (LPWANs) technologies defined in RFC8376, being Sigfox, LoRaWAN, NB- IoT and IEEE 802.15.4w. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 October 2023. Zuniga, et al. Expires 7 October 2023 [Page 1] Internet-Draft SCHC Compound ACK April 2023 Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SCHC Compound ACK . . . . . . . . . . . . . . . . . . . . . . 4 3.1. SCHC Compound ACK Message Format . . . . . . . . . . . . 4 3.2. SCHC Compound ACK Behaviour . . . . . . . . . . . . . . . 7 8.4.3. ACK-on-Error Mode . . . . . . . . . . . . . . . . . . 8 4. SCHC Compound ACK Example . . . . . . . . . . . . . . . . . . 16 5. SCHC Compound ACK YANG Data Model . . . . . . . . . . . . . . 17 5.1. SCHC YANG Data Model Extension . . . . . . . . . . . . . 17 5.2. SCHC YANG Tree Extension . . . . . . . . . . . . . . . . 19 6. SCHC Compound ACK Parameters . . . . . . . . . . . . . . . . 20 7. Security considerations . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.1. URI Registration . . . . . . . . . . . . . . . . . . . . 21 8.2. YANG Module Name Registration . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The Generic Framework for Static Context Header Compression and Fragmentation (SCHC) specification [RFC8724] describes two mechanisms: i) a protocol header compression scheme, and ii) a frame fragmentation and loss recovery functionality. Either can be used on top of radio technologies such as the four Low Power Wide Area Networks (LPWANs) listed in [RFC8376], being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. These LPWANs have similar characteristics such as star-oriented topologies, network architecture, connected devices with built-in applications, etc. Zuniga, et al. Expires 7 October 2023 [Page 2] Internet-Draft SCHC Compound ACK April 2023 SCHC offers a great level of flexibility to accommodate all these LPWAN technologies. Even though there are a great number of similarities between them, some differences exist with respect to the transmission characteristics, payload sizes, etc. Hence, there are optimal parameters and modes of operation that can be used when SCHC is used on top of a specific LPWAN technology. In ACK-on-Error mode in [RFC8724] the SCHC Packet is fragmented into pieces called tiles, with all tiles of the same size except for the last one, which can be smaller. Successive tiles are grouped in windows of fixed size. A SCHC Fragment carries one or several contiguous tiles, which may span multiple windows. When sending all tiles from all windows, the last tile is sent in an All-1 SCHC Fragment. The SCHC receiver, after receiving the All-1 SCHC Fragment will send a SCHC ACK reporting on the reception of exactly one window of tiles. In case of SCHC Fragment losses, a bitmap is added to the failure SCHC ACK, where each bit in the bitmap corresponds to a tile in the window. If SCHC Fragment losses span multiple windows, the SCHC receiver will send one failure SCHC ACK per window with losses. The present document updates the SCHC protocol for frame fragmentation and loss recovery. It defines a SCHC Compound ACK format and procedure, which is intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of SCHC. The SCHC Compound ACK extends the failure SCHC ACK message format so that it can contain several bitmaps, each bitmap being identified by its corresponding window number. The SCHC Compound ACK is backwards compatible with the SCHC ACK as defined in [RFC8724], and introduces flexibility, as the receiver has the capability to respond to the All-0 SCHC Fragment, providing more downlink opportunities, and therefore adjusting to the delay requirements of the application. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. It is assumed that the reader is familiar with the terms and mechanisms defined in [RFC8376] and in [RFC8724]. Zuniga, et al. Expires 7 October 2023 [Page 3] Internet-Draft SCHC Compound ACK April 2023 3. SCHC Compound ACK The SCHC Compound ACK is a failure SCHC ACK message that can contain several bitmaps, each bitmap being identified by its corresponding window number. In [RFC8724], the failure SCHC ACK message only contain one bitmap corresponding to one window. The SCHC Compound ACK extends this format allowing more windows to be acknowledged in a single ACK, reducing the total number of failure SCHC ACK messages, specially when fragment losses are present in intermediate windows. The SCHC Compound ACK MAY be used in fragmentation modes that use windows and that allow reporting the bitmaps of multiple windows at the same time, and MUST NOT be used otherwise. The SCHC Compound ACK: * provides feedback only for windows with fragment losses, * has a variable size that depends on the number of windows with fragment losses being reported in the single Compound SCHC ACK, * includes the window number (i.e., W) of each bitmap, * might not cover all windows with fragment losses of a SCHC Packet, * and is distinguishable from the SCHC Receiver-Abort. 3.1. SCHC Compound ACK Message Format Figure 1 shows the success SCHC ACK format, i.e., when all fragments have been correctly received (C=1), as defined in [RFC8724]. |-- SCHC ACK Header --| |--T-|---M--| 1 | +--------+----+------+---+~~~~~~~~~~~~~~~~~~ | RuleID |DTag| W |C=1| padding as needed +--------+----+------+---+~~~~~~~~~~~~~~~~~~ Figure 1: SCHC Success ACK message format, as defined in RFC8724 In case SCHC Fragment losses are found in any of the windows of the SCHC Packet, the SCHC Compound ACK MAY be used. The SCHC Compound ACK message format is shown in Figure 2 and Figure 3. Zuniga, et al. Expires 7 October 2023 [Page 4] Internet-Draft SCHC Compound ACK April 2023 |--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----| |--T-|---M--|-1-| |...|---M--| |---M--| +------+----+------+---+--------+...+------+--------+------+~~~~~+ |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |00..00| pad | +------+----+------+---+--------+...+------+--------+------+~~~~~+ next L2 Word boundary ->|<-- L2 Word ->| Losses are found in windows W = w1,...,wi; where w1| Losses are found in windows W = w1,...,wi; where w1| SCHC Compound ACK with uncompressed Bitmap |--- SCHC ACK Header --|- W=w1 -|...|-- W=wi --| |--T-|---M--|-1-| |...|---M--| +------+----+------+---+--------+...+------+---+ |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1| +------+----+------+---+--------+...+------+---+ next L2 Word boundary ->| Transmitted SCHC Compound ACK with compressed Bitmap Losses are found in windows W = w1,...,wi; where w1| SCHC Compound ACK with uncompressed Bitmap |--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------| |--T-|---M--|-1-| |...|---M--| |---M--| +------+----+------+---+------+...+------+--------------+------+~~~+ |RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |00..00|pad| +------+----+------+---+------+...+------+--------------+------+~~~+ next L2 Word boundary ->|<------ L2 Word ------>| Transmitted SCHC Compound ACK Losses are found in windows W = w1,...,wi; where w1 for one among several possible examples of a Finite State Machine implementing a sender behavior obeying this specification. 8.4.3.2. Receiver Behavior On receiving a SCHC Fragment with a RuleID and DTag pair not being processed at that time: * the receiver SHOULD check if the DTag value has not recently been used for that RuleID value, thereby ensuring that the received SCHC Fragment is not a remnant of a prior fragmented SCHC Packet transmission. The initial value of the Inactivity Timer is the Zuniga, et al. Expires 7 October 2023 [Page 13] Internet-Draft SCHC Compound ACK April 2023 RECOMMENDED lifetime for the DTag value at the receiver. If the SCHC Fragment is determined to be such a remnant, the receiver MAY silently ignore it and discard it. * the receiver MUST start a process to assemble a new SCHC Packet with that RuleID and DTag value pair. The receiver MUST start an Inactivity Timer for that RuleID and DTag value pair. It MUST initialize an Attempts counter to 0 for that RuleID and DTag value pair. If the receiver is under-resourced to do this, it MUST respond to the sender with a SCHC Receiver-Abort. On reception of any SCHC F/R message for the RuleID and DTag pair being processed, the receiver MUST reset the Inactivity Timer pertaining to that RuleID and DTag pair. All message receptions being discussed in the rest of this section are to be understood as "matching the RuleID and DTag pair being processed", even if not spelled out, for brevity. On receiving a SCHC Fragment message, the receiver determines what tiles were received, based on the payload length and on the W and FCN fields of the SCHC Fragment. * if the FCN is All-1, if a Payload is present, the full SCHC Fragment Payload MUST be assembled including the padding bits. This is because the size of the last tile is not known by the receiver; therefore, padding bits are indistinguishable from the tile data bits, at this stage. They will be removed by the SCHC C/D sublayer. If the size of the SCHC Fragment Payload exceeds or equals the size of one regular tile plus the size of an L2 Word, this SHOULD raise an error flag. * otherwise, tiles MUST be assembled based on the a priori known tile size. - If allowed by the Profile, the end of the payload MAY contain the last tile, which may be shorter. Padding bits are indistinguishable from the tile data bits, at this stage. - The payload may contain the penultimate tile that, if allowed by the Profile, MAY be exactly one L2 Word shorter than the regular tile size. - Otherwise, padding bits MUST be discarded. This is possible because: o the size of the tiles is known a priori, Zuniga, et al. Expires 7 October 2023 [Page 14] Internet-Draft SCHC Compound ACK April 2023 o tiles are larger than an L2 Word, and o padding bits are always strictly less than an L2 Word. On receiving a SCHC All-0 SCHC Fragment: * if the receiver knows of any windows with missing tiles for the packet being reassembled (and depending on certain parameters, like network conditions, sender buffer/chache size, supported application delay, among others), it MAY return a SCHC Compound ACK for the missing tiles, starting from the lowest-numbered window. On receiving a SCHC ACK REQ or an All-1 SCHC Fragment: * if the receiver knows of any windows with missing tiles for the packet being reassembled, it MUST return a SCHC Compound ACK for the missing tiles, starting from the lowest-numbered window. * otherwise: - if it has received at least one tile, it MUST return a SCHC Compound ACK for the highest-numbered window it currently has tiles for, - otherwise, it MUST return a SCHC Compound ACK for window numbered 0. A Profile MAY specify other times and circumstances at which a receiver sends a SCHC Compound ACK, and which window the SCHC Compound ACK reports about in these circumstances. Upon sending a SCHC Compound ACK, the receiver MUST increase the Attempts counter. After receiving an All-1 SCHC Fragment, a receiver MUST check the integrity of the reassembled SCHC Packet at least every time it prepares for sending a SCHC Compound ACK for the last window. Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an error condition. Upon expiration of the Inactivity Timer, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition. On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition. Zuniga, et al. Expires 7 October 2023 [Page 15] Internet-Draft SCHC Compound ACK April 2023 Reassembly of the SCHC Packet concludes when: * a Sender-Abort has been received, or * the Inactivity Timer has expired, or * the Attempts counter has exceeded MAX_ACK_REQUESTS, or * at least an All-1 SCHC Fragment has been received and integrity checking of the reassembled SCHC Packet is successful. See Figure 44 for one among several possible examples of a Finite State Machine implementing a receiver behavior obeying this specification. The example provided is meant to match the sender Finite State Machine of Figure 43. 4. SCHC Compound ACK Example Figure 7 shows an example transmission of a SCHC Packet in ACK-on- Error mode using the SCHC Compound ACK. In the example, the SCHC Packet is fragmented in 14 tiles, with N=3, WINDOW_SIZE=7, M=2 and two lost SCHC fragments. Only 1 compound SCHC ACK is generated. Sender Receiver |-----W=0, FCN=6 ----->| |-----W=0, FCN=5 ----->| |-----W=0, FCN=4 ----->| |-----W=0, FCN=3 ----->| |-----W=0, FCN=2 --X | |-----W=0, FCN=1 ----->| |-----W=0, FCN=0 ----->| Bitmap: 1111011 (no ACK) |-----W=1, FCN=6 ----->| |-----W=1, FCN=5 ----->| |-----W=1, FCN=4 ----->| |-----W=1, FCN=3 ----->| |-----W=1, FCN=2 ----->| |-----W=1, FCN=1 --X | |-- W=1, FCN=7 + RCS ->| Integrity check: failure |<--- Compound ACK ----| [C=0, W=0 - Bitmap:1111011, |-----W=0, FCN=2 ----->| W=1 - Bitmap:1111101] |-----W=1, FCN=1 ----->| Integrity check: success |<--- ACK, W=1, C=1 ---| C=1 (End) Figure 7: SCHC Compound ACK message sequence example Zuniga, et al. Expires 7 October 2023 [Page 16] Internet-Draft SCHC Compound ACK April 2023 |--- SCHC ACK Header --|- W=00 --|----- W=01 -----| |--T-|---M--|-1-| |---M--| |---M--| +------+----+------+---+---------+------+---------+------+-----+ |RuleID|DTag| W=00 |C=0| 1111011 | W=01 | 1111101 | 00 | pad | +------+----+------+---+---------+------+---------+------+-----+ next L2 Word boundary ->|<-- L2 Word ->| Figure 8: SCHC Compound ACK message format example: Losses are found in windows 00 and 01 5. SCHC Compound ACK YANG Data Model The present document also extends the SCHC YANG data model defined in [RFC9363] by including a new leaf in the Ack-on-Error fragmentation mode to describe both the option to use the SCHC Compound ACK, as well as its bitmap format. 5.1. SCHC YANG Data Model Extension file "ietf-lpwan-schc-compound-ack@2023-03-16.yang" module ietf-lpwan-schc-compound-ack { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:" + "ietf-lpwan-schc-compound-ack"; prefix schc-compound-ack; import ietf-schc { prefix schc; } organization "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; contact "WG Web: WG List: Editor: Laurent Toutain Editor: Juan Carlos Zuniga Editor: Sergio Aguilar "; description "Copyright (c) 2023 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set Zuniga, et al. Expires 7 October 2023 [Page 17] Internet-Draft SCHC Compound ACK April 2023 forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 9363 (https://www.rfc-editor.org/info/rfc9363); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. *************************************************************** Generic data model for the Static Context Header Compression Rule for SCHC, based on RFCs 8724 and 8824. Including compression, no-compression, and fragmentation Rules."; revision 2023-03-16 { description "Initial version for RFC YYYY "; reference "RFC YYYY: SCHC Compound ACK"; } identity bitmap-format-base-type { description "Define how the bitmap is formed in ACK messages."; } identity bitmap-RFC8724 { base bitmap-format-base-type; description "Bitmap by default as defined in RFC8724."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } identity bitmap-compound-ack { base bitmap-format-base-type; description "Compound ACK allows several bitmaps in a ACK message."; } typedef bitmap-format-type { type identityref { base bitmap-format-base-type; } description Zuniga, et al. Expires 7 October 2023 [Page 18] Internet-Draft SCHC Compound ACK April 2023 "Type of bitmap used in rules."; } augment "/schc:schc/schc:rule/schc:nature/" + "schc:fragmentation/schc:mode/schc:ack-on-error" { leaf bitmap-format { when "derived-from-or-self(../schc:fragmentation-mode, 'schc:fragmentation-mode-ack-on-error')"; type schc-compound-ack:bitmap-format-type; default "schc-compound-ack:bitmap-RFC8724"; description "How the bitmaps are included in the SCHC ACK message."; } leaf last-bitmap-compression { when "derived-from-or-self(../schc:fragmentation-mode, 'schc:fragmentation-mode-ack-on-error')"; type boolean; default "true"; description "When true the ultimate bitmap in the SCHC ACK message can be compressed. Default behavior from RFC8724"; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } description "Augment the SCHC rules to manage Compound Ack."; } } Figure 9: SCHC YANG Data Model - Compound ACK extension 5.2. SCHC YANG Tree Extension module: ietf-lpwan-schc-compound-ack augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/ schc:mode/schc:ack-on-error: +--rw bitmap-format? schc-compound-ack:bitmap-format-type +--rw last-bitmap-compression? boolean Figure 10: Tree Diagram - Compound ACK extension Zuniga, et al. Expires 7 October 2023 [Page 19] Internet-Draft SCHC Compound ACK April 2023 6. SCHC Compound ACK Parameters This section lists the parameters related to the SCHC Compound ACK usage that need to be defined in the Profile. This list MUST be appended to the list of SCHC parameters under "Decision to use SCHC fragmentation mechanism or not. If yes, the document must describe:" in Annex D of [RFC8724]. * Usage or not of the SCHC Compound ACK message. * Usage or not of the compressed bitmap format in the last window of the SCHC Compound ACK message. 7. Security considerations The current document specifies a message format extension for SCHC. Hence, the same Security Considerations defined in [RFC8724] and in [RFC9363] apply. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: /schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/ schc:ack-on-error: All the data nodes may be modified. The Rule contains sensitive information, such as the SCHC F/R mode configuration and usage and configuration of the SCHC Compound ACK. An attacker may try to modify other devices' Rules by changing the F/ R mode or the usage of the SCHC Compound ACK and may block communication or create extra ACKs. Therefore, a device must be allowed to modify only its own rules on the remote SCHC instance. The identity of the requester must be validated. This can be done through certificates or access lists. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/ vulnerability: /schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/ schc:ack-on-error: By reading this module, an attacker may learn the F/R mode used by the device and how the device manage the bitmap creation and also learn the buffer sizes and when the device will request an ACK. Zuniga, et al. Expires 7 October 2023 [Page 20] Internet-Draft SCHC Compound ACK April 2023 8. IANA Considerations This document registers one URI and one YANG data model. 8.1. URI Registration IANA registered the following URI in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-lpwan-schc-compound-ack Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. 8.2. YANG Module Name Registration IANA has registered the following YANG data model in the "YANG Module Names" registry [RFC6020]. name: ietf-lpwan-schc-compound-ack namespace: urn:ietf:params:xml:ns:yang:ietf-lpwan-schc-compound- ack prefix: schc-compound-ack reference: RFC 9. Acknowledgements Carles Gomez has been funded in part by the Spanish Government through the TEC2016-79988-P grant, and the PID2019-106808RA-I00 grant (funded by MCIN / AEI / 10.13039/501100011033), and by Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat de Catalunya 2017 through grant SGR 376. Sergio Aguilar has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P and project PID2019-106808RA-I00, AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033). Sandra Cespedes has been funded in part by the ANID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008. Diego Wistuba has been funded by the ANID Chile Project FONDECYT Regular 1201893. Zuniga, et al. Expires 7 October 2023 [Page 21] Internet-Draft SCHC Compound ACK April 2023 The authors would like to thank Rafael Vidal, Julien Boite, Renaud Marty, Antonis Platis, Dominique Barthel and Pascal Thubert for their very useful comments, reviews and implementation design considerations. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . [RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, March 2023, . 10.2. Informative References [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, . Authors' Addresses Zuniga, et al. Expires 7 October 2023 [Page 22] Internet-Draft SCHC Compound ACK April 2023 Juan Carlos Zuniga Cisco Montreal QC Canada Email: juzuniga@cisco.com Carles Gomez Universitat Politecnica de Catalunya C/Esteve Terradas, 7 08860 Castelldefels Spain Email: carles.gomez@upc.edu Sergio Aguilar Universitat Politecnica de Catalunya C/Esteve Terradas, 7 08860 Castelldefels Spain Email: sergio.aguilar.romero@upc.edu Laurent Toutain IMT-Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@imt-atlantique.fr Sandra Cespedes Concordia University 1455 De Maisonneuve Blvd. W. Montreal QC, H3G 1M8 Canada Email: sandra.cespedes@concordia.ca Diego Wistuba NIC Labs, Universidad de Chile Av. Almte. Blanco Encalada 1975 Santiago Chile Email: wistuba@niclabs.cl Zuniga, et al. Expires 7 October 2023 [Page 23]