< draft-ietf-lpwan-schc-compound-ack-03.txt   draft-ietf-lpwan-schc-compound-ack-04.txt >
lpwan Working Group JC. Zuniga lpwan Working Group JC. Zuniga
Internet-Draft SIGFOX Internet-Draft Cisco
Intended status: Standards Track C. Gomez Updates: RFC8724 (if approved) C. Gomez
Expires: 12 August 2022 S. Aguilar Intended status: Standards Track S. Aguilar
Universitat Politècnica de Catalunya Expires: 22 September 2022 Universitat Politècnica de Catalunya
L. Toutain L. Toutain
IMT-Atlantique IMT-Atlantique
S. Céspedes S. Céspedes
D. Wistuba D. Wistuba
NIC Labs, Universidad de Chile NIC Labs, Universidad de Chile
8 February 2022 21 March 2022
SCHC Compound ACK SCHC Compound ACK
draft-ietf-lpwan-schc-compound-ack-03 draft-ietf-lpwan-schc-compound-ack-04
Abstract Abstract
The present document describes an extension to the SCHC (Static The present document describes an extension to the SCHC (Static
Context Header Compression and fragmentation) protocol [RFC8724]. It Context Header Compression and fragmentation) protocol [RFC8724]. It
defines a SCHC Compound ACK message format, which is intended to defines a SCHC Compound ACK message format and procedure, which are
reduce the number of response transmissions (i.e., SCHC ACKs) by intended to reduce the number of response transmissions (i.e., SCHC
accumulating bitmaps of several windows in a single SCHC message ACKs) in the ACK-on-Error mode, by accumulating bitmaps of several
(i.e., the SCHC Compound ACK). windows in a single SCHC message (i.e., the SCHC Compound ACK).
The message format is generic, and can be used, for instance, by any Both message format and procedure are generic, so they can be used,
of the four LWPAN technologies defined in [RFC8376], being Sigfox, for instance, by any of the four LWPAN technologies defined in
LoRaWAN, NB-IoT and IEEE 802.15.4w. [RFC8376], being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 August 2022. This Internet-Draft will expire on 22 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 10 skipping to change at page 3, line 10
SCHC offers a great level of flexibility to accommodate all these SCHC offers a great level of flexibility to accommodate all these
LPWAN technologies. Even though there are a great number of LPWAN technologies. Even though there are a great number of
similarities between them, some differences exist with respect to the similarities between them, some differences exist with respect to the
transmission characteristics, payload sizes, etc. Hence, there are transmission characteristics, payload sizes, etc. Hence, there are
optimal parameters and modes of operation that can be used when SCHC optimal parameters and modes of operation that can be used when SCHC
is used on top of a specific LPWAN technology. is used on top of a specific LPWAN technology.
The present document describes an extension to the SCHC protocol for The present document describes an extension to the SCHC protocol for
frame fragmentation and loss recovery. It defines a SCHC Compound frame fragmentation and loss recovery. It defines a SCHC Compound
ACK format, which is intended to reduce the number of response ACK format and procedure, which is intended to reduce the number of
transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of SCHC. response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of
The SCHC Compound ACK extends the SCHC ACK message format so that it SCHC. The SCHC Compound ACK extends the SCHC ACK message format so
can contain several bitmaps, each bitmap being identified by its that it can contain several bitmaps, each bitmap being identified by
corresponding window number. its corresponding window number.
The SCHC Compound ACK: The SCHC Compound ACK:
* provides feedback only for windows with fragment losses, * provides feedback only for windows with fragment losses,
* has a variable size that depends on the number of windows with * has a variable size that depends on the number of windows with
fragment losses being reported in the single Compound SCHC ACK, fragment losses being reported in the single Compound SCHC ACK,
* includes the window number (i.e., W) of each bitmap, * includes the window number (i.e., W) of each bitmap,
skipping to change at page 3, line 47 skipping to change at page 3, line 47
3. SCHC Compound ACK 3. SCHC Compound ACK
The SCHC Compound ACK is a SCHC ACK message that can contain several The SCHC Compound ACK is a SCHC ACK message that can contain several
bitmaps, each bitmap being identified by its corresponding window bitmaps, each bitmap being identified by its corresponding window
number. number.
The SCHC Compound ACK groups the window number (W) with its The SCHC Compound ACK groups the window number (W) with its
corresponding bitmap. Windows do not need to be contiguous. corresponding bitmap. Windows do not need to be contiguous.
However, the window numbers and corresponding bitmaps included in the However, the window numbers and corresponding bitmaps included in the
SCHC Compound ACK message MUST be ordered from the lowest-numbered to SCHC Compound ACK message MUST be ordered from the lowest-numbered to
the highest-numbered window. 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 3.1. SCHC Compound ACK Message Format
Figure 1 shows the regular SCHC ACK format when all fragments have Figure 1 shows the regular SCHC ACK format when all fragments have
been correctly received (C=1), as defined in [RFC8724]. been correctly received (C=1), as defined in [RFC8724].
|- SCHC ACK Header --| |- SCHC ACK Header --|
+ -------+---+------ + ------------ + + -------+---+------ + ------------ +
| RuleID | W | C=b'1 | b'0-pad(opt) | | RuleID | W | C=b'1 | b'0-pad(opt) |
+ ------ + - + ----- + ------------ + + ------ + - + ----- + ------------ +
Figure 1: SCHC Success ACK message format, as defined in RFC8724 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 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 SCHC Packet, the SCHC Compound ACK MAY be used. The SCHC Compound
ACK message format is shown in Figure 2. ACK message format is shown in Figure 2.
The window numbered 00, if present in the SCHC Compound ACK, MUST be
placed between the Rule ID and the C bit to avoid confusion with
padding bits.
|--SCHC ACK Header--| W = w1 |...| W = wi | |--SCHC ACK Header--| W = w1 |...| W = wi |
+-------------------+ ------ +...+ ------- + ------ +------------+ +-------------------+ ------ +...+ ------- + ------ +------------+
|RuleID|W=b'w1|C=b'0| Bitmap |...| W=b'wi | Bitmap |b'0-pad(opt)| |RuleID|W=b'w1|C=b'0| Bitmap |...| W=b'wi | Bitmap |b'0-pad(opt)|
+------+------+-----+ ------ +...+ ------- + ------ +------------+ +------+------+-----+ ------ +...+ ------- + ------ +------------+
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi Losses are found in windows W = w1,...,wi; where w1<w2<...<wi
Figure 2: SCHC Compound ACK message format Figure 2: SCHC Compound ACK message format
The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for
skipping to change at page 5, line 15 skipping to change at page 5, line 15
3.2. SCHC Compound ACK Behaviour 3.2. SCHC Compound ACK Behaviour
The SCHC ACK-on-Error behaviour is described in section 8.4.3 of The SCHC ACK-on-Error behaviour is described in section 8.4.3 of
[RFC8724]. The present document slightly modifies this behaviour, [RFC8724]. The present document slightly modifies this behaviour,
since in the baseline SCHC specification a SCHC ACK reports only one since in the baseline SCHC specification a SCHC ACK reports only one
bitmap for the reception of exactly one window of tiles. The present bitmap for the reception of exactly one window of tiles. The present
SCHC Compound ACK specification extends the SCHC ACK message format SCHC Compound ACK specification extends the SCHC ACK message format
so that it can contain several bitmaps, each bitmap being identified so that it can contain several bitmaps, each bitmap being identified
by its corresponding window number. 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 The following sections describe the differences between the baseline
SCHC specification and the present SCHC protocol extension SCHC specification and the present SCHC protocol extension
specification. specification.
3.2.1. Sender Behaviour 3.2.1. Sender Behaviour
OLD TEXT ([RFC8724], section 8.4.3.1) - On receiving a SCHC ACK: OLD TEXT ([RFC8724], section 8.4.3.1) - On receiving a SCHC ACK:
* (...) * (...)
* the fragment sender MUST send SCHC Fragment messages containing * the fragment sender MUST send SCHC Fragment messages containing
all the tiles that are reported missing in the SCHC ACK. all the tiles that are reported missing in the SCHC ACK.
* if the last of these SCHC Fragment messages reported missing is * if the last of these SCHC Fragment messages is not an All-1 SCHC
not an All-1 SCHC Fragment, then the fragment sender MAY either, Fragment, then the fragment sender MUST in addition send after it
send in addition a SCHC ACK REQ with the W field corresponding to a SCHC ACK REQ with the W field corresponding to the last window.
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.
NEW TEXT - On receiving a SCHC Compound ACK: NEW TEXT - On receiving a SCHC Compound ACK:
* (...) * (...)
* the fragment sender MUST resend SCHC Fragment messages containing * the fragment sender MUST resend SCHC Fragment messages containing
all the tiles of all the windows that are reported missing in the all the tiles of all the windows that are reported missing in the
SCHC Compound ACK. SCHC Compound ACK.
* if the last of these SCHC Fragment messages reported missing is * if the last of these SCHC Fragment messages reported missing is
skipping to change at page 11, line 38 skipping to change at page 11, line 38
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724, Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020, DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>. <https://www.rfc-editor.org/info/rfc8724>.
Authors' Addresses Authors' Addresses
Juan Carlos Zúñiga Juan Carlos Zúñiga
SIGFOX Cisco
Montreal QC Montreal QC
Canada Canada
Email: juzuniga@cisco.com
Email: j.c.zuniga@ieee.org
Carles Gomez Carles Gomez
Universitat Politècnica de Catalunya Universitat Politècnica de Catalunya
C/Esteve Terradas, 7 C/Esteve Terradas, 7
08860 Castelldefels 08860 Castelldefels
Spain Spain
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
Sergio Aguilar Sergio Aguilar
Universitat Politècnica de Catalunya Universitat Politècnica de Catalunya
C/Esteve Terradas, 7 C/Esteve Terradas, 7
08860 Castelldefels 08860 Castelldefels
Spain Spain
Email: sergio.aguilar.romero@upc.edu Email: sergio.aguilar.romero@upc.edu
Laurent Toutain Laurent Toutain
IMT-Atlantique IMT-Atlantique
2 rue de la Chataigneraie 2 rue de la Chataigneraie
CS 17607 CS 17607
35576 Cesson-Sevigne Cedex 35576 Cesson-Sevigne Cedex
France France
Email: Laurent.Toutain@imt-atlantique.fr Email: Laurent.Toutain@imt-atlantique.fr
Sandra Céspedes Sandra Céspedes
NIC Labs, Universidad de Chile NIC Labs, Universidad de Chile
Av. Almte. Blanco Encalada 1975 Av. Almte. Blanco Encalada 1975
Santiago Santiago
Chile Chile
Email: scespedes@niclabs.cl Email: scespedes@niclabs.cl
Diego Wistuba Diego Wistuba
NIC Labs, Universidad de Chile NIC Labs, Universidad de Chile
Av. Almte. Blanco Encalada 1975 Av. Almte. Blanco Encalada 1975
Santiago Santiago
Chile Chile
Email: wistuba@niclabs.cl Email: wistuba@niclabs.cl
 End of changes. 18 change blocks. 
38 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/