| < 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/ | ||||