Internet-Draft | SCHC Compound ACK | March 2022 |
Zuniga, et al. | Expires 22 September 2022 | [Page] |
- Workgroup:
- lpwan Working Group
- Internet-Draft:
- draft-ietf-lpwan-schc-compound-ack-04
- Updates:
- RFC8724 (if approved)
- Published:
- Intended Status:
- Standards Track
- Expires:
SCHC Compound ACK
Abstract
The present document describes an extension to the SCHC (Static Context Header Compression and fragmentation) protocol [RFC8724]. 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 LWPAN 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 22 September 2022.¶
Copyright Notice
Copyright (c) 2022 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.¶
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 LWPAN defined 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.¶
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.¶
The present document describes an extension to 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 SCHC ACK message format so that it can contain several bitmaps, each bitmap being identified by its corresponding window number.¶
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,¶
- has the same SCHC ACK format defined in [RFC8724] when only one window with losses is reported,¶
- might not cover all windows with fragment losses of a SCHC Packet,¶
- and is distinguishable from the SCHC Receiver-Abort.¶
2. Terminology
It is assumed that the reader is familiar with the terms and mechanisms defined in [RFC8376] and in [RFC8724].¶
3. SCHC Compound ACK
The SCHC Compound ACK is a SCHC ACK message that can contain several bitmaps, each bitmap being identified by its corresponding window number.¶
The SCHC Compound ACK groups the window number (W) with its corresponding bitmap. Windows do not need to be contiguous. However, the window numbers and corresponding bitmaps included in the SCHC Compound ACK message MUST be ordered from the lowest-numbered to the highest-numbered window. Hence, if the the bitmap of window number zero is present in the SCHC Compound ACK message, it MUST always be the first one in order and its W number MUST be placed in-between the Rule ID and the C bit. This also avoids confusing any '0s' padding bits following the first bitmap with W number zero.¶
3.1. SCHC Compound ACK Message Format
Figure 1 shows the regular SCHC ACK format when all fragments have been correctly received (C=1), 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.¶
The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for intermediate windows/bitmaps (i.e., bitmaps that are not the last one), and therefore intermediate bitmaps fields MUST be of size WINDOW_SIZE. Hence, the SCHC Compound ACK MAY use a Compressed Bitmap format only for the last bitmap. The optional usage of this Compressed Bitmap for the last bitmap MUST be specified by the SCHC technology-specific profile.¶
If a SCHC sender gets a SCHC Compound ACK with invalid W's, such as duplicate W values or W values not sent yet, it MUST discard the whole SCHC Compound ACK message.¶
Each different SCHC LPWAN technology profile MUST specify how the SCHC Compound ACK is different from the Receiver-Abort message as per [RFC8724], e.g., the Receiver-Abort message is padded with 1s with an extra byte appended at the end, while the SCHC Compound ACK is 0-padded.¶
3.2. SCHC Compound ACK Behaviour
The SCHC ACK-on-Error behaviour is described in section 8.4.3 of [RFC8724]. The present document slightly modifies this behaviour, since in the baseline SCHC specification a SCHC ACK reports only one bitmap for the reception of exactly one window of tiles. The present SCHC Compound ACK specification extends the SCHC ACK message format so that it can contain several bitmaps, each bitmap being identified by its corresponding window number.¶
Also, some flexibility is introduced with respect to [RFC8724], in that the receiver has the capability to respond to the All-0 with a SCHC Compound ACK or not, depending on certain parameters, like network conditions. Note that even though the protocol allows for such flexibility, the actual decision criteria is not specified in this document.¶
The following sections describe the differences between the baseline SCHC specification and the present SCHC protocol extension specification.¶
3.2.1. Sender Behaviour
OLD TEXT ([RFC8724], section 8.4.3.1) - On receiving a SCHC ACK:¶
- (...)¶
- the fragment sender MUST send SCHC Fragment messages containing all the tiles that are reported missing in the SCHC ACK.¶
- if the last of these SCHC Fragment messages is not an All-1 SCHC Fragment, then the fragment sender MUST in addition send after it a SCHC ACK REQ with the W field corresponding to the last window.¶
NEW TEXT - On receiving a SCHC Compound ACK:¶
- (...)¶
- the fragment sender MUST resend SCHC Fragment messages containing all the tiles of all the windows that are reported missing in the SCHC Compound ACK.¶
- if the last of these SCHC Fragment messages reported missing is not an All-1 SCHC Fragment, then the fragment sender MAY either, send in addition a SCHC ACK REQ with the W field corresponding to the last window, continue the transmission of the remaining fragments to be transmitted, or repeat the All-1 fragment to confirm that all fragments have been correctly received.¶
3.2.2. Receiver Behaviour
OLD TEXT ([RFC8724], section 8.4.3.2) - 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 ACK for the lowest-numbered such window.¶
NEW TEXT: On receiving an All-0 SCHC Fragment:¶
- if the receiver knows of any windows with missing tiles for the packet being reassembled (and if network conditions are known to be conducive), it MAY return a SCHC Compound ACK for the missing fragments, starting from the lowest-numbered window.¶
NEW TEXT: 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 fragments, starting from the lowest-numbered window.¶
3.3. SCHC Compound ACK Examples
Figure 3 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.¶
3.4. SCHC Compound ACK YANG Data Model
The present document also extends the SCHC YANG data model defined in [I-D.ietf-lpwan-schc-yang-data-model] 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.¶
4. SCHC Compound ACK Parameters
This section lists the parameters related to the SCHC Compound ACK usage that need to be defined in the Profile, in addition to the ones listed 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.¶
- Differentiation between SCHC Receiver-Abort and SCHC Compound ACK message, e.g., Receiver-Abort message padded with 1s with an extra byte appended at the end, while the SCHC Compound ACK is 0-padded.¶
5. Security considerations
The current document specifies a message format extension for SCHC. Hence, the same Security Considerations defined in [RFC8724] apply.¶
6. 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.¶
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.¶
7. Normative References
- [I-D.ietf-lpwan-schc-yang-data-model]
- Minaburo, A. and L. Toutain, "Data Model for Static Context Header Compression (SCHC)", Work in Progress, Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-04, , <http://www.ietf.org/internet-drafts/draft-ietf-lpwan-schc-yang-data-model-04.txt>.
- [RFC8376]
- Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, , <https://www.rfc-editor.org/info/rfc8376>.
- [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, , <https://www.rfc-editor.org/info/rfc8724>.